[PATCH 0/6] AM43xx & OMAP5 DSS DT changes

[tony@atomide.com (Tony Lindgren)]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 08:33]:
> On 21/05/14 18:26, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 08:18]:
> >> On 21/05/14 18:02, Tony Lindgren wrote:
> >>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140521 05:51]:
> >>>> Hi,
> >>>>
> >>>> Here are the AM43xx and OMAP5 display DT changes again. I've sent the clock
> >>>> related changes separately, and I removed OMAP5's RFBI node, which depends on
> >>>> more clock changes. The RFBI driver doesn't work at the moment anyway, so
> >>>> removing the RFBI node should not be an issue.
> >>>>
> >>>> Tony, if these look fine (the rfbi change is the only one compared to the
> >>>> previous versions), can you queue them for 3.16?
> >>>
> >>> Probably best that you do a late branch again after arm-soc dts changes
> >>> have been merged. Sounds like you have at least that macro dependency
> >>> to omap-for-v3.16/dt-v2 so you should probably base your branch on
> >>
> >> There are no dependencies that I know of. Which macro dependency is that?
> > 
> > Oh for the "[PATCH v2] ARM: dts: duovero-parlor: Add HDMI output" that
> > now uses the OMAP4_IOPAD macro.
> 
> Ok.
> 
> But generally, isn't it better if the .dts changes go through your tree?
> None of the display related .dts changes have any dependencies to
> omapdss as such.

Yes in general, but it's getting very late for v3.16, and..
 
> I can collect the patches, as I've done, to let them mature a bit in my
> tree, but I'd rather get them merged via your dt branch.

..I may not queue any more patches for v3.16. The branches I've sent have
not yet been merged into arm-soc, so at minimum I'm going to wait for
that. If we have -rc6 tagged today and no -rc7, I'm switching into fixes
only mode. So in this case it's probably best that you merge them so
we can get the display dependency out of the way for v3.16.

Regards,

Tony