[PATCH linux dev-4.7 1/3] ARM: dts: aspeed-g5: Add SoC Display Controller node

[Andrew Jeffery]

On Tue, 2017-02-14 at 09:27 +1030, Joel Stanley wrote:
> > On Tue, Feb 14, 2017 at 3:54 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> > On Mon, Feb 13, 2017 at 01:28:49PM +1030, Andrew Jeffery wrote:
> > > diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> > > index e1994c9e38c3..5ce0a7a65e77 100644
> > > --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> > > +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> > > @@ -1005,6 +1005,12 @@
> > >                               reg = <0x1e6e202c 0x4>;
> > >                       };
> > > 
> > > > > > +                     gfx: display at 1e6e6000 {
> > > +                             compatible = "aspeed,ast2500-gfx", "syscon";
> > > +                             reg = <0x1e6e6000 0x1000>;
> > > +                             reg-io-width = <4>;
> > > +                     };
> > > +
> > 
> > Is this valid to add on all G5 chips?  I believe Zaius is using a
> > variant of the 2500 that does not have the graphics engine.
> 
> Andrew, do we need to fix this now? If so, can you please re-spin with
> this set to disabled, and enabling it in the .dts?

We should do that regardless. I'll resend. We should also fix that
upstream.

> 
> How does this affect your pinmux driver? 

I scanned the first two pages of the pinmux tables comparing the 2510
to the 2500: Many functions have been deleted for the 2510, but the
pinmux configuration remains the same. Further evidence for the
controller being the same is the 2510 claims to be pin compatible with
the 2500.

It appears that other chips are subsets of the 2500's functionality, so
in the easy case we just need a small mod to the bindings and to the
driver so we can selectively register phandles relevant to the hardware
(e.g. only the lhc phandle in the case of the 2520, which doesn't have
gfx).

If you want to make the driver more tedious but arguably more correct,
you could also advertise a restricted set of mux functions depending on
the matched compatible string. Given you need to know your hardware to
mux functions to begin with, I'd argue if you want to foot-gun by
muxing functions that don't exist in the SoC at hand, then go ahead.

> Can we still mux all of the
> pins on the 2510?

The way it works is you can enable deleted functions in the pinmux and
effectively disable the use of a pin as the function doesn't exist.
There shouldn't be any other side-effects.

> 
> Cheers,
> 
> Joel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170214/1eaa60a0/attachment-0001.sig>