[adding devicetree and mmc lists] On Thu, Jan 16, 2014 at 6:02 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thursday 16 January 2014 13:36:49 Russell King - ARM Linux wrote: > >> >> The Wifi/BT chip can only be detected via probing the SDIO connection, and >> only when the device has been powered up and released from reset - so we >> have to power up and reset the bcrm device before we probe via the SDIO >> bus. > > This is indeed a common problem, and while we've talked about solving > it in the past, nothing has happened code-wise. It indeed needs an > implementation in the sdio framework. Yeah, this is what's keeping wifi from working on the ARM Chromebook upstream as well, and it's been on my list to deal with for a long time. So now is as good a time as any. Generic SDIO framework solution/binding would be great, since these constructs are quite common on systems these days (even x86 is starting to get peripherals on SDIO). >> While it's possible to attach the power supply for the Wifi/BT chip to the >> vmmc-supply property of the host, it's not possible to do that with the >> oscillator supply. Neither is there any provision for manipulating the >> GPIOs to deal with the resets. >> >> I can't find any examples of anything similar in our existing set of DT >> files, so I suspect either this is a device which no one supports on any >> DT platform, or there's some clever way to handle this. > > The former. We've dealt with it with local code in our tree for Chrome OS, and I suspect everyone else has too. It's definitely time to solve generically. >> How do other people support this in DT? Do they hack up some platform >> specific code (which isn't nice)? What other solutions are there to get >> around this problem? How does this kind of thing get represented in DT? >> >> (Don't suggest adding DT support to the bcrmfmac driver - this is a >> chicken-and-egg problem. The driver isn't being probed at the moment >> because the device is powered down and/or held in reset, so is >> undetectable. The kernel needs to power it up and release the reset >> so it becomes detectable.) > > The problem is two-fold: > > a) we need to add a generic mechanism to the SDIO probe code to > allow specifying clocks, regulators and resets (possibly more) > for an SDIO endpoint that get enabled before the probe starts. > This parts needs a DT binding for SDIO slots as well as code. "for SDIO slots" is somewhat misleading; nearly all controllers only do one slot/device per controller. The designware controller can do multiple slots, and that adds a bit of driver and binding complexity for something that seemingly not a single vendor has actually implemented. So we can likely assume to keep these reset/power/clock lines per host controller, no need to add a slot construct. > b) We need to add a way to attach a device_node to an sdio_func, > so that a function driver can find additional DT properties. > This part should be relatively simple once (a) is done and > should only need a little code but no new binding. The code > would be similar to what we do for amba, i2c or spi devices. This isn't actually needed for this functionality, but might be needed for other things... > Note that the same problem exists for a number of other discoverable > buses that get used in nondiscoverable ways, e.g. USB, PCI, > or even SCSI. It's normally a spec violation if those devices > are wired up like this, but of course we still want to support > the hardware. ... such as these. :) -Olof -- 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
