On 01/15/2014 02:06 AM, Thierry Reding wrote:
> 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.
>>> 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).
OK, that last bit is the important part. So, this is fine.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
