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 <swarren@xxxxxxxxxx>
>
> 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
Attachment:
pgpF6DjC1LTxb.pgp
Description: PGP signature
