Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
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
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
...
};
@@ -318,6 +333,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_AM335X_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
Apart from these minor issues, the patch looks good to me.
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
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
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
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
Sorry. I didn’t get this.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
...
};
@@ -318,6 +333,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_AM335X_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
Apart from these minor issues, the patch looks good to me.
Acked-by: Sekhar Nori nsek...@ti.com
Thanks,
Sekhar
Regards,
Gururaja
Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
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
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
Sorry. I didn’t get this.
See example below I provided. If its still not clear, let me know what
is not clear.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
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
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
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
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] =
{
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
Sorry. I didn’t get this.
See example below I provided. If its still not clear, let me know what
is not clear.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
Thanks for the clarification. In this case will it ok if I update the previous
member also.
Thanks,
Sekhar
Regards,
Gururaja
Re: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
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... March/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.
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
RE: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar 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.
Ok. I will update the same now in v2.
Thanks,
Sekhar
Regards,
Gururaja
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On 7/2/2013 11:41 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
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
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] =
{
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
Sorry. I didn’t get this.
See example below I provided. If its still not clear, let me know what
is not clear.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
Thanks for the clarification. In this case will it ok if I update the previous
member also.
You dont really reference [0] in omap_rtc_of_match[] so even if you
leave it as-is, that's fine with me. I am mostly concerned with the
index definitions and initialization order being out of sync and that's
really not an issue with [0].
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
Re: [PATCH v3 0/2]: auto request GPIO as input if used as IRQ via DT
On 07/02/2013 01:23 AM, Kevin Hilman wrote:
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drivers should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just request the IRQ and this has to
be handled by the irq_chip driver.
With the current OMAP GPIO DT binding, if we define:
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
reg = 0x49058000 0x200;
interrupts = 34;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
};
interrupt-parent = gpio6;
interrupts = 16 8;
The GPIO is correctly mapped as an IRQ but a call to gpio_request()
is never made. Ideally this has to be handled by the IRQ core and
there are some work-in-progress to add this logic to the core but
until this general solution gets into mainline we need to solve this
on a per irq_chip driver basis.
Some drivers solve this by calling gpio_request() using a custom
.xlate function handler. But .xlate could get called many times
while the irq domain .map function handler is called just once
when a IRQ mapping is created with a call to irq_create_mapping().
This patch-set adds a custom .map function handler for the gpio-omap
irq_chip driver that automatically call gpio_request() when a IRQ
mapping is created for the GPIO line used as interrupt when using DT.
This is just a temporary solution (a.k.a a hack) until a kernel wide
approach is implemented and added to mainline.
This is a third version of a patch-set that addresses some issues pointed
out by Grant Like, it is composed of the following patches:
[PATCH v3 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT
[PATCH v3 2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT
This was tested on an OMAP3 DM3735 board (IGEPv2) and all the supported
peripherals are working correctly with both legacy and DT booting. Further
testing will be highly appreciated.
Was there any testing done to hit low-power modes? suspend/resume?
CPUidle enabled? etc. It is especially instructive to enable off
mode[1] on OMAP3 platforms and see if things still work as expected.
Kevin
[1] echo 1 /sys/kerel/debug/pm_debug/enable_off_mode
Hi Kevin,
Thanks a lot for your feedback.
I tested enabling power domain transitions to off mode [1] and suspending to RAM
[2] with both DT and legacy boot. With legacy booting everything works as
expected.
In the DT case suspending/resume (without enabling off mode) doesn't affect
system operation. For example the Ethernet chip that uses a GPIO IRQ still is
able to transmit frames after suspending to RAM and waking up the board hitting
Ctrl+C in the serial console.
Now, enabling off mode [2] with DT makes the board to never go out from suspend:
root@igep00x0:~# echo 1 /sys/kernel/debug/pm_debug/enable_off_mode
root@igep00x0:~# echo mem /sys/power/state
[ 129.833343] PM: Syncing filesystems ... done.
[ 129.879211] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 129.905487] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
done.
[ 129.935363] Suspending console(s) (use no_console_suspend to debug)
The board just hangs/sleeps and I don't have a way to take it from suspend.
I don't know if there something missing on my board DT file but I think this is
orthogonal with these patches since since I got the same behavior without them.
Best regards,
Javier
[1] echo 1 /sys/kernel/debug/pm_debug/enable_off_mode
[2] echo mem /sys/power/state
--
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 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar 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;
I believe the order is not important here. I mean, below is also fine. Right?
compatible = ti,da830-rtc, ti,am3352-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.
Thanks,
Sekhar
Regards,
Gururaja
Re: [PATCH v3 1/4] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
On 7/2/2013 9:44 AM, Gupta, Pekon wrote: This does not apply to l2-mtd.git, could you please re-base? [Pekon]: rebased to l2-mtd.git - updated [Patch 3/4] which conflicted with commit '26331c04' which touched omap2.c. - Please ignore [Patch 4/4] as it’s a DT update, which adds on top of Benoit's tree (which has NAND node commits too). If you need one patch (DT patch) in the series to be merged in another repository (DT maintainer tree) then separate out that patch as separate series and mention the dependency or need ack from the driver maintainer so that both maintainer can apply the whole series into his repository instead of applying partially here and there. Agree. Yes, I should have sent the DT patch separately. But I posted all changes as part of single series, as its easy for users to Test and Ack them. Similarly patches for GPMC (Tony's tree) and NAND (Artem's tree) are functionally coupled, So at times I have to send them as part of same series. However, I'll clearly mention that in my cover-letter for future patches. Thanks for feedback .. In that case you can publish your testing branch to a public repo and point to that repo in your cover letter so that someone who wants to test can test from your repo which has all dependent patches. Regards Mugunthan V N -- 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 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? 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 :(. 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
[PATCHv2] drivers: spi: Add qspi flash controller
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).
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:
1. Placed pm specific calls in prepare/unprepare apis.
2. Put a mask to support upto 32 bits word length.
3. Used devm_ioremap_resource variants.
4. Add dt binding doumentation.
Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 ++
drivers/spi/Kconfig |8 +
drivers/spi/Makefile |1 +
drivers/spi/ti-qspi.c | 357 +
4 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
create mode 100644 drivers/spi/ti-qspi.c
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
new file mode 100644
index 000..65075c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -0,0 +1,22 @@
+TI QSPI controller.
+
+Required properties:
+- compatible : should be ti,dra7xxx-qspi.
+- reg: Should contain QSPI registers location and length.
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ti,hwmods: Name of the hwmod associated to the QSPI
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+qspi: qspi@4b30 {
+ compatible = ti,dra7xxx-qspi;
+ reg = 0x4b30 0x100;
+ #address-cells = 1;
+ #size-cells = 0;
+spi-max-frequency = 2500;
+ ti,hwmods = qspi;
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92a9345..9937d66 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,14 @@ config SPI_OMAP24XX
SPI master controller for OMAP24XX and later Multichannel SPI
(McSPI) modules.
+config QSPI_DRA7xxx
+ tristate DRA7xxx QSPI controller support
+ depends on ARCH_OMAP2PLUS
+ help
+ QSPI master controller for DRA7xxx used for flash devices.
+ This device supports single, dual and quad read support, while
+ it only supports single write mode.
+
config SPI_OMAP_100K
tristate OMAP SPI 100K
depends on ARCH_OMAP850 || ARCH_OMAP730
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..ea14eff 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K)+= spi-omap-100k.o
obj-$(CONFIG_SPI_OMAP24XX) += spi-omap2-mcspi.o
+obj-$(CONFIG_QSPI_DRA7xxx) += ti-qspi.o
obj-$(CONFIG_SPI_ORION)+= spi-orion.o
obj-$(CONFIG_SPI_PL022)+= spi-pl022.o
obj-$(CONFIG_SPI_PPC4xx) += spi-ppc4xx.o
diff --git a/drivers/spi/ti-qspi.c b/drivers/spi/ti-qspi.c
new file mode 100644
index 000..e646a93
--- /dev/null
+++ b/drivers/spi/ti-qspi.c
@@ -0,0 +1,357 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated
+ *
+ * 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/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+
+#include linux/spi/spi.h
+
+struct dra7xxx_qspi {
+ struct spi_master *master;
+ void __iomem*base;
+ int device_type;
+ struct device *dev;
+ u32 spi_max_frequency;
+ u32 cmd;
+ u32 dc;
+};
+
Re: [PATCHv2] drivers: spi: Add qspi flash controller
Hi,
On Tue, Jul 02, 2013 at 02:26:39PM +0530, Sourav Poddar wrote:
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..ea14eff 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON)+= spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K) += spi-omap-100k.o
obj-$(CONFIG_SPI_OMAP24XX) += spi-omap2-mcspi.o
+obj-$(CONFIG_QSPI_DRA7xxx) += ti-qspi.o
all other drivers are prepended with spi-
diff --git a/drivers/spi/ti-qspi.c b/drivers/spi/ti-qspi.c
new file mode 100644
index 000..e646a93
--- /dev/null
+++ b/drivers/spi/ti-qspi.c
@@ -0,0 +1,357 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated
+ *
+ * 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/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+
+#include linux/spi/spi.h
+
+struct dra7xxx_qspi {
+ struct spi_master *master;
+ void __iomem*base;
+ int device_type;
+ struct device *dev;
nit: move this pointer up and the int down.
+ u32 spi_max_frequency;
+ u32 cmd;
+ u32 dc;
+};
+
+#define QSPI_PID (0x0)
+#define QSPI_SYSCONFIG (0x10)
+#define QSPI_INTR_STATUS_RAW_SET (0x20)
+#define QSPI_INTR_STATUS_ENABLED_CLEAR (0x24)
+#define QSPI_INTR_ENABLE_SET_REG (0x28)
+#define QSPI_INTR_ENABLE_CLEAR_REG (0x2c)
+#define QSPI_SPI_CLOCK_CNTRL_REG (0x40)
+#define QSPI_SPI_DC_REG (0x44)
+#define QSPI_SPI_CMD_REG (0x48)
+#define QSPI_SPI_STATUS_REG (0x4c)
+#define QSPI_SPI_DATA_REG(0x50)
+#define QSPI_SPI_SETUP0_REG (0x54)
+#define QSPI_SPI_SWITCH_REG (0x64)
+#define QSPI_SPI_SETUP1_REG (0x58)
+#define QSPI_SPI_SETUP2_REG (0x5c)
+#define QSPI_SPI_SETUP3_REG (0x60)
+#define QSPI_SPI_DATA_REG_1 (0x68)
+#define QSPI_SPI_DATA_REG_2 (0x6c)
+#define QSPI_SPI_DATA_REG_3 (0x70)
+
+#define QSPI_TIMEOUT 200
+
+#define QSPI_FCLK19200
+
+/* Clock Control */
+#define QSPI_CLK_EN (1 31)
+#define QSPI_CLK_DIV_MAX 0x
+
+/* Command */
+#define QSPI_EN_CS(n)(n 28)
+#define QSPI_WLEN(n) ((n-1) 19)
+#define QSPI_3_PIN (1 18)
+#define QSPI_RD_SNGL (1 16)
+#define QSPI_WR_SNGL (2 16)
+#define QSPI_RD_QUAD (7 16)
+#define QSPI_INVAL (4 16)
+
+/* Device Control */
+#define QSPI_DD(m, n)(m (3 + n*8))
+#define QSPI_CKPHA(n)(1 (2 + n*8))
+#define QSPI_CSPOL(n)(1 (1 + n*8))
+#define QSPI_CKPOL(n)(1 (n*8))
+
+/* Status */
+#define QSPI_WC (1 1)
+#define QSPI_BUSY(1 0)
+#define QSPI_WC_BUSY (QSPI_WC | QSPI_BUSY)
+#define QSPI_XFER_DONE QSPI_WC
+
+#define XFER_END 0x01
+
+#define SPI_AUTOSUSPEND_TIMEOUT 2000
+
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi-base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi-base + reg);
+}
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi =
+ spi_master_get_devdata(spi-master);
+
+ int clk_div;
+
+ if (!qspi-spi_max_frequency)
+ clk_div = 0;
won't this generate division by zero ?
+ else
+ clk_div = (QSPI_FCLK / qspi-spi_max_frequency) - 1;
this QSPI_FCLK looks like it should be a clk_get_rate().
+ pr_debug(%s: hz:
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tue, Jul 02, 2013 at 02:26:39PM +0530, Sourav Poddar wrote: 1. Placed pm specific calls in prepare/unprepare apis. 2. Put a mask to support upto 32 bits word length. Does this hardware really support anything other than 8 bits per word? There is no code in the driver which pays any attention to the word size... signature.asc Description: Digital signature
RE: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas
Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 27, 2013 10:05 AM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux-omap@vger.kernel.org Subject: RE: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:36 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you please pull this one? A gentle ping on this. Could you pull this one. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Mark Brown broo...@linaro.org --- .../devicetree/bindings/regulator/palmas-pmic.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas- pmic.txt b/Documentation/devicetree/bindings/regulator/palmas- pmic.txt index d5a3086..5115cd7 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps659038-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. -- 1.7.5.4 Regards, Keerthy Regards, Keerthy -- 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 1/4] MFD: Add TPS659038 documentation under Palmas
Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 27, 2013 10:03 AM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Hi Grant, -Original Message- From: J, KEERTHY Sent: Monday, June 24, 2013 6:26 PM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; J, KEERTHY; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:35 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you pull this Please? A gentle ping on this. A gentle ping on this. Could you pull this one? Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 1.7.5.4 Regards, Keerthy Regards, Keerthy Regards, Keerthy -- 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: spi: Add qspi flash controller
Hi, On Tue, Jul 02, 2013 at 10:32:47AM +0100, Mark Brown wrote: On Tue, Jul 02, 2013 at 02:26:39PM +0530, Sourav Poddar wrote: 1. Placed pm specific calls in prepare/unprepare apis. 2. Put a mask to support upto 32 bits word length. Does this hardware really support anything other than 8 bits per word? There is no code in the driver which pays any attention to the word size... the HW has a 128-bit shift register ;-) but driver doesn't look complete. -- balbi signature.asc Description: Digital signature
Re: [PATCHv2] drivers: spi: Add qspi flash controller
Hi Felipe,
On Tuesday 02 July 2013 02:54 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 02:26:39PM +0530, Sourav Poddar wrote:
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..ea14eff 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K) += spi-omap-100k.o
obj-$(CONFIG_SPI_OMAP24XX)+= spi-omap2-mcspi.o
+obj-$(CONFIG_QSPI_DRA7xxx) += ti-qspi.o
all other drivers are prepended with spi-
Hmm, will change the name in next version.
diff --git a/drivers/spi/ti-qspi.c b/drivers/spi/ti-qspi.c
new file mode 100644
index 000..e646a93
--- /dev/null
+++ b/drivers/spi/ti-qspi.c
@@ -0,0 +1,357 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated
+ *
+ * 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.
+ */
+
+#includelinux/kernel.h
+#includelinux/init.h
+#includelinux/interrupt.h
+#includelinux/module.h
+#includelinux/device.h
+#includelinux/delay.h
+#includelinux/dma-mapping.h
+#includelinux/dmaengine.h
+#includelinux/omap-dma.h
+#includelinux/platform_device.h
+#includelinux/err.h
+#includelinux/clk.h
+#includelinux/io.h
+#includelinux/slab.h
+#includelinux/pm_runtime.h
+#includelinux/of.h
+#includelinux/of_device.h
+#includelinux/pinctrl/consumer.h
+
+#includelinux/spi/spi.h
+
+struct dra7xxx_qspi {
+ struct spi_master *master;
+ void __iomem*base;
+ int device_type;
+ struct device *dev;
nit: move this pointer up and the int down.
Ok.
+ u32 spi_max_frequency;
+ u32 cmd;
+ u32 dc;
+};
+
+#define QSPI_PID (0x0)
+#define QSPI_SYSCONFIG (0x10)
+#define QSPI_INTR_STATUS_RAW_SET (0x20)
+#define QSPI_INTR_STATUS_ENABLED_CLEAR (0x24)
+#define QSPI_INTR_ENABLE_SET_REG (0x28)
+#define QSPI_INTR_ENABLE_CLEAR_REG (0x2c)
+#define QSPI_SPI_CLOCK_CNTRL_REG (0x40)
+#define QSPI_SPI_DC_REG(0x44)
+#define QSPI_SPI_CMD_REG (0x48)
+#define QSPI_SPI_STATUS_REG(0x4c)
+#define QSPI_SPI_DATA_REG (0x50)
+#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SWITCH_REG(0x64)
+#define QSPI_SPI_SETUP1_REG(0x58)
+#define QSPI_SPI_SETUP2_REG(0x5c)
+#define QSPI_SPI_SETUP3_REG(0x60)
+#define QSPI_SPI_DATA_REG_1(0x68)
+#define QSPI_SPI_DATA_REG_2(0x6c)
+#define QSPI_SPI_DATA_REG_3(0x70)
+
+#define QSPI_TIMEOUT 200
+
+#define QSPI_FCLK 19200
+
+/* Clock Control */
+#define QSPI_CLK_EN(1 31)
+#define QSPI_CLK_DIV_MAX 0x
+
+/* Command */
+#define QSPI_EN_CS(n) (n 28)
+#define QSPI_WLEN(n) ((n-1) 19)
+#define QSPI_3_PIN (1 18)
+#define QSPI_RD_SNGL (1 16)
+#define QSPI_WR_SNGL (2 16)
+#define QSPI_RD_QUAD (7 16)
+#define QSPI_INVAL (4 16)
+
+/* Device Control */
+#define QSPI_DD(m, n) (m (3 + n*8))
+#define QSPI_CKPHA(n) (1 (2 + n*8))
+#define QSPI_CSPOL(n) (1 (1 + n*8))
+#define QSPI_CKPOL(n) (1 (n*8))
+
+/* Status */
+#define QSPI_WC(1 1)
+#define QSPI_BUSY (1 0)
+#define QSPI_WC_BUSY (QSPI_WC | QSPI_BUSY)
+#define QSPI_XFER_DONE QSPI_WC
+
+#define XFER_END 0x01
+
+#define SPI_AUTOSUSPEND_TIMEOUT 2000
+
+static inline unsigned long dra7xxx_readl(struct dra7xxx_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi-base + reg);
+}
+
+static inline void dra7xxx_writel(struct dra7xxx_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi-base + reg);
+}
+
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi =
+ spi_master_get_devdata(spi-master);
+
+ int clk_div;
+
+ if (!qspi-spi_max_frequency)
+ clk_div = 0;
won't this generate division by zero ?
Yes, Probably only an error should be thrown here. ?
since min clk_div should be kept at 1.
+ else
+ clk_div = (QSPI_FCLK
Re: [PATCHv2] drivers: spi: Add qspi flash controller
Hi,
On Tue, Jul 02, 2013 at 03:30:42PM +0530, Sourav Poddar wrote:
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi =
+ spi_master_get_devdata(spi-master);
+
+ int clk_div;
+
+ if (!qspi-spi_max_frequency)
+ clk_div = 0;
won't this generate division by zero ?
Yes, Probably only an error should be thrown here. ?
since min clk_div should be kept at 1.
right, if spi_max_frequency isn't passed, this is a broken DT binding.
Bail out.
+ pm_runtime_get_sync(qspi-dev);
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG)
+ ~QSPI_CLK_EN, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div 0) {
btw, add a space between clk_div and
+ dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
+ dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
+ timeout = QSPI_TIMEOUT;
+ while ((status QSPI_WC_BUSY) != QSPI_XFER_DONE) {
do you really need to poll ? No IRQ available ?
There is an interrupt available, I will try using that.
look at how i2c-omap.c synchronizes interrupt with the transfer_msg
code. It just uses a wait_for_completion().
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m-spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int flags = 0;
+
+ /* setup command reg */
+ qspi-cmd = 0;
+ qspi-cmd |= QSPI_WLEN(8);
+ qspi-cmd |= QSPI_EN_CS(0);
+ qspi-cmd |= 0xfff;
Since, we dont know the number of frame lenght that need to be
transferred and it comes from the spi framework, we keep the frame
lenght to maximum.
Then depending on the count value above in while loop, we terminate
our trasnfer.
what ? seriously didn't get what you meant.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tue, Jul 02, 2013 at 12:44:04PM +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 10:32:47AM +0100, Mark Brown wrote: Does this hardware really support anything other than 8 bits per word? There is no code in the driver which pays any attention to the word size... the HW has a 128-bit shift register ;-) but driver doesn't look complete. That's not the issue - remember that SPI specifies big endian byte ordering for words on the bus so things will need to be reordered by the hardware for anything except 8 bits. signature.asc Description: Digital signature
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tuesday 02 July 2013 03:46 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 03:30:42PM +0530, Sourav Poddar wrote:
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi =
+ spi_master_get_devdata(spi-master);
+
+ int clk_div;
+
+ if (!qspi-spi_max_frequency)
+ clk_div = 0;
won't this generate division by zero ?
Yes, Probably only an error should be thrown here. ?
since min clk_div should be kept at 1.
right, if spi_max_frequency isn't passed, this is a broken DT binding.
Bail out.
+ pm_runtime_get_sync(qspi-dev);
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG)
+ ~QSPI_CLK_EN, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div 0) {
btw, add a space between clk_div and
+ dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
+ dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
+ timeout = QSPI_TIMEOUT;
+ while ((status QSPI_WC_BUSY) != QSPI_XFER_DONE) {
do you really need to poll ? No IRQ available ?
There is an interrupt available, I will try using that.
look at how i2c-omap.c synchronizes interrupt with the transfer_msg
code. It just uses a wait_for_completion().
Ok.
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m-spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int flags = 0;
+
+ /* setup command reg */
+ qspi-cmd = 0;
+ qspi-cmd |= QSPI_WLEN(8);
+ qspi-cmd |= QSPI_EN_CS(0);
+ qspi-cmd |= 0xfff;
Since, we dont know the number of frame lenght that need to be
transferred and it comes from the spi framework, we keep the frame
lenght to maximum.
Then depending on the count value above in while loop, we terminate
our trasnfer.
what ? seriously didn't get what you meant.
I mean, the lower 12 bits of cmd register is meant to be filled with
frame lenght.
But the frame lenght is parsed when you iterate the list. So, what is
done here is that
the framelenght is kept to its maximum value.
Then, to signal the the end of the frame, we use
static int qspi_transfer_msg(struct dra7xxx_qspi *qspi, unsigned count,
const u8 *txbuf, u8 *rxbuf, bool flags)
{
uint status;
int timeout;
while (count--) {
if (txbuf) {
pr_debug(tx cmd %08x dc %08x data %02x\n,
qspi-cmd | QSPI_WR_SNGL, qspi-dc,
*txbuf);
dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
QSPI_SPI_CMD_REG);
status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
timeout = QSPI_TIMEOUT;
while ((status QSPI_WC_BUSY) != QSPI_XFER_DONE) {
if (--timeout 0) {
pr_debug(QSPI tx timed out\n);
return
.
status, *(rxbuf-1));
}
}
if (flags XFER_END)
dra7xxx_writel(qspi, qspi-cmd | QSPI_INVAL,
QSPI_SPI_CMD_REG);
}
INVAL will terminate the current frame.
--
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: spi: Add qspi flash controller
Hi Mark, On Tuesday 02 July 2013 03:47 PM, Mark Brown wrote: On Tue, Jul 02, 2013 at 12:44:04PM +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 10:32:47AM +0100, Mark Brown wrote: Does this hardware really support anything other than 8 bits per word? There is no code in the driver which pays any attention to the word size... the HW has a 128-bit shift register ;-) but driver doesn't look complete. That's not the issue - remember that SPI specifies big endian byte ordering for words on the bus so things will need to be reordered by the hardware for anything except 8 bits. Yes, I defaulted my driver to assume 8 bits. I will introduce case by case reads based on t-len Something like.. case 8: readb(); case 16: readw(); case 32: readl(); ~Sourav -- 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: spi: Add qspi flash controller
Hi,
On Tue, Jul 02, 2013 at 03:53:49PM +0530, Sourav Poddar wrote:
On Tuesday 02 July 2013 03:46 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 03:30:42PM +0530, Sourav Poddar wrote:
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi =
+ spi_master_get_devdata(spi-master);
+
+ int clk_div;
+
+ if (!qspi-spi_max_frequency)
+ clk_div = 0;
won't this generate division by zero ?
Yes, Probably only an error should be thrown here. ?
since min clk_div should be kept at 1.
right, if spi_max_frequency isn't passed, this is a broken DT binding.
Bail out.
+ pm_runtime_get_sync(qspi-dev);
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG)
+~QSPI_CLK_EN, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div 0) {
btw, add a space between clk_div and
+ dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
+ dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
+ timeout = QSPI_TIMEOUT;
+ while ((status QSPI_WC_BUSY) != QSPI_XFER_DONE) {
do you really need to poll ? No IRQ available ?
There is an interrupt available, I will try using that.
look at how i2c-omap.c synchronizes interrupt with the transfer_msg
code. It just uses a wait_for_completion().
Ok.
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m-spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int flags = 0;
+
+ /* setup command reg */
+ qspi-cmd = 0;
+ qspi-cmd |= QSPI_WLEN(8);
+ qspi-cmd |= QSPI_EN_CS(0);
+ qspi-cmd |= 0xfff;
Since, we dont know the number of frame lenght that need to be
transferred and it comes from the spi framework, we keep the frame
lenght to maximum.
Then depending on the count value above in while loop, we terminate
our trasnfer.
what ? seriously didn't get what you meant.
I mean, the lower 12 bits of cmd register is meant to be filled with
frame lenght.
But the frame lenght is parsed when you iterate the list. So, what is
which list ?
done here is that
the framelenght is kept to its maximum value.
why ? That seems wrong. If you can get the actual frame length at some
point, that's what you should use.
Then, to signal the the end of the frame, we use
static int qspi_transfer_msg(struct dra7xxx_qspi *qspi, unsigned count,
const u8 *txbuf, u8 *rxbuf, bool flags)
{
uint status;
int timeout;
while (count--) {
if (txbuf) {
pr_debug(tx cmd %08x dc %08x data %02x\n,
qspi-cmd | QSPI_WR_SNGL, qspi-dc,
*txbuf);
dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
QSPI_SPI_CMD_REG);
status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
timeout = QSPI_TIMEOUT;
while ((status QSPI_WC_BUSY) != QSPI_XFER_DONE) {
if (--timeout 0) {
pr_debug(QSPI tx timed out\n);
return
.
status, *(rxbuf-1));
}
}
if (flags XFER_END)
dra7xxx_writel(qspi, qspi-cmd | QSPI_INVAL,
QSPI_SPI_CMD_REG);
}
INVAL will terminate the current frame.
nevermind that this value is RESERVED on the documentation. You should
not rely on reserved features, they can go away at any point in time.
That's probably there only for some IP debugging kinda thing.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tuesday 02 July 2013 04:01 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 03:53:49PM +0530, Sourav Poddar wrote:
On Tuesday 02 July 2013 03:46 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 03:30:42PM +0530, Sourav Poddar wrote:
+static int dra7xxx_qspi_setup(struct spi_device *spi)
+{
+ struct dra7xxx_qspi *qspi =
+ spi_master_get_devdata(spi-master);
+
+ int clk_div;
+
+ if (!qspi-spi_max_frequency)
+ clk_div = 0;
won't this generate division by zero ?
Yes, Probably only an error should be thrown here. ?
since min clk_div should be kept at 1.
right, if spi_max_frequency isn't passed, this is a broken DT binding.
Bail out.
+ pm_runtime_get_sync(qspi-dev);
+
+ /* disable SCLK */
+ dra7xxx_writel(qspi, dra7xxx_readl(qspi, QSPI_SPI_CLOCK_CNTRL_REG)
+ ~QSPI_CLK_EN, QSPI_SPI_CLOCK_CNTRL_REG);
+
+ if (clk_div0) {
btw, add a space between clk_div and
+ dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
+ dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
+ dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
+ QSPI_SPI_CMD_REG);
+ status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
+ timeout = QSPI_TIMEOUT;
+ while ((statusQSPI_WC_BUSY) != QSPI_XFER_DONE) {
do you really need to poll ? No IRQ available ?
There is an interrupt available, I will try using that.
look at how i2c-omap.c synchronizes interrupt with the transfer_msg
code. It just uses a wait_for_completion().
Ok.
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m-spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int flags = 0;
+
+ /* setup command reg */
+ qspi-cmd = 0;
+ qspi-cmd |= QSPI_WLEN(8);
+ qspi-cmd |= QSPI_EN_CS(0);
+ qspi-cmd |= 0xfff;
Since, we dont know the number of frame lenght that need to be
transferred and it comes from the spi framework, we keep the frame
lenght to maximum.
Then depending on the count value above in while loop, we terminate
our trasnfer.
what ? seriously didn't get what you meant.
I mean, the lower 12 bits of cmd register is meant to be filled with
frame lenght.
But the frame lenght is parsed when you iterate the list. So, what is
which list ?
message list, from which we iterate through each transfers.
done here is that
the framelenght is kept to its maximum value.
why ? That seems wrong. If you can get the actual frame length at some
point, that's what you should use.
Ok.Then probably it makes sense to have frame count interrupt also to
signal the end of frame.
Then, to signal the the end of the frame, we use
static int qspi_transfer_msg(struct dra7xxx_qspi *qspi, unsigned count,
const u8 *txbuf, u8 *rxbuf, bool flags)
{
uint status;
int timeout;
while (count--) {
if (txbuf) {
pr_debug(tx cmd %08x dc %08x data %02x\n,
qspi-cmd | QSPI_WR_SNGL, qspi-dc,
*txbuf);
dra7xxx_writel(qspi, *txbuf++, QSPI_SPI_DATA_REG);
dra7xxx_writel(qspi, qspi-dc, QSPI_SPI_DC_REG);
dra7xxx_writel(qspi, qspi-cmd | QSPI_WR_SNGL,
QSPI_SPI_CMD_REG);
status = dra7xxx_readl(qspi, QSPI_SPI_STATUS_REG);
timeout = QSPI_TIMEOUT;
while ((status QSPI_WC_BUSY) != QSPI_XFER_DONE) {
if (--timeout 0) {
pr_debug(QSPI tx timed out\n);
return
.
status, *(rxbuf-1));
}
}
if (flags XFER_END)
dra7xxx_writel(qspi, qspi-cmd | QSPI_INVAL,
QSPI_SPI_CMD_REG);
}
INVAL will terminate the current frame.
nevermind that this value is RESERVED on the documentation. You should
not rely on reserved features, they can go away at any point in time.
That's probably there only for some IP debugging kinda thing.
--
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: spi: Add qspi flash controller
On Tue, Jul 02, 2013 at 11:17:18AM +0100, Mark Brown wrote:
On Tue, Jul 02, 2013 at 12:44:04PM +0300, Felipe Balbi wrote:
On Tue, Jul 02, 2013 at 10:32:47AM +0100, Mark Brown wrote:
Does this hardware really support anything other than 8 bits per word?
There is no code in the driver which pays any attention to the word
size...
the HW has a 128-bit shift register ;-) but driver doesn't look
complete.
That's not the issue - remember that SPI specifies big endian byte
ordering for words on the bus so things will need to be reordered by the
hardware for anything except 8 bits.
right, the driver is far from being complete. In fact this driver is
quite buggy, if you look here :
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m-spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int flags = 0;
+
+ /* setup command reg */
+ qspi-cmd = 0;
+ qspi-cmd |= QSPI_WLEN(8);
Sourav hardcodes wordlenght to 8-bits, and yet he enables 8, 16 and
32-bits per word.
+ qspi-cmd |= QSPI_EN_CS(0);
he's also hardcoding the chipselect line which should be take from
m-spi-chip_select
+ qspi-cmd |= 0xfff;
and he's hardcoding the frame length to 4096 frames!!
This is all buggy.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On 7/2/2013 2:26 PM, Sourav Poddar wrote:
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).
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:
1. Placed pm specific calls in prepare/unprepare apis.
2. Put a mask to support upto 32 bits word length.
3. Used devm_ioremap_resource variants.
4. Add dt binding doumentation.
Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 ++
drivers/spi/Kconfig |8 +
drivers/spi/Makefile |1 +
drivers/spi/ti-qspi.c | 357
+
4 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
create mode 100644 drivers/spi/ti-qspi.c
Please cc devicetree-discuss list when adding new bindings.
+static int dra7xxx_qspi_probe(struct platform_device *pdev)
+{
+ struct dra7xxx_qspi *qspi;
+ struct spi_master *master;
+ struct resource *r;
+ struct device_node *np = pdev-dev.of_node;
+ u32 max_freq;
+ int ret;
+
+ master = spi_alloc_master(pdev-dev, sizeof(*qspi));
+ if (!master)
+ return -ENOMEM;
+
+ master-mode_bits = SPI_CPOL | SPI_CPHA;
+
+ master-num_chipselect = 1;
+ master-bus_num = -1;
+ master-setup = dra7xxx_qspi_setup;
+ master-prepare_transfer_hardware = dra7xxx_qspi_prepare_xfer;
+ master-transfer_one_message = dra7xxx_qspi_start_transfer_one;
+ master-unprepare_transfer_hardware = dra7xxx_qspi_unprepare_xfer;
+ master-dev.of_node = pdev-dev.of_node;
+ master-bits_per_word_mask = BIT(32 - 1) | BIT(16 - 1) | BIT(8 - 1);
+
+ dev_set_drvdata(pdev-dev, master);
+
+ qspi = spi_master_get_devdata(master);
+ qspi-master = master;
+ qspi-dev = pdev-dev;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (r == NULL) {
+ ret = -ENODEV;
+ goto free_master;
+ }
+
+ qspi-base = devm_ioremap_resource(pdev-dev, r);
+ if (!qspi-base) {
+ dev_dbg(pdev-dev, can't ioremap MCSPI\n);
+ ret = -ENOMEM;
+ goto free_master;
+ }
This should be
if (IS_ERR(qspi-base)) {
dev_dbg(pdev-dev, can't ioremap QSPI\n);
ret = PTR_ERR(qspi-base);
goto free_master;
}
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
Re: [PATCHv2] drivers: spi: Add qspi flash controller
Hi Sekhar,
On Tuesday 02 July 2013 04:27 PM, Sekhar Nori wrote:
On 7/2/2013 2:26 PM, Sourav Poddar wrote:
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).
Signed-off-by: Sourav Poddarsourav.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:
1. Placed pm specific calls in prepare/unprepare apis.
2. Put a mask to support upto 32 bits word length.
3. Used devm_ioremap_resource variants.
4. Add dt binding doumentation.
Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 ++
drivers/spi/Kconfig |8 +
drivers/spi/Makefile |1 +
drivers/spi/ti-qspi.c | 357 +
4 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
create mode 100644 drivers/spi/ti-qspi.c
Please cc devicetree-discuss list when adding new bindings.
Ok.
+static int dra7xxx_qspi_probe(struct platform_device *pdev)
+{
+ struct dra7xxx_qspi *qspi;
+ struct spi_master *master;
+ struct resource *r;
+ struct device_node *np = pdev-dev.of_node;
+ u32 max_freq;
+ int ret;
+
+ master = spi_alloc_master(pdev-dev, sizeof(*qspi));
+ if (!master)
+ return -ENOMEM;
+
+ master-mode_bits = SPI_CPOL | SPI_CPHA;
+
+ master-num_chipselect = 1;
+ master-bus_num = -1;
+ master-setup = dra7xxx_qspi_setup;
+ master-prepare_transfer_hardware = dra7xxx_qspi_prepare_xfer;
+ master-transfer_one_message = dra7xxx_qspi_start_transfer_one;
+ master-unprepare_transfer_hardware = dra7xxx_qspi_unprepare_xfer;
+ master-dev.of_node = pdev-dev.of_node;
+ master-bits_per_word_mask = BIT(32 - 1) | BIT(16 - 1) | BIT(8 - 1);
+
+ dev_set_drvdata(pdev-dev, master);
+
+ qspi = spi_master_get_devdata(master);
+ qspi-master = master;
+ qspi-dev =pdev-dev;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (r == NULL) {
+ ret = -ENODEV;
+ goto free_master;
+ }
+
+ qspi-base = devm_ioremap_resource(pdev-dev, r);
+ if (!qspi-base) {
+ dev_dbg(pdev-dev, can't ioremap MCSPI\n);
+ ret = -ENOMEM;
+ goto free_master;
+ }
This should be
if (IS_ERR(qspi-base)) {
dev_dbg(pdev-dev, can't ioremap QSPI\n);
ret = PTR_ERR(qspi-base);
goto free_master;
}
Ok. will change it in next version.
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
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tue, Jul 02, 2013 at 01:43:38PM +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 11:17:18AM +0100, Mark Brown wrote: + /* setup command reg */ + qspi-cmd = 0; + qspi-cmd |= QSPI_WLEN(8); Sourav hardcodes wordlenght to 8-bits, and yet he enables 8, 16 and 32-bits per word. Yeah, that's what I noticed (well first off I noticed that there were no constraints on bits per word at all). + qspi-cmd |= QSPI_EN_CS(0); he's also hardcoding the chipselect line which should be take from m-spi-chip_select This one *can* be OK if the driver only accepts one chip select (though obviously supporting more is better). I'd really only done a fairly high level review for framework stuff so hadn't got that far yet. One thing I really want to get round to doing with the SPI core is providing an easy to pick up GPIO chip select as standard signature.asc Description: Digital signature
[RFC 8/9] ARM: OMAP2+: AM335x: Migrate to OMAP4 PRM/CM APIs
With all the minor issues addressed in previous patches
we can now safely migrate over AM335x to OMAP4 APIs and
get rid of the AM335x version of the same.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c | 7 ++
arch/arm/mach-omap2/io.c | 3 +
arch/arm/mach-omap2/omap_hwmod.c | 177 ++-
arch/arm/mach-omap2/prm44xx.c| 15
4 files changed, 31 insertions(+), 171 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index 4ec9712..2937c54 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -491,3 +491,10 @@ struct clkdm_ops omap4_clkdm_operations = {
.clkdm_clk_enable = omap4_clkdm_clk_enable,
.clkdm_clk_disable = omap4_clkdm_clk_disable,
};
+
+struct clkdm_ops am33xx_clkdm_operations = {
+ .clkdm_sleep= omap4_clkdm_sleep,
+ .clkdm_wakeup = omap4_clkdm_wakeup,
+ .clkdm_clk_enable = omap4_clkdm_clk_enable,
+ .clkdm_clk_disable = omap4_clkdm_clk_disable,
+};
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..dbfabab 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -575,8 +575,11 @@ void __init am33xx_init_early(void)
NULL);
omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE));
omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE), NULL);
+ omap_prm_base_init();
+ omap_cm_base_init();
omap3xxx_check_revision();
ti81xx_check_features();
+ omap44xx_prm_init();
am33xx_voltagedomains_init();
am33xx_powerdomains_init();
am33xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 0f756b4..3385bab 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -953,26 +953,6 @@ static void _omap4_enable_module(struct omap_hwmod *oh)
}
/**
- * _am33xx_enable_module - enable CLKCTRL modulemode on AM33XX
- * @oh: struct omap_hwmod *
- *
- * Enables the PRCM module mode related to the hwmod @oh.
- * No return value.
- */
-static void _am33xx_enable_module(struct omap_hwmod *oh)
-{
- if (!oh-clkdm || !oh-prcm.omap4.modulemode)
- return;
-
- pr_debug(omap_hwmod: %s: %s: %d\n,
-oh-name, __func__, oh-prcm.omap4.modulemode);
-
- am33xx_cm_module_enable(oh-prcm.omap4.modulemode, oh-clkdm-cm_inst,
- oh-clkdm-clkdm_offs,
- oh-prcm.omap4.clkctrl_offs);
-}
-
-/**
* _omap4_wait_target_disable - wait for a module to be disabled on OMAP4
* @oh: struct omap_hwmod *
*
@@ -999,31 +979,6 @@ static int _omap4_wait_target_disable(struct omap_hwmod
*oh)
}
/**
- * _am33xx_wait_target_disable - wait for a module to be disabled on AM33XX
- * @oh: struct omap_hwmod *
- *
- * Wait for a module @oh to enter slave idle. Returns 0 if the module
- * does not have an IDLEST bit or if the module successfully enters
- * slave idle; otherwise, pass along the return value of the
- * appropriate *_cm*_wait_module_idle() function.
- */
-static int _am33xx_wait_target_disable(struct omap_hwmod *oh)
-{
- if (!oh)
- return -EINVAL;
-
- if (oh-_int_flags _HWMOD_NO_MPU_PORT)
- return 0;
-
- if (oh-flags HWMOD_NO_IDLEST)
- return 0;
-
- return am33xx_cm_wait_module_idle(oh-clkdm-cm_inst,
-oh-clkdm-clkdm_offs,
-oh-prcm.omap4.clkctrl_offs);
-}
-
-/**
* _count_mpu_irqs - count the number of MPU IRQ lines associated with @oh
* @oh: struct omap_hwmod *oh
*
@@ -1837,36 +1792,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
}
/**
- * _am33xx_disable_module - enable CLKCTRL modulemode on AM33XX
- * @oh: struct omap_hwmod *
- *
- * Disable the PRCM module mode related to the hwmod @oh.
- * Return EINVAL if the modulemode is not supported and 0 in case of success.
- */
-static int _am33xx_disable_module(struct omap_hwmod *oh)
-{
- int v;
-
- if (!oh-clkdm || !oh-prcm.omap4.modulemode)
- return -EINVAL;
-
- pr_debug(omap_hwmod: %s: %s\n, oh-name, __func__);
-
- if (_are_any_hardreset_lines_asserted(oh))
- return 0;
-
- am33xx_cm_module_disable(oh-clkdm-cm_inst, oh-clkdm-clkdm_offs,
-oh-prcm.omap4.clkctrl_offs);
-
- v = _am33xx_wait_target_disable(oh);
- if (v)
- pr_warn(omap_hwmod: %s: _wait_target_disable failed\n,
- oh-name);
-
- return 0;
-}
-
-/**
* _ocp_softreset - reset an omap_hwmod via the OCP_SYSCONFIG bit
* @oh: struct omap_hwmod *
*
@@ -2887,33 +2812,6 @@ static int _omap4_wait_target_ready(struct omap_hwmod
[RFC 0/9] Consolidate AM335x and OMAP4 PRM/CM APIs
Even though there are differences in the PRCM features on different TI SoCs (mostly OMAP3+) the underlying PRCM architecture is similar on OMAP4+, AM335x, AM437x (and DM81xx). With some rework of the OMAP4 APIs we can easily consolidate the low level PRM/CM APIs for these SoCs and cut down 800+ lines under mach-omap2. These patches go on top of v3.10-rc7 (would rebase once 3.11-rc1 is out) and have been boot tested on AM335x EVM. I have tried to ensure OMAP4+ is not affected but any testing on OMAP4+ would be helpful. NOTE: The last patch which has the AM335x restart function would need to be reworked since the OMAP4 code is moving to a different file. Vaibhav Bedia (9): ARM: OMAP2+: AM335X: Add a constant CM_INST for all the clkdomains ARM: OMAP2+: CM code: Reintroduce SW_SLEEP for OMAP4 class of devices ARM: OMAP2+: AM335X: Add a constant PRCM_PARITION for the pwrdomains ARM: OMAP4: PRM: Get rid of hardcoded offsets ARM: OMAP4: Add offsets for pwrstctrl and pwrstst ARM: OMAP4: CM code: Remove the check for non-zero clkctrl_offs ARM: OMAP4: Generalize reset handling API ARM: OMAP2+: AM335x: Migrate to OMAP4 PRM/CM APIs ARM: OMAP2+: AM33XX: Get rid of custom PRM, CM APIs arch/arm/mach-omap2/Makefile| 3 +- arch/arm/mach-omap2/am33xx-restart.c| 34 --- arch/arm/mach-omap2/clockdomains33xx_data.c | 18 ++ arch/arm/mach-omap2/cm33xx.c| 364 arch/arm/mach-omap2/cm33xx.h| 41 +--- arch/arm/mach-omap2/cminst44xx.c| 31 ++- arch/arm/mach-omap2/io.c| 3 + arch/arm/mach-omap2/omap4-common.c | 14 ++ arch/arm/mach-omap2/omap_hwmod.c| 184 +- arch/arm/mach-omap2/powerdomains33xx_data.c | 6 + arch/arm/mach-omap2/powerdomains44xx_data.c | 32 +++ arch/arm/mach-omap2/prm33xx.c | 338 -- arch/arm/mach-omap2/prm33xx.h | 12 +- arch/arm/mach-omap2/prm44xx.c | 45 ++-- arch/arm/mach-omap2/prminst44xx.c | 47 +++- arch/arm/mach-omap2/prminst44xx.h | 6 +- 16 files changed, 183 insertions(+), 995 deletions(-) delete mode 100644 arch/arm/mach-omap2/am33xx-restart.c delete mode 100644 arch/arm/mach-omap2/cm33xx.c delete mode 100644 arch/arm/mach-omap2/prm33xx.c -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/9] ARM: OMAP2+: CM code: Reintroduce SW_SLEEP for OMAP4 class of devices
Commit 65aa94b (ARM: OMAP4: clockdomain/CM code: Update supported transition
modes)
removed SW_SLEEP mode for clockdomains on OMAP4 class of devices. Not having
SW_SLEEP mode works fine for OMAP4/5 devices but it gets in the way of other
devices like AM335x which have the same hardware underneath but support only
SW_SLEEP/SW_WKUP modes. So far, AM335x has been uses its own set of PRM/CM
APIs and hence the lack of SW_SLEEP mode in the OMAP4 code was not a problem.
However we would like to consolidate the AM335x and OMAP4 code and reintroducing
this mode is necessary. Doing so also makes the API consistent with what
the comments states.
While here also fixup a trivial typo in the comment.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index f0290f5..2d1d4ef 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -237,7 +237,7 @@ void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst,
u16 cdoffs)
}
/**
- * omap4_cminst_clkdm_force_sleep - try to take a clockdomain out of idle
+ * omap4_cminst_clkdm_force_wakeup - try to take a clockdomain out of idle
* @part: PRCM partition ID that the clockdomain registers exist in
* @inst: CM instance register offset (*_INST macro)
* @cdoffs: Clockdomain register offset (*_CDOFFS macro)
@@ -250,6 +250,20 @@ void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst,
u16 cdoffs)
_clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_WAKEUP, part, inst, cdoffs);
}
+/**
+ * omap4_cminst_clkdm_force_sleep - try to put a clockdomain to idle
+ * @part: PRCM partition ID that the clockdomain registers exist in
+ * @inst: CM instance register offset (*_INST macro)
+ * @cdoffs: Clockdomain register offset (*_CDOFFS macro)
+ *
+ * Put a clockdomain referred to by (@part, @inst, @cdoffs) to idle,
+ * forcing it to sleep. No return value.
+ */
+void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs)
+{
+ _clktrctrl_write(OMAP34XX_CLKSTCTRL_FORCE_SLEEP, part, inst, cdoffs);
+}
+
/*
*
*/
@@ -404,7 +418,7 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct
clockdomain *clkdm)
static int omap4_clkdm_sleep(struct clockdomain *clkdm)
{
- omap4_cminst_clkdm_enable_hwsup(clkdm-prcm_partition,
+ omap4_cminst_clkdm_force_sleep(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
return 0;
}
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 7/9] ARM: OMAP4: Generalize reset handling API
Reset status bits on AM335x have different masks and register
is not consistent across powerdomains. Generalize the OMAP4
reset handling code to take care of these.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 7 +++
arch/arm/mach-omap2/prminst44xx.c | 27 +++
arch/arm/mach-omap2/prminst44xx.h | 5 +++--
3 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..0f756b4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3011,13 +3011,12 @@ static int _omap4_deassert_hardreset(struct omap_hwmod
*oh,
if (!oh-clkdm)
return -EINVAL;
- if (ohri-st_shift)
- pr_err(omap_hwmod: %s: %s: hwmod data error: OMAP4 does not
support st_shift\n,
- oh-name, ohri-name);
return omap4_prminst_deassert_hardreset(ohri-rst_shift,
+ ohri-st_shift,
oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
- oh-prcm.omap4.rstctrl_offs);
+ oh-prcm.omap4.rstctrl_offs,
+ oh-prcm.omap4.rstst_offs);
}
/**
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index c12320c..5e165ea 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -136,26 +136,37 @@ int omap4_prminst_assert_hardreset(u8 shift, u8 part, s16
inst,
* -EINVAL upon an argument error, -EEXIST if the submodule was already out
* of reset, or -EBUSY if the submodule did not exit reset promptly.
*/
-int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
-u16 rstctrl_offs)
+int omap4_prminst_deassert_hardreset(u8 shift, u8 st_shift, u8 part, s16 inst,
+u16 rstctrl_offs, u16 rstst_offs)
{
int c;
- u32 mask = 1 shift;
- u16 rstst_offs = rstctrl_offs + OMAP4_RST_CTRL_ST_OFFSET;
+ u32 ctrl_mask = 1 shift;
+ u32 st_mask;
+
+ if (!rstst_offs)
+ rstst_offs = rstctrl_offs + OMAP4_RST_CTRL_ST_OFFSET;
+
+ if (!st_shift) {
+ st_mask = 1 shift;
+ st_shift = shift;
+ } else {
+ st_mask = 1 st_shift;
+ }
/* Check the current status to avoid de-asserting the line twice */
if (omap4_prminst_is_hardreset_asserted(shift, part, inst,
rstctrl_offs) == 0)
return -EEXIST;
+
/* Clear the reset status by writing 1 to the status bit */
- omap4_prminst_rmw_inst_reg_bits(0x, mask, part, inst,
+ omap4_prminst_rmw_inst_reg_bits(0x, st_mask, part, inst,
rstst_offs);
/* de-assert the reset control line */
- omap4_prminst_rmw_inst_reg_bits(mask, 0, part, inst, rstctrl_offs);
+ omap4_prminst_rmw_inst_reg_bits(ctrl_mask, 0, part, inst, rstctrl_offs);
/* wait the status to be set */
- omap_test_timeout(omap4_prminst_is_hardreset_asserted(shift, part, inst,
- rstst_offs),
+ omap_test_timeout(omap4_prminst_is_hardreset_asserted(st_shift, part,
+ inst, rstst_offs),
MAX_MODULE_HARDRESET_WAIT, c);
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
diff --git a/arch/arm/mach-omap2/prminst44xx.h
b/arch/arm/mach-omap2/prminst44xx.h
index a2ede2d..3973212 100644
--- a/arch/arm/mach-omap2/prminst44xx.h
+++ b/arch/arm/mach-omap2/prminst44xx.h
@@ -27,8 +27,9 @@ extern int omap4_prminst_is_hardreset_asserted(u8 shift, u8
part, s16 inst,
u16 rstctrl_offs);
extern int omap4_prminst_assert_hardreset(u8 shift, u8 part, s16 inst,
u16 rstctrl_offs);
-extern int omap4_prminst_deassert_hardreset(u8 shift, u8 part, s16 inst,
- u16 rstctrl_offs);
+extern int omap4_prminst_deassert_hardreset(u8 shift, u8 st_shift, u8 part,
+ s16 inst, u16 rstctrl_offs,
+ u16 rstst_offs);
extern void omap_prm_base_init(void);
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 9/9] ARM: OMAP2+: AM33XX: Get rid of custom PRM, CM APIs
Now that we have migrated AM335x over to use OMAP4 style
PRM, CM APIs we can delete the custom APIs
To avoid build breakage the reset function is reimplemented
in the same patch.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +-
arch/arm/mach-omap2/am33xx-restart.c | 34
arch/arm/mach-omap2/cm33xx.c | 364 ---
arch/arm/mach-omap2/cm33xx.h | 39
arch/arm/mach-omap2/omap4-common.c | 14 ++
arch/arm/mach-omap2/prm33xx.c| 338
arch/arm/mach-omap2/prm33xx.h| 11 --
arch/arm/mach-omap2/prminst44xx.c| 20 ++
arch/arm/mach-omap2/prminst44xx.h| 1 +
9 files changed, 36 insertions(+), 788 deletions(-)
delete mode 100644 arch/arm/mach-omap2/am33xx-restart.c
delete mode 100644 arch/arm/mach-omap2/cm33xx.c
delete mode 100644 arch/arm/mach-omap2/prm33xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..a47b517 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -56,7 +56,7 @@ AFLAGS_sram34xx.o :=-Wa,-march=armv7-a
# Restart code (OMAP4/5 currently in omap4-common.c)
obj-$(CONFIG_SOC_OMAP2420) += omap2-restart.o
obj-$(CONFIG_SOC_OMAP2430) += omap2-restart.o
-obj-$(CONFIG_SOC_AM33XX) += am33xx-restart.o
+obj-$(CONFIG_SOC_AM33XX) += omap4-common.o
obj-$(CONFIG_ARCH_OMAP3) += omap3-restart.o
# Pin multiplexing
@@ -109,7 +109,6 @@ obj-y += prm_common.o
cm_common.o
obj-$(CONFIG_ARCH_OMAP2) += prm2xxx_3xxx.o prm2xxx.o cm2xxx.o
obj-$(CONFIG_ARCH_OMAP3) += prm2xxx_3xxx.o prm3xxx.o cm3xxx.o
obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o
-obj-$(CONFIG_SOC_AM33XX) += prm33xx.o cm33xx.o
omap-prcm-4-5-common = cminst44xx.o cm44xx.o prm44xx.o \
prcm_mpu44xx.o prminst44xx.o \
vc44xx_data.o vp44xx_data.o
diff --git a/arch/arm/mach-omap2/am33xx-restart.c
b/arch/arm/mach-omap2/am33xx-restart.c
deleted file mode 100644
index 88e4fa8..000
--- a/arch/arm/mach-omap2/am33xx-restart.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * am33xx-restart.c - Code common to all AM33xx machines.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include linux/kernel.h
-
-#include common.h
-#include prm-regbits-33xx.h
-#include prm33xx.h
-
-/**
- * am3xx_restart - trigger a software restart of the SoC
- * @mode: the reboot mode, see arch/arm/kernel/{setup,process}.c
- * @cmd: passed from the userspace program rebooting the system (if provided)
- *
- * Resets the SoC. For @cmd, see the 'reboot' syscall in
- * kernel/sys.c. No return value.
- */
-void am33xx_restart(char mode, const char *cmd)
-{
- /* TODO: Handle mode and cmd if necessary */
-
- am33xx_prm_rmw_reg_bits(AM33XX_GLOBAL_WARM_SW_RST_MASK,
- AM33XX_GLOBAL_WARM_SW_RST_MASK,
- AM33XX_PRM_DEVICE_MOD,
- AM33XX_PRM_RSTCTRL_OFFSET);
-
- /* OCP barrier */
- (void)am33xx_prm_read_reg(AM33XX_PRM_DEVICE_MOD,
- AM33XX_PRM_RSTCTRL_OFFSET);
-}
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
deleted file mode 100644
index 325a515..000
--- a/arch/arm/mach-omap2/cm33xx.c
+++ /dev/null
@@ -1,364 +0,0 @@
-/*
- * AM33XX CM functions
- *
- * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
- * Vaibhav Hiremath hvaib...@ti.com
- *
- * Reference taken from from OMAP4 cminst44xx.c
- *
- * 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 version 2.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; 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/types.h
-#include linux/errno.h
-#include linux/err.h
-#include linux/io.h
-
-#include clockdomain.h
-#include cm.h
-#include cm33xx.h
-#include cm-regbits-34xx.h
-#include cm-regbits-33xx.h
-#include prm33xx.h
-
-/*
- * CLKCTRL_IDLEST_*: possible values for the CM_*_CLKCTRL.IDLEST bitfield:
- *
- * 0x0 func: Module is fully functional, including OCP
- * 0x1 trans:Module is performing transition: wakeup, or sleep, or sleep
- * abortion
- * 0x2 idle: Module is in Idle mode (only OCP part). It is functional if
- *
[RFC 4/9] ARM: OMAP4: PRM: Get rid of hardcoded offsets
Instead of hardcoded offsets of PWRSTCTRL and PWRSTST use the offsets from the pwrdomain data. This helps us in reusing the same code across OMAP4 and AM335x. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- arch/arm/mach-omap2/prm44xx.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c index 415c7e0..11f56a7 100644 --- a/arch/arm/mach-omap2/prm44xx.c +++ b/arch/arm/mach-omap2/prm44xx.c @@ -384,7 +384,8 @@ static int omap4_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst) omap4_prminst_rmw_inst_reg_bits(OMAP_POWERSTATE_MASK, (pwrst OMAP_POWERSTATE_SHIFT), pwrdm-prcm_partition, - pwrdm-prcm_offs, OMAP4_PM_PWSTCTRL); + pwrdm-prcm_offs, + pwrdm-pwrstctrl_offs); return 0; } @@ -393,7 +394,7 @@ static int omap4_pwrdm_read_next_pwrst(struct powerdomain *pwrdm) u32 v; v = omap4_prminst_read_inst_reg(pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTCTRL); + pwrdm-pwrstctrl_offs); v = OMAP_POWERSTATE_MASK; v = OMAP_POWERSTATE_SHIFT; @@ -405,7 +406,7 @@ static int omap4_pwrdm_read_pwrst(struct powerdomain *pwrdm) u32 v; v = omap4_prminst_read_inst_reg(pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTST); + pwrdm-pwrstst_offs); v = OMAP_POWERSTATEST_MASK; v = OMAP_POWERSTATEST_SHIFT; @@ -417,7 +418,7 @@ static int omap4_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm) u32 v; v = omap4_prminst_read_inst_reg(pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTST); + pwrdm-pwrstst_offs); v = OMAP4430_LASTPOWERSTATEENTERED_MASK; v = OMAP4430_LASTPOWERSTATEENTERED_SHIFT; @@ -429,7 +430,8 @@ static int omap4_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm) omap4_prminst_rmw_inst_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK, (1 OMAP4430_LOWPOWERSTATECHANGE_SHIFT), pwrdm-prcm_partition, - pwrdm-prcm_offs, OMAP4_PM_PWSTCTRL); + pwrdm-prcm_offs, + pwrdm-pwrstctrl_offs); return 0; } @@ -438,7 +440,7 @@ static int omap4_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm) omap4_prminst_rmw_inst_reg_bits(OMAP4430_LASTPOWERSTATEENTERED_MASK, OMAP4430_LASTPOWERSTATEENTERED_MASK, pwrdm-prcm_partition, - pwrdm-prcm_offs, OMAP4_PM_PWSTST); + pwrdm-prcm_offs, pwrdm-pwrstst_offs); return 0; } @@ -449,7 +451,7 @@ static int omap4_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst) v = pwrst __ffs(OMAP4430_LOGICRETSTATE_MASK); omap4_prminst_rmw_inst_reg_bits(OMAP4430_LOGICRETSTATE_MASK, v, pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTCTRL); + pwrdm-pwrstctrl_offs); return 0; } @@ -463,7 +465,7 @@ static int omap4_pwrdm_set_mem_onst(struct powerdomain *pwrdm, u8 bank, omap4_prminst_rmw_inst_reg_bits(m, (pwrst __ffs(m)), pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTCTRL); + pwrdm-pwrstctrl_offs); return 0; } @@ -477,7 +479,7 @@ static int omap4_pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8 bank, omap4_prminst_rmw_inst_reg_bits(m, (pwrst __ffs(m)), pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTCTRL); + pwrdm-pwrstctrl_offs); return 0; } @@ -487,7 +489,7 @@ static int omap4_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm) u32 v; v = omap4_prminst_read_inst_reg(pwrdm-prcm_partition, pwrdm-prcm_offs, - OMAP4_PM_PWSTST); + pwrdm-pwrstst_offs); v = OMAP4430_LOGICSTATEST_MASK; v = OMAP4430_LOGICSTATEST_SHIFT; @@ -499,7 +501,7 @@ static int omap4_pwrdm_read_logic_retst(struct powerdomain *pwrdm) u32 v; v = omap4_prminst_read_inst_reg(pwrdm-prcm_partition, pwrdm-prcm_offs, -
[RFC 3/9] ARM: OMAP2+: AM335X: Add a constant PRCM_PARITION for the pwrdomains
OMAP4 style PRM, CM APIs expect the pwrdomains to specify a
prcm_partition. Introduce a PRCM_PARTITION for the AM335x
pwrdomains so that we can eventually consolidate the code.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/powerdomains33xx_data.c | 6 ++
arch/arm/mach-omap2/prm33xx.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomains33xx_data.c
b/arch/arm/mach-omap2/powerdomains33xx_data.c
index 869adb8..646e912 100644
--- a/arch/arm/mach-omap2/powerdomains33xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains33xx_data.c
@@ -24,6 +24,7 @@
static struct powerdomain gfx_33xx_pwrdm = {
.name = gfx_pwrdm,
.voltdm = { .name = core },
+ .prcm_partition = AM33XX_PRM_PARTITION,
.prcm_offs = AM33XX_PRM_GFX_MOD,
.pwrstctrl_offs = AM33XX_PM_GFX_PWRSTCTRL_OFFSET,
.pwrstst_offs = AM33XX_PM_GFX_PWRSTST_OFFSET,
@@ -55,6 +56,7 @@ static struct powerdomain gfx_33xx_pwrdm = {
static struct powerdomain rtc_33xx_pwrdm = {
.name = rtc_pwrdm,
.voltdm = { .name = rtc },
+ .prcm_partition = AM33XX_PRM_PARTITION,
.prcm_offs = AM33XX_PRM_RTC_MOD,
.pwrstctrl_offs = AM33XX_PM_RTC_PWRSTCTRL_OFFSET,
.pwrstst_offs = AM33XX_PM_RTC_PWRSTST_OFFSET,
@@ -65,6 +67,7 @@ static struct powerdomain rtc_33xx_pwrdm = {
static struct powerdomain wkup_33xx_pwrdm = {
.name = wkup_pwrdm,
.voltdm = { .name = core },
+ .prcm_partition = AM33XX_PRM_PARTITION,
.prcm_offs = AM33XX_PRM_WKUP_MOD,
.pwrstctrl_offs = AM33XX_PM_WKUP_PWRSTCTRL_OFFSET,
.pwrstst_offs = AM33XX_PM_WKUP_PWRSTST_OFFSET,
@@ -75,6 +78,7 @@ static struct powerdomain wkup_33xx_pwrdm = {
static struct powerdomain per_33xx_pwrdm = {
.name = per_pwrdm,
.voltdm = { .name = core },
+ .prcm_partition = AM33XX_PRM_PARTITION,
.prcm_offs = AM33XX_PRM_PER_MOD,
.pwrstctrl_offs = AM33XX_PM_PER_PWRSTCTRL_OFFSET,
.pwrstst_offs = AM33XX_PM_PER_PWRSTST_OFFSET,
@@ -118,6 +122,7 @@ static struct powerdomain per_33xx_pwrdm = {
static struct powerdomain mpu_33xx_pwrdm = {
.name = mpu_pwrdm,
.voltdm = { .name = mpu },
+ .prcm_partition = AM33XX_PRM_PARTITION,
.prcm_offs = AM33XX_PRM_MPU_MOD,
.pwrstctrl_offs = AM33XX_PM_MPU_PWRSTCTRL_OFFSET,
.pwrstst_offs = AM33XX_PM_MPU_PWRSTST_OFFSET,
@@ -161,6 +166,7 @@ static struct powerdomain mpu_33xx_pwrdm = {
static struct powerdomain cefuse_33xx_pwrdm = {
.name = cefuse_pwrdm,
.voltdm = { .name = core },
+ .prcm_partition = AM33XX_PRM_PARTITION,
.prcm_offs = AM33XX_PRM_CEFUSE_MOD,
.pwrstctrl_offs = AM33XX_PM_CEFUSE_PWRSTCTRL_OFFSET,
.pwrstst_offs = AM33XX_PM_CEFUSE_PWRSTST_OFFSET,
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 9b9918d..c82b22b2 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -24,6 +24,7 @@
#define AM33XX_PRM_REGADDR(inst, reg) \
AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE + (inst) + (reg))
+#define AM33XX_PRM_PARTITION 1
/* PRM instances */
#define AM33XX_PRM_OCP_SOCKET_MOD 0x0B00
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/9] ARM: OMAP2+: AM335X: Add a constant CM_INST for all the clkdomains
OMAP4 style PRM, CM APIs expect the clkdomains to specify a
cm_inst. Introduce a CM_INST for the AM335x clkdomains so that
we can eventually consolidate the code.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/clockdomains33xx_data.c | 18 ++
arch/arm/mach-omap2/cm33xx.h| 2 ++
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/clockdomains33xx_data.c
b/arch/arm/mach-omap2/clockdomains33xx_data.c
index 32c90fd..819a6bf 100644
--- a/arch/arm/mach-omap2/clockdomains33xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains33xx_data.c
@@ -25,6 +25,7 @@
static struct clockdomain l4ls_am33xx_clkdm = {
.name = l4ls_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_L4LS_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -33,6 +34,7 @@ static struct clockdomain l4ls_am33xx_clkdm = {
static struct clockdomain l3s_am33xx_clkdm = {
.name = l3s_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_L3S_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -41,6 +43,7 @@ static struct clockdomain l3s_am33xx_clkdm = {
static struct clockdomain l4fw_am33xx_clkdm = {
.name = l4fw_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_L4FW_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -49,6 +52,7 @@ static struct clockdomain l4fw_am33xx_clkdm = {
static struct clockdomain l3_am33xx_clkdm = {
.name = l3_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_L3_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -57,6 +61,7 @@ static struct clockdomain l3_am33xx_clkdm = {
static struct clockdomain l4hs_am33xx_clkdm = {
.name = l4hs_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_L4HS_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -65,6 +70,7 @@ static struct clockdomain l4hs_am33xx_clkdm = {
static struct clockdomain ocpwp_l3_am33xx_clkdm = {
.name = ocpwp_l3_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_OCPWP_L3_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -73,6 +79,7 @@ static struct clockdomain ocpwp_l3_am33xx_clkdm = {
static struct clockdomain pruss_ocp_am33xx_clkdm = {
.name = pruss_ocp_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_PRUSS_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -81,6 +88,7 @@ static struct clockdomain pruss_ocp_am33xx_clkdm = {
static struct clockdomain cpsw_125mhz_am33xx_clkdm = {
.name = cpsw_125mhz_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_CPSW_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -89,6 +97,7 @@ static struct clockdomain cpsw_125mhz_am33xx_clkdm = {
static struct clockdomain lcdc_am33xx_clkdm = {
.name = lcdc_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_LCDC_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -97,6 +106,7 @@ static struct clockdomain lcdc_am33xx_clkdm = {
static struct clockdomain clk_24mhz_am33xx_clkdm = {
.name = clk_24mhz_clkdm,
.pwrdm = { .name = per_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_PER_MOD,
.clkdm_offs = AM33XX_CM_PER_CLK_24MHZ_CLKSTCTRL_OFFSET,
.flags = CLKDM_CAN_SWSUP,
@@ -105,6 +115,7 @@ static struct clockdomain clk_24mhz_am33xx_clkdm = {
static struct clockdomain l4_wkup_am33xx_clkdm = {
.name = l4_wkup_clkdm,
.pwrdm = { .name = wkup_pwrdm },
+ .prcm_partition = AM33XX_CM_PARTITION,
.cm_inst= AM33XX_CM_WKUP_MOD,
.clkdm_offs = AM33XX_CM_WKUP_CLKSTCTRL_OFFSET,
[RFC 5/9] ARM: OMAP4: Add offsets for pwrstctrl and pwrstst
OMAP4 powerdomains have a consistent register layout
and so far the pwrstctrl and pwrstst offsets were
hardcoded in the lowlevel APIs.
AM335x powerdomains don't have a consistent register
layout and hence the offsets used in the lowlevel APIs
need to be removed. As part of the AM335x work two additional
fields pwrstctrl_offs and pwrstst_offs were introduced in
the pwrdomain data structure. To enable consolidation of
AM335x and OMAP4 lowlevel APIs add in the appropriate
offsets to the OMAP4 pwrdomains.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 32 +
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index 704664c..ed53787 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,6 +36,8 @@ static struct powerdomain core_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs= OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 5,
@@ -62,6 +64,8 @@ static struct powerdomain gfx_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs= OMAP4430_PRM_GFX_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
.pwrsts_mem_ret = {
@@ -79,6 +83,8 @@ static struct powerdomain abe_44xx_pwrdm = {
.voltdm = { .name = iva },
.prcm_offs= OMAP4430_PRM_ABE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks= 2,
@@ -99,6 +105,8 @@ static struct powerdomain dss_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs= OMAP4430_PRM_DSS_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks= 1,
@@ -117,6 +125,8 @@ static struct powerdomain tesla_44xx_pwrdm = {
.voltdm = { .name = iva },
.prcm_offs= OMAP4430_PRM_TESLA_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 3,
@@ -139,6 +149,8 @@ static struct powerdomain wkup_44xx_pwrdm = {
.voltdm = { .name = wakeup },
.prcm_offs= OMAP4430_PRM_WKUP_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_ON,
.banks= 1,
.pwrsts_mem_ret = {
@@ -155,6 +167,8 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs= OMAP4430_PRCM_MPU_CPU0_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
@@ -172,6 +186,8 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs= OMAP4430_PRCM_MPU_CPU1_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
@@ -189,6 +205,8 @@ static struct powerdomain emu_44xx_pwrdm = {
.voltdm = { .name = wakeup },
.prcm_offs= OMAP4430_PRM_EMU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs = OMAP4_PM_PWSTST,
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
.pwrsts_mem_ret = {
@@ -205,6 +223,8 @@ static struct powerdomain mpu_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs= OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .pwrstctrl_offs = OMAP4_PM_PWSTCTRL,
+ .pwrstst_offs
[RFC 6/9] ARM: OMAP4: CM code: Remove the check for non-zero clkctrl_offs
AM335x which will migrate to the OMAP4 APIs in subsequent patches
has one CLKCTRL at offset 0. A similar check existed in the AM335x
custom APIs and that was removed to fix a crash on boot in commit
169c82a (ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check bug).
Do the same in the OMAP4 API to avoid any regressions on AM335x
when it switches over to these APIs.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/cminst44xx.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index 2d1d4ef..4ec9712 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -285,9 +285,6 @@ int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16
cdoffs,
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(part, inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
@@ -310,9 +307,6 @@ int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16
cdoffs, u16 clkctrl_off
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout((_clkctrl_idlest(part, inst, cdoffs, clkctrl_offs) ==
CLKCTRL_IDLEST_DISABLED),
MAX_MODULE_DISABLE_TIME, i);
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
(+ 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 (with Author Name fixed) Changes v2 - v3 - PATCH-1: re-arranged code to remove redundancy, added NAND_BUSWIDTH_AUTO - PATCH-2: updated nand-ecc-opt DT mapping and Documentation - PATCH-3: code-cleaning + changes to match PATCH-1 - PATCH-4 DROPPED update DT attribute for ti,nand-ecc-opt - received feedback to keep DT mapping independent of linuxism - PATCH-4:NEW : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt - independent patch for AM335x-evm.dts update based on PATCH-2 Changes v1 - v2 added [PATCH 3/4] and [PATCH 4/4] Patches in this series: [PATCH 1/4]: clean-up and optimization for supported ECC schemes. [PATCH 2/4]: add separate DT options each supported ECC scheme. [PATCH 3/4]: update BCH4 ECC implementation (using ELM or using lib/bch.h) [PATCH 4/4]: ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt After this patch series, omap2-nand driver will supports following ECC schemes: +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W| |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| |OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires, Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm. - Selection of OMAP_ECC_BCHx_CODE_HW requires, Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module. Pekon Gupta (4): mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe ARM: OMAP2+: cleaned-up DT support of various ECC schemes mtd:nand:omap2: updated support for BCH4 ECC scheme ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt .../devicetree/bindings/mtd/gpmc-nand.txt | 65 ++- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/mach-omap2/gpmc.c | 14 +- drivers/mtd/nand/Kconfig | 30 +- drivers/mtd/nand/omap2.c | 481 ++--- include/linux/platform_data/elm.h | 4 + include/linux/platform_data/mtd-nand-omap2.h | 22 +- 7 files changed, 308 insertions(+), 310 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_OMAP_BCH)| | |
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
This patch
- separates the configurations for various ECC schemes.
- fixes dependency issues based on Kconfig options.
- cleans up redundant code
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 504 +++---
include/linux/platform_data/elm.h | 4 +
2 files changed, 252 insertions(+), 256 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index daa3dfc..c4c7e0d 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,8 +25,10 @@
#include linux/of.h
#include linux/of_device.h
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
#endif
@@ -141,6 +143,9 @@
#define BCH_ECC_SIZE0 0x0 /* ecc_size0 = 0, no oob protection */
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
+#define BADBLOCK_MARKER_LENGTH 0x2
+#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
+
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +187,11 @@ struct omap_nand_info {
u_char *buf;
int buf_len;
struct gpmc_nand_regs reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
- struct bch_control *bch;
- struct nand_ecclayout ecclayout;
+ /* fields specific for BCHx_HW ECC scheme */
+ struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
-#endif
};
/**
@@ -1058,8 +1060,6 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
/**
* omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
* @mtd: MTD device structure
@@ -1141,6 +1141,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd,
int mode)
writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
}
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
* @mtd: MTD device structure
@@ -1227,6 +1228,62 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
}
/**
+ * omap3_correct_data_bch - Decode received data and correct errors
+ * @mtd: MTD device structure
+ * @data: page data
+ * @read_ecc: ecc read from nand flash
+ * @calc_ecc: ecc read from HW ECC registers
+ */
+static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ int i, count;
+ /* cannot correct more than 8 errors */
+ unsigned int errloc[8];
+ struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
+ mtd);
+
+ count = decode_bch(info-bch, NULL, 512, read_ecc, calc_ecc, NULL,
+ errloc);
+ if (count 0) {
+ /* correct errors */
+ for (i = 0; i count; i++) {
+ /* correct data only, not ecc bytes */
+ if (errloc[i] 8*512)
+ data[errloc[i]/8] ^= 1 (errloc[i] 7);
+ pr_debug(corrected bitflip %u\n, errloc[i]);
+ }
+ } else if (count 0) {
+ pr_err(ecc unrecoverable error\n);
+ }
+ return count;
+}
+
+/**
+ * omap3_free_bch - Release BCH ecc resources
+ * @mtd: MTD device structure
+ */
+static void omap3_free_bch(struct mtd_info *mtd)
+{
+ struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
+
[PATCH v4 3/4] mtd:nand:omap2: updated support for BCH4 ECC scheme
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW - uses GPMC H/W engine for calculating ECC. - uses software library (lib/bch.h nand_bch.h) for error correction. - OMAP_ECC_BCH4_CODE_HW - uses GPMC H/W engine for calculating ECC. - uses ELM H/W engine for error correction. With this patch omap2-nand driver supports following ECC schemes: +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W| |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| |OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ Important: - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires, Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm. - Selection of OMAP_ECC_BCHx_CODE_HW requires, Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module. Signed-off-by: Pekon Gupta pe...@ti.com --- .../devicetree/bindings/mtd/gpmc-nand.txt | 27 +++- drivers/mtd/nand/Kconfig | 30 +--- drivers/mtd/nand/omap2.c | 165 + include/linux/platform_data/mtd-nand-omap2.h | 10 +- 4 files changed, 101 insertions(+), 131 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 690070e..b3f23df 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -28,26 +28,43 @@ Optional properties: hamming_code_sw 1-bit Hamming ECC - ECC calculation in software - Error detection in software + - ECC layout compatible with S/W scheme hamming_code_hw 1-bit Hamming ECC - ECC calculation in hardware - Error detection in software + - ECC layout compatible with S/W scheme hamming_code_hw_romcode 1-bit Hamming ECC - ECC calculation in hardware - Error detection in software - - ECC layout compatible to ROM code + - ECC layout compatible with ROM code - bch8_hw_code_detection_sw 8-bit BCH ECC + bch4_code_hw_detection_sw 4-bit BCH ECC - ECC calculation in hardware - Error detection in software - - depends on CONFIG_MTD_NAND_ECC_BCH + - ECC layout compatible with S/W scheme + * depends on CONFIG_MTD_NAND_ECC_BCH + + bch4_code_hw 4-bit BCH ECC + - ECC calculation in hardware + - Error detection in hardware + - ECC layout compatible with ROM code + * depends on CONFIG_MTD_NAND_OMAP_BCH + * requires elm_id to be specified + + bch8_code_hw_detection_sw 8-bit BCH ECC + - ECC calculation in hardware + - Error detection in software + - ECC layout compatible with S/W scheme + * depends on CONFIG_MTD_NAND_ECC_BCH bch8_code_hw 8-bit BCH ECC - ECC calculation in hardware - Error detection in hardware - - depends on CONFIG_MTD_NAND_OMAP_BCH - - requires elm_id to be specified + - ECC layout compatible with ROM code + * depends on
[PATCH v4 4/4] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index c71bb77..cc50fb8 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -135,7 +135,7 @@
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-opt = bch8_code_hw;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
gpmc,cs-on-ns = 0;
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
ECC scheme on NAND devices can be implemented in multiple ways.Some using
Software algorithm, while others using in-build Hardware engines.
omap2-nand driver currently supports following flavours of ECC schemes,
selectable via DTB.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
+---+---+---+
|(requires CONFIG_MTD_NAND_OMAP_BCH)| | |
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Selection of some ECC schemes also require enabling following Kconfig options.
This was done to optimize footprint of omap2-nand driver.
-Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
-Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
Signed-off-by: Pekon Gupta pe...@ti.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 44 --
arch/arm/mach-omap2/gpmc.c | 14 ---
include/linux/platform_data/mtd-nand-omap2.h | 22 +++
3 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 6a983c1..690070e 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -17,20 +17,42 @@ Required properties:
Optional properties:
- - nand-bus-width: Set this numeric value to 16 if the hardware
- is wired that way. If not specified, a bus
- width of 8 is assumed.
+ - nand-bus-width: Determines data-width of the connected device
+ x16 = 16
+ x8 = 8 (default)
- - ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc hamming mode method romcode layout
- bch4 4-bit BCH ecc code
- bch8 8-bit BCH ecc code
+ - ti,nand-ecc-opt:Determines the ECC scheme used by driver.
+ It can be any of the following strings:
+
+ hamming_code_sw 1-bit Hamming ECC
+ - ECC calculation in software
+ - Error detection in software
+
+ hamming_code_hw 1-bit Hamming ECC
+ - ECC calculation in hardware
+ - Error detection in software
+
+ hamming_code_hw_romcode 1-bit Hamming ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - ECC layout compatible to ROM code
+
+ bch8_hw_code_detection_sw 8-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in software
+ - depends on CONFIG_MTD_NAND_ECC_BCH
+
+ bch8_code_hw 8-bit BCH ECC
+ - ECC calculation in hardware
+ - Error detection in hardware
+ - depends on CONFIG_MTD_NAND_OMAP_BCH
+ - requires elm_id to be specified
+
+
+ - elm_id: Specifies elm device node. This is required to
+ support some BCH ECC schemes mentioned above.
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
For inline partiton table parsing (optional):
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fb6f241..2a6001e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1341,11 +1341,13 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
static const char * const nand_ecc_opts[] = {
-
RT and omap-gpio irqchip with DeviceTree
Hi..
I am running into Problems with a network adapter IRQ connected to an
omap-gpio pin.
omap-gpio expects gpio-request() to be called before i can use the pin.
But this is abstracted via the DeviceTree bindings.
I see 8d4c277e185c31359cf70573d8b0351fb7dd0dfe in mainline.
This one just puts a warning into the exact place, i am dealing with.
But i need to make this work, instead of bailing out.
I have this fix in place, instead:
---
commit 4ca17be8e7e24863cb98f440992fd89034aa34f5
Author: Torben Hohn torb...@linutronix.de
Date: Fri Jun 21 17:34:24 2013 +0200
gpio omap: Fix for DT calling into gpio_irq_type without request_gpio()
gpio_irq_type() requires that the GPIO is requested, do that.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f1fbedb2..57d956c 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -87,6 +87,8 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+static int omap_gpio_request(struct gpio_chip *chip, unsigned offset);
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return gpio_irq - bank-irq_base + bank-chip.base;
@@ -429,6 +431,9 @@ static int gpio_irq_type(struct irq_data *d, unsigned type)
if (!gpio)
gpio = irq_to_gpio(bank, d-irq);
+ if (!bank-mod_usage)
+ omap_gpio_request( bank-chip, gpio );
+
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
-
But now with RT i am running into a Problem, because gpio_irq_type() is called
under a raw_spinlock() But its calling pm_runtime_suspend() which carries a
normal spinlock.
-
/**
* irq_set_type - set the irq trigger type for an irq
* @irq: irq number
* @type: IRQ_TYPE_{LEVEL,EDGE}_* value - see include/linux/irq.h
*/
int irq_set_irq_type(unsigned int irq, unsigned int type)
{
unsigned long flags;
struct irq_desc *desc = irq_get_desc_buslock(irq, flags,
IRQ_GET_DESC_CHECK_GLOBAL);
int ret = 0;
if (!desc)
return -EINVAL;
type = IRQ_TYPE_SENSE_MASK;
ret = __irq_set_trigger(desc, irq, type);
irq_put_desc_busunlock(desc, flags);
return ret;
}
-
I think, i need a normal hook in the irq_chip, which prepares the irq, but i
dont see one.
--
Mit freundlichen Grüßen
Torben Hohn
Linutronix GmbH
Standort: Bremen
Phone: +49 421 5650 2310 ; Fax.: +49 7556 919 886
mailto: torb...@linutronix.de
Firmensitz / Registered Office: D-88690 Uhldingen, Auf dem Berg 3
Registergericht / Local District Court: Freiburg i. Br., HRB Nr. / Trade
register no.: 700 806;
Geschäftsführer / Managing Directors: Heinz Egger, Thomas Gleixner
signature.asc
Description: Digital signature
Re: RT and omap-gpio irqchip with DeviceTree
+ Grant, Linus W and Jean-Christophe.
On Tue, Jul 2, 2013 at 1:44 PM, Torben Hohn torb...@linutronix.de wrote:
Hi..
I am running into Problems with a network adapter IRQ connected to an
omap-gpio pin.
omap-gpio expects gpio-request() to be called before i can use the pin.
But this is abstracted via the DeviceTree bindings.
I see 8d4c277e185c31359cf70573d8b0351fb7dd0dfe in mainline.
This one just puts a warning into the exact place, i am dealing with.
But i need to make this work, instead of bailing out.
This has been discussed extensively on the linux-omap mailing list and
the agreement is that it has to be handled by the IRQ core. So when a
GPIO line is mapped in the IRQ domain with irq_create_of_mapping(),
the core has to take care to request the GPIO and configure it as
input.
But until we have this general solution we have to do it on a per irq
chip driver basis and the less hack-ish solution is to have a custom
.map function handler that request the GPIO used as IRQ.
There is already a patch [1] queued in Linus Walleij linux-gpio tree
[2] for-next branch that implements this for OMAP GPIO. It would be
great if you can test it and give feedback.
I have this fix in place, instead:
---
commit 4ca17be8e7e24863cb98f440992fd89034aa34f5
Author: Torben Hohn torb...@linutronix.de
Date: Fri Jun 21 17:34:24 2013 +0200
gpio omap: Fix for DT calling into gpio_irq_type without request_gpio()
gpio_irq_type() requires that the GPIO is requested, do that.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f1fbedb2..57d956c 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -87,6 +87,8 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1 GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+static int omap_gpio_request(struct gpio_chip *chip, unsigned offset);
+
static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return gpio_irq - bank-irq_base + bank-chip.base;
@@ -429,6 +431,9 @@ static int gpio_irq_type(struct irq_data *d, unsigned
type)
if (!gpio)
gpio = irq_to_gpio(bank, d-irq);
+ if (!bank-mod_usage)
+ omap_gpio_request( bank-chip, gpio );
+
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
-
But now with RT i am running into a Problem, because gpio_irq_type() is called
under a raw_spinlock() But its calling pm_runtime_suspend() which carries a
normal spinlock.
-
/**
* irq_set_type - set the irq trigger type for an irq
* @irq: irq number
* @type: IRQ_TYPE_{LEVEL,EDGE}_* value - see include/linux/irq.h
*/
int irq_set_irq_type(unsigned int irq, unsigned int type)
{
unsigned long flags;
struct irq_desc *desc = irq_get_desc_buslock(irq, flags,
IRQ_GET_DESC_CHECK_GLOBAL);
int ret = 0;
if (!desc)
return -EINVAL;
type = IRQ_TYPE_SENSE_MASK;
ret = __irq_set_trigger(desc, irq, type);
irq_put_desc_busunlock(desc, flags);
return ret;
}
-
I think, i need a normal hook in the irq_chip, which prepares the irq, but
i dont see one.
--
Mit freundlichen Grüßen
Torben Hohn
Linutronix GmbH
Standort: Bremen
Phone: +49 421 5650 2310 ; Fax.: +49 7556 919 886
mailto: torb...@linutronix.de
Firmensitz / Registered Office: D-88690 Uhldingen, Auf dem Berg 3
Registergericht / Local District Court: Freiburg i. Br., HRB Nr. / Trade
register no.: 700 806;
Geschäftsführer / Managing Directors: Heinz Egger, Thomas Gleixner
Thanks a lot and best regards,
Javier
[1]:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=570c4bb53366157fa076922d0fc7e7adfd81cf42
[2]: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[3.10] [AM335x-EVMSK] BUG: spinlock bad magic on CPU#0
Hi, While booting 3.10 on AM355x-evmsk with following steps seeing race condition leading to SPIN BUG: Attached log for reference. Config: omap2plus_defconfig. make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage -j 8 LOADADDR=0x80008000 make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- am335x-evmsk.dtb cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-evmsk.dtb zImage mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d zImage uImage [2.359689] cpsw: platform data missing [2.364835] BUG: spinlock bad magic on CPU#0, swapper/0/1 [2.370537] lock: 0xce11021c, .magic: , .owner: /0, .owner_cpu: 3 [2.377767] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-dirty #10 [2.384662] [c001bf38] (unwind_backtrace+0x0/0xf4) from [c0018650] (show_stack+0x10/0x14) [2.393639] [c0018650] (show_stack+0x10/0x14) from [c02ec380] (do_raw_spin_lock+0x1b8/0x1f8) [2.402896] [c02ec380] (do_raw_spin_lock+0x1b8/0x1f8) from [c054e7a8] (_raw_spin_lock_irqsave+0x4c/0x58) [2.413243] [c054e7a8] (_raw_spin_lock_irqsave+0x4c/0x58) from [c035d3d0] (devres_remove+0x20/0x80) [2.423125] [c035d3d0] (devres_remove+0x20/0x80) from [c035d440] (devres_release+0x10/0x38) [2.432273] [c035d440] (devres_release+0x10/0x38) from [c02fa718] (devm_pinctrl_put+0x18/0x40) [2.441699] [c02fa718] (devm_pinctrl_put+0x18/0x40) from [c0370470] (pinctrl_bind_pins+0x84/0xb8) [2.451397] [c0370470] (pinctrl_bind_pins+0x84/0xb8) from [c035a588] (driver_probe_device+0x60/0x224) [2.461462] [c035a588] (driver_probe_device+0x60/0x224) from [c035a7e0] (__driver_attach+0x94/0x98) [2.471343] [c035a7e0] (__driver_attach+0x94/0x98) from [c0358dd0] (bus_for_each_dev+0x68/0x8c) [2.480857] [c0358dd0] (bus_for_each_dev+0x68/0x8c) from [c0359714] (bus_add_driver+0x208/0x2a4) [2.490462] [c0359714] (bus_add_driver+0x208/0x2a4) from [c035adb4] (driver_register+0x78/0x194) [2.500067] [c035adb4] (driver_register+0x78/0x194) from [c0008684] (do_one_initcall+0x30/0x168) [2.509682] [c0008684] (do_one_initcall+0x30/0x168) from [c075c308] (kernel_init_freeable+0xf4/0x1c0) [2.519745] [c075c308] (kernel_init_freeable+0xf4/0x1c0) from [c05454cc] (kernel_init+0x8/0xe4) [2.529268] [c05454cc] (kernel_init+0x8/0xe4) from [c00142e8] (ret_from_fork+0x14/0x2c) [ 11.974206] BUG: spinlock lockup suspected on CPU#0, swapper/0/1 [ 11.980519] lock: 0xce11021c, .magic: , .owner: /0, .owner_cpu: 3 [ 11.987744] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-dirty #10 [ 11.994612] [c001bf38] (unwind_backtrace+0x0/0xf4) from [c0018650] (show_stack+0x10/0x14) [ 12.003577] [c0018650] (show_stack+0x10/0x14) from [c02ec338] (do_raw_spin_lock+0x170/0x1f8) [ 12.012818] [c02ec338] (do_raw_spin_lock+0x170/0x1f8) from [c054e7a8] (_raw_spin_lock_irqsave+0x4c/0x58) [ 12.023155] [c054e7a8] (_raw_spin_lock_irqsave+0x4c/0x58) from [c035d3d0] (devres_remove+0x20/0x80) [ 12.033033] [c035d3d0] (devres_remove+0x20/0x80) from [c035d440] (devres_release+0x10/0x38) [ 12.042179] [c035d440] (devres_release+0x10/0x38) from [c02fa718] (devm_pinctrl_put+0x18/0x40) [ 12.051600] [c02fa718] (devm_pinctrl_put+0x18/0x40) from [c0370470] (pinctrl_bind_pins+0x84/0xb8) [ 12.061294] [c0370470] (pinctrl_bind_pins+0x84/0xb8) from [c035a588] (driver_probe_device+0x60/0x224) [ 12.071352] [c035a588] (driver_probe_device+0x60/0x224) from [c035a7e0] (__driver_attach+0x94/0x98) [ 12.081228] [c035a7e0] (__driver_attach+0x94/0x98) from [c0358dd0] (bus_for_each_dev+0x68/0x8c) [ 12.090738] [c0358dd0] (bus_for_each_dev+0x68/0x8c) from [c0359714] (bus_add_driver+0x208/0x2a4) [ 12.100339] [c0359714] (bus_add_driver+0x208/0x2a4) from [c035adb4] (driver_register+0x78/0x194) [ 12.109940] [c035adb4] (driver_register+0x78/0x194) from [c0008684] (do_one_initcall+0x30/0x168) [ 12.119545] [c0008684] (do_one_initcall+0x30/0x168) from [c075c308] (kernel_init_freeable+0xf4/0x1c0) [ 12.129602] [c075c308] (kernel_init_freeable+0xf4/0x1c0) from [c05454cc] (kernel_init+0x8/0xe4) [ 12.139112] [c05454cc] (kernel_init+0x8/0xe4) from [c00142e8] (ret_from_fork+0x14/0x2c) Regards, Ambresh U-Boot 2012.10 (Jul 02 2013 - 10:41:19) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw,
Re: reset handling in am335x hwmod data
On 07/01/2013 11:37 PM, Hiremath, Vaibhav wrote: -Original Message- From: Balbi, Felipe Sent: Friday, June 28, 2013 4:24 PM To: Hiremath, Vaibhav Cc: Menon, Nishanth; Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-omap@vger.kernel.org; Tony Lindgren; Sebastian Andrzej Siewior Subject: Re: reset handling in am335x hwmod data Hi, On Mon, May 20, 2013 at 08:20:29PM +0200, Hiremath, Vaibhav wrote: -Original Message- From: Menon, Nishanth Sent: Monday, May 20, 2013 11:34 PM To: Hiremath, Vaibhav Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux- o...@vger.kernel.org; Tony Lindgren Subject: Re: reset handling in am335x hwmod data On 12:47-20130520, Hiremath, Vaibhav wrote: [...] On 20:10-20130517, Peter Korsgaard wrote: Kevin == Kevin Hilman khil...@linaro.org writes: In this case, we cannot reset that bank, otherwise Starter Kit will never boot in mainline. Bad PCB design, I know, but it's not something we can change now :-) Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is a Kevin fun one), and this is why we have omap_hwmod_no_setup_reset(). Yes, but there's no dts bindings for this, and from a quick test the reset handling happens before the device tree is probed. I have the same issue with TPS62361 on Palmas - GPIO controls the voltage register supplying MPU, without any driver setting things up, GPIO gets reset and obviously voltage value switches to an voltage where device does not function. Solution I am working on to solve this is [1]: snippet is part of a patch that I am working on atm. This is the right way to do it IMHO. Will allow the driver to exist when HWMOD will be eventually replaced by some other framework. [1]: http://pastebin.com/XPmAB1Zb Both seems to be different to me. What we need is to Avoid reset of whole GPIO bank during kernel boot. Yes - that is what the above does - as long as the GPIO is requested and set to the right level by the relevant driver, it is not unused and hence not reset at late_init. May be I am missing something here, Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall. Hmm.. You are right, I missed that :( I am a little unclear as to why this needs to have anything to do with the precise under-lying mechanism (hwmod or something else). May be both seem to be different to me needs a little further elaboration? GPIO is connected to the DDR VTT control pin, and we have observed that Due to GPIO bank reset as part of hwmod init during bootup. Is this because there is no need for an EMIF driver to handle DDR? and reset of the GPIO will occur as EMIF is configured at bootloader and there is no need to do that in kernel, correspondingly there is no driver to hold the gpio? Ideally, it would have been much better if drivers starts handling Idle, ocp reset and standby on their own (killing dependency on hwmod init layer). But looking at current state, I agree we need to use DT property here, so how about Adding DT property to GPIO node itself. But we have to parse I believe you mean at OMAP specific DT property for hwmod? something like ti,hwmod-no-init-reset? That’s the idea. It early during hwmod init stage. We should read all DT nodes Inside function __setup() function, that way can get rid of HWMOD_INIT_NO_RESET flag completely. Also, this will handle Both ocp_reset and domain reset. Forgot to mention, Since this is kernel boot failure issue, I think, By the time we reach to conclusion, another approach is to set HWMOD_INIT_NO_RESET flag For GPIO0 bank. a) if the GPIO gets moved over to some other GPIO bank on another platform, this wont work Yes that’s true, but such schematic interface is not recommended. And we have not seen any known side-effect of not resetting GPIO0 bank. unless you mark the GPIO as taken, another driver could in- adverantly take over the GPIO and set it to a wrong level (we had a similar story with LED gpio between Panda Vs Panda-ES). b) for platforms that dont use gpio to hold DDR power, maybe this is not even relevant and the GPIO bank can safely be reset? As I mentioned, there is no known side-effect of not resetting GPIO bank 0. It should depend on the platform. There are other uses for hwmod-no-reset - Eg. boot logo displayed by bootloader - if there is a reset of DSS block and re-configuration, we'd notice a blank-out, which is not desirable either. There could be a few other usage based on no-reset. In all cases, you'd prefer to make this: a) platform dependent (board dts) b) reserve GPIO as well so that no other driver'd take it - if they attempt ther'd at least be some form of warning. Completely agree with you on both the points, and my point and all my comments Were more related to option 'a' above. so, what happened here ? Will we not have AM335x-SK working in mainline
Re: OMAP baseline test results for v3.10-rc6
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. -- Regards, Nishanth Menon -- 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: RT and omap-gpio irqchip with DeviceTree
On Tue, Jul 02, 2013 at 02:15:46PM +0200, Javier Martinez Canillas wrote: + Grant, Linus W and Jean-Christophe. On Tue, Jul 2, 2013 at 1:44 PM, Torben Hohn torb...@linutronix.de wrote: Hi.. I am running into Problems with a network adapter IRQ connected to an omap-gpio pin. omap-gpio expects gpio-request() to be called before i can use the pin. But this is abstracted via the DeviceTree bindings. I see 8d4c277e185c31359cf70573d8b0351fb7dd0dfe in mainline. This one just puts a warning into the exact place, i am dealing with. But i need to make this work, instead of bailing out. This has been discussed extensively on the linux-omap mailing list and the agreement is that it has to be handled by the IRQ core. So when a GPIO line is mapped in the IRQ domain with irq_create_of_mapping(), the core has to take care to request the GPIO and configure it as input. Can you give me a pointer to this discussion please ? Because i fail to understand why you just dont save the irq_type in some private data structure, and then use chip-irq_enable() or something. But until we have this general solution we have to do it on a per irq chip driver basis and the less hack-ish solution is to have a custom .map function handler that request the GPIO used as IRQ. There is already a patch [1] queued in Linus Walleij linux-gpio tree [2] for-next branch that implements this for OMAP GPIO. It would be great if you can test it and give feedback. Thanks for the pointer. The kernel i am working on is based on 3.8.x (this is before the irq_domain change to linear) First i only backported: [1] and [2] With these i see big streams like these: [1.554809] omap_gpio gpio.9: Could not request GPIO-256 [1.560394] omap_gpio gpio.9: Could not request GPIO-255 [1.566009] omap_gpio gpio.9: Could not request GPIO-254 [1.571594] omap_gpio gpio.9: Could not request GPIO-253 [1.577178] omap_gpio gpio.9: Could not request GPIO-252 [1.582794] omap_gpio gpio.9: Could not request GPIO-251 This is basically coming from irq_domain_add_legacy() which calls ops-map(domain, irq, hwirq) before the gpio chip is actually added. I fixed it by also taking [3]. However, OMAP1 is still calling irq_domain_add_legacy(). This would probably break with DeviceTree. But since omap1 doesnt use DeviceTree, this is probably a non-issue. [1] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=570c4bb53366157fa076922d0fc7e7adfd81cf42 [2] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=50fc1d067d9f4b6c99717b91c1618075f859 [3] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=ede4d7a5b9835510fd1f724367f68d2fa4128453 -- Mit freundlichen Grüßen Torben Hohn Linutronix GmbH Standort: Bremen Phone: +49 421 5650 2310 ; Fax.: +49 7556 919 886 mailto: torb...@linutronix.de Firmensitz / Registered Office: D-88690 Uhldingen, Auf dem Berg 3 Registergericht / Local District Court: Freiburg i. Br., HRB Nr. / Trade register no.: 700 806; Geschäftsführer / Managing Directors: Heinz Egger, Thomas Gleixner signature.asc Description: Digital signature
Re: omap4 ehci sporadic resume issue
On 06/28/2013 07:47 PM, Michael Trimarchi wrote: Hi On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote: On 06/28/2013 02:33 PM, Michael Trimarchi wrote: Hi Roger On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote: On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi mich...@amarulasolutions.com wrote: Do you have locks around this software workaround? The patch I did against 3.4 linux kernel may be helpful for you in such case: http://review.omapzoom.org/28515 Another patch extends this WA for all OMAP4 SoCs: http://review.omapzoom.org/31108 I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so the problem could be: 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion could be it a problem? If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the issue if OFF mode is disabled? If yes then it probably is not related to SAR. 2) idle status of ulpis pins? Yes this can be possible. When you said earlier that the problem doesn't happen when one of the ULPIs is used did you try both of them individually. e.g. case 1: port 1 only enabled, case 2: port 2 only enabled. Did it work in both the cases? Yes, so I don't think could be a problem of ulpi pins and why this happen on both at the same time? Seems more connected to somenthing else. Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? 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: omap4 ehci sporadic resume issue
Hi Roger On 07/02/2013 04:42 PM, Roger Quadros wrote: On 06/28/2013 07:47 PM, Michael Trimarchi wrote: Hi On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote: On 06/28/2013 02:33 PM, Michael Trimarchi wrote: Hi Roger On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote: On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi mich...@amarulasolutions.com wrote: Do you have locks around this software workaround? The patch I did against 3.4 linux kernel may be helpful for you in such case: http://review.omapzoom.org/28515 Another patch extends this WA for all OMAP4 SoCs: http://review.omapzoom.org/31108 I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so the problem could be: 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion could be it a problem? If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the issue if OFF mode is disabled? If yes then it probably is not related to SAR. 2) idle status of ulpis pins? Yes this can be possible. When you said earlier that the problem doesn't happen when one of the ULPIs is used did you try both of them individually. e.g. case 1: port 1 only enabled, case 2: port 2 only enabled. Did it work in both the cases? Yes, so I don't think could be a problem of ulpi pins and why this happen on both at the same time? Seems more connected to somenthing else. Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline. Last question: If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode? Michael 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
[PATCH v2 7/9] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho coe...@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 v2 9/9] wlcore/wl12xx: check if we got correct clock data from DT
The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values. WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error. WiLink7 needs both clocks, if either is not available we
return with an error.
Signed-off-by: Luciano Coelho 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 903dcb3..72d13e4 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int
*selected_clock)
u16 sys_clk_cfg;
int ret;
+ if ((priv-ref_clock 0) || (priv-tcxo_clock 0)) {
+ wl1271_error(Missing fref and/or tcxo clock settings\n);
+ return -EINVAL;
+ }
+
/* For XTAL-only modes, FREF will be used after switching from TCXO */
if (priv-ref_clock == WL12XX_REFCLOCK_26_XTAL ||
priv-ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
u32 clk;
int ret;
+ if (priv-ref_clock 0) {
+ wl1271_error(Missing fref clock settings\n);
+ return -EINVAL;
+ }
+
if (WL127X_PG_GET_MAJOR(wl-hw_pg_ver) 3)
wl-quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
@@ -1757,7 +1767,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, wl12xx_ht_cap);
wl12xx_conf_init(wl);
- if (!fref_param) {
+ if (!fref_param (pdata-ref_clock_freq 0)) {
priv-ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
pdata-ref_clock_freq,
pdata-ref_clock_xtal);
@@ -1768,6 +1778,8 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv-ref_clock;
}
+ } else if (!fref_param) {
+ priv-ref_clock = -EINVAL;
} else {
if (!strcmp(fref_param, 19.2))
priv-ref_clock = WL12XX_REFCLOCK_19;
@@ -1785,7 +1797,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wl1271_error(Invalid fref parameter %s, fref_param);
}
- if (!tcxo_param) {
+ if (!fref_param (pdata-tcxo_clock_freq 0)) {
priv-tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
pdata-tcxo_clock_freq,
pdata-tcxo_clock_xtal);
@@ -1796,7 +1808,9 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv-tcxo_clock;
}
- } else {
+ } else if (!fref_param) {
+ priv-tcxo_clock = -EINVAL;
+ }else {
if (!strcmp(tcxo_param, 19.2))
priv-tcxo_clock = WL12XX_TCXOCLOCK_19_2;
else if (!strcmp(tcxo_param, 26))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
- /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
glue-refclock = of_clk_get_by_name(np, refclock);
if (IS_ERR(glue-refclock)) {
- dev_err(dev, couldn't find refclock on the device tree\n);
glue-refclock = NULL;
} else {
clk_prepare_enable(glue-refclock);
pdata-ref_clock_freq = clk_get_rate(glue-refclock);
}
- /* TODO: make sure we have this when needed (ie. for WL7) */
glue-tcxoclock = of_clk_get_by_name(np, tcxoclock);
if (IS_ERR(glue-tcxoclock)) {
- dev_err(dev, couldn't find tcxoclock on the device tree\n);
glue-tcxoclock = NULL;
} else {
clk_prepare_enable(glue-tcxoclock);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/9] wlcore: sdio: get clocks from device tree
Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.
Signed-off-by: Luciano Coelho coe...@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 v2 5/9] wlcore: always use one-shot IRQ
Since we are now using threaded IRQs without the primary handler, we need to set IRQF_ONESHOT, otherwise our request will fail. Signed-off-by: Luciano Coelho coe...@ti.com --- drivers/net/wireless/ti/wlcore/main.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c index d306cd5..bc1cff3 100644 --- a/drivers/net/wireless/ti/wlcore/main.c +++ b/drivers/net/wireless/ti/wlcore/main.c @@ -5927,7 +5927,8 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context) wl-irq = platform_get_irq(pdev, 0); wl-if_ops = pdev_data-if_ops; - wl-irq_flags = pdata-irq_flags; + /* Since we don't use the primary handler, we must set ONESHOT */ + wl-irq_flags = pdata-irq_flags | IRQF_ONESHOT; ret = request_threaded_irq(wl-irq, NULL, wlcore_irq, wl-irq_flags, pdev-name, wl); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
On 16:49-20130702, Michael Trimarchi wrote: Last question: If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode? Without going to the depth of what TRM says already: SAR comes into play only if device-off sequence was triggered. Depending on which domain and what level of retention state was programmed, device-off sequence may not even start. Note: Generically speaking, not achieving device OFF may not mean other powerdomains cannot achieve OFF and loose context. Specific example of USB tied on core domain, the behavior could be different. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/9] wlcore: add initial device tree support to the sdio module
If platform data is not available, try to get the required information
from the device tree. Register an OF match table and parse the
appropriate device tree nodes.
Parse interrupt property only, for now.
Signed-off-by: Luciano Coelho 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 v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Change all board files to reflect this.
Cc: Tony Lindgren 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| 58 +-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +
include/linux/wl12xx.h | 28 ++---
8 files changed, 99 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d2a2a98..202f3d0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.irq_flags = IRQF_TRIGGER_RISING,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c2334aa..da2b892 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -694,8 +694,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_26,
- .board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
+ .tcxo_clock_freq = 2600,
};
static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a0c0adf..d24435c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -459,7 +459,8 @@ static struct platform_device omap3evm_wlan_regulator = {
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index ba00862..ac6413c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -231,7 +231,8 @@ static struct platform_device omap_vwlan_device = {
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index ced012c..f4f4fe7 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -245,7 +245,8 @@ static struct platform_device *zoom_devices[] __initdata = {
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..903dcb3 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static struct wl12xx_clock wl12xx_refclock_table[] = {
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+ { 16368000, false, WL12XX_TCXOCLOCK_16_368 },
+ { 1680, false, WL12XX_TCXOCLOCK_16_8 },
+ { 1920, false, WL12XX_TCXOCLOCK_19_2 },
+ {
[PATCH v2 1/9] wl1251: split wl251 platform data to a separate structure
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Cc: Tony Lindgren 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 v2 0/9] wilink: add device tree support
Hi, This is a follow-up on a previous patch set that had a smaller audience. This time, I added the lists and people who were involved in the review of the bindings documentation, since most of my changes in v2 are coming from discussions there. This patch series adds device tree support to the wlcore_sdio driver, which is used by WiLink6, WiLink7 and WiLink8. The first patches do some clean-up to make the data needed in the wilink device tree node smaller. The remaining patches implement the actual device tree node parsing in wlcore_sdio. I still need to figure out how to add the information about whether the clocks are XTAL or not. I'll send it in a separate patche set. The DTS file changes will be sent separately, since they need to go via different trees. The bindings documentation patch will also be updated and sent separately, once the XTAL issue is solved. Tony has acked some of the patches that touch OMAP areas. I still need one more ack to a new patch I added (wl12xx: use frequency instead of enumerations for pdata clocks). Sekhar, can you please check the patches that touch the davinci board file and ack them? Changes in v2: * New clean-up patch (4/9); * Patch 6/9 (previously patch 5/5) now doesn't add the clock parsing, since it became more complicated and I added separate patches for that; * 3 new patches (from 7/9 till 9/9) to handle the clock reading in the device tree; Please review. -- Cheers, Luca. Luciano Coelho (9): wl1251: split wl251 platform data to a separate structure wlcore: use irq_flags in pdata instead of hiding it behind a quirk wlcore: remove pwr_in_suspend from platform data wl12xx: use frequency instead of enumerations for pdata clocks wlcore: always use one-shot IRQ wlcore: add initial device tree support to the sdio module wlcore: sdio: add wilink clock providers wlcore: sdio: get clocks from device tree wlcore/wl12xx: check if we got correct clock data from DT arch/arm/mach-davinci/board-da850-evm.c|5 +- arch/arm/mach-omap2/board-4430sdp.c|6 +- arch/arm/mach-omap2/board-omap3evm.c |4 +- arch/arm/mach-omap2/board-omap3pandora.c |4 +- arch/arm/mach-omap2/board-omap4panda.c |4 +- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |4 +- drivers/net/wireless/ti/wilink_platform_data.c | 37 ++-- drivers/net/wireless/ti/wl1251/sdio.c | 12 +-- drivers/net/wireless/ti/wl1251/spi.c |2 +- drivers/net/wireless/ti/wl12xx/main.c | 78 +++-- drivers/net/wireless/ti/wl12xx/wl12xx.h| 28 ++ drivers/net/wireless/ti/wlcore/debugfs.c |2 +- drivers/net/wireless/ti/wlcore/main.c | 16 ++-- drivers/net/wireless/ti/wlcore/sdio.c | 112 ++-- drivers/net/wireless/ti/wlcore/wlcore.h|5 +- drivers/net/wireless/ti/wlcore/wlcore_i.h |1 + include/linux/wl12xx.h | 54 ++-- 18 files changed, 295 insertions(+), 81 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding it behind a quirk
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, export the
whole irq_flags element and let the board file define what to use.
This will be more meaningful than driver-specific quirks when we
switch to DT.
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-davinci/board-da850-evm.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap4panda.c |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
drivers/net/wireless/ti/wlcore/main.c| 13 +++--
drivers/net/wireless/ti/wlcore/wlcore.h |5 ++---
include/linux/wl12xx.h |5 +
9 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..d2a2a98 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
+ .irq_flags = IRQF_TRIGGER_RISING,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..c2334aa 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_26,
.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
};
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..a0c0adf 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -458,6 +458,7 @@ static struct platform_device omap3evm_wlan_regulator = {
};
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1e2c75e..ba00862 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,6 +230,7 @@ static struct platform_device omap_vwlan_device = {
};
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..ced012c 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,6 +244,7 @@ static struct platform_device *zoom_devices[] __initdata = {
};
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
};
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c
b/drivers/net/wireless/ti/wlcore/debugfs.c
index c3e1f79..5eff663 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -486,7 +486,7 @@ static ssize_t driver_state_read(struct file *file, char
__user *user_buf,
DRIVER_STATE_PRINT_HEX(irq);
/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
DRIVER_STATE_PRINT_HEX(hw_pg_ver);
- DRIVER_STATE_PRINT_HEX(platform_quirks);
+ DRIVER_STATE_PRINT_HEX(irq_flags);
DRIVER_STATE_PRINT_HEX(chip.id);
DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index b8db55c..e7294b8 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -516,7 +516,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
* In case edge triggered interrupt must be used, we cannot iterate
* more than once without introducing race conditions with the hardirq.
*/
- if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
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.
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-
drivers/net/wireless/ti/wl12xx/main.c| 58
+-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +
include/linux/wl12xx.h | 28 ++---
8 files changed, 99 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d2a2a98..202f3d0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.irq_flags = IRQF_TRIGGER_RISING,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c2334aa..da2b892 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -694,8 +694,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_26,
- .board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
+ .tcxo_clock_freq = 2600,
};
static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a0c0adf..d24435c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -459,7 +459,8 @@ static struct platform_device omap3evm_wlan_regulator = {
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index ba00862..ac6413c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -231,7 +231,8 @@ static struct platform_device omap_vwlan_device = {
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index ced012c..f4f4fe7 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -245,7 +245,8 @@ static struct platform_device *zoom_devices[] __initdata
= {
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
.irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
- .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..903dcb3 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static struct wl12xx_clock wl12xx_refclock_table[] = {
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static struct wl12xx_clock wl12xx_tcxoclock_table
Re: omap4 ehci sporadic resume issue
On 07/02/2013 05:49 PM, Michael Trimarchi wrote: Hi Roger On 07/02/2013 04:42 PM, Roger Quadros wrote: On 06/28/2013 07:47 PM, Michael Trimarchi wrote: Hi When you said earlier that the problem doesn't happen when one of the ULPIs is used did you try both of them individually. e.g. case 1: port 1 only enabled, case 2: port 2 only enabled. Did it work in both the cases? Yes, so I don't think could be a problem of ulpi pins and why this happen on both at the same time? Seems more connected to somenthing else. Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline. Yes, our aim is to get it working with mainline as well. Last question: If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode? SAR restore will only happen when the Device enters OFF mode. Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter 3.9.3 Device OFF State Management in the TRM. 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
[PATCH v2 3/9] wlcore: remove pwr_in_suspend from platform data
The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure. Move it to the platform device data that
is passed from SDIO to wlcore.
Signed-off-by: Luciano Coelho 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 e7294b8..d306cd5 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5941,7 +5941,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
if (!ret) {
wl-irq_wake_enabled = true;
device_init_wakeup(wl-dev, 1);
- if (pdata-pwr_in_suspend)
+ if (pdev_data-pwr_in_suspend)
wl-hw-wiphy-wowlan = wlcore_wowlan_support;
}
#endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
dev_dbg(glue-dev, sdio PM caps = 0x%x\n, mmcflags);
if (mmcflags MMC_PM_KEEP_POWER)
- pdev_data-pdata-pwr_in_suspend = true;
+ pdev_data-pwr_in_suspend = true;
sdio_set_drvdata(func, glue);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
struct wlcore_platdev_data {
struct wl12xx_platform_data *pdata;
struct wl1271_if_operations *if_ops;
+ bool pwr_in_suspend;
};
#define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 04e3096..1e4ed6e 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -60,7 +60,6 @@ struct wl12xx_platform_data {
unsigned long irq_flags;
int board_ref_clock;
int board_tcxo_clock;
- bool pwr_in_suspend;
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tue, Jul 02, 2013 at 12:04:32PM +0100, Mark Brown wrote: On Tue, Jul 02, 2013 at 01:43:38PM +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 11:17:18AM +0100, Mark Brown wrote: + /* setup command reg */ + qspi-cmd = 0; + qspi-cmd |= QSPI_WLEN(8); Sourav hardcodes wordlenght to 8-bits, and yet he enables 8, 16 and 32-bits per word. Yeah, that's what I noticed (well first off I noticed that there were no constraints on bits per word at all). + qspi-cmd |= QSPI_EN_CS(0); he's also hardcoding the chipselect line which should be take from m-spi-chip_select This one *can* be OK if the driver only accepts one chip select (though obviously supporting more is better). I'd really only done a fairly this controller has 6 chip selects IIRC high level review for framework stuff so hadn't got that far yet. One thing I really want to get round to doing with the SPI core is providing an easy to pick up GPIO chip select as standard that should be fairly simple I guess. Just lack of time, I'm assuming ? Complex will be to support up to 128-bits per word as this particular controller supports. In fact, this controller is, IMO, overly flexible. You can do 1, 2, 3, 4, 5, 6, ... , 128 bits per word. The only problem is that the DATA registers which give you access to the shift register, aren't mapped to consecutive offsets, but that should still be ok since we will, anyway, be using readl/writel for each register. Still, for platforms which can provide writeq/readq (not sure if that's already supported on ARM) we could save a few cycles, no ? anyway... it is what it is. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding it behind a quirk
Hi,
On Tue, Jul 02, 2013 at 05:55:41PM +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, export the
whole irq_flags element and let the board file define what to use.
This will be more meaningful than driver-specific quirks when we
switch to DT.
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-davinci/board-da850-evm.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap4panda.c |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
drivers/net/wireless/ti/wlcore/main.c| 13 +++--
drivers/net/wireless/ti/wlcore/wlcore.h |5 ++---
include/linux/wl12xx.h |5 +
9 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..d2a2a98 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
+ .irq_flags = IRQF_TRIGGER_RISING,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..c2334aa 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
couldn't you just call irq_set_irq_type() from the board-file itself ?
Then on your driver you can just pass IRQF_ONESHOT (to make sure heh) to
your request_threaded_irq_handler()
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
Hi,
On Tue, Jul 02, 2013 at 05:55:43PM +0300, Luciano Coelho wrote:
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..903dcb3 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static struct wl12xx_clock wl12xx_refclock_table[] = {
const
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
const
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 5/9] wlcore: always use one-shot IRQ
On Tue, Jul 02, 2013 at 05:55:44PM +0300, Luciano Coelho wrote: Since we are now using threaded IRQs without the primary handler, we need to set IRQF_ONESHOT, otherwise our request will fail. Signed-off-by: Luciano Coelho coe...@ti.com good to see this happening, I remember we talked about this a while back :-) Acked-by: Felipe Balbi ba...@ti.com Still, if you call irq_set_irq_type() on board-file (since DT will do something similar for you anyway) then you can completely drop irq_flags. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 7/9] wlcore: sdio: add wilink clock providers
On Tue, Jul 02, 2013 at 05:55:46PM +0300, Luciano Coelho wrote: 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 Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
Hi, On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote: @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func, /* Use block mode for transferring over one block size of data */ func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE; + sdio_set_drvdata(func, glue); is this move really necessary ? -- balbi signature.asc Description: Digital signature
Re: [PATCHv2] drivers: spi: Add qspi flash controller
On Tue, Jul 02, 2013 at 06:19:47PM +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 12:04:32PM +0100, Mark Brown wrote: One thing I really want to get round to doing with the SPI core is providing an easy to pick up GPIO chip select as standard that should be fairly simple I guess. Just lack of time, I'm assuming ? That and all the refactoring of drivers required to adopt it. signature.asc Description: Digital signature
Re: RT and omap-gpio irqchip with DeviceTree
On Tue, Jul 2, 2013 at 4:31 PM, Torben Hohn torb...@linutronix.de wrote: On Tue, Jul 02, 2013 at 02:15:46PM +0200, Javier Martinez Canillas wrote: + Grant, Linus W and Jean-Christophe. On Tue, Jul 2, 2013 at 1:44 PM, Torben Hohn torb...@linutronix.de wrote: Hi.. I am running into Problems with a network adapter IRQ connected to an omap-gpio pin. omap-gpio expects gpio-request() to be called before i can use the pin. But this is abstracted via the DeviceTree bindings. I see 8d4c277e185c31359cf70573d8b0351fb7dd0dfe in mainline. This one just puts a warning into the exact place, i am dealing with. But i need to make this work, instead of bailing out. This has been discussed extensively on the linux-omap mailing list and the agreement is that it has to be handled by the IRQ core. So when a GPIO line is mapped in the IRQ domain with irq_create_of_mapping(), the core has to take care to request the GPIO and configure it as input. Can you give me a pointer to this discussion please ? Because i fail to understand why you just dont save the irq_type in some private data structure, and then use chip-irq_enable() or something. Yes, it starts here [1] but it the thread is 90+ mails long. But until we have this general solution we have to do it on a per irq chip driver basis and the less hack-ish solution is to have a custom .map function handler that request the GPIO used as IRQ. There is already a patch [1] queued in Linus Walleij linux-gpio tree [2] for-next branch that implements this for OMAP GPIO. It would be great if you can test it and give feedback. Thanks for the pointer. The kernel i am working on is based on 3.8.x (this is before the irq_domain change to linear) First i only backported: [1] and [2] With these i see big streams like these: [1.554809] omap_gpio gpio.9: Could not request GPIO-256 [1.560394] omap_gpio gpio.9: Could not request GPIO-255 [1.566009] omap_gpio gpio.9: Could not request GPIO-254 [1.571594] omap_gpio gpio.9: Could not request GPIO-253 [1.577178] omap_gpio gpio.9: Could not request GPIO-252 [1.582794] omap_gpio gpio.9: Could not request GPIO-251 This is basically coming from irq_domain_add_legacy() which calls ops-map(domain, irq, hwirq) before the gpio chip is actually added. I fixed it by also taking [3]. Yes, sorry for not mentioning that it has as a dependency the legacy to linear domain mapping change. I didn't mentioned since I thought that you were basing your work on mainline. However, OMAP1 is still calling irq_domain_add_legacy(). This would probably break with DeviceTree. Indeed, OMAP1 doesn't support DT. In fact if you are interested in OMAP1, then you need to cherry-pick another patch from mainline since linear domain mapping does not work with OMAP1 because OMAP1 does not support SPARSE_IRQ. That's why the change from legacy to linear domain mapping was partially reverted for OMAP1 in mainline commit 397eada9 (gpio/omap: don't use linear domain mapping for OMAP1) But since omap1 doesnt use DeviceTree, this is probably a non-issue. Yes, the GPIO is only requested on the .map function handler if bank-chip.of_node is not NULL so it doesn't have a side effect on platforms that don't support DT. After all, this issue has only been detected once we migrated to DT since for legacy booting is the platform code the responsible to do this setup (e.g: configuring the OMAP pin mux, request the GPIO, configure it as input, etc). [1] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=570c4bb53366157fa076922d0fc7e7adfd81cf42 [2] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=50fc1d067d9f4b6c99717b91c1618075f859 [3] https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/commit/?h=for-nextid=ede4d7a5b9835510fd1f724367f68d2fa4128453 -- Mit freundlichen Grüßen Torben Hohn Linutronix GmbH Standort: Bremen Phone: +49 421 5650 2310 ; Fax.: +49 7556 919 886 mailto: torb...@linutronix.de Firmensitz / Registered Office: D-88690 Uhldingen, Auf dem Berg 3 Registergericht / Local District Court: Freiburg i. Br., HRB Nr. / Trade register no.: 700 806; Geschäftsführer / Managing Directors: Heinz Egger, Thomas Gleixner Best regards, Javier [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85544.html -- 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: spi: Add qspi flash controller
Hi,
Alright, so I spent some time looking at the SPI framework and :
On Tue, Jul 02, 2013 at 02:26:39PM +0530, Sourav Poddar wrote:
+static int dra7xxx_qspi_start_transfer_one(struct spi_master *master,
+ struct spi_message *m)
+{
+ struct dra7xxx_qspi *qspi = spi_master_get_devdata(master);
+ struct spi_device *spi = m-spi;
+ struct spi_transfer *t;
+ int status = 0;
+ int flags = 0;
+
+ /* setup command reg */
+ qspi-cmd = 0;
+ qspi-cmd |= QSPI_WLEN(8);
this m-spi-bits_per_word;
+ qspi-cmd |= QSPI_EN_CS(0);
this should be m-spi-chip_select;
+ qspi-cmd |= 0xfff;
this will be a little tricky to count... because, I believe it should be
something like:
int count = 0;
list_for_each_entry(t, m-transfers, transfer_list)
count += t-len;
frame_length = DIV_ROUND_UP(count, m-spi-bits_per_word);
/* up to 4096 words */
frame_length = clamp(frame_length, 4096);
qspi-cmd |= QSPI_FRAME_LENGTH(DIV_ROUND_UP(count,
frame_length));
Now, it would've been better if SPI framework would already give us
some sort of total_length field in struct spi_message which would be the
sum of all spi_transfers.
+ /* setup device control reg */
+ qspi-dc = 0;
+
+ if (spi-mode SPI_CPHA)
+ qspi-dc |= QSPI_CKPHA(0);
+ if (spi-mode SPI_CPOL)
+ qspi-dc |= QSPI_CKPOL(0);
+ if (spi-mode SPI_CS_HIGH)
+ qspi-dc |= QSPI_CSPOL(0);
all of these zeroes being passed to these macros should be
m-spi-chip_select
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 0/2]: auto request GPIO as input if used as IRQ via DT
On Wed, Jun 26, 2013 at 12:50 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: [...] Aaro, could you please test if these changes break any of your OMAP1 boards? Although it shouldn't do it as far as I can tell. This doesn't build for omap1_defconfig (at least in next-20130702): /work/kernel/next/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init': /work/kernel/next/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has no member named 'of_node' /work/kernel/next/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map': /work/kernel/next/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has no member named 'of_node' Probably because OMAP1 is non-DT? Kevin -- 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 0/2]: auto request GPIO as input if used as IRQ via DT
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
On 07/02/2013 01:23 AM, Kevin Hilman wrote:
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drivers should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just request the IRQ and this has to
be handled by the irq_chip driver.
With the current OMAP GPIO DT binding, if we define:
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
reg = 0x49058000 0x200;
interrupts = 34;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
};
interrupt-parent = gpio6;
interrupts = 16 8;
The GPIO is correctly mapped as an IRQ but a call to gpio_request()
is never made. Ideally this has to be handled by the IRQ core and
there are some work-in-progress to add this logic to the core but
until this general solution gets into mainline we need to solve this
on a per irq_chip driver basis.
Some drivers solve this by calling gpio_request() using a custom
.xlate function handler. But .xlate could get called many times
while the irq domain .map function handler is called just once
when a IRQ mapping is created with a call to irq_create_mapping().
This patch-set adds a custom .map function handler for the gpio-omap
irq_chip driver that automatically call gpio_request() when a IRQ
mapping is created for the GPIO line used as interrupt when using DT.
This is just a temporary solution (a.k.a a hack) until a kernel wide
approach is implemented and added to mainline.
This is a third version of a patch-set that addresses some issues pointed
out by Grant Like, it is composed of the following patches:
[PATCH v3 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT
[PATCH v3 2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT
This was tested on an OMAP3 DM3735 board (IGEPv2) and all the supported
peripherals are working correctly with both legacy and DT booting. Further
testing will be highly appreciated.
Was there any testing done to hit low-power modes? suspend/resume?
CPUidle enabled? etc. It is especially instructive to enable off
mode[1] on OMAP3 platforms and see if things still work as expected.
Kevin
[1] echo 1 /sys/kerel/debug/pm_debug/enable_off_mode
Hi Kevin,
Thanks a lot for your feedback.
I tested enabling power domain transitions to off mode [1] and suspending to
RAM
[2] with both DT and legacy boot. With legacy booting everything works as
expected.
Excellent, thanks.
In the DT case suspending/resume (without enabling off mode) doesn't affect
system operation. For example the Ethernet chip that uses a GPIO IRQ still is
able to transmit frames after suspending to RAM and waking up the board
hitting
Ctrl+C in the serial console.
Now, enabling off mode [2] with DT makes the board to never go out from
suspend:
root@igep00x0:~# echo 1 /sys/kernel/debug/pm_debug/enable_off_mode
root@igep00x0:~# echo mem /sys/power/state
[ 129.833343] PM: Syncing filesystems ... done.
[ 129.879211] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 129.905487] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
done.
[ 129.935363] Suspending console(s) (use no_console_suspend to debug)
The board just hangs/sleeps and I don't have a way to take it from suspend.
I don't know if there something missing on my board DT file but I think this
is
orthogonal with these patches since since I got the same behavior without
them.
Yes, you're right. I forgot we don't have full wakeup capabilities from
low-power states yet (IO pad wakeups) with DT boots. We have that
mostly working now, but not ready for v3.10.
Thanks for testing,
Once the OMAP1 build failure is fixed (omap1_defconfig build fails
because of this series), feel free to add
Tested-by: Kevin Hilman khil...@linaro.org # OMAP3530: Beagle, Overo
Reviewed-by: Kevin Hilman khil...@linaro.org
Kevin
--
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 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. 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. 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? 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 0/2]: auto request GPIO as input if used as IRQ via DT
On Tue, Jul 2, 2013 at 6:10 PM, Kevin Hilman khil...@linaro.org wrote:
On Wed, Jun 26, 2013 at 12:50 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
[...]
Aaro, could you please test if these changes break any of your OMAP1 boards?
Although it shouldn't do it as far as I can tell.
This doesn't build for omap1_defconfig (at least in next-20130702):
/work/kernel/next/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init':
/work/kernel/next/drivers/gpio/gpio-omap.c:1080:17: error: 'struct
gpio_chip' has no member named 'of_node'
/work/kernel/next/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map':
/work/kernel/next/drivers/gpio/gpio-omap.c:1116:16: error: 'struct
gpio_chip' has no member named 'of_node'
Probably because OMAP1 is non-DT?
Kevin
--
Hi Kevin,
Yes, sorry about that. In the a previous version of the patch-set
of_have_populated_dt() was used instead of chip.of_node and it built
correctly with OMAP1 since it just default to return false.
Then I was told to check if the struct gpio_chip has an associated
device node instead and forget to build test for OMAP1 :-(
Could you please tell me if the following patch looks like a good fix
to you so I can do a proper post?
From 2d14bcc7c300a9451d7d8a37eeff4e0285c977a0 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Tue, 2 Jul 2013 19:04:14 +0200
Subject: [PATCH 1/1] gpio/omap: fix build error when CONFIG_OF_GPIO is not
defined.
The OMAP GPIO driver check if the chip has an associated
DT device node using the struct gpio_chip of_node member.
But this is only built if CONFIG_OF_GPIO is defined which
leads to the following error when using omap1_defconfig:
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init':
linux/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has
no member named 'of_node'
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map':
linux/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has
no member named 'of_node'
Reported-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4f0aa2..bd536f1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1037,6 +1037,18 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank,
unsigned int irq_start,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
+#if defined(CONFIG_OF_GPIO)
+static inline bool omap_gpio_chip_dt_boot(struct gpio_chip *chip)
+{
+ return chip-of_node != NULL;
+}
+#else
+static inline bool omap_gpio_chip_dt_boot(struct gpio_chip *chip)
+{
+ return false;
+}
+#endif
+
static void omap_gpio_chip_init(struct gpio_bank *bank)
{
int j;
@@ -1077,7 +1089,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
* irq_create_of_mapping() only for the GPIO lines that
* are used as interrupts.
*/
- if (!bank-chip.of_node)
+ if (!omap_gpio_chip_dt_boot(bank-chip))
for (j = 0; j bank-width; j++)
irq_create_mapping(bank-domain, j);
irq_set_chained_handler(bank-irq, gpio_irq_handler);
@@ -1113,7 +1125,7 @@ static int omap_gpio_irq_map(struct irq_domain
*d, unsigned int virq,
* but until then this has to be done on a per driver
* basis. Remove this once this is managed by the core.
*/
- if (bank-chip.of_node) {
+ if (omap_gpio_chip_dt_boot(bank-chip)) {
gpio = irq_to_gpio(bank, hwirq);
ret = gpio_request_one(gpio, GPIOF_IN, NULL);
if (ret) {
--
1.7.7.6
--
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-rc7
Hi, On Mon, Jul 01, 2013 at 11:42:36PM +0300, Felipe Balbi wrote: On Mon, Jul 01, 2013 at 07:48:50PM +, Paul Walmsley wrote: Boot to userspace: FAIL ( 2/12): 37xxevm, am335xbonelt quoting part of [1] | U-Boot# tftp 0x8200 am335x-boneblack.dtb | link up on port 0, speed 100, full duplex | Using cpsw device | TFTP from server 192.168.57.1; our IP address is 192.168.57.138 | Filename 'am335x-boneblack.dtb'. Where are you taking am335x-boneblack.dtb from ? It's not in mainline v3.10-rc7 kernel: $ ls arch/arm/boot/dts/am33*.dts arch/arm/boot/dts/am335x-bone.dts arch/arm/boot/dts/am335x-evm.dts arch/arm/boot/dts/am335x-evmsk.dts $ git grep -e boneblack arch/arm/ $ echo $ 1 $ git show commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d Author: Linus Torvalds torva...@linux-foundation.org Date: Sat Jun 22 09:47:31 2013 -1000 Linux 3.10-rc7 diff --git a/Makefile b/Makefile index c6863b5..0142c93 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 3 PATCHLEVEL = 10 SUBLEVEL = 0 -EXTRAVERSION = -rc6 +EXTRAVERSION = -rc7 NAME = Unicycling Gorilla # *DOCUMENTATION* [1] http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/am335xbonelt/am335x-bone/am335xbonelt_log.txt just a gentle ping here, wondering if you still have some garbage DTBs left in your tree. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/5] usb: common: introduce of_usb_get_maximum_speed()
Hi,
On Tue, Jul 02, 2013 at 06:04:45PM +, Paul Zimmerman wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Tuesday, July 02, 2013 2:31 AM
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
new file mode 100644
index 000..477d5bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -0,0 +1,24 @@
+Generic USB Properties
+
+Optional properties:
+ - maximum-speed: tells USB controllers we want to work up to a certain
+ speed. Valid arguments are super-speed, high-speed,
+ full-speed and low-speed. In case this isn't passed
+ via DT, USB controllers should default to their maximum
+ HW capability.
+ - dr_mode: tells Dual-Role USB controllers that we want to work on a
+ particular mode. Valid arguments are host,
+ peripheral and otg. In case this attribute isn't
+ passed via DT, USB DRD controllers should default to
+ OTG.
+
+This is an attribute to a USB controller such as:
+
+dwc3@4a03 {
+ compatible = synopsys,dwc3;
Hi Felipe,
Just a small nit. Weren't you going to change this property to
snps,dwc3 to match the existing Synopsys DT naming convention
in the kernel? Or has the horse already left the gate on that?
I think we can still change, but we need to keep compatibility for the
old one in the driver :-)
Here's a patch for that:
commit 90dc4b82df9d0b4d049d03d1be225b9c7456522b
Author: Felipe Balbi ba...@ti.com
Date: Tue Jul 2 21:20:24 2013 +0300
usb: dwc3: core: switch to snps,dwc3
all other drivers using Synopsys IPs with DT
have a compatible of snps,$driver, in order
to add consistency, we are switching over to
snps,dwc3 but keeping synopsys,dwc3 in the core
driver to maintain backwards compatibility.
New DTS bindings should NOT use synopsys,dwc3.
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..3a64e20 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -3,7 +3,7 @@ synopsys DWC3 CORE
DWC3- USB3 CONTROLLER
Required properties:
- - compatible: must be synopsys,dwc3
+ - compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
- usb-phy : array of phandle for the PHY device
@@ -14,7 +14,7 @@ Optional properties:
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
- compatible = synopsys,dwc3;
+ compatible = snps,dwc3;
reg = 0x4a03 0xcfff;
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 635cae2..2462708 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,7 +641,7 @@
utmi-mode = 2;
ranges;
dwc3@4a03 {
- compatible = synopsys,dwc3;
+ compatible = snps,dwc3;
reg = 0x4a03 0x1000;
interrupts = 0 92 4;
usb-phy = usb2_phy, usb3_phy;
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c86ae12..a4dab1c 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -755,6 +755,9 @@ static const struct dev_pm_ops dwc3_dev_pm_ops = {
#ifdef CONFIG_OF
static const struct of_device_id of_dwc3_match[] = {
{
+ .compatible = snps,dwc3
+ },
+ {
.compatible = synopsys,dwc3
},
{ },
--
balbi
signature.asc
Description: Digital signature
[PATCH 1/1] gpio/omap: fix build error when OF_GPIO is not defined.
The OMAP GPIO driver check if the chip has an associated
Device Tree node using the struct gpio_chip of_node member.
But this is only build if CONFIG_OF_GPIO is defined which
leads to the following error when using omap1_defconfig:
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init':
linux/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has no member
named 'of_node'
linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map':
linux/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has no member
named 'of_node'
Reported-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hi Linus,
Sorry for not spoting this issue before. In a previous version of the patch-set:
[PATCH v3 0/2]: auto request GPIO as input if used as IRQ via DT
of_have_populated_dt() was used instead of struct gpio_chip of_node member to
check wether legacy or DT boot was used. I did a build test on every OMAP
platform
but later I was asked to use .of_node instead of_have_populated_dt() and forget
to do a built test for OMAP1.
I hope this patch can go as a fix for the v3.11-rc cycle.
Thanks a lot and best regards,
Javier
drivers/gpio/gpio-omap.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c4f0aa2..00c6f77 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1037,6 +1037,18 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int
irq_start,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
+#if defined(CONFIG_OF_GPIO)
+static inline bool omap_gpio_chip_boot_dt(struct gpio_chip *chip)
+{
+ return chip-of_node != NULL;
+}
+#else
+static inline bool omap_gpio_chip_boot_dt(struct gpio_chip *chip)
+{
+ return false;
+}
+#endif
+
static void omap_gpio_chip_init(struct gpio_bank *bank)
{
int j;
@@ -1077,7 +1089,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
* irq_create_of_mapping() only for the GPIO lines that
* are used as interrupts.
*/
- if (!bank-chip.of_node)
+ if (!omap_gpio_chip_boot_dt(bank-chip))
for (j = 0; j bank-width; j++)
irq_create_mapping(bank-domain, j);
irq_set_chained_handler(bank-irq, gpio_irq_handler);
@@ -1113,7 +1125,7 @@ static int omap_gpio_irq_map(struct irq_domain *d,
unsigned int virq,
* but until then this has to be done on a per driver
* basis. Remove this once this is managed by the core.
*/
- if (bank-chip.of_node) {
+ if (omap_gpio_chip_boot_dt(bank-chip)) {
gpio = irq_to_gpio(bank, hwirq);
ret = gpio_request_one(gpio, GPIOF_IN, NULL);
if (ret) {
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/9] wlcore: use irq_flags in pdata instead of hiding it behind a quirk
On Tue, 2013-07-02 at 18:26 +0300, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 05:55:41PM +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, export the
whole irq_flags element and let the board file define what to use.
This will be more meaningful than driver-specific quirks when we
switch to DT.
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-davinci/board-da850-evm.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap4panda.c |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
drivers/net/wireless/ti/wlcore/main.c| 13 +++--
drivers/net/wireless/ti/wlcore/wlcore.h |5 ++---
include/linux/wl12xx.h |5 +
9 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..d2a2a98 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,8 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
+ .irq_flags = IRQF_TRIGGER_RISING,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..c2334aa 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,6 +693,7 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
+ .irq_flags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
couldn't you just call irq_set_irq_type() from the board-file itself ?
Then on your driver you can just pass IRQF_ONESHOT (to make sure heh) to
your request_threaded_irq_handler()
Good point. This is an oldish patch from the time I still thought I'd
have to pass the flags in the device tree. It turned out that I don't
need it anymore, so this can be totally removed from pdata and be set by
the board file itself.
As you saw in a later patch, I do make sure the driver sets
IRQF_ONESHOT. ;)
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
On Tue, 2013-07-02 at 18:31 +0300, Felipe Balbi wrote:
Hi,
On Tue, Jul 02, 2013 at 05:55:43PM +0300, Luciano Coelho wrote:
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..903dcb3 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static struct wl12xx_clock wl12xx_refclock_table[] = {
const
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static struct wl12xx_clock wl12xx_tcxoclock_table[] = {
const
Duh! Thanks for noticing it.
--
Luca.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] gpio/omap: fix build error when OF_GPIO is not defined.
On Tue, Jul 2, 2013 at 9:46 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The OMAP GPIO driver check if the chip has an associated Device Tree node using the struct gpio_chip of_node member. But this is only build if CONFIG_OF_GPIO is defined which leads to the following error when using omap1_defconfig: linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init': linux/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has no member named 'of_node' linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map': linux/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has no member named 'of_node' Reported-by: Kevin Hilman khil...@linaro.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Hi Linus, Sorry for not spoting this issue before. In a previous version of the patch-set: [PATCH v3 0/2]: auto request GPIO as input if used as IRQ via DT of_have_populated_dt() was used instead of struct gpio_chip of_node member to check wether legacy or DT boot was used. I did a build test on every OMAP platform but later I was asked to use .of_node instead of_have_populated_dt() and forget to do a built test for OMAP1. Such things happen ... I hope this patch can go as a fix for the v3.11-rc cycle. Yeah I queued it on top of the others. Good thing I didn't rush the other two out :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/9] wlcore: always use one-shot IRQ
On Tue, 2013-07-02 at 18:32 +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 05:55:44PM +0300, Luciano Coelho wrote: Since we are now using threaded IRQs without the primary handler, we need to set IRQF_ONESHOT, otherwise our request will fail. Signed-off-by: Luciano Coelho coe...@ti.com good to see this happening, I remember we talked about this a while back :-) Yeah, we talked about it and I did the patch immediately. This is needed because this is obviously not set automatically in the interrupts created via device tree. Acked-by: Felipe Balbi ba...@ti.com Still, if you call irq_set_irq_type() on board-file (since DT will do something similar for you anyway) then you can completely drop irq_flags. Yep. -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote: Hi, On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote: @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func, /* Use block mode for transferring over one block size of data */ func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE; + sdio_set_drvdata(func, glue); is this move really necessary ? It is, because I use the glue in wlcore_get_pdata_from_of(), so I need to call sdio_set_drvdata() earlier. I reckoned it wouldn't hurt to move this, so I wouldn't have to pass the glue in the wlcore_get_pdata_from_of() call. -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote: On 17:55-20130702, Luciano Coelho wrote: Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not. Change all board files to reflect this. Cc: Tony Lindgren 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. -- 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 1/1] gpio/omap: fix build error when OF_GPIO is not defined.
Linus Walleij linus.wall...@linaro.org writes: On Tue, Jul 2, 2013 at 9:46 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The OMAP GPIO driver check if the chip has an associated Device Tree node using the struct gpio_chip of_node member. But this is only build if CONFIG_OF_GPIO is defined which leads to the following error when using omap1_defconfig: linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_chip_init': linux/drivers/gpio/gpio-omap.c:1080:17: error: 'struct gpio_chip' has no member named 'of_node' linux/drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_map': linux/drivers/gpio/gpio-omap.c:1116:16: error: 'struct gpio_chip' has no member named 'of_node' Reported-by: Kevin Hilman khil...@linaro.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Hi Linus, Sorry for not spoting this issue before. In a previous version of the patch-set: [PATCH v3 0/2]: auto request GPIO as input if used as IRQ via DT of_have_populated_dt() was used instead of struct gpio_chip of_node member to check wether legacy or DT boot was used. I did a build test on every OMAP platform but later I was asked to use .of_node instead of_have_populated_dt() and forget to do a built test for OMAP1. Such things happen ... I hope this patch can go as a fix for the v3.11-rc cycle. Yeah I queued it on top of the others. Good thing I didn't rush the other two out :-) I can confirm this makes the build work again for omap1_defconfig. Javier, thanks for the quick fix! Acked-by: Kevin Hilman khil...@linaro.org Kevin -- 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 7/9] wlcore: sdio: add wilink clock providers
Hi, On Tue, Jul 02, 2013 at 06:34:23PM +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 05:55:46PM +0300, Luciano Coelho wrote: 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 Acked-by: Felipe Balbi ba...@ti.com I guess this should've been Reviewed-by: Felipe Balbi ba...@ti.com instead -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
On Tue, Jul 02, 2013 at 11:19:54PM +0300, Luciano Coelho wrote: On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote: Hi, On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote: @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func, /* Use block mode for transferring over one block size of data */ func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE; + sdio_set_drvdata(func, glue); is this move really necessary ? It is, because I use the glue in wlcore_get_pdata_from_of(), so I need to call sdio_set_drvdata() earlier. I reckoned it wouldn't hurt to move this, so I wouldn't have to pass the glue in the wlcore_get_pdata_from_of() call. that's alright, it does look like it deserves a mention in changelog though. Other than that: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 8/9] wlcore: sdio: get clocks from device tree
On Wed, 2013-07-03 at 00:32 +0300, Felipe Balbi wrote: On Tue, Jul 02, 2013 at 11:19:54PM +0300, Luciano Coelho wrote: On Tue, 2013-07-02 at 18:35 +0300, Felipe Balbi wrote: Hi, On Tue, Jul 02, 2013 at 05:55:47PM +0300, Luciano Coelho wrote: @@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func, /* Use block mode for transferring over one block size of data */ func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE; + sdio_set_drvdata(func, glue); is this move really necessary ? It is, because I use the glue in wlcore_get_pdata_from_of(), so I need to call sdio_set_drvdata() earlier. I reckoned it wouldn't hurt to move this, so I wouldn't have to pass the glue in the wlcore_get_pdata_from_of() call. that's alright, it does look like it deserves a mention in changelog though. Other than that: Uh, ok. This was so tiny (and I thought so obvious) a change that I didn't mention it. But if you asked about it, it was not obvious enough. ;) I'll add a small comment about it in the commit message. Reviewed-by: Felipe Balbi ba...@ti.com Thanks! -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
Hi all,
Kindly ignore this message. It was sent in wrong format.
Sorry for the noise
Regards,
Gururaja
On Wed, Jul 03, 2013 at 10:26:57, Hebbar, Gururaja wrote:
Below is the code snippet I was referring to
From drivers/rtc/rtc-omap.c
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,
},
{},
};
MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
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);
From arch/arm/boot/dts/am33xx.dtsi
rtc@44e3e000 {
compatible = ti,da830-rtc, ti,am3352-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
ti,hwmods = rtc;
};
As seen from above snippet, 2 compatible items are specified for
compatible dt property (ti,da830-rtc ti,am3352-rtc”)
These are the same compatibles that are mentioned in the of_device_id
structure inside rtc-omap driver.
What I observed is, if we mention both compatible in the .dtsi file that
are under one single of_device_id structure, the first match from the
of_device_id structure is considered (ti,da830-rtc in above case)
To confirm, I switched the 2 compatible inside of_device_id structure as
below
static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,am3352-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
},
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
{},
};
In this case, the first match from compatible field was chosen
(ti,am3352-rtc now).
Hope this is clear.
Kindly let me know when you are free to discuss.
Regards
Gururaja
-Original Message-
From: Nori, Sekhar
Sent: Tuesday, July 02, 2013 11:47 AM
To: Hebbar, Gururaja
Cc: khil...@linaro.org; t...@atomide.com; Cousson, Benoit; linux-
o...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com; Bedia, Vaibhav;
Rajashekhara, Sudhakar; Grant Likely; Rob Herring; Rob Landley;
Alessandro Zummo; rtc-li...@googlegroups.com; linux-
d...@vger.kernel.org
Subject: Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to
alarm events
On 7/2/2013 11:41 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
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
mailto:gururaja.heb...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
mailto:grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
mailto:rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net mailto:r...@landley.net
Cc: Sekhar Nori nsek...@ti.com mailto:nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org mailto:khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
mailto:a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
mailto:rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
mailto:devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org mailto:linux-...@vger.kernel.org
---
[...]
-#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_AM335X_IDX 2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id
omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device
name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER |
OMAP_RTC_HAS_IRQWAKEEN,
