lkml.org 
[lkml]   [2014]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
    On 09/12/14 15:41, Lee Jones wrote:
    >>>>>>>> struct max77693_led_platform_data {
    >>>>>>>> > >>>>>>+ const char *label[2];
    >>>>>>>> > >>>>>> u32 fleds[2];
    >>>>>>>> > >>>>>> u32 iout_torch[2];for_each_available_child_of_node
    >>>>>>>> > >>>>>> u32 iout_flash[2];
    >>>>>>>> > >>>>>> u32 trigger[2];
    >>>>>>>> > >>>>>> u32 trigger_type[2];
    >>>>>>>> > >>>>>>+ u32 flash_timeout[2];
    >>>>>>>> > >>>>>> u32 num_leds;
    >>>>>>>> > >>>>>> u32 boost_mode;
    >>>>>>>> > >>>>>>- u32 flash_timeout;
    >>>>>>>> > >>>>>> u32 boost_vout;
    >>>>>>>> > >>>>>> u32 low_vsys;
    >>>>>>>> > >>>>>>+ struct device_node *sub_nodes[2];
    >>>>>>> > >>>>>
    >>>>>>> > >>>>>I haven't seen anyone do this before. Why can't you use the provided
    >>>>>>> > >>>>>OF functions to traverse through your tree?
    >>>>>> > >>>>
    >>>>>> > >>>>I use for_each_available_child_of_node when parsing DT node, but I
    >>>>>> > >>>>need to cache the pointer to sub-node to be able to use it later
    >>>>>> > >>>>when it needs to be passed to V4L2 sub-device which is then
    >>>>>> > >>>>asynchronously matched by the phandle to sub-node.
    >>>>>> > >>>>
    >>>>>> > >>>>If it is not well seen to cache it in the platform data then
    >>>>>> > >>>>I will find different way to accomplish this.
    >>>>> > >>>
    >>>>> > >>>I haven't seen the end-driver for this, but why can't you use that
    >>>>> > >>>device's of_node pointer?
    >>>> > >>
    >>>> > >>Maybe it is indeed a good idea. I could pass the of_node pointer
    >>>> > >>and the sub-led identifier to the V4L2 sub-device and there look
    >>>> > >>for the sub-node containing relevant identifier. The downside
    >>>> > >>would be only that for_each_available_child_of_node would
    >>>> > >>have to be called twice - in the led driver and in the V4L2 sub-device.
    >>>> > >>I think that we can live with it.
    >>> > >
    >>> > >Are the LED and V4L2 drivers children of this MFD? If so, you can use
    >>> > >the of_compatible attribute in struct mfd_cell to populate the each
    >>> > >child's of_node dynamically i.e. the MFD core will do that for you.
    >>> > >
    >> >
    >> > V4L2 driver wraps LED driver. This way the LED device can be
    >> > controlled with use of two interfaces - LED subsystem sysfs
    >> > and V4L2 Flash. This is the aim of the whole patch set.
    >> >
    >> > I've thought it over again and it seems that I will need to cache
    >> > somewhere these sub_nodes pointers. They have to be easily accessible
    >> > for the V4L2 sub-device as it can be asynchronously registered
    >> > or unregistered within V4L2 media device. Sub-devices are matched
    >> > basing on the sub-node phandle.
    >
    > Not quite getting this. Can you explain this in another way please?

    Only the LED controller driver is a child the MFD. The LED controller
    can contain multiple outputs with a physical LED attached to it. AFAICS
    this binding is modelling each such an output as a the LED's controller
    node child node.

    I'm not sure though why storing the device node pointers is required,
    rather than traversing OF tree when needed.
    I guess we only need the list of the node pointer to populate struct
    v4l2_async_subdev array for v4l2_async_notifier_register() call ?


    --
    Regards,
    Sylwester


    \
     
     \ /
      Last update: 2014-12-09 16:21    [W:4.150 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site