user/sven/linux.git/include/soc, branch v4.19.59

soc: fsl: qbman: add APIs to retrieve the probing status

2018-09-27T20:43:35Z

Add a couple of new APIs to check the probing status of qman and bman: 'int bman_is_probed()' and 'int qman_is_probed()'. They return the following values. * 1 if qman/bman were probed correctly * 0 if qman/bman were not yet probed * -1 if probing of qman/bman failed Drivers that use qman/bman driver services are required to use these APIs before calling any functions exported by qman or bman drivers or otherwise they will crash the kernel. The APIs will be used in the following couple of qbman portal patches and later in the series in the dpaa1 ethernet driver. Signed-off-by: Laurentiu Tudor Signed-off-by: Li Yang

Merge tag 'soc-fsl-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux into next/drivers

2018-07-26T07:12:56Z

Various updates to soc/fsl for 4.19 Moves DPAA2 DPIO driver from staging to fsl/soc Adds multiple-pin support to QE gpio driver * tag 'soc-fsl-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux: soc: fsl: cleanup Kconfig menu soc: fsl: dpio: Convert DPIO documentation to .rst staging: fsl-mc: Remove remaining files staging: fsl-mc: Move DPIO from staging to drivers/soc/fsl staging: fsl-dpaa2: eth: move generic FD defines to DPIO soc: fsl: qe: gpio: Add qe_gpio_set_multiple Signed-off-by: Olof Johansson

Merge tag 'qcom-drivers-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/drivers

2018-07-26T07:03:25Z

Qualcomm ARM Based Driver Updates for v4.19 * Add Qualcomm LLCC driver * Add Qualcomm RPMH controller * Fix memleak in Qualcomm RMTFS * Add dummy qcom_scm_assign_mem() * Fix check for global partition in SMEM * tag 'qcom-drivers-for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: soc: qcom: rmtfs-mem: fix memleak in probe error paths soc: qcom: llc-slice: Add missing MODULE_LICENSE() drivers: qcom: rpmh: fix unwanted error check for get_tcs_of_type() drivers: qcom: rpmh-rsc: fix the loop index check in get_req_from_tcs firmware: qcom: scm: add a dummy qcom_scm_assign_mem() drivers: qcom: rpmh-rsc: Check cmd_db_ready() to help children drivers: qcom: rpmh-rsc: allow active requests from wake TCS drivers: qcom: rpmh: add support for batch RPMH request drivers: qcom: rpmh: allow requests to be sent asynchronously drivers: qcom: rpmh: cache sleep/wake state requests drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS drivers: qcom: rpmh: add RPMH helper functions drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs drivers: soc: Add LLCC driver dt-bindings: Documentation for qcom, llcc soc: qcom: smem: Correct check for global partition Signed-off-by: Olof Johansson

staging: fsl-mc: Move DPIO from staging to drivers/soc/fsl

2018-07-24T21:18:55Z

Move the NXP DPIO (Datapath I/O Driver) out of the drivers/staging directory and into the drivers/soc/fsl directory. The DPIO driver enables access to Queue and Buffer Manager (QBMAN) hardware on NXP DPAA2 devices. This is a prerequisite to moving the DPAA2 Ethernet driver out of staging. Signed-off-by: Roy Pledge Reviewed-by: Horia Geantă Reviewed-by: Ioana Radulescu Signed-off-by: Li Yang

drivers: qcom: rpmh: add support for batch RPMH request

2018-07-21T18:33:36Z

Platform drivers need make a lot of resource state requests at the same time, say, at the start or end of an usecase. It can be quite inefficient to send each request separately. Instead they can give the RPMH library a batch of requests to be sent and wait on the whole transaction to be complete. rpmh_write_batch() is a blocking call that can be used to send multiple RPMH command sets. Each RPMH command set is set asynchronously and the API blocks until all the command sets are complete and receive their tx_done callbacks. Signed-off-by: Lina Iyer Signed-off-by: Raju P.L.S.S.S.N Reviewed-by: Matthias Kaehlcke Signed-off-by: Andy Gross

drivers: qcom: rpmh: allow requests to be sent asynchronously

2018-07-21T18:33:27Z

Platform drivers that want to send a request but do not want to block until the RPMH request completes have now a new API - rpmh_write_async(). The API allocates memory and send the requests and returns the control back to the platform driver. The tx_done callback from the controller is handled in the context of the controller's thread and frees the allocated memory. This API allows RPMH requests from atomic contexts as well. Signed-off-by: Lina Iyer Signed-off-by: Raju P.L.S.S.S.N Signed-off-by: Andy Gross

drivers: qcom: rpmh: cache sleep/wake state requests

2018-07-21T18:33:12Z

Active state requests are sent immediately to the RSC controller, while sleep and wake state requests are cached in this driver to avoid taxing the RSC controller repeatedly. The cached values will be sent to the controller when the rpmh_flush() is called. Generally, flushing is a system PM activity and may be called from the system PM drivers when the system is entering suspend or deeper sleep modes during cpuidle. Also allow invalidating the cached requests, so they may be re-populated again. Signed-off-by: Lina Iyer [rplsssn: remove unneeded semicolon, address line over 80chars error] Signed-off-by: Raju P.L.S.S.S.N Reviewed-by: Evan Green Reviewed-by: Matthias Kaehlcke Signed-off-by: Andy Gross

drivers: qcom: rpmh: add RPMH helper functions

2018-07-21T18:32:40Z

Sending RPMH requests and waiting for response from the controller through a callback is common functionality across all platform drivers. To simplify drivers, add a library functions to create RPMH client and send resource state requests. rpmh_write() is a synchronous blocking call that can be used to send active state requests. Signed-off-by: Lina Iyer Signed-off-by: Raju P.L.S.S.S.N Signed-off-by: Andy Gross

drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

2018-07-21T18:32:06Z

Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer Signed-off-by: Raju P.L.S.S.S.N Signed-off-by: Andy Gross

ARM: bcm2835: Add GET_THROTTLED firmware property

2018-06-22T00:17:11Z

Recent Raspberry Pi firmware provides a mailbox property to detect under-voltage conditions. Here is the current definition. The u32 value returned by the firmware is divided into 2 parts: - lower 16-bits are the live value - upper 16-bits are the history or sticky value Bits: 0: undervoltage 1: arm frequency capped 2: currently throttled 16: undervoltage has occurred 17: arm frequency capped has occurred 18: throttling has occurred Signed-off-by: Stefan Wahren Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt