[PATCH 5/8] of: Add Tegra124 EMC bindings

[thierry.reding@gmail.com (Thierry Reding)]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140714/ff6d249a/attachment-0001.sig>