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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Jul 2009 13:11:15 +0100
From:	David Vrabel <david.vrabel@....com>
To:	Linus Walleij <linus.walleij@...ricsson.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Pierre Ossman <pierre@...man.eu>,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [PATCH 1/2] MMC Agressive clocking framework v5

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/