Re: ath10k: calibration data through Device Tree?
Hi Kumar, Kumar Gala writes: > As Arnd mentioned you would have something like: > > pci { > pcie@0 { > reg = <0 0 0 0 0>; > #interrupt-cells = <1>; > #size-cells = <2>; > #address-cells = <3>; > device_type = "pci"; > > ath10k@0,0 { > reg = <0x 0x0 0x0 0x0 0x0>; > device_type = "pci"; > qcom,ath10k-calibration-data = [ 01 03 04 05 06 … ]; > }; > }; > }; > > On the driver side you can do something like: > > struct device_node *np; > > np = pci_device_to_OF_node(dev); > > than you can do normal OF calls on ‘np’. Ah, now I understand how this is supposed to work. Thank you very much for providing an example. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Oct 7, 2014, at 6:44 PM, Kalle Valo wrote: > Andy Lutomirski writes: > >> Perhaps unsurprisingly, the OpenWRT patch that enables it to work for >> real (by shoving a file into /lib/firmware that's contains a copy of >> data read from flash) hasn't made it upstream. I assume that the >> purpose of this discussion is to settle on a real solution. > > I'm hoping to have ath10k support three different methods to get > calibration data: > > 1) OTP (already supported) > > 2) Device Tree (under discussion) > > 3) from a file > > I'm hoping to send patches for 2) and 3) soon. As Arnd mentioned you would have something like: pci { pcie@0 { reg = <0 0 0 0 0>; #interrupt-cells = <1>; #size-cells = <2>; #address-cells = <3>; device_type = "pci"; ath10k@0,0 { reg = <0x 0x0 0x0 0x0 0x0>; device_type = "pci"; qcom,ath10k-calibration-data = [ 01 03 04 05 06 … ]; }; }; }; On the driver side you can do something like: struct device_node *np; np = pci_device_to_OF_node(dev); than you can do normal OF calls on ‘np’. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
Andy Lutomirski writes: > Perhaps unsurprisingly, the OpenWRT patch that enables it to work for > real (by shoving a file into /lib/firmware that's contains a copy of > data read from flash) hasn't made it upstream. I assume that the > purpose of this discussion is to settle on a real solution. I'm hoping to have ath10k support three different methods to get calibration data: 1) OTP (already supported) 2) Device Tree (under discussion) 3) from a file I'm hoping to send patches for 2) and 3) soon. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
As far as I'm aware there's no unique identifier in the silicon. It's all in the OTP or flash. The NIC comes up with a standard MAC address, the same for all NICs in the family. -a ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Fri, Oct 3, 2014 at 9:42 AM, Arnd Bergmann wrote: > On Friday 03 October 2014 17:25:13 Mark Rutland wrote: >> > From a system design point, it's still horrible that you have to use >> > DT for a device that is on a discoverable bus like PCI, but as you >> > describe, >> > the reality is that products are shipping that use ath10k PCI devices >> > without this data in them. >> >> I'd see any DT property for this as a workaround, the use of which >> should be discouraged. > > By extension though, any use of DT is really a workaround for the fact > that embedded systems and SoCs don't use discoverable buses, and it should > be discouraged. x86 SoCs actually get this right to a large degree by > making on-chip devices appear as PCI devices that can be used standalone, > although Intel's latest generation SoCs are regressing in this regard > and you still need DT (or something like it) to describe off-chip devices > there. > >> A fun question that springs to mind is can the ath10k chip be removed, >> and if so am I able to place it into a non-DT system (whereupon I have >> no calibration data, so it won't work)? > > Some can be removed, others cannot. If the chip is on a removable pcie > mini card and doesn't have that data on the card itself, it's already > impossible to put it into another system. I don't think we need to solve > that case. Do these minipcie devices have any sort of unique identifier? If so, one could shove the calibration data in /lib/firmware/ath10k/caldata_[CARDID].dat and, as long as that file followed the minipcie card around, it would work just fine. --Andy ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Friday 03 October 2014 17:25:13 Mark Rutland wrote: > > From a system design point, it's still horrible that you have to use > > DT for a device that is on a discoverable bus like PCI, but as you describe, > > the reality is that products are shipping that use ath10k PCI devices > > without this data in them. > > I'd see any DT property for this as a workaround, the use of which > should be discouraged. By extension though, any use of DT is really a workaround for the fact that embedded systems and SoCs don't use discoverable buses, and it should be discouraged. x86 SoCs actually get this right to a large degree by making on-chip devices appear as PCI devices that can be used standalone, although Intel's latest generation SoCs are regressing in this regard and you still need DT (or something like it) to describe off-chip devices there. > A fun question that springs to mind is can the ath10k chip be removed, > and if so am I able to place it into a non-DT system (whereupon I have > no calibration data, so it won't work)? Some can be removed, others cannot. If the chip is on a removable pcie mini card and doesn't have that data on the card itself, it's already impossible to put it into another system. I don't think we need to solve that case. We have similar issues with removable but nondiscoverable USB and SDIO devices, e.g. when they are lacking the PROM for the mac address. Arnd ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Fri, Oct 3, 2014 at 8:29 AM, Arnd Bergmann wrote: > On Thursday 02 October 2014 12:05:27 Andy Lutomirski wrote: >> On 10/02/2014 06:44 AM, Kalle Valo wrote: >> > Hi Mark, >> > >> > Mark Rutland writes: >> > >> >>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and >> >>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports >> >>> PCI devices. >> >>> >> >>> Some of the devices store the calibration data to the host flash and the >> >>> bootloader reads the data from the flash. And now we need a method to >> >>> deliver the calibration data from bootloader to ath10k. >> >> >> >> What does this calibration data consist of? >> > >> > From ath10k point of view it's just a binary blob which we push to the >> > firmware before we start it. ath10k does not parse it in any way. >> > >> >> What happens if you don't have the calibration data? Is it a critical >> >> requirement for the use of the device, or does its absence simply result >> >> in degraded performance? >> > >> > From my point of view the device should not be used if it doesn't >> > contain the correct calibration data. I guess it could work somehow but >> > there's no guarantee about the perfomance. >> > >> >> What do you do on non-DT systems? Where does the information come from >> >> in that case? >> > >> > Currently ath10k only supports having the calibration data in the OTP >> > area inside the QCA98XX chip. But some manufacturers want to store it on >> > the host file, I assume because of the flexibility it provides. And >> > that's why we have the need for Device Tree support. >> >> To give an actual concrete example that might be what Kalle is talking >> about: >> >> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie >> device. For whatever reason (I honestly have no clue whatsoever why the >> hardware works this way), the calibration data is on a host flash >> partition, not on the minipcie device's ROM or flash or whatever it is. > > Just to clarify: is this data specific to the design of the device and > identical for all parts in a manufacture run, or does each individual > board have to be calibrated separately? Each board has separate data. (Even the MAC address is in this blob on my device.) --Andy ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
> From a system design point, it's still horrible that you have to use > DT for a device that is on a discoverable bus like PCI, but as you describe, > the reality is that products are shipping that use ath10k PCI devices > without this data in them. I'd see any DT property for this as a workaround, the use of which should be discouraged. A fun question that springs to mind is can the ath10k chip be removed, and if so am I able to place it into a non-DT system (whereupon I have no calibration data, so it won't work)? Mark. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Thursday 02 October 2014 12:05:27 Andy Lutomirski wrote: > On 10/02/2014 06:44 AM, Kalle Valo wrote: > > Hi Mark, > > > > Mark Rutland writes: > > > >>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and > >>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports > >>> PCI devices. > >>> > >>> Some of the devices store the calibration data to the host flash and the > >>> bootloader reads the data from the flash. And now we need a method to > >>> deliver the calibration data from bootloader to ath10k. > >> > >> What does this calibration data consist of? > > > > From ath10k point of view it's just a binary blob which we push to the > > firmware before we start it. ath10k does not parse it in any way. > > > >> What happens if you don't have the calibration data? Is it a critical > >> requirement for the use of the device, or does its absence simply result > >> in degraded performance? > > > > From my point of view the device should not be used if it doesn't > > contain the correct calibration data. I guess it could work somehow but > > there's no guarantee about the perfomance. > > > >> What do you do on non-DT systems? Where does the information come from > >> in that case? > > > > Currently ath10k only supports having the calibration data in the OTP > > area inside the QCA98XX chip. But some manufacturers want to store it on > > the host file, I assume because of the flexibility it provides. And > > that's why we have the need for Device Tree support. > > To give an actual concrete example that might be what Kalle is talking > about: > > I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie > device. For whatever reason (I honestly have no clue whatsoever why the > hardware works this way), the calibration data is on a host flash > partition, not on the minipcie device's ROM or flash or whatever it is. Just to clarify: is this data specific to the design of the device and identical for all parts in a manufacture run, or does each individual board have to be calibrated separately? > Needless to say, the mainline ath10k driver won't load on it. (An old > version used to load without calibration data. It didn't work very well.) > > Presuambly the idea is that, if things like this used DT (which mine > doesn't, I presume), then ath10k could get the calibration data via DT. > And maybe some vendors of ARM-based wifi devices are planning on > playing similar games, and they do use DT. Yes, this makes sense. I would also very much love to see DT support for arch/mips/ath79 in general, it seems like a nice platform that is used in a lot of devices with good openwrt support, and using DT would make it easier to support additional devices. >From a system design point, it's still horrible that you have to use DT for a device that is on a discoverable bus like PCI, but as you describe, the reality is that products are shipping that use ath10k PCI devices without this data in them. Arnd ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Thu, Oct 2, 2014 at 12:28 PM, Adrian Chadd wrote: > On 2 October 2014 12:05, Andy Lutomirski wrote: >> On 10/02/2014 06:44 AM, Kalle Valo wrote: >>> Hi Mark, >>> >>> Mark Rutland writes: >>> > ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and > located in drivers/net/wireless/ath/ath10k/. Currently it only supports > PCI devices. > > Some of the devices store the calibration data to the host flash and the > bootloader reads the data from the flash. And now we need a method to > deliver the calibration data from bootloader to ath10k. What does this calibration data consist of? >>> >>> From ath10k point of view it's just a binary blob which we push to the >>> firmware before we start it. ath10k does not parse it in any way. >>> What happens if you don't have the calibration data? Is it a critical requirement for the use of the device, or does its absence simply result in degraded performance? >>> >>> From my point of view the device should not be used if it doesn't >>> contain the correct calibration data. I guess it could work somehow but >>> there's no guarantee about the perfomance. >>> What do you do on non-DT systems? Where does the information come from in that case? >>> >>> Currently ath10k only supports having the calibration data in the OTP >>> area inside the QCA98XX chip. But some manufacturers want to store it on >>> the host file, I assume because of the flexibility it provides. And >>> that's why we have the need for Device Tree support. >> >> To give an actual concrete example that might be what Kalle is talking >> about: >> >> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie >> device. For whatever reason (I honestly have no clue whatsoever why the >> hardware works this way), the calibration data is on a host flash >> partition, not on the minipcie device's ROM or flash or whatever it is. > > The hardware works this way because it's what's being chosen at > manufacturing time. > > It _used_ to be this way because then the manufacturers could choose > whether to put the serial EEPROM on the wireless card or on board - or > just save that particular component and load in the same data from the > existing SPI flash chip that holds the firmware. > > With OTP they'd have to include writing OTP data out to the chip as > part of the manufacturing process, rather than just "load in data via > JTAG or uboot". I always assumed that vendors like TP-Link bought pre-calibrated minipcie cards from someone else. I guess I was wrong :) > > It also means they can re-do the calibration or configuration space > for the device rather than the "One Time Programmable" bits which (a) > will eventually run out of space for programming, (b) occasionally may > error during programming, or (c) may end up writing the wrong data > during programming time, making a chip or a whole batch of chips > useless. > >> Needless to say, the mainline ath10k driver won't load on it. (An old >> version used to load without calibration data. It didn't work very well.) > > I'm surprised it worked at all. :) My gf's Macbook didn't think it worked. My supremely crappy old Intel card thought it did, at least as well as it thought that anything worked. Go figure. Perhaps unsurprisingly, the OpenWRT patch that enables it to work for real (by shoving a file into /lib/firmware that's contains a copy of data read from flash) hasn't made it upstream. I assume that the purpose of this discussion is to settle on a real solution. --Andy ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On 2 October 2014 12:05, Andy Lutomirski wrote: > On 10/02/2014 06:44 AM, Kalle Valo wrote: >> Hi Mark, >> >> Mark Rutland writes: >> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and located in drivers/net/wireless/ath/ath10k/. Currently it only supports PCI devices. Some of the devices store the calibration data to the host flash and the bootloader reads the data from the flash. And now we need a method to deliver the calibration data from bootloader to ath10k. >>> >>> What does this calibration data consist of? >> >> From ath10k point of view it's just a binary blob which we push to the >> firmware before we start it. ath10k does not parse it in any way. >> >>> What happens if you don't have the calibration data? Is it a critical >>> requirement for the use of the device, or does its absence simply result >>> in degraded performance? >> >> From my point of view the device should not be used if it doesn't >> contain the correct calibration data. I guess it could work somehow but >> there's no guarantee about the perfomance. >> >>> What do you do on non-DT systems? Where does the information come from >>> in that case? >> >> Currently ath10k only supports having the calibration data in the OTP >> area inside the QCA98XX chip. But some manufacturers want to store it on >> the host file, I assume because of the flexibility it provides. And >> that's why we have the need for Device Tree support. > > To give an actual concrete example that might be what Kalle is talking > about: > > I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie > device. For whatever reason (I honestly have no clue whatsoever why the > hardware works this way), the calibration data is on a host flash > partition, not on the minipcie device's ROM or flash or whatever it is. The hardware works this way because it's what's being chosen at manufacturing time. It _used_ to be this way because then the manufacturers could choose whether to put the serial EEPROM on the wireless card or on board - or just save that particular component and load in the same data from the existing SPI flash chip that holds the firmware. With OTP they'd have to include writing OTP data out to the chip as part of the manufacturing process, rather than just "load in data via JTAG or uboot". It also means they can re-do the calibration or configuration space for the device rather than the "One Time Programmable" bits which (a) will eventually run out of space for programming, (b) occasionally may error during programming, or (c) may end up writing the wrong data during programming time, making a chip or a whole batch of chips useless. > Needless to say, the mainline ath10k driver won't load on it. (An old > version used to load without calibration data. It didn't work very well.) I'm surprised it worked at all. :) -a ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On 10/02/2014 06:44 AM, Kalle Valo wrote: > Hi Mark, > > Mark Rutland writes: > >>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and >>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports >>> PCI devices. >>> >>> Some of the devices store the calibration data to the host flash and the >>> bootloader reads the data from the flash. And now we need a method to >>> deliver the calibration data from bootloader to ath10k. >> >> What does this calibration data consist of? > > From ath10k point of view it's just a binary blob which we push to the > firmware before we start it. ath10k does not parse it in any way. > >> What happens if you don't have the calibration data? Is it a critical >> requirement for the use of the device, or does its absence simply result >> in degraded performance? > > From my point of view the device should not be used if it doesn't > contain the correct calibration data. I guess it could work somehow but > there's no guarantee about the perfomance. > >> What do you do on non-DT systems? Where does the information come from >> in that case? > > Currently ath10k only supports having the calibration data in the OTP > area inside the QCA98XX chip. But some manufacturers want to store it on > the host file, I assume because of the flexibility it provides. And > that's why we have the need for Device Tree support. To give an actual concrete example that might be what Kalle is talking about: I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie device. For whatever reason (I honestly have no clue whatsoever why the hardware works this way), the calibration data is on a host flash partition, not on the minipcie device's ROM or flash or whatever it is. Needless to say, the mainline ath10k driver won't load on it. (An old version used to load without calibration data. It didn't work very well.) Presuambly the idea is that, if things like this used DT (which mine doesn't, I presume), then ath10k could get the calibration data via DT. And maybe some vendors of ARM-based wifi devices are planning on playing similar games, and they do use DT. --Andy ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Thursday 02 October 2014 17:55:57 Kalle Valo wrote: > > > I notice that there are no Qualcomm or Atheros PCI host controller drivers > > in Linux though, so you first have to write a driver that allows probing > > the PCI bus, and get the binding reviewed for that before you can add > > it to the dts files. Is this for ipq8064 or something else? > > But now I'm lost again I want ath10k and this feature to work with > all possible PCI controllers, not just with Qualcomm controllers. So why > do I need to wait for Qualcomm PCI host controller driver? Sorry, my fault. You can definitely do this with any SoC that uses DT for probing the PCI. I was merely assuming that you were asking about ipq because the wifi chips and SoCs tend to come bundled from the same manufacturer in embedded systems, and the MIPS based QCA SoCs currently don't use DT. For any machine that does not use DT, it would be much harder to solve this problem though. Arnd ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Thu, Oct 02, 2014 at 02:44:26PM +0100, Kalle Valo wrote: > Hi Mark, > > Mark Rutland writes: > > >> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and > >> located in drivers/net/wireless/ath/ath10k/. Currently it only supports > >> PCI devices. > >> > >> Some of the devices store the calibration data to the host flash and the > >> bootloader reads the data from the flash. And now we need a method to > >> deliver the calibration data from bootloader to ath10k. > > > > What does this calibration data consist of? > > From ath10k point of view it's just a binary blob which we push to the > firmware before we start it. ath10k does not parse it in any way. Ok. So this is an arbitrary binary blob that the firmware needs. Who is in charge of loading the firmware onto the device? Where does the firmware come from? > > What happens if you don't have the calibration data? Is it a critical > > requirement for the use of the device, or does its absence simply result > > in degraded performance? > > From my point of view the device should not be used if it doesn't > contain the correct calibration data. I guess it could work somehow but > there's no guarantee about the perfomance. Ok. > > What do you do on non-DT systems? Where does the information come from > > in that case? > > Currently ath10k only supports having the calibration data in the OTP > area inside the QCA98XX chip. But some manufacturers want to store it on > the host file, I assume because of the flexibility it provides. And > that's why we have the need for Device Tree support. So currently the calibration data is stored within the device itself? What is the rationale for overriding this? While it might be 'flexible', that's not to say it's fantastic idea to rely upon it. This sounds like a workaround for buggy/incomplete data in the OTP area. > > I'm somewhat puzzled as to why a discoverable PCI device would require > > non-discoverable information to use. > > ath9k has a similar model as well, but it doesn't support Device Tree > (at least not yet). Ah. So currently it's possible to read calibration data from the device itself. That sounds more like what I had expected. Given that, why is it necessary to override this data? > >> * The calibration data is now 2116 bytes, in the future it might be > >> longer. The data is unique for each radio and is created at the > >> factory. > > > > Why would this change in future? Who is in charge of providing this > > information, and deciding upon the format thereof? > > That's up to the firmare and hardware teams working on the chipsets. > Basically ath10k just needs the data and the length of the data. One issue I'm concerned with is the possiblity of a mismatch between the FW (which is presumably loaded by Linux from a filesystem somewhere), and the FW-specific(?) calibration data which comes from somewhere else. I assume given the calibration data would otherwise come from the OTP area that new FW must be backwards compatible with old calibration data? I hope that even with a 'flexible' mechanism for overriding this information, that compatibility would remain the case, so a user would not have to update their DTB simply because they updated their userspace and hence their firmware. Otherwise, this sounds broken to me. > >> * ath10k must be able to reliably map the PCI device (=radio) to the > >> correct calibration data. Maybe with using PCI bus and slot numbers? > > > > I guess we'd have to do something along those lines. > > > > I'd like to get a better understanding of the problem before we start > > figuring out how to pass an arbitrary blob of information around. > > I hope my answers helped. Somewhat, yes! Thanks, Mark. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
Arnd Bergmann writes: > On Thursday 02 October 2014 16:47:48 Kalle Valo wrote: >> > >> > When you know the PCI bus/device/function ID of the device, you can put >> > a device node in the dts file that corresponds to the PCI dev, and you >> > can find the of_node pointer from pci_dev->dev.of_node. >> >> For me that's easier said than done as I'm a total newbie with Device >> Tree Can you give any pointers or examples how to do that in >> practise, please? Especially "node in the dts file that corresponds to >> the PCI dev" part is puzzling me. > > See the recent patch "[PATCH v4] ARM: shmobile: r8a7791: link PCI USB > devices to USB PHY" where someone does the same thing to supply additional > data to a PCI device node in shmobile. > > Basically you just need to add a node under your PCI host controller node > with "reg = <0x800 0 0 0 0>" (or whatever the address is and put the > properties in there. See www.openfirmware.org/1275/bindings/pci/pci2_1.pdf > for the description of how to construct the addresses. Excellent, thanks. I'll study these and try to learn more. > I notice that there are no Qualcomm or Atheros PCI host controller drivers > in Linux though, so you first have to write a driver that allows probing > the PCI bus, and get the binding reviewed for that before you can add > it to the dts files. Is this for ipq8064 or something else? But now I'm lost again :) I want ath10k and this feature to work with all possible PCI controllers, not just with Qualcomm controllers. So why do I need to wait for Qualcomm PCI host controller driver? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Thursday 02 October 2014 16:47:48 Kalle Valo wrote: > > > > When you know the PCI bus/device/function ID of the device, you can put > > a device node in the dts file that corresponds to the PCI dev, and you > > can find the of_node pointer from pci_dev->dev.of_node. > > For me that's easier said than done as I'm a total newbie with Device > Tree Can you give any pointers or examples how to do that in > practise, please? Especially "node in the dts file that corresponds to > the PCI dev" part is puzzling me. See the recent patch "[PATCH v4] ARM: shmobile: r8a7791: link PCI USB devices to USB PHY" where someone does the same thing to supply additional data to a PCI device node in shmobile. Basically you just need to add a node under your PCI host controller node with "reg = <0x800 0 0 0 0>" (or whatever the address is and put the properties in there. See www.openfirmware.org/1275/bindings/pci/pci2_1.pdf for the description of how to construct the addresses. I notice that there are no Qualcomm or Atheros PCI host controller drivers in Linux though, so you first have to write a driver that allows probing the PCI bus, and get the binding reviewed for that before you can add it to the dts files. Is this for ipq8064 or something else? Arnd ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
Arnd Bergmann writes: > On Thursday 02 October 2014 16:14:43 Kalle Valo wrote: >> Hi Device Tree gurus, >> >> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and >> located in drivers/net/wireless/ath/ath10k/. Currently it only supports >> PCI devices. >> >> Some of the devices store the calibration data to the host flash and the >> bootloader reads the data from the flash. And now we need a method to >> deliver the calibration data from bootloader to ath10k. Basically our >> requirements are: >> >> * ath10k must support any number of radios (one radio per PCI device). >> >> * The calibration data is now 2116 bytes, in the future it might be >> longer. The data is unique for each radio and is created at the >> factory. >> >> * ath10k must be able to reliably map the PCI device (=radio) to the >> correct calibration data. Maybe with using PCI bus and slot numbers? >> >> We have been trying to find similar cases from other drivers but no >> luck. Basically my question is how to do this properly with Device Tree? >> Especially how to map the calibration data to correct PCI device? Are >> there any examples which would help us to implement this? > > When you know the PCI bus/device/function ID of the device, you can put > a device node in the dts file that corresponds to the PCI dev, and you > can find the of_node pointer from pci_dev->dev.of_node. For me that's easier said than done as I'm a total newbie with Device Tree :) Can you give any pointers or examples how to do that in practise, please? Especially "node in the dts file that corresponds to the PCI dev" part is puzzling me. > 2116 is probably ok to put into a DT property of that device directly. Ok, that's good. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
Hi Mark, Mark Rutland writes: >> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and >> located in drivers/net/wireless/ath/ath10k/. Currently it only supports >> PCI devices. >> >> Some of the devices store the calibration data to the host flash and the >> bootloader reads the data from the flash. And now we need a method to >> deliver the calibration data from bootloader to ath10k. > > What does this calibration data consist of? >From ath10k point of view it's just a binary blob which we push to the firmware before we start it. ath10k does not parse it in any way. > What happens if you don't have the calibration data? Is it a critical > requirement for the use of the device, or does its absence simply result > in degraded performance? >From my point of view the device should not be used if it doesn't contain the correct calibration data. I guess it could work somehow but there's no guarantee about the perfomance. > What do you do on non-DT systems? Where does the information come from > in that case? Currently ath10k only supports having the calibration data in the OTP area inside the QCA98XX chip. But some manufacturers want to store it on the host file, I assume because of the flexibility it provides. And that's why we have the need for Device Tree support. > I'm somewhat puzzled as to why a discoverable PCI device would require > non-discoverable information to use. ath9k has a similar model as well, but it doesn't support Device Tree (at least not yet). >> * The calibration data is now 2116 bytes, in the future it might be >> longer. The data is unique for each radio and is created at the >> factory. > > Why would this change in future? Who is in charge of providing this > information, and deciding upon the format thereof? That's up to the firmare and hardware teams working on the chipsets. Basically ath10k just needs the data and the length of the data. >> * ath10k must be able to reliably map the PCI device (=radio) to the >> correct calibration data. Maybe with using PCI bus and slot numbers? > > I guess we'd have to do something along those lines. > > I'd like to get a better understanding of the problem before we start > figuring out how to pass an arbitrary blob of information around. I hope my answers helped. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
Hi, > ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and > located in drivers/net/wireless/ath/ath10k/. Currently it only supports > PCI devices. > > Some of the devices store the calibration data to the host flash and the > bootloader reads the data from the flash. And now we need a method to > deliver the calibration data from bootloader to ath10k. What does this calibration data consist of? What happens if you don't have the calibration data? Is it a critical requirement for the use of the device, or does its absence simply result in degraded performance? What do you do on non-DT systems? Where does the information come from in that case? I'm somewhat puzzled as to why a discoverable PCI device would require non-discoverable information to use. > * The calibration data is now 2116 bytes, in the future it might be > longer. The data is unique for each radio and is created at the > factory. Why would this change in future? Who is in charge of providing this information, and deciding upon the format thereof? > * ath10k must be able to reliably map the PCI device (=radio) to the > correct calibration data. Maybe with using PCI bus and slot numbers? I guess we'd have to do something along those lines. I'd like to get a better understanding of the problem before we start figuring out how to pass an arbitrary blob of information around. Thanks, Mark. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
On Thursday 02 October 2014 16:14:43 Kalle Valo wrote: > Hi Device Tree gurus, > > ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and > located in drivers/net/wireless/ath/ath10k/. Currently it only supports > PCI devices. > > Some of the devices store the calibration data to the host flash and the > bootloader reads the data from the flash. And now we need a method to > deliver the calibration data from bootloader to ath10k. Basically our > requirements are: > > * ath10k must support any number of radios (one radio per PCI device). > > * The calibration data is now 2116 bytes, in the future it might be > longer. The data is unique for each radio and is created at the > factory. > > * ath10k must be able to reliably map the PCI device (=radio) to the > correct calibration data. Maybe with using PCI bus and slot numbers? > > We have been trying to find similar cases from other drivers but no > luck. Basically my question is how to do this properly with Device Tree? > Especially how to map the calibration data to correct PCI device? Are > there any examples which would help us to implement this? When you know the PCI bus/device/function ID of the device, you can put a device node in the dts file that corresponds to the PCI dev, and you can find the of_node pointer from pci_dev->dev.of_node. 2116 is probably ok to put into a DT property of that device directly. Arnd ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
ath10k: calibration data through Device Tree?
Hi Device Tree gurus, ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and located in drivers/net/wireless/ath/ath10k/. Currently it only supports PCI devices. Some of the devices store the calibration data to the host flash and the bootloader reads the data from the flash. And now we need a method to deliver the calibration data from bootloader to ath10k. Basically our requirements are: * ath10k must support any number of radios (one radio per PCI device). * The calibration data is now 2116 bytes, in the future it might be longer. The data is unique for each radio and is created at the factory. * ath10k must be able to reliably map the PCI device (=radio) to the correct calibration data. Maybe with using PCI bus and slot numbers? We have been trying to find similar cases from other drivers but no luck. Basically my question is how to do this properly with Device Tree? Especially how to map the calibration data to correct PCI device? Are there any examples which would help us to implement this? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: calibration data through Device Tree?
Kalle Valo writes: > ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and > located in drivers/net/wireless/ath/ath10k/. Currently it only supports > PCI devices. Great, I used an old address: 5.1.0 - Unknown address error 550-'5.1.6 : Recipient address rejected: User has moved to devicetree at vger.kernel.org' I'll resend the mail to the new address. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
ath10k: calibration data through Device Tree?
Hi Device Tree gurus, ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and located in drivers/net/wireless/ath/ath10k/. Currently it only supports PCI devices. Some of the devices store the calibration data to the host flash and the bootloader reads the data from the flash. And now we need a method to deliver the calibration data from bootloader to ath10k. Basically our requirements are: * ath10k must support any number of radios (one radio per PCI device). * The calibration data is now 2116 bytes, in the future it might be longer. The data is unique for each radio and is created at the factory. * ath10k must be able to reliably map the PCI device (=radio) to the correct calibration data. Maybe with using PCI bus and slot numbers? We have been trying to find similar cases from other drivers but no luck. Basically my question is how to do this properly with Device Tree? Especially how to map the calibration data to correct PCI device? Are there any examples which would help us to implement this? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k