* Re: How to support SDIO wifi/bt in DT [not found] ` <3215037.8HVCjAeS8g@wuerfel> @ 2014-01-16 17:15 ` Olof Johansson 2014-01-16 19:58 ` Russell King - ARM Linux ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Olof Johansson @ 2014-01-16 17:15 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org [adding devicetree and mmc lists] On Thu, Jan 16, 2014 at 6:02 AM, Arnd Bergmann <arnd@arndb.de> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 17:15 ` How to support SDIO wifi/bt in DT Olof Johansson @ 2014-01-16 19:58 ` Russell King - ARM Linux 2014-01-16 20:00 ` Olof Johansson 2014-01-16 21:46 ` Arnd Bergmann ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Russell King - ARM Linux @ 2014-01-16 19:58 UTC (permalink / raw) To: Olof Johansson Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote: > 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. As there's no code for any Cubox-i or Hummingboard (they're both purely DT), what this means is that the answer to Wifi/BT support in mainline is that this is "impossible at the moment"... I guess this is becoming a higher priority issue which really needs to be solved somehow. :) -- 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". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 19:58 ` Russell King - ARM Linux @ 2014-01-16 20:00 ` Olof Johansson 2014-01-16 20:03 ` Russell King - ARM Linux 2014-01-17 9:39 ` Alexandre Belloni 0 siblings, 2 replies; 24+ messages in thread From: Olof Johansson @ 2014-01-16 20:00 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote: >> 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. > > As there's no code for any Cubox-i or Hummingboard (they're both purely > DT), what this means is that the answer to Wifi/BT support in mainline is > that this is "impossible at the moment"... > > I guess this is becoming a higher priority issue which really needs to be > solved somehow. :) I'm looking at it right now actually, might as well sort it out while people are paying attention. Patches a little later today unless I get distrac^Winterrupted. :) -Olof ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 20:00 ` Olof Johansson @ 2014-01-16 20:03 ` Russell King - ARM Linux 2014-01-17 9:39 ` Alexandre Belloni 1 sibling, 0 replies; 24+ messages in thread From: Russell King - ARM Linux @ 2014-01-16 20:03 UTC (permalink / raw) To: Olof Johansson Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote: > On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote: > >> 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. > > > > As there's no code for any Cubox-i or Hummingboard (they're both purely > > DT), what this means is that the answer to Wifi/BT support in mainline is > > that this is "impossible at the moment"... > > > > I guess this is becoming a higher priority issue which really needs to be > > solved somehow. :) > > I'm looking at it right now actually, might as well sort it out while > people are paying attention. Patches a little later today unless I get > distrac^Winterrupted. :) I'll look forward to them, but I may not be able to do much more this evening. -- 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". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 20:00 ` Olof Johansson 2014-01-16 20:03 ` Russell King - ARM Linux @ 2014-01-17 9:39 ` Alexandre Belloni 2014-01-17 10:06 ` Chen-Yu Tsai 2014-01-17 10:44 ` Andrew Lunn 1 sibling, 2 replies; 24+ messages in thread From: Alexandre Belloni @ 2014-01-17 9:39 UTC (permalink / raw) To: Olof Johansson Cc: Russell King - ARM Linux, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Arnd Bergmann [-- Attachment #1: Type: text/plain, Size: 1550 bytes --] On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote : > On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote: > >> 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. > > > > As there's no code for any Cubox-i or Hummingboard (they're both purely > > DT), what this means is that the answer to Wifi/BT support in mainline is > > that this is "impossible at the moment"... > > > > I guess this is becoming a higher priority issue which really needs to be > > solved somehow. :) > > I'm looking at it right now actually, might as well sort it out while > people are paying attention. Patches a little later today unless I get > distrac^Winterrupted. :) > Maybe it is not completely related but I think it needs to be thought about while you are it: The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on UART but they share the same clock. So, the next question would be what if I just want to enable one or the other (and take that decision at runtime) ? Where do I put the pinctrl/clocks/regulators in the DT ? I guess it can become an issue to enable both WiFi and BT at the same time if both SDIO and UART are trying to handle the same pinctrl and regulators. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 9:39 ` Alexandre Belloni @ 2014-01-17 10:06 ` Chen-Yu Tsai 2014-01-17 10:14 ` Alexandre Belloni 2014-01-17 10:44 ` Andrew Lunn 1 sibling, 1 reply; 24+ messages in thread From: Chen-Yu Tsai @ 2014-01-17 10:06 UTC (permalink / raw) To: Alexandre Belloni Cc: Olof Johansson, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel@lists.infradead.org On Fri, Jan 17, 2014 at 5:39 PM, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote: > On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote : >> On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote: >> >> 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. >> > >> > As there's no code for any Cubox-i or Hummingboard (they're both purely >> > DT), what this means is that the answer to Wifi/BT support in mainline is >> > that this is "impossible at the moment"... >> > >> > I guess this is becoming a higher priority issue which really needs to be >> > solved somehow. :) >> >> I'm looking at it right now actually, might as well sort it out while >> people are paying attention. Patches a little later today unless I get >> distrac^Winterrupted. :) >> > > Maybe it is not completely related but I think it needs to be thought > about while you are it: > > The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on > UART but they share the same clock. So, the next question would be what > if I just want to enable one or the other (and take that decision at > runtime) ? Some Broadcom chips (BCM4329/4330) and the AP6210 found on CubieTruck are like this as well. In our case, the SD/MMC host driver hasn't been mainlined yet. But BT on UART is independent and usable. > Where do I put the pinctrl/clocks/regulators in the DT ? I guess it can > become an issue to enable both WiFi and BT at the same time if both SDIO > and UART are trying to handle the same pinctrl and regulators. Shouldn't the clocks and regulators be registered in the DT _AS_ clocks and regulators? fixed-regulator already accepts GPIO lines. fixed-rate-clock mentions GPIOs in DT bindings, but doesn't seem to use them in the code. We'd still need a device to tie them to, especially in the UART use case. Or we could try rfkill devices. Not saying it's the correct way, but it is a solution. Cheers, ChenYu ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 10:06 ` Chen-Yu Tsai @ 2014-01-17 10:14 ` Alexandre Belloni 0 siblings, 0 replies; 24+ messages in thread From: Alexandre Belloni @ 2014-01-17 10:14 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Olof Johansson, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel@lists.infradead.org [-- Attachment #1: Type: text/plain, Size: 1777 bytes --] On Fri, Jan 17, 2014 at 06:06:41PM +0800, Chen-Yu Tsai wrote : > On Fri, Jan 17, 2014 at 5:39 PM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: > > Maybe it is not completely related but I think it needs to be thought > > about while you are it: > > > > The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on > > UART but they share the same clock. So, the next question would be what > > if I just want to enable one or the other (and take that decision at > > runtime) ? > > Some Broadcom chips (BCM4329/4330) and the AP6210 found on CubieTruck > are like this as well. In our case, the SD/MMC host driver hasn't been > mainlined yet. But BT on UART is independent and usable. > > > Where do I put the pinctrl/clocks/regulators in the DT ? I guess it can > > become an issue to enable both WiFi and BT at the same time if both SDIO > > and UART are trying to handle the same pinctrl and regulators. > > Shouldn't the clocks and regulators be registered in the DT _AS_ clocks > and regulators? fixed-regulator already accepts GPIO lines. fixed-rate-clock > mentions GPIOs in DT bindings, but doesn't seem to use them in the code. > We'd still need a device to tie them to, especially in the UART use case. > Yeah, I meant if you tie your clock/pinctrl/reset/regulator to both the BT and the WiFI nodes because it is shared, you'll at least get a warning or one of the two won't be working. > Or we could try rfkill devices. Not saying it's the correct way, but it is > a solution. > You'll get the same issue there. Two rfkill devices sharing the same clock or reset for example. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 9:39 ` Alexandre Belloni 2014-01-17 10:06 ` Chen-Yu Tsai @ 2014-01-17 10:44 ` Andrew Lunn 2014-02-05 17:11 ` Mark Brown 1 sibling, 1 reply; 24+ messages in thread From: Andrew Lunn @ 2014-01-17 10:44 UTC (permalink / raw) To: Alexandre Belloni Cc: Olof Johansson, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-arm-kernel@lists.infradead.org > The TI wilink chips (TiWi, wl12xx, wl18xx) have wifi on SDIO and BT on > UART but they share the same clock. So, the next question would be what > if I just want to enable one or the other (and take that decision at > runtime) ? At least for the clock is it not an issue. The generic clock framework does "reference" counting. It will only turn the clock off when all users have said to turn it off. So put a phandle to the clock in all nodes which use it. I've not looked at regulators, but i would hope it also does reference counting of a regulators users. Andrew ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 10:44 ` Andrew Lunn @ 2014-02-05 17:11 ` Mark Brown 0 siblings, 0 replies; 24+ messages in thread From: Mark Brown @ 2014-02-05 17:11 UTC (permalink / raw) To: Andrew Lunn Cc: Alexandre Belloni, devicetree@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-mmc@vger.kernel.org, Olof Johansson, linux-arm-kernel@lists.infradead.org [-- Attachment #1: Type: text/plain, Size: 184 bytes --] On Fri, Jan 17, 2014 at 11:44:23AM +0100, Andrew Lunn wrote: > I've not looked at regulators, but i would hope it also does reference > counting of a regulators users. Yes, it does. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 17:15 ` How to support SDIO wifi/bt in DT Olof Johansson 2014-01-16 19:58 ` Russell King - ARM Linux @ 2014-01-16 21:46 ` Arnd Bergmann 2014-01-16 21:52 ` Olof Johansson 2014-01-16 22:14 ` Marcel Holtmann 2014-01-17 3:08 ` Nicolas Pitre 2014-01-17 9:02 ` Alexandre Belloni 3 siblings, 2 replies; 24+ messages in thread From: Arnd Bergmann @ 2014-01-16 21:46 UTC (permalink / raw) To: linux-arm-kernel Cc: Olof Johansson, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux On Thursday 16 January 2014 09:15:17 Olof Johansson wrote: > > > 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... > There is at least one sdio driver (cw1200) that needs to get a MAC address from DT and has the same kind of hack that you mention to work around it at the moment (actually worse, it's not even using auxdata). The MAC address is certainly a property of the device, not the host. This is of course the same problem that we have on various development boards with USB ethernet controllers lacking an EEPROM. Getting the device to probe in the first place is more important, and this is a much simpler problem though. Arnd ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 21:46 ` Arnd Bergmann @ 2014-01-16 21:52 ` Olof Johansson 2014-01-16 22:14 ` Marcel Holtmann 1 sibling, 0 replies; 24+ messages in thread From: Olof Johansson @ 2014-01-16 21:52 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux On Thu, Jan 16, 2014 at 1:46 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Thursday 16 January 2014 09:15:17 Olof Johansson wrote: >> >> > 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... >> > > There is at least one sdio driver (cw1200) that needs to get > a MAC address from DT and has the same kind of hack that > you mention to work around it at the moment (actually worse, > it's not even using auxdata). The MAC address is certainly > a property of the device, not the host. This is of course > the same problem that we have on various development boards > with USB ethernet controllers lacking an EEPROM. Yeah, definitely overlap with the on-board usb ethernet adapters where the vendor hasn't bothered with an eeprom. > Getting the device to probe in the first place is more important, > and this is a much simpler problem though. Yes, agreed -- both needs solving but they're separate issues. -Olof ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 21:46 ` Arnd Bergmann 2014-01-16 21:52 ` Olof Johansson @ 2014-01-16 22:14 ` Marcel Holtmann 1 sibling, 0 replies; 24+ messages in thread From: Marcel Holtmann @ 2014-01-16 22:14 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, Olof Johansson, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux Hi Arnd, >>> 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... >> > > There is at least one sdio driver (cw1200) that needs to get > a MAC address from DT and has the same kind of hack that > you mention to work around it at the moment (actually worse, > it's not even using auxdata). The MAC address is certainly > a property of the device, not the host. This is of course > the same problem that we have on various development boards > with USB ethernet controllers lacking an EEPROM. there are plenty of these devices. It is not just Ethernet or WiFi. You can add Bluetooth devices addresses to this as well. The Nokia N900 drivers for example. Even the Nexus 4 devices are in this boat as well. The addresses are either stored in some magic place or plain simple on the host filesystem. Maybe this whole magic persistent IEEE addresses thing need its own subsystem. So drivers needing an address can just request it from the subsystem and the subsystem deals with the nasty storage details on how to get the addresses into the kernel in the first place. Currently it is a big mess. I have seen nasty workaround with delayed initialization from probe or other crazy sysfs settings to just make this work. Regards Marcel ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 17:15 ` How to support SDIO wifi/bt in DT Olof Johansson 2014-01-16 19:58 ` Russell King - ARM Linux 2014-01-16 21:46 ` Arnd Bergmann @ 2014-01-17 3:08 ` Nicolas Pitre 2014-01-17 14:47 ` Arnd Bergmann [not found] ` <alpine.LFD.2.10.1401162204560.28907-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org> 2014-01-17 9:02 ` Alexandre Belloni 3 siblings, 2 replies; 24+ messages in thread From: Nicolas Pitre @ 2014-01-17 3:08 UTC (permalink / raw) To: Olof Johansson Cc: devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org, Arnd Bergmann On Thu, 16 Jan 2014, Olof Johansson wrote: > "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. The Marvell 8688, just to name one, does both WIFI and BlueTooth over the same SDIO controller using separate functions/slots. Or maybe I'm misunderstanding you? Nicolas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 3:08 ` Nicolas Pitre @ 2014-01-17 14:47 ` Arnd Bergmann [not found] ` <alpine.LFD.2.10.1401162204560.28907-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org> 1 sibling, 0 replies; 24+ messages in thread From: Arnd Bergmann @ 2014-01-17 14:47 UTC (permalink / raw) To: Nicolas Pitre Cc: Olof Johansson, linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org On Friday 17 January 2014, Nicolas Pitre wrote: > On Thu, 16 Jan 2014, Olof Johansson wrote: > > > "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. > > The Marvell 8688, just to name one, does both WIFI and BlueTooth over > the same SDIO controller using separate functions/slots. > > Or maybe I'm misunderstanding you? > I wasn't aware of this but I just checked (in mmc_attach_sdio) that there can be multiple functions on a slot. I assume the sd8688 has a single slot with two functions, so that potentially extends the problem space if we need to supply clocks and regulators per function rather than just per slot. Arnd ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <alpine.LFD.2.10.1401162204560.28907-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>]
* Re: How to support SDIO wifi/bt in DT [not found] ` <alpine.LFD.2.10.1401162204560.28907-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org> @ 2014-01-17 15:14 ` Rob Herring 2014-01-17 16:58 ` Nicolas Pitre 0 siblings, 1 reply; 24+ messages in thread From: Rob Herring @ 2014-01-17 15:14 UTC (permalink / raw) To: Nicolas Pitre Cc: Olof Johansson, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King - ARM Linux, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Arnd Bergmann On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org> wrote: > On Thu, 16 Jan 2014, Olof Johansson wrote: > >> "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. > > The Marvell 8688, just to name one, does both WIFI and BlueTooth over > the same SDIO controller using separate functions/slots. But that is logical functions within a chip, not multiple discrete chips (i.e. slots) with their own reset, regulators, etc. There would still be a single set of external controls per host controller I think. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 15:14 ` Rob Herring @ 2014-01-17 16:58 ` Nicolas Pitre 2014-01-19 19:29 ` Olof Johansson 0 siblings, 1 reply; 24+ messages in thread From: Nicolas Pitre @ 2014-01-17 16:58 UTC (permalink / raw) To: Rob Herring Cc: Olof Johansson, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org, Arnd Bergmann On Fri, 17 Jan 2014, Rob Herring wrote: > On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote: > > On Thu, 16 Jan 2014, Olof Johansson wrote: > > > >> "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. > > > > The Marvell 8688, just to name one, does both WIFI and BlueTooth over > > the same SDIO controller using separate functions/slots. > > But that is logical functions within a chip, not multiple discrete > chips (i.e. slots) with their own reset, regulators, etc. OK. If that's the definition of a slot in this context then I agree. Nicolas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 16:58 ` Nicolas Pitre @ 2014-01-19 19:29 ` Olof Johansson 2014-01-19 20:28 ` Arnd Bergmann 2014-01-19 23:09 ` Alexandre Belloni 0 siblings, 2 replies; 24+ messages in thread From: Olof Johansson @ 2014-01-19 19:29 UTC (permalink / raw) To: Nicolas Pitre Cc: Rob Herring, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org, Arnd Bergmann On Fri, Jan 17, 2014 at 8:58 AM, Nicolas Pitre <nico@fluxnic.net> wrote: > On Fri, 17 Jan 2014, Rob Herring wrote: > >> On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote: >> > On Thu, 16 Jan 2014, Olof Johansson wrote: >> > >> >> "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. >> > >> > The Marvell 8688, just to name one, does both WIFI and BlueTooth over >> > the same SDIO controller using separate functions/slots. >> >> But that is logical functions within a chip, not multiple discrete >> chips (i.e. slots) with their own reset, regulators, etc. > > OK. If that's the definition of a slot in this context then I agree. Correct -- the device that I've been doing the work in is actually the combined wifi/bluetooth module on the Samsung Chromebook, which is a Marvell 8797. It has multiple functions which still work well. The "multi-slot" concept I was talking about was one host controller for several physical slots. Seems like at91 implements _and_ uses this but nobody else. However, it seems that they allocate one mmc host per slot, so the same model still works. -Olof ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-19 19:29 ` Olof Johansson @ 2014-01-19 20:28 ` Arnd Bergmann 2014-01-19 23:26 ` Olof Johansson 2014-01-19 23:09 ` Alexandre Belloni 1 sibling, 1 reply; 24+ messages in thread From: Arnd Bergmann @ 2014-01-19 20:28 UTC (permalink / raw) To: Olof Johansson Cc: Nicolas Pitre, Rob Herring, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org On Sunday 19 January 2014, Olof Johansson wrote: > The "multi-slot" concept I was talking about was one host controller > for several physical slots. Seems like at91 implements and uses this > but nobody else. However, it seems that they allocate one mmc host per > slot, so the same model still works. > IIRC dw-mci also has multiple slots, and it's a common host controller in a number of SoCs. I don't know how many of them actually support multiple slots rather than a simplified single-slot version of that controller. Arnd ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-19 20:28 ` Arnd Bergmann @ 2014-01-19 23:26 ` Olof Johansson 0 siblings, 0 replies; 24+ messages in thread From: Olof Johansson @ 2014-01-19 23:26 UTC (permalink / raw) To: Arnd Bergmann Cc: Nicolas Pitre, Rob Herring, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org On Sun, Jan 19, 2014 at 09:28:53PM +0100, Arnd Bergmann wrote: > On Sunday 19 January 2014, Olof Johansson wrote: > > The "multi-slot" concept I was talking about was one host controller > > for several physical slots. Seems like at91 implements and uses this > > but nobody else. However, it seems that they allocate one mmc host per > > slot, so the same model still works. > > > > IIRC dw-mci also has multiple slots, and it's a common host controller > in a number of SoCs. I don't know how many of them actually support > multiple slots rather than a simplified single-slot version of > that controller. Right, that's the main one i had in mind -- the binding, and the driver, allow for multiple slots but we've been searching high and low for an actual SoC that implements that, and none seem to do it. So the additional overhead is just wasted, and there's been talk of bringing the binding more in line with a single-slot driver instead. It makes a lot of sense to do. -Olof ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-19 19:29 ` Olof Johansson 2014-01-19 20:28 ` Arnd Bergmann @ 2014-01-19 23:09 ` Alexandre Belloni 2014-01-19 23:30 ` Olof Johansson 1 sibling, 1 reply; 24+ messages in thread From: Alexandre Belloni @ 2014-01-19 23:09 UTC (permalink / raw) To: Olof Johansson Cc: Nicolas Pitre, devicetree@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote : > The "multi-slot" concept I was talking about was one host controller > for several physical slots. Seems like at91 implements _and_ uses this > but nobody else. However, it seems that they allocate one mmc host per > slot, so the same model still works. > I think we need to be extra careful about the DT bindings then because adding a property in a slot is requiring handling that in the at91 driver whereas adding a common property for the various mmc hosts can be done in the core code. >From what I remember, it would be really good to put the DT parsing for the slots in the core code but I only had a really quick look at that. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-19 23:09 ` Alexandre Belloni @ 2014-01-19 23:30 ` Olof Johansson 2014-01-20 3:57 ` Olof Johansson 0 siblings, 1 reply; 24+ messages in thread From: Olof Johansson @ 2014-01-19 23:30 UTC (permalink / raw) To: Alexandre Belloni Cc: Nicolas Pitre, devicetree@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote: > On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote : > > The "multi-slot" concept I was talking about was one host controller > > for several physical slots. Seems like at91 implements _and_ uses this > > but nobody else. However, it seems that they allocate one mmc host per > > slot, so the same model still works. > > > > I think we need to be extra careful about the DT bindings then because > adding a property in a slot is requiring handling that in the at91 > driver whereas adding a common property for the various mmc hosts can be > done in the core code. > > From what I remember, it would be really good to put the DT parsing for > the slots in the core code but I only had a really quick look at that. The patches I have here do it all in the core per host with common bindings. I hope to post them tonight. They should fit the at91 model just fine as well, since they do each slot as a mmc_host, not as a separate slot with a shared host controller. (Some drivers don't seem to call mmc_of_parse(), which they will need to do to take advantage of the common implementation. But that can be addressed driver by driver as someone has a chance to test it). -Olof ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-19 23:30 ` Olof Johansson @ 2014-01-20 3:57 ` Olof Johansson 0 siblings, 0 replies; 24+ messages in thread From: Olof Johansson @ 2014-01-20 3:57 UTC (permalink / raw) To: Alexandre Belloni Cc: Nicolas Pitre, devicetree@vger.kernel.org, Russell King - ARM Linux, Arnd Bergmann, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Sun, Jan 19, 2014 at 3:30 PM, Olof Johansson <olof@lixom.net> wrote: > On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote: >> On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote : >> > The "multi-slot" concept I was talking about was one host controller >> > for several physical slots. Seems like at91 implements _and_ uses this >> > but nobody else. However, it seems that they allocate one mmc host per >> > slot, so the same model still works. >> > >> >> I think we need to be extra careful about the DT bindings then because >> adding a property in a slot is requiring handling that in the at91 >> driver whereas adding a common property for the various mmc hosts can be >> done in the core code. >> >> From what I remember, it would be really good to put the DT parsing for >> the slots in the core code but I only had a really quick look at that. > > The patches I have here do it all in the core per host with common > bindings. I hope to post them tonight. Done. See RFC series at: http://marc.info/?l=linux-mmc&m=139019015915702&w=2 -Olof ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-16 17:15 ` How to support SDIO wifi/bt in DT Olof Johansson ` (2 preceding siblings ...) 2014-01-17 3:08 ` Nicolas Pitre @ 2014-01-17 9:02 ` Alexandre Belloni 2014-01-17 9:38 ` Nicolas Ferre 3 siblings, 1 reply; 24+ messages in thread From: Alexandre Belloni @ 2014-01-17 9:02 UTC (permalink / raw) To: Olof Johansson Cc: Arnd Bergmann, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org, Ludovic Desroches, Nicolas Ferre [-- Attachment #1: Type: text/plain, Size: 725 bytes --] On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote : > "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. > Actually, the atmel chips have two slots per controller so it would probably be better to think about that now. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to support SDIO wifi/bt in DT 2014-01-17 9:02 ` Alexandre Belloni @ 2014-01-17 9:38 ` Nicolas Ferre 0 siblings, 0 replies; 24+ messages in thread From: Nicolas Ferre @ 2014-01-17 9:38 UTC (permalink / raw) To: Alexandre Belloni, Olof Johansson Cc: Arnd Bergmann, devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King - ARM Linux, linux-arm-kernel@lists.infradead.org, Ludovic Desroches On 17/01/2014 10:02, Alexandre Belloni : > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote : >> "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. >> > > Actually, the atmel chips have two slots per controller so it would > probably be better to think about that now. Moreover, we have DT description for this. Cf. Documentation/devicetree/bindings/mmc/atmel-hsmci.txt Best regards, -- Nicolas Ferre ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-02-05 17:11 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20140116133649.GV15937@n2100.arm.linux.org.uk>
[not found] ` <3215037.8HVCjAeS8g@wuerfel>
2014-01-16 17:15 ` How to support SDIO wifi/bt in DT Olof Johansson
2014-01-16 19:58 ` Russell King - ARM Linux
2014-01-16 20:00 ` Olof Johansson
2014-01-16 20:03 ` Russell King - ARM Linux
2014-01-17 9:39 ` Alexandre Belloni
2014-01-17 10:06 ` Chen-Yu Tsai
2014-01-17 10:14 ` Alexandre Belloni
2014-01-17 10:44 ` Andrew Lunn
2014-02-05 17:11 ` Mark Brown
2014-01-16 21:46 ` Arnd Bergmann
2014-01-16 21:52 ` Olof Johansson
2014-01-16 22:14 ` Marcel Holtmann
2014-01-17 3:08 ` Nicolas Pitre
2014-01-17 14:47 ` Arnd Bergmann
[not found] ` <alpine.LFD.2.10.1401162204560.28907-fMhRO7WWcppj+hNMo8g0rg@public.gmane.org>
2014-01-17 15:14 ` Rob Herring
2014-01-17 16:58 ` Nicolas Pitre
2014-01-19 19:29 ` Olof Johansson
2014-01-19 20:28 ` Arnd Bergmann
2014-01-19 23:26 ` Olof Johansson
2014-01-19 23:09 ` Alexandre Belloni
2014-01-19 23:30 ` Olof Johansson
2014-01-20 3:57 ` Olof Johansson
2014-01-17 9:02 ` Alexandre Belloni
2014-01-17 9:38 ` Nicolas Ferre
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).