[lkml]   [2011]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.
    On Wednesday 17 August 2011, Mark Brown wrote:
    > On Wed, 2011-08-17 at 12:42 +0200, Arnd Bergmann wrote:
    > > > I'd expect that bringing the device out of reset is going to be largely
    > > > unrelated to the host controller, it's going to be GPIOs, clocks and
    > > > regulators. The individual drivers are going to want to manage this
    > > > stuff dynamically at runtime too.
    > > But it's even less related to the individual driver than to the host.
    > No, not at all - all the bus specifies is the two wire control
    > interface, if a device on the bus requires power or anything else that's
    > not something the CPU Slimbus (I keep wanting to typo that as
    > Slumbus...) controller has any idea about. In this respect Slimbus is
    > much more like I2C than USB where there's a standard provision for power
    > even if embedded systems routinely ignore it.
    > The device driver will know what power supplies and other signals the
    > device has, and it will know how and when to use them. This can
    > generally be done independently of the board with just some platform or
    > device tree data to configure GPIOs.

    Ok, I think you've managed to get through to me ;-)

    > > The way I see this working is that something outside of the driver
    > > should provide a way to enable each device in order for it to get
    > > probed, and the driver's ->probe callback does a pm_runtime_get()
    > > call when it wants to keep the device enabled.
    > Some pre-cooked off the shelf device wide power management is definitely
    > useful for simple cases but I don't think that scales to high end
    > devices - it's too binary. Like I said I really do want to have some
    > transparent device model way of handling the simple cases but we need to
    > leave room for devices which want to do more complicated things.
    > It also occurs to me that if we're supporting going down to cold with
    > runtime PM anyway the kernel is going to have to be able to understand
    > the idea that devices it already knows about are going to hotplug in and
    > out while staying registered. If we're doing that then it seems like the
    > bus is going to have pretty much all the concepts required for explicit
    > registration anyway.

    How about a mixed model then?

    I can see three relevant cases to consider:

    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.

    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.


     \ /
      Last update: 2011-08-17 16:03    [W:0.062 / U:8.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site