[lkml]   [2011]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.
    >> 1. A simple potentially hotplugged device that registers itself to the
    >> bus
    >> can be automatically matched to the driver.
    >> 2. A device tree representation for hardwired devices that require
    >> something to happen in order to register to the bus (clock,
    >> regulator,
    >> ...).
    >> 3. A hardcoded list of devices on a slimbus host for stuff that is known
    >> to be there, e.g. on a PCI card that has its own driver and that
    >> also need some special setup as in case 2.
    >> I think in all three cases, we should identify the device by its EA and
    >> match that to the device driver. We create the slim_device and register
    >> it to the bus as soon as one of the three above is found, but in case 2
    >> and 3, the driver is responsible for the device to actually become
    >> active
    >> on the bus before it's allowed to send any commands to it.
    > Yes, I think that makes sense and it matches what we're doing with the
    > other subsystems well. We should be able to make the drivers work with
    > all cases. Probably the probe function should have a flag and/or query
    > function to let the driver know if the device has actually appeared yet.

    Thanks again everyone for your feedback.
    I will make sure to use the fields of the 48-bit elemental address for
    device-to-driver-matching and will try to incorporate hot-plug
    capabilities for the device powering up without assistance from the
    driver's probe function. Other cases discussed in the mixed-approach will
    be supported as well.
    Another suggestion about probe is having callback to notify when the
    device is ready-to-use after driver probe powers it up. I will change the
    framework accordingly to have this done.

    >> For the device tree binding, I would suggest defining a slimbus bus to
    >> have #address-cells=1, #size-cells=0 and just put the EA into the reg
    >> property. This is enough for the host driver to add create a
    >> slim_device and match a driver to it. The driver can access all the
    >> properties from the device_node (or platform_data in case of statically
    >> defined devices). When the physical device shows up on the bus, it is
    >> automatically associated with the existing slim_device.
    > Sounds reasonable I'd need to actually look at the specs again for the
    > details.
    I will try to incorporate device-tree binding in the framework and put it
    up for review for more suggestions.


    Sent by an employee of the Qualcomm Innovation Center, Inc.
    The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

     \ /
      Last update: 2011-08-22 00:13    [W:0.025 / U:30.016 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site