The ufs_reset pin is expected to be wired to the reset pin of the
primary UFS memory but is pretty much just a general purpose output pin.
Reorder the pins and expose it as gpio 156, so that the UFS driver can
toggle it.
Change-Id: I566196bd2ab6629c2761b47ed844022cf9ffb458
Signed-off-by: Nitin Rawat <nitirawa@codeaurora.org>
Currently USB top and bottom half are using same index to update
number of events posted/handled, and updating relevant time. As
top half is not guaranteed to be prevented when bottom half is
running those index based logging doesn't allow to relate information.
Also start logging bh_start_time and increase existing buffer size
from 10 to 25 to get more data of USB interrupt processing.
Also get count how many cancelled requqest being given back from
bottom half context, and log any update/start cmd failure.
Change-Id: Iefc883cb5a2259f256f30c9727db8a68ddd41af7
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
This change is for general scheduler improvements.
Change-Id: Ica36bb6ccd4c2d8897dab62614eadb5a060d5390
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
This change is for general scheduler improvements.
Change-Id: I3a220142f08a9664845b4d0e9918ec7c48bb11f7
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Enable PSI ftrace logging to collect ftrace information about
PSI events.
Change-Id: Ia4d786f5cbc242991fd0e0ecdb63d16714bffeb8
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Some tpdm don't support cmb msr, add an option "qcom,cmb-msr-skip"
to indicate whether MSR is supported.
Change-Id: I8ae66e639fe68b236ad8a268b18acbda737a9d93
Signed-off-by: Yuanfang Zhang <zhangyuanfang@codeaurora.org>
Certain GPIOs are reserved for secure world and cannot be accessed by HLOS.
Supply "reserved_gpios" to msm_pinctrl to mark these pins as invalid.
Change-Id: Ic8f45181b2210a6295bba1bdec45d24e607bede9
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
Userspace does not have access to MM_STAT configs, so remove redundant
config checks.
Change-Id: I0ec0807a1e62bd5932f01ed285f2175f27900e37
Signed-off-by: Prakash Gupta <guptap@codeaurora.org>
Update pinctrl configuration for Shima, to match the
latest released configuration.
Change-Id: I1537735755e1a0384a9c48dca6184a85b49b2237
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
There is a possibility of client driver's dev_wake request
as part mhi_device_get() racing with M1 state transition
event processing. This can result in a scenario where client
finds MHI state as M0 after mhi_device_get() returns only to
be changed later as M1 event processing is still pending on
different CPU core.
It causes M0 -> M2 -> M0 state transition after mhi_device_get()
has already returned. This isn't expected by client and currently
treats that as fatal error. Also, as per MHI spec host must allow
M1 -> M2 transition for device and it shouldn't abort that.
However, clients can ignore that transition as device is expected
to immediately move from M2 to M0 without entering deep sleep
state. Hence, it must be safe to access their MMIO.
To simplify this logic, introduce mhi_device_get_sync_atomic()
function that can be used by clients to achieve the same and once
it returns success they don't need to have any explicit MHI state
checks.
Change-Id: I0b4a1ad723a0444ee2402bf171fc5ffc46afcdce
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
The sleep/wake state batch requests are saved in a linked list and
flushed along with other sleep/wake request when entering system low
power modes. Caches are flushed only if the state flag is marked dirty.
A race situation could cause the batch sleep/wake requests to not be
flushed. Here is how this could happen -
- Interconnect driver (ICC) invalidates the sleep/wake requests
- RSC driver clears the TCSes (BCM, VRM, ARC sleep votes cleared)
- ICC sends an active state response-required request
- RSC driver sends the AMC request
- RPMH waits on the response, calls wait_for_completion
- Scheduler schedules idle thread
- cpuidle enters cluster idle state
- RPMH flushes cache and marks cache clean
(no BCM votes in TCS)
- RSC driver receives IRQ response
- RPMH calls complete()
- ICC worker thread resumes execution
- ICC driver calls RPMH driver with updated sleep and wake votes
- RPMH caches the request, *cache is NOT marked dirty*
- Scheduler schedules idle thread
- cpuidle enters cluster idle state
- Cache is clean and nothing to flush
- CPU enters idle
=>ICC sleep/wake votes are not sent
Fix this by dirtying the cache state even when caching batch requests.
Change-Id: I7613e665d181f8abb27915d622442e7b981f9fcc
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
