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. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
