[REGRESSION 4.10] dw_mmc: failures on Rockchip rk3288 veyron boards
shawn.lin at rock-chips.com
Thu Apr 13 01:28:10 PDT 2017
在 2017/4/13 0:12, Doug Anderson 写道:
> On Tue, Apr 11, 2017 at 5:54 PM, Shawn Lin <shawn.lin at rock-chips.com> wrote:
>>> This doesn't surprise me at all. What surprises me, though, is that
>>> nobody else seems to be able to reproduce this.
>>> On veyron, WiFi is connected via SDIO. For good speed, it uses SDIO
>>> Interrupts. See this bit in the device tree:
>> all of *my* boards are using side-band interrupt, so there are no
> They are all using side-band interrupt? What WiFi device do you have connected?
I'm using brcm wifi that using out-of-tree drivers.
> If you're truly using a side-band interrupt using the dedicated SDIO
> interrupt pin on your SoC, I'm pretty sure you still need to define
Not really. The intention of using side-band int is that we could put
the host into low power mode(maybe with pd off), so that the wifi could
still works with Socs. And mostly, we don't need to keep the controller
on when in S3. The side-band io could be registered as a gpio interrupt
(wakeup source), and once the wifi chip need to communicate with Socs,
it could wakeup the system(of course sdio controller will be alive
then). Also, once using side-band interrupt, the interrupt service and
management should be done with the wifi function drivers. I'm pretty
sure that my at-hand drivers, for instance, brcm and realtek actually
> cap-sdio-irq in order for things to work properly. If you don't do
> that, you'll get "polling mode" for SDIO Interrupts. See
> sdio_irq_thread() where you can see that the kernel will poll your
> device every 10 ms if MMC_CAP_SDIO_IRQ isn't set.
> Maybe you should try defining cap-sdio-irq and see if you get a big
> performance boost?
Sorry, I didn't test the upstreamed wifi drivers but from the test of my
out-of-tree wifi drivers, there is no much difference.
More information about the Linux-rockchip