Re: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
Gururaja,
On 7/2/2013 11:42 AM, Sekhar Nori wrote:
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: b-cous...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
-compatible = ti,da830-rtc;
+compatible = ti,am3352-rtc;
compatible is a list so you can instead do:
compatible = ti,am3352-rtc, ti,da830-rtc;
That way the dts works irrespective of driver updates. When driver
supports enhanced features of hardware, they are available to the user
else the basic functionality still works.
On doing some experiments myself, the of_device_id which gets selected
during probe depends on the order in which its entry appears in the
match table inside the driver rather than how the compatible string is
written. I think this puts undue dependency on how the driver is
written, so I am okay with providing a single compatible value like the
way you have done ATM.
I do think the string appearing first in the compatible list is what
should be selected if a match is available but I am not sure if there
are other considerations due to which of_match_device() is written the
way it is written.
Thanks,
Sekhar
--
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] rtc: omap: add rtc wakeup support to alarm events
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
Changes in V2:
- Coding style corrections (use lower case for hex numbers)
- use [AM/am]3352 instead of [AM/am]335x to keep the all
usages in sync.
- Use index defined for struct members so they remain in sync
:100644 100644 b47aa41... 5a0f02d... M
Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 761919d... c2e18fe... M drivers/rtc/rtc-omap.c
Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +-
drivers/rtc/rtc-omap.c | 60 +---
2 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..5a0f02d 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -1,7 +1,11 @@
TI Real Time Clock
Required properties:
-- compatible: ti,da830-rtc
+- compatible:
+ - ti,da830-rtc - for RTC IP used similar to that on DA8xx SoC family.
+ - ti,am3352-rtc - for RTC IP used similar to that on AM335x SoC
family.
+ This RTC IP has special WAKE-EN Register to enable
+ Wakeup generation for event Alarm.
- reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 761919d..c2e18fe 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,8 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_IRQWAKEEN 0x7c
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -96,12 +98,21 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_IRQWAKEEN bit fields: */
+#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN(11)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+/*
+ * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
+ * generation for event Alarm.
+ */
+#defineOMAP_RTC_HAS_IRQWAKEEN 0x2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -301,12 +312,18 @@ static struct rtc_class_ops omap_rtc_ops = {
static int omap_rtc_alarm;
static int omap_rtc_timer;
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM3352_IDX1
+#defineOMAP_RTC_DATA_DA830_IDX 2
static struct platform_device_id omap_rtc_devtype[] = {
{
.name = DRIVER_NAME,
- }, {
+ },
+ [OMAP_RTC_DATA_AM3352_IDX] = {
+ .name = am3352-rtc,
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
+ },
+ [OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
@@ -318,6 +335,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
+ { .compatible = ti,am3352-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
@@ -466,16 +486,28 @@ static u8 irqstat;
static int omap_rtc_suspend(struct device *dev)
{
+ u8 irqwake_stat;
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(pdev);
+
irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
/* FIXME the RTC alarm is not currently acting as a wakeup event
-* source, and in fact this enable() call is just saving a flag
-* that's never used...
+* source on some platforms, and in fact this enable() call is just
+* saving a flag that's never used...
*/
- if
[Patch V2 1/4] rtc: omap: restore back (hard-code) wakeup support
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Acked-by: Kevin Hilman khil...@linaro.org Cc: Alessandro Zummo a.zu...@towertech.it Cc: rtc-li...@googlegroups.com --- :100644 100644 b0ba3fc... 761919d... M drivers/rtc/rtc-omap.c drivers/rtc/rtc-omap.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index b0ba3fc..761919d 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev) *is write-only, and always reads as zero...) */ + device_init_wakeup(pdev-dev, true); + if (new_ctrl (u8) OMAP_RTC_CTRL_SPLIT) pr_info(%s: split power mode\n, pdev-name); -- 1.7.9.5 -- 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: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori nsek...@ti.com
davinci: da8xx/omap-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Russell King li...@arm.linux.org.uk
---
Changes in V2:
- Coding style corrections (remove extra space)
- use prefix ARM: for commit subject keeping with arch/arm convention
:100644 100644 bf57252... 9140b1c... M arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci/devices-da8xx.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..9140b1c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
int da8xx_register_rtc(void)
{
- int ret;
-
- ret = platform_device_register(da8xx_rtc_device);
- if (!ret)
- /* Atleast on DA850, RTC is a wakeup source */
- device_init_wakeup(da8xx_rtc_device.dev, true);
-
- return ret;
+ return platform_device_register(da8xx_rtc_device);
}
static void __iomem *da8xx_ddr2_ctlr_base;
--
1.7.9.5
--
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: AM33XX: update rtc node compatibility
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
--
1.7.9.5
--
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] rtc: omap: handle rtc wakeup support in driver
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. Also, update Davinci AM335x files to above changes. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Changes in V2: - Coding style corrections (remove extra space, use lower case for hex numbers - use prefix ARM: for commit subject keeping with arch/arm convention) - use [AM/am]3352 instead of [AM/am]335x to keep the all usages in sync. - Use index defined for struct members so they remain in sync - Add new compatible to existing one so that when driver supports enhanced features of hardware, they are available to the user else the basic functionality still works Hebbar Gururaja (4): rtc: omap: restore back (hard-code) wakeup support ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup rtc: omap: add rtc wakeup support to alarm events ARM: dts: AM33XX: update rtc node compatibility Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +- arch/arm/boot/dts/am33xx.dtsi |2 +- arch/arm/mach-davinci/devices-da8xx.c |9 +-- drivers/rtc/rtc-omap.c | 62 +--- 4 files changed, 61 insertions(+), 18 deletions(-) -- 1.7.9.5 -- 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: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 07/02/2013 08:17 PM, Alan Stern wrote: On Tue, 2 Jul 2013, Roger Quadros wrote: On 07/02/2013 12:01 AM, Alan Stern wrote: On Mon, 1 Jul 2013, Felipe Balbi wrote: I don't know what Pad wakeup is. The wakeup signal has to originate from the EHCI controller, doesn't it? If not, how does the Pad know when a wakeup is needed? That's really an OMAP thing, I guess. Pad wakeup sits in the PRCM (IIRC) inside and always on power domain. EHCI sits in another power domain which be turned off. When it's turned off (power gated and clock gated) the EHCI block has no means to wakeup whatsoever. That's when pad wakeup comes into play. It is generated when PRCM sees a change in the actual pad of the die. To check who should 'own' the wakeup, it checks the muxing settings to verify whose pad is that. How does the PRCM know which changes should generate wakeup events? It doesn't know. It will always generate a wakeup on any change in the monitored pins. We can only configure which pins we want to monitor. So we can't choose which wakeup events we want to monitor. We just can enable or disable all events. In the EHCI controller, this is managed by the settings of the WKOC_E, WKDSCNNT_E, and WKCNNT_E bits in the PORTSC registers. But if EHCI is powered off, those bits can't be used. Is powered off same as ehci_suspend? If yes then how does it work on other systems for remote wakeup? Above, Felipe wrote that on OMAP, EHCI sits in a power domain which is turned off: power gated and clock gated. ehci_suspend() doesn't do those things, but they are what I was referring to. OK right, those things are done by OMAP platform support code. A PCI-based EHCI controller has two power sources: the core well (which is turned off during suspend) and the auxiliary well (which remains powered). That's how remote wakeup works; it uses the auxiliary well. OK. Thanks for the info. Also, once the wakeup signal has been turned on, how does it get turned off again? That is taken care of by the OMAP pinctrl driver. It will always turn off the wakeup signal once the event is detected and forwarded as an IRQ. I know that all this is a bit ugly :(. I still a little confused. The wakeup signal turns on. Then the pinctrl driver sees it, forwards it as an IRQ, and turns the wakeup signal off. But what if the IRQ is disabled (as it would be with your patch)? Does the IRQ line remain active until it causes an interrupt? What eventually turns off the IRQ line? In the beagle/panda board, the USB lines of the OMAP are used in ULPI mode. Here we are monitoring DATA0, DATA1 and DATA3 lines which get configured as Linestate and Interrupt of the PHY device whenever the PHY is put into suspend mode. This usually happens when we suspend the EHCI controller. When EHCI is suspended, the pinctrl wakeup mechanism is active. Whenever there is a change in the monitored lines we get the PAD IRQ and hence the EHCI IRQ. We don't really care much about which line changed state. (NOTE: while suspending, we didn't disable the EHCI IRQ). So we will always get the first IRQ and then we disable it and queue a hub_resume_work. Then EHCI resumes, pinctrl wakeup is disabled and EHCI IRQ is enabled. When pinctrl wakeup mechanism is active, it clears the wakeup event flag after a PAD IRQ, but it has no control on disabling the interrupt source. If there is a change in the pad, the PAD IRQ will fire again. cheers, -roger -- 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 v9 0/8] Generic PHY Framework
Hi Kishon, -Original Message- From: ABRAHAM, KISHON VIJAY Sent: Wednesday, June 26, 2013 5:17 PM To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe; ABRAHAM, KISHON VIJAY; a...@arndb.de; swar...@nvidia.com; sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux- foundation.org Cc: rob.herr...@calxeda.com; r...@landley.net; li...@arm.linux.org.uk; benoit.cous...@linaro.org; mche...@redhat.com; ces...@cesarb.net; da...@davemloft.net; Nayak, Rajendra; shawn@linaro.org; Shilimkar, Santosh; devicetree-disc...@lists.ozlabs.org; linux- d...@vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian, George Subject: [PATCH v9 0/8] Generic PHY Framework Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. I would like to use this framework for a smart-card controller connected to a smart-card phy. I have some questions and would like to get feedback on the same. I am using “TDA8026 Smartcard PHY from NXP. Here is the link for datasheet and app note for the same. The smart card controller is inside the TI SoC I am working with. Datasheet : www.nxp.com/documents/data_sheet/TDA8026.pdf? Appnote : http://www.nxp.com/documents/application_note/AN10724.pdf The TI SoC details are not public (yet). I can provide details to you offline. Brief about operation: - The controller can work with and without a PHY - When not using PHY, it is limited to talking to a single smart card. There is also a need to put external de-activation logic on card removal for this case. - With a PHY you can use more than one smart card. - Phy has 5 slots : 1 for smart card (credit/debit/other card with chip) and others for SAM – SIM like modules - Once the PHY is initialized, there are some operations that the controller can request of the PHY like: - Card configurations - set voltage - Activation of card - ATR – Answer to reset - Warm reset - ADPU exchange - Deactivation ( Normal/Emergency) - In the mode when smartcard controller talks directly to the card without the need for a PHY, all the above operations will be carried out by the controller itself My current thought process is to make the controller driver provide the user interface and talk to the PHY using the generic PHY framework you proposed. In the case where there is no PHY, my idea is to create a dummy PHY which uses the controller functionality itself. What I seem to be missing from the PHY framework is support for event detection and generic read/write API which will enable the controller to talk to the PHY for the operations listed above and also react to events from the PHY. Is there a reason why such functionality has not been included. If it was only a case of lack of use case, then do you think it will be useful to extend the framework to add such functionality? I can help with the development. Thanks, Satish -- 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
Hi, On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho coe...@ti.com 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. I can offer you my help testing things on pandora and I'm sure someone here could try it on N900. -- Gražvydas -- 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
[PATCHv2] drivers: mtd: spinand: Add generic spinand frameowrk.
From: Mona Anonuevo manonu...@micron.com
This patch adds support for a generic spinand framework(spinand_mtd.c).
This frameowrk can be used for other spi based flash devices. The idea
is to have a common model under drivers/mtd, as also present for other non spi
devices(there is a generic framework and device part simply attaches itself to
it.)
Signed-off-by: Mona Anonuevo manonu...@micron.com
Signed-off-by: Tuan Nguyen tqngu...@micron.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
This patch was sent as a part of a series[1];
but this can go in as a standalone patch.
[1]: https://lkml.org/lkml/2013/6/26/83
v1-v2:
seperated the specific micron driver,
flash devices can attach itself seperately to this
generic framework.
drivers/mtd/Kconfig |2 +
drivers/mtd/Makefile |2 +
drivers/mtd/spinand/Kconfig | 24 ++
drivers/mtd/spinand/Makefile |8 +
drivers/mtd/spinand/spinand_mtd.c | 690 +
include/linux/mtd/spinand.h | 155 +
6 files changed, 881 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spinand/Kconfig
create mode 100644 drivers/mtd/spinand/Makefile
create mode 100644 drivers/mtd/spinand/spinand_mtd.c
create mode 100644 include/linux/mtd/spinand.h
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 5fab4e6..c9e6c60 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -318,6 +318,8 @@ source drivers/mtd/nand/Kconfig
source drivers/mtd/onenand/Kconfig
+source drivers/mtd/spinand/Kconfig
+
source drivers/mtd/lpddr/Kconfig
source drivers/mtd/ubi/Kconfig
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 4cfb31e..cce68db 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -32,4 +32,6 @@ inftl-objs:= inftlcore.o inftlmount.o
obj-y += chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/
+obj-y += spinand/
+
obj-$(CONFIG_MTD_UBI) += ubi/
diff --git a/drivers/mtd/spinand/Kconfig b/drivers/mtd/spinand/Kconfig
new file mode 100644
index 000..38c739f
--- /dev/null
+++ b/drivers/mtd/spinand/Kconfig
@@ -0,0 +1,24 @@
+#
+# linux/drivers/mtd/spinand/Kconfig
+#
+
+menuconfig MTD_SPINAND
+ tristate SPINAND Device Support
+ depends on MTD
+ help
+This enables support for accessing Micron SPI NAND flash
+devices.
+
+if MTD_SPINAND
+
+config MTD_SPINAND_ONDIEECC
+ bool Use SPINAND internal ECC
+ help
+Internel ECC
+
+config MTD_SPINAND_SWECC
+ bool Use software ECC
+ depends on MTD_NAND
+ help
+software ECC
+endif
diff --git a/drivers/mtd/spinand/Makefile b/drivers/mtd/spinand/Makefile
new file mode 100644
index 000..be18de7
--- /dev/null
+++ b/drivers/mtd/spinand/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for the SPI NAND MTD
+#
+
+# Core functionality.
+obj-$(CONFIG_MTD_SPINAND) += spinand.o
+
+spinand-objs := spinand_mtd.o
diff --git a/drivers/mtd/spinand/spinand_mtd.c
b/drivers/mtd/spinand/spinand_mtd.c
new file mode 100644
index 000..8bfff86
--- /dev/null
+++ b/drivers/mtd/spinand/spinand_mtd.c
@@ -0,0 +1,690 @@
+/*
+spinand_mtd.c
+
+Copyright (c) 2009-2010 Micron Technology, Inc.
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/jiffies.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/spinand.h
+#include linux/mtd/nand_ecc.h
+
+/**
+ * spinand_get_device - [GENERIC] Get chip for selected access
+ * @param mtd MTD device structure
+ * @param new_statethe state which is requested
+ *
+ * Get the device and lock it for exclusive access
+ */
+#define mu_spi_nand_driver_version Beagle-MTD_01.00_Linux2.6.33_20100507
+
+static int spinand_get_device(struct mtd_info *mtd, int new_state)
+{
+ struct spinand_chip *this = mtd-priv;
+ DECLARE_WAITQUEUE(wait, current);
+
+ /*
+* Grab the lock and see if the device is available
+*/
+ while (1) {
+ spin_lock(this-chip_lock);
+ if (this-state == FL_READY) {
+ this-state = new_state;
+ spin_unlock(this-chip_lock);
+ break;
+ }
+ if (new_state == FL_PM_SUSPENDED) {
+ spin_unlock(this-chip_lock);
+ return
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
* Luciano Coelho coe...@ti.com [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 t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- 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. Regards, Tony -- 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 coe...@ti.com [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 t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- 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: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Hi, On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote: A PCI-based EHCI controller has two power sources: the core well (which is turned off during suspend) and the auxiliary well (which remains powered). That's how remote wakeup works; it uses the auxiliary well. This, kinda, matches what OMAP tries to do with pad wakeup. Just that pad wakeup sits outside of the device itself. Perhaps we could look into how PCI handles the aux well and take some inspiration from there. Any pointers under drivers/pci/ would be great :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Tuesday 02 July 2013, Pekon Gupta wrote: (+ CC: devicetree-disc...@lists.ozlabs.org) Changes v3 - v4 - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 MTD_NAND_OMAP_BCH4 from nand/Kconfig ECC scheme selectable via nand DT (nand-ecc-opt). - [*] rebased for l2-mtd.git Do you also fix these build error? /git/arm-soc/drivers/mtd/nand/omap2.c: In function 'omap_nand_probe': /git/arm-soc/drivers/mtd/nand/omap2.c:1964:7: error: 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' undeclared (first use in this function) case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW: ^ /git/arm-soc/drivers/mtd/nand/omap2.c:1964:7: note: each undeclared identifier is reported only once for each function it appears in /git/arm-soc/drivers/mtd/nand/omap2.c:1991:7: error: 'OMAP_ECC_BCH4_CODE_HW_DETECTION_SW' undeclared (first use in this function) case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW: ^ Arnd -- 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: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 07/03/2013 03:57 PM, Felipe Balbi wrote: Hi, On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote: A PCI-based EHCI controller has two power sources: the core well (which is turned off during suspend) and the auxiliary well (which remains powered). That's how remote wakeup works; it uses the auxiliary well. This, kinda, matches what OMAP tries to do with pad wakeup. Just that pad wakeup sits outside of the device itself. Perhaps we could look into how PCI handles the aux well and take some inspiration from there. Any pointers under drivers/pci/ would be great :-) From what I understood, auxiliary well is just a power source, and it keeps the EHCI controller powered even during suspend. If that is true then it is different from our situation as we power down the EHCI controller completely. cheers, -roger -- 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: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote: On 07/03/2013 03:57 PM, Felipe Balbi wrote: Hi, On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote: A PCI-based EHCI controller has two power sources: the core well (which is turned off during suspend) and the auxiliary well (which remains powered). That's how remote wakeup works; it uses the auxiliary well. This, kinda, matches what OMAP tries to do with pad wakeup. Just that pad wakeup sits outside of the device itself. Perhaps we could look into how PCI handles the aux well and take some inspiration from there. Any pointers under drivers/pci/ would be great :-) From what I understood, auxiliary well is just a power source, and it keeps the EHCI controller powered even during suspend. If that is true then it is different from our situation as we power down the EHCI controller completely. right but our auxiliary well keeps PRCM powered which can wake EHCI up ;-) What I'm saying is that from ehci-omap's perspective, there's very little difference, specially since we route the wakeup through the same IRQ line anyway. Perhaps we could take some inspiration from the PCI land to make our hwmod/omap_device a little easier from driver perspective. Or maybe it doesn't make sense ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Tuesday 02 July 2013, Pekon Gupta wrote: (+ CC: devicetree-disc...@lists.ozlabs.org) Changes v3 - v4 - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 MTD_NAND_OMAP_BCH4 from nand/Kconfig ECC scheme selectable via nand DT (nand-ecc-opt). - [*] rebased for l2-mtd.git Do you also fix these build error? /git/arm-soc/drivers/mtd/nand/omap2.c: In function 'omap_nand_probe': /git/arm-soc/drivers/mtd/nand/omap2.c:1964:7: error: 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' undeclared (first use in this function) case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW: ^ /git/arm-soc/drivers/mtd/nand/omap2.c:1964:7: note: each undeclared identifier is reported only once for each function it appears in /git/arm-soc/drivers/mtd/nand/omap2.c:1991:7: error: 'OMAP_ECC_BCH4_CODE_HW_DETECTION_SW' undeclared (first use in this function) case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW: ^ Arnd [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly returning from probe with pr_err(), if the required libraries (/lib/bch.c) are not build-in the system. --- [Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC.. @@static int omap_nand_probe(struct platform_device *pdev) + default: + pr_err(selected ECC scheme not supported or not enabled\n); + err = -EINVAL; + goto out_release_mem_region; + } --- However, if you are still seeing this, could you please send me your config? with regards, pekon -- 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 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote: [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly returning from probe with pr_err(), if the required libraries (/lib/bch.c) are not build-in the system. --- [Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC.. @@static int omap_nand_probe(struct platform_device *pdev) + default: + pr_err(selected ECC scheme not supported or not enabled\n); + err = -EINVAL; + goto out_release_mem_region; + } --- However, if you are still seeing this, could you please send me your config? I compile tested your patches too, and did not see any issues with my omap2_defconfig. -- Best Regards, Artem Bityutskiy -- 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 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Wednesday 03 July 2013, Artem Bityutskiy wrote: On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote: [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly returning from probe with pr_err(), if the required libraries (/lib/bch.c) are not build-in the system. --- [Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC.. @@static int omap_nand_probe(struct platform_device *pdev) + default: + pr_err(selected ECC scheme not supported or not enabled\n); + err = -EINVAL; + goto out_release_mem_region; + } --- However, if you are still seeing this, could you please send me your config? I compile tested your patches too, and did not see any issues with my omap2_defconfig. To clarify: I'm getting this error with randconfig on today's linux-next. I think it only happens with MTD_NAND_ECC_BCH enabled, which is not the default in omap2_defconfig. Arnd -- 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 coe...@ti.com 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
Re: [PATCH] ARM: OMAP5: Enable Cortex A15 errata 798181
Ping.. On Wednesday 19 June 2013 03:52 PM, Santosh Shilimkar wrote: ARM errata 798181 is applicable for OMAP5 based devices. So enable the same in the build. Errata extract and workaround information is as below. On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not adequately shooting down all use of the old entries. The ARM_ERRATA_798181 option enables the Linux kernel workaround for this erratum which sends an IPI to the CPUs that are running the same ASID as the one being invalidated. Cc: Tony Lindgren t...@atomide.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..fbd2b9f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -112,6 +112,7 @@ config SOC_OMAP5 select HAVE_SMP select COMMON_CLK select HAVE_ARM_ARCH_TIMER + select ARM_ERRATA_798181 comment OMAP Core Type depends on ARCH_OMAP2 -- 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 coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
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 coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
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 linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
+#include linux/clk-provider.h
#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 t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
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,
[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 coe...@ti.com
---
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 coe...@ti.com
---
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 linux/mmc/sdio_ids.h
#include linux/mmc/card.h
#include linux/mmc/host.h
-#include linux/gpio.h
+#include linux/of_irq.h
#include linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
@@ -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 t...@atomide.com
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
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 linux/err.h
#include linux/wl12xx.h
-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 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 coe...@ti.com
---
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 t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
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 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -413,20 +413,44
Re: [PATCH v3 1/8] wl1251: split wl251 platform data to a separate structure
On Wed, Jul 03, 2013 at 05:03:22PM +0300, Luciano Coelho wrote: 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 t...@atomide.com Signed-off-by: Luciano Coelho coe...@ti.com Acked-by: Tony Lindgren t...@atomide.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 3/8] wlcore: remove pwr_in_suspend from platform data
On Wed, Jul 03, 2013 at 05:03:24PM +0300, Luciano Coelho wrote: 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 coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
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 t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
[...]
@@ -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 4/8] wl12xx: use frequency instead of enumerations for pdata clocks
On Wed, Jul 03, 2013 at 05:03:25PM +0300, 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 t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 5/8] wlcore: add initial device tree support to the sdio module
On Wed, Jul 03, 2013 at 05:03:26PM +0300, Luciano Coelho wrote: 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 coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
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 8/8] wlcore/wl12xx: check if we got correct clock data from DT
On Wed, Jul 03, 2013 at 05:03:29PM +0300, Luciano Coelho wrote: 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 coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, Jul 03, 2013 at 05:18:14PM +0300, Luciano Coelho wrote:
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.
hah, missed the 'return' call, my bad :-p
Reviewed-by: Felipe Balbi ba...@ti.com
Corrected-my-broken-eye-sight-by: Luciano Coelho coe...@ti.com
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On Wed, 3 Jul 2013, Felipe Balbi wrote: On Wed, Jul 03, 2013 at 04:06:04PM +0300, Roger Quadros wrote: On 07/03/2013 03:57 PM, Felipe Balbi wrote: Hi, On Tue, Jul 02, 2013 at 01:17:58PM -0400, Alan Stern wrote: A PCI-based EHCI controller has two power sources: the core well (which is turned off during suspend) and the auxiliary well (which remains powered). That's how remote wakeup works; it uses the auxiliary well. This, kinda, matches what OMAP tries to do with pad wakeup. Just that pad wakeup sits outside of the device itself. Perhaps we could look into how PCI handles the aux well and take some inspiration from there. Any pointers under drivers/pci/ would be great :-) From what I understood, auxiliary well is just a power source, and it keeps the EHCI controller powered even during suspend. If that is true then it is different from our situation as we power down the EHCI controller completely. right but our auxiliary well keeps PRCM powered which can wake EHCI up ;-) What I'm saying is that from ehci-omap's perspective, there's very little difference, specially since we route the wakeup through the same IRQ line anyway. Perhaps we could take some inspiration from the PCI land to make our hwmod/omap_device a little easier from driver perspective. Or maybe it doesn't make sense ;-) This idea probably won't lead anywhere. To the best of my knowledge (and I'm not an expert on PCI), these different power wells are simply part of the PCI bus. The bus controller knows to turn off one of them when the device (or maybe when all the devices on a bus segment) goes into D3. One big difference with respect to OMAP is the way PCI handles wakeup messages. There's a separate bus signal, PME# (which stands for Power Management Event), that a device asserts when it wants to send a wakeup request. When the ACPI driver sees the PME# signal, it searches through the entire PCI tree to find the device or devices which need to be resumed. Or maybe when ACPI sees the signal, it tells the PCI core to do this -- I'm not sure of the details. Alan Stern -- 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, Jul 3, 2013 at 4:15 PM, Luciano Coelho coe...@ti.com 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 t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
[...]
@@ -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.
Hi Luca
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().
Best regards,
Javier
--
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
AM335x: is AUTORTS mode supported ?
I'm struggling to determine if AUTORTS mode is currently supported in 3.10 ?
I have dug into the source code, and can see various references to the relevant
bits
in the various UART registers, but I'm at a lose as to how to actually *enable*
the
mode !!
In drivers/tty/omap-serial.c serial_omap_set_termios() we have:-
if (termios-c_cflag CRTSCTS up-port.flags UPF_HARD_FLOW) {
/* Enable AUTORTS and AUTOCTS */
up-efr |= UART_EFR_CTS | UART_EFR_RTS;
/* Ensure MCR RTS is asserted */
up-mcr |= UART_MCR_RTS;
} else {
...
}
So it looks like I need to set the CRTSCTS and UPF_HARD_FLOW flags.
From userspace, I've tried:-
$ stty -F /dev/ttyO2 crtscts
But I've not idea how to enable UPF_HARD_FLOW !?!
Can anyone point me in the right direction ?
Cheers
Mark J.
--
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: [PATCHv2] drivers: mtd: spinand: Add generic spinand frameowrk.
Hello,
2013/7/3 Sourav Poddar sourav.pod...@ti.com:
From: Mona Anonuevo manonu...@micron.com
This patch adds support for a generic spinand framework(spinand_mtd.c).
This frameowrk can be used for other spi based flash devices. The idea
is to have a common model under drivers/mtd, as also present for other non spi
devices(there is a generic framework and device part simply attaches itself
to it.)
Resending my comments since your previous submissino
Signed-off-by: Mona Anonuevo manonu...@micron.com
Signed-off-by: Tuan Nguyen tqngu...@micron.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[snip]
+if MTD_SPINAND
+
+config MTD_SPINAND_ONDIEECC
+ bool Use SPINAND internal ECC
+ help
+Internel ECC
+
+config MTD_SPINAND_SWECC
+ bool Use software ECC
+ depends on MTD_NAND
+ help
+software ECC
Can this somehow be made a runtime thing?
[snip]
+ if (count oob_num ops-oobbuf chip-oobbuf) {
+ int size;
+ int offset, len, temp;
+
+ /* repack spare to oob */
+ memset(chip-oobbuf, 0, info-ecclayout-oobavail);
+
+ temp = 0;
+ offset = info-ecclayout-oobfree[0].offset;
+ len = info-ecclayout-oobfree[0].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset,
len);
Sounds like a for look might be useful here
+
+ temp += len;
+ offset = info-ecclayout-oobfree[1].offset;
+ len = info-ecclayout-oobfree[1].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset,
len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[2].offset;
+ len = info-ecclayout-oobfree[2].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset,
len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[3].offset;
+ len = info-ecclayout-oobfree[3].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset,
len);
+
[snip]
+ /* repack oob to spare */
+ temp = 0;
+ offset = info-ecclayout-oobfree[0].offset;
+ len = info-ecclayout-oobfree[0].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
And here too.
+
+ temp += len;
+ offset = info-ecclayout-oobfree[1].offset;
+ len = info-ecclayout-oobfree[1].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[2].offset;
+ len = info-ecclayout-oobfree[2].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[3].offset;
+ len = info-ecclayout-oobfree[3].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
+ }
[snip]
+++ b/include/linux/mtd/spinand.h
@@ -0,0 +1,155 @@
+/*
+ * linux/include/linux/mtd/spinand.h
+ * Copyright (c) 2009-2010 Micron Technology, Inc.
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+/bin/bash: 4: command not found
+ *
+ * based on nand.h
+ */
+#ifndef __LINUX_MTD_SPI_NAND_H
+#define __LINUX_MTD_SPI_NAND_H
+
+#include linux/wait.h
+#include linux/spinlock.h
+#include linux/mtd/mtd.h
+
+/* cmd */
+#define CMD_READ 0x13
+#define CMD_READ_RDM 0x03
+#define CMD_PROG_PAGE_CLRCACHE 0x02
+#define CMD_PROG_PAGE 0x84
+#define CMD_PROG_PAGE_EXC 0x10
+#define CMD_ERASE_BLK 0xd8
+#define
Re: [alsa-devel] Query on Audio DMA using DMAEngine
Copying some more lists are we're also discussing the DMA controller in the SoCs. Thanks. On 07/03/2013 04:43 AM, Mark Brown wrote: On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote: On 07/02/2013 02:13 PM, Mark Brown wrote: This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer). Yes, this is usually how it is done. But I'm wondering maybe the EDMA controller only has a small total amount of slots available. Well, you don't need particularly many slots so long as you can cope with a large period size. Hi Mark, When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? I see tegra and aux1x go upto .period_bytes_min = 1024 About slots, following are no.of slots on some SoCs with EDMA: am1808 - 96 slots available + 32 taken up for channel but can be reused with some changes. am335x - 172 slots available + 64 taken up for channels On a slightly different note, about buffer_bytes_max, is there any drawback to setting it to a smaller value? Currently 128K is about what is used on davinci-pcm. My idea is to map to do the direct mapping to IRAM if the IRAM transfers are really what are preventing the under runs, but 128K will be too much for the buffer as we don't have that much IRAM infact it is just the boundary on am33xx (128K) Thanks, -Joel -- 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 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Wednesday 03 July 2013, Artem Bityutskiy wrote:
On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote:
[Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly
returning from probe with pr_err(), if the required libraries (/lib/bch.c)
are not build-in the system.
---
[Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC..
@@static int omap_nand_probe(struct platform_device *pdev)
+ default:
+ pr_err(selected ECC scheme not supported or not
enabled\n);
+ err = -EINVAL;
+ goto out_release_mem_region;
+ }
---
However, if you are still seeing this, could you please send me your
config?
I compile tested your patches too, and did not see any issues with my
omap2_defconfig.
To clarify: I'm getting this error with randconfig on today's linux-next.
I think it only happens with MTD_NAND_ECC_BCH enabled, which is not
the default in omap2_defconfig.
Arnd
Hi Arnd, Artem, Stephen,
I see the issue in linux-next/master tree..
linux-next/master has only the first [Patch v4 1/4] from the series.
Other patches [Patch v4 2/4.. 4/4] of this series were dropped,
as 'Olof Johansson' had some apprehensions about DT bindings.
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/249662
As these patches are inter-dependent, so please drop the whole series
including the commit below.
fb1585b [Patch v4 1/4] mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW
I'm awaiting feedbacks from 'Olof Johansson' or other DT maintainers,
once approved, I'll resend the whole series.
[PATCH v4 2/4] ARM: OMAP2+: cleaned-up DT support had the
declarations which were required for above build errors.
---
include/linux/platform_data/mtd-nand-omap2.h
enum omap_ecc {
+ /* 4-bit ECC calculation by GPMC, Error detection by Software */
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW,
...
+ /* 8-bit ECC calculation by GPMC, Error detection by Software */
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
---
with regards, pekon
Re: [alsa-devel] Query on Audio DMA using DMAEngine
On Wed, Jul 03, 2013 at 12:55:36PM -0500, Joel Fernandes wrote: When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? This is an application issue not a driver issue. An application that wants low latency may need high resolution information about what exactly the hardware is doing. signature.asc Description: Digital signature
Re: [alsa-devel] Query on Audio DMA using DMAEngine
On 07/03/2013 01:12 PM, Mark Brown wrote: On Wed, Jul 03, 2013 at 12:55:36PM -0500, Joel Fernandes wrote: When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? This is an application issue not a driver issue. An application that wants low latency may need high resolution information about what exactly the hardware is doing. Hi Darren, Can anyone in your team share some insight about min/max buffer size and min/max period size in the davinci-pcm driver. This will help make better decisions about the Cyclic DMA. Below was my original email on the mailing list. Also could you copy Peter? I couldn't find his email address. Thanks, Joel Quoting my original email to the mailing list: Copying some more lists are we're also discussing the DMA controller in the SoCs. Thanks. On 07/03/2013 04:43 AM, Mark Brown wrote: On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote: On 07/02/2013 02:13 PM, Mark Brown wrote: This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer). Yes, this is usually how it is done. But I'm wondering maybe the EDMA controller only has a small total amount of slots available. Well, you don't need particularly many slots so long as you can cope with a large period size. Hi Mark, When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? I see tegra and aux1x go upto .period_bytes_min = 1024 About slots, following are no.of slots on some SoCs with EDMA: am1808 - 96 slots available + 32 taken up for channel but can be reused with some changes. am335x - 172 slots available + 64 taken up for channels On a slightly different note, about buffer_bytes_max, is there any drawback to setting it to a smaller value? Currently 128K is about what is used on davinci-pcm. My idea is to map to do the direct mapping to IRAM if the IRAM transfers are really what are preventing the under runs, but 128K will be too much for the buffer as we don't have that much IRAM infact it is just the boundary on am33xx (128K) Thanks, -Joel -- 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: OMAP baseline test results for v3.10-rc6
On Tue, 2 Jul 2013, Nishanth Menon wrote: On 07/01/2013 11:29 PM, Hiremath, Vaibhav wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, July 01, 2013 7:46 AM To: Vutla, Lokesh Cc: Nayak, Rajendra; Hiremath, Vaibhav; Kevin Hilman; Rini, Tom; linux- o...@vger.kernel.org; Balbi, Felipe; linux-arm- ker...@lists.infradead.org Subject: Re: OMAP baseline test results for v3.10-rc6 On Fri, 28 Jun 2013, Paul Walmsley wrote: On Thu, 27 Jun 2013, Lokesh Vutla wrote: Here is the catch.. Your dtb is generated in arch/arm/boot/dts/ folder(before V3.8 dtb was generated in arch/arm/boot). Ugh... that's probably it :-( to prevent this from happening again, Lokesh did post a patch: https://patchwork.kernel.org/patch/2796921/ Will be good to ack it if we think it might prevent such scenarios in the future. Thanks for the suggestion. Unfortunately it wouldn't have caught the problem, since, as I mentioned in the E-mail you quoted, I build from a fresh tree each time. So there was no previous DTB. This wasn't caught here because 'cat' was copying over the kernel to its standard output, even though it was returning an error, and I wasn't checking the 'cat' return value. This is obviously being remedied here. Also will modify the build scripts to output each command as it's being run. As far as Lokesh's patch goes: it doesn't make sense to me to remove a file during 'make clean' that the build process doesn't create. So while I understand the motivation for the patch, and don't mind if upstream takes it, I personally wouldn't care to ack it. - Paul -- 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: Query on Audio DMA using DMAEngine
Hi Mike, On 07/03/2013 08:17 AM, Mike Looijmans wrote: On 07/03/2013 11:43 AM, Mark Brown wrote: On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote: On 07/02/2013 02:13 PM, Mark Brown wrote: This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer). Yes, this is usually how it is done. But I'm wondering maybe the EDMA controller only has a small total amount of slots available. Well, you don't need particularly many slots so long as you can cope with a large period size. On the OMAP L138, there are 128 PARAM slots. 32 of those are tied to hardware events (though you can use them if you aren't using the related hardware, for example the UART drivers don't use DMA so you can freely use those slots if you want), leaving (at least) 96 PARAM slots free. Both audio events are on the same controller, so you can't use the 128 of the other one (the OMAP has 2 EDMA controllers). Only a few dozen of those are being used by various drivers, the SD card driver being the most hungry. For the system to work, you can even get away with only using one slot, and hence one period, but then you'll have to use a mmap and a timer to fill it. I experimented with various memory layouts. For large transfers, using 2 big periods was quite enough. I also tested with very small period sizes. Using the Wouldn't very small periods take up too many interrupts, and also occupy lots of slots? original code, I was unable to reliably capture (to /dev/null) at period sizes below 80 samples. With the cyclic DMA, I could set a period size of only 40 samples and still be able to record audio reliably, when using only 8 periods. The same for playback, basically. So that's how I arrived at the MAX_PERIODS define of 8. It will only claim channels when you use them, so setting it to say 100 will not crash the system. Thanks for your post Mike. It makes more sense to me now. Correct me if I'm wrong but: - more the periods, more the granularity- but the drawback is you'd need more slots and too many interrupts; so we want fewer periods as many as we need. I still don't know though, how do we arrive at an acceptable number that userspace expects? - periods also will determine buffer size. Considering in future if we'd want to use IRAM as the buffer which is limited on some users of the davinci-pcm, there might not be enough buffer space. So too many periods is certainly not a good thing. I wonder how we can arrive at what would constitute an acceptable number? As Linus said, we never break userspace :P so I'd rather not change anything that breaks someone's audio application. I will post some RFC notes soon capture our discussion and other ideas I had put together for EDMA as some notes to summarize and get everyone's opinion. I will copy you on that as well. Thanks. -Joel -- 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: [PATCHv2] drivers: mtd: spinand: Add generic spinand frameowrk.
Hi,
On Wednesday 03 July 2013 10:47 PM, Florian Fainelli wrote:
Hello,
2013/7/3 Sourav Poddarsourav.pod...@ti.com:
From: Mona Anonuevomanonu...@micron.com
This patch adds support for a generic spinand framework(spinand_mtd.c).
This frameowrk can be used for other spi based flash devices. The idea
is to have a common model under drivers/mtd, as also present for other non spi
devices(there is a generic framework and device part simply attaches itself to
it.)
Resending my comments since your previous submissino
Signed-off-by: Mona Anonuevomanonu...@micron.com
Signed-off-by: Tuan Nguyentqngu...@micron.com
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
[snip]
+if MTD_SPINAND
+
+config MTD_SPINAND_ONDIEECC
+ bool Use SPINAND internal ECC
+ help
+Internel ECC
+
+config MTD_SPINAND_SWECC
+ bool Use software ECC
+ depends on MTD_NAND
+ help
+software ECC
Can this somehow be made a runtime thing?
Ahh..I think we might opt for a device tree entry and based on that
check for ECC.
[snip]
+ if (count oob_num ops-oobbuf chip-oobbuf) {
+ int size;
+ int offset, len, temp;
+
+ /* repack spare to oob */
+ memset(chip-oobbuf, 0, info-ecclayout-oobavail);
+
+ temp = 0;
+ offset = info-ecclayout-oobfree[0].offset;
+ len = info-ecclayout-oobfree[0].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset, len);
Sounds like a for look might be useful here
I dont think so, there is a while loop above under which it happens.
We are increasing count at the bottom of the while loop. So, I think
this should work fine.
+
+ temp += len;
+ offset = info-ecclayout-oobfree[1].offset;
+ len = info-ecclayout-oobfree[1].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset, len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[2].offset;
+ len = info-ecclayout-oobfree[2].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset, len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[3].offset;
+ len = info-ecclayout-oobfree[3].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size + offset, len);
+
[snip]
+ /* repack oob to spare */
+ temp = 0;
+ offset = info-ecclayout-oobfree[0].offset;
+ len = info-ecclayout-oobfree[0].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
And here too.
Same as above.
+
+ temp += len;
+ offset = info-ecclayout-oobfree[1].offset;
+ len = info-ecclayout-oobfree[1].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[2].offset;
+ len = info-ecclayout-oobfree[2].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
+
+ temp += len;
+ offset = info-ecclayout-oobfree[3].offset;
+ len = info-ecclayout-oobfree[3].length;
+ memcpy(chip-buf + info-page_main_size + offset,
+ chip-oobbuf + temp, len);
+ }
[snip]
+++ b/include/linux/mtd/spinand.h
@@ -0,0 +1,155 @@
+/*
+ * linux/include/linux/mtd/spinand.h
+ * Copyright (c) 2009-2010 Micron Technology, Inc.
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+/bin/bash: 4: command not found
+ *
+ * based on nand.h
+ */
+#ifndef __LINUX_MTD_SPI_NAND_H
+#define __LINUX_MTD_SPI_NAND_H
+
+#includelinux/wait.h
+#includelinux/spinlock.h
+#includelinux/mtd/mtd.h
+
+/* cmd */
+#define CMD_READ 0x13
+#define CMD_READ_RDM
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On 7/3/2013 7:33 PM, 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 t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c |8 +- For the board-da850-evm.c change, Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- 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] usb: phy: omap-usb3: fix dpll clock index
Correction of the omap_usb3_dpll_params array when the sys_clk_rate is
20MHz.
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/phy/phy-omap-usb3.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index efe6e14..a2fb30b 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -71,9 +71,9 @@ static struct usb_dpll_params
omap_usb3_dpll_params[NUM_SYS_CLKS] = {
{1250, 5, 4, 20, 0},/* 12 MHz */
{3125, 20, 4, 20, 0}, /* 16.8 MHz */
{1172, 8, 4, 20, 65537},/* 19.2 MHz */
+ {1000, 7, 4, 10, 0},/* 20 MHz */
{1250, 12, 4, 20, 0}, /* 26 MHz */
{3125, 47, 4, 20, 92843}, /* 38.4 MHz */
- {1000, 7, 4, 10, 0},/* 20 MHz */
};
--
1.7.9.5
--
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
