On Tue, Jan 14, 2014 at 10:53:19AM -0700, Stephen Warren wrote: > On 01/14/2014 07:45 AM, Thierry Reding wrote: > > The head number of a given display controller is fixed in hardware and > > required to program outputs appropriately. Relying on the driver probe > > order to determine this number will not work, since that could yield a > > situation where the second head was probed first and would be assigned > > head number 0 instead of 1. > > > > By explicitly specifying the head number in the device tree, it is no > > longer necessary to rely on these assumptions. As a fallback, if the > > property isn't available, derive the head number from the display > > controller node's position in the device tree. That's somewhat more > > reliable than the previous default but not a proper solution. > > The series, > Tested-by: Stephen Warren <[email protected]> > > This patch should really have been sent to the DT maintainers and list > since it changes a DT binding...
Indeed. I'll resend this to the appropriate people and lists. Sorry
about that.
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>
> > +static int tegra_dc_parse_dt(struct tegra_dc *dc)
> > +{
> > + struct device_node *np;
> > + u32 value = 0;
> > + int err;
> > +
> > + err = of_property_read_u32(dc->dev->of_node, "nvidia,head", &value);
>
> If of_property_read_u32() returns an error, does it guarantee that value
> is left unchanged? I suspect it'd be safer to add ...
That's the way it's always been at least. of_property_read_u32() ends up
calling of_property_read_u32_array(), which looking at the code only
modifies the out_values parameter when it knows that it will succeed.
Furthermore the function's kernel-doc explicitly says that "out_values
is modified only if a valid u32 value can be decoded" (i.e. on success).
Thierry
pgpf88hIiW1JY.pgp
Description: PGP signature
