Re: [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
Hi Sourav, On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote: > Booting 3.8-rc4 om omap 4430sdp results in the following error > > omap_i2c 4807.i2c: did not get pins for i2c error: -19 > [1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz > [1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 > [1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz > [1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19 > [1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz > [1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19 > [1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz > > This happens because omap4 dts file is not adapted to use i2c through pinctrl > framework. Populating i2c pinctrl data to get rid of the error. > > Tested on omap4430 sdp with 3.8-rc4 kernel. > > Signed-off-by: Sourav Poddar > Reported-by: Santosh Shilimkar > --- Could you do the same thing for panda? I'm getting the same kind of errors with it: [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [...] [2.884826] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 [2.890686] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz [2.892028] omap_i2c 4806.i2c: did not get pins for i2c error: -19 [2.899047] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz [2.906677] omap_i2c 4835.i2c: did not get pins for i2c error: -19 [2.912872] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
On Wed, 2013-01-30 at 14:18 +0530, Santosh Shilimkar wrote: > On Wednesday 30 January 2013 02:13 PM, Kumar, Anil wrote: > > Hi Sourav, > > > > On Wed, Jan 30, 2013 at 12:10:18, Poddar, Sourav wrote: > >> Hi Luciano, > >> On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote: > >>> Hi Sourav, > >>> > >>> On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote: > >>>> Booting 3.8-rc4 om omap 4430sdp results in the following error > >>>> > >>>> omap_i2c 4807.i2c: did not get pins for i2c error: -19 > >>>> [1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz > >>>> [1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 > >>>> [1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz > >>>> [1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19 > >>>> [1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz > >>>> [1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19 > >>>> [1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz > >>>> > >>>> This happens because omap4 dts file is not adapted to use i2c through > >>>> pinctrl > >>>> framework. Populating i2c pinctrl data to get rid of the error. > >>>> > >>>> Tested on omap4430 sdp with 3.8-rc4 kernel. > >>>> > >>>> Signed-off-by: Sourav Poddar > >>>> Reported-by: Santosh Shilimkar > >>>> --- > >>> Could you do the same thing for panda? I'm getting the same kind of > >>> errors with it: > > > > omap4 uses pinctrl-single driver for pinmux with DT. Currently > > pinctrl-single driver is getting up after I2C driver. So I2c cannot > > use pinctrl. The below patch solve this issue > > > > http://www.gossamer-threads.com/lists/linux/kernel/1669067 > > > > Can you try with this ? it may solve it. > > > OMAP i2c driver already takes care of -EPROBE_DEFER. The issue > as you see from the log is not probe failure but missing the > pin information in DT blob. And thats what patch does. Yes, Santosh is right. I tried this patch, but it didn't fix the warnings. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Thu, 2013-01-31 at 16:42 -0500, Matt Porter wrote: > On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: > > On Thursday 31 January 2013, Matt Porter wrote: > > > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > > > On Wednesday 30 January 2013, Matt Porter wrote: > > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > > > + of_dma_controller_register(dev->of_node, > > > > > + of_dma_simple_xlate, > > > > > + &edma_filter_info); > > > > > + } > > > > > > > > How do you actually deal with the problem mentioned by Padma, that > > > > the filter function does not know which edma instance it is looking > > > > at? If you assume that there can only be a single edma instance in > > > > the system, that is probably a limitation that should be documented > > > > somewhere, and ideally the probe() function should check for that. > > > > > > I make an assumption of one edma instance in the system in the case of > > > DT being populated. This is always true right now as the only SoC with > > > two EDMA controllers in existence is Davinci DA850. Until recently, > > > Davinci had no DT support. Given the steady work being done today on DT > > > support for DA850, it'll probably be something needed in 3.10. > > > > > > I will add a comment and check in probe() to capture this assumption > > > and then plan to update separately to support DA850 booting from DT. > > > > Ok, sounds good. Hopefully by then we will already have a nicer > > way to write an xlate function that does not rely on a filter > > function. > > Yes, it would be nice to avoid what Padma had to do. I should have > mentioned also that the second EDMA on DA850 has no DMA events of > immediate use on it anyway. All the in-kernel users use events on the > first controller, except for the second MMC instance. That's only used > for a wl12xx module on the EVM and that driver has no DT support so it > doesn't matter yet in the DT case. Because of this, DA850 can actually > add EDMA DT support immediately (on top of this series) and add DMA > support to the DT support already posted for the Davinci SPI and MMC > client drivers. I haven't followed this whole discussion in details, but please notice that I'm aiming to get DT support for the WiLink modules (wlcore, wl12xx...) for 3.10. ;) -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] Documentation: dt: bindings: TI WiLink modules
Add device tree bindings documentation for the TI WiLink modules. Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 modules is supported. Signed-off-by: Luciano Coelho --- I created a new directory under net to contain wireless bindings documentation. The actual implementation in the driver will follow separately. .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file mode 100644 index 000..d8e8bfbb --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt @@ -0,0 +1,46 @@ +TI WiLink Wireless Modules Device Tree Bindings +=== + +The WiLink modules provide wireless connectivity, such as WLAN, +Bluetooth, FM and NFC. + +There are several different modules available, which can be grouped by +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not +currently supported with device tree. + +Currently, only the WLAN portion of the modules is supported with +device tree. + +Required properties: + + +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" +- interrupt-parent: the interrupt controller +- interrupts: out-of-band WLAN interrupt + See the interrupt controller's bindings documentation for + detailed definition. + +Optional properties: + + +- refclock: the internal WLAN reference clock frequency (required for + WiLink6 and WiLink7; not used for WiLink8). Must be one of the + following: + 0 = 19.2 MHz + 1 = 26.0 MHz + 2 = 38.4 MHz + 3 = 52.0 MHz + 4 = 38.4 MHz, XTAL + 5 = 26.0 MHz, XTAL + +- tcxoclock: the internal WLAN TCXO clock frequency (required for + WiLink7 not used for WiLink6 and WiLink8). Must be one of the + following: + 0 = 19.200 MHz + 1 = 26.000 MHz + 2 = 38.400 MHz + 3 = 52.000 MHz + 4 = 16.368 MHz + 5 = 32.736 MHz + 6 = 16.800 MHz + 7 = 33.600 MHz -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Tue, 2013-06-25 at 14:12 +0300, Felipe Balbi wrote: > On Tue, Jun 25, 2013 at 11:35:30AM +0300, Luciano Coelho wrote: > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > > + following: > > + 0 = 19.200 MHz > > + 1 = 26.000 MHz > > + 2 = 38.400 MHz > > + 3 = 52.000 MHz > > + 4 = 16.368 MHz > > + 5 = 32.736 MHz > > + 6 = 16.800 MHz > > + 7 = 33.600 MHz > > DTS files are pre-processed, so you could add defines in a header and > share the header between DTS and driver. Could help you having: > > tcxoclock = WILINK_19_200MHz; > > instead of > > tcxoclock = 0; I don't see any .dts file really doing this. There are some imx*.dtsi files that include imx*.h files, but I don't see these headers being included in any source code file. In fact, we already have all these values defined in include/linux/wl12xx.h, so it could be nice to reuse. But the cross-directory includes would look "funny". And I think it's a bit overkill. These values are actually used by the firmware itself, not only the driver, so they are also platform independent and not related to the OS. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
(fixed the ARM mailing list address) On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: > Add device tree bindings documentation for the TI WiLink modules. > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > modules is supported. > > Signed-off-by: Luciano Coelho > --- > > I created a new directory under net to contain wireless bindings > documentation. > > The actual implementation in the driver will follow separately. > > .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 > > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > new file mode 100644 > index 000..d8e8bfbb > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > @@ -0,0 +1,46 @@ > +TI WiLink Wireless Modules Device Tree Bindings > +=== > + > +The WiLink modules provide wireless connectivity, such as WLAN, > +Bluetooth, FM and NFC. > + > +There are several different modules available, which can be grouped by > +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not > +currently supported with device tree. > + > +Currently, only the WLAN portion of the modules is supported with > +device tree. > + > +Required properties: > + > + > +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" > +- interrupt-parent: the interrupt controller > +- interrupts: out-of-band WLAN interrupt > + See the interrupt controller's bindings documentation for > + detailed definition. > + > +Optional properties: > + > + > +- refclock: the internal WLAN reference clock frequency (required for > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > + following: > + 0 = 19.2 MHz > + 1 = 26.0 MHz > + 2 = 38.4 MHz > + 3 = 52.0 MHz > + 4 = 38.4 MHz, XTAL > + 5 = 26.0 MHz, XTAL > + > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > + following: > + 0 = 19.200 MHz > + 1 = 26.000 MHz > + 2 = 38.400 MHz > + 3 = 52.000 MHz > + 4 = 16.368 MHz > + 5 = 32.736 MHz > + 6 = 16.800 MHz > + 7 = 33.600 MHz If this is okay for everyone, can I push this via my tree (which goes to linux-wireless->net->linus)? I think it makes more sense to send the documentation together with the patch that actually implements the DT node parsing in the driver. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
(oh crap, now *really* fixed the ARM mailing list address) On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: > Add device tree bindings documentation for the TI WiLink modules. > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > modules is supported. > > Signed-off-by: Luciano Coelho > --- > > I created a new directory under net to contain wireless bindings > documentation. > > The actual implementation in the driver will follow separately. > > .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 > > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > > diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > new file mode 100644 > index 000..d8e8bfbb > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt > @@ -0,0 +1,46 @@ > +TI WiLink Wireless Modules Device Tree Bindings > +=== > + > +The WiLink modules provide wireless connectivity, such as WLAN, > +Bluetooth, FM and NFC. > + > +There are several different modules available, which can be grouped by > +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not > +currently supported with device tree. > + > +Currently, only the WLAN portion of the modules is supported with > +device tree. > + > +Required properties: > + > + > +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8" > +- interrupt-parent: the interrupt controller > +- interrupts: out-of-band WLAN interrupt > + See the interrupt controller's bindings documentation for > + detailed definition. > + > +Optional properties: > + > + > +- refclock: the internal WLAN reference clock frequency (required for > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > + following: > + 0 = 19.2 MHz > + 1 = 26.0 MHz > + 2 = 38.4 MHz > + 3 = 52.0 MHz > + 4 = 38.4 MHz, XTAL > + 5 = 26.0 MHz, XTAL > + > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > + following: > + 0 = 19.200 MHz > + 1 = 26.000 MHz > + 2 = 38.400 MHz > + 3 = 52.000 MHz > + 4 = 16.368 MHz > + 5 = 32.736 MHz > + 6 = 16.800 MHz > + 7 = 33.600 MHz If this is okay for everyone, can I push this via my tree (which goes to linux-wireless->net->linus)? I think it makes more sense to send the documentation together with the patch that actually implements the DT node parsing in the driver. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
Hi Tony, On Tue, 2013-06-25 at 23:24 -0700, Tony Lindgren wrote: > * Luciano Coelho [130625 12:43]: > > On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: > > > Add device tree bindings documentation for the TI WiLink modules. > > > Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 > > > modules is supported. > > > > > > Signed-off-by: Luciano Coelho > > > --- [...] > > > +Optional properties: > > > + > > > + > > > +- refclock: the internal WLAN reference clock frequency (required for > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > > > + following: > > > + 0 = 19.2 MHz > > > + 1 = 26.0 MHz > > > + 2 = 38.4 MHz > > > + 3 = 52.0 MHz > > > + 4 = 38.4 MHz, XTAL > > > + 5 = 26.0 MHz, XTAL > > This is just the omap refclock, right? If so, you can just pass the > standard clock phandle. I know we don't yet have the DT clocks merged, > but Tero just posted another revision of those. This is an internal clock. This clock is part of the module that contains the WiLink chip. It is not associated with the clocks in the main board (OMAP). > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > > > + following: > > > + 0 = 19.200 MHz > > > + 1 = 26.000 MHz > > > + 2 = 38.400 MHz > > > + 3 = 52.000 MHz > > > + 4 = 16.368 MHz > > > + 5 = 32.736 MHz > > > + 6 = 16.800 MHz > > > + 7 = 33.600 MHz > > Where does this clock come from? Maybe this can be set based on the > compatible value if it's completely internal? This is also a completely internal clock. My "compatible" values are based on the WiLink chip itself, not in the module that contains the chip. There are several modules and they are the ones that specify the clock frequencies. This data I'm passing here is just to tell the WiLink chip which frequencies the module uses. My driver is for the WiLink chip itself, not to the module (in theory). So I think having the WiLink values as bindings would be more generic than having to specify values for each available module (eg. "lsr-research,tiwi-ble") and mapping those values to specific frequencies in the driver. > > If this is okay for everyone, can I push this via my tree (which goes to > > linux-wireless->net->linus)? I think it makes more sense to send the > > documentation together with the patch that actually implements the DT > > node parsing in the driver. > > If we can use the standard bindings, it might be worth waiting until > we have the DT clocks available as we have the pdata workaround merged > anyways. That's because then we don't need to support the custom > binding later on ;) I looked into Tero's patches and I considered using the generic clock bindings, but I think it doesn't make sense in this case. The thing is that the module is not providing the clocks to the main board. Neither is the WiLink chip consuming clocks from the main board. I thought about specifying clock providers and consumers to be used only by the module and WiLink chip, but I think it's overkill. And we would also have to find a way to prevent the main clock framework from trying to handle them. So, my conclusion was that, even though these *are* clocks, from the main board's perspective they're just specifications of what the module looks like. Does this make sense? -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
(added mailing lists and everyone back to the thread)
On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote:
> On 06/25/2013 03:35 AM, Luciano Coelho wrote:
> > +Optional properties:
> > +
> > +
> > +- refclock: the internal WLAN reference clock frequency (required for
> > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > + following:
> > + 0 = 19.2 MHz
> > + 1 = 26.0 MHz
> > + 2 = 38.4 MHz
> > + 3 = 52.0 MHz
> > + 4 = 38.4 MHz, XTAL
> > + 5 = 26.0 MHz, XTAL
> > +
> > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > + following:
> > + 0 = 19.200 MHz
> > + 1 = 26.000 MHz
> > + 2 = 38.400 MHz
> > + 3 = 52.000 MHz
> > + 4 = 16.368 MHz
> > + 5 = 32.736 MHz
> > + 6 = 16.800 MHz
> > + 7 = 33.600 MHz
> >
> just a gentle query - why not use frequency itself here in Hz for
> refclock and txoclk?
I thought about using the actual frequencies, but I decided not to do
so, because I'd have to convert them to these values anyway. These
values are used to configure the firmware and it uses these
"enumerations".
> might not another option of using
> node {
> clocks=<&clk>;
> }
>
> Usually refclock is an external clock source, no?
No. In the WiLink case, both refclock and tcxoclock are internal
clocks. They are in the module itself and what we need to do is tell
the WiLink chip what the module's clocks look like.
> the above allows you to do an devm_clk_get and clk_get_rate() to figure
> out the exact clock frequency.
No, we can't use these calls, because they are internal clocks.
Please see my more complete explanation as an answer to Tony's email.
Thanks for your review!
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-06-27 at 07:51 -0500, Nishanth Menon wrote: > On 11:47-20130627, Luciano Coelho wrote: > > (added mailing lists and everyone back to the thread) > > > > On Wed, 2013-06-26 at 23:38 -0500, Nishanth Menon wrote: > > > On 06/25/2013 03:35 AM, Luciano Coelho wrote: > > > > +Optional properties: > > > > + > > > > + > > > > +- refclock: the internal WLAN reference clock frequency (required for > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the > > > > + following: > > > > + 0 = 19.2 MHz > > > > + 1 = 26.0 MHz > > > > + 2 = 38.4 MHz > > > > + 3 = 52.0 MHz > > > > + 4 = 38.4 MHz, XTAL > > > > + 5 = 26.0 MHz, XTAL > > > > + > > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the > > > > + following: > > > > + 0 = 19.200 MHz > > > > + 1 = 26.000 MHz > > > > + 2 = 38.400 MHz > > > > + 3 = 52.000 MHz > > > > + 4 = 16.368 MHz > > > > + 5 = 32.736 MHz > > > > + 6 = 16.800 MHz > > > > + 7 = 33.600 MHz > > > > > > > just a gentle query - why not use frequency itself here in Hz for > > > refclock and txoclk? > > > > I thought about using the actual frequencies, but I decided not to do > > so, because I'd have to convert them to these values anyway. These > > values are used to configure the firmware and it uses these > > "enumerations". > Could we not hide this under preprocessor macros instead? just wondering > of txoclock = <6>; kind of usage.. easy to make mistakes and easier to > confuse a new reader :). Yes, I guess we could create some preprocessor macros for this. But the documentation would remain the same. I can't add preprocessor macros to the bindings documentation. ;) For the actual DTS files, I could add a wilink.dtsi with enumerations for these values so they could be used in the node definitions. But I'm not sure it's going to be that valuable in the end. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote: > On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho wrote: > > For the actual DTS files, I could add a wilink.dtsi with enumerations > > for these values so they could be used in the node definitions. But I'm > > not sure it's going to be that valuable in the end. > The way GPIO HIGH was defined might help to provide guidance I think :) Where? As far as I can see, the GPIO flags are defined in a bitmap. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote: > On 06/27/2013 08:19 AM, Luciano Coelho wrote: > > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote: > >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho wrote: > >>> For the actual DTS files, I could add a wilink.dtsi with enumerations > >>> for these values so they could be used in the node definitions. But I'm > >>> not sure it's going to be that valuable in the end. > >> The way GPIO HIGH was defined might help to provide guidance I think :) > > > > Where? As far as I can see, the GPIO flags are defined in a bitmap. > > include/dt-bindings/gpio/gpio.h Thanks! I don't see these macros used anywhere, though. > And corresponding kernel header: > include/linux/of_gpio.h This seems to be a completely different thing. This is the header that contains the helper functions to get GPIO-related device tree nodes, isn't it? > just a hint. not saying frequencies were defined in header. for systems > that define frequencies - example cpufreq OPPs, clock node usage, we do > not use indexing to frequency, instead, that is the responsibility of > driver to convert frequency back to required index. > git grep frequency Documentation/devicetree/bindings gives you how the > precedence looks like. > > Personally, if given a choice, I'd go with actual frequencies rather > than indexes. If I do that, I need to add also a separate flag to define whether the XTAL clock is used or not. For instance, we have 26MHz and 26MHz crystal; and 38.4MHz and 38.4MHz crystal... -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho wrote:
> > On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
> >> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> >> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho wrote:
> >> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >> >>> for these values so they could be used in the node definitions. But
> >> >>> I'm
> >> >>> not sure it's going to be that valuable in the end.
> >> >> The way GPIO HIGH was defined might help to provide guidance I think :)
> >> >
> >> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
> >>
> >> include/dt-bindings/gpio/gpio.h
> >
> > Thanks! I don't see these macros used anywhere, though.
> umm... I'd think you have'nt looked deep enough / lists :)
If you mean mailing lists, you're right, I didn't. I just did a git
grep for the macros and didn't find any users.
> >> And corresponding kernel header:
> >> include/linux/of_gpio.h
> >
> > This seems to be a completely different thing. This is the header that
> > contains the helper functions to get GPIO-related device tree nodes,
> > isn't it?
> That is true, but it also contains the flag for level which needs to
> be in sync with the gpio.h dts header.
> >> just a hint. not saying frequencies were defined in header. for systems
> >> that define frequencies - example cpufreq OPPs, clock node usage, we do
> >> not use indexing to frequency, instead, that is the responsibility of
> >> driver to convert frequency back to required index.
> >> git grep frequency Documentation/devicetree/bindings gives you how the
> >> precedence looks like.
> >>
> >> Personally, if given a choice, I'd go with actual frequencies rather
> >> than indexes.
> >
> > If I do that, I need to add also a separate flag to define whether the
> > XTAL clock is used or not. For instance, we have 26MHz and 26MHz
> > crystal; and 38.4MHz and 38.4MHz crystal...
> Yes, you would have to. at the same time, it is easy for module maker
> to provide dtsi corresponding to exact h/w representation on his
> module using wilink chip without being worried about weird index value
> whose meaning is hidden in binding
The module makers need to know about the bindings and read the document
before they specify the node in DTS. I think for clarity, a comment in
the DTS file stating the actual frequency is good enough. Simpler and
more efficient (in terms of DT binary size and module code size) than
adding the actual frequencies.
> On the flip side, It also allows driver to reject frequencies /
> configurations that are not supported by the corresponding chip.
It's actually much easier to reject frequencies that are not valid with
the enumeration. "if (refclock > 5) { bail_out(); }". If I need to
check every frequency, I need to add an array of valid frequencies and
so on. Waste of code, IMHO.
> As I said, just my 2 cents. Personally, I'd like dts files to be as
> readable as c files without having to dig through bindings document.
As I said before, for readability, adding a comment with the frequency
is good enough. This is what I did for PandaES's DTS (not sent out
yet):
wlan {
compatible = "ti,wilink6";
interrupt-parent = <&gpio2>;
interrupts = <21 0x4>; /* gpio line 53, high level triggered */
refclock = <2>;/* 38.4 MHz */
};
Looks more readable to me than:
wlan {
compatible = "ti,wilink6";
interrupt-parent = <&gpio2>;
interrupts = <21 0x4>; /* gpio line 53, high level triggered */
refclock = <38400>;
refclock_xtal = <0>;
};
The macro idea sounds better to me, but in this case this code is so
simple that I don't think it's really worth it.
And, from another point of view, I see this as only a specification of
the module's details. The frequency value is not really used anywhere
outside the module, so we don't see it. I don't think there's a good
reason to expose the actual frequency to the kernel (and parse it back
to the values the firmware needs), since nothing else inside the kernel
will care about it.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-06-27 at 14:12 -0500, Nishanth Menon wrote:
> On 06/27/2013 01:51 PM, Luciano Coelho wrote:
> > On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
> >> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho wrote:
> >>> On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
> >>>> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> >>>>> On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >>>>>> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho wrote:
> >>>>>>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >>>>>>> for these values so they could be used in the node definitions. But
> >>>>>>> I'm
> >>>>>>> not sure it's going to be that valuable in the end.
> >>>>>> The way GPIO HIGH was defined might help to provide guidance I think
> >>>>>> :)
> >>>>>
> >>>>> Where? As far as I can see, the GPIO flags are defined in a bitmap.
> >>>>
> >>>> include/dt-bindings/gpio/gpio.h
> >>>
> >>> Thanks! I don't see these macros used anywhere, though.
> >> umm... I'd think you have'nt looked deep enough / lists :)
> >
> > If you mean mailing lists, you're right, I didn't. I just did a git
> > grep for the macros and didn't find any users.
> git grep "GPIO_ACTIVE_[HIGH|LOW]" arch/arm/boot/dts/|wc -l
> 344
> on next-20130626. anyways, besides the point.
>
>
> >>> This seems to be a completely different thing. This is the header that
> >>> contains the helper functions to get GPIO-related device tree nodes,
> >>> isn't it?
> >> That is true, but it also contains the flag for level which needs to
> >> be in sync with the gpio.h dts header.
> >>>> just a hint. not saying frequencies were defined in header. for systems
> >>>> that define frequencies - example cpufreq OPPs, clock node usage, we do
> >>>> not use indexing to frequency, instead, that is the responsibility of
> >>>> driver to convert frequency back to required index.
> >>>> git grep frequency Documentation/devicetree/bindings gives you how the
> >>>> precedence looks like.
> >>>>
> >>>> Personally, if given a choice, I'd go with actual frequencies rather
> >>>> than indexes.
> >>>
> >>> If I do that, I need to add also a separate flag to define whether the
> >>> XTAL clock is used or not. For instance, we have 26MHz and 26MHz
> >>> crystal; and 38.4MHz and 38.4MHz crystal...
> >> Yes, you would have to. at the same time, it is easy for module maker
> >> to provide dtsi corresponding to exact h/w representation on his
> >> module using wilink chip without being worried about weird index value
> >> whose meaning is hidden in binding
> >
> > The module makers need to know about the bindings and read the document
> > before they specify the node in DTS. I think for clarity, a comment in
> > the DTS file stating the actual frequency is good enough. Simpler and
> > more efficient (in terms of DT binary size and module code size) than
> > adding the actual frequencies.
> >
> >
> >> On the flip side, It also allows driver to reject frequencies /
> >> configurations that are not supported by the corresponding chip.
> >
> > It's actually much easier to reject frequencies that are not valid with
> > the enumeration. "if (refclock > 5) { bail_out(); }". If I need to
> > check every frequency, I need to add an array of valid frequencies and
> > so on. Waste of code, IMHO.
> >
> >
> >> As I said, just my 2 cents. Personally, I'd like dts files to be as
> >> readable as c files without having to dig through bindings document.
> >
> > As I said before, for readability, adding a comment with the frequency
> > is good enough. This is what I did for PandaES's DTS (not sent out
> > yet):
> >
> > wlan {
> > compatible = "ti,wilink6";
> > interrupt-parent = <&gpio2>;
> > interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > refclock = <2>;/* 38.4 MHz */
> > };
> >
> > Looks more readable to me than:
> >
> > wlan {
> > compatible = "ti,wilink6";
> > interrup
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > +Optional properties:
> > +
> > +
> > +- refclock: the internal WLAN reference clock frequency (required for
> > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > + following:
> > + 0 = 19.2 MHz
> > + 1 = 26.0 MHz
> > + 2 = 38.4 MHz
> > + 3 = 52.0 MHz
> > + 4 = 38.4 MHz, XTAL
> > + 5 = 26.0 MHz, XTAL
> > +
> > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > + following:
> > + 0 = 19.200 MHz
> > + 1 = 26.000 MHz
> > + 2 = 38.400 MHz
> > + 3 = 52.000 MHz
> > + 4 = 16.368 MHz
> > + 5 = 32.736 MHz
> > + 6 = 16.800 MHz
> > + 7 = 33.600 MHz
>
> This looks suspiciously like what we have the common clock bindings for:
>
> refclk {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <1920>;
> }
>
> wilink {
> compatible = "ti,wilink7";
> interrupt-parent = <&some_interrupt_controller>;
> interrupts = <0 1 1>;
> clocks = <&refclk>, <&refclk>;
> clock-names = "refclk", "txoclk";
> };
>
> Could you not use them?
Hmmm... this actually does look good. But these are internal clocks in
the modules, they cannot be accessed from outside. Does it make sense
to register them with the clock framework?
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
(fixed Mike's address)
On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > > +Optional properties:
> > > > +
> > > > +
> > > > +- refclock: the internal WLAN reference clock frequency (required for
> > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > > > + following:
> > > > + 0 = 19.2 MHz
> > > > + 1 = 26.0 MHz
> > > > + 2 = 38.4 MHz
> > > > + 3 = 52.0 MHz
> > > > + 4 = 38.4 MHz, XTAL
> > > > + 5 = 26.0 MHz, XTAL
> > > > +
> > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > > > + following:
> > > > + 0 = 19.200 MHz
> > > > + 1 = 26.000 MHz
> > > > + 2 = 38.400 MHz
> > > > + 3 = 52.000 MHz
> > > > + 4 = 16.368 MHz
> > > > + 5 = 32.736 MHz
> > > > + 6 = 16.800 MHz
> > > > + 7 = 33.600 MHz
> > >
> > > This looks suspiciously like what we have the common clock bindings for:
> > >
> > > refclk {
> > > compatible = "fixed-clock";
> > > #clock-cells = <0>;
> > > clock-frequency = <1920>;
> > > }
> > >
> > > wilink {
> > > compatible = "ti,wilink7";
> > > interrupt-parent = <&some_interrupt_controller>;
> > > interrupts = <0 1 1>;
> > > clocks = <&refclk>, <&refclk>;
> > > clock-names = "refclk", "txoclk";
> > > };
> > >
> > > Could you not use them?
> >
> > Hmmm... this actually does look good. But these are internal clocks in
> > the modules, they cannot be accessed from outside. Does it make sense
> > to register them with the clock framework?
>
> Given we already have a common way of describing clocks, I think it
> makes sense to use it -- people already understand the common bindings,
> and it's less code to add add to the kernel. I don't think the fact
> these clocks are internal should prevent us from describing them as we
> would an external clock.
Yes, I agree with you. Thanks for the suggestion! I think it will look
much better. And now that I dug a bit more into the code, I can see
that there are only structs being populated, so there shouldn't be any
other side-effects.
> Perhaps Mike Turquette [Cc'd] has an opinion on the matter.
Experts' opinions are appreciated. :)
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> (fixed Mike's address)
>
> On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > > > +Optional properties:
> > > > > +
> > > > > +
> > > > > +- refclock: the internal WLAN reference clock frequency (required for
> > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > > > > + following:
> > > > > + 0 = 19.2 MHz
> > > > > + 1 = 26.0 MHz
> > > > > + 2 = 38.4 MHz
> > > > > + 3 = 52.0 MHz
> > > > > + 4 = 38.4 MHz, XTAL
> > > > > + 5 = 26.0 MHz, XTAL
> > > > > +
> > > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > > > > + following:
> > > > > + 0 = 19.200 MHz
> > > > > + 1 = 26.000 MHz
> > > > > + 2 = 38.400 MHz
> > > > > + 3 = 52.000 MHz
> > > > > + 4 = 16.368 MHz
> > > > > + 5 = 32.736 MHz
> > > > > + 6 = 16.800 MHz
> > > > > + 7 = 33.600 MHz
> > > >
> > > > This looks suspiciously like what we have the common clock bindings for:
> > > >
> > > > refclk {
> > > > compatible = "fixed-clock";
> > > > #clock-cells = <0>;
> > > > clock-frequency = <1920>;
> > > > }
> > > >
> > > > wilink {
> > > > compatible = "ti,wilink7";
> > > > interrupt-parent = <&some_interrupt_controller>;
> > > > interrupts = <0 1 1>;
> > > > clocks = <&refclk>, <&refclk>;
> > > > clock-names = "refclk", "txoclk";
> > > > };
> > > >
> > > > Could you not use them?
> > >
> > > Hmmm... this actually does look good. But these are internal clocks in
> > > the modules, they cannot be accessed from outside. Does it make sense
> > > to register them with the clock framework?
> >
> > Given we already have a common way of describing clocks, I think it
> > makes sense to use it -- people already understand the common bindings,
> > and it's less code to add add to the kernel. I don't think the fact
> > these clocks are internal should prevent us from describing them as we
> > would an external clock.
>
> Yes, I agree with you. Thanks for the suggestion! I think it will look
> much better. And now that I dug a bit more into the code, I can see
> that there are only structs being populated, so there shouldn't be any
> other side-effects.
Hmmm, one thing that escaped me. Besides the frequency, I also need a
boolean that tells if the clock is XTAL or not. I can't figure out how
to pass this if I use the generic clock framework. Any suggestions?
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > (fixed Mike's address)
> > >
> > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > > > > > +Optional properties:
> > > > > > > +
> > > > > > > +
> > > > > > > +- refclock: the internal WLAN reference clock frequency
> > > > > > > (required for
> > > > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > > > > > > + following:
> > > > > > > + 0 = 19.2 MHz
> > > > > > > + 1 = 26.0 MHz
> > > > > > > + 2 = 38.4 MHz
> > > > > > > + 3 = 52.0 MHz
> > > > > > > + 4 = 38.4 MHz, XTAL
> > > > > > > + 5 = 26.0 MHz, XTAL
> > > > > > > +
> > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > > > > > > + following:
> > > > > > > + 0 = 19.200 MHz
> > > > > > > + 1 = 26.000 MHz
> > > > > > > + 2 = 38.400 MHz
> > > > > > > + 3 = 52.000 MHz
> > > > > > > + 4 = 16.368 MHz
> > > > > > > + 5 = 32.736 MHz
> > > > > > > + 6 = 16.800 MHz
> > > > > > > + 7 = 33.600 MHz
> > > > > >
> > > > > > This looks suspiciously like what we have the common clock bindings
> > > > > > for:
> > > > > >
> > > > > > refclk {
> > > > > > compatible = "fixed-clock";
> > > > > > #clock-cells = <0>;
> > > > > > clock-frequency = <1920>;
> > > > > > }
> > > > > >
> > > > > > wilink {
> > > > > > compatible = "ti,wilink7";
> > > > > > interrupt-parent = <&some_interrupt_controller>;
> > > > > > interrupts = <0 1 1>;
> > > > > > clocks = <&refclk>, <&refclk>;
> > > > > > clock-names = "refclk", "txoclk";
> > > > > > };
> > > > > >
> > > > > > Could you not use them?
> > > > >
> > > > > Hmmm... this actually does look good. But these are internal clocks
> > > > > in
> > > > > the modules, they cannot be accessed from outside. Does it make sense
> > > > > to register them with the clock framework?
> > > >
> > > > Given we already have a common way of describing clocks, I think it
> > > > makes sense to use it -- people already understand the common bindings,
> > > > and it's less code to add add to the kernel. I don't think the fact
> > > > these clocks are internal should prevent us from describing them as we
> > > > would an external clock.
> > >
> > > Yes, I agree with you. Thanks for the suggestion! I think it will look
> > > much better. And now that I dug a bit more into the code, I can see
> > > that there are only structs being populated, so there shouldn't be any
> > > other side-effects.
> >
> > Hmmm, one thing that escaped me. Besides the frequency, I also need a
> > boolean that tells if the clock is XTAL or not. I can't figure out how
> > to pass this if I use the generic clock framework. Any suggestions?
>
> Could you use clock-output-names for that ?
>
> XTAL clock:
>
> refclk {
> compatible = "fixed-clock";
> #clock cells = <0>;
> clock-frequency = <1920>;
> clock-output-names = "xtal";
> };
>
> non-XTAL clock:
>
> refclk {
> compatible = "fixed-clock";
> #clock cells = <0>;
> clock-frequency = <1920>;
> clock-output-names = "osc"; /* any better name ? */
> };
This starts looking a bit hacky. Using the output name as a flag is not
very pretty.
I think it would be better to have a separate flag for it in the wlan
node. Like an optional "refclock-xtal" boolean or something. The
downside of this is that we would be adding information about the clock
details in the wilink node. :(
OTOH, we could add a flag to the generic clock binding? A new optional
boolean that tells whether the clock is XTAL or not:
refclk {
compatible = "fixed-clock";
#clock cells = <0>;
clock-frequency = <1920>;
clock-xtal;
};
Do you think that would make sense?
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> > > On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > > > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > > > (fixed Mike's address)
> > > > >
> > > > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > > > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > > > > > > > +Optional properties:
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +- refclock: the internal WLAN reference clock frequency
> > > > > > > > > (required for
> > > > > > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one
> > > > > > > > > of the
> > > > > > > > > + following:
> > > > > > > > > + 0 = 19.2 MHz
> > > > > > > > > + 1 = 26.0 MHz
> > > > > > > > > + 2 = 38.4 MHz
> > > > > > > > > + 3 = 52.0 MHz
> > > > > > > > > + 4 = 38.4 MHz, XTAL
> > > > > > > > > + 5 = 26.0 MHz, XTAL
> > > > > > > > > +
> > > > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency
> > > > > > > > > (required for
> > > > > > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of
> > > > > > > > > the
> > > > > > > > > + following:
> > > > > > > > > + 0 = 19.200 MHz
> > > > > > > > > + 1 = 26.000 MHz
> > > > > > > > > + 2 = 38.400 MHz
> > > > > > > > > + 3 = 52.000 MHz
> > > > > > > > > + 4 = 16.368 MHz
> > > > > > > > > + 5 = 32.736 MHz
> > > > > > > > > + 6 = 16.800 MHz
> > > > > > > > > + 7 = 33.600 MHz
> > > > > > > >
> > > > > > > > This looks suspiciously like what we have the common clock
> > > > > > > > bindings for:
> > > > > > > >
> > > > > > > > refclk {
> > > > > > > > compatible = "fixed-clock";
> > > > > > > > #clock-cells = <0>;
> > > > > > > > clock-frequency = <1920>;
> > > > > > > > }
> > > > > > > >
> > > > > > > > wilink {
> > > > > > > > compatible = "ti,wilink7";
> > > > > > > > interrupt-parent = <&some_interrupt_controller>;
> > > > > > > > interrupts = <0 1 1>;
> > > > > > > > clocks = <&refclk>, <&refclk>;
> > > > > > > > clock-names = "refclk", "txoclk";
> > > > > > > > };
> > > > > > > >
> > > > > > > > Could you not use them?
> > > > > > >
> > > > > > > Hmmm... this actually does look good. But these are internal
> > > > > > > clocks in
> > > > > > > the modules, they cannot be accessed from outside. Does it make
> > > > > > > sense
> > > > > > > to register them with the clock framework?
> > > > > >
> > > > > > Given we already have a common way of describing clocks, I think it
> > > > > > makes sense to use it -- people already understand the common
> > > > > > bindings,
> > > > > > and it's less code to add add to the kernel. I don't think the fact
> > > > > > these clocks are internal should prevent us from describing them as
> > > > > > we
> > > > > > would an external clock.
> > > > >
> > > > > Yes, I agree wit
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
> On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> > On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > > On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> > > > On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > > > > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > > > > (fixed Mike's address)
> > > > > >
> > > > > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > > > > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho
> > > > > > > > > wrote:
> > > > > > > > > > +Optional properties:
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > +- refclock: the internal WLAN reference clock frequency
> > > > > > > > > > (required for
> > > > > > > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one
> > > > > > > > > > of the
> > > > > > > > > > + following:
> > > > > > > > > > + 0 = 19.2 MHz
> > > > > > > > > > + 1 = 26.0 MHz
> > > > > > > > > > + 2 = 38.4 MHz
> > > > > > > > > > + 3 = 52.0 MHz
> > > > > > > > > > + 4 = 38.4 MHz, XTAL
> > > > > > > > > > + 5 = 26.0 MHz, XTAL
> > > > > > > > > > +
> > > > > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency
> > > > > > > > > > (required for
> > > > > > > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one
> > > > > > > > > > of the
> > > > > > > > > > + following:
> > > > > > > > > > + 0 = 19.200 MHz
> > > > > > > > > > + 1 = 26.000 MHz
> > > > > > > > > > + 2 = 38.400 MHz
> > > > > > > > > > + 3 = 52.000 MHz
> > > > > > > > > > + 4 = 16.368 MHz
> > > > > > > > > > + 5 = 32.736 MHz
> > > > > > > > > > + 6 = 16.800 MHz
> > > > > > > > > > + 7 = 33.600 MHz
> > > > > > > > >
> > > > > > > > > This looks suspiciously like what we have the common clock
> > > > > > > > > bindings for:
> > > > > > > > >
> > > > > > > > > refclk {
> > > > > > > > > compatible = "fixed-clock";
> > > > > > > > > #clock-cells = <0>;
> > > > > > > > > clock-frequency = <1920>;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > wilink {
> > > > > > > > > compatible = "ti,wilink7";
> > > > > > > > > interrupt-parent = <&some_interrupt_controller>;
> > > > > > > > > interrupts = <0 1 1>;
> > > > > > > > > clocks = <&refclk>, <&refclk>;
> > > > > > > > > clock-names = "refclk", "txoclk";
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > Could you not use them?
> > > > > > > >
> > > > > > > > Hmmm... this actually does look good. But these are internal
> > > > > > > > clocks in
> > > > > > > > the modules, they cannot be accessed from outside. Does it
> > > > > > > > make sense
> > > > > > > > to register them with the clock framework?
> > > > > > >
> > > > > > > Given we already have a common way of describing clocks, I think
> > > > > > > it
> > > > > > > makes sense to use it -- people
[RFC] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho
---
Hi,
I came up with this code, trying to make the WiLink clocks definitions
as generic as possible and use existing fixed-clock bindings. This
looks relatively clean to me, even though it adds some complexity.
But I think it's better than the original bindings I had defined.
I still need to take care of the XTAL/not-XTAl boolean, but I will do
that separately.
This patch will be split (to take away the Panda DTS part) and
squashed in other patches in my series.
Please let me know what you think.
--
Cheers,
Luca.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ---
drivers/net/wireless/ti/wlcore/sdio.c | 43 ++---
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 670c3ce..7f061b8 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -65,11 +65,19 @@
enable-active-high;
};
+
wlan {
-compatible = "ti,wilink6";
-interrupt-parent = <&gpio2>;
-interrupts = <21 0x4>; /* gpio line 53, high level triggered */
-refclock = <2>;/* 38.4 MHz */
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 0x4>; /* gpio line 53, high level triggered */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ };
};
};
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 5b08620..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -52,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -214,10 +216,16 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = "ti,wilink-clock" },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
+ struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,11 +249,28 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
- of_property_read_u32(np, "refclock", &pdata->ref_clock_freq);
+ glue->refclock = of_clk_get_by_name(np, "refclock");
+ if (IS_ERR(glue->refclock)) {
+ dev_err(dev, "couldn't find refclock on the device tree\n");
+ glue->refclock = NULL;
+ } else {
+ clk_prepare_enable(glue->refclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+ }
/* TODO: make sure we have this when needed (ie. for WL7) */
- of_property_read_u32(np, "tcxoclock", &pdata->tcxo_clock_freq);
+ glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+ if (IS_ERR(glue->tcxoclock)) {
+ dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+ glue->tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue->tcxoclock);
+
Re: [RFC] wlcore: sdio: add wilink clock providers
On Mon, 2013-07-01 at 23:46 +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 670c3ce..7f061b8 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -65,11 +65,19 @@
> > enable-active-high;
> > };
> >
> > +
> > wlan {
> > -compatible = "ti,wilink6";
> > -interrupt-parent = <&gpio2>;
> > -interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > -refclock = <2>;/* 38.4 MHz */
> > + compatible = "ti,wilink6";
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > + clocks = <&refclock>;
> > + clock-names = "refclock";
>
> hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
> explicitly here ?
No, not needed for Panda. Panda uses WiLink6 and only the refclock
needs to be provided.
> Also, you should probably make it clear that the WiLink module is fed by
> the 32K sync clock just to make sure clock usecounts are correctly
> incremented ?
Hmmm, yes, that is probably a good idea. At least to make sure
everything is initialized properly before the WiLink module is up and
running. I'll look into it and eventually add in a separate patch.
Thanks for your comments!
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/9] wlcore: remove pwr_in_suspend from platform data
The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure. Move it to the platform device data that
is passed from SDIO to wlcore.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wlcore/main.c |2 +-
drivers/net/wireless/ti/wlcore/sdio.c |2 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h |1 +
include/linux/wl12xx.h|1 -
4 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index e7294b8..d306cd5 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5941,7 +5941,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
if (!ret) {
wl->irq_wake_enabled = true;
device_init_wakeup(wl->dev, 1);
- if (pdata->pwr_in_suspend)
+ if (pdev_data->pwr_in_suspend)
wl->hw->wiphy->wowlan = &wlcore_wowlan_support;
}
#endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
if (mmcflags & MMC_PM_KEEP_POWER)
- pdev_data->pdata->pwr_in_suspend = true;
+ pdev_data->pwr_in_suspend = true;
sdio_set_drvdata(func, glue);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
struct wlcore_platdev_data {
struct wl12xx_platform_data *pdata;
struct wl1271_if_operations *if_ops;
+ bool pwr_in_suspend;
};
#define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 04e3096..1e4ed6e 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -60,7 +60,6 @@ struct wl12xx_platform_data {
unsigned long irq_flags;
int board_ref_clock;
int board_tcxo_clock;
- bool pwr_in_suspend;
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/9] wilink: add device tree support
Hi, This is a follow-up on a previous patch set that had a smaller audience. This time, I added the lists and people who were involved in the review of the bindings documentation, since most of my changes in v2 are coming from discussions there. This patch series adds device tree support to the wlcore_sdio driver, which is used by WiLink6, WiLink7 and WiLink8. The first patches do some clean-up to make the data needed in the wilink device tree node smaller. The remaining patches implement the actual device tree node parsing in wlcore_sdio. I still need to figure out how to add the information about whether the clocks are XTAL or not. I'll send it in a separate patche set. The DTS file changes will be sent separately, since they need to go via different trees. The bindings documentation patch will also be updated and sent separately, once the XTAL issue is solved. Tony has acked some of the patches that touch OMAP areas. I still need one more ack to a new patch I added (wl12xx: use frequency instead of enumerations for pdata clocks). Sekhar, can you please check the patches that touch the davinci board file and ack them? Changes in v2: * New clean-up patch (4/9); * Patch 6/9 (previously patch 5/5) now doesn't add the clock parsing, since it became more complicated and I added separate patches for that; * 3 new patches (from 7/9 till 9/9) to handle the clock reading in the device tree; Please review. -- Cheers, Luca. Luciano Coelho (9): wl1251: split wl251 platform data to a separate structure wlcore: use irq_flags in pdata instead of hiding it behind a quirk wlcore: remove pwr_in_suspend from platform data wl12xx: use frequency instead of enumerations for pdata clocks wlcore: always use one-shot IRQ wlcore: add initial device tree support to the sdio module wlcore: sdio: add wilink clock providers wlcore: sdio: get clocks from device tree wlcore/wl12xx: check if we got correct clock data from DT arch/arm/mach-davinci/board-da850-evm.c|5 +- arch/arm/mach-omap2/board-4430sdp.c|6 +- arch/arm/mach-omap2/board-omap3evm.c |4 +- arch/arm/mach-omap2/board-omap3pandora.c |4 +- arch/arm/mach-omap2/board-omap4panda.c |4 +- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |4 +- drivers/net/wireless/ti/wilink_platform_data.c | 37 ++-- drivers/net/wireless/ti/wl1251/sdio.c | 12 +-- drivers/net/wireless/ti/wl1251/spi.c |2 +- drivers/net/wireless/ti/wl12xx/main.c | 78 +++-- drivers/net/wireless/ti/wl12xx/wl12xx.h| 28 ++ drivers/net/wireless/ti/wlcore/debugfs.c |2 +- drivers/net/wireless/ti/wlcore/main.c | 16 ++-- drivers/net/wireless/ti/wlcore/sdio.c | 112 ++-- drivers/net/wireless/ti/wlcore/wlcore.h|5 +- drivers/net/wireless/ti/wlcore/wlcore_i.h |1 + include/linux/wl12xx.h | 54 ++-- 18 files changed, 295 insertions(+), 81 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/9] wl1251: split wl251 platform data to a separate structure
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Cc: Tony Lindgren
Signed-off-by: Luciano Coelho
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-omap3pandora.c |4 +--
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37
drivers/net/wireless/ti/wl1251/sdio.c | 12
drivers/net/wireless/ti/wl1251/spi.c |2 +-
include/linux/wl12xx.h | 22 +-
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 28133d5..bf06d95 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -540,7 +540,7 @@ static struct spi_board_info omap3pandora_spi_board_info[]
__initdata = {
static void __init pandora_wl1251_init(void)
{
- struct wl12xx_platform_data pandora_wl1251_pdata;
+ struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -554,7 +554,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
+ ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
if (ret < 0)
goto fail_irq;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 18ca61e..733f3f2 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
};
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c
b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
#include
#include
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
- if (platform_data)
+ if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
- platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!platform_data)
+ wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl12xx_platform_data)
return -ENOMEM;
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct
wl12xx_platform_data *data)
struct wl12xx_platform_data *wl12xx_get_platform_data(void)
{
- if (!platform_data)
+ if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
- return platform_data;
+ return wl12xx_platform_data;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ if (wl1251_platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl1251_platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ if (!wl1251_platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c
b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
- const struct wl12xx_platform_data *wl12xx_board_data;
+ const struct wl1251_platform_data *wl1251_board_data;
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl->if_priv = wl_sdio;
wl->if_ops = &wl1251_sdio_ops;
- wl12xx_board_data = wl12xx_get_platform_data();
- if (!IS_ERR(wl12xx_board_data)) {
- wl->set_power = wl12xx_board_data->set_power;
- w
[PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Change all board files to reflect this.
Cc: Tony Lindgren
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
---
arch/arm/mach-davinci/board-da850-evm.c |3 +-
arch/arm/mach-omap2/board-4430sdp.c |5 ++-
arch/arm/mach-omap2/board-omap3evm.c |3 +-
arch/arm/mach-omap2/board-omap4panda.c |3 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-
drivers/net/wireless/ti/wl12xx/main.c| 58 +-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +
include/linux/wl12xx.h | 28 ++---
8 files changed, 99 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d2a2a98..202f3d0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.irq_flags = IRQF_TRIGGER_RISING,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c2334aa..da2b892 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -694,8 +694,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_26,
- .board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
+ .tcxo_clock_freq = 2600,
};
static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a0c0adf..d24435c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -459,7 +459,8 @@ static struct platform_device omap3evm_wlan_regulator = {
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index ba00862..ac6413c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -231,7 +231,8 @@ static struct platform_device omap_vwlan_device = {
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index ced012c..f4f4fe7 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -245,7 +245,8 @@ static struct platform_device *zoom_devices[] __initdata = {
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..903dcb3 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static struct wl12xx_clock wl12xx_refclock_table[] = {
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+ { 16368000, false, WL12XX_TCXOCLOCK_16_368 },
+ { 1680, false, WL12XX_TCXOCLOCK_16_8 },
+ { 1920, false, WL12XX_TCXOCLOCK_19_2 },
+ { 2600, false, WL12XX_TCXOCLOCK_26
[PATCH v2 5/9] wlcore: always use one-shot IRQ
Since we are now using threaded IRQs without the primary handler, we need to set IRQF_ONESHOT, otherwise our request will fail. Signed-off-by: Luciano Coelho --- drivers/net/wireless/ti/wlcore/main.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c index d306cd5..bc1cff3 100644 --- a/drivers/net/wireless/ti/wlcore/main.c +++ b/drivers/net/wireless/ti/wlcore/main.c @@ -5927,7 +5927,8 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context) wl->irq = platform_get_irq(pdev, 0); wl->if_ops = pdev_data->if_ops; - wl->irq_flags = pdata->irq_flags; + /* Since we don't use the primary handler, we must set ONESHOT */ + wl->irq_flags = pdata->irq_flags | IRQF_ONESHOT; ret = request_threaded_irq(wl->irq, NULL, wlcore_irq, wl->irq_flags, pdev->name, wl); -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 6/9] wlcore: add initial device tree support to the sdio module
If platform data is not available, try to get the required information
from the device tree. Register an OF match table and parse the
appropriate device tree nodes.
Parse interrupt property only, for now.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wlcore/sdio.c | 69 ++---
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
+{
+ struct wl12xx_platform_data *pdata;
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ np = of_find_matching_node(NULL, dev->driver->of_match_table);
+ if (!np) {
+ dev_notice(dev, "device tree node not available\n");
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, "can't allocate platform data\n");
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+
+ pdata->irq = irq_of_parse_and_map(np, 0);
+ if (pdata->irq < 0) {
+ dev_err(dev, "can't get interrupt gpio from the device tree\n");
+ goto out_free;
+ }
+
+ goto out;
+
+out_free:
+ kfree(pdata);
+ pdata = ERR_PTR(-ENODEV);
+
+out:
+ return pdata;
+}
+
static int wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ /* The pdata allocated here is freed when the device is freed,
+* so we don't need an additional out label to free it in case
+* of error further on.
+*/
+
+ /* Try to get legacy platform data from the board file */
pdev_data->pdata = wl12xx_get_platform_data();
if (IS_ERR(pdev_data->pdata)) {
- ret = PTR_ERR(pdev_data->pdata);
- dev_err(glue->dev, "missing wlan platform data: %d\n", ret);
- goto out_free_glue;
+ dev_info(&func->dev,
+"legacy platform data not found, trying device
tree\n");
+
+ pdev_data->pdata = wlcore_get_pdata_from_of(&func->dev);
+ if (IS_ERR(pdev_data->pdata)) {
+ dev_err(&func->dev, "can't get platform data\n");
+ goto out_free_glue;
+ }
}
/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
};
#endif
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+ { .compatible = "ti,wilink6" },
+ { .compatible = "ti,wilink7" },
+ { .compatible = "ti,wilink8" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
static struct sdio_driver wl1271_sdio_driver = {
.name = "wl1271_sdio",
.id_table = wl1271_devices,
.probe = wl1271_probe,
.remove = wl1271_remove,
-#ifdef CONFIG_PM
.drv = {
+#ifdef CONFIG_PM
.pm = &wl1271_sdio_pm_ops,
- },
#endif
+ .of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+ },
};
static int __init wl1271_init(void)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding it behind a quirk
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, export the
whole irq_flags element and let the board file define what to use.
This will be more meaningful than driver-specific quirks when we
switch to DT.
Cc: Tony Lindgren
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
Acked-by: Tony Lindgren
---
arch/arm/mach-davinci/board-da850-evm.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap4panda.c |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
drivers/net/wireless/ti/wlcore/main.c| 13 +++--
drivers/net/wireless/ti/wlcore/wlcore.h |5 ++---
include/linux/wl12xx.h |5 +
9 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..d2a2a98 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
+ .irq_flags = IRQF_TRIGGER_RISING,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..c2334aa 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_26,
.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
};
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..a0c0adf 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -458,6 +458,7 @@ static struct platform_device omap3evm_wlan_regulator = {
};
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1e2c75e..ba00862 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,6 +230,7 @@ static struct platform_device omap_vwlan_device = {
};
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..ced012c 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,6 +244,7 @@ static struct platform_device *zoom_devices[] __initdata = {
};
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
};
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c
b/drivers/net/wireless/ti/wlcore/debugfs.c
index c3e1f79..5eff663 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -486,7 +486,7 @@ static ssize_t driver_state_read(struct file *file, char
__user *user_buf,
DRIVER_STATE_PRINT_HEX(irq);
/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
DRIVER_STATE_PRINT_HEX(hw_pg_ver);
- DRIVER_STATE_PRINT_HEX(platform_quirks);
+ DRIVER_STATE_PRINT_HEX(irq_flags);
DRIVER_STATE_PRINT_HEX(chip.id);
DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index b8db55c..e7294b8 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -516,7 +516,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
* In case edge triggered interrupt must be used, we cannot iterate
* more than once without introducing race conditions with the hardirq.
*/
- if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+ if (wl->irq_flags & IRQF_
[PATCH v2 8/9] wlcore: sdio: get clocks from device tree
Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wlcore/sdio.c | 36 +++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
+ /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+ glue->refclock = of_clk_get_by_name(np, "refclock");
+ if (IS_ERR(glue->refclock)) {
+ dev_err(dev, "couldn't find refclock on the device tree\n");
+ glue->refclock = NULL;
+ } else {
+ clk_prepare_enable(glue->refclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+ }
+
+ /* TODO: make sure we have this when needed (ie. for WL7) */
+ glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+ if (IS_ERR(glue->tcxoclock)) {
+ dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+ glue->tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue->tcxoclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+ }
+
goto out;
out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ sdio_set_drvdata(func, glue);
+
/* The pdata allocated here is freed when the device is freed,
* so we don't need an additional out label to free it in case
* of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
if (mmcflags & MMC_PM_KEEP_POWER)
pdev_data->pwr_in_suspend = true;
- sdio_set_drvdata(func, glue);
-
/* Tell PM core that we don't need the card to be powered now */
pm_runtime_put_noidle(&func->dev);
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
{
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+ if (glue->refclock) {
+ clk_disable_unprepare(glue->refclock);
+ clk_put(glue->refclock);
+ }
+
+ if (glue->tcxoclock) {
+ clk_disable_unprepare(glue->tcxoclock);
+ clk_put(glue->tcxoclock);
+ }
+
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(&func->dev);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 9/9] wlcore/wl12xx: check if we got correct clock data from DT
The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values. WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error. WiLink7 needs both clocks, if either is not available we
return with an error.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wl12xx/main.c | 20 +---
drivers/net/wireless/ti/wlcore/sdio.c |4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 903dcb3..72d13e4 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int
*selected_clock)
u16 sys_clk_cfg;
int ret;
+ if ((priv->ref_clock < 0) || (priv->tcxo_clock < 0)) {
+ wl1271_error("Missing fref and/or tcxo clock settings\n");
+ return -EINVAL;
+ }
+
/* For XTAL-only modes, FREF will be used after switching from TCXO */
if (priv->ref_clock == WL12XX_REFCLOCK_26_XTAL ||
priv->ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
u32 clk;
int ret;
+ if (priv->ref_clock < 0) {
+ wl1271_error("Missing fref clock settings\n");
+ return -EINVAL;
+ }
+
if (WL127X_PG_GET_MAJOR(wl->hw_pg_ver) < 3)
wl->quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
@@ -1757,7 +1767,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, &wl12xx_ht_cap);
wl12xx_conf_init(wl);
- if (!fref_param) {
+ if (!fref_param && (pdata->ref_clock_freq > 0)) {
priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
pdata->ref_clock_freq,
pdata->ref_clock_xtal);
@@ -1768,6 +1778,8 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv->ref_clock;
}
+ } else if (!fref_param) {
+ priv->ref_clock = -EINVAL;
} else {
if (!strcmp(fref_param, "19.2"))
priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1785,7 +1797,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wl1271_error("Invalid fref parameter %s", fref_param);
}
- if (!tcxo_param) {
+ if (!fref_param && (pdata->tcxo_clock_freq > 0)) {
priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
pdata->tcxo_clock_freq,
pdata->tcxo_clock_xtal);
@@ -1796,7 +1808,9 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv->tcxo_clock;
}
- } else {
+ } else if (!fref_param) {
+ priv->tcxo_clock = -EINVAL;
+ }else {
if (!strcmp(tcxo_param, "19.2"))
priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
else if (!strcmp(tcxo_param, "26"))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
- /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
glue->refclock = of_clk_get_by_name(np, "refclock");
if (IS_ERR(glue->refclock)) {
- dev_err(dev, "couldn't find refclock on the device tree\n");
glue->refclock = NULL;
} else {
clk_prepare_enable(glue->refclock);
pdata->ref_clock_freq = clk_get_rate(glue->refclock);
}
- /* TODO: make sure we have this when needed (ie. for WL7) */
glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
if (IS_ERR(glue->tcxoclock)) {
- dev_err(dev, "couldn't find tcxoclock on the device tree\n");
glue->tcxoclock = NULL;
} else {
clk_prepare_enable(glue->tcxoclock);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 7/9] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wlcore/sdio.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = "ti,wilink-clock" },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
+ struct device_node *clock_node;
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
goto out;
out_free:
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding it behind a quirk
On Tue, 2013-07-02 at 18:26 +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 02, 2013 at 05:55:41PM +0300, Luciano Coelho wrote:
> > The platform_quirk element in the platform data was used to change the
> > way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
> > the irqflags used and treat edge trigger differently from the rest.
> >
> > Instead of hiding this irq flag setting behind the quirk, export the
> > whole irq_flags element and let the board file define what to use.
> > This will be more meaningful than driver-specific quirks when we
> > switch to DT.
> >
> > Cc: Tony Lindgren
> > Cc: Sekhar Nori
> > Signed-off-by: Luciano Coelho
> > Acked-by: Tony Lindgren
> > ---
> > arch/arm/mach-davinci/board-da850-evm.c |2 +-
> > arch/arm/mach-omap2/board-4430sdp.c |1 +
> > arch/arm/mach-omap2/board-omap3evm.c |1 +
> > arch/arm/mach-omap2/board-omap4panda.c |1 +
> > arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
> > drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
> > drivers/net/wireless/ti/wlcore/main.c| 13 +++--
> > drivers/net/wireless/ti/wlcore/wlcore.h |5 ++---
> > include/linux/wl12xx.h |5 +
> > 9 files changed, 12 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c
> > b/arch/arm/mach-davinci/board-da850-evm.c
> > index 8a24b6c..d2a2a98 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
> >
> > static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
> > .irq= -1,
> > + .irq_flags = IRQF_TRIGGER_RISING,
> > .board_ref_clock= WL12XX_REFCLOCK_38,
> > - .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
> > };
> >
> > static __init int da850_wl12xx_init(void)
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> > b/arch/arm/mach-omap2/board-4430sdp.c
> > index 56a9a4f..c2334aa 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
> > }
> >
> > static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
> > + .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>
> couldn't you just call irq_set_irq_type() from the board-file itself ?
> Then on your driver you can just pass IRQF_ONESHOT (to make sure heh) to
> your request_threaded_irq_handler()
Good point. This is an oldish patch from the time I still thought I'd
have to pass the flags in the device tree. It turned out that I don't
need it anymore, so this can be totally removed from pdata and be set by
the board file itself.
As you saw in a later patch, I do make sure the driver sets
IRQF_ONESHOT. ;)
--
Cheers,
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
On Tue, 2013-07-02 at 18:31 +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 02, 2013 at 05:55:43PM +0300, Luciano Coelho wrote:
> > diff --git a/drivers/net/wireless/ti/wl12xx/main.c
> > b/drivers/net/wireless/ti/wl12xx/main.c
> > index 1c627da..903dcb3 100644
> > --- a/drivers/net/wireless/ti/wl12xx/main.c
> > +++ b/drivers/net/wireless/ti/wl12xx/main.c
> > @@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
> > },
> > };
> >
> > +static struct wl12xx_clock wl12xx_refclock_table[] = {
>
> const
>
> > + { 1920, false, WL12XX_REFCLOCK_19 },
> > + { 2600, false, WL12XX_REFCLOCK_26 },
> > + { 2600, true, WL12XX_REFCLOCK_26_XTAL },
> > + { 3840, false, WL12XX_REFCLOCK_38 },
> > + { 3840, true, WL12XX_REFCLOCK_38_XTAL },
> > + { 5200, false, WL12XX_REFCLOCK_52 },
> > + { 0,false, 0 }
> > +};
> > +
> > +static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
>
> const
Duh! Thanks for noticing it.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/9] wlcore: always use one-shot IRQ
On Tue, 2013-07-02 at 18:32 +0300, Felipe Balbi wrote: > On Tue, Jul 02, 2013 at 05:55:44PM +0300, Luciano Coelho wrote: > > Since we are now using threaded IRQs without the primary handler, we > > need to set IRQF_ONESHOT, otherwise our request will fail. > > > > Signed-off-by: Luciano Coelho > > good to see this happening, I remember we talked about this a while back > :-) Yeah, we talked about it and I did the patch immediately. This is needed because this is obviously not set automatically in the interrupts created via device tree. > Acked-by: Felipe Balbi > > Still, if you call irq_set_irq_type() on board-file (since DT will do > something similar for you anyway) then you can completely drop > irq_flags. Yep. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote: > Hi, > > On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote: > > @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func, > > /* Use block mode for transferring over one block size of data */ > > func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE; > > > > + sdio_set_drvdata(func, glue); > > is this move really necessary ? It is, because I use the glue in wlcore_get_pdata_from_of(), so I need to call sdio_set_drvdata() earlier. I reckoned it wouldn't hurt to move this, so I wouldn't have to pass the glue in the wlcore_get_pdata_from_of() call. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote: > On 17:55-20130702, Luciano Coelho wrote: > > Instead of defining an enumeration with the FW specific values for the > > different clock rates, use the actual frequency instead. Also add a > > boolean to specify whether the clock is XTAL or not. > > > > Change all board files to reflect this. > > > > Cc: Tony Lindgren > > Cc: Sekhar Nori > > Signed-off-by: Luciano Coelho > > --- > > arch/arm/mach-davinci/board-da850-evm.c |3 +- > > arch/arm/mach-omap2/board-4430sdp.c |5 ++- > ^^ > > arch/arm/mach-omap2/board-omap3evm.c |3 +- > > arch/arm/mach-omap2/board-omap4panda.c |3 +- > ^^ > Please do not add more platform data to platforms that are DT only. Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had been removed in linux-next. I base my tree on wireless-next and it doesn't contain these changes yet. I would only have noticed this when I rebased my tree once the merge window is closed. ;) Thanks for pointing out, I'll make sure these changes will not be there when I send the pull request. -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
On Wed, 2013-07-03 at 00:32 +0300, Felipe Balbi wrote: > On Tue, Jul 02, 2013 at 11:19:54PM +0300, Luciano Coelho wrote: > > On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote: > > > Hi, > > > > > > On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote: > > > > @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func, > > > > /* Use block mode for transferring over one block size of data > > > > */ > > > > func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE; > > > > > > > > + sdio_set_drvdata(func, glue); > > > > > > is this move really necessary ? > > > > It is, because I use the glue in wlcore_get_pdata_from_of(), so I need > > to call sdio_set_drvdata() earlier. I reckoned it wouldn't hurt to move > > this, so I wouldn't have to pass the glue in the > > wlcore_get_pdata_from_of() call. > > that's alright, it does look like it deserves a mention in changelog > though. Other than that: Uh, ok. This was so tiny (and I thought so obvious) a change that I didn't mention it. But if you asked about it, it was not obvious enough. ;) I'll add a small comment about it in the commit message. > Reviewed-by: Felipe Balbi Thanks! -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
On Wed, 2013-07-03 at 04:33 -0700, Tony Lindgren wrote: > * Luciano Coelho [130702 13:33]: > > On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote: > > > On 17:55-20130702, Luciano Coelho wrote: > > > > Instead of defining an enumeration with the FW specific values for the > > > > different clock rates, use the actual frequency instead. Also add a > > > > boolean to specify whether the clock is XTAL or not. > > > > > > > > Change all board files to reflect this. > > > > > > > > Cc: Tony Lindgren > > > > Cc: Sekhar Nori > > > > Signed-off-by: Luciano Coelho > > > > --- > > > > arch/arm/mach-davinci/board-da850-evm.c |3 +- > > > > arch/arm/mach-omap2/board-4430sdp.c |5 ++- > > > ^^ > > > > arch/arm/mach-omap2/board-omap3evm.c |3 +- > > > > arch/arm/mach-omap2/board-omap4panda.c |3 +- > > > ^^ > > > Please do not add more platform data to platforms that are DT only. > > > > Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had > > been removed in linux-next. I base my tree on wireless-next and it > > doesn't contain these changes yet. I would only have noticed this when > > I rebased my tree once the merge window is closed. ;) > > > > Thanks for pointing out, I'll make sure these changes will not be there > > when I send the pull request. > > Please separate out the minimal pdata and arch/arm/mach-omap2 changes int > a immutable branch on v3.11-rc1 that I can also pull in. For v3.12, we're > going to be making more boards device tree only, so these changes may > otherwise cause pointless merge conflicts. Okay. I don't want to freeze my work, I'll continue using my wireless-based tree (which is based on 3.10) for now. When the merge window closes, I'll reorganize all this before sending pull requests, so we can avoid conflicts. Please ignore my changes to board files that will disappear on 3.11 and keep reviewing the rest. ;) -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/9] wilink: add device tree support
On Wed, 2013-07-03 at 13:13 +0300, Grazvydas Ignotas wrote: > Hi, Hi Gražvydas, > On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho wrote: > > Hi, > > > > This is a follow-up on a previous patch set that had a smaller > > audience. This time, I added the lists and people who were involved > > in the review of the bindings documentation, since most of my changes > > in v2 are coming from discussions there. > > > > This patch series adds device tree support to the wlcore_sdio driver, > > which is used by WiLink6, WiLink7 and WiLink8. > > Could you perhaps consider doing device tree conversion for wl1251 > too? With the knowledge you have from working on this series, it would > be much easier for you to do it than for someone else, and I don't > have much hope someone will do it at all. It's WiLink series chip > after all. Without this pandora and N900 are going to lose wifi > support after the switch to dt-only kernel. Unfortunately I don't have much time to work on wl1251. I think it wouldn't be too difficult to do though, so patches are welcome. ;) Maybe you could try to make this change and I could support you if needed? > I can offer you my help testing things on pandora and I'm sure someone > here could try it on N900. I could try it on the N900, if it is still bootable easily with the mainline. ;) -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/8] wilink: add device tree support
Hi, This patch series adds device tree support to the wlcore_sdio driver, which is used by WiLink6, WiLink7 and WiLink8. The first patches do some clean-up to make the data needed in the wilink device tree node smaller. The remaining patches implement the actual device tree node parsing in wlcore_sdio. I still need to figure out how to add the information about whether the clocks are XTAL or not. I'll send it in a separate patche set. The DTS file changes will be sent separately, since they need to go via different trees. The bindings documentation patch will also be updated and sent separately, once the XTAL issue is solved. Changes in v3: * Remove irq_flags from pdata and handle them in the board files. This caused the "wlcore: use irq_flags in pdata instead of hiding it behind a quirk" (now 2/8) to be changed considerably, so I removed the Acked-by from Tony. I also added calls to gpio_request_one() for the WiLink IRQ GPIO that were missing in the board files (thanks Felipe); * Added "const" to the frequency tables in patch 4/8 (thanks Felipe); * Squashed patch 5/9 into the new 2/8; * Added comment about the sdio_set_drvdata() call move in 7/8 (thanks Felipe); * I'm still modifying the panda and 4430sdp board files that are going to be removed in 3.11. Please ignore the changes I made there, I just wanted to make sure they still work with my current tree. Once the 3.11 merge window close, I'll do the relevant merges before I send pull requests (thanks Tony and Nishant). Please review. -- Cheers, Luca. Luciano Coelho (8): wl1251: split wl251 platform data to a separate structure wlcore: set irq_flags in the board files instead of hiding behind a quirk wlcore: remove pwr_in_suspend from platform data wl12xx: use frequency instead of enumerations for pdata clocks wlcore: add initial device tree support to the sdio module wlcore: sdio: add wilink clock providers wlcore: sdio: get clocks from device tree wlcore/wl12xx: check if we got correct clock data from DT arch/arm/mach-davinci/board-da850-evm.c| 11 ++- arch/arm/mach-omap2/board-4430sdp.c| 23 - arch/arm/mach-omap2/board-omap3evm.c | 22 - arch/arm/mach-omap2/board-omap3pandora.c |4 +- arch/arm/mach-omap2/board-omap4panda.c | 39 +++-- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 33 ++- drivers/net/wireless/ti/wilink_platform_data.c | 37 ++-- drivers/net/wireless/ti/wl1251/sdio.c | 12 +-- drivers/net/wireless/ti/wl1251/spi.c |2 +- drivers/net/wireless/ti/wl12xx/main.c | 77 ++-- drivers/net/wireless/ti/wl12xx/wl12xx.h| 28 ++ drivers/net/wireless/ti/wlcore/debugfs.c |2 +- drivers/net/wireless/ti/wlcore/main.c | 26 +++--- drivers/net/wireless/ti/wlcore/sdio.c | 112 ++-- drivers/net/wireless/ti/wlcore/wlcore.h|5 +- drivers/net/wireless/ti/wlcore/wlcore_i.h |1 + include/linux/wl12xx.h | 52 +-- 18 files changed, 398 insertions(+), 90 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
---
arch/arm/mach-davinci/board-da850-evm.c |8 +-
arch/arm/mach-omap2/board-4430sdp.c | 18 +
arch/arm/mach-omap2/board-omap3evm.c | 19 ++
arch/arm/mach-omap2/board-omap4panda.c | 36 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 30 ++---
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
drivers/net/wireless/ti/wlcore/main.c| 24 ++---
drivers/net/wireless/ti/wlcore/wlcore.h |5 ++--
include/linux/wl12xx.h |4 ---
9 files changed, 118 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..544b6fa 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,6 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
@@ -1409,6 +1408,13 @@ static __init int da850_wl12xx_init(void)
goto free_wlan_en;
}
+ ret = irq_set_irq_type(gpio_to_irq(DA850_WLAN_IRQ),
+ IRQ_TYPE_EDGE_RISING);
+ if (ret) {
+ pr_err("Could not set wl12xx irq type: %d\n", ret);
+ goto free;
+ }
+
da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
ret = wl12xx_set_platform_data(&da850_wl12xx_wlan_data);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..953f620 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
omap4_sdp4430_wifi_mux_init();
omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
+ if (ret) {
+ pr_err("error requesting wl12xx gpio: %d\n", ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err("error setting wl12xx irq type: %d\n", ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
if (ret)
pr_err("Error setting wl12xx data: %d\n", ret);
+
ret = platform_device_register(&omap_vwlan_device);
if (ret)
pr_err("Error registering wl12xx device: %d\n", ret);
+out:
+ return;
+free:
+ gpio_free(GPIO_WIFI_IRQ);
}
static void __init omap_4430sdp_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..8abce3cd 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -612,12 +612,31 @@ static void __init omap3_evm_wl12xx_init(void)
/* WL12xx WLAN Init */
omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
+
+ ret = gpio_request_one(OMAP3EVM_WLAN_IRQ_GPIO, GPIOF_IN,
+ "OMAP3EVM_WLAN_IRQ_GPIO");
+ if (ret) {
+ pr_err("error requesting wl12xx gpio: %d\n", ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO),
+ IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err("error setting wl12xx irq type: %d\n", ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(&omap3evm_wlan_data);
if (ret)
pr_err("error setting wl12xx data: %d\n", ret);
ret = platform_device_register(&omap3evm_wlan_regulator);
if (ret)
pr_err("error registering wl12xx device: %d\n", ret);
+out:
+ return;
+free:
+ gpio_free(OMAP3EVM_WLAN_IRQ_GPIO);
#endif
}
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1e2c75e..5b33626
[PATCH v3 1/8] wl1251: split wl251 platform data to a separate structure
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Cc: Tony Lindgren
Signed-off-by: Luciano Coelho
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-omap3pandora.c |4 +--
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37
drivers/net/wireless/ti/wl1251/sdio.c | 12
drivers/net/wireless/ti/wl1251/spi.c |2 +-
include/linux/wl12xx.h | 22 +-
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 28133d5..bf06d95 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -540,7 +540,7 @@ static struct spi_board_info omap3pandora_spi_board_info[]
__initdata = {
static void __init pandora_wl1251_init(void)
{
- struct wl12xx_platform_data pandora_wl1251_pdata;
+ struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -554,7 +554,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
+ ret = wl1251_set_platform_data(&pandora_wl1251_pdata);
if (ret < 0)
goto fail_irq;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 18ca61e..733f3f2 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
};
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c
b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
#include
#include
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
- if (platform_data)
+ if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
- platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!platform_data)
+ wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl12xx_platform_data)
return -ENOMEM;
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct
wl12xx_platform_data *data)
struct wl12xx_platform_data *wl12xx_get_platform_data(void)
{
- if (!platform_data)
+ if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
- return platform_data;
+ return wl12xx_platform_data;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ if (wl1251_platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl1251_platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ if (!wl1251_platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c
b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
- const struct wl12xx_platform_data *wl12xx_board_data;
+ const struct wl1251_platform_data *wl1251_board_data;
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl->if_priv = wl_sdio;
wl->if_ops = &wl1251_sdio_ops;
- wl12xx_board_data = wl12xx_get_platform_data();
- if (!IS_ERR(wl12xx_board_data)) {
- wl->set_power = wl12xx_board_data->set_power;
- w
[PATCH v3 5/8] wlcore: add initial device tree support to the sdio module
If platform data is not available, try to get the required information
from the device tree. Register an OF match table and parse the
appropriate device tree nodes.
Parse interrupt property only, for now.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wlcore/sdio.c | 69 ++---
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
+{
+ struct wl12xx_platform_data *pdata;
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ np = of_find_matching_node(NULL, dev->driver->of_match_table);
+ if (!np) {
+ dev_notice(dev, "device tree node not available\n");
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, "can't allocate platform data\n");
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+
+ pdata->irq = irq_of_parse_and_map(np, 0);
+ if (pdata->irq < 0) {
+ dev_err(dev, "can't get interrupt gpio from the device tree\n");
+ goto out_free;
+ }
+
+ goto out;
+
+out_free:
+ kfree(pdata);
+ pdata = ERR_PTR(-ENODEV);
+
+out:
+ return pdata;
+}
+
static int wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ /* The pdata allocated here is freed when the device is freed,
+* so we don't need an additional out label to free it in case
+* of error further on.
+*/
+
+ /* Try to get legacy platform data from the board file */
pdev_data->pdata = wl12xx_get_platform_data();
if (IS_ERR(pdev_data->pdata)) {
- ret = PTR_ERR(pdev_data->pdata);
- dev_err(glue->dev, "missing wlan platform data: %d\n", ret);
- goto out_free_glue;
+ dev_info(&func->dev,
+"legacy platform data not found, trying device
tree\n");
+
+ pdev_data->pdata = wlcore_get_pdata_from_of(&func->dev);
+ if (IS_ERR(pdev_data->pdata)) {
+ dev_err(&func->dev, "can't get platform data\n");
+ goto out_free_glue;
+ }
}
/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
};
#endif
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+ { .compatible = "ti,wilink6" },
+ { .compatible = "ti,wilink7" },
+ { .compatible = "ti,wilink8" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
static struct sdio_driver wl1271_sdio_driver = {
.name = "wl1271_sdio",
.id_table = wl1271_devices,
.probe = wl1271_probe,
.remove = wl1271_remove,
-#ifdef CONFIG_PM
.drv = {
+#ifdef CONFIG_PM
.pm = &wl1271_sdio_pm_ops,
- },
#endif
+ .of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+ },
};
static int __init wl1271_init(void)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 4/8] wl12xx: use frequency instead of enumerations for pdata clocks
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Change all board files to reflect this.
Cc: Tony Lindgren
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
---
arch/arm/mach-davinci/board-da850-evm.c |3 +-
arch/arm/mach-omap2/board-4430sdp.c |5 ++-
arch/arm/mach-omap2/board-omap3evm.c |3 +-
arch/arm/mach-omap2/board-omap4panda.c |3 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-
drivers/net/wireless/ti/wl12xx/main.c| 57 +-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +
include/linux/wl12xx.h | 27 ++--
8 files changed, 97 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 544b6fa..eddced8 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,7 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 953f620..0d3cb10 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,8 +693,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_26,
- .board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
+ .tcxo_clock_freq = 2600,
};
static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8abce3cd..8f953ed 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -458,7 +458,8 @@ static struct platform_device omap3evm_wlan_regulator = {
};
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5b33626..b90fd4c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,7 +230,8 @@ static struct platform_device omap_vwlan_device = {
};
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 4f84cf9..83a9a36 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,7 +244,8 @@ static struct platform_device *zoom_devices[] __initdata = {
};
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..216c2fd 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static const struct wl12xx_clock wl12xx_refclock_table[] = {
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static const struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+ { 16368000, true, WL12XX_TCXOCLOCK_16_368 },
+ { 1680, true, WL12XX_TCXOCLOCK_16_8 },
+ { 1920, true, WL12XX_TCXOCLOCK_19_2 },
+ { 2600, true, WL12XX_TCXOCLOCK_26 },
+ { 32736000, true, WL12XX_TCXOCLOCK_32_736 },
+ { 3360, true, WL12XX_TCXOCLOCK_33_6 },
+ { 3840, true, WL12XX_TCXOCLOCK_38_4 },
+ { 5200, true, WL12XX_TCXOCLOCK_52
[PATCH v3 3/8] wlcore: remove pwr_in_suspend from platform data
The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure. Move it to the platform device data that
is passed from SDIO to wlcore.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wlcore/main.c |2 +-
drivers/net/wireless/ti/wlcore/sdio.c |2 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h |1 +
include/linux/wl12xx.h|1 -
4 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 7b5d0cc..aada037 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5952,7 +5952,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
if (!ret) {
wl->irq_wake_enabled = true;
device_init_wakeup(wl->dev, 1);
- if (pdata->pwr_in_suspend)
+ if (pdev_data->pwr_in_suspend)
wl->hw->wiphy->wowlan = &wlcore_wowlan_support;
}
#endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
if (mmcflags & MMC_PM_KEEP_POWER)
- pdev_data->pdata->pwr_in_suspend = true;
+ pdev_data->pwr_in_suspend = true;
sdio_set_drvdata(func, glue);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
struct wlcore_platdev_data {
struct wl12xx_platform_data *pdata;
struct wl1271_if_operations *if_ops;
+ bool pwr_in_suspend;
};
#define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 1bfcd19..ab90b1c 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,7 +59,6 @@ struct wl12xx_platform_data {
int irq;
int board_ref_clock;
int board_tcxo_clock;
- bool pwr_in_suspend;
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 8/8] wlcore/wl12xx: check if we got correct clock data from DT
The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values. WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error. WiLink7 needs both clocks, if either is not available we
return with an error.
Signed-off-by: Luciano Coelho
---
drivers/net/wireless/ti/wl12xx/main.c | 20 +---
drivers/net/wireless/ti/wlcore/sdio.c |4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 216c2fd..1be0b51 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int
*selected_clock)
u16 sys_clk_cfg;
int ret;
+ if ((priv->ref_clock < 0) || (priv->tcxo_clock < 0)) {
+ wl1271_error("Missing fref and/or tcxo clock settings\n");
+ return -EINVAL;
+ }
+
/* For XTAL-only modes, FREF will be used after switching from TCXO */
if (priv->ref_clock == WL12XX_REFCLOCK_26_XTAL ||
priv->ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
u32 clk;
int ret;
+ if (priv->ref_clock < 0) {
+ wl1271_error("Missing fref clock settings\n");
+ return -EINVAL;
+ }
+
if (WL127X_PG_GET_MAJOR(wl->hw_pg_ver) < 3)
wl->quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
@@ -1757,7 +1767,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, &wl12xx_ht_cap);
wl12xx_conf_init(wl);
- if (!fref_param) {
+ if (!fref_param && (pdata->ref_clock_freq > 0)) {
priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
pdata->ref_clock_freq,
pdata->ref_clock_xtal);
@@ -1768,6 +1778,8 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv->ref_clock;
}
+ } else if (!fref_param) {
+ priv->ref_clock = -EINVAL;
} else {
if (!strcmp(fref_param, "19.2"))
priv->ref_clock = WL12XX_REFCLOCK_19;
@@ -1785,7 +1797,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wl1271_error("Invalid fref parameter %s", fref_param);
}
- if (!tcxo_param) {
+ if (!fref_param && (pdata->tcxo_clock_freq > 0)) {
priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
pdata->tcxo_clock_freq,
true);
@@ -1795,7 +1807,9 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv->tcxo_clock;
}
- } else {
+ } else if (!fref_param) {
+ priv->tcxo_clock = -EINVAL;
+ }else {
if (!strcmp(tcxo_param, "19.2"))
priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
else if (!strcmp(tcxo_param, "26"))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
- /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
glue->refclock = of_clk_get_by_name(np, "refclock");
if (IS_ERR(glue->refclock)) {
- dev_err(dev, "couldn't find refclock on the device tree\n");
glue->refclock = NULL;
} else {
clk_prepare_enable(glue->refclock);
pdata->ref_clock_freq = clk_get_rate(glue->refclock);
}
- /* TODO: make sure we have this when needed (ie. for WL7) */
glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
if (IS_ERR(glue->tcxoclock)) {
- dev_err(dev, "couldn't find tcxoclock on the device tree\n");
glue->tcxoclock = NULL;
} else {
clk_prepare_enable(glue->tcxoclock);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 6/8] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho
Reviewed-by: Felipe Balbi
---
drivers/net/wireless/ti/wlcore/sdio.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = "ti,wilink-clock" },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
+ struct device_node *clock_node;
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
goto out;
out_free:
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 7/8] wlcore: sdio: get clocks from device tree
Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.
Also, call sdio_set_drvdata() earlier, so the glue is already set in
the driver data when we call wlcore_get_pdata_from_of() and we don't
need to pass it as a parameter.
Signed-off-by: Luciano Coelho
Reviewed-by: Felipe Balbi
---
drivers/net/wireless/ti/wlcore/sdio.c | 36 +++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
+ /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+ glue->refclock = of_clk_get_by_name(np, "refclock");
+ if (IS_ERR(glue->refclock)) {
+ dev_err(dev, "couldn't find refclock on the device tree\n");
+ glue->refclock = NULL;
+ } else {
+ clk_prepare_enable(glue->refclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+ }
+
+ /* TODO: make sure we have this when needed (ie. for WL7) */
+ glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+ if (IS_ERR(glue->tcxoclock)) {
+ dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+ glue->tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue->tcxoclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+ }
+
goto out;
out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ sdio_set_drvdata(func, glue);
+
/* The pdata allocated here is freed when the device is freed,
* so we don't need an additional out label to free it in case
* of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
if (mmcflags & MMC_PM_KEEP_POWER)
pdev_data->pwr_in_suspend = true;
- sdio_set_drvdata(func, glue);
-
/* Tell PM core that we don't need the card to be powered now */
pm_runtime_put_noidle(&func->dev);
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
{
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+ if (glue->refclock) {
+ clk_disable_unprepare(glue->refclock);
+ clk_put(glue->refclock);
+ }
+
+ if (glue->tcxoclock) {
+ clk_disable_unprepare(glue->tcxoclock);
+ clk_put(glue->tcxoclock);
+ }
+
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(&func->dev);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
> The platform_quirk element in the platform data was used to change the
> way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
> the irqflags used and treat edge trigger differently from the rest.
>
> Instead of hiding this irq flag setting behind the quirk, have the
> board files set the flags during initialization. This will be more
> meaningful than driver-specific quirks when we switch to DT.
>
> Additionally, fix missing gpio_request() calls in the boarding files
> (so that setting the flags actually works).
>
> Cc: Tony Lindgren
> Cc: Sekhar Nori
> Signed-off-by: Luciano Coelho
> ---
[...]
> @@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw,
> void *context)
> wlcore_adjust_conf(wl);
>
> wl->irq = platform_get_irq(pdev, 0);
> - wl->platform_quirks = pdata->platform_quirks;
> wl->if_ops = pdev_data->if_ops;
>
> - if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
> - irqflags = IRQF_TRIGGER_RISING;
> - else
> - irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
> + irq_data = irq_get_irq_data(wl->irq);
> + if (!irq_data) {
> + wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
> + ret = -EINVAL;
> + goto out_free_nvs;
> + }
> +
> + wl->irq_flags = irqd_get_trigger_type(irq_data);
BTW, there seems to be a patch on its way to make reading the flags
easier (ie. no need to get the irq_data first):
http://mid.gmane.org/1367945288-5625-1-git-send-email-jav...@dowhile0.org
I'm not sure if this is going to be taken in, but if it does, it would
be nice to change the code here to use the new irq_get_trigger_type()
function.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, 2013-07-03 at 17:13 +0300, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> > b/arch/arm/mach-omap2/board-4430sdp.c
> > index 56a9a4f..953f620 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
> >
> > omap4_sdp4430_wifi_mux_init();
> > omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
> > +
> > + ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, "GPIO_WIFI_IRQ");
> > + if (ret) {
> > + pr_err("error requesting wl12xx gpio: %d\n", ret);
> > + goto out;
> > + }
> > +
> > + ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
> > + if (ret) {
> > + pr_err("error setting wl12xx irq type: %d\n", ret);
> > + goto free;
> > + }
> > +
> > ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
> > if (ret)
> > pr_err("Error setting wl12xx data: %d\n", ret);
> > +
> > ret = platform_device_register(&omap_vwlan_device);
> > if (ret)
> > pr_err("Error registering wl12xx device: %d\n", ret);
> > +out:
> > + return;
> > +free:
> > + gpio_free(GPIO_WIFI_IRQ);
>
> actually, you should leave this GPIO requested in order to use it as
> IRQ.
>
> ditto for all others
Actually, I don't need to use the GPIO if something goes wrong (ie.
setting the IRQ type or setting the platform data). Notice that in the
normal cases (ie. without errors), I return before the gpio_free() is
called.
This is not really needed, but it's a bit cleaner and we can probably
release some resources.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, 2013-07-03 at 17:12 +0200, Javier Martinez Canillas wrote:
> On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho wrote:
> > On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
> >> The platform_quirk element in the platform data was used to change the
> >> way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
> >> the irqflags used and treat edge trigger differently from the rest.
> >>
> >> Instead of hiding this irq flag setting behind the quirk, have the
> >> board files set the flags during initialization. This will be more
> >> meaningful than driver-specific quirks when we switch to DT.
> >>
> >> Additionally, fix missing gpio_request() calls in the boarding files
> >> (so that setting the flags actually works).
> >>
> >> Cc: Tony Lindgren
> >> Cc: Sekhar Nori
> >> Signed-off-by: Luciano Coelho
> >> ---
> >
> > [...]
> >
> >> @@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware
> >> *fw, void *context)
> >> wlcore_adjust_conf(wl);
> >>
> >> wl->irq = platform_get_irq(pdev, 0);
> >> - wl->platform_quirks = pdata->platform_quirks;
> >> wl->if_ops = pdev_data->if_ops;
> >>
> >> - if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
> >> - irqflags = IRQF_TRIGGER_RISING;
> >> - else
> >> - irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
> >> + irq_data = irq_get_irq_data(wl->irq);
> >> + if (!irq_data) {
> >> + wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
> >> + ret = -EINVAL;
> >> + goto out_free_nvs;
> >> + }
> >> +
> >> + wl->irq_flags = irqd_get_trigger_type(irq_data);
> >
> > BTW, there seems to be a patch on its way to make reading the flags
> > easier (ie. no need to get the irq_data first):
> >
> > http://mid.gmane.org/1367945288-5625-1-git-send-email-jav...@dowhile0.org
> >
> > I'm not sure if this is going to be taken in, but if it does, it would
> > be nice to change the code here to use the new irq_get_trigger_type()
> > function.
> That patch has been already merged in Linus tree as commit 1f6236bf
> ("genirq: Add irq_get_trigger_type() to get IRQ flags").
>
> So yes, it would be better if you can use irq_get_trigger_type()
> instead calling irq_get_irq_data() + irqd_get_trigger_type().
That's great, thanks! I'll make this change as soon as I get your patch
into my tree (ie. after the merge window closes).
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-07-18 at 01:58 +0200, Laurent Pinchart wrote: > Hi Luciano, Hi Laurent, > On Monday 01 July 2013 15:39:30 Luciano Coelho wrote: > > The only thing I can come up with is to make a small clock driver (maybe > > even inside the WiLink module itself) that registers a new type of > > clock, "ti,wilink-clock" or something. But this would really be > > overkill, wouldn't it? > > > > Any other ideas? > > One possibility would be to just call clk_get_rate() on the clock from the > WiLink driver, which would return the fixed frequency specified in DT, and > configure the WiLink hardware accordingly. This might be a bit hackish though. The problem is not get the rate itself, the problem is knowing whether the clock is XTAL or not. The WiLink chip uses the clock in a slightly different way if it is XTAL, due to some stabilization time constraints. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote: > Without WLAN we cannot switch omap4 to use device tree > only booting. This patch can be reverted when the > binding for wl12xx is added. > > Cc: Luciano Coelho > Cc: Benoit Cousson > Cc: Rajendra Nayak > Cc: devicetree-discuss@lists.ozlabs.org > Signed-off-by: Tony Lindgren > --- Tested-by: Luciano Coelho -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for blaze
On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote: > This should work assuming the board-4430sdp.c works, but it seems > that I don't have the "1283 PG 2.21 connectivity device" on > my blaze. Anybody got a spare connectivity device for blaze? > > Also, if somebody has the schematics, please provide a patch > for the missing GPIO muxes for blaze, see the the panda for > what's currently missing. > > Cc: Luciano Coelho > Cc: Benoit Cousson > Cc: Rajendra Nayak > Cc: Ruslan Bilovol > Cc: devicetree-discuss@lists.ozlabs.org > Signed-off-by: Tony Lindgren > --- Tested-by: Luciano Coelho -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
Hi Koen, On Fri, 2013-04-26 at 11:33 +0200, Koen Kooi wrote: > Op 26 apr. 2013, om 05:52 heeft Tony Lindgren het volgende > geschreven: > > > Without WLAN we cannot switch omap4 to use device tree > > only booting. This patch can be reverted when the > > binding for wl12xx is added. > > How much boards am I allowed to add to this? I need to get the wl12xx wifi > expansionboards for beagleboard, beagleboard xM and beaglebone working with > DT :) Do you know where I can get a wl12xx wifi expansion board for beaglebone? -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
On Fri, 2013-04-26 at 14:00 +0300, Luciano Coelho wrote: > Hi Koen, > > On Fri, 2013-04-26 at 11:33 +0200, Koen Kooi wrote: > > Op 26 apr. 2013, om 05:52 heeft Tony Lindgren het > > volgende geschreven: > > > > > Without WLAN we cannot switch omap4 to use device tree > > > only booting. This patch can be reverted when the > > > binding for wl12xx is added. > > > > How much boards am I allowed to add to this? I need to get the wl12xx wifi > > expansionboards for beagleboard, beagleboard xM and beaglebone working with > > DT :) > > Do you know where I can get a wl12xx wifi expansion board for > beaglebone? Uhmmm, never mind. I somehow thought this was with the WiLink 8 chip, but you said wl12xx, so it's not. ;) -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for pandaboard
On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
> This is needed to get wl12xx working with device tree based
> booting.
>
> Note that we claim the various GPIO inputs in the regulator
> as the proper muxing is needed to enable and disable the
> regulator.
>
> Also, we want to use non-removable instead of ti,non-removable
> as the ti,non-removable also sets no_regulator_off_init which
> is really not what we want as then wl12xx won't get powered
> up and down which is needed for resetting it.
>
> Cc: Luciano Coelho
> Cc: Benoit Cousson
> Cc: Rajendra Nayak
> Cc: devicetree-discuss@lists.ozlabs.org
> Signed-off-by: Tony Lindgren
> ---
I tried this now and it seems to work fine too. So:
Tested-by: Luciano Coelho
Except that with linux-next I'm getting some problems with the
interrupts when trying to use wl12xx. It's not related to this patch
though, and I'm investigating it right now.
Also, I found one small whitespace problem in this patch:
[...]
> + /* wl12xx GPIO inputs and SDIO pins */
> + wl12xx_pins: pinmux_wl12xx_pins {
> + pinctrl-single,pins = <
> + 0x38 0x103 /* gpmc_ncs2.gpio_52 INPUT | MODE3 */
> + 0x3a 0x103 /* gpmc_ncs3.gpio_53 INPUT | MODE3 */
> + 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
> MODE0 */
> + 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
> MODE0 */
> + 0x10c 0x118 /* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP
> | MODE0 */
> + 0x10e 0x118 /* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP
> | MODE0 */
> + 0x110 0x118 /* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP
> | MODE0 */
> + 0x112 0x118 /* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP
> | MODE0 */
> + >;
git am reports a "space before tab in indent" here.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] I2C: OMAP: fix build breakage when CONFIG_OF is not set
Since commit 6145197be6cc0583fa1a2f4ec1079d366137061e, building
i2c_omap.c breaks if CONFIG_OF is not set:
drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared
(first use in this function)
drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is
reported only once
drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.)
This is because the definition of omap_i2c_of_match is #ifdef'd on
CONFIG_OF, but the usage of it is not.
Since the places where omap_ic2_of_match are prepared to get NULL
pointers if CONFIG_OF is not defined, we can simply define it to NULL.
Cc: Benoit Cousson
Signed-off-by: Luciano Coelho
---
drivers/i2c/busses/i2c-omap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..fd200eb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -979,6 +979,8 @@ static const struct of_device_id omap_i2c_of_match[] = {
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+static const struct of_device_id *omap_i2c_of_match = NULL;
#endif
static int __devinit
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] I2C: OMAP: fix build breakage when CONFIG_OF is not set
On Wed, 2012-02-08 at 12:59 +0200, Felipe Balbi wrote: > On Wed, Feb 08, 2012 at 12:56:52PM +0200, Luciano Coelho wrote: > > Since commit 6145197be6cc0583fa1a2f4ec1079d366137061e, building > > we generally like to see the commit subject here too. And adding the > abbreviated commit instead of the full sha1, wouldn't hurt either ;-) Ok, different practices. :) I'll send v2. > > i2c_omap.c breaks if CONFIG_OF is not set: > > > > drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe': > > drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared > > (first use in this function) > > drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is > > reported only once > > drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.) > > > > This is because the definition of omap_i2c_of_match is #ifdef'd on > > CONFIG_OF, but the usage of it is not. > > > > Since the places where omap_ic2_of_match are prepared to get NULL > > pointers if CONFIG_OF is not defined, we can simply define it to NULL. > > > > Cc: Benoit Cousson > > Signed-off-by: Luciano Coelho > > after fixing the commit log, you can add: > > Reviewed-by: Felipe Balbi > > if you want. Thanks for your quick review! -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] I2C: OMAP: fix build breakage when CONFIG_OF is not set
On Wed, 2012-02-08 at 12:56 +0200, Luciano Coelho wrote: > Since commit 6145197be6cc0583fa1a2f4ec1079d366137061e, building > i2c_omap.c breaks if CONFIG_OF is not set: > > drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe': > drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared > (first use in this function) > drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is > reported only once > drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.) > > This is because the definition of omap_i2c_of_match is #ifdef'd on > CONFIG_OF, but the usage of it is not. > > Since the places where omap_ic2_of_match are prepared to get NULL > pointers if CONFIG_OF is not defined, we can simply define it to NULL. > > Cc: Benoit Cousson > Signed-off-by: Luciano Coelho > --- Forgot to say that I think this should go into 3.3, since it's a build break. -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3.3 v2] I2C: OMAP: fix build breakage when CONFIG_OF is not set
Since commit 6145197 (i2c: OMAP: Add DT support for i2c controller),
building i2c_omap.c breaks if CONFIG_OF is not set:
drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared
(first use in this function)
drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is
reported only once
drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.)
This is because the definition of omap_i2c_of_match is #ifdef'd on
CONFIG_OF, but the usage of it is not.
Since the places where omap_ic2_of_match are prepared to get NULL
pointers if CONFIG_OF is not defined, we can simply define it to NULL.
Cc: Benoit Cousson
Signed-off-by: Luciano Coelho
Reviewed-by: Felipe Balbi
---
v2: changed the commit log to use abbrev sha and include the commit subject
drivers/i2c/busses/i2c-omap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..fd200eb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -979,6 +979,8 @@ static const struct of_device_id omap_i2c_of_match[] = {
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+static const struct of_device_id *omap_i2c_of_match = NULL;
#endif
static int __devinit
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] I2C: OMAP: fix build breakage when CONFIG_OF is not set
On Wed, 2012-02-08 at 16:42 +0530, Shubhrajyoti Datta wrote: > On Wed, Feb 8, 2012 at 4:34 PM, Luciano Coelho wrote: > > On Wed, 2012-02-08 at 12:59 +0200, Felipe Balbi wrote: > >> On Wed, Feb 08, 2012 at 12:56:52PM +0200, Luciano Coelho wrote: > >> > Since commit 6145197be6cc0583fa1a2f4ec1079d366137061e, building > >> > >> we generally like to see the commit subject here too. And adding the > >> abbreviated commit instead of the full sha1, wouldn't hurt either ;-) > > > > Ok, different practices. :) > > However there was already a discurssion. > Anyways thanks for the patch. > http://permalink.gmane.org/gmane.linux.ports.arm.omap/69796 > > > > > > I'll send v2. > I think there was already a fix for this. > > http://www.spinics.net/lists/linux-omap/msg63151.html > > Anyways thanks for the patch. Ah, okay. Thanks for the info, I hadn't seen these. -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3.3 v2] I2C: OMAP: fix build breakage when CONFIG_OF is not set
Hi Ben,
On Mon, 2012-02-13 at 23:27 +, Ben Dooks wrote:
> On Wed, Feb 08, 2012 at 01:18:21PM +0200, Luciano Coelho wrote:
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index f713eac..fd200eb 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -979,6 +979,8 @@ static const struct of_device_id omap_i2c_of_match[] = {
> > { },
> > };
> > MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> > +#else
> > +static const struct of_device_id *omap_i2c_of_match = NULL;
> > #endif
>
> of_match_ptr(_ptr) will go to NULL if CONFIG_OF is not set, use that please.
Yes, you're right. But this patch can be ignored, since there was
already an equivalent one queued up (which I missed). And it uses
of_match_ptr() ;)
Thanks for your comment anyway!
--
Cheers,
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
