On Thu, Jan 20, 2011 at 05:28:55PM +0900, Magnus Damm wrote: > On Thu, Jan 20, 2011 at 4:07 PM, Simon Horman <horms@xxxxxxxxxxxx> wrote: > > As we discussed (offline) yesterday, it ought to be possible > > to change the frequency of the clock source. And in the case of > > the mackerel this can probably be done without disturbing anything > > else as there are per SHDI clock sources. > > Uhm, this is not entirely correct. The sh7372 used by Mackerel is in > this case similar to most older SH processors and shares a clock > between all SDHI hardware blocks. This clock is also shared with a > bunch of other peripherals, so we can't adjust it freely during > runtime. > > The sh73a0 processor has per-SDHI block clock control. > Or at least the driver would need to have some logic for attempting to make the change and being rejected by the clock framework for the shared clock case. It should be pretty trivial to make this behaviour configurable anyways, given that the driver is largely impervious to the clock refcount otherwise. If the blocks in question are optionally capable of driving their own clocks and exposing a wider range of frequencies, then that's something that should be looked in to as well. For older blocks we're likely not going to have a lot of flexibility with regards to the clock source, though. > > I imagine it would be possible to manipulate the frequency > > such that MMC can be run closer to 20Mhz than 12Mhz. > > > > However, I am unsure if this would improve performance in any way. > > It most likely would. Perhaps it's worth adjusting the shared clock a > bit to support 20MHz? > "Most likely" isn't a constructive performance metric. It's worth trying out, and if it helps then of course it makes sense to try and support. It's not really worth going through and adding in additional complexity in order to support every possible frequency just becase we can, however. It would also be good to see what's going on with class 2 and 10 here, given that we still aren't seeing expected class 10 numbers, regardless of frequency. -- 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
