Re: [PATCHv3 0/8] omap hwspinlock dt support
On Tue, Nov 12, 2013 at 06:16:42PM +, Anna, Suman wrote: Hi, This is an updated series addressing the review comments from the v2 series. The hwmod patches have been dropped from the repost as per Paul's request, they have already been queued. Mark, Hi Suman, Any comments on this series? Tony has picked up the OMAP DTS patches for 3.13, and so the ti,omap4-hwspinlock compatible string is showing up as undocumented in linux-next. How do you want me to proceed here? I will be separating out the bindings into separate patches in the future. The only thing I note that I'm not so keen on is that the hwlock-specifier is always one cell, rather than using a #hwlock-cells property on the provider (even if we required it to be 1 for the moment and just failed if it wasn't). If possible, I would like an amendment to always use #hwlock-cells, but otherwise this looks fine to me. Feel free to add my Ack: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM437x GP EVM support
On Wed, Nov 13, 2013 at 12:34:29PM +0530, Afzal Mohammed wrote: Hi Felipe, On Tuesday 12 November 2013 07:52 PM, Felipe Balbi wrote: On Tue, Nov 12, 2013 at 04:54:26PM +0530, Afzal Mohammed wrote: From: Lokesh Vutla lokeshvu...@ti.com AM437x GP EVM DTS with pinmux information to make I2C on EVM usable. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com Signed-off-by: Afzal Mohammed af...@ti.com could you instead send the much more complete version we already have at [1] ? It's pointless to repatch all of that in this file if we *know* those are already working. By taking those changes and testing on mainline, I couldn't get mmc working and was not confident about ethernet changes, I2C changes were verified and boot test was done (with DT clock series). I posted only the changes that I felt confident. Basic DT file and I2C are dependency for others, it was necessary to remove dependencies at the earliest. fair enough, still sounds weird not to send the full DTS considering it won't cause regressions, it just exposes an existing failure WRT AM437x support upstream. -- balbi signature.asc Description: Digital signature
Re: [PATCH V2] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+ pm_runtime_set_suspended(dev);
don't you have to disable pm_runtime around status changes ? Or is
pm_runtime already disabled by the time we get here ?
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
- if ((od-flags OMAP_DEVICE_SUSPENDED)
- !pm_runtime_status_suspended(dev)) {
+ if (od-flags OMAP_DEVICE_SUSPENDED) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
omap_device_enable(pdev);
+ pm_runtime_set_active(dev);
ditto, also pm_runtime_set_active() may fail.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] clk: add flags to distinguish xtal clocks
On Tue, Nov 12, 2013 at 10:05:49AM +0200, Luca Coelho wrote: What I'm not really convinced about is *how* you carry that metadata in the DT, that's all, nothing more. Okay, I get you. My point is that being a crystal or not *is* a characteristic of the clock, so I think it could be part of the flags that describe it. Yeah, but then, a crystal has a slightly different behaviour and property than a oscillator, therefore the two aren't fully compatible with each other. In any case, it's not really my call. This is about the clock and it's not even my home turf (wireless). ;) Thanks for your comments. And I'm sorry if the tone of my previous email sounded harsh, it was not supposed to. :) That's fine, don't worry :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH V2] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+pm_runtime_set_suspended(dev);
don't you have to disable pm_runtime around status changes ? Or is
pm_runtime already disabled by the time we get here ?
pm_runtime is already disabled by the time no_irq suspend is invoked.
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
-if ((od-flags OMAP_DEVICE_SUSPENDED)
-!pm_runtime_status_suspended(dev)) {
+if (od-flags OMAP_DEVICE_SUSPENDED) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
omap_device_enable(pdev);
+pm_runtime_set_active(dev);
ditto, also pm_runtime_set_active() may fail.
again, pm_runtime is not yet active here yet - we just restore the pm
runtime state with which we went down with - and that is not expected
to fail either - So, how about just adding a WARN if our expectation
of balanced operation was somehow broken in the future with changes to
runtime framework?
--
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: [PATCH V2] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On Wed, Nov 13, 2013 at 08:56:06AM -0600, Nishanth Menon wrote:
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+ pm_runtime_set_suspended(dev);
don't you have to disable pm_runtime around status changes ? Or is
pm_runtime already disabled by the time we get here ?
pm_runtime is already disabled by the time no_irq suspend is invoked.
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
- if ((od-flags OMAP_DEVICE_SUSPENDED)
- !pm_runtime_status_suspended(dev)) {
+ if (od-flags OMAP_DEVICE_SUSPENDED) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
omap_device_enable(pdev);
+ pm_runtime_set_active(dev);
ditto, also pm_runtime_set_active() may fail.
again, pm_runtime is not yet active here yet - we just restore the pm
runtime state with which we went down with - and that is not expected
to fail either - So, how about just adding a WARN if our expectation
of balanced operation was somehow broken in the future with changes to
runtime framework?
you mean:
WARN(pm_runtime_set_active(dev)); ?
sounds good
thanks
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V3 1/7] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/7] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt lines from the subsystems are not needed at the same time, so they have to be muxed to the irq-controller appropriately. In such places a interrupt controllers are preceded by an CROSSBAR that provides flexibility in muxing the device requests to the controller inputs. This driver takes care a allocating a free irq and then configuring the crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should be called right before the irqchip_init, so that it is setup to handle the irqchip callbacks. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Kumar Gala ga...@codeaurora.org (for DT binding portion) --- As someone commented already, lets call the driver as irq-crossbar since there might need of something similar for DMA and IO's. So rename the code accordingly. Other than that, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 3/7] ARM: DTS: DRA: Add crossbar device binding
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: This adds the irq crossbar device node. There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The Peripheral irq requests are connected to only one crossbar input and the output of the crossbar is connected to only one controller's input line. The crossbar device is used to map a peripheral input to a free mpu's interrupt controller line. Cc: Benoit Cousson bcous...@baylibre.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On 11/13/2013 09:20 AM, Felipe Balbi wrote:
On Wed, Nov 13, 2013 at 08:56:06AM -0600, Nishanth Menon wrote:
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+ pm_runtime_set_suspended(dev);
don't you have to disable pm_runtime around status changes ? Or is
pm_runtime already disabled by the time we get here ?
pm_runtime is already disabled by the time no_irq suspend is invoked.
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
- if ((od-flags OMAP_DEVICE_SUSPENDED)
- !pm_runtime_status_suspended(dev)) {
+ if (od-flags OMAP_DEVICE_SUSPENDED) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
omap_device_enable(pdev);
+ pm_runtime_set_active(dev);
ditto, also pm_runtime_set_active() may fail.
again, pm_runtime is not yet active here yet - we just restore the pm
runtime state with which we went down with - and that is not expected
to fail either - So, how about just adding a WARN if our expectation
of balanced operation was somehow broken in the future with changes to
runtime framework?
you mean:
WARN(pm_runtime_set_active(dev)); ?
yes
sounds good
Thanks. Will post a v3 tomorrow morning to give a chance for
discussions on further comments if any.
--
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: [PATCH V3 4/7] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: Now with the crossbar IP in picture, the peripherals do not have the fixed interrupt lines. Instead they rely on the crossbar irqchip to allocate and map a free interrupt line to its crossbar input. So replacing all the peripheral interrupt numbers with its fixed crossbar input lines. Cc: Benoit Cousson bcous...@baylibre.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/boot/dts/dra7.dtsi | 86 +-- 1 file changed, 43 insertions(+), 43 deletions(-) You probably need to split the series with dts and drivers/irqchip/* changes. For patch itself, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 5/7] ARM: DTS: DRA7: Add routable-irqs property for gic node
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The gic provides the support for such IPs in the form of routable-irqs. So adding the property here to gic node. Cc: Benoit Cousson bcous...@baylibre.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 6/7] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: The wakeup gen mask/unmask callback uses the irq element of the irq_data to setup. The irq is the linux virtual irq number and is same as the hardware irq number only when the parent irqchip is setup as a legacy domain. When it is used as a linear domain, the virtual irqs are allocated dynamically and wakeup gen code cannot rely on these numbers to access the irq registers. Instead use the hwirq element of the irq_data which represent the physical irq number. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: Enable the crossbar IP support for DRA7xx soc. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
On 11/11/2013 11:47 PM, Sricharan R wrote: Hi Rajendra, On Tuesday 12 November 2013 11:11 AM, Rajendra Nayak wrote: On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote: Enable the crossbar IP support for DRA7xx soc. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap4-common.c |4 2 files changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b5fb5f7..2086c65 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -141,6 +141,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK + select IRQ_CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 5791143..274cbfa 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -22,6 +22,7 @@ #include linux/of_platform.h #include linux/export.h #include linux/irqchip/arm-gic.h +#include linux/irqchip/irq-crossbar.h #include linux/of_address.h #include linux/reboot.h @@ -282,9 +283,12 @@ void __init omap_gic_of_init(void) skip_errata_init: omap_wakeupgen_init(); + if (soc_is_dra7xx()) + crossbar_init(); Its good if this is called irqcrossbar_init() to avoid confusion with the dma crossbar which also exists in dra7 devices. Ya makes sense. Will change this. Also why not call it without explicit soc check? there is already parse for of_find_matching_node(NULL, crossbar_match); to see if we have a match in the crossbar_init. OR call it from dra7 init without SoC check dependency? Rationale - with more TI SoCs trending towards crossbar, we dont need to keep adding to the soc_is checks, further, we intend to remove soc_is checks in it's entirety.. -- 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: [PATCH V3 1/7] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
Hi, On Wednesday 13 November 2013 08:54 PM, Santosh Shilimkar wrote: On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks Santosh. Will repost all with the minor changes suggested. Regards, Sricharan -- 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 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
On Wednesday 13 November 2013 09:02 PM, Nishanth Menon wrote: On 11/11/2013 11:47 PM, Sricharan R wrote: Hi Rajendra, On Tuesday 12 November 2013 11:11 AM, Rajendra Nayak wrote: On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote: Enable the crossbar IP support for DRA7xx soc. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap4-common.c |4 2 files changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b5fb5f7..2086c65 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -141,6 +141,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK + select IRQ_CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 5791143..274cbfa 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -22,6 +22,7 @@ #include linux/of_platform.h #include linux/export.h #include linux/irqchip/arm-gic.h +#include linux/irqchip/irq-crossbar.h #include linux/of_address.h #include linux/reboot.h @@ -282,9 +283,12 @@ void __init omap_gic_of_init(void) skip_errata_init: omap_wakeupgen_init(); + if (soc_is_dra7xx()) + crossbar_init(); Its good if this is called irqcrossbar_init() to avoid confusion with the dma crossbar which also exists in dra7 devices. Ya makes sense. Will change this. Also why not call it without explicit soc check? there is already parse for of_find_matching_node(NULL, crossbar_match); to see if we have a match in the crossbar_init. OR call it from dra7 init without SoC check dependency? Rationale - with more TI SoCs trending towards crossbar, we dont need to keep adding to the soc_is checks, further, we intend to remove soc_is checks in it's entirety.. Oh yes. I missed this. Thanks for pointing. Will correct. Regards, Sricharan -- 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] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
Nishanth Menon n...@ti.com writes:
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+ pm_runtime_set_suspended(dev);
don't you have to disable pm_runtime around status changes ? Or is
pm_runtime already disabled by the time we get here ?
pm_runtime is already disabled by the time no_irq suspend is invoked.
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
- if ((od-flags OMAP_DEVICE_SUSPENDED)
- !pm_runtime_status_suspended(dev)) {
+ if (od-flags OMAP_DEVICE_SUSPENDED) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
omap_device_enable(pdev);
+ pm_runtime_set_active(dev);
ditto, also pm_runtime_set_active() may fail.
again, pm_runtime is not yet active here yet - we just restore the pm
runtime state with which we went down with - and that is not expected
to fail either - So, how about just adding a WARN if our expectation
of balanced operation was somehow broken in the future with changes to
runtime framework?
And also a note in the changelog (or comment at the WARN) about the
assumption that runtime PM is disabled at this point.
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] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On Wed, Nov 13, 2013 at 9:45 AM, Kevin Hilman khil...@linaro.org wrote:
Nishanth Menon n...@ti.com writes:
On 11/13/2013 06:51 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 12, 2013 at 05:08:30PM -0600, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index b69dd9a..f97b34b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -621,6 +621,7 @@ static int _od_suspend_noirq(struct device *dev)
if (!ret !pm_runtime_status_suspended(dev)) {
if (pm_generic_runtime_suspend(dev) == 0) {
+ pm_runtime_set_suspended(dev);
don't you have to disable pm_runtime around status changes ? Or is
pm_runtime already disabled by the time we get here ?
pm_runtime is already disabled by the time no_irq suspend is invoked.
@@ -634,10 +635,10 @@ static int _od_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
- if ((od-flags OMAP_DEVICE_SUSPENDED)
- !pm_runtime_status_suspended(dev)) {
+ if (od-flags OMAP_DEVICE_SUSPENDED) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
omap_device_enable(pdev);
+ pm_runtime_set_active(dev);
ditto, also pm_runtime_set_active() may fail.
again, pm_runtime is not yet active here yet - we just restore the pm
runtime state with which we went down with - and that is not expected
to fail either - So, how about just adding a WARN if our expectation
of balanced operation was somehow broken in the future with changes to
runtime framework?
And also a note in the changelog (or comment at the WARN) about the
assumption that runtime PM is disabled at this point.
Ofcourse. will do.
--
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: [PATCH V3 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
On Wednesday 13 November 2013 10:32 AM, Nishanth Menon wrote: On 11/11/2013 11:47 PM, Sricharan R wrote: [..] Rationale - with more TI SoCs trending towards crossbar, we dont need to keep adding to the soc_is checks, further, we intend to remove soc_is checks in it's entirety.. Just for record, and thats what am pushing the TI hardware folks is not to build default IRQ configuration considering the software will clean-up the mess. So hope is that we don't have to use this infrastructure always but only for exceptional cases. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Various omap device tree usability fixes for v3.13 merge window
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, Here are some patches to fix various issue for device tree based booting for omaps that I've ran into recently while working on removing legacy platform data for mach-omap2. Regards, Tony Tony Lindgren (8): net: smc91x: Fix device tree based configuration so it's usable mmc: omap: Fix DMA configuration to not rely on device id mmc: omap: Fix I2C dependency and make driver usable with device tree i2c: omap: Fix missing device tree flags for omap2 gpio: twl4030: Fix regression for twl gpio output gpio: twl4030: Fix passing of pdata in the device tree case ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x ARM: dts: Fix omap2 specific dtsi files by adding the missing entries .../devicetree/bindings/net/smsc-lan91c111.txt | 4 + arch/arm/boot/dts/omap-zoom-common.dtsi| 2 +- arch/arm/boot/dts/omap2.dtsi | 96 ++ arch/arm/boot/dts/omap2420.dtsi| 23 ++ arch/arm/boot/dts/omap2430.dtsi| 49 +++ arch/arm/mach-omap2/gpmc.c | 58 + drivers/gpio/gpio-twl4030.c| 13 ++- drivers/i2c/busses/i2c-omap.c | 22 + drivers/mmc/host/omap.c| 42 +- drivers/net/ethernet/smsc/smc91x.c | 52 +--- 10 files changed, 285 insertions(+), 76 deletions(-) -- 1.8.1.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 1/8] net: smc91x: Fix device tree based configuration so it's usable
Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.
Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.
Cc: Nicolas Pitre n...@fluxnic.net
Cc: David S. Miller da...@davemloft.net
Cc: net...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
.../devicetree/bindings/net/smsc-lan91c111.txt | 4 ++
drivers/net/ethernet/smsc/smc91x.c | 52 +-
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
index 953049b..53d69e3 100644
--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -8,3 +8,7 @@ Required properties:
Optional properties:
- phy-device : phandle to Ethernet phy
- local-mac-address : Ethernet mac address to use
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+ should be performed on the device. Valid value for SMSC LAN is
+ 1, 2 or 4. If it's omitted or invalid, the size would be 2.
+- smsc,nowait : Setup for fast register access with no waits
diff --git a/drivers/net/ethernet/smsc/smc91x.c
b/drivers/net/ethernet/smsc/smc91x.c
index 73be7f3..93d4b7d 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -82,6 +82,7 @@ static const char version[] =
#include linux/mii.h
#include linux/workqueue.h
#include linux/of.h
+#include linux/of_device.h
#include linux/netdevice.h
#include linux/etherdevice.h
@@ -2189,6 +2190,15 @@ static void smc_release_datacs(struct platform_device
*pdev, struct net_device *
}
}
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id smc91x_match[] = {
+ { .compatible = smsc,lan91c94, },
+ { .compatible = smsc,lan91c111, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
/*
* smc_init(void)
* Input parameters:
@@ -2203,6 +2213,8 @@ static void smc_release_datacs(struct platform_device
*pdev, struct net_device *
static int smc_drv_probe(struct platform_device *pdev)
{
struct smc91x_platdata *pd = dev_get_platdata(pdev-dev);
+ struct device_node *np = pdev-dev.of_node;
+ const struct of_device_id *match = NULL;
struct smc_local *lp;
struct net_device *ndev;
struct resource *res, *ires;
@@ -,11 +2234,40 @@ static int smc_drv_probe(struct platform_device *pdev)
*/
lp = netdev_priv(ndev);
+ lp-cfg.flags = 0;
if (pd) {
memcpy(lp-cfg, pd, sizeof(lp-cfg));
lp-io_shift = SMC91X_IO_SHIFT(lp-cfg.flags);
- } else {
+ }
+
+#if IS_BUILTIN(CONFIG_OF)
+ match = of_match_device(of_match_ptr(smc91x_match), pdev-dev);
+ if (match) {
+ u32 val;
+
+ of_property_read_u32(np, reg-io-width, val);
+ switch (val) {
+ case 1:
+ lp-cfg.flags |= SMC91X_USE_8BIT;
+ break;
+ case 2:
+ lp-cfg.flags |= SMC91X_USE_16BIT;
+ break;
+ case 4:
+ lp-cfg.flags |= SMC91X_USE_32BIT;
+ break;
+ default:
+ lp-cfg.flags |= SMC91X_USE_16BIT;
+ break;
+ }
+
+ if (of_get_property(np, smsc,nowait, NULL))
+ lp-cfg.flags |= SMC91X_NOWAIT;
+ }
+#endif
+
+ if (!pd !match) {
lp-cfg.flags |= (SMC_CAN_USE_8BIT) ? SMC91X_USE_8BIT : 0;
lp-cfg.flags |= (SMC_CAN_USE_16BIT) ? SMC91X_USE_16BIT : 0;
lp-cfg.flags |= (SMC_CAN_USE_32BIT) ? SMC91X_USE_32BIT : 0;
@@ -2375,15 +2416,6 @@ static int smc_drv_resume(struct device *dev)
return 0;
}
-#ifdef CONFIG_OF
-static const struct of_device_id smc91x_match[] = {
- { .compatible = smsc,lan91c94, },
- { .compatible = smsc,lan91c111, },
- {},
-};
-MODULE_DEVICE_TABLE(of, smc91x_match);
-#endif
-
static struct dev_pm_ops smc_drv_pm_ops = {
.suspend= smc_drv_suspend,
.resume = smc_drv_resume,
--
1.8.1.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 2/8] mmc: omap: Fix DMA configuration to not rely on device id
We are wrongly relying on device id for the DMA configuration which can lead to wrong DMA channel being selected. Fix the issue by using the standard resources like we should. Cc: Chris Ball c...@laptop.org Cc: linux-...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- If this looks OK, I'd like to merge this as a fix via arm-soc tree along with the other patches in this series as my later patches depend on patches in this series. --- drivers/mmc/host/omap.c | 32 +++- 1 file changed, 11 insertions(+), 21 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index b94f38e..ed56868 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -90,17 +90,6 @@ #define OMAP_MMC_CMDTYPE_AC2 #define OMAP_MMC_CMDTYPE_ADTC 3 -#define OMAP_DMA_MMC_TX21 -#define OMAP_DMA_MMC_RX22 -#define OMAP_DMA_MMC2_TX 54 -#define OMAP_DMA_MMC2_RX 55 - -#define OMAP24XX_DMA_MMC2_TX 47 -#define OMAP24XX_DMA_MMC2_RX 48 -#define OMAP24XX_DMA_MMC1_TX 61 -#define OMAP24XX_DMA_MMC1_RX 62 - - #define DRIVER_NAME mmci-omap /* Specifies how often in millisecs to poll for card status changes @@ -1408,19 +1397,20 @@ static int mmc_omap_probe(struct platform_device *pdev) host-dma_tx_burst = -1; host-dma_rx_burst = -1; - if (mmc_omap2()) - sig = host-id == 0 ? OMAP24XX_DMA_MMC1_TX : OMAP24XX_DMA_MMC2_TX; - else - sig = host-id == 0 ? OMAP_DMA_MMC_TX : OMAP_DMA_MMC2_TX; - host-dma_tx = dma_request_channel(mask, omap_dma_filter_fn, sig); + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx); + if (res) + sig = res-start; + host-dma_tx = dma_request_slave_channel_compat(mask, + omap_dma_filter_fn, sig, pdev-dev, tx); if (!host-dma_tx) dev_warn(host-dev, unable to obtain TX DMA engine channel %u\n, sig); - if (mmc_omap2()) - sig = host-id == 0 ? OMAP24XX_DMA_MMC1_RX : OMAP24XX_DMA_MMC2_RX; - else - sig = host-id == 0 ? OMAP_DMA_MMC_RX : OMAP_DMA_MMC2_RX; - host-dma_rx = dma_request_channel(mask, omap_dma_filter_fn, sig); + + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx); + if (res) + sig = res-start; + host-dma_rx = dma_request_slave_channel_compat(mask, + omap_dma_filter_fn, sig, pdev-dev, rx); if (!host-dma_rx) dev_warn(host-dev, unable to obtain RX DMA engine channel %u\n, sig); -- 1.8.1.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 3/8] mmc: omap: Fix I2C dependency and make driver usable with device tree
Some features can be configured by the companion I2C chips,
which may not be available at the probe time. Fix the issue
by returning -EPROBE_DEFER when the MMC controller slots
are not configured.
While at it, let's also add minimal device tree support so
omap24xx platforms can use this driver without legacy mode
since we claim to support device tree for mach-omap2 based
systems.
Although adding the minimal device tree support is not strictly
a fix, it does remove one of the last blockers for dropping a
bunch of legacy platform data for mach-omap2.
Cc: Chris Ball c...@laptop.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
drivers/mmc/host/omap.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index ed56868..43c66ad 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -22,6 +22,7 @@
#include linux/delay.h
#include linux/spinlock.h
#include linux/timer.h
+#include linux/of.h
#include linux/omap-dma.h
#include linux/mmc/host.h
#include linux/mmc/card.h
@@ -1330,7 +1331,7 @@ static int mmc_omap_probe(struct platform_device *pdev)
}
if (pdata-nr_slots == 0) {
dev_err(pdev-dev, no slots\n);
- return -ENXIO;
+ return -EPROBE_DEFER;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1553,6 +1554,12 @@ static int mmc_omap_resume(struct platform_device *pdev)
#define mmc_omap_resumeNULL
#endif
+#if IS_BUILTIN(CONFIG_OF)
+static const struct of_device_id mmc_omap_match[] = {
+ { .compatible = ti,omap2420-mmc, },
+ { },
+};
+#endif
static struct platform_driver mmc_omap_driver = {
.probe = mmc_omap_probe,
.remove = mmc_omap_remove,
@@ -1561,6 +1568,7 @@ static struct platform_driver mmc_omap_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mmc_omap_match),
},
};
--
1.8.1.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 8/8] ARM: dts: Fix omap2 specific dtsi files by adding the missing entries
Looks like we're missing few entries for omap2 and the drivers
have only worked because of the omap hwmod building the devices
for the missing entries.
Let's fix the missing entries so we don't need to rely on hwmod
for the basic data and can then later on remove the duplicate
data from hwmod. Otherwise device tree only drivers will not
work properly.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap2.dtsi| 96 +
arch/arm/boot/dts/omap2420.dtsi | 23 ++
arch/arm/boot/dts/omap2430.dtsi | 49 +
3 files changed, 168 insertions(+)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index a2bfcde..d0c5b37 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -9,6 +9,7 @@
*/
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
#include dt-bindings/pinctrl/omap.h
#include skeleton.dtsi
@@ -21,6 +22,8 @@
serial0 = uart1;
serial1 = uart2;
serial2 = uart3;
+ i2c0 = i2c1;
+ i2c1 = i2c2;
};
cpus {
@@ -53,6 +56,28 @@
ranges;
ti,hwmods = l3_main;
+ aes: aes@480a6000 {
+ compatible = ti,omap2-aes;
+ ti,hwmods = aes;
+ reg = 0x480a6000 0x50;
+ dmas = sdma 9 sdma 10;
+ dma-names = tx, rx;
+ };
+
+ hdq1w: 1w@480b2000 {
+ compatible = ti,omap2420-1w;
+ ti,hwmods = hdq1w;
+ reg = 0x480b2000 0x1000;
+ interrupts = 58;
+ };
+
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ ti,hwmods = mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26;
+ };
+
intc: interrupt-controller@1 {
compatible = ti,omap2-intc;
interrupt-controller;
@@ -63,6 +88,7 @@
sdma: dma-controller@48056000 {
compatible = ti,omap2430-sdma, ti,omap2420-sdma;
+ ti,hwmods = dma;
reg = 0x48056000 0x1000;
interrupts = 12,
13,
@@ -73,21 +99,91 @@
#dma-requests = 64;
};
+ i2c1: i2c@4807 {
+ compatible = ti,omap2-i2c;
+ ti,hwmods = i2c1;
+ reg = 0x4807 0x80;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts = 56;
+ dmas = sdma 27 sdma 28;
+ dma-names = tx, rx;
+ };
+
+ i2c2: i2c@48072000 {
+ compatible = ti,omap2-i2c;
+ ti,hwmods = i2c2;
+ reg = 0x48072000 0x80;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts = 57;
+ dmas = sdma 29 sdma 30;
+ dma-names = tx, rx;
+ };
+
+ mcspi1: mcspi@48098000 {
+ compatible = ti,omap2-mcspi;
+ ti,hwmods = mcspi1;
+ reg = 0x48098000 0x100;
+ interrupts = 65;
+ dmas = sdma 35 sdma 36 sdma 37 sdma 38
+ sdma 39 sdma 40 sdma 41 sdma 42;
+ dma-names = tx0, rx0, tx1, rx1,
+ tx2, rx2, tx3, rx3;
+ };
+
+ mcspi2: mcspi@4809a000 {
+ compatible = ti,omap2-mcspi;
+ ti,hwmods = mcspi2;
+ reg = 0x4809a000 0x100;
+ interrupts = 66;
+ dmas = sdma 43 sdma 44 sdma 45 sdma 46;
+ dma-names = tx0, rx0, tx1, rx1;
+ };
+
+ rng: rng@480a {
+ compatible = ti,omap2-rng;
+ ti,hwmods = rng;
+ reg = 0x480a 0x50;
+ interrupts = 36;
+ };
+
+ sham: sham@480a4000 {
+ compatible = ti,omap2-sham;
+ ti,hwmods = sham;
+ reg = 0x480a4000 0x64;
+ interrupts = 51;
+ dmas = sdma 13;
+ dma-names = rx;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
[PATCH 6/8] gpio: twl4030: Fix passing of pdata in the device tree case
We still have some legacy code needing the callback functions
that won't work properly without platform data. To use platform
data for twl4030-gpio, we need to not trash the possible data.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-g...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
drivers/gpio/gpio-twl4030.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 5738d5a..e6ecbe3 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -436,7 +436,8 @@ static int gpio_twl4030_debounce(u32 debounce, u8 mmc_cd)
static int gpio_twl4030_remove(struct platform_device *pdev);
-static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev,
+ struct twl4030_gpio_platform_data *pdata)
{
struct twl4030_gpio_platform_data *omap_twl_info;
@@ -444,6 +445,9 @@ static struct twl4030_gpio_platform_data
*of_gpio_twl4030(struct device *dev)
if (!omap_twl_info)
return NULL;
+ if (pdata)
+ memcpy(omap_twl_info, pdata, sizeof(*omap_twl_info));
+
omap_twl_info-use_leds = of_property_read_bool(dev-of_node,
ti,use-leds);
@@ -501,7 +505,7 @@ no_irqs:
mutex_init(priv-mutex);
if (node)
- pdata = of_gpio_twl4030(pdev-dev);
+ pdata = of_gpio_twl4030(pdev-dev, pdata);
if (pdata == NULL) {
dev_err(pdev-dev, Platform data is missing\n);
--
1.8.1.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 5/8] gpio: twl4030: Fix regression for twl gpio output
Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output
states in private data) improved things in general, but caused a
regression for setting the GPIO output direction.
The change reorganized twl_direction_out() and twl_set() and swapped
the function names around in the process. While doing that, a bug got
introduced that's not obvious while reading the patch as it appears
as no change to the code.
The bug is we now call function twl4030_set_gpio_dataout() twice in
both twl_direction_out() and twl_set(). Instead, we should first
call twl_direction_out() in twl_direction_out() followed by
twl4030_set_gpio_dataout() in twl_set().
This regression probably has gone unnoticed for a long time as the
bootloader may have set the GPIO direction properly in many cases.
This fixes at least the LCD panel not turning on omap3 LDP for
example.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: linux-g...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
drivers/gpio/gpio-twl4030.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 0c7e891..5738d5a 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -354,17 +354,18 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ int ret = -EINVAL;
mutex_lock(priv-mutex);
if (offset TWL4030_GPIO_MAX)
- twl4030_set_gpio_dataout(offset, value);
+ ret = twl4030_set_gpio_direction(offset, 0);
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
twl_set(chip, offset, value);
- return 0;
+ return ret;
}
static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
--
1.8.1.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 4/8] i2c: omap: Fix missing device tree flags for omap2
As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
drivers/i2c/busses/i2c-omap.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9967a6f..f04afd1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
};
#ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+ .rev = OMAP_I2C_IP_VERSION_1,
+ .flags = OMAP_I2C_FLAG_NO_FIFO |
+ OMAP_I2C_FLAG_SIMPLE_CLOCK |
+ OMAP_I2C_FLAG_16BIT_DATA_REG |
+ OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+ .rev = OMAP_I2C_IP_VERSION_1,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
.compatible = ti,omap3-i2c,
.data = omap3_pdata,
},
+ {
+ .compatible = ti,omap2430-i2c,
+ .data = omap2430_pdata,
+ },
+ {
+ .compatible = ti,omap2420-i2c,
+ .data = omap2420_pdata,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
--
1.8.1.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 7/8] ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x
Commit f2bf0e72d000 (ARM: OMAP2+: Add minimal 8250 support
for GPMC) added support for using bootloader timings for some
devices. Turns out we can do the same by looking at the compatible
flags of the child without adding a new function as smc91x has
a similar issue as 8250 with the bootloader timings.
And let's fix the 8250 naming, we should use the device type as
the name like uart instead of 8250 for zoom dts file.
Cc: Benoît Cousson bcous...@baylibre.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap-zoom-common.dtsi | 2 +-
arch/arm/mach-omap2/gpmc.c | 58 +++--
2 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/omap-zoom-common.dtsi
b/arch/arm/boot/dts/omap-zoom-common.dtsi
index b0ee342..68221fa 100644
--- a/arch/arm/boot/dts/omap-zoom-common.dtsi
+++ b/arch/arm/boot/dts/omap-zoom-common.dtsi
@@ -13,7 +13,7 @@
* they probably share the same GPIO IRQ
* REVISIT: Add timing support from slls644g.pdf
*/
- 8250@3,0 {
+ uart@3,0 {
compatible = ns16550a;
reg = 3 0 0x100;
bank-width = 2;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 51525fa..e09e5ba 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1482,6 +1482,22 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
}
/*
+* For some GPMC devices we still need to rely on the bootloader
+* timings because the devices can be connected via FPGA. So far
+* the list is smc91x on the omap2 SDP boards, and 8250 on zooms.
+* REVISIT: Add timing support from slls644g.pdf and from the
+* lan91c96 manual.
+*/
+ if (of_device_is_compatible(child, ns16550a) ||
+ of_device_is_compatible(child, smsc,lan91c94) ||
+ of_device_is_compatible(child, smsc,lan91c111)) {
+ dev_warn(pdev-dev,
+%s using bootloader timings on CS%d\n,
+child-name, cs);
+ goto no_timings;
+ }
+
+ /*
* FIXME: gpmc_cs_request() will map the CS to an arbitary
* location in the gpmc address space. When booting with
* device-tree we want the NOR flash to be mapped to the
@@ -1509,6 +1525,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
gpmc_read_timings_dt(child, gpmc_t);
gpmc_cs_set_timings(cs, gpmc_t);
+no_timings:
if (of_platform_device_create(child, NULL, pdev-dev))
return 0;
@@ -1521,42 +1538,6 @@ err:
return ret;
}
-/*
- * REVISIT: Add timing support from slls644g.pdf
- */
-static int gpmc_probe_8250(struct platform_device *pdev,
- struct device_node *child)
-{
- struct resource res;
- unsigned long base;
- int ret, cs;
-
- if (of_property_read_u32(child, reg, cs) 0) {
- dev_err(pdev-dev, %s has no 'reg' property\n,
- child-full_name);
- return -ENODEV;
- }
-
- if (of_address_to_resource(child, 0, res) 0) {
- dev_err(pdev-dev, %s has malformed 'reg' property\n,
- child-full_name);
- return -ENODEV;
- }
-
- ret = gpmc_cs_request(cs, resource_size(res), base);
- if (ret 0) {
- dev_err(pdev-dev, cannot request GPMC CS %d\n, cs);
- return ret;
- }
-
- if (of_platform_device_create(child, NULL, pdev-dev))
- return 0;
-
- dev_err(pdev-dev, failed to create gpmc child %s\n, child-name);
-
- return -ENODEV;
-}
-
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1598,10 +1579,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
else if (of_node_cmp(child-name, onenand) == 0)
ret = gpmc_probe_onenand_child(pdev, child);
else if (of_node_cmp(child-name, ethernet) == 0 ||
-of_node_cmp(child-name, nor) == 0)
+of_node_cmp(child-name, nor) == 0 ||
+of_node_cmp(child-name, uart) == 0)
ret = gpmc_probe_generic_child(pdev, child);
- else if (of_node_cmp(child-name, 8250) == 0)
- ret = gpmc_probe_8250(pdev, child);
if (WARN(ret 0, %s: probing gpmc child %s failed\n,
__func__, child-full_name))
--
1.8.1.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
Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2
On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote: As we claim to support device tree for mach-omap2, we should have the necessary flags in the driver to make it usable. Cc: Wolfram Sang w...@the-dreams.de Cc: linux-...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Wolfram Sang w...@the-dreams.de It would have been helpful if the message PATCH [0/x] would have been sent to the i2c-list also. Thanks, Wolfram signature.asc Description: Digital signature
