On Mon, Jul 14, 2014 at 12:06:32PM +0300, Mikko Perttunen wrote: > On 14/07/14 11:15, Thierry Reding wrote: > >* PGP Signed by an unknown key > > > >On Mon, Jul 14, 2014 at 10:55:51AM +0300, Mikko Perttunen wrote: > >>On 11/07/14 19:01, Mikko Perttunen wrote: > >>>On 07/11/2014 05:51 PM, Thierry Reding wrote: > >>>>On Fri, Jul 11, 2014 at 05:18:30PM +0300, Mikko Perttunen wrote: > >>>>>... > >>>>... > >>> > >>>In this case, all the registers that will be written are such that the > >>>MC driver will never need to write them. They are shadowed registers, > >>>meaning that all writes are stored and are only effective starting from > >>>the next time the EMC rate change state machine is activated, so writing > >>>them from anywhere except than the EMC driver would be pointless. > >>> > >>>I can find two users of these registers in downstream: > >>>1) mc.c saves and loads them on suspend/restore (I don't know why, that > >>>shouldn't do anything. They will be overridden anyway during the next > >>>EMC rate change). > >>>2) tegra12x_la.c reads MC_EMEM_ARB_MISC0 during a core_initcall to > >>>calculate a value which it then writes to a register that is also > >>>shadowed and that is part of downstream burst registers so that doesn't > >>>do anything either. > >>> > >>>The reason I implemented two ways to specify the MC register area was > >>>that this could be merged before an MC driver and retain > >>>backwards-compatibility after the MC driver arrives. > >>> > >>>If this is not acceptable, we can certainly wait for the MC driver to be > >>>merged first. (Although with the general rate of things, I hope I won't > >>>be back at school at that point..) I assume that this is blocked on the > >>>IOMMU bindings discussion? In that case, there are several options: the > >>>MC driver could have its own tables for each EMC rate or we could just > >>>make the EMC tables global (i.e. not under the EMC node). In any case, > >>>the MC driver would need to implement a function that would just write > >>>these values but be guaranteed to not do anything else, since that could > >>>cause nasty things during the EMC rate change sequence. > >> > >>Having taken another look at the code, I don't think the MC driver could do > >>anything that bad. There are also two other places where the EMC driver > >>needs to read MC registers: Inside the sequence, it reads a register but > >>discards its contents. According to comments, this acts as a memory barrier, > >>probably for the preceding step that writes into MC memory. If the register > >>writes are moved to the MC driver, it could also handle that. In another > >>place it reads the number of RAM modules from a MC register. The MC driver > >>could export this as another function. > > > >Exporting this functionality from the MC driver is the right thing to do > >in my opinion. > > Ok, let's do that then. Do you think I could make a bare-bones MC driver to > support the EMC driver before your MC driver with IOMMU/LA is ready? Can the > MC device tree node be stabilized yet? Of course, if things go well, that > concern might turn out to be unnecessary. Well, at this point this isn't 3.17 material anyway, so there's no need to rush things. I'd prefer to take a patch on top of my proposed MC driver patch in anticipation of merging that for 3.18. But if it turns out that for whatever reason we can't do that, having a separate patch makes it easy to extract the changes into a bare-bones driver. Thierry
Attachment:
pgpDUXvlAawGj.pgp
Description: PGP signature
