TX FSM reset command generates TX_RESET_DONE & TX_DMA_DONE interrupt bits.
Upon receiving TX_DMA_DONE we initiate new TX transfer for the pending
bytes present in tty uart circular buffer. That leaves TX sequencer active
after reset sequence. That can result into all kinds of SMMU crash where
client initiates new TX DMA transfer without knowing that we have already
a transfer queued. This is unexpected behaviour because we expect TX
sequencer and DMA engine to go IDLE after reset.
To fix above scenario, don't handle TX_DMA_DONE upon reciving
TX_RESET_DONE.
Also, add IPC logs to get_mctrl function to get the IOS status.
Change-Id: Ib76750b5e2c6ec5bf993c341c258791e471672d2
Signed-off-by: Akash Asthana <akashast@codeaurora.org>
Some customers are using UART node in UFFI for console and using
the same node for HSUART in kernel but not as console. In this
scenario there is a possibility for null pointer access
with handle_rx while trying to stop secondary sequencer.
This change will move handle_rx initialization from port_startup to
probe function. This will help to avoid null pointer access issues.
Change-Id: Ibda592b375d14ba0c23c4b99223006b1fa53c211
Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
Signed-off-by: Akash Asthana <akashast@codeaurora.org>
msm_geni_serial: Use the common driver API for dma_alloc
msm: msm-geni-se: Make DFS clock table specific to SE of QUP
serial: msm_geni_serial: Don't depend on clock freq table to set baud
rate
msm-geni-serial: Correct the interrupt polling logic in uart
serial: msm_geni_serial: Improve IPC logging in UART driver
serial: msm_geni_serial: drop port->lock before tty_flip_buffer_push()
call
serial: msm_geni_serial: No need to stop_tx/rx on UART shutdown
serial: msm_geni_serial: Do not check_transfers_inflight() post
port_close
serial: msm_geni_serial: Enable IRQ from port startup
serial: msm_geni_serial: Fix geni_wait_for_cmd_done timeouts
serial: msm_geni_serial: Do not drop port->lock in polling mode
Also, fix stackoverflow issue seen after propagating above changes.
Console TX is getting stuck in recursive call and leading to
stackoverflow issue.
Steps that leads to bad recursion call:
1) msm_geni_serial_handle_tx calls for stop_tx if all the data are sent and
acknowledged.
2) stop_tx issue cancel command if the main sequencer is still
active.
3) As part of cancel command execution msm_geni_serial_handle_tx is called
again that takes us to step 1 and goes in a loop.
To fix above scenario remove the stop_tx call from geni_serial_handle_tx
because if the data is transmited and acknowledged main sequencer should
automatically go to inactive state.
Ideally we should never enter into this situation the first place because
after receiving CMD_DONE we expect that sequencer will go IDLE/inactive.
So, probably this can be a race btw updation of CMD_DONE and GENI_STATUS
register because after adding some more IPC logs in the above code path we
are not hitting this issue. It might be adding required delay.
Change-Id: I85cfe87170ea347c4b8d98c858cc762da413624f
Signed-off-by: Prudhvi Yarlagadda <pyarlaga@codeaurora.org>
Signed-off-by: Chandana Kishori Chiluveru <cchiluve@codeaurora.org>
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
Signed-off-by: Akash Asthana <akashast@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>
Fixed the names of the SW_CTRL and Debug GPIOs in devicetree.
Change-Id: Ibdcc1164cd88a65fe5b33927f2b0f0098c15af1f
Signed-off-by: Umesh Vats <uvats@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>
