> > > > > On Wed, 11 Oct 2023 at 07:36, Ricky WU <ricky_wu@xxxxxxxxxxx> wrote: > > > > > > > > Hi Ulf Hansson, > > > > > > > > Can I know what is this patch status or has some concern on this patch? > > > > > > Didn't you read my earlier replies? > > > > > > > Are you talking about BFQ for testing speed? > > Because we tested the Read/Write speed are better than before and our > customer that uses our reader on their product also tested the Read/Write > speed, they want us to push this patch on > > It's certainly a very positive thing that your target is to upstream > solutions that improve performance. We all appreciate this! > > In this regard, I believe I have tried to guide you on how to move > forward with this. This particular optimization doesn't belong in an > mmc host driver, but rather at the common upper block device driver > layer, such that it can benefit more than one particular mmc host > driver. > > I fully understand that making that kind of improvement is way more > difficult and requires in-depth analysis to understand what is > happening on those layers too. On the other hand it could be something > that may benefit a lot of devices/platforms. Unfortunately, I am > currently not in a position where I have the bandwidth to dive deeper > into this. > > If you decide to pursue your investigations, I think we need to > involve the experts from the common block community (linux-block > mailing list) to get their advice. > > So to be clear, I am not going to apply $subject patch - or anything > similar to an mmc host driver. > This improve performance solution is developed for our HW design We discussed internally, The CMD 12 response timing is depend on HW design so this solution maybe cannot meet all devices, and the core part of this mechanism is when we got sequential data we control our DMA register for read/write data, this operating has different designed on different device, so this is not easy to push a same way on the mmc core. > > Kind regards > Uffe
