On Sat, Feb 15, 2014 at 05:21:11PM +0100, Arnd Bergmann wrote: > 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, SPI support is mandatory for SDIO as well. SDIO has CIS (remember card information structures... like PCMCIA) which identifies the various different logical functions of the device, giving class information, vendor information etc. So... certainly the type of the attached device is discoverable even on SPI. > 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. Given that the SPI mode is mandatory for SDIO cards, why would you also implement another SPI mode with different commands? > > 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. Well, USB is another discoverable bus. As HSIC is a derivative of USB, I'd be surprised if it weren't discoverable there too. So, out of everything identified so far, we have no undiscoverable buses. > 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. That's partly the nature of integrating something onto a board where you want maximal power savings. It's basically that dreaded word which software people seem to hate: "embedded". > * 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). - requires different DT if the chip is changed, which causes problems for users to identify which out of zillions of DT files they should use for their exact platform. - have to work out how to match up the fake device with a probed device when it becomes available: existing SDIO drivers all assume that the card has been through a fairly complex initialisation sequence already. - multi-function SDIO is much harder to deal with since you have mutliple drivers involved, and the SDIO device as a whole needs initialisation before anyone can drive it. - adds complexity to the SDIO drivers; they would have to know whether they're embedded or on a plug-in card. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
