On 29/06/16 17:24, Ritesh Harjani wrote: > Hi Adrian, > > On 6/29/2016 6:54 PM, Adrian Hunter wrote: >> Hi >> >> Here is an updated version of the Software Command Queuing patches, >> re-based on the SDHCI patches that I have. >> >> Ulf, there are a lot of patches now and I think it would be worth taking >> some of them. For example, the first 25 affect SDHCI only. If you accept >> the "Command during Transfer" API introduced in patch 26, then you could >> take patches 26-30 as well. > Are these patches affecting anything w.r.t. SW/HW CMDQ solution? No. There are changes to SDHCI but it should be straight forward to re-base on top of them. > Although not yet gone through in detail. > But otherwise do you think it will be worthwhile to check both the solutions > before merging any particular design to upstream? Yes, that needs to be done. > > > Well actually as you are aware of, HW CMDQ solution separate out itself from > legacy w.r.t. pulling/issuing/completing of reqs. > So mostly it should not affect much here w.r.t. SW CMDQ, but it will be good > if we could consider, how both solution will look into upstream going forward. Yes, they are essentially separate but with some common ground around switching. > >> >> There wasn't much comment on the RFC so there have been few changes. >> Venu Byravarasu commented that it may be more efficient to use Software >> Command Queuing only when there is more than 1 request queued - it isn't >> obvious how well that would work in practice, but it could be added later >> if it could be shown to be beneficial. > Agree. > >> >> I haven't had a chance to go through the hardware Command Queuing patches >> in detail yet, but otherwise these patches are ready to go. > Request you to kindly review HW CMDQ patches as well before we plan to merge > both of them to upstream? Yes I will review the HW CMDQ patches. > We do as well plan to go through SW CMDQ set of patches. Yes please! -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
