Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
Hi, On Mon, 2011-06-06 at 14:05 +0300, Luciano Coelho wrote: > On Mon, 2011-06-06 at 14:02 +0300, Felipe Balbi wrote: > > On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote: > > > looks like this is resulting from the missing hwmod conversion in > > > mainlnie. Check if reverting 7e6502d577106fb5b202bbaac64c5f1b065e6daa > > > helps. > > > > I verified off-list with Luca that reverting that commit does make it > > work. Keshava, care to send a revert patch to Sam until we get all the > > hwmod stuff in. > > Yes, I confirm that I'm not getting the oops anymore, after reverting > this patch. > > Thanks a lot for the quick answer, dude! :) I'm again getting a very similar oops with 3.1-rc1 on my pandaboard: [2.054351] usbcore: registered new interface driver cdc_ncm [2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [2.068664] Unhandled fault: imprecise external abort (0x1406) at 0x [2.076110] Internal error: : 1406 [#1] SMP [2.080505] Modules linked in: [2.083709] CPU: 0Not tainted (3.1.0-rc1-wl+ #283) [2.089233] PC is at omap_usbhs_enable+0x148/0x590 [2.094299] LR is at trace_hardirqs_off+0x14/0x18 [2.099243] pc : []lr : []psr: 6093 [2.099243] sp : df871dc8 ip : df871d80 fp : df871dec [2.111328] r10: 8013 r9 : df9ef9e0 r8 : df9ef9ec [2.116821] r7 : dfa32800 r6 : dfa316f8 r5 : c06f5da8 r4 : dfa316a0 [2.123687] r3 : r2 : r1 : 0001 r0 : [2.130584] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [2.138366] Control: 10c53c7d Table: 8000404a DAC: 0015 [2.144409] Process swapper (pid: 1, stack limit = 0xdf8702f8) [2.150543] Stack: (0xdf871dc8 to 0xdf872000) [2.155120] 1dc0: df105400 dfa32808 df105400 dfa32800 df9ef9ec 0003 [2.163726] 1de0: df871e8c df871df0 c0321d60 c02a8504 df871e2c df10a588 df1075a0 df10a588 [2.172363] 1e00: df871e2c df871e10 df10a588 df10a608 dfa28e88 006d fc064c00 [2.180969] 1e20: df871e6c df871e30 c015654c c0155c08 c0082098 c0071f74 0001 dfa32898 [2.189575] 1e40: dfa28e88 dfa32808 dfa32810 73757368 3062 [2.198181] 1e60: df871e7c dfa32808 c0716da8 c0716da8 [2.206787] 1e80: df871e9c df871e90 c0298cfc c0321bb8 df871ec4 df871ea0 c0297650 c0298ce4 [2.215423] 1ea0: df871ec4 dfa32808 dfa3283c dfa32808 dfa3283c c0716da8 df871ee4 df871ec8 [2.224029] 1ec0: c02977ec c0297504 c0716da8 c0297774 df871f0c df871ee8 [2.232635] 1ee0: c0296c00 c0297780 df891658 dfa31670 c023ac60 c0716da8 df1075a0 c070d6f8 [2.241241] 1f00: df871f1c df871f10 c0297334 c0296bb0 df871f4c df871f20 c02963ec c0297318 [2.249847] 1f20: c05b84a8 df871f30 c0716da8 c0c7e4c0 c0014ba0 [2.258483] 1f40: df871f74 df871f50 c0297f00 c0296320 c0298d44 c0c7df14 c0c7e4c0 c0014ba0 [2.267089] 1f60: df871f84 df871f78 c02991e0 c0297e54 df871fa4 df871f88 [2.275695] 1f80: c069904c c0299198 00a0 0060 c06c4e40 c0698fa4 df871fdc df871fa8 [2.284301] 1fa0: c0008854 c0698fb0 c0014ba0 c009960c df871fdc df871fc0 c06c4e40 c06c49dc [2.292907] 1fc0: c0014ba0 0013 df871ff4 df871fe0 c06792d4 c00087b8 [2.301513] 1fe0: c067924c df871ff8 c0014ba0 c0679258 882bf20f 3184000e [2.310150] [] (omap_usbhs_enable+0x148/0x590) from [] (ehci_hcd_omap_probe+0x1b4/0x568) [2.320526] [] (ehci_hcd_omap_probe+0x1b4/0x568) from [] (platform_drv_probe+0x24/0x28) [2.330780] [] (platform_drv_probe+0x24/0x28) from [] (driver_probe_device+0x158/0x27c) [2.341033] [] (driver_probe_device+0x158/0x27c) from [] (__driver_attach+0x78/0x9c) [2.351043] [] (__driver_attach+0x78/0x9c) from [] (bus_for_each_dev+0x5c/0x8c) [2.360565] [] (bus_for_each_dev+0x5c/0x8c) from [] (driver_attach+0x28/0x30) [2.369903] [] (driver_attach+0x28/0x30) from [] (bus_add_driver+0xd8/0x260) [2.379180] [] (bus_add_driver+0xd8/0x260) from [] (driver_register+0xb8/0x144) [2.388702] [] (driver_register+0xb8/0x144) from [] (platform_driver_register+0x54/0x68) [2.399047] [] (platform_driver_register+0x54/0x68) from [] (ehci_hcd_init+0xa8/0xfc) [2.409149] [] (ehci_hcd_init+0xa8/0xfc) from [] (do_one_initcall+0xa8/0x17c) [2.418487] [] (do_one_initcall+0xa8/0x17c) from [] (kernel_init+0x88/0x134) [2.427764] [] (kernel_init+0x88/0x134) from [] (kernel_thread_exit+0x0/0x8) [2.437011] Code: e59f0414 e1a01005 e59f2424 ebffac8d (e594303c) This seems to be very similar (if not identical) to the oops I was getting before (with 3.0-rc2). I checked the git log and the revert that fixed my problem with 3.0-rc2 is now included in 3.1-rc1, so it seems that something else is
Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
On Thu, 2011-08-11 at 11:07 +0300, Ohad Ben-Cohen wrote: > > Any clues? > > Reverting 665d001338b494d6d62810aa99b4c0fa1a0884b9 "OMAP2+: hwmod: > Follow the recommended PRCM module enable sequence" fixes this for me. > > More specifically, this hunk alone seems to do the trick: > > diff --git a/arch/arm/mach-omap2/clock44xx_data.c > b/arch/arm/mach-omap2/clock44x > index 2af0e3f..12d22a8 100644 > --- a/arch/arm/mach-omap2/clock44xx_data.c > +++ b/arch/arm/mach-omap2/clock44xx_data.c > @@ -3379,7 +3379,6 @@ int __init omap4xxx_clk_init(void) > } > > clk_init(&omap2_clk_functions); > - omap2_clk_disable_clkdm_control(); > > for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks); > c++) > > I'm not suggesting this is anyway near a real fix, but hopefully it > will help pin-point the problem (clock44xx_data.c changes ?). This solves (or works around?) the problem for me too. Thanks, Ohad! -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
On Thu, 2011-08-11 at 17:29 +0530, Rajendra Nayak wrote: > On 8/11/2011 1:37 PM, Ohad Ben-Cohen wrote: > > + Paul, Benoit, Rajendra > > > > On Tue, Aug 9, 2011 at 2:26 PM, Luciano Coelho wrote: > >> I'm again getting a very similar oops with 3.1-rc1 on my pandaboard: > >> > >> [2.054351] usbcore: registered new interface driver cdc_ncm > >> [2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > >> [2.068664] Unhandled fault: imprecise external abort (0x1406) at > >> 0x > >> [2.076110] Internal error: : 1406 [#1] SMP > >> [2.080505] Modules linked in: > >> [2.083709] CPU: 0Not tainted (3.1.0-rc1-wl+ #283) > >> [2.089233] PC is at omap_usbhs_enable+0x148/0x590 > >> [2.094299] LR is at trace_hardirqs_off+0x14/0x18 > > ... > >> [2.310150] [] (omap_usbhs_enable+0x148/0x590) from > >> [] (ehci_hcd_omap_probe+0x1b4/0x568) > >> [2.320526] [] (ehci_hcd_omap_probe+0x1b4/0x568) from > >> [] (platform_drv_probe+0x24/0x28) > >> [2.330780] [] (platform_drv_probe+0x24/0x28) from > >> [] (driver_probe_device+0x158/0x27c) > >> [2.341033] [] (driver_probe_device+0x158/0x27c) from > >> [] (__driver_attach+0x78/0x9c) > >> [2.351043] [] (__driver_attach+0x78/0x9c) from [] > >> (bus_for_each_dev+0x5c/0x8c) > >> [2.360565] [] (bus_for_each_dev+0x5c/0x8c) from [] > >> (driver_attach+0x28/0x30) > >> [2.369903] [] (driver_attach+0x28/0x30) from [] > >> (bus_add_driver+0xd8/0x260) > >> [2.379180] [] (bus_add_driver+0xd8/0x260) from [] > >> (driver_register+0xb8/0x144) > >> [2.388702] [] (driver_register+0xb8/0x144) from [] > >> (platform_driver_register+0x54/0x68) > >> [2.399047] [] (platform_driver_register+0x54/0x68) from > >> [] (ehci_hcd_init+0xa8/0xfc) > >> [2.409149] [] (ehci_hcd_init+0xa8/0xfc) from [] > >> (do_one_initcall+0xa8/0x17c) > >> [2.418487] [] (do_one_initcall+0xa8/0x17c) from [] > >> (kernel_init+0x88/0x134) > >> [2.427764] [] (kernel_init+0x88/0x134) from [] > >> (kernel_thread_exit+0x0/0x8) > > > > I get this too. > > > >> Any clues? > > Its quite expected as omap_usbhs_enable() still relies on clock > framework to enable the clocks. > Any driver still using clock framework on OMAP4 to enable "main" clocks > is expected to be broken. The only way to fix this is to adapt > the driver to runtime PM. Well, this is a regression in 3.1 and must be fixed. It's probably too late to make big changes in the usbhs driver, so probably the change in OMAP that broke this should be reverted. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.1-rc3 fails to boot on my pandaboard
Hi, There seems to be a problem with 3.1-rc3, which prevents it from booting on my PandaBoard (ARM OMAP4). 3.1-rc2 works fine, so I have bisected the problem and it turns out to be caused by this: commit f3637a5f2e2eb391ff5757bc83fb5de8f9726464 Author: Sebastian Andrzej Siewior Date: Thu Jul 7 22:32:17 2011 +0200 irq: Always set IRQF_ONESHOT if no primary handler is specified After reverting this commit, -rc3 boots fine. I'm not sure where exactly the problem is. Maybe it's something in the omap code which is broken and this patch causes the bug to show up? What happens is that the booting process hangs after printing out this: [...] [7.408477] EXT3-fs: barriers not enabled [7.415008] kjournald starting. Commit interval 5 seconds [7.446228] EXT3-fs (mmcblk0p5): using internal journal [7.452087] EXT3-fs (mmcblk0p5): mounted filesystem with ordered data mode [7.459625] VFS: Mounted root (ext3 filesystem) on device 179:5. [7.466094] Freeing init memory: 312K [7.471710] Failed to execute /init. Attempting defaults... [ 10.254333] EXT3-fs (mmcblk0p5): using internal journal The full boot logs can be found here: http://pastebin.pandaboard.org/index.php/view/88995306 Any ideas what may be going wrong? -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.1-rc3 fails to boot on my pandaboard
On Thu, 2011-08-25 at 13:04 +0200, Sebastian Andrzej Siewior wrote:
> * Luciano Coelho | 2011-08-25 13:39:29 [+0300]:
> >Any ideas what may be going wrong?
>
> I think my commit was identified as bogus and tglx is going to revert
> it. The problem is that I force ONESHOT mode for all threaded IRQs but
> there are also others without the flag which is not allowed.
>
> I was trying to check something but I don't get my board to boot. Could
> you please try to boot with the patch reverted and paste me the
> the output of
> cat /proc/interrupts | grep 74 ?
Hmmm... There doesn't seem to be an irq 74. The only thing I get is
this:
root@xiru:~# cat /proc/interrupts | grep 74
IPI1: 2667 3743 Rescheduling interrupts
Which is probably not what you wanted. ;)
> I *think* that the flow handler is level (I can't find evidence of it
> beeing edge, and omap_alloc_gc() is the place installing it).
>
> So could you please gather additional debug info with this patch?
>
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 2e94258..eda25a0 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1327,6 +1327,9 @@ int request_threaded_irq(unsigned int irq,
> irq_handler_t handler,
> if (!irq_settings_can_request(desc))
> return -EINVAL;
>
> + if (irq == 74)
> + printk(KERN_ERR "%s() h %pS th %pS f %lx dev %s flow %pS\n",
> __func__,
> + handler, thread_fn, irqflags, devname,
> desc->handle_irq);
> if (!handler) {
> if (!thread_fn)
> return -EINVAL;
>
>
> %pS should resolve the function names.
As I mentioned above, there doesn't seem to be irq 74, so this code
doesn't hit.
These are the interrupts reported in /proc/interrupts on my board:
root@xiru:~# cat /proc/interrupts
CPU0 CPU1
39: 0 0 GIC TWL6030-PIH
41: 0 0 GIC l3-dbg-irq
42: 0 0 GIC l3-app-irq
44: 5397 0 GIC DMA
52: 0 0 GIC gpmc
69: 16 0 GIC gp timer
88:270 0 GIC omap_i2c
89: 0 0 GIC omap_i2c
91:183 0 GIC mmc1
93: 0 0 GIC omap_i2c
94: 0 0 GIC omap_i2c
102: 0 0 GIC serial idle
104: 0 0 GIC serial idle
105: 0 0 GIC serial idle
106:290 0 GIC serial idle, OMAP UART2
108: 1 0 GIC ohci_hcd:usb3
109:493 0 GIC ehci_hcd:usb1
115: 6260 0 GIC mmc0
124: 1 0 GIC musb-hdrc
125: 0 0 GIC musb-hdrc
213: 0 0 GPIO wl1271
372: 0 0 twl6030 twl6030_usb
378: 0 0 twl6030 twl6030_usb
379: 0 0 twl6030 rtc0
IPI0: 0 0 Timer broadcast interrupts
IPI1: 2995 3606 Rescheduling interrupts
IPI2: 0 0 Function call interrupts
IPI3: 57 61 Single function call interrupts
IPI4: 0 0 CPU stop interrupts
LOC: 8879 5844 Local timer interrupts
Err: 0
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.1-rc3 fails to boot on my pandaboard
On Thu, 2011-08-25 at 17:05 +0530, Govindraj wrote: > On Thu, Aug 25, 2011 at 4:09 PM, Luciano Coelho wrote: > > Hi, > > > > There seems to be a problem with 3.1-rc3, which prevents it from booting > > on my PandaBoard (ARM OMAP4). > > > > 3.1-rc2 works fine, so I have bisected the problem and it turns out to > > be caused by this: > > > > commit f3637a5f2e2eb391ff5757bc83fb5de8f9726464 > > Author: Sebastian Andrzej Siewior > > Date: Thu Jul 7 22:32:17 2011 +0200 > > > >irq: Always set IRQF_ONESHOT if no primary handler is specified > > > > After reverting this commit, -rc3 boots fine. I'm not sure where > > exactly the problem is. Maybe it's something in the omap code which is > > broken and this patch causes the bug to show up? > > > > What happens is that the booting process hangs after printing out this: > > > > fyi, > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69dd3d8e29e294caaf63eb5e8a72d250279f9e5f;hp=fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c Ah, thanks. Now I see where the irq == 74 comes from. :) Still, I don't see that on my system. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE
From: Randy Dunlap Combine MFD_SUPPORT (which only enabled the remainder of the MFD menu) and MFD_CORE. This allows other drivers to select MFD_CORE without needing to also select MFD_SUPPORT, which fixes some kconfig unmet dependency warnings. Modeled after I2C kconfig. [Forward-ported to 3.1-rc4. This fixes a warning when some drivers, such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca] Signed-off-by: Randy Dunlap Reported-by: Johannes Berg Cc: Jean Delvare Cc: Tony Lindgren Cc: Grant Likely Signed-off-by: Luciano Coelho --- I guess this should fix the problem. I've simple forward-ported Randy's patch to the latest mainline kernel. I don't know via which tree this should go in, though. NOTE: I have *not* tested this very thoroughly. But at least omap2plus stuff seems to work okay with this change. MFD_SUPPORT is also selected by a couple of "tile" platforms defconfigs, but I guess the Kconfig system should take care of it. arch/arm/mach-omap2/Kconfig |2 +- drivers/gpio/Kconfig|3 +- drivers/mfd/Kconfig | 54 +++--- 3 files changed, 6 insertions(+), 53 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 57b66d5..1046923 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL select SERIAL_OMAP_CONSOLE select I2C select I2C_OMAP - select MFD_SUPPORT + select MFD_CORE select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index d539efd..fbc5fd4 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -180,7 +180,7 @@ config GPIO_SCH config GPIO_VX855 tristate "VIA VX855/VX875 GPIO" - depends on MFD_SUPPORT && PCI + depends on PCI select MFD_CORE select MFD_VX855 help @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE config GPIO_RDC321X tristate "RDC R-321x GPIO support" depends on PCI - select MFD_SUPPORT select MFD_CORE select MFD_RDC321X help diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..1836cdf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool "Multifunction device drivers" +menuconfig MFD_CORE + tristate "Multifunction device drivers" depends on HAS_IOMEM - default y help Multifunction devices embed several functions (e.g. GPIOs, touchscreens, keyboards, current regulators, power management chips, @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT This option alone does not add any kernel code. -if MFD_SUPPORT - -config MFD_CORE - tristate - default n +if MFD_CORE config MFD_88PM860X bool "Support Marvell 88PM8606/88PM8607" depends on I2C=y && GENERIC_HARDIRQS - select MFD_CORE help This supports for Marvell 88PM8606/88PM8607 Power Management IC. This includes the I2C driver and the core APIs _only_, you have to @@ -55,14 +49,12 @@ config MFD_SM501_GPIO config MFD_ASIC3 bool "Support for Compaq ASIC3" depends on GENERIC_HARDIRQS && GPIOLIB && ARM - select MFD_CORE ---help--- This driver supports the ASIC3 multifunction chip found on many PDAs (mainly iPAQ and HTC based ones) config MFD_DAVINCI_VOICECODEC tristate - select MFD_CORE config MFD_DM355EVM_MSP bool "DaVinci DM355 EVM microcontroller" @@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP config MFD_TI_SSP tristate "TI Sequencer Serial Port support" depends on ARCH_DAVINCI_TNETV107X - select MFD_CORE ---help--- Say Y here if you want support for the Sequencer Serial Port in a Texas Instruments TNETV107X SoC. @@ -93,7 +84,6 @@ config HTC_EGPIO config HTC_PASIC3 tristate "HTC PASIC3 LED/DS1WM chip support" - select MFD_CORE help This core driver provides register access for the LED/DS1WM chips labeled "AIC2" and "AIC3", found on HTC Blueangel and @@ -124,7 +114,6 @@ config TPS6105X tristate "TPS61050/61052 Boost Converters" depends on I2C select REGULATOR - select MFD_CORE select REGULATOR_FIXED_VOLTAGE help This option enables a driver for the TP61050/TPS61052 @@ -147,7 +136,6 @@ config TPS65010 config TPS6507X tristate "TPS6507x Power Management / Touch Screen chips" - select MFD_CORE
Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE
On Wed, 2011-08-31 at 18:49 +0200, Arnd Bergmann wrote: > On Monday 29 August 2011, Luciano Coelho wrote: > > From: Randy Dunlap > > > > Combine MFD_SUPPORT (which only enabled the remainder of the MFD > > menu) and MFD_CORE. This allows other drivers to select MFD_CORE > > without needing to also select MFD_SUPPORT, which fixes some > > kconfig unmet dependency warnings. Modeled after I2C kconfig. > > > > [Forward-ported to 3.1-rc4. This fixes a warning when some drivers, > > such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca] > > > > Signed-off-by: Randy Dunlap > > Reported-by: Johannes Berg > > Cc: Jean Delvare > > Cc: Tony Lindgren > > Cc: Grant Likely > > Signed-off-by: Luciano Coelho > > --- > > > > I guess this should fix the problem. I've simple forward-ported > > Randy's patch to the latest mainline kernel. I don't know via which > > tree this should go in, though. > > > > NOTE: I have not tested this very thoroughly. But at least > > omap2plus stuff seems to work okay with this change. MFD_SUPPORT is > > also selected by a couple of "tile" platforms defconfigs, but I guess > > the Kconfig system should take care of it. > > Doing this is a good idea, but incidentally I have just spent some time > with the same problem and ended up with a solution that I like better, > which is removing CONFIG_MFD_SUPPORT altogether. > > The point is that there is no use enabling MFD_CORE if you don't also > enable any of the specific drivers. MFD_SUPPORT was added as a 'menuconfig' > before we had Kconfig warn about broken dependencies, so everything was > fine. Since Kconfig now issues the warnings, I think it would be better > to just turn the MFD menu into a plain 'menu' and remove all the > 'depends on MFD_SUPPORT' and 'select MFD_SUPPORT' lines from the other > Kconfig files. Yes, this makes sense. I think your solution is indeed cleaner. If you want to send it it's fine with me. I don't really have any preference, I just wanted to clean a problem that was reported to me. ;) If you send your changes, my patch can be ignored, otherwise, I can send a v2 with the changes Jean proposed. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ti.com addresses randomly unsubscribed from vger.kernel.org lists
On Thu, 2011-09-15 at 10:26 -0700, Kevin Hilman wrote: > Hello, > > There have been ongoing problems for awhile now where ti.com addresses > have been randomly unsubscribed from vger.kernel.org lists (linux-omap, > linux-kernel, etc.) > > Luca and myself have been working with TI IT to figure out this problem, > and they claim to have fixed the problem (details on problem below.) > > Please send me an email if you find yourself suddenly unsubscribed from > one of these mailing lists, and also open a ticket with IT. > > Kevin > > > More details: > > The problem is that the mailing list admin was receiving bounces from > the ti.com mail servers, but the bounces were not descriptive enough to > discover which addresses were failing. The result was "big hammer" > approach in that ti.com addresses were unsubscribed until the bounces > stopped. > > After talking with the list admins, this has been going on for years. > > We were able to get copies of the bounced emails from the kernel.org > list admin and share them with IT, and they have found the problem and > have claimed to fix it. > > If you find yourself suddenly unsubscribed again, please open a ticket > and also let me know. Yeah, I've been in contact with Dave and he helped us by sending some bounce emails to be investigated by TI's IT. It seems that they have worked around this problem, by whitelisting vger.kernel.org. According to IT, the problem was the way vger sends emails, by opening a single SMTP connection to send loads of emails at once, instead of opening a separate connection for each recipient. The SPAM filters TI uses consider that kind of behavior as SPAM by default. Hopefully the bounces won't happen anymore with the whitelisting. Dave said he hasn't got any bounces for a while (he used to get 50-60 a day) and that he will inform me in case he sees more bounces from ti.com. I use my gmail account for these subscriptions, and have done it for a few years, after having similar problems with my ex nokia.com email. ;) As Kevin said, if you use ti.com emails and you get mysteriously unsubscribed from some mailing lists, let us know. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
On Mon, 2011-11-28 at 10:26 +0200, Eliad Peller wrote: > On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano wrote: > > On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller wrote: > >> Declare support for keeping the power of the wlan chip > >> while suspended. this is needed for Wakeup-On-Wireless. > >> > >> Signed-off-by: Eliad Peller > >> --- > >> arch/arm/mach-omap2/board-4430sdp.c |1 + > >> 1 files changed, 1 insertions(+), 0 deletions(-) > > > > What about all the other board files that also have this structure? > > For example board-omap4panda.c? I think they should all be changed and > > the change should also be communicated more broadly for those board > > files which (unfortunately) are not upstream (or which are upstream > > but without the wl12xx-specific definitions on it, such as Beagle). > > > i preferred adding this capability only for boards i can test. > unfortunately, i don't a panda/beagle setup. > anyway, i don't think we have to add it all at once. > let's just do it one board at a time... i'll add support for zoom as > well. any volunteers for panda/beagle? ;) Hmmm, okay, there is logic in that for the pragmatic, but this seems to be so clearly what is needed to solve the same problem with other boards that it could deserve changing all the board files. In practice, your changes may affect all the other boards too, regardless of whether you set the new flag or not. In any case, not my call here. I may do it for panda later on, if I get the time to test it. For beagle, it doesn't really apply, because the wl12xx support is out-of-tree, unfortunately. :( -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote: > Hi Luciano, Hi Igor, > On 11/28/11 11:08, Luciano Coelho wrote: > > I may do it for panda later on, if I get the time to test it. For > > beagle, it doesn't really apply, because the wl12xx support is > > out-of-tree, unfortunately. :( > > If I understood correctly, you want to change all the > board files supporting the wl12xx wifi chip to have this > capability set, right? > Isn't this immediately affects the power consumption in > sleep state? > Shouldn't this be runtime controllable? > I bet there are many applications that do not care about WoW, > but do care about the power consumption. > How does this change affect them? Good point, I don't know. :) Probably Eliad has the answer for that. In any case, I don't see why this behaviour should be different in the different board files. If there is the problem of power consumption while in suspend, we will have it also with the 4430sdp board. I'm not sure about doing it dynamically, though. I think it would be more of a kernel configuration option or something. At least the board file is not the correct place to decide whether the wl12xx chip will support WoW or not. And, if we change only the MMC capabilities of the wl12xx chip, we won't hurt other scenarios, when the wl12xx chip is not in use. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
On Mon, 2011-11-28 at 12:12 +0200, Eliad Peller wrote: > On Mon, Nov 28, 2011 at 11:58 AM, Luciano Coelho wrote: > > On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote: > >> On 11/28/11 11:08, Luciano Coelho wrote: > >> > I may do it for panda later on, if I get the time to test it. For > >> > beagle, it doesn't really apply, because the wl12xx support is > >> > out-of-tree, unfortunately. :( > >> > >> If I understood correctly, you want to change all the > >> board files supporting the wl12xx wifi chip to have this > >> capability set, right? > >> Isn't this immediately affects the power consumption in > >> sleep state? > >> Shouldn't this be runtime controllable? > >> I bet there are many applications that do not care about WoW, > >> but do care about the power consumption. > >> How does this change affect them? > > > > Good point, I don't know. :) Probably Eliad has the answer for that. > > > see the discussion regarding patch [2/3] - we only declare here > support for this capability, but it's disabled by default. Great, thanks! :) I now also understand the difference between the pm_flags and pm_caps. :) So, back to where we started, we should add the capability to all boards that define the MMC capabilities of the wl12xx chip. No matter who will do it. :) -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On Thu, 2013-07-18 at 01:59 -0700, Tony Lindgren wrote: > * Arend van Spriel [130718 01:47]: > Then for the SDIO with device tree, take a look at the following > patches: > > [PATCH 0/3] WLAN support for omap4 when booted with devicetree > http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > > The wl12xx .dts changes for pandaboard are still missing too. Just for the record, I already have the DTS patches for wl12xx on Panda (and a few other boards). I held them back because I wanted the bindings to be properly defined first. I'll continue this work pretty soon, when I come back from my summer vacations (in a week). -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] 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
---
Changes in v2:
Use generic clock definitions to get the clock data instead of passing
the frequencies directly. Also added definition for "internal"
ti,wilink-clock.
Please review.
Luca.
.../devicetree/bindings/net/wireless/ti-wilink.txt | 68 ++
1 file changed, 68 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..5fd27dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
@@ -0,0 +1,68 @@
+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:
+
+
+- clocks: list of clocks needed by the chip as follows:
+
+ refclock: the internal WLAN reference clock frequency (required for
+ WiLink6 and WiLink7; not used for WiLink8).
+
+ tcxoclock: the internal WLAN TCXO clock frequency (required for
+ WiLink7 not used for WiLink6 and WiLink8).
+
+ The clocks must be defined and named accordingly. For example:
+
+ clocks = <&refclock>
+ clock-names = "refclock";
+
+ refclock: refclock {
+compatible = "ti,wilink-clock";
+#clock-cells = <0>;
+clock-frequency = <3840>;
+ };
+
+ Some modules that contain the WiLink chip provide clocks in the
+ module itself. In this case, we define a "ti,wilink-clock" as shown
+ above. But any other clock could in theory be used, so the proper
+ clock definition should be used.
+
+
+Example:
+
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+ 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>;
+ };
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 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
Reviewed-by: Felipe Balbi
---
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 b1547a0..84d56e8 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,7 +541,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));
@@ -555,7 +555,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 9c2dd10..01e5711 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;
-
[PATCH v4 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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 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
Reviewed-by: Felipe Balbi
---
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 a6c2a14..60d2ff4 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;
@@ -1758,7 +1768,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);
@@ -1769,6 +1779,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;
@@ -1786,7 +1798,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);
@@ -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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 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.
Additionally, this reverts commit 26f45c (ARM: OMAP2+: Legacy support
for wl12xx when booted with devicetree), since this is not be needed
anymore, now that DT support for WiLink is implemented.
Cc: Tony Lindgren
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
Reviewed-by: Felipe Balbi
---
arch/arm/mach-davinci/board-da850-evm.c | 3 +-
arch/arm/mach-omap2/board-omap3evm.c | 3 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 3 +-
arch/arm/mach-omap2/devices.c| 39 ---
drivers/net/wireless/ti/wl12xx/main.c| 58 +++-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 ++
include/linux/wl12xx.h | 27 ++---
7 files changed, 93 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 03de2e9..6b2768f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1376,7 +1376,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-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 9c7dfc5..4ccfcc0 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -460,7 +460,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-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/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..10e6126 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -8,7 +8,6 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
-#include
#include
#include
#include
@@ -19,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -513,40 +511,6 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
-#if IS_ENABLED(CONFIG_WL12XX)
-
-static struct wl12xx_platform_data wl12xx __initdata;
-
-void __init omap_init_wl12xx_of(void)
-{
- int ret;
-
- if (!of_have_populated_dt())
- return;
-
- if (of_machine_is_compatible("ti,omap4-sdp")) {
- wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
- wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
- wl12xx.irq = gpio_to_irq(53);
- } else if (of_machine_is_compatible("ti,omap4-panda")) {
- wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
- wl12xx.irq = gpio_to_irq(53);
- } else {
- return;
- }
-
- ret = wl12xx_set_platform_data(&wl12xx);
- if (ret) {
- pr_err("error setting wl12xx data: %d\n", ret);
- return;
- }
-}
-#else
-static inline void omap_init_wl12xx_of(void)
-{
-}
-#endif
-
/*-*/
static int __init omap2_init_devices(void)
@@ -570,9 +534,6 @@ static int __init omap2_init_devices(void)
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
- } else {
- /* These can be removed when bindings are done */
- omap_init_wl12xx_of();
}
omap_init_sti();
omap_init_rng();
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..a6c2a14 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,43 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static const struct
[PATCH v4 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. Regarding the XTAL clock issues, for now we don't support XTAL mode with DT, but I have sent a proposal for a small change in the clock framework to support this, but it's still under discussions [1]. The DTS file changes will be sent separately, since they need to go via different trees. A new version of the bindings documentation has been sent [2] and, if no more comments are given to it, I'll apply it via my tree. [1] http://news.gmane.org/find-root.php?message_id=1372971912-10877-1-git-send-email-coe...@ti.com [2] http://news.gmane.org/find-root.php?message_id=1375109728-5931-1-git-send-email-coe...@ti.com Changes in v4: * Rebased on top of 3.11-rc3 (eg. no more changes on the board files that were removed); * Use the new irq_get_trigger_type() instead of irqd_get_trigger_type() (thanks Javier); * Added some missing const's (thanks Felipe); * Reverted Tony's workaround to get WiLink to work on Panda while DT was not supported yet. Please review. 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-omap3evm.c | 22 - arch/arm/mach-omap2/board-omap3pandora.c | 4 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 33 +++- arch/arm/mach-omap2/devices.c | 39 - 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 | 20 ++--- 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 +--- 17 files changed, 340 insertions(+), 120 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 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
Reviewed-by: Felipe Balbi
---
drivers/net/wireless/ti/wlcore/main.c | 3 +--
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(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 11dab9a..e771de0 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5900,7 +5900,6 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
struct wl1271 *wl = context;
struct platform_device *pdev = wl->pdev;
struct wlcore_platdev_data *pdev_data = pdev->dev.platform_data;
- struct wl12xx_platform_data *pdata = pdev_data->pdata;
int ret;
@@ -5947,7 +5946,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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 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
Reviewed-by: Felipe Balbi
Acked-by: Sekhar Nori
---
arch/arm/mach-davinci/board-da850-evm.c | 8 +++-
arch/arm/mach-omap2/board-omap3evm.c | 19 ++
arch/arm/mach-omap2/board-zoom-peripherals.c | 30 +---
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
drivers/net/wireless/ti/wlcore/main.c| 17
drivers/net/wireless/ti/wlcore/wlcore.h | 5 ++---
include/linux/wl12xx.h | 4
7 files changed, 64 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index bea6793..03de2e9 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,7 +1377,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)
@@ -1408,6 +1407,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-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8c02626..9c7dfc5 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -614,12 +614,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-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..4f84cf9 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -339,16 +339,40 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-void __init zoom_peripherals_init(void)
+static void __init zoom_wilink_init(void)
{
int ret;
omap_zoom_wlan_data.irq = gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO);
- ret = wl12xx_set_platform_data(&omap_zoom_wlan_data);
- if (ret)
+ ret = gpio_request_one(OMAP_ZOOM_WLAN_IRQ_GPIO, GPIOF_IN,
+ "OMAP_ZOOM_WLAN_IRQ_GPIO");
+ if (ret) {
+ pr_err("error requesting wl12xx gpio: %d\n", ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(OMAP_ZOOM_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(&omap_zoom_wlan_data);
+ if (ret) {
pr_err("error setting wl12xx data: %d\n", ret);
+ goto free;
+ }
+out:
+ return;
+free:
+ gpio_free(OMAP_ZOOM_WLAN_IRQ_GPIO);
+}
+void __init zoom_peripheral
[PATCH v4 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
Reviewed-by: Felipe Balbi
---
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.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
*/
clock-frequency = <1920>;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 11 0>; /* gpio line 43 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -132,6 +142,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&hsusbb1_pins
+ &wilink_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x66 0x3/* gpio_43 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -314,8 +338,13 @@
};
&mmc5 {
- ti,non-removable;
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-sdp.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
"DMic", "Digital Mic",
"Digital Mic", "Digital Mic1 Bias";
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 22 0>; /* gpio line 54 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -166,6 +176,7 @@
&mcbsp2_pins
&dss_hdmi_pins
&tpd12s015_pins
+ &wilink_pins
>;
uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x7c 0x3/* gpio_54 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -420,8 +444,13 @@
};
&mmc5 {
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] arm: dts: omap4-panda-common: add WiLink6 device tree nodes
Add the WiLink device tree nodes. On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used. The refclock
frequency is 38.4MHz.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..77e4a42 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -117,6 +117,20 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ wlan {
+ 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>;
+ };
+};
};
&omap4_pmx_wkup {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
Hi, These patches add the necessary DT configuration to use the WLAN part of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze). I've tested these changes on Panda and it works fine. But I couldn't test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having problems with clocks and SDIO stuff. So it's pretty much just compiled tested. I've tried this (without the new clock definition stuff) on Blaze with 3.10 and it was working, though. Please take a look and let me know what you think. Luca. Luciano Coelho (4): ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration arm: dts: omap4-panda-common: add WiLink6 device tree nodes ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration arm: dts: omap4-sdp: add WiLink7 device tree node arch/arm/boot/dts/omap4-panda-common.dtsi | 45 +++- arch/arm/boot/dts/omap4-sdp.dts | 49 +++ 2 files changed, 93 insertions(+), 1 deletion(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] arm: dts: omap4-sdp: add WiLink7 device tree node
Add appropriate device tree node for Blaze's WiLink7 module. It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO. Additionally, add the clock
frequencies used by the module.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-sdp.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..2fecca1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -150,6 +150,26 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink7";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 0x4>; /* gpio line 53, high level triggered */
+ clocks = <&refclock &tcxoclock>;
+ clock-names = "refclock tcxoclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ };
+
+ tcxoclock: tcxoclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ };
+};
};
&omap4_pmx_wkup {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: dt: bindings: TI WiLink modules
(using the new devicetree mailing list address)
On Tue, 2013-07-30 at 20:24 +0200, Laurent Pinchart wrote:
> Hi Luciano,
>
> Thank you for the patch.
>
> On Monday 29 July 2013 17:55:28 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
> > ---
> >
> > Changes in v2:
> >
> > Use generic clock definitions to get the clock data instead of passing
> > the frequencies directly. Also added definition for "internal"
> > ti,wilink-clock.
> >
> > Please review.
>
> The proposal looks good to me, I just have one small comment.
Cool! Thanks for the review.
[...]
> > +Example:
> > +
> > +
> > +Example definition that can be used in OMAP4 Panda:
> > +
> > +wlan {
> > + compatible = "ti,wilink6";
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
>
> Could you please use the IRQ_TYPE_LEVEL_HIGH macro (defined in bindings/interrupt-controller/irq.h>) instead of the hardcode 0x4 constant ?
Ah, right, I saw this new header file recently but forgot to update my
example. I'll update the OMAP4 Panda and OMAP4 SDP dts files I just
sent out as well.
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] 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
---
In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
.../devicetree/bindings/net/wireless/ti-wilink.txt | 68 ++
1 file changed, 68 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..aafebb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
@@ -0,0 +1,68 @@
+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:
+
+
+- clocks: list of clocks needed by the chip as follows:
+
+ refclock: the internal WLAN reference clock frequency (required for
+ WiLink6 and WiLink7; not used for WiLink8).
+
+ tcxoclock: the internal WLAN TCXO clock frequency (required for
+ WiLink7 not used for WiLink6 and WiLink8).
+
+ The clocks must be defined and named accordingly. For example:
+
+ clocks = <&refclock>
+ clock-names = "refclock";
+
+ refclock: refclock {
+compatible = "ti,wilink-clock";
+#clock-cells = <0>;
+clock-frequency = <3840>;
+ };
+
+ Some modules that contain the WiLink chip provide clocks in the
+ module itself. In this case, we define a "ti,wilink-clock" as shown
+ above. But any other clock could in theory be used, so the proper
+ clock definition should be used.
+
+
+Example:
+
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ };
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
Hi, In v2: use IRQ_TYPE_LEVEL_HIGH when defining the interrupts, as suggested by Laurent. These patches add the necessary DT configuration to use the WLAN part of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze). I've tested these changes on Panda and it works fine. But I couldn't test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having problems with clocks and SDIO stuff. So it's pretty much just compiled tested. I've tried this (without the new clock definition stuff) on Blaze with 3.10 and it was working, though. Please take a look and let me know what you think. Luca. Luciano Coelho (4): ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration arm: dts: omap4-panda-common: add WiLink6 device tree nodes ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration arm: dts: omap4-sdp: add WiLink7 device tree node arch/arm/boot/dts/omap4-panda-common.dtsi | 46 +++- arch/arm/boot/dts/omap4-sdp.dts | 50 +++ 2 files changed, 95 insertions(+), 1 deletion(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
*/
clock-frequency = <1920>;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 11 0>; /* gpio line 43 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -132,6 +142,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&hsusbb1_pins
+ &wilink_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x66 0x3/* gpio_43 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -314,8 +338,13 @@
};
&mmc5 {
- ti,non-removable;
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] arm: dts: omap4-sdp: add WiLink7 device tree node
Add appropriate device tree node for Blaze's WiLink7 module. It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO. Additionally, add the clock
frequencies used by the module.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-sdp.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..63f1af1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -7,6 +7,7 @@
*/
/dts-v1/;
+#include
#include "omap443x.dtsi"
#include "elpida_ecb240abacn.dtsi"
@@ -150,6 +151,26 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink7";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock &tcxoclock>;
+ clock-names = "refclock tcxoclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ };
+
+ tcxoclock: tcxoclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ };
+};
};
&omap4_pmx_wkup {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-sdp.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
"DMic", "Digital Mic",
"Digital Mic", "Digital Mic1 Bias";
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 22 0>; /* gpio line 54 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -166,6 +176,7 @@
&mcbsp2_pins
&dss_hdmi_pins
&tpd12s015_pins
+ &wilink_pins
>;
uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x7c 0x3/* gpio_54 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -420,8 +444,13 @@
};
&mmc5 {
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] arm: dts: omap4-panda-common: add WiLink6 device tree nodes
Add the WiLink device tree nodes. On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used. The refclock
frequency is 38.4MHz.
Signed-off-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..59a797d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -5,6 +5,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include "elpida_ecb240abacn.dtsi"
/ {
@@ -117,6 +118,20 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ };
+};
};
&omap4_pmx_wkup {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
On Tue, 2013-07-30 at 15:35 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-30 06:04:34)
> > +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);
>
> Hi Luciano,
Hi Mike,
> Any reason for establishing your own compatible string if you just plan
> to use the fixed rate clock? You could just use "fixed-clock" compatible
> in your DTS.
The reason is that I can't call of_clk_init(), because this function is
not exported and my module can't use it. I would have to link with the
clk code to be able to call it.
Also, I reckoned that, since these clock cannot be used by anyone else
than the WiLink module itself, it would make sense to have a different
compatible string.
> I will be posting patches this week which makes the fixed-rate clock a
> proper driver and matches that compatible string to instantiate those
> clocks. That means that your driver could probably remove the clock
> setup code completely.
Okay, if this is done, then I could probably use "fixed-clock" directly,
since the driver itself will take care of going through the DT and
initializing all the fixed-clocks.
--
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
Hi Mark, On Wed, 2012-12-19 at 09:45 +, Mark Brown wrote: > On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote: > > > damn, this is still part of our v3.7-rc kernel. Original commit was done > > with no testing whatsoever and caused a big regression to (at least) > > TI's WiFi driver which depend on SDIO to function. > > > Too bad things break and even when reported nobody gives a rat's *** > > about them :-s > > I guess it's going to be even more of an issue going forward given the > recent events but FWIW it was always very unusual to see any review of > any TWL patches, the PMIC appeared to have been rather abandoned so the > only way of getting any testing was to put stuff in -next and hope. Unfortunately I don't know how many of us are using this specific platform with the latest kernel, so not much testing is done. > Mind you, if there is an issue it doesn't seem that serious given that > it took at least one kernel release before anyone noticed and even when > they did you're the first person who bothered to respond... To me it has been very serious. I had to revert a bunch of patches to be able to continue working with the mainline. It took me a while to see the bug because I've been away during the 3.6 cycle. I think one of the reasons not many people use the mainline with TWL is exactly because something seems to break on every new kernel release. I'm one of those who care and report things when I see them. I think saying that it is not important because only one person reported it is not a good excuse. I would at least have liked seeing an answer saying, "this can't be fixed because of this and that" or "can you try to fix it by doing this or that". -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 10:28 +, Mark Brown wrote: > On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote: > > > I think one of the reasons not many people use the mainline with TWL is > > exactly because something seems to break on every new kernel release. > > I'm one of those who care and report things when I see them. > > Well, it's a recursive thing - nobody works on mainline, nobody reviews > mainline code and therefore you shouldn't be surprised if there's > issues. Sure, it's a vicious circle. In any case, I still endure using it and going against the flow. ;) > > I think saying that it is not important because only one person reported > > it is not a good excuse. I would at least have liked seeing an answer > > saying, "this can't be fixed because of this and that" or "can you try > > to fix it by doing this or that". > > That's not what I'm saying. What I'm saying is that it's clearly not > the case that OMAP is completely broken here or anything, it appears to > be one particular system which it appears vanishingly few people cared > about in mainline even before all the stuff with TI recently. You're right. I also had problems with MMC in a Pandaboard too, but I didn't even bother investigating it (yet) because I can use my other setup. > Looking at your report the reason I didn't reply myself is most likely > to be a combination of my expectation that someone from TI would look at > OMAP problems (at the time there were hundreds of people working on > OMAP) and the lack of detail in your mail - the bisection report was a > bit unclear as you said that you'd reverted the patch "plus a couple of > associated patches" without saying what exactly you'd backed out and > there was no analysis of the problem to engage with. Right, my report was a bit vague indeed. What I meant by "plus a couple of associated patches" was the things that would break compilation if I reverted only the patch in question. Most likely I ended up reverting your whole patchset. I didn't provide further analysis because I had already spent too much time trying to figure out how to get my stuff to work. Reverting the patches locally and hoping someone would respond to my report was good enough for me at the time. I also agree that someone from OMAP should have picked it up, but my report went out exactly when the bomb was exploding inside TI. So that probably explains it. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 10:32 +, Mark Brown wrote: > On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote: > > > Sure. It must be a clock driver. I already have similar driver (for McPDM > > fclk > > clock) for twl6040. > > Let me check linux-next, if CCF is there for OMAP I can send the 32k clock > > driver soon (after writing it and testing it). It is going to be for 3.9 but > > we can roll it with us I think locally to resolv issues. > > Well, we still haven't got the foggiest idea what the actual problem is > beyond that it's probably related to the 32kHz clock in some way (unless > it was one of the other reverts that coincidentally made a difference, > but we don't know what they were) so it's unlikely that just randomly > implementing clock support is going to fix anything immediately here. This is exactly what I had to revert (as I mentioned in the other email, I had to revert the other patches otherwise compilation would break): 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings" e76ab829 "regulator: twl: Remove references to the twl4030 regulator" 029dd3ce "regulator: twl: Remove another unused variable warning" Let me know if you need more info. -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 11:56 +0100, Peter Ujfalusi wrote: > On 12/19/2012 11:45 AM, Luciano Coelho wrote: > >> Well, we still haven't got the foggiest idea what the actual problem is > >> beyond that it's probably related to the 32kHz clock in some way (unless > >> it was one of the other reverts that coincidentally made a difference, > >> but we don't know what they were) so it's unlikely that just randomly > >> implementing clock support is going to fix anything immediately here. > > > > This is exactly what I had to revert (as I mentioned in the other email, > > I had to revert the other patches otherwise compilation would break): > > > > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings" > > e76ab829 "regulator: twl: Remove references to the twl4030 regulator" > > 029dd3ce "regulator: twl: Remove another unused variable warning" > > Yeah. 32k clock is not provided by twl. > > As I said I need to take a look at CCF to see if it already there. If it is > clock driver + mapping + patch for wl12xx should fix the issue you are facing. > > > Let me know if you need more info. > > BTW: have you happened to ubdate u-boot recently? There is a nice easter egg > added there: > f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. > > Which means that _essential_ clocks and pads are no longer configured. Actually no, I haven't updated my u-boot for a while. I'll check if that improves things. -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32kHz clock removal causes problems omap_hsmmc
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote: > On 12/19/2012 02:01 PM, Felipe Balbi wrote: > > On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote: > >> BTW: have you happened to ubdate u-boot recently? There is a nice easter > >> egg > >> added there: > >> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls. > >> > >> Which means that _essential_ clocks and pads are no longer configured. > > > > anything essential you can list ? > > Yeah, that u-boot version is just unusable at all with any mainline > kernel, since we are still missing pads conf for every drivers. > > Regarding the 32k clock, I noticed as well that the OMAP4460 panda > u-boot is the only one to enable it at boot time, and thus this is the > only board that can probe the wilink chip properly as of today. Do you mean that with the latest mainline u-boot all boards will have trouble except panda? I'm still reorganizing everything and update my stuff with the latest mainline u-boot, but at least blaze and panda now boot and recognize their wilink chips (with the patches I mentioned reverted). Now I'll try to remove my reverts and see what happens. -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: omap4-panda: add WiLink shared transport power functions
The code to enable and disable the WiLink shared transport has been
removed from the TI-ST driver, so it must be implemented in the board
files instead. Add the relevant operations to Panda's board file.
Additionally, add the UART2 muxing data, so it's properly configured.
Signed-off-by: Luciano Coelho
---
arch/arm/mach-omap2/board-omap4panda.c | 57 +---
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5c8e9ce..97a274b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -51,18 +51,57 @@
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
#define GPIO_WIFI_IRQ 53
+#define GPIO_BT_EN 46
/* wl127x BT, FM, GPS connectivity chip */
+static int plat_kim_chip_enable(struct kim_data_s *kim_data)
+{
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+ mdelay(5);
+ gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
+ mdelay(100);
+
+ return 0;
+}
+
+static int plat_kim_chip_disable(struct kim_data_s *kim_data)
+{
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+ mdelay(1);
+ gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
+ mdelay(1);
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+
+ return 0;
+}
+
static struct ti_st_plat_data wilink_platform_data = {
- .nshutdown_gpio = 46,
.dev_name = "/dev/ttyO1",
.flow_cntrl = 1,
.baud_rate = 300,
- .chip_enable= NULL,
- .suspend= NULL,
- .resume = NULL,
+ .chip_enable= plat_kim_chip_enable,
+ .chip_disable = plat_kim_chip_disable,
};
+static int wilink_st_init(void)
+{
+ int status;
+
+ status = gpio_request(GPIO_BT_EN, "kim");
+ if (status) {
+ pr_err("%s: failed to request gpio %d\n", __func__,
+ GPIO_BT_EN);
+ return status;
+ }
+
+ status = gpio_direction_output(GPIO_BT_EN, 0);
+ if (status)
+ pr_err("%s: unable to configure gpio %d", __func__,
+ GPIO_BT_EN);
+
+ return status;
+}
+
static struct platform_device wl1271_device = {
.name = "kim",
.id = -1,
@@ -397,6 +436,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* UART2 - BT/FM/GPS shared transport */
+ OMAP4_MUX(UART2_CTS,OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RTS,OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -433,6 +478,10 @@ static void __init omap4_panda_init(void)
if (ret)
pr_err("error setting wl12xx data: %d\n", ret);
+ ret = wilink_st_init();
+ if (ret)
+ pr_err("WiLink shared transport init failed: %d\n", ret);
+
omap4_panda_init_rev();
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap4-panda: add WiLink shared transport power functions
On Wed, 2013-01-16 at 19:10 -0200, Fabio Estevam wrote:
> On Wed, Jan 16, 2013 at 6:34 PM, Luciano Coelho wrote:
>
> > +static int wilink_st_init(void)
> > +{
> > + int status;
> > +
> > + status = gpio_request(GPIO_BT_EN, "kim");
> > + if (status) {
> > + pr_err("%s: failed to request gpio %d\n", __func__,
> > + GPIO_BT_EN);
> > + return status;
> > + }
> > +
> > + status = gpio_direction_output(GPIO_BT_EN, 0);
> > + if (status)
> > + pr_err("%s: unable to configure gpio %d", __func__,
> > + GPIO_BT_EN);
> > +
>
> You could use gpio_request_one() instead.
Good point. I'll send v2 using this instead:
gpio_request_one(GPIO_BT_EN, GPIOF_OUT_INIT_LOW, "kim")
--
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
The code to enable and disable the WiLink shared transport has been
removed from the TI-ST driver, so it must be implemented in the board
files instead. Add the relevant operations to Panda's board file.
Additionally, add the UART2 muxing data, so it's properly configured.
Cc: stable [3.7]
Signed-off-by: Luciano Coelho
---
In v2: use gpio_request_one() instead of gpio_request() and
gpio_direction_output(). (Thanks Fabio!)
arch/arm/mach-omap2/board-omap4panda.c | 50 +---
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5c8e9ce..f44fccf 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -51,18 +51,50 @@
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
#define GPIO_WIFI_IRQ 53
+#define GPIO_BT_EN 46
/* wl127x BT, FM, GPS connectivity chip */
+static int plat_kim_chip_enable(struct kim_data_s *kim_data)
+{
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+ mdelay(5);
+ gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
+ mdelay(100);
+
+ return 0;
+}
+
+static int plat_kim_chip_disable(struct kim_data_s *kim_data)
+{
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+ mdelay(1);
+ gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
+ mdelay(1);
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+
+ return 0;
+}
+
static struct ti_st_plat_data wilink_platform_data = {
- .nshutdown_gpio = 46,
.dev_name = "/dev/ttyO1",
.flow_cntrl = 1,
.baud_rate = 300,
- .chip_enable= NULL,
- .suspend= NULL,
- .resume = NULL,
+ .chip_enable= plat_kim_chip_enable,
+ .chip_disable = plat_kim_chip_disable,
};
+static int wilink_st_init(void)
+{
+ int status;
+
+ status = gpio_request_one(GPIO_BT_EN, GPIOF_OUT_INIT_LOW, "kim");
+ if (status)
+ pr_err("%s: failed to request gpio %d\n", __func__,
+ GPIO_BT_EN);
+
+ return status;
+}
+
static struct platform_device wl1271_device = {
.name = "kim",
.id = -1,
@@ -397,6 +429,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* UART2 - BT/FM/GPS shared transport */
+ OMAP4_MUX(UART2_CTS,OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RTS,OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -433,6 +471,10 @@ static void __init omap4_panda_init(void)
if (ret)
pr_err("error setting wl12xx data: %d\n", ret);
+ ret = wilink_st_init();
+ if (ret)
+ pr_err("WiLink shared transport init failed: %d\n", ret);
+
omap4_panda_init_rev();
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] OMAP: 4430sdp: add shared trasport devices to the board file
Add the btwilink, nfcwilink and shared transport devices to the board
file, including functions to power things on and off.
Additionally, add the UART2 muxing data, so it's properly configured.
Signed-off-by: Luciano Coelho
---
This is pretty much the same as the patch I just sent for panda, but
there were a few more things missing in the 4430sdp board file and I
also included NFC support.
I'm sending this as RFC because I'm not sure this is the right thing
to do for 4430sdp. This configuration works when the WiLink COM8
module is installed. The WLAN support is already hardcoded in this
file, so adding shared transport (BT/NFC/FM/GPS) support at least
won't make things much worse.
Additionally, only WiLink8 has optional support for NFC and I'm not
sure there is a way to figure that out at runtime.
arch/arm/mach-omap2/board-4430sdp.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1cc6696..7cf273e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -53,6 +55,7 @@
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
+#define GPIO_BT_EN 55
#define GPIO_WIFI_PMENA54
#define GPIO_WIFI_IRQ 53
@@ -408,6 +411,66 @@ static struct platform_device sdp4430_abe_audio = {
},
};
+/* TI shared transport for Bluetooth and NFC */
+static int plat_kim_chip_enable(struct kim_data_s *kim_data)
+{
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+ mdelay(5);
+ gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
+ mdelay(100);
+
+ return 0;
+}
+
+static int plat_kim_chip_disable(struct kim_data_s *kim_data)
+{
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+ mdelay(1);
+ gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
+ mdelay(1);
+ gpio_set_value(GPIO_BT_EN, GPIO_LOW);
+
+ return 0;
+}
+
+static struct ti_st_plat_data wilink_pdata = {
+ .dev_name = "/dev/ttyO1",
+ .flow_cntrl = 1,
+ .baud_rate = 300,
+ .chip_enable= plat_kim_chip_enable,
+ .chip_disable = plat_kim_chip_disable,
+};
+
+static int wilink_st_init(void)
+{
+ int status;
+
+ status = gpio_request_one(GPIO_BT_EN, GPIOF_OUT_INIT_LOW, "kim");
+ if (status)
+ pr_err("%s: failed to request gpio %d\n", __func__,
+ GPIO_BT_EN);
+
+ return status;
+}
+
+static struct platform_device wl12xx_device = {
+ .name = "kim",
+ .id = -1,
+ .dev = {
+ .platform_data = &wilink_pdata,
+ },
+};
+
+static struct platform_device btwilink_device = {
+ .name = "btwilink",
+ .id = -1,
+};
+
+static struct platform_device nfcwilink_device = {
+ .name = "nfcwilink",
+ .id = -1,
+};
+
static struct platform_device *sdp4430_devices[] __initdata = {
&sdp4430_gpio_keys_device,
&sdp4430_leds_gpio,
@@ -416,6 +479,9 @@ static struct platform_device *sdp4430_devices[] __initdata
= {
&sdp4430_dmic_codec,
&sdp4430_abe_audio,
&sdp4430_hdmi_audio_codec,
+ &wl12xx_device,
+ &btwilink_device,
+ &nfcwilink_device,
};
static struct omap_musb_board_data musb_board_data = {
@@ -632,6 +698,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* UART2 - BT/FM/GPS shared transport */
+ OMAP4_MUX(UART2_CTS,OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RTS,OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -711,6 +783,10 @@ static void __init omap_4430sdp_init(void)
if (status)
pr_err("Keypad initialization failed: %d\n", status);
+ status = wilink_st_init();
+ if (status)
+ pr_err("WiLink shared transport init failed: %d\n", status);
+
omap_4430sdp_display_init();
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, 2013-01-17 at 10:30 +0100, Peter Ujfalusi wrote:
> Hi Luca,
Hi Péter!
> On 01/16/2013 10:45 PM, Luciano Coelho wrote:
> > static struct ti_st_plat_data wilink_platform_data = {
> > - .nshutdown_gpio = 46,
> > .dev_name = "/dev/ttyO1",
> > .flow_cntrl = 1,
> > .baud_rate = 300,
> > - .chip_enable= NULL,
> > - .suspend= NULL,
> > - .resume = NULL,
> > + .chip_enable= plat_kim_chip_enable,
> > + .chip_disable = plat_kim_chip_disable,
>
> I just wonder how this is going to work with DT... You are not going to have
> the ability to use callback in this form.
> I think the GPIO handling should be done in the driver itself rather than in
> the board file.
I agree. The problem is that it used to be in the ti-st driver itself,
but it has been removed in a patch that says "different platforms have
begun to have their own ways to power-up/down the chip." (eccf2979
drivers/misc/ti-st: remove gpio handling).
This needs to be clarified first. I think we could use this for now and
later fix this properly (hopefully move it back to the ti-st driver).
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, 2013-01-17 at 12:09 +0200, Felipe Balbi wrote: > On Thu, Jan 17, 2013 at 12:05:10PM +0200, Felipe Balbi wrote: > > Hi, > > > > On Thu, Jan 17, 2013 at 10:55:14AM +0100, Peter Ujfalusi wrote: > > > On 01/17/2013 10:34 AM, Felipe Balbi wrote: > > > >> I just wonder how this is going to work with DT... You are not going > > > >> to have > > > >> the ability to use callback in this form. > > > >> I think the GPIO handling should be done in the driver itself rather > > > >> than in > > > >> the board file. > > > > > > > > that can (should ?) be moved to ti-st eventually. In fact I don't know > > > > why it was removed in the first place, we would need Pavan to help us > > > > with that query. > > > > > > Yes, this is a good question. I don't know what is the spacial thing > > > platforms > > > need to do in the callback.. > > hah! looks like I found the reason: > > http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-44xx-54xx-connectivity.c;h=e4852b93e91b6daa8f85cca91a1e7fbcc778f45b;hb=594aedd9e7da0491523411f8999efd98297f4fe4#l177 > > IMHO: > > a) removing gpio handling wasn't necessary, we could just check > if gpio_is_valid(nshutdown_gpio) > > b) that whole omap_serial_ext_uart_enable() looks really hacky. I'm sure > we can come up with something better. > This out-of-tree code doesn't explain why we need to do the enable/disable in the board file. We just need to do things a bit differently in the driver. I'll start cleaning all this stuff up for -next pretty soon. For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so that TI-ST at least works on Panda? Simply reverting the gpio removal patch doesn't help, because we also need to handle the UART2 muxing (which my patch does as well). -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Hi Tony, On Thu, 2013-01-17 at 09:31 -0800, Tony Lindgren wrote: > * Peter Ujfalusi [130117 02:44]: > > On 01/17/2013 11:35 AM, Luciano Coelho wrote: > > > This out-of-tree code doesn't explain why we need to do the > > > enable/disable in the board file. We just need to do things a bit > > > differently in the driver. I'll start cleaning all this stuff up for > > > -next pretty soon. > > > > > > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so > > > that TI-ST at least works on Panda? Simply reverting the gpio removal > > > patch doesn't help, because we also need to handle the UART2 muxing > > > (which my patch does as well). > > > > I don't see better way to fix this either. In any case, I give you my: > > > > Reviewed-by: Peter Ujfalusi > > So what is actually broken? The horrible bluetooth muxing over serial > port? If so, let's rather fix it properly than even attempt to fix > it as it seems that it's been broken for two merge windows now. Yes, it is the horrible Bluetooth muxing over serial that is broken. It has been broken for two merge windows, because nobody seemed to care until I started looking into it and tried to figure out how to get it to work. :) The implementation is really weak and there are loads of things I want to start fixing/cleaning up. This patch was just my intention to start with a relatively clean table (ie. horrible or not, at least working). > Also, let's just do absolutely minimal board-*.c file fixes now. > This thing should be just moved to use DT so we can flip over omap4 > to be DT only and drop estimated 5k LOC from mach-omap2. I totally agree, I'll start looking into that next. But this patch is pretty small and simple, so why not include it to at least fix the breakage in 3.7 and 3.8? Whether you take it or not now won't make any difference in the 5k LOC in these kernel versions. -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote: > * Luciano Coelho [130117 10:04]: > > But this patch is pretty small and simple, so why not include it to at > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now > > won't make any difference in the 5k LOC in these kernel versions. > > Well we are planning to drop the non-DT support for omap4 as soon as it's > usable with DT. For omap4 we are only carrying SDP and panda support to > make this transition easier. The only bindings missing AFAIK are wl12xx and > USB. In my view this is a regression and it should be fixed with as simple a patch as possible. The alternative to my solution is to revert the patch that removed the enable/disable from the ti-st driver *and* fix u-boot, because if it doesn't mux the UART2 pins properly (and it doesn't) the shared transport still won't work. > If we add this, then it implies we're somehow supporting it, which is not > the way to go IMHO as we need to get rid of these platform callbacks instead. It's a regression fix, not a new feature. I also think these callbacks are silly, but it's the quickest solution I found for 3.7 and 3.8. > What's your estimate of having minimal wl12xx WLAN DT binding available? To tell you the truth, I haven't even started looking into DT for wl12xx myself. So I have no idea when it will be ready. Benoit has been looking into it, but I don't know how far he is. -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote: > * Luciano Coelho [130118 01:03]: > > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote: > > > * Luciano Coelho [130117 10:04]: > > > > But this patch is pretty small and simple, so why not include it to at > > > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now > > > > won't make any difference in the 5k LOC in these kernel versions. > > > > > > Well we are planning to drop the non-DT support for omap4 as soon as it's > > > usable with DT. For omap4 we are only carrying SDP and panda support to > > > make this transition easier. The only bindings missing AFAIK are wl12xx > > > and > > > USB. > > > > In my view this is a regression and it should be fixed with as simple a > > patch as possible. The alternative to my solution is to revert the > > patch that removed the enable/disable from the ti-st driver *and* fix > > u-boot, because if it doesn't mux the UART2 pins properly (and it > > doesn't) the shared transport still won't work. > > Fixing the muxing here makes sense naturally as we cannot do that in the > driver > until we've flipped things over to use DT. > > But I don't think we should fix the driver regression by adding more platform > callbacks as we are getting rid of them anyways. Okay, you're right. We need at least to pass the GPIO number from the board file to the driver so that it knows what to switch. This is also something that it will need from DT in the future. > > > If we add this, then it implies we're somehow supporting it, which is not > > > the way to go IMHO as we need to get rid of these platform callbacks > > > instead. > > > > It's a regression fix, not a new feature. I also think these callbacks > > are silly, but it's the quickest solution I found for 3.7 and 3.8. > > Right, so how about let's fix the regression in the driver, and add the > muxing to platform init code? Agreed. I'll cook up a patch to revert the changes in eccf2979 (it doesn't revert cleanly) and change the panda board file to do the muxing and set the gpio number in the pdata for the driver to use. > > > What's your estimate of having minimal wl12xx WLAN DT binding available? > > > > To tell you the truth, I haven't even started looking into DT for wl12xx > > myself. So I have no idea when it will be ready. Benoit has been > > looking into it, but I don't know how far he is. > > If it's going to take long we should just init the platform data for > it temporarily even in the DT boot case until the binding is available. I'll start looking into this now. It's not going to be that simple, I'm sure, but I need to look more into DT in general to be able to say something more accurate. I'll let you know as soon as I know more. :) -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
