The following series adds support for an optional wl12xx based expansion
card for the AM18x EVM:
http://processors.wiki.ti.com/index.php/AM18x_%2B_WL1271
The first couple of patches address issues which had to be fixed for this
series to work. However, these should be fixed regardless of the wl12xx
daughter board support.
Only the Wi-Fi functionality of the expansion card is supported. Bluetooth
functionality is not yet supported.
The patches are based on v3.0-rc6.
Changes from v1:
* Explicitly set the default queue for all channel controllers on all
platforms. As it makes little sense to set DA850's default queue to an
invalid value and then fix it, merge the two patches
* Move pinmux configurations to separate patches
* Remove FREF Kconfig entry, use a default value of 38MHz instead
* Use msleep for long delays, usleep_range for shorter ones
* Minor cleanups
Ido.
Ido Yariv (6):
arm: davinci: Fix low level gpio irq handlers' argument
arm: davinci: Explicitly set channel controllers' default queues
arm: davinci: mmc: Add support for set_power callback
arm: davinci: DA850: Add MMC/SD1 pinmux configuration
arm: davinci: DA850: Add GPIO pinmux configuration for wl1271
arm: davinci: DA850: Add wl1271/wlan support
arch/arm/mach-davinci/Kconfig | 10 +++
arch/arm/mach-davinci/board-da850-evm.c | 127 +++++++++++++++++++++++++++++
arch/arm/mach-davinci/da850.c | 9 ++
arch/arm/mach-davinci/devices-da8xx.c | 3 +
arch/arm/mach-davinci/devices-tnetv107x.c | 1 +
arch/arm/mach-davinci/dm355.c | 1 +
arch/arm/mach-davinci/dm644x.c | 1 +
arch/arm/mach-davinci/dm646x.c | 1 +
arch/arm/mach-davinci/dma.c | 2 -
arch/arm/mach-davinci/gpio.c | 32 +++++++-
arch/arm/mach-davinci/include/mach/mmc.h | 3 +
arch/arm/mach-davinci/include/mach/mux.h | 10 +++
drivers/mmc/host/davinci_mmc.c | 13 +++
13 files changed, 207 insertions(+), 6 deletions(-)
--
1.7.4.1
Commit 7416401 ("arm: davinci: Fix fallout from generic irq chip
conversion") introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.
Fix this by converting gpio_irq_handler's bank_irq argument to the
corresponding irq base number.
Signed-off-by: Ido Yariv <redacted>
CC: Thomas Gleixner <redacted>
---
arch/arm/mach-davinci/gpio.c | 32 ++++++++++++++++++++++++++++----
1 files changed, 28 insertions(+), 4 deletions(-)
@@ -249,16 +249,40 @@ static struct irq_chip gpio_irqchip = {.flags=IRQCHIP_SET_TYPE_MASKED,};+staticinlineintbankirq_to_irqbase(unsignedintbank_irq)+{+intgpio;+intindex;++/* Each irq bank consists of up to 16 irqs */+gpio=16*(bank_irq-davinci_soc_info.gpio_irq);++/* Each controller controls 32 GPIOs */+index=gpio/32;++if(unlikely(!davinci_soc_info.gpio_ctlrs))+return-EINVAL;++if(unlikely(index>=davinci_soc_info.gpio_ctlrs_num))+return-EINVAL;++returndavinci_soc_info.gpio_ctlrs[index].irq_base;+}+staticvoid-gpio_irq_handler(unsignedirq,structirq_desc*desc)+gpio_irq_handler(unsignedbank_irq,structirq_desc*desc){structdavinci_gpio_regs__iomem*g;u32mask=0xffff;+intirqbase=bankirq_to_irqbase(bank_irq);++if(unlikely(irqbase<0))+return;g=(__forcestructdavinci_gpio_regs__iomem*)irq_desc_get_handler_data(desc);/* we only care about one bank */-if(irq&1)+if(bank_irq&1)mask<<=16;/* temporarily mask (level sensitive) parent IRQ */
@@ -274,11 +298,11 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)if(!status)break;__raw_writel(status,&g->intstat);-if(irq&1)+if(bank_irq&1)status>>=16;/* now demux them to the right lowlevel handler */-n=(int)irq_get_handler_data(irq);+n=irqbase;while(status){res=ffs(status);n+=res;
Davinci platforms may define a default queue for each channel
controller. If one is not defined, the default queue is set to EVENTQ_1.
However, there's no way to distinguish between an unset default queue to
one that is set to EVENTQ_0, as EVENTQ_0 = 0.
Explicitly specify the default queue for all channel controllers on all
Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
function.
One exception is the DA850 board, for which EVENTQ_1 is not a valid
option for its second channel controller. Use EVENTQ_0 instead for that
channel controller.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/devices-da8xx.c | 3 +++
arch/arm/mach-davinci/devices-tnetv107x.c | 1 +
arch/arm/mach-davinci/dm355.c | 1 +
arch/arm/mach-davinci/dm644x.c | 1 +
arch/arm/mach-davinci/dm646x.c | 1 +
arch/arm/mach-davinci/dma.c | 2 --
6 files changed, 7 insertions(+), 2 deletions(-)
Some devices connected to the MMC bus are power controlled by external
means. For instance, an SDIO device may be powered down/up by an
external gpio line.
In order to avoid toggling power from within the MMC host driver, add a
set_power callback function, which will be called by set_ios upon
powering down/up.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/include/mach/mmc.h | 3 +++
drivers/mmc/host/davinci_mmc.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
The wl1271 daughter board makes use of a few GPIOs:
GPIO6_9 is used for powering down/up the WLAN functionality.
GPIO6_10 is used as an input IRQ line from the WLAN chip.
Add the required pinmux configuration for these GPIOs.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/da850.c | 2 ++
arch/arm/mach-davinci/include/mach/mux.h | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
This patch adds support for the WLAN capabilities of this expansion
board.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/Kconfig | 10 +++
arch/arm/mach-davinci/board-da850-evm.c | 127 +++++++++++++++++++++++++++++++
2 files changed, 137 insertions(+), 0 deletions(-)
Hi Ido,
On Sun, Jul 10, 2011 at 18:44:34, Ido Yariv wrote:
quoted hunk
Commit 7416401 ("arm: davinci: Fix fallout from generic irq chip
conversion") introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.
Fix this by converting gpio_irq_handler's bank_irq argument to the
corresponding irq base number.
Signed-off-by: Ido Yariv <redacted>
CC: Thomas Gleixner <redacted>
---
arch/arm/mach-davinci/gpio.c | 32 ++++++++++++++++++++++++++++----
1 files changed, 28 insertions(+), 4 deletions(-)
@@ -249,16 +249,40 @@ static struct irq_chip gpio_irqchip = {.flags=IRQCHIP_SET_TYPE_MASKED,};+staticinlineintbankirq_to_irqbase(unsignedintbank_irq)+{+intgpio;+intindex;++/* Each irq bank consists of up to 16 irqs */+gpio=16*(bank_irq-davinci_soc_info.gpio_irq);++/* Each controller controls 32 GPIOs */+index=gpio/32;++if(unlikely(!davinci_soc_info.gpio_ctlrs))+return-EINVAL;++if(unlikely(index>=davinci_soc_info.gpio_ctlrs_num))+return-EINVAL;++returndavinci_soc_info.gpio_ctlrs[index].irq_base;+}+staticvoid-gpio_irq_handler(unsignedirq,structirq_desc*desc)+gpio_irq_handler(unsignedbank_irq,structirq_desc*desc){structdavinci_gpio_regs__iomem*g;u32mask=0xffff;+intirqbase=bankirq_to_irqbase(bank_irq);++if(unlikely(irqbase<0))+return;g=(__forcestructdavinci_gpio_regs__iomem*)irq_desc_get_handler_data(desc);/* we only care about one bank */-if(irq&1)+if(bank_irq&1)mask<<=16;/* temporarily mask (level sensitive) parent IRQ */
@@ -274,11 +298,11 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)if(!status)break;__raw_writel(status,&g->intstat);-if(irq&1)+if(bank_irq&1)status>>=16;/* now demux them to the right lowlevel handler */-n=(int)irq_get_handler_data(irq);+n=irqbase;while(status){res=ffs(status);n+=res;
Thanks for the bug fix.
How about setting the handler data for bank IRQ in
davinci_gpio_irq_setup() to &chips[bank]?
chips[bank].regs should give you the register base address
(g) and chips[bank].irq_base should give you 'n'.
Also please drop the rename of irq to bank_irq as it is not
central to the bug fix.
If you spin in soon enough, we may make it to v3.0
Thanks,
Sekhar
Hi Sekhar,
On Mon, Jul 11, 2011 at 05:28:44PM +0530, Nori, Sekhar wrote:
Thanks for the bug fix.
How about setting the handler data for bank IRQ in
davinci_gpio_irq_setup() to &chips[bank]?
chips[bank].regs should give you the register base address
(g) and chips[bank].irq_base should give you 'n'.
Also please drop the rename of irq to bank_irq as it is not
central to the bug fix.
If you spin in soon enough, we may make it to v3.0
Sure, I'll send a v3 in a few.
Thanks for the review,
Ido.
Commit 7416401 ("arm: davinci: Fix fallout from generic irq chip
conversion") introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.
Set the irq handler data to be a pointer to the corresponding gpio
controller. The chained irq handler can then use it to extract both the
irq base number and the gpio registers structure.
Signed-off-by: Ido Yariv <redacted>
CC: Thomas Gleixner <redacted>
---
arch/arm/mach-davinci/gpio.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
@@ -254,8 +254,10 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc){structdavinci_gpio_regs__iomem*g;u32mask=0xffff;+structdavinci_gpio_controller*ctl;-g=(__forcestructdavinci_gpio_regs__iomem*)irq_desc_get_handler_data(desc);+ctl=(structdavinci_gpio_controller*)irq_desc_get_handler_data(desc);+g=(structdavinci_gpio_regs__iomem*)ctl->regs;/* we only care about one bank */if(irq&1)
@@ -278,7 +280,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)status>>=16;/* now demux them to the right lowlevel handler */-n=(int)irq_get_handler_data(irq);+n=ctl->irq_base;while(status){res=ffs(status);n+=res;
@@ -424,7 +426,13 @@ static int __init davinci_gpio_irq_setup(void)/* set up all irqs in this bank */irq_set_chained_handler(bank_irq,gpio_irq_handler);-irq_set_handler_data(bank_irq,(__forcevoid*)g);++/*+*Eachchiphandles32gpios,andeachirqbankconsistsof16+*gpioirqs.Passtheirqbank'scorrespondingcontrollerto+*thechainedirqhandler.+*/+irq_set_handler_data(bank_irq,&chips[bank*16/32]);for(i=0;i<16&&gpio<ngpio;i++,irq++,gpio++){irq_set_chip(irq,&gpio_irqchip);
Hi Ido,
On Tue, Jul 12, 2011 at 02:33:11, Ido Yariv wrote:
quoted hunk
Commit 7416401 ("arm: davinci: Fix fallout from generic irq chip
conversion") introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.
Set the irq handler data to be a pointer to the corresponding gpio
controller. The chained irq handler can then use it to extract both the
irq base number and the gpio registers structure.
Signed-off-by: Ido Yariv <redacted>
CC: Thomas Gleixner <redacted>
---
arch/arm/mach-davinci/gpio.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
Lets call the variable "d" to be consistent with the rest of the file.
quoted hunk
- g = (__force struct davinci_gpio_regs __iomem *) irq_desc_get_handler_data(desc);
+ ctl = (struct davinci_gpio_controller *)irq_desc_get_handler_data(desc);
+ g = (struct davinci_gpio_regs __iomem *)ctl->regs;
/* we only care about one bank */
if (irq & 1)
@@ -278,7 +280,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) status >>= 16; /* now demux them to the right lowlevel handler */- n = (int)irq_get_handler_data(irq);+ n = ctl->irq_base;
I realized that this breaks for odd banks as the status is
right shifted by 16. The GPIO you are using must have been
in even bank?
quoted hunk
while (status) {
res = ffs(status);
n += res;
@@ -424,7 +426,13 @@ static int __init davinci_gpio_irq_setup(void) /* set up all irqs in this bank */ irq_set_chained_handler(bank_irq, gpio_irq_handler);- irq_set_handler_data(bank_irq, (__force void *)g);++ /*+ * Each chip handles 32 gpios, and each irq bank consists of 16+ * gpio irqs. Pass the irq bank's corresponding controller to+ * the chained irq handler.+ */+ irq_set_handler_data(bank_irq, &chips[bank * 16 / 32]);
This can simply be:
irq_set_handler_data(bank_irq, &chips[gpio / 32]);
In the interest of time, I did these fixes and pushed the
patch to "fixes" branch of git://gitorious.org/linux-davinci/linux-davinci.git
Can you please test it out and let me know if it works.
Updated patch also attached.
Thanks,
Sekhar
8<---------------------
From: Ido Yariv <redacted>
Subject: arm: davinci: Fix low level gpio irq handlers' argument
Commit 7416401 ("arm: davinci: Fix fallout from generic irq chip
conversion") introduced a bug, causing low level interrupt handlers to
get a bogus irq number as an argument. The gpio irq handler falsely
assumes that the handler data is the irq base number and that is no
longer true.
Set the irq handler data to be a pointer to the corresponding gpio
controller. The chained irq handler can then use it to extract both the
irq base number and the gpio registers structure.
Signed-off-by: Ido Yariv <redacted>
CC: Thomas Gleixner <redacted>
[nsekhar at ti.com: renamed "ctl" to "d", simplified indexing logic for chips and
took care of odd bank handling in irq handler]
Signed-off-by: Sekhar Nori <redacted>
---
arch/arm/mach-davinci/gpio.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
@@ -254,8 +254,10 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc){structdavinci_gpio_regs__iomem*g;u32mask=0xffff;+structdavinci_gpio_controller*d;-g=(__forcestructdavinci_gpio_regs__iomem*)irq_desc_get_handler_data(desc);+d=(structdavinci_gpio_controller*)irq_desc_get_handler_data(desc);+g=(structdavinci_gpio_regs__iomem*)d->regs;/* we only care about one bank */if(irq&1)
@@ -274,11 +276,14 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)if(!status)break;__raw_writel(status,&g->intstat);-if(irq&1)-status>>=16;/* now demux them to the right lowlevel handler */-n=(int)irq_get_handler_data(irq);+n=d->irq_base;+if(irq&1){+n+=16;+status>>=16;+}+while(status){res=ffs(status);n+=res;
@@ -424,7 +429,13 @@ static int __init davinci_gpio_irq_setup(void)/* set up all irqs in this bank */irq_set_chained_handler(bank_irq,gpio_irq_handler);-irq_set_handler_data(bank_irq,(__forcevoid*)g);++/*+*Eachchiphandles32gpios,andeachirqbankconsistsof16+*gpioirqs.Passtheirqbank'scorrespondingcontrollerto+*thechainedirqhandler.+*/+irq_set_handler_data(bank_irq,&chips[gpio/32]);for(i=0;i<16&&gpio<ngpio;i++,irq++,gpio++){irq_set_chip(irq,&gpio_irqchip);
Hi Sekhar,
On Tue, Jul 12, 2011 at 02:52:17PM +0530, Nori, Sekhar wrote:
quoted
- g = (__force struct davinci_gpio_regs __iomem *) irq_desc_get_handler_data(desc);
+ ctl = (struct davinci_gpio_controller *)irq_desc_get_handler_data(desc);
+ g = (struct davinci_gpio_regs __iomem *)ctl->regs;
/* we only care about one bank */
if (irq & 1)
@@ -278,7 +280,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc) status >>= 16; /* now demux them to the right lowlevel handler */- n = (int)irq_get_handler_data(irq);+ n = ctl->irq_base;
I realized that this breaks for odd banks as the status is
right shifted by 16. The GPIO you are using must have been
in even bank?
You're absolutely right, I missed that. And yes, I have been using an
even bank GPIO.
quoted
while (status) {
res = ffs(status);
n += res;
@@ -424,7 +426,13 @@ static int __init davinci_gpio_irq_setup(void) /* set up all irqs in this bank */ irq_set_chained_handler(bank_irq, gpio_irq_handler);- irq_set_handler_data(bank_irq, (__force void *)g);++ /*+ * Each chip handles 32 gpios, and each irq bank consists of 16+ * gpio irqs. Pass the irq bank's corresponding controller to+ * the chained irq handler.+ */+ irq_set_handler_data(bank_irq, &chips[bank * 16 / 32]);
This can simply be:
irq_set_handler_data(bank_irq, &chips[gpio / 32]);
In the interest of time, I did these fixes and pushed the
patch to "fixes" branch of git://gitorious.org/linux-davinci/linux-davinci.git
Can you please test it out and let me know if it works.
This patch seems to work just fine. I'm afraid I can't test an odd bank
GPIO here to verify that this indeed fixed the issue you raised, but it
looks correct.
Thanks,
Ido.
On Sun, Jul 10, 2011 at 18:44:35, Ido Yariv wrote:
Davinci platforms may define a default queue for each channel
controller. If one is not defined, the default queue is set to EVENTQ_1.
However, there's no way to distinguish between an unset default queue to
one that is set to EVENTQ_0, as EVENTQ_0 = 0.
Explicitly specify the default queue for all channel controllers on all
Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
function.
One exception is the DA850 board, for which EVENTQ_1 is not a valid
option for its second channel controller. Use EVENTQ_0 instead for that
channel controller.
Signed-off-by: Ido Yariv <redacted>
Looks good to me. Will queue for v3.2/fixes
BTW, Arnd has indicated a preference for "ARM: davinci: "
prefix so I will make that change while applying.
Thanks,
Sekhar
On Sun, Jul 10, 2011 at 18:44:36, Ido Yariv wrote:
Some devices connected to the MMC bus are power controlled by external
means. For instance, an SDIO device may be powered down/up by an
external gpio line.
In order to avoid toggling power from within the MMC host driver, add a
set_power callback function, which will be called by set_ios upon
powering down/up.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/include/mach/mmc.h | 3 +++
drivers/mmc/host/davinci_mmc.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
This looks good to me, but needs Ack/Sign-off from
MMC maintainer. Please repost keeping him in CC.
Thanks,
Sekhar
On Sun, Jul 10, 2011 at 18:44:38, Ido Yariv wrote:
The wl1271 daughter board makes use of a few GPIOs:
GPIO6_9 is used for powering down/up the WLAN functionality.
GPIO6_10 is used as an input IRQ line from the WLAN chip.
Add the required pinmux configuration for these GPIOs.
Signed-off-by: Ido Yariv <redacted>
4/6 and 5/6 both look good, will queue for v3.2/features
Thanks,
Sekhar
From: Sergei Shtylyov <hidden> Date: 2011-07-25 13:33:45
Hello.
Nori, Sekhar wrote:
quoted
Davinci platforms may define a default queue for each channel
controller. If one is not defined, the default queue is set to EVENTQ_1.
However, there's no way to distinguish between an unset default queue to
one that is set to EVENTQ_0, as EVENTQ_0 = 0.
quoted
Explicitly specify the default queue for all channel controllers on all
Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
function.
quoted
One exception is the DA850 board, for which EVENTQ_1 is not a valid
option for its second channel controller. Use EVENTQ_0 instead for that
channel controller.
quoted
Signed-off-by: Ido Yariv <redacted>
Looks good to me. Will queue for v3.2/fixes
Why wait for 3.2? If this is considered a fix, it should be applied to 3.1, no?
WBR, Sergei
Hi Sergei,
On Mon, Jul 25, 2011 at 19:03:45, Sergei Shtylyov wrote:
Hello.
Nori, Sekhar wrote:
quoted
quoted
Davinci platforms may define a default queue for each channel
controller. If one is not defined, the default queue is set to EVENTQ_1.
However, there's no way to distinguish between an unset default queue to
one that is set to EVENTQ_0, as EVENTQ_0 = 0.
quoted
quoted
Explicitly specify the default queue for all channel controllers on all
Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
function.
quoted
quoted
One exception is the DA850 board, for which EVENTQ_1 is not a valid
option for its second channel controller. Use EVENTQ_0 instead for that
channel controller.
quoted
quoted
Signed-off-by: Ido Yariv <redacted>
quoted
Looks good to me. Will queue for v3.2/fixes
Why wait for 3.2? If this is considered a fix, it should be applied to 3.1, no?
3.2/fixes just indicates it will be queued as a fix/cleanup
for 3.2 so it will have higher priority for merge when compared
to a new feature.
This patch doesn't really fix any existing broken functionality.
It corrects event queue configuration for EDMA CC1 on DA850 for
which there are no current users in mainline.
So, not sending for v3.1.
Thanks,
Sekhar
On Sun, Jul 10, 2011 at 18:44:39, Ido Yariv wrote:
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
This patch adds support for the WLAN capabilities of this expansion
board.
Signed-off-by: Ido Yariv <redacted>
---
+#ifdef CONFIG_DA850_WL12XX
+
+static int da850_wl12xx_fref = WL12XX_REFCLOCK_38;
+
+static int __init setup_da850_wl12xx_fref(char *fref)
+{
+ if (!strcmp(fref, "19.2"))
+ da850_wl12xx_fref = WL12XX_REFCLOCK_19;
+ else if (!strcmp(fref, "26"))
+ da850_wl12xx_fref = WL12XX_REFCLOCK_26;
+ else if (!strcmp(fref, "38.4"))
+ da850_wl12xx_fref = WL12XX_REFCLOCK_38;
+ else if (!strcmp(fref, "52"))
+ da850_wl12xx_fref = WL12XX_REFCLOCK_52;
+ else if (!strcmp(fref, "XTAL26"))
+ da850_wl12xx_fref = WL12XX_REFCLOCK_26_XTAL;
+ else if (!strcmp(fref, "XTAL38.4"))
+ da850_wl12xx_fref = WL12XX_REFCLOCK_38_XTAL;
+ else
+ pr_info("da850_wl12xx_fref is invalid. Valid options: "
+ "19.2, 26, 38.4, 52, XTAL26 or XTAL38.4\n");
+ return 0;
+}
+__setup("da850_wl12xx_fref=", setup_da850_wl12xx_fref);
Adding a new kernel parameter requires update to
Documentation/kernel-parameters.txt as well.
I am Ccing a couple of folks in case they have ideas on
whether there is a better way to pass this information
to the kernel. I assume there is no way to detect
this from hardware.
Hi Sekhar,
On Mon, Jul 25, 2011 at 11:10:55PM +0530, Nori, Sekhar wrote:
Adding a new kernel parameter requires update to
Documentation/kernel-parameters.txt as well.
I am Ccing a couple of folks in case they have ideas on
whether there is a better way to pass this information
to the kernel. I assume there is no way to detect
this from hardware.
Unfortunately, auto-detection of the reference clock is not currently
possible. However, it might be a better idea to have the ability to
override this value with a wl12xx module parameter instead of a kernel
parameter. I'll drop this kernel parameter.
Some devices connected to the MMC bus are power controlled by external
means. For instance, an SDIO device may be powered down/up by an
external gpio line.
In order to avoid toggling power from within the MMC host driver, add a
set_power callback function, which will be called by set_ios upon
powering down/up.
Signed-off-by: Ido Yariv <redacted>
CC: Chris Ball <redacted>
---
arch/arm/mach-davinci/include/mach/mmc.h | 3 +++
drivers/mmc/host/davinci_mmc.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
Add support for the WLAN capabilities of this expansion board.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/Kconfig | 10 +++
arch/arm/mach-davinci/board-da850-evm.c | 114 +++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+), 0 deletions(-)
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
Add support for the WLAN capabilities of this expansion board.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/Kconfig | 10 +++
arch/arm/mach-davinci/board-da850-evm.c | 114 +++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+), 0 deletions(-)
@@ -1117,6 +1122,110 @@ static __init int da850_evm_init_cpufreq(void)static__initintda850_evm_init_cpufreq(void){return0;}#endif+#ifdef CONFIG_DA850_WL12XX++staticvoidwl12xx_set_power(intindex,boolpower_on)+{+staticboolpower_state;++pr_debug("Powering %s wl12xx",power_on?"on":"off");++if(power_on==power_state)+return;+power_state=power_on;++if(power_on){+/* Power up sequence required for wl127x devices */+gpio_set_value(DA850_WLAN_EN,1);+usleep_range(15000,15000);+gpio_set_value(DA850_WLAN_EN,0);+usleep_range(1000,1000);+gpio_set_value(DA850_WLAN_EN,1);+msleep(70);
Why turn on, then off, and then back on?
Isn't off, then back on sufficient?
Also, why not use regulator API like panda board does?
Hi Troy,
On Thu, Jul 28, 2011 at 02:15:41PM -0700, Troy Kisky wrote:
quoted
+ if (power_on) {
+ /* Power up sequence required for wl127x devices */
+ gpio_set_value(DA850_WLAN_EN, 1);
+ usleep_range(15000, 15000);
+ gpio_set_value(DA850_WLAN_EN, 0);
+ usleep_range(1000, 1000);
+ gpio_set_value(DA850_WLAN_EN, 1);
+ msleep(70);
Why turn on, then off, and then back on?
Isn't off, then back on sufficient?
Unfortunately, no. This is a required power up sequence for some
hardware revisions of the 1271 chip.
Also, why not use regulator API like panda board does?
Unlike omap_hsmmc, davinci's MMC host driver does not toggle any
regulators. To keep things simple, a set_power callback function was
added to the mmc host as part of this patch series.
I've considered adding regulator support instead, but found it to be
a bit over-complicated for this task. In addition, it would require
either modifying the fixed regulator or adding a new one in order to
support the above power sequence.
Thanks for your review,
Ido.
From: Ben Gardiner <hidden> Date: 2011-07-29 14:42:36
On Mon, Jul 25, 2011 at 12:31 PM, Nori, Sekhar [off-list ref] wrote:
Hi Sergei,
On Mon, Jul 25, 2011 at 19:03:45, Sergei Shtylyov wrote:
quoted
Hello.
Nori, Sekhar wrote:
quoted
quoted
Davinci platforms may define a default queue for each channel
controller. If one is not defined, the default queue is set to EVENTQ_1.
However, there's no way to distinguish between an unset default queue to
one that is set to EVENTQ_0, as EVENTQ_0 = 0.
quoted
quoted
Explicitly specify the default queue for all channel controllers on all
Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
function.
quoted
quoted
One exception is the DA850 board, for which EVENTQ_1 is not a valid
option for its second channel controller. Use EVENTQ_0 instead for that
channel controller.
quoted
quoted
Signed-off-by: Ido Yariv <redacted>
quoted
Looks good to me. Will queue for v3.2/fixes
? ? Why wait for 3.2? If this is considered a fix, it should be applied to 3.1, no?
3.2/fixes just indicates it will be queued as a fix/cleanup
for 3.2 so it will have higher priority for merge when compared
to a new feature.
This patch doesn't really fix any existing broken functionality.
It corrects event queue configuration for EDMA CC1 on DA850 for
which there are no current users in mainline.
So, not sending for v3.1.
If it's not too late:
Tested this patch and it fixes SD/MMC1 support on da850.
Tested-by: Ben Gardiner <redacted>
Thanks, Ido!
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
Hi Troy,
On Thu, Jul 28, 2011 at 02:15:41PM -0700, Troy Kisky wrote:
quoted
quoted
+ if (power_on) {
+ /* Power up sequence required for wl127x devices */
+ gpio_set_value(DA850_WLAN_EN, 1);
+ usleep_range(15000, 15000);
+ gpio_set_value(DA850_WLAN_EN, 0);
+ usleep_range(1000, 1000);
+ gpio_set_value(DA850_WLAN_EN, 1);
+ msleep(70);
Why turn on, then off, and then back on?
Isn't off, then back on sufficient?
Unfortunately, no. This is a required power up sequence for some
hardware revisions of the 1271 chip.
That's too bad.
quoted
Also, why not use regulator API like panda board does?
Unlike omap_hsmmc, davinci's MMC host driver does not toggle any
regulators. To keep things simple, a set_power callback function was
added to the mmc host as part of this patch series.
I've considered adding regulator support instead, but found it to be
a bit over-complicated for this task. In addition, it would require
either modifying the fixed regulator or adding a new one in order to
support the above power sequence.
Yes, that is more effort. I'm fine with your method, but with all
the consolidation effort that's being expended currently, it would
be nice if all boards could use a common method to power up sdio cards.
It might make a device tree implementation for this driver easier too,
though I am certainly no expert there.
Hi Ido,
On Fri, Jul 29, 2011 at 02:22:53, Ido Yariv wrote:
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
Add support for the WLAN capabilities of this expansion board.
Signed-off-by: Ido Yariv <redacted>
Can you please rebase this patch to master branch of my
tree[1] and repost. It doesn't apply at the moment.
Also, when you repost, please change the subject to
"ARM: davinci: AM18x: Add wl1271/wlan support"
so that it is consistent with other patches.
Thanks,
Sekhar
[1] git://gitorious.org/linux-davinci/linux-davinci.git
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
Add support for the WLAN capabilities of this expansion board.
Signed-off-by: Ido Yariv <redacted>
---
arch/arm/mach-davinci/Kconfig | 10 +++
arch/arm/mach-davinci/board-da850-evm.c | 114 +++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+), 0 deletions(-)
Hi Ido,
A quick question for my own understanding. What's the mechanism by
which wl12xx is bound with above. I see above wl12xx_set_platform_data
but I didn't see something like .name = "wl1271" or dev_name that
comes in through platform_device_register. If I look at other board
files, I see:
321 #ifdef CONFIG_WL12XX_PLATFORM_DATA
322 {
323 .name = "wl1271",
324 .mmc = 2,
325 .caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_POWER_OFF_CARD,
326 .gpio_wp = -EINVAL,
327 .gpio_cd = -EINVAL,
328 .nonremovable = true,
329 },
330 #endif
and
729 #ifdef CONFIG_WL12XX_PLATFORM_DATA
730 /* WL12xx WLAN Init */
731 if (wl12xx_set_platform_data(&omap3evm_wlan_data))
732 pr_err("error setting wl12xx data\n");
733 platform_device_register(&omap3evm_wlan_regulator);
734 #endif
Thanks,
jayakumar
Hi Jaya,
On Thu, Aug 04, 2011 at 04:40:01PM +0800, Jaya Kumar wrote:
Hi Ido,
A quick question for my own understanding. What's the mechanism by
which wl12xx is bound with above. I see above wl12xx_set_platform_data
but I didn't see something like .name = "wl1271" or dev_name that
comes in through platform_device_register.
The wl12xx module calls wl12xx_get_platform_data, which simply returns
the structure set by wl12xx_set_platform_data. This mechanism only
supports a single platform data.
If I look at other board files, I see:
321 #ifdef CONFIG_WL12XX_PLATFORM_DATA
322 {
323 .name = "wl1271",
324 .mmc = 2,
325 .caps = MMC_CAP_4_BIT_DATA |
MMC_CAP_POWER_OFF_CARD,
326 .gpio_wp = -EINVAL,
327 .gpio_cd = -EINVAL,
328 .nonremovable = true,
329 },
330 #endif
'name' is just a descriptive name of omap2_hsmmc_info. davinci_mmc_config
doesn't have such a member.
Please note that the platform_device_register above is used for
registering a regulator device, which is driven by the fixed regulator
driver and not by wl12xx. This regulator is controlled by omap's mmc
host driver.
Hope this clarifies things,
Ido.
On Thu, Aug 04, 2011 at 13:21:23, Ido Yariv wrote:
The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity
add-on card, based on the LS Research TiWi module with Texas
Instruments' wl1271 solution.
It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ
line and is power-controlled by a GPIO-based fixed regulator.
Add support for the WLAN capabilities of this expansion board.
Signed-off-by: Ido Yariv <redacted>