2009/10/2 Magnus Damm <magnus.damm@xxxxxxxxx>: >> I asked if the clock freq. changes - you said 'Well, the goal is >> dynamic clocks, but at this point it's dynamic until the clock is >> enabled'. >> >> Since your code doesnt set the clock frequency, that means the MMC >> drivers f_max will be set to whatever the clock was running at when >> you grab it. > > Yes? Well if its set to 512kHz prior to being claimed, that means the MMC clock will run between 1kHz and 512kHz tmio_mmc will work like that but it seems kinda daft... > You can call it whatever you want. On SuperH we can do clock scaling > which seems very dynamic to me. But before changing the clock we need > to make sure that all drivers and hardware blocks support changing > the frequency. Changing the clock frequency while the driver or > hardware needs it fixed is of course a programming error. exactly - which is one reason why I said your clk based implementation is broken - tmio_mmc has no logic for coping with a clock that changed frequency. Since all tmio-based devices appear to have the frequency-divider built in, I suspect that all tmio units expect to have a host (input) clock in the 20-30MHz range. Since the superH tmio blocks clock divider is missing the unity divisor, varying the imput clock speed to change the MMC bus frequency seems like a bad idea. If you could do unity-divisor then you might be able to save a little power disabling the TMIO divisor and adjusting the input clock frequency >> Well the tmio MFD drivers do just that, if you take a look. The hooks >> are already there. > > Do you mean powering off the SD-Card? Well the CNF area controls card clocking and power. but the MFD code provides enable and disable hooks. Cutting the clock and sleeping the chip is the best the toshiba hardware can do, but theres no reason not to turn off the chip when its not in use (as opposed to suspended / idle - or the registers will lose state) > I don't think your MFD drivers do that, Actually they do provide provision for that by means of the enable / disable hooks. if you unload the driver, the disable hook will get called and you can power it off there. > especially since the Runtime > PM framework was merged quite recently and I doubt that there are any > ARM implementations available upstream at this point. Thats something for the future - right now tmio-mmc wont take power being interrupted whilst it runs. > I've already tested the first patch with my series that that I posted > earlier today. So from the SuperH side things are ok. Great - as soon as Philipp gets back to us with the ASIC3 update I'll re-do my patchset to include ASIC3 - if the changes to tmio-mmc and submitted seperately, it will break ASIC3 so that needs to go in the same patchset. Philipp will be ready this weekend, not long to wait. -- Ian Molton Linux, Automotive, and other hacking: http://www.mnementh.co.uk/ -- 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
