Re: [PATCH 1/2] MMC Agressive clocking framework v5

[David Vrabel]

Linus Walleij wrote:
> This patch modified the MMC core code to optionally call the
> set_ios() operation on the driver with the clock frequency set
> to 0 (gate) after a grace period of at least 8 MCLK cycles, then
> restore it (ungate) before any new request. This gives
> the driver the option to shut down the hardware block clock and
> thus (in known designs) the MCI clock to the MMC/SD card when
> the clock frequency is 0, i.e. the core has stated that the MCI
> clock does not need to be generated.

I'm not sure this is the right approach.

1. With some controllers (e.g., PXA270 I think) turning the clock on and
off is slow.  This means if you're doing back-to-back commands you
should leave the clock on for best performance.  I think there needs to
be a higher level active/idle knob for the user of the card (be it the
block driver or an SDIO function driver) to control whether to idle the
bus clock or controller.

2. Some controllers cannot detect SDIO interrupts if the clock is
stopped.  There should either be a distinction between clock off and
clock idle.

3. Regardless of point 1 above.  Using a workqueue item in this way
seems overkill.  Consider using a timer and simply calling mod_timer()
at the start of every command.  When the timer expires, idle the clock.
 You will probably need a "command in progress" bit to ensure you don't
idle the clock if the timer expires in the middle of a command.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/


'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/