On Wed, 2017-01-18 at 17:44 -0800, Steve Longerbeam wrote:
> 
> On 01/14/2017 02:42 PM, Steve Longerbeam wrote:
> >
> >>> +/* parse inputs property from a sensor node */
> >>> +static void of_parse_sensor_inputs(struct imx_media_dev *imxmd,
> >>> +                            struct imx_media_subdev *sensor,
> >>> +                            struct device_node *sensor_np)
> >>> +{
> >>> + struct imx_media_sensor_input *sinput = &sensor->input;
> >>> + int ret, i;
> >>> +
> >>> + for (i = 0; i < IMX_MEDIA_MAX_SENSOR_INPUTS; i++) {
> >>> +         const char *input_name;
> >>> +         u32 val;
> >>> +
> >>> +         ret = of_property_read_u32_index(sensor_np, "inputs", i, &val);
> >>> +         if (ret)
> >>> +                 break;
> >>> +
> >>> +         sinput->value[i] = val;
> >>> +
> >>> +         ret = of_property_read_string_index(sensor_np, "input-names",
> >>> +                                             i, &input_name);
> >>> +         /*
> >>> +          * if input-names not provided, they will be set using
> >>> +          * the subdev name once the sensor is known during
> >>> +          * async bind
> >>> +          */
> >>> +         if (!ret)
> >>> +                 strncpy(sinput->name[i], input_name,
> >>> +                         sizeof(sinput->name[i]));
> >>> + }
> >>> +
> >>> + sinput->num = i;
> >>> +
> >>> + /* if no inputs provided just assume a single input */
> >>> + if (sinput->num == 0)
> >>> +         sinput->num = 1;
> >>> +}
> >> This should be parsed by the sensor driver, not imx-media.
> >
> > you're probably right. I'll submit a patch for adv7180.c.
> 
> Actually, the problem here is that this parses an input routing value to
> pass to s_routing, and an input name string. There would need to be
> another subdev callback, maybe enum_imput, that would return this
> information for the bridge driver, if this info were to be parsed and
> maintained by the sensor.
> 
> But this info should really be known and parsed by the bridge anyway,
> because as the header for s_routing states,
> 
> "An i2c device shouldn't know about whether an input pin is connected
>   to a Composite connector, because on another board or platform it
>   might be connected to something else entirely. The calling driver is
>   responsible for mapping a user-level input to the right pins on the i2c
>   device."

I think this description is for non-DT only, as parsing the DT bindings
is the obligation of the bound driver, and with that it information it
can very well know its connections.

regards
Philipp

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to