> > I guess using the clk_notifier may be OK for the 1st case. > > In both cases, isn't the overall operation something like: > > a) Do some work before changing the EMC clock > b) Change the EMC clock > c) Do some work after changing the EMC clock > There is hw interaction between the EMC controller and the CAR module. Writing to the EMC clock source register in CAR will trigger a state machine in the EMC controller to handle the change of memory clock. The details of the state machine and how it needs to be setup are different for each Tegra variant. This means we need to be sure of the exact sequence of CAR and EMC register accesses for this to work. In theory this could be done with pre and post rate change notifiers, but I'm afraid this would be quite fragile. > Admittedly, the exact definition of "some work" is different for your > cases (1) and (2) above, but the overall structure is the same. As such, > can't the EMC scaling driver do (a), then do (b) i.e. call > clk_set_rate(), then do (c)? Or, in your case (2), do we need to do We would need to be very sure clk_set_rate() doesn't access any other register besides the EMC clock source register before returning to the EMC scaling driver. > funny tricks like running from IRAM since we can't access SDRAM during > the clock change? If so, I'm not sure how having the EMC clock changing > code is going to help your case (2) anyway, since we'll presumably have > to code up a custom stub in assembly for the part of the code that runs > from IRAM... > There is no need for assembler or running from IRAM (at least from Tegra30 onwards, I don't know about Tegra20). Cheers, Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
