Hi, On Thu, Mar 5, 2020 at 1:41 AM Maulik Shah <mkshah@xxxxxxxxxxxxxx> wrote: >> There are other cases like below which also gets impacted if driver > >> don't cache anything... > >> > >> for example, when we don’t have dedicated ACTIVE TCS ( if we have below > >> config with ACTIVE TCS count 0) > >> qcom,tcs-config = <ACTIVE_TCS 0>, > >> <SLEEP_TCS 3>, > >> <WAKE_TCS 3>, > >> > >> Now to send active data, driver may re-use/ re-purpose few of the sleep > >> or wake TCS, to be used as ACTIVE TCS and once work is done, > >> it will be re-allocated in SLEEP/ WAKE TCS pool accordingly. If driver > >> don’t cache, all the SLEEP and WAKE data is lost when one > >> of TCS is repurposed to use as ACTIVE TCS. > > Ah, interesting. I'll read the code more, but are you expecting this > > type of situation to work today, or is it theoretical for the future? > yes, we have targets which needs to work with this type of situation. My brain is still slowly absorbing all the code, but something tells me that targets with no ACTIVE TCS will not work properly with non-OSI mode unless you change your patches more. Specifically to make the zero ACTIVE TCS case work I think you need a rpmh_flush() call after _ALL_ calls to rpmh_write() and rpmh_write_batch() (even those modifying ACTIVE state). rpmh_write_async() will be yet more interesting because you'd have to flush in rpmh_tx_done() I guess? ...and also somehow you need to inhibit entering sleep mode if an async write was in progress? Maybe easier to just detect the "non-OSI-mode + 0 ACTIVE TCS" case at probe time and fail to probe? -Doug
