Re: [PATCH] libfdt: add address translation support

[Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>]

On Mon, 2014-05-12 at 16:10 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-05-12 at 16:00 +1000, David Gibson wrote:
> > I'm not all that impressed by this translation code - in particular
> > the per-bus-type hooks don't make sense to me.  AFAIK the
> > interpretation of ranges is not bus specific. I think it will also
> > fail in some cases with #address-cells > 2, which is unfortunate.
> > 
> > I'm about to post my own implementation of address translation.
> 
> Well, I came up with the original code which did per-bus type hooks.
> There are cases where it is needed.
> 
> Take PCI. The top word can contain completely unrelated stuff such
> as the "prefetchable" attribute.
> 
> It's perfectly legal to put a prefetchable BAR under a non-prefetchable
> bridge window.
> 
> However a translation scheme that doesn't know to know that bit
> will fail.

Oh and the other way around with IO vs. memory btw.

> It's not far fetched, it happens on our machines today.
> 
> And that's just one of the problems I had back then...

Note that I'm just stating the problem :-) There may be a better way to
address it. For example, for the one above specifically, well, we could
have a per-bus-type list of masks to apply before translation (bits to
ignore).

I wish in fact OF had done that to begin with like we have
interrupt-map-mask, maybe we should introduce that concept to limit the
damage to existing well known cases like PCI and have anything new just
tell us what to use for the compare.

In fact, thinking more, the above mask trick might not fully work for
PCI, we have to check the exact values, because I think the same field
somewhat use an enumeration for 32-bit MEM, 64-bit MEM and IO ... oh
well.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html