On Saturday 15 February 2014 14:22:30 Tomasz Figa wrote: > On 15.02.2014 14:09, Arnd Bergmann wrote: > > > For spi-mode SDIO devices I'm assuming it's similar, except that > > you'd describe the actual SDIO device in the board info rather than > > create a fake SDIO controller. Still not discoverable unless I'm > > missing your point. > > I'm not sure if we should assume that SPI = MMC over SPI. I believe > there might be a custom protocol involved as well. In case of SD/MMC, you essentially have three separate command sets: SPI, MMC and SD, and each of them has multiple versions. MMC and SD compatible devices generally also support the SPI command set (IIRC it is required, but I'm not completely sure), and on the bus the main difference seems to be that you have only 1-bit serial signalling, while MMC also supports 4-bit and 8-bit parallel transmission. If a device supports both SDIO and SPI, I think a straightforward implementation would be to use the exact same command set, but you are right that this isn't the only possibility, and the SD/MMC shows how they can be slightly different already. > Stepping aside from SPI, I already gave an example of a WLAN chip that > supports multiple control busses [1]. In addition to the commonly used > SDIO, it supports USB and HSIC as well: > > [1] http://www.marvell.com/wireless/assets/marvell_avastar_88w8797.pdf > > Moreover, some of Samsung boards use HSIC to communicate with modem > chips, which have exactly the same problem as we're trying to solve here > - they need to be powered on to be discovered. Thanks, this definitely makes a good example. I see that it also supports SPI mode for SDIO as mentioned in your link. > So I really don't think we should be limiting this to MMC alone by any > means. Agreed. Putting the same chip on USB or HSIC has the exact same requirements, since we also have a discoverable bus, but actually finding the device likely involves some power-on sequencing before the bus controller can find it. > Now I don't really know why we want that badly to represent low level > control parts of such devices as children of control buses of their > enumerable parts. Could you tell me what benefits it has to justify the > added complexity of having to instantiate fake devices in respective > devices, even though they can be fully detected later? It's not that I "badly want" to do it one way or another, I'm just trying to find arguments either way, since as Russell points out whatever we decide to do in DT is what we're stuck with for the long term future. Let me try to summarize what we found so far: * Common aspects: * we need a way to attach properties for run-time configuration to devices on discoverable buses when the configuration is not discoverable. In your 88w8797 example, this includes the use of the GPIO pins, runtime power management (clocks, regulators) and the attached codecs. * We may want to connect the same device to either a discoverable or a nondiscoverable bus, ideally using the same binding and sharing code whereever possible. * Olof's proposal (add properties or a child node to the host controller node with just power-on sequencing information): + We only need one implementation for each bus, possibly shared across buses to some degree, and can handle lots of devices without having to touch their individual drivers. + A logical extension of things we already do on SD cards (CD/WP GPIOs, external clocks and voltages supplied to standard compliant devices as part of the normal probing) - The shared code may get rather complex to deal with all possible corner cases we run into over the years. - Somewhat harder to do if you have to attach the power information to a device node for a USB hub port, rather than an SDIO controller that only has one slave device. * Arnd's proposal (change bus code to probe nonstandard devices from DT if we can't easily detect them): + Matches what we already do for PCI (at least on powerpc) and AMBA/Primecell devices: If a device can't be probed using the standard method, we treat it as nondiscoverable and describe it using DT. + Devices can have arbitrary complex requirements without impacting the core, since all code is contained in the driver for the nonstandard device. + Properties that are required for probing and runtime configuration only have to be set once (e.g. you may need clk_get() for probing and clk_set_rate() for runtime-pm). + Devices that have alternative bus interfaces like 88w8797 can implement the power-on code in a central place per driver, and can reuse the code they have for nondiscoverable buses on the buses that are normally discoverable but broken here. - Still need to modify each subsystem to have alternate ways of probing, and match up devices later. - Has to be implemented in each driver that needs it, making it harder to share code for drivers with the same need (e.g. every device that just needs an external reset trigger). Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
