am335x boneblack memory size and dtb: is memory live patched?
Lately i've been trying to track down a panic i hit when i pass the mem=256M
option to a 3.16 kernel on a bleaglebone black, and i noticed this:
dtc -I dtb ./arch/arm/boot/dts/am335x-boneblack.dtb
...
memory {
device_type = memory;
reg = 0x8000 0x1000;
};
...
that's 256M of memory while the beaglebone black has 512M, does it mean the dtb
is live patched (by u-boot?) before being passed to the kernel?
--
bye,
p.
--
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] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
On 01/16/2015 12:28 AM, Thomas Niederprüm wrote: This patch fixes faulty behaviour in a setup where the input clock for the SRG is fed through the CLKR pin but the McBSP is configured to be master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR must not be configured as output pin. Otherwise the input clock is messed up horribly. The same reasoning applies if CLKX is configured as input for the SRG. If CLKX/CLKR is used as input clock for McBSP then the CBS_CFS is not valid. In this case you need to use CBM_CFS. Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de --- sound/soc/omap/omap-mcbsp.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index bd3ef2a..c89f562 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -530,8 +530,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, case OMAP_MCBSP_SYSCLK_CLKX_EXT: regs-srgr2 |= CLKSM; + regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKXM; + break; case OMAP_MCBSP_SYSCLK_CLKR_EXT: regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKRM; break; default: err = -ENODEV; -- Péter -- 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] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
Hi On Thu, Jan 15, 2015 at 11:28:21PM +0100, Thomas Niederprüm wrote: This patch fixes faulty behaviour in a setup where the input clock for the SRG is fed through the CLKR pin but the McBSP is configured to be master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR must not be configured as output pin. Otherwise the input clock is messed up horribly. The same reasoning applies if CLKX is configured as input for the SRG. Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de --- sound/soc/omap/omap-mcbsp.c | 4 1 file changed, 4 insertions(+) I cannot check at the moment but is this actually a contradictory configuration if McBSP is set to bit clock master but at the same want to use it as an input also? Should you use SND_SOC_DAIFMT_CBM_CFS instead? Peter: care to check? -- Jarkko -- 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] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
Am Freitag, den 16.01.2015, 11:15 +0200 schrieb Peter Ujfalusi: On 01/16/2015 12:28 AM, Thomas Niederprüm wrote: This patch fixes faulty behaviour in a setup where the input clock for the SRG is fed through the CLKR pin but the McBSP is configured to be master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR must not be configured as output pin. Otherwise the input clock is messed up horribly. The same reasoning applies if CLKX is configured as input for the SRG. If CLKX/CLKR is used as input clock for McBSP then the CBS_CFS is not valid. In this case you need to use CBM_CFS. The setup I am using is the following: McBSP is driving an external i2s DAC as master by supplying CLKX and FSX and DX. The DAC only supports i2s slave mode. For synchronization the DAC and the McBSP should share the same master/reference clock (CLKM). Since I don't need the receive path of the McBSP anyway for the DAC I can use the CLKR pin to insert the CLKM as input to the SRG. I think in this scenario CBS_CFS is valid since the McBSP acts as master (for the transmit path) It might be more common to use the CKLS pin to inject the reference clock, but the beagleboard-xm I am using already hard wired this to the built-in twl4030 codec which makes it unusable. Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de --- sound/soc/omap/omap-mcbsp.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index bd3ef2a..c89f562 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -530,8 +530,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, case OMAP_MCBSP_SYSCLK_CLKX_EXT: regs-srgr2 |= CLKSM; + regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKXM; + break; case OMAP_MCBSP_SYSCLK_CLKR_EXT: regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKRM; break; default: err = -ENODEV; -- Thomas Niederprüm TU Kaiserslautern FB Physik (AG Ott) Erwin-Schrödinger-Str. 46/431 67663 Kaiserslautern Tel.: 0631 205 2387 Fax: 0631 205 3906 -- 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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Fri, Jan 16, 2015 at 06:09:00AM +, Ohad Ben-Cohen wrote: On Thu, Jan 15, 2015 at 4:42 PM, Rob Herring robherri...@gmail.com wrote: On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland mark.rutl...@arm.com wrote: On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote: On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote: +- hwlock-base-id: An unique base Id for the locks for a particular hwlock + device. This property is mandatory for all platform + implementations. This property makes no sense. The ID encoded in the hwlock cells is relative to the instance (identified by phandle), not global. So the DT has no global ID space. Why do you think you need this? Having looked at the way this proeprty is used, NAK. If you need to carve up a Linux-internal ID space, do that dynamically. There is no need for this property. Better yet, don't create a Linux ID space for this. Everywhere we have one, we want to get rid of it. Rob, Mark, The hwlock is a basic hardware primitive that allow synchronization between different processors in the system, which may be running Linux as well as other operating systems, and may have no other means of communication. The hwlock id numbers are predefined, global and static across the entire system: Linux may boot well after other operating systems are already running and using these hwlocks to communicate, and therefore, in order to use these hardware devices, it must not enumerate them differently than the rest of the system. That's not true. In order to communicate it must agree with the other users as to the meaning of each instance, and the protocol for use. That doesn't necessarily mean that Linux needs to know the numerical ID from a datasheet, and regardless that ID is separate from the logical ID Linux uses internally. Given that these id numbers are global, system-wide, static and predefined, where Linux may just be one user of them, please reconsider the approach as implemented by Suman, or suggest an alternative one you may prefer. To communicate with the other processors, Linux will need to understand the protocol. So there will need to be nodes in the DT describing the protocol. Those nodes can refer to the relevant locks using phandle + args (with a hwlock-names list if indexing is not appropriate). The entire point of the hwlock-cells is to allow individual locks to be referred to in this way. 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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Thu, Jan 15, 2015 at 02:42:23PM +, Rob Herring wrote: On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland mark.rutl...@arm.com wrote: On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote: On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote: This patch adds the generic common bindings used to represent a hwlock device and use/request locks in a device-tree build. All the platform-specific hwlock driver implementations need the number of locks and associated base id for registering the locks present within the device with the driver core. This base id needs to be unique across multiple IP instances of a hwspinlock device, so that each hwlock can be represented uniquely in a system. The number of locks is represented by 'hwlock-num-locks' property, and the base id is represented by the 'hwlock-base-id' property. The args specifier length is dependent on each vendor-specific implementation and is represented through the '#hwlock-cells' property. Client users need to use the property 'hwlocks' for requesting specific lock(s). Note that the document is named hwlock.txt deliberately to keep it a bit more generic. Cc: Rob Herring robh...@kernel.org Signed-off-by: Suman Anna s-a...@ti.com --- v7: Revised binding info for hwlock-base-id, it is mandatory now .../devicetree/bindings/hwlock/hwlock.txt | 55 ++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt new file mode 100644 index ..8de7aaf878f9 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -0,0 +1,55 @@ +Generic hwlock bindings +=== + +Generic bindings that are common to all the hwlock platform specific driver +implementations. + +The validity and need of these common properties may vary from one platform +implementation to another. The platform specific bindings should explicitly +state if an optional property is used. Please also look through the individual +platform specific hwlock binding documentations for identifying the applicable +properties. + +Common properties: +- #hwlock-cells: Specifies the number of cells needed to represent a + specific lock. This property is mandatory for all + platform implementations. +- hwlock-num-locks:Number of locks present in a hwlock device. This + property is needed on hwlock devices, where the number + of supported locks within a hwlock device cannot be + read from a register. +- hwlock-base-id: An unique base Id for the locks for a particular hwlock + device. This property is mandatory for all platform + implementations. This property makes no sense. The ID encoded in the hwlock cells is relative to the instance (identified by phandle), not global. So the DT has no global ID space. Why do you think you need this? Having looked at the way this proeprty is used, NAK. If you need to carve up a Linux-internal ID space, do that dynamically. There is no need for this property. Better yet, don't create a Linux ID space for this. Everywhere we have one, we want to get rid of it. Agreed. A completely opaque token / desc structure would prevent a lot of potential abuse and save us from painful breakage. 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] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
On 01/16/2015 12:15 PM, Thomas Niederprüm wrote: Am Freitag, den 16.01.2015, 11:15 +0200 schrieb Peter Ujfalusi: On 01/16/2015 12:28 AM, Thomas Niederprüm wrote: This patch fixes faulty behaviour in a setup where the input clock for the SRG is fed through the CLKR pin but the McBSP is configured to be master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR must not be configured as output pin. Otherwise the input clock is messed up horribly. The same reasoning applies if CLKX is configured as input for the SRG. If CLKX/CLKR is used as input clock for McBSP then the CBS_CFS is not valid. In this case you need to use CBM_CFS. The setup I am using is the following: McBSP is driving an external i2s DAC as master by supplying CLKX and FSX and DX. The DAC only supports i2s slave mode. For synchronization the DAC and the McBSP should share the same master/reference clock (CLKM). Since I don't need the receive path of the McBSP anyway for the DAC I can use the CLKR pin to insert the CLKM as input to the SRG. I think in this scenario CBS_CFS is valid since the McBSP acts as master (for the transmit path) Unfortunately the omap-mcbsp driver only supports synchronous configuration for tx/rx (since almost all McBSP instance can only be used this way). The first stream will configure both tx and rx to have the same properties. Even if you are using McBSP1 which has separate FSX and FSR lines, the driver does not have support for this. From HW point of view this configuration is valid (not something I would expect in any product). I don't think there are or will be other designs than your using this mode... But, if you add some comment around the masking of CLKXM and CLKRM bits that would be great. Just shortly why and also note that the set_dai_sysclk() _need_ to be called after set_dai_fmt() to get the configuration you expect to see. It might be more common to use the CKLS pin to inject the reference clock, but the beagleboard-xm I am using already hard wired this to the built-in twl4030 codec which makes it unusable. If you don't use the twl4030 the 256FS line should be floating, we are using CBM_CFM for the twl4030 card which means that the 256FS is not enabled - the line is floating. It should be safe to use the CLKS, but it is not rooted to any pin :( Or remove the resistor form the line and connect your sync clock instead. Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de --- sound/soc/omap/omap-mcbsp.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index bd3ef2a..c89f562 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -530,8 +530,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, case OMAP_MCBSP_SYSCLK_CLKX_EXT: regs-srgr2 |= CLKSM; + regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKXM; + break; case OMAP_MCBSP_SYSCLK_CLKR_EXT: regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKRM; break; default: err = -ENODEV; -- Péter -- 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] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
Am Freitag, den 16.01.2015, 14:42 +0200 schrieb Peter Ujfalusi: On 01/16/2015 12:15 PM, Thomas Niederprüm wrote: Am Freitag, den 16.01.2015, 11:15 +0200 schrieb Peter Ujfalusi: On 01/16/2015 12:28 AM, Thomas Niederprüm wrote: This patch fixes faulty behaviour in a setup where the input clock for the SRG is fed through the CLKR pin but the McBSP is configured to be master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR must not be configured as output pin. Otherwise the input clock is messed up horribly. The same reasoning applies if CLKX is configured as input for the SRG. If CLKX/CLKR is used as input clock for McBSP then the CBS_CFS is not valid. In this case you need to use CBM_CFS. The setup I am using is the following: McBSP is driving an external i2s DAC as master by supplying CLKX and FSX and DX. The DAC only supports i2s slave mode. For synchronization the DAC and the McBSP should share the same master/reference clock (CLKM). Since I don't need the receive path of the McBSP anyway for the DAC I can use the CLKR pin to insert the CLKM as input to the SRG. I think in this scenario CBS_CFS is valid since the McBSP acts as master (for the transmit path) Unfortunately the omap-mcbsp driver only supports synchronous configuration for tx/rx (since almost all McBSP instance can only be used this way). The first stream will configure both tx and rx to have the same properties. Even if you are using McBSP1 which has separate FSX and FSR lines, the driver does not have support for this. From HW point of view this configuration is valid (not something I would expect in any product). I don't think there are or will be other designs than your using this mode... But, if you add some comment around the masking of CLKXM and CLKRM bits that would be great. Do you mean adding it to the commit message or to the code? or both? Just shortly why and also note that the set_dai_sysclk() _need_ to be called after set_dai_fmt() to get the configuration you expect to see. It might be more common to use the CKLS pin to inject the reference clock, but the beagleboard-xm I am using already hard wired this to the built-in twl4030 codec which makes it unusable. If you don't use the twl4030 the 256FS line should be floating, we are using CBM_CFM for the twl4030 card which means that the 256FS is not enabled - the line is floating. It should be safe to use the CLKS, but it is not rooted to any pin :( Or remove the resistor form the line and connect your sync clock instead. I considered that for a moment as well, but it seemed hack-ish to me. I have to live with whatever can be muxed to the expansion headers of the beagle-xm and with that boundary condition using the CLKR seemed to be the most elegant solution. Also I gain the benefit that the twl4030 remains usable. Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de --- sound/soc/omap/omap-mcbsp.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index bd3ef2a..c89f562 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -530,8 +530,12 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai, case OMAP_MCBSP_SYSCLK_CLKX_EXT: regs-srgr2 |= CLKSM; + regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKXM; + break; case OMAP_MCBSP_SYSCLK_CLKR_EXT: regs-pcr0 |= SCLKME; + regs-pcr0 = ~CLKRM; break; default: err = -ENODEV; -- Thomas Niederprüm TU Kaiserslautern FB Physik (AG Ott) Erwin-Schrödinger-Str. 46/431 67663 Kaiserslautern Tel.: 0631 205 2387 Fax: 0631 205 3906 -- 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-net-next v3 1/2] net: ethernet: cpsw: unroll IRQ request loop
This patch is in preparation for a nicer IRQ
handling scheme where we use different IRQ
handlers for each IRQ line (as it should be).
Later, we will also drop IRQs offset 0 and 3
because they are always disabled in this driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
no changes
drivers/net/ethernet/ti/cpsw.c | 62 --
1 file changed, 47 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index e61ee8351272..8e1af51e4b76 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2156,7 +2156,8 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
u32 slave_offset, sliver_offset, slave_size;
- int ret = 0, i, k = 0;
+ int ret = 0, i;
+ int irq;
ndev = alloc_etherdev(sizeof(struct cpsw_priv));
if (!ndev) {
@@ -2345,24 +2346,55 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
- while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
- if (k = ARRAY_SIZE(priv-irqs_table)) {
- ret = -EINVAL;
- goto clean_ale_ret;
- }
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0)
+ goto clean_ale_ret;
- ret = devm_request_irq(pdev-dev, res-start, cpsw_interrupt,
- 0, dev_name(pdev-dev), priv);
- if (ret 0) {
- dev_err(priv-dev, error attaching irq (%d)\n, ret);
- goto clean_ale_ret;
- }
+ priv-irqs_table[0] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
+ }
- priv-irqs_table[k] = res-start;
- k++;
+ irq = platform_get_irq(pdev, 1);
+ if (irq 0)
+ goto clean_ale_ret;
+
+ priv-irqs_table[1] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
+ }
+
+ irq = platform_get_irq(pdev, 2);
+ if (irq 0)
+ goto clean_ale_ret;
+
+ priv-irqs_table[2] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
+ }
+
+ irq = platform_get_irq(pdev, 3);
+ if (irq 0)
+ goto clean_ale_ret;
+
+ priv-irqs_table[3] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ 0, dev_name(pdev-dev), priv);
+ if (ret 0) {
+ dev_err(priv-dev, error attaching irq (%d)\n, ret);
+ goto clean_ale_ret;
}
- priv-num_irqs = k;
+ priv-num_irqs = 4;
ndev-features |= NETIF_F_HW_VLAN_CTAG_FILTER;
--
2.2.0
--
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-net-next v3 2/2] net: ethernet: cpsw: don't requests IRQs we don't use
CPSW never uses RX_THRESHOLD or MISC interrupts. In
fact, they are always kept masked in their appropriate
IRQ Enable register.
Instead of allocating an IRQ that never fires, it's best
to remove that code altogether and let future patches
implement it if anybody needs those.
Signed-off-by: Felipe Balbi ba...@ti.com
---
combined patches 2 and 3.
drivers/net/ethernet/ti/cpsw.c | 72 +++---
1 file changed, 33 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8e1af51e4b76..ba09ff3c1695 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -754,17 +754,25 @@ requeue:
dev_kfree_skb_any(new_skb);
}
-static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
+static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
- int value = irq - priv-irqs_table[0];
- /* NOTICE: Ending IRQ here. The trick with the 'value' variable above
-* is to make sure we will always write the correct value to the EOI
-* register. Namely 0 for RX_THRESH Interrupt, 1 for RX Interrupt, 2
-* for TX Interrupt and 3 for MISC Interrupt.
-*/
- cpdma_ctlr_eoi(priv-dma, value);
+ cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_TX);
+ cpdma_chan_process(priv-txch, 128);
+
+ priv = cpsw_get_slave_priv(priv, 1);
+ if (priv)
+ cpdma_chan_process(priv-txch, 128);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
+{
+ struct cpsw_priv *priv = dev_id;
+
+ cpdma_ctlr_eoi(priv-dma, CPDMA_EOI_RX);
cpsw_intr_disable(priv);
if (priv-irq_enabled == true) {
@@ -1617,7 +1625,8 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
cpsw_intr_disable(priv);
cpdma_ctlr_int_ctrl(priv-dma, false);
- cpsw_interrupt(ndev-irq, priv);
+ cpsw_rx_interrupt(priv-irq[0], priv);
+ cpsw_tx_interrupt(priv-irq[1], priv);
cpdma_ctlr_int_ctrl(priv-dma, true);
cpsw_intr_enable(priv);
}
@@ -2339,62 +2348,47 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_dma_ret;
}
- ndev-irq = platform_get_irq(pdev, 0);
+ ndev-irq = platform_get_irq(pdev, 1);
if (ndev-irq 0) {
dev_err(priv-dev, error getting irq resource\n);
ret = -ENOENT;
goto clean_ale_ret;
}
- irq = platform_get_irq(pdev, 0);
- if (irq 0)
- goto clean_ale_ret;
-
- priv-irqs_table[0] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
- 0, dev_name(pdev-dev), priv);
- if (ret 0) {
- dev_err(priv-dev, error attaching irq (%d)\n, ret);
- goto clean_ale_ret;
- }
+ /* Grab RX and TX IRQs. Note that we also have RX_THRESHOLD and
+* MISC IRQs which are always kept disabled with this driver so
+* we will not request them.
+*
+* If anyone wants to implement support for those, make sure to
+* first request and append them to irqs_table array.
+*/
+ /* RX IRQ */
irq = platform_get_irq(pdev, 1);
if (irq 0)
goto clean_ale_ret;
- priv-irqs_table[1] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ priv-irqs_table[0] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_rx_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
goto clean_ale_ret;
}
+ /* TX IRQ */
irq = platform_get_irq(pdev, 2);
if (irq 0)
goto clean_ale_ret;
- priv-irqs_table[2] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
- 0, dev_name(pdev-dev), priv);
- if (ret 0) {
- dev_err(priv-dev, error attaching irq (%d)\n, ret);
- goto clean_ale_ret;
- }
-
- irq = platform_get_irq(pdev, 3);
- if (irq 0)
- goto clean_ale_ret;
-
- priv-irqs_table[3] = irq;
- ret = devm_request_irq(pdev-dev, irq, cpsw_interrupt,
+ priv-irqs_table[1] = irq;
+ ret = devm_request_irq(pdev-dev, irq, cpsw_tx_interrupt,
0, dev_name(pdev-dev), priv);
if (ret 0) {
dev_err(priv-dev, error attaching irq (%d)\n, ret);
goto clean_ale_ret;
}
-
- priv-num_irqs = 4;
+ priv-num_irqs = 2;
ndev-features |= NETIF_F_HW_VLAN_CTAG_FILTER;
--
2.2.0
--
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
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
* Russell King - ARM Linux li...@arm.linux.org.uk [150115 09:22]: On Thu, Jan 15, 2015 at 07:28:39AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 02:53]: I don't think we've proven a link there. While you're right that it causes the wrong interrupt to be claimed, I have two kernels here, both claim the same interrupt, one which is multi-platform and issues that strange warning, and one which targets only OMAP4 which doesn't. There's something else going on which causes the bus errors which we haven't found. I think it gets triggered if you enable PREEMPT. That's something which we can try to prove... build running now with CONFIG_PREEMPT=y Looks like you now have the omap_l3_noc error appear for sdp4430 in your logs after enabling PREEMPT. I guess that means case closed for this one? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Fri, Jan 16, 2015 at 08:21:20AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 09:22]: On Thu, Jan 15, 2015 at 07:28:39AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 02:53]: I don't think we've proven a link there. While you're right that it causes the wrong interrupt to be claimed, I have two kernels here, both claim the same interrupt, one which is multi-platform and issues that strange warning, and one which targets only OMAP4 which doesn't. There's something else going on which causes the bus errors which we haven't found. I think it gets triggered if you enable PREEMPT. That's something which we can try to prove... build running now with CONFIG_PREEMPT=y Looks like you now have the omap_l3_noc error appear for sdp4430 in your logs after enabling PREEMPT. I guess that means case closed for this one? I would still like to understand /why/ enabling preempt causes the error. Changing the preempt configuration really should not change what happens on the bus. (Think about it.) It's an indication that there is some other error present. Unfortunately, the OMAP hardware appears to make it impossible to determine what the access that caused the error was, so it looks like it's pretty much undebuggable. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
* Russell King - ARM Linux li...@arm.linux.org.uk [150116 08:33]: On Fri, Jan 16, 2015 at 08:21:20AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 09:22]: On Thu, Jan 15, 2015 at 07:28:39AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 02:53]: I don't think we've proven a link there. While you're right that it causes the wrong interrupt to be claimed, I have two kernels here, both claim the same interrupt, one which is multi-platform and issues that strange warning, and one which targets only OMAP4 which doesn't. There's something else going on which causes the bus errors which we haven't found. I think it gets triggered if you enable PREEMPT. That's something which we can try to prove... build running now with CONFIG_PREEMPT=y Looks like you now have the omap_l3_noc error appear for sdp4430 in your logs after enabling PREEMPT. I guess that means case closed for this one? I would still like to understand /why/ enabling preempt causes the error. Changing the preempt configuration really should not change what happens on the bus. (Think about it.) It's an indication that there is some other error present. We have a wrong irq number caused by $subject. And the wrong irq gets triggered before the dma hardware is configured during dma init. And then we get the invalid access error from omap_l3_noc. Unfortunately, the OMAP hardware appears to make it impossible to determine what the access that caused the error was, so it looks like it's pretty much undebuggable. Yeah would be nice to have more info from omap_l3_noc. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Fri, Jan 16, 2015 at 08:41:06AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 08:33]: On Fri, Jan 16, 2015 at 08:21:20AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 09:22]: On Thu, Jan 15, 2015 at 07:28:39AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150115 02:53]: I don't think we've proven a link there. While you're right that it causes the wrong interrupt to be claimed, I have two kernels here, both claim the same interrupt, one which is multi-platform and issues that strange warning, and one which targets only OMAP4 which doesn't. There's something else going on which causes the bus errors which we haven't found. I think it gets triggered if you enable PREEMPT. That's something which we can try to prove... build running now with CONFIG_PREEMPT=y Looks like you now have the omap_l3_noc error appear for sdp4430 in your logs after enabling PREEMPT. I guess that means case closed for this one? I would still like to understand /why/ enabling preempt causes the error. Changing the preempt configuration really should not change what happens on the bus. (Think about it.) It's an indication that there is some other error present. We have a wrong irq number caused by $subject. And the wrong irq gets triggered before the dma hardware is configured during dma init. And then we get the invalid access error from omap_l3_noc. Unfortunately, the OMAP hardware appears to make it impossible to determine what the access that caused the error was, so it looks like it's pretty much undebuggable. Yeah would be nice to have more info from omap_l3_noc. you can probably get more info by decoding all L4 instance errors. It's just not implemented anywhere. In this case, we should decode l4cfg which is who generated the error. -- balbi signature.asc Description: Digital signature
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Thursday 15 January 2015 07:37:48 Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:46]: On Thu, Jan 15 2015 at 2:27:56 pm GMT, Arnd Bergmann a...@arndb.de wrote: On Thursday 15 January 2015 13:42:57 Marc Zyngier wrote: Probably there is a workable strategy, but my knowledge about OMAP is close to *nothing*... I have a feeling this might bite other platforms too and we just have not noticed it yet.. I'm looking through the entire tree now, scanning for machines that have GIC and use IORESOURCE_IRQ or DEFINE_RES_IRQ in their platform code. Most platforms using GIC are completely converted to DT and have no hardcoded legacy IRQs. I have checked that cns3xxx and realview are both fine by inspection. The only one I'm not sure about is shmobile, which looks like it might suffer from the same problem. Simon/Magnus, could you verify this with a multiplatform kernel on any SoC that has GIC and uses devices that have interrupts defined in setup-*.c or board-*.c? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Fri, Jan 16, 2015 at 08:41:06AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 08:33]: I would still like to understand /why/ enabling preempt causes the error. Changing the preempt configuration really should not change what happens on the bus. (Think about it.) It's an indication that there is some other error present. We have a wrong irq number caused by $subject. And the wrong irq gets triggered before the dma hardware is configured during dma init. And then we get the invalid access error from omap_l3_noc. ... which should happen whether or not preempt is enabled, which is really my point. We know tha the wrong IRQ gets requested by the driver - and that wrong IRQ is requested whether or not we have preempt enabled. Yet we get the warning whether or not preempt is enabled. The DMA handler is not registered as a threaded handler, so it's not depending on a context switch to execute omap2_dma_irq_handler(). Another reason why I don't agree with your explanation is that by the time setup_irq() is called, we have already poked at the DMA hardware several times - omap_clear_dma() and omap2_disable_irq_lch() will have been called for each DMA channel - and both will write to the hardware. What's more is that the only things left after setup_irq() has been called is to possibly reserve the first two DMA channels and print the DMA message (via show_dma_caps). So I see nothing after setup_irq() which would finish any unfinished hardware initialisation. The final reason I don't agree is that I've put a printk() in omap2_dma_irq_handler(), and this does not trigger. So, I think this has nothing to do with the DMA hardware /at all/, but more to do with the GPIO code, and it suggests that the GPIO code publishes IRQs before it is safe for those IRQs to be used. Maybe it has to do with omap_gpio_irq_handler() being called... added printk(), nope, that's not called either. So it's not an IRQ which gets triggered at all. What is called are (in order): omap_gpio_unmask_irq() omap_set_gpio_irqenable() omap_enable_gpio_irqbank() and this reveals where the problem is, especially when you then add instrumentation into the runtime PM functions - and this reveals that when a GPIO IRQ is requested, these functions are called while the GPIO is runtime suspended. _That_ is where the *real* problem lies - requesting a GPIO interrupt results in the kernel touching possibly runtime-suspended hardware. The reason it happens with preempt is that preempt introduces scheduling points during the kernel boot which would not otherwise be there (with preempt disabled, you have to hit an explicit context switch due to contention on some lock or a wait in order for some other thread to run.) So, the GPIO driver really needs fixing - and I'd suggest fixing it first, before fixing the DMA problem, because the DMA problem allows us to see the GPIO problem. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On 16/01/15 16:56, Arnd Bergmann wrote: On Thursday 15 January 2015 07:37:48 Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:46]: On Thu, Jan 15 2015 at 2:27:56 pm GMT, Arnd Bergmann a...@arndb.de wrote: On Thursday 15 January 2015 13:42:57 Marc Zyngier wrote: Probably there is a workable strategy, but my knowledge about OMAP is close to *nothing*... I have a feeling this might bite other platforms too and we just have not noticed it yet.. I'm looking through the entire tree now, scanning for machines that have GIC and use IORESOURCE_IRQ or DEFINE_RES_IRQ in their platform code. Most platforms using GIC are completely converted to DT and have no hardcoded legacy IRQs. I have checked that cns3xxx and realview are both fine by inspection. The only one I'm not sure about is shmobile, which looks like it might suffer from the same problem. Simon/Magnus, could you verify this with a multiplatform kernel on any SoC that has GIC and uses devices that have interrupts defined in setup-*.c or board-*.c? There are 3 patches floating around for shmobile, converting their non-DT support to directly initializing the GIC instead of relying on irqchip_init(). That's assuming their DT implementation doesn't use any of these device declarations. If they do, we could use a hack similar to the one I implemented for OMAP, populating the virtual IRQ in the resource at boot time, just after the irqchip initialization. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
* Russell King - ARM Linux li...@arm.linux.org.uk [150116 09:25]: On Fri, Jan 16, 2015 at 08:41:06AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 08:33]: I would still like to understand /why/ enabling preempt causes the error. Changing the preempt configuration really should not change what happens on the bus. (Think about it.) It's an indication that there is some other error present. We have a wrong irq number caused by $subject. And the wrong irq gets triggered before the dma hardware is configured during dma init. And then we get the invalid access error from omap_l3_noc. ... which should happen whether or not preempt is enabled, which is really my point. We know tha the wrong IRQ gets requested by the driver - and that wrong IRQ is requested whether or not we have preempt enabled. Yet we get the warning whether or not preempt is enabled. The DMA handler is not registered as a threaded handler, so it's not depending on a context switch to execute omap2_dma_irq_handler(). Another reason why I don't agree with your explanation is that by the time setup_irq() is called, we have already poked at the DMA hardware several times - omap_clear_dma() and omap2_disable_irq_lch() will have been called for each DMA channel - and both will write to the hardware. What's more is that the only things left after setup_irq() has been called is to possibly reserve the first two DMA channels and print the DMA message (via show_dma_caps). So I see nothing after setup_irq() which would finish any unfinished hardware initialisation. The final reason I don't agree is that I've put a printk() in omap2_dma_irq_handler(), and this does not trigger. Oh, yes that blows my theory completely then. So, I think this has nothing to do with the DMA hardware /at all/, but more to do with the GPIO code, and it suggests that the GPIO code publishes IRQs before it is safe for those IRQs to be used. Maybe it has to do with omap_gpio_irq_handler() being called... added printk(), nope, that's not called either. So it's not an IRQ which gets triggered at all. What is called are (in order): omap_gpio_unmask_irq() omap_set_gpio_irqenable() omap_enable_gpio_irqbank() and this reveals where the problem is, especially when you then add instrumentation into the runtime PM functions - and this reveals that when a GPIO IRQ is requested, these functions are called while the GPIO is runtime suspended. _That_ is where the *real* problem lies - requesting a GPIO interrupt results in the kernel touching possibly runtime-suspended hardware. The reason it happens with preempt is that preempt introduces scheduling points during the kernel boot which would not otherwise be there (with preempt disabled, you have to hit an explicit context switch due to contention on some lock or a wait in order for some other thread to run.) OK makes sense. So, the GPIO driver really needs fixing - and I'd suggest fixing it first, before fixing the DMA problem, because the DMA problem allows us to see the GPIO problem. Yes we need to fix that. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On 01/16/2015 04:19 AM, Mark Rutland wrote: On Thu, Jan 15, 2015 at 02:42:23PM +, Rob Herring wrote: On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland mark.rutl...@arm.com wrote: On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote: On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote: This patch adds the generic common bindings used to represent a hwlock device and use/request locks in a device-tree build. All the platform-specific hwlock driver implementations need the number of locks and associated base id for registering the locks present within the device with the driver core. This base id needs to be unique across multiple IP instances of a hwspinlock device, so that each hwlock can be represented uniquely in a system. The number of locks is represented by 'hwlock-num-locks' property, and the base id is represented by the 'hwlock-base-id' property. The args specifier length is dependent on each vendor-specific implementation and is represented through the '#hwlock-cells' property. Client users need to use the property 'hwlocks' for requesting specific lock(s). Note that the document is named hwlock.txt deliberately to keep it a bit more generic. Cc: Rob Herring robh...@kernel.org Signed-off-by: Suman Anna s-a...@ti.com --- v7: Revised binding info for hwlock-base-id, it is mandatory now .../devicetree/bindings/hwlock/hwlock.txt | 55 ++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt new file mode 100644 index ..8de7aaf878f9 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -0,0 +1,55 @@ +Generic hwlock bindings +=== + +Generic bindings that are common to all the hwlock platform specific driver +implementations. + +The validity and need of these common properties may vary from one platform +implementation to another. The platform specific bindings should explicitly +state if an optional property is used. Please also look through the individual +platform specific hwlock binding documentations for identifying the applicable +properties. + +Common properties: +- #hwlock-cells: Specifies the number of cells needed to represent a + specific lock. This property is mandatory for all + platform implementations. +- hwlock-num-locks:Number of locks present in a hwlock device. This + property is needed on hwlock devices, where the number + of supported locks within a hwlock device cannot be + read from a register. +- hwlock-base-id: An unique base Id for the locks for a particular hwlock + device. This property is mandatory for all platform + implementations. This property makes no sense. The ID encoded in the hwlock cells is relative to the instance (identified by phandle), not global. So the DT has no global ID space. Why do you think you need this? Having looked at the way this proeprty is used, NAK. If you need to carve up a Linux-internal ID space, do that dynamically. There is no need for this property. Better yet, don't create a Linux ID space for this. Everywhere we have one, we want to get rid of it. Agreed. A completely opaque token / desc structure would prevent a lot of potential abuse and save us from painful breakage. The regular API to acquire or release a lock on Linux does indeed use opaque handles, but the id space is needed for communication with other processors as the handles have no meaning on non-Linux processors. The id space is the simplest to exchange which lock to use with other processors compared to the device instance plus the lock number within that device. regards Suman -- 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: [v3,15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Hi Pankaj, On 15/01/15 06:41, Pankaj Dubey wrote: +CC: Thomas Abraham thomas...@samsung.com Hi Mark, On Monday 12 January 2015 11:56 PM, Marc Zyngier wrote: Exynos has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the fact that the PMU block is actually the first interrupt controller in the chain for RTC, kernels with this patch applied wont have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs may not even boot. Also, I stronly suspect that there is more than two wake-up interrupts on these platforms, but I leave it to the maintainers to fix their mess. Signed-off-by: Marc Zyngier marc.zyng...@arm.com I tested this series on Exynos5250, using kgene/for-next and linux-next/next-20150114, but S2R failed on Exynos5250 based SMDK board. Following is the log I got on SMDK5250 board, (note I have added some debugging log to know what is happening) I can see is S3C-RTC's enable_irq_wake is failing with error -6. I also observed that even though we are adding pmu_domain_ops using irq_domain_add_hierarchy, but none of pmu_domain_ops are getting called. Please let me know if I am missing anything or do I need to modify anything to test S2R on Exynos SoC. Thanks for giving it a go. One think I noticed is that I forgot to add a #interrupt-cells = 3; to the pmu_system_controller node. Also, it would be interesting to know what is the hwirq associated with the irq_desc you've printed below. Thanks, M. - echo +10 /sys/class/rtc/rtc1/wakealarm; sleep 1; echo mem /sys/power/sta te [ 257.428163] PM: Syncing filesystems ... done. [ 257.431786] Freezing user space processes ... (elapsed 0.003 seconds) done. [ 257.439680] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 257.544451] wake enabled for irq 116 [ 257.546916] CPU: 0 PID: 1311 Comm: ash Not tainted 3.19.0-rc4-next-20150114-00023-g492ff37 #15 [ 257.555141] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 257.561231] [c0014430] (unwind_backtrace) from [c0011594] (show_stack+0x10/0x14) [ 257.568948] [c0011594] (show_stack) from [c0418b00] (dump_stack+0x84/0xc4) [ 257.576151] [c0418b00] (dump_stack) from [c005ce30] (set_irq_wake_real+0x58/0x8c) [ 257.583961] [c005ce30] (set_irq_wake_real) from [c005cef0] (irq_set_irq_wake+0x8c/0xf0) [ 257.592295] [c005cef0] (irq_set_irq_wake) from [c02e9d94] (s3c_rtc_suspend+0xb8/0xdc) [ 257.600456] [c02e9d94] (s3c_rtc_suspend) from [c0298c80] (dpm_run_callback.isra.13+0x1c/0x60) [ 257.609308] [c0298c80] (dpm_run_callback.isra.13) from [c02996a0] (__device_suspend+0x128/0x2d0) [ 257.618422] [c02996a0] (__device_suspend) from [c029a850] (dpm_suspend+0x64/0x22c) [ 257.626320] [c029a850] (dpm_suspend) from [c0058488] (suspend_devices_and_enter+0x88/0x3dc) [ 257.634999] [c0058488] (suspend_devices_and_enter) from [c00589c8] (pm_suspend+0x1ec/0x24c) [ 257.643680] [c00589c8] (pm_suspend) from [c00576e0] (state_store+0x68/0xb8) [ 257.650972] [c00576e0] (state_store) from [c012835c] (kernfs_fop_write+0xb8/0x19c) [ 257.658870] [c012835c] (kernfs_fop_write) from [c00cf620] (vfs_write+0xa0/0x1ac) [ 257.666595] [c00cf620] (vfs_write) from [c00cfc78] (SyS_write+0x44/0x9c) [ 257.673625] [c00cfc78] (SyS_write) from [c000e6e0] (ret_fast_syscall+0x0/0x30) [ 257.681176] genirq: PKD: irq_desc-name: (null): irq: 60 [ 257.686469] genirq: PKD: set_irq_wake_real: ret: -6 [ 257.691349] s3c-rtc 101e.rtc: enable_irq_wake failed: -6 [ 257.708926] PM: suspend of devices complete after 260.482 msecs [ 257.713362] BUCK9: No configuration [ 257.716840] BUCK8: No configuration [ 257.720309] BUCK7: No configuration [ 257.723776] BUCK6: No configuration [ 257.727254] P1.8V_BUCK_OUT5: No configuration [ 257.731597] LDO26: No configuration [ 257.735066] LDO25: No configuration [ 257.738532] LDO24: No configuration [ 257.742009] LDO23: No configuration [ 257.745481] LDO22: No configuration [ 257.748954] LDO21: No configuration [ 257.752419] LDO20: No configuration [ 257.755897] LDO19: No configuration [ 257.759370] LDO18: No configuration [ 257.762835] LDO17: No configuration [ 257.766314] P1.8V_LDO_OUT16: No configuration [ 257.770653] P1.0V_LDO_OUT15: No configuration [ 257.774994] P1.8V_LDO_OUT14: No configuration [ 257.779334] P1.8V_LDO_OUT13: No configuration [ 257.783668] P3.0V_LDO_OUT12: No configuration [ 257.788013] P1.8V_LDO_OUT11: No configuration [ 257.792353] P1.8V_LDO_OUT10: No configuration [ 257.796693] LDO9: No configuration [ 257.800079] P1.0V_LDO_OUT8: No configuration [ 257.804332] P1.1V_LDO_OUT7: No
[PATCH 1/1] gpio: omap: Fix bad device access with setup_irq()
Similar to omap_gpio_irq_type() let's make sure that the GPIO
is usable as an interrupt if the platform init code did not
call gpio_request(). Otherwise we can get invalid device access
after setup_irq():
WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x214/0x340()
4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in
Supervisor mode during Functional access
...
[c05f21e4] (__irq_svc) from [c05f1974]
(_raw_spin_unlock_irqrestore+0x34/0x44)
[c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8]
(__setup_irq+0x244/0x530)
[c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c)
[c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4)
[c0039c8c] (omap_system_dma_probe) from [c03b2200]
(platform_drv_probe+0x44/0xa4)
...
We can fix this the same way omap_gpio_irq_type() is handling it.
Note that the long term solution is to change the gpio-omap driver
to handle the banks as separate driver instances. This will allow
us to rely on just runtime PM for tracking the bank specific state.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Kevin Hilman khil...@kernel.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 39 +--
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 30646cf..f476ae2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -88,6 +88,8 @@ struct gpio_bank {
#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
#define LINE_USED(line, offset) (line (BIT(offset)))
+static void omap_gpio_unmask_irq(struct irq_data *d);
+
static int omap_irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
{
return bank-chip.base + gpio_irq;
@@ -477,6 +479,16 @@ static int omap_gpio_is_input(struct gpio_bank *bank, int
mask)
return readl_relaxed(reg) mask;
}
+static void omap_gpio_init_irq(struct gpio_bank *bank, unsigned gpio,
+ unsigned offset)
+{
+ if (!LINE_USED(bank-mod_usage, offset)) {
+ omap_enable_gpio_module(bank, offset);
+ omap_set_gpio_direction(bank, offset, 1);
+ }
+ bank-irq_usage |= BIT(GPIO_INDEX(bank, gpio));
+}
+
static int omap_gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
@@ -506,15 +518,11 @@ static int omap_gpio_irq_type(struct irq_data *d,
unsigned type)
spin_lock_irqsave(bank-lock, flags);
offset = GPIO_INDEX(bank, gpio);
retval = omap_set_gpio_triggering(bank, offset, type);
- if (!LINE_USED(bank-mod_usage, offset)) {
- omap_enable_gpio_module(bank, offset);
- omap_set_gpio_direction(bank, offset, 1);
- } else if (!omap_gpio_is_input(bank, BIT(offset))) {
+ omap_gpio_init_irq(bank, gpio, offset);
+ if (!omap_gpio_is_input(bank, BIT(offset))) {
spin_unlock_irqrestore(bank-lock, flags);
return -EINVAL;
}
-
- bank-irq_usage |= BIT(GPIO_INDEX(bank, gpio));
spin_unlock_irqrestore(bank-lock, flags);
if (type (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
@@ -792,6 +800,24 @@ exit:
pm_runtime_put(bank-dev);
}
+static unsigned int omap_gpio_irq_startup(struct irq_data *d)
+{
+ struct gpio_bank *bank = omap_irq_data_get_bank(d);
+ unsigned int gpio = omap_irq_to_gpio(bank, d-hwirq);
+ unsigned long flags;
+ unsigned offset = GPIO_INDEX(bank, gpio);
+
+ if (!BANK_USED(bank))
+ pm_runtime_get_sync(bank-dev);
+
+ spin_lock_irqsave(bank-lock, flags);
+ omap_gpio_init_irq(bank, gpio, offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ omap_gpio_unmask_irq(d);
+
+ return 0;
+}
+
static void omap_gpio_irq_shutdown(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
@@ -1181,6 +1207,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
if (!irqc)
return -ENOMEM;
+ irqc-irq_startup = omap_gpio_irq_startup,
irqc-irq_shutdown = omap_gpio_irq_shutdown,
irqc-irq_ack = omap_gpio_ack_irq,
irqc-irq_mask = omap_gpio_mask_irq,
--
2.1.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: Regression with legacy IRQ numbers caused by 9a1091ef0017
* Tony Lindgren t...@atomide.com [150116 09:36]: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 09:25]: On Fri, Jan 16, 2015 at 08:41:06AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 08:33]: I would still like to understand /why/ enabling preempt causes the error. Changing the preempt configuration really should not change what happens on the bus. (Think about it.) It's an indication that there is some other error present. We have a wrong irq number caused by $subject. And the wrong irq gets triggered before the dma hardware is configured during dma init. And then we get the invalid access error from omap_l3_noc. ... which should happen whether or not preempt is enabled, which is really my point. We know tha the wrong IRQ gets requested by the driver - and that wrong IRQ is requested whether or not we have preempt enabled. Yet we get the warning whether or not preempt is enabled. The DMA handler is not registered as a threaded handler, so it's not depending on a context switch to execute omap2_dma_irq_handler(). Another reason why I don't agree with your explanation is that by the time setup_irq() is called, we have already poked at the DMA hardware several times - omap_clear_dma() and omap2_disable_irq_lch() will have been called for each DMA channel - and both will write to the hardware. What's more is that the only things left after setup_irq() has been called is to possibly reserve the first two DMA channels and print the DMA message (via show_dma_caps). So I see nothing after setup_irq() which would finish any unfinished hardware initialisation. The final reason I don't agree is that I've put a printk() in omap2_dma_irq_handler(), and this does not trigger. Oh, yes that blows my theory completely then. So, I think this has nothing to do with the DMA hardware /at all/, but more to do with the GPIO code, and it suggests that the GPIO code publishes IRQs before it is safe for those IRQs to be used. Maybe it has to do with omap_gpio_irq_handler() being called... added printk(), nope, that's not called either. So it's not an IRQ which gets triggered at all. What is called are (in order): omap_gpio_unmask_irq() omap_set_gpio_irqenable() omap_enable_gpio_irqbank() and this reveals where the problem is, especially when you then add instrumentation into the runtime PM functions - and this reveals that when a GPIO IRQ is requested, these functions are called while the GPIO is runtime suspended. _That_ is where the *real* problem lies - requesting a GPIO interrupt results in the kernel touching possibly runtime-suspended hardware. The reason it happens with preempt is that preempt introduces scheduling points during the kernel boot which would not otherwise be there (with preempt disabled, you have to hit an explicit context switch due to contention on some lock or a wait in order for some other thread to run.) OK makes sense. So, the GPIO driver really needs fixing - and I'd suggest fixing it first, before fixing the DMA problem, because the DMA problem allows us to see the GPIO problem. Yes we need to fix that. Posted a minimal fix for that one as a separate thread: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq() Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq()
On Fri, Jan 16, 2015 at 02:50:50PM -0800, Tony Lindgren wrote: Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Kevin Hilman khil...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Russell King - ARM Linux li...@arm.linux.org.uk Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Tony sent me this patch privately for testing, I've boot tested with AM437x IDK, AM437x SK and BBB with CONFIG_PREEMPT. Here are the logs: http://hastebin.com/vabenibema http://hastebin.com/weyukexuzi http://hastebin.com/siceyiwite Tested-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Fri, Jan 16, 2015 at 02:52:44PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150116 09:36]: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 09:25]: So, the GPIO driver really needs fixing - and I'd suggest fixing it first, before fixing the DMA problem, because the DMA problem allows us to see the GPIO problem. Yes we need to fix that. Posted a minimal fix for that one as a separate thread: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq() Thanks, I'll throw that onto the build tree for tonights build. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/5] mfd: tps65218: make INT[12] and STATUS registers volatile
Hi, On Wed, Jan 14, 2015 at 09:07:17AM -0800, Tony Lindgren wrote: STATUS register can be modified by the HW, so we should bypass cache because of that. In the case of INT[12] registers, they are the ones that actually clear the IRQ source at the time they are read. If we rely on the cache for them, we will never be able to clear the interrupt, which will cause our IRQ line to be disabled due to IRQ throttling. Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC Cc: sta...@vger.kernel.org # v3.15+ Cc: Keerthy j-keer...@ti.com Cc: Lee Jones lee.jo...@linaro.org Signed-off-by: Felipe Balbi ba...@ti.com ping another ping. Without this and the following patch TPS65218 power button driver which was already applied by Dmitry, won't work. Anybody ? -rc4 is out and tps65218 is still broken because nobody has acted on these two patches. All other patches which are meant for 3.20 merge window are applied and because of these pending, those patches won't work. Lee, are you planning to pick these two drivers/mfd patches? Samuel, Lee, is someone planning on picking these two patches up ? v3.19 remains broken. -- balbi signature.asc Description: Digital signature
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
* Russell King - ARM Linux li...@arm.linux.org.uk [150116 15:00]: On Fri, Jan 16, 2015 at 02:52:44PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150116 09:36]: * Russell King - ARM Linux li...@arm.linux.org.uk [150116 09:25]: So, the GPIO driver really needs fixing - and I'd suggest fixing it first, before fixing the DMA problem, because the DMA problem allows us to see the GPIO problem. Yes we need to fix that. Posted a minimal fix for that one as a separate thread: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq() Thanks, I'll throw that onto the build tree for tonights build. Great thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/3] omap non-urgent fixes for v3.20
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/fixes-not-urgent-pt1 for you to fetch changes up to 13efcb188984f69e1f97b4d9e7d3663fb782946f: ARM: OMAP2+: Disable omap3 PM init for ti81xx (2015-01-14 17:37:16 -0800) Non-urgent fixes for omap variant dm816x that has been in a sorry broken half merged state for a few years now. This gets us to the point where we can boot it properly once the related SoC data is added. Note that we've already made dm816x device tree only by removing the known broken board file. Tony Lindgren (6): ARM: OMAP2+: Fix error handling for omap2_clk_enable_init_clocks ARM: OMAP2+: Fix ti81xx devtype ARM: OMAP2+: Fix ti81xx class type ARM: OMAP2+: Fix dm814 and dm816 for clocks and timer init ARM: OMAP2+: Fix reboot for 81xx ARM: OMAP2+: Disable omap3 PM init for ti81xx arch/arm/mach-omap2/Makefile| 1 + arch/arm/mach-omap2/clock.c | 3 +++ arch/arm/mach-omap2/common.h| 11 +- arch/arm/mach-omap2/control.h | 4 arch/arm/mach-omap2/id.c| 2 ++ arch/arm/mach-omap2/io.c| 26 +- arch/arm/mach-omap2/powerdomains3xxx_data.c | 2 +- arch/arm/mach-omap2/prm_common.c| 4 arch/arm/mach-omap2/soc.h | 4 ++-- arch/arm/mach-omap2/ti81xx-restart.c| 34 + arch/arm/mach-omap2/timer.c | 2 ++ 11 files changed, 84 insertions(+), 9 deletions(-) create mode 100644 arch/arm/mach-omap2/ti81xx-restart.c -- 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
[GIT PULL 3/3] omap device tree changes for v3.20
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/dt-pt1 for you to fetch changes up to 7300bfff886a1340cfeb252035303e265cd556d9: ARM: dts: omap3-gta04: Add handling for tv output (2015-01-13 08:02:21 -0800) Device tree changes for omaps. Mostly to add support for new am437x-idk and update am437x-sk boards. Also enabling new devices for multiple boards. Aaro Koskinen (1): ARM: dts: N950/N9: add twl_power Benoit Parrot (3): ARM: dts: am4372: add VPFE DT node entries ARM: dts: am43x-epos-evm: add VPFE device tree data ARM: dts: am437x-gp-evm: add VPFE device tree data Darren Etheridge (1): ARM: dts: am437x-sk-evm: add VPFE device tree data Dave Gerlach (1): ARM: dts: am437x-sk-evm: Hook dcdc2 as the cpu0-supply Dmitry Lifshitz (1): ARM: dts: cm-t3x: add NAND support Felipe Balbi (10): ARM: dts: am437x-sk: remove internal pulls from QSPI ARM: dts: am437x-sk: add explicit MMC0 pinmux ARM: dts: am437x-sk: remove ethernet pulls ARM: dts: am437x-sk: add explicit pinmux for both USB instances ARM: dts: am437x-sk: remove internal i2c pullups ARM: dts: am437x-sk: remove DSS pulls ARM: dts: am57xx-beagle-x15: Add dual ethernet ARM: dts: add support for AM437x IDK ARM: dts: am437x-sk: add power button binding ARM: dts: am437x-idk: add gpio-based power key Marek Belisko (1): ARM: dts: omap3-gta04: Add handling for tv output Nishanth Menon (1): ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node Pavel Machek (1): ARM: dts: omap3-n900: cleanup english Vignesh R (1): ARM: dts: DRA7X: drop id property in pcie_phy arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/am4372.dtsi | 16 ++ arch/arm/boot/dts/am437x-gp-evm.dts | 106 + arch/arm/boot/dts/am437x-idk-evm.dts| 405 arch/arm/boot/dts/am437x-sk-evm.dts | 217 - arch/arm/boot/dts/am43x-epos-evm.dts| 53 + arch/arm/boot/dts/am57xx-beagle-x15.dts | 120 ++ arch/arm/boot/dts/dra7.dtsi | 2 - arch/arm/boot/dts/omap3-cm-t3x.dtsi | 58 + arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 3 +- arch/arm/boot/dts/omap3-gta04.dtsi | 49 arch/arm/boot/dts/omap3-n900.dts| 3 +- arch/arm/boot/dts/omap3-n950-n9.dtsi| 5 + arch/arm/boot/dts/omap3-sbc-t3517.dts | 4 + arch/arm/boot/dts/omap3-sbc-t3530.dts | 10 +- arch/arm/boot/dts/omap3-sbc-t3730.dts | 5 +- 16 files changed, 979 insertions(+), 78 deletions(-) create mode 100644 arch/arm/boot/dts/am437x-idk-evm.dts -- 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
[GIT PULL 2/3] omap clean-up for v3.20
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/cleanup-pt1 for you to fetch changes up to ca662ee7b8a85c54c1cb9ef34b7c6b4f67933a7e: ARM: OMAP2+: Remove unused ti81xx platform init code (2015-01-14 17:21:00 -0800) Clean-up for omaps to remove dead code found with cppcheck after we've made several SoCs to boot in device tree only mode. Rickard Strandqvist (10): ARM: OMAP2+: clkt2xxx_apll.c: Remove some unused functions ARM: OMAP2+: cm33xx.c: Remove some unused functions ARM: OMAP2+: dpll44xx.c: Remove unused function ARM: OMAP2+: omap_hwmod.c: Remove some unused functions ARM: OMAP2+: powerdomain.c: Remove some unused functions ARM: OMAP2+: voltage: Remove some unused functions ARM: OMAP2+: omap-pm-noop.c: Remove some unused functions ARM: OMAP1: irq.c: Remove unused function ARM: OMAP1: timer32k.c: Remove unused function ARM: OMAP: dma.c: Remove unused function Tero Kristo (3): ARM: OMAP2: clock: remove unused apll code ARM: OMAP2: CM: remove unused PLL functions ARM: OMAP3+: PRM: remove prm_get_reset_sources declaration from headers Tony Lindgren (1): ARM: OMAP2+: Remove unused ti81xx platform init code arch/arm/mach-omap1/irq.c | 5 - arch/arm/mach-omap1/timer32k.c | 5 - arch/arm/mach-omap2/Makefile| 1 - arch/arm/mach-omap2/cclock3xxx_data.c | 6 +- arch/arm/mach-omap2/clkt2xxx_apll.c | 142 --- arch/arm/mach-omap2/clock.h | 1 - arch/arm/mach-omap2/clock2xxx.h | 11 -- arch/arm/mach-omap2/cm2xxx.c| 10 -- arch/arm/mach-omap2/cm2xxx.h| 2 - arch/arm/mach-omap2/cm33xx.c| 21 --- arch/arm/mach-omap2/dpll44xx.c | 20 --- arch/arm/mach-omap2/omap-pm-noop.c | 196 --- arch/arm/mach-omap2/omap-pm.h | 192 -- arch/arm/mach-omap2/omap_hwmod.c| 232 arch/arm/mach-omap2/omap_hwmod.h| 16 --- arch/arm/mach-omap2/omap_phy_internal.c | 35 - arch/arm/mach-omap2/powerdomain.c | 82 --- arch/arm/mach-omap2/powerdomain.h | 5 - arch/arm/mach-omap2/prm3xxx.h | 1 - arch/arm/mach-omap2/prm44xx_54xx.h | 1 - arch/arm/mach-omap2/usb-musb.c | 12 +- arch/arm/mach-omap2/usb.h | 2 - arch/arm/mach-omap2/voltage.c | 110 --- arch/arm/mach-omap2/voltage.h | 13 -- arch/arm/plat-omap/dma.c| 8 -- 25 files changed, 3 insertions(+), 1126 deletions(-) delete mode 100644 arch/arm/mach-omap2/clkt2xxx_apll.c -- 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 bad device access with setup_irq()
On 1/16/2015 2:50 PM, Tony Lindgren wrote: Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): I let Linus W comment on it but IIRC we chewed this issue last time and the conclusion was the gpio_request() must have to be called directly or indirectly in case of irq line. One old thread on possibly similar issue is here[1] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Kevin Hilman khil...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Russell King - ARM Linux li...@arm.linux.org.uk Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/gpio/gpio-omap.c | 39 +-- 1 file changed, 33 insertions(+), 6 deletions(-) Is it really OMAP specific issue ? On OMAP, clocks needs to enabled for GPIO's to work which is what the init is doing but I believe the same should apply to other GPIO controllers as well. regards, Santosh [1] https://lkml.org/lkml/2013/8/27/509 -- 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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
Mark, On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland mark.rutl...@arm.com wrote: The hwlock is a basic hardware primitive that allow synchronization between different processors in the system, which may be running Linux as well as other operating systems, and may have no other means of communication. The hwlock id numbers are predefined, global and static across the entire system: Linux may boot well after other operating systems are already running and using these hwlocks to communicate, and therefore, in order to use these hardware devices, it must not enumerate them differently than the rest of the system. That's not true. In order to communicate it must agree with the other users as to the meaning of each instance, and the protocol for use. That doesn't necessarily mean that Linux needs to know the numerical ID from a datasheet, and regardless that ID is separate from the logical ID Linux uses internally. Let me describe hwspinlocks a bit more so we all get to know it better and can then agree on a proper solution. - What makes handling of hwspinlock ID numbers convenient is the fact that it's not based on random datasheet numbers. In fact, hwspinlocks is just special memory: usually datasheets just define the base address and the size of the hwspinlock area. So any numerical ID we use to call the locks themselves are already logical and sane, similar to the way we handle memory (i.e. if we have 32 locks we'll always use 0..31). So hwlocks ids are very much like memory addressing, and not irq numbers. - Sometimes Linux will have to dynamically allocate a hwlock, and send the ID of the allocated lock to a remote processor (which may not be running Linux). - Sometimes a remote processor, which may not be running Linux, will have to dynamically allocate a hwlock, and send the ID of the allocated lock to us (another processor running Linux) We cannot tell in advance what kind of IPC is going to be used for sending and receiving this hwlock ID. Some are handled by Linux (kernel) and some by the user space. So we must be able to expose an ID the system will understand as well as receive one. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression with legacy IRQ numbers caused by 9a1091ef0017
On Fri, Jan 16, 2015 at 05:23:05PM +, Marc Zyngier wrote: On 16/01/15 16:56, Arnd Bergmann wrote: On Thursday 15 January 2015 07:37:48 Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:46]: On Thu, Jan 15 2015 at 2:27:56 pm GMT, Arnd Bergmann a...@arndb.de wrote: On Thursday 15 January 2015 13:42:57 Marc Zyngier wrote: Probably there is a workable strategy, but my knowledge about OMAP is close to *nothing*... I have a feeling this might bite other platforms too and we just have not noticed it yet.. I'm looking through the entire tree now, scanning for machines that have GIC and use IORESOURCE_IRQ or DEFINE_RES_IRQ in their platform code. Most platforms using GIC are completely converted to DT and have no hardcoded legacy IRQs. I have checked that cns3xxx and realview are both fine by inspection. The only one I'm not sure about is shmobile, which looks like it might suffer from the same problem. Simon/Magnus, could you verify this with a multiplatform kernel on any SoC that has GIC and uses devices that have interrupts defined in setup-*.c or board-*.c? There are 3 patches floating around for shmobile, converting their non-DT support to directly initializing the GIC instead of relying on irqchip_init(). There is also a fourth patch pending to fix one last SoC, the r8a73a4. My understanding is that should be the end of the problems that we have been seeing in this area. That's assuming their DT implementation doesn't use any of these device declarations. I believe that assumption is correct. shmobile does not use any devices that have interrupts defined in setup-*.c or board-*.c when booting using multiplatform. If they do, we could use a hack similar to the one I implemented for OMAP, populating the virtual IRQ in the resource at boot time, just after the irqchip initialization. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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 RESEND v8 1/2] clk: Make clk API return per-user struct clk instances
On 01/12, Tomeu Vizoso wrote:
Moves clock state to struct clk_core, but takes care to change as little API
as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their
clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
Looks mostly good. Missing some NULL checks mostly.
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f4963b7..7eddfd8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -114,7 +123,7 @@ static struct hlist_head *orphan_list[] = {
+static void clk_summary_show_one(struct seq_file *s, struct clk_core *c, int
level)
{
if (!c)
return;
@@ -122,14 +131,14 @@ static void clk_summary_show_one(struct seq_file *s,
struct clk *c, int level)
[...]
-static void clk_summary_show_subtree(struct seq_file *s, struct clk *c,
+static void clk_summary_show_subtree(struct seq_file *s, struct clk_core *c,
int level)
{
- struct clk *child;
+ struct clk_core *child;
if (!c)
return;
@@ -172,7 +181,7 @@ static const struct file_operations clk_summary_fops = {
.release= single_release,
};
-static void clk_dump_one(struct seq_file *s, struct clk *c, int level)
+static void clk_dump_one(struct seq_file *s, struct clk_core *c, int level)
{
if (!c)
return;
@@ -180,14 +189,14 @@ static void clk_dump_one(struct seq_file *s, struct clk
*c, int level)
[...]
-static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
+static void clk_dump_subtree(struct seq_file *s, struct clk_core *c, int
level)
{
- struct clk *child;
+ struct clk_core *child;
if (!c)
return;
@@ -418,19 +427,20 @@ static int __init clk_debug_init(void)
[...]
/* caller must hold prepare_lock */
-static void clk_unprepare_unused_subtree(struct clk *clk)
+static void clk_unprepare_unused_subtree(struct clk_core *clk)
{
- struct clk *child;
+ struct clk_core *child;
if (!clk)
return;
@@ -453,9 +463,9 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
}
/* caller must hold prepare_lock */
-static void clk_disable_unused_subtree(struct clk *clk)
+static void clk_disable_unused_subtree(struct clk_core *clk)
{
- struct clk *child;
+ struct clk_core *child;
unsigned long flags;
if (!clk)
Note: These NULL checks look bogus. No need to fix them here, but
a patch to remove them would be nice.
@@ -532,48 +542,59 @@ late_initcall_sync(clk_disable_unused);
[...]
+
+struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
+{
+ struct clk_core *parent;
+
+ parent = clk_core_get_parent_by_index(clk-core, index);
I suppose clk could be NULL here (although this is mostly a
clk-provider function). At least before we would return NULL in
such a case so we should keep the same behavior instead of NULL
deref.
+
+ return !parent ? NULL : parent-hw-clk;
+}
EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
@@ -593,9 +614,14 @@ unsigned long __clk_get_rate(struct clk *clk)
out:
return ret;
}
+
+unsigned long __clk_get_rate(struct clk *clk)
+{
+ return clk_core_get_rate_nolock(clk-core);
Oops. clk can be NULL here. We should check for that and return
0.
+}
EXPORT_SYMBOL_GPL(__clk_get_rate);
@@ -630,7 +656,12 @@ out:
return !!ret;
}
-bool __clk_is_enabled(struct clk *clk)
+bool __clk_is_prepared(struct clk *clk)
+{
+ return clk_core_is_prepared(clk-core);
Oops. clk can be NULL here. Return false if so. Or drop the
function entirely? It looks like it may become unused.
+}
@@ -650,12 +681,17 @@ bool __clk_is_enabled(struct clk *clk)
out:
return !!ret;
}
+
+bool __clk_is_enabled(struct clk *clk)
+{
+ return clk_core_is_enabled(clk-core);
Oops. clk can be NULL here. Return false if so.
+}
EXPORT_SYMBOL_GPL(__clk_is_enabled);
@@ -762,7 +805,12 @@ void __clk_unprepare(struct clk *clk)
if (clk-ops-unprepare)
clk-ops-unprepare(clk-hw);
- __clk_unprepare(clk-parent);
+ clk_core_unprepare(clk-parent);
+}
+
+void __clk_unprepare(struct clk *clk)
+{
+ clk_core_unprepare(clk-core);
OOps. clk can be NULL here. Bail early if so.
}
/**
@@ -813,6 +861,11 @@ int __clk_prepare(struct clk *clk)
return 0;
}
+int __clk_prepare(struct clk *clk)
+{
+ return clk_core_prepare(clk-core);
Oops. clk can be NULL here. Return 0 if so.
+}
+
@@ -851,7 +904,12 @@
Re: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq()
* santosh shilimkar santosh.shilim...@oracle.com [150116 16:23]: On 1/16/2015 2:50 PM, Tony Lindgren wrote: Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): I let Linus W comment on it but IIRC we chewed this issue last time and the conclusion was the gpio_request() must have to be called directly or indirectly in case of irq line. This is a corner case where the error is triggered by a wrong, non-GPIO IRQ so gpio_request() will never be called before setup_irq() unlike for any legacy platform code. The legacy and DT cases we're already handling in the gpio-omap.c driver a while back with: 2f56e0a57ff1 (gpio/omap: use gpiolib API to mark a GPIO used as an IRQ) fac7fa162a19 (gpio/omap: auto-setup a GPIO when used as an IRQ) fa365e4d7290 (gpio/omap: maintain GPIO and IRQ usage separately) And most of that the bank specific hacks we can get rid of by making the driver multple instances as that allows replacing BANK_USED with just runtime PM. One old thread on possibly similar issue is here[1] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Kevin Hilman khil...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Russell King - ARM Linux li...@arm.linux.org.uk Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/gpio/gpio-omap.c | 39 +-- 1 file changed, 33 insertions(+), 6 deletions(-) Is it really OMAP specific issue ? On OMAP, clocks needs to enabled for GPIO's to work which is what the init is doing but I believe the same should apply to other GPIO controllers as well. In the long run it should be handled by the generic GPIO code IMO. I doubt that's doable for the -rc series though. Probably only a few platforms have hit PM related issues like this. And actually the omap specific hacks become really minimal if we make the driver have a separate instance for each GPIO bank. Regards, Tony [1] https://lkml.org/lkml/2013/8/27/509 -- 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 RESEND v8 2/2] clk: Add floor and ceiling constraints to clock rates
On 01/12, Tomeu Vizoso wrote:
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7eddfd8..2793bd7 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1013,8 +1015,8 @@ static unsigned long clk_core_round_rate_nolock(struct
clk_core *clk,
if (clk-ops-determine_rate) {
parent_hw = parent ? parent-hw : NULL;
- return clk-ops-determine_rate(clk-hw, rate, parent_rate,
- parent_hw);
+ return clk-ops-determine_rate(clk-hw, rate, 0, ULONG_MAX,
+ parent_rate, parent_hw);
} else if (clk-ops-round_rate)
return clk-ops-round_rate(clk-hw, rate, parent_rate);
else if (clk-flags CLK_SET_RATE_PARENT)
@@ -1453,8 +1458,20 @@ static struct clk_core *clk_calc_new_rates(struct
clk_core *clk,
/* find the closest rate and parent clk/rate */
if (clk-ops-determine_rate) {
+ hlist_for_each_entry(clk_user, clk-clks, child_node) {
+ floor_rate = max(floor_rate,
+ clk_user-floor_constraint);
+ }
+
+ hlist_for_each_entry(clk_user, clk-clks, child_node) {
+ ceiling_rate = min(ceiling_rate,
+clk_user-ceiling_constraint);
+ }
I would think we need to do this in the clk_round_rate() path as
well. We can't just pass 0 and ULONG_MAX there or we'll determine
one rate here and another rate in round_rate(), violating the
contract between set_rate() and round_rate().
+
parent_hw = parent ? parent-hw : NULL;
new_rate = clk-ops-determine_rate(clk-hw, rate,
+ floor_rate,
+ ceiling_rate,
best_parent_rate,
parent_hw);
parent = parent_hw ? parent_hw-core : NULL;
We should enforce a constraint if the clk is using the
round_rate() op too. If the .round_rate() op returns some rate
within range it should be ok. Otherwise we can fail the rate
change because it's out of range.
We'll also need to introduce some sort of
clk_core_determine_rate(core, rate, min, max) so that clock
providers can ask parent clocks to find a rate within some range
that they can tolerate. If we update __clk_mux_determine_rate()
we can see how that would work out.
@@ -1660,13 +1657,92 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
[...]
+ */
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ return clk_core_set_rate(clk-core, rate);
clk could be NULL.
+}
EXPORT_SYMBOL_GPL(clk_set_rate);
+int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max)
+{
+ int ret = 0;
Check for NULL clk.
+
+/**
+ * clk_set_floor_rate - set a minimum clock rate for a clock source
+ * @clk: clock source
+ * @rate: desired minimum clock rate in Hz
+ *
+ * Returns success (0) or negative errno.
+ */
+int clk_set_floor_rate(struct clk *clk, unsigned long rate)
+{
+ return clk_set_rate_range(clk, rate, clk-ceiling_constraint);
clk could be NULL.
+}
+EXPORT_SYMBOL_GPL(clk_set_floor_rate);
+
+/**
+ * clk_set_ceiling_rate - set a maximum clock rate for a clock source
+ * @clk: clock source
+ * @rate: desired maximum clock rate in Hz
+ *
+ * Returns success (0) or negative errno.
+ */
+int clk_set_ceiling_rate(struct clk *clk, unsigned long rate)
+{
+ return clk_set_rate_range(clk, clk-floor_constraint, rate);
clk could be NULL.
+}
+EXPORT_SYMBOL_GPL(clk_set_ceiling_rate);
+
static struct clk_core *clk_core_get_parent(struct clk_core *core)
{
struct clk_core *parent;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 2e65419..ae5c800 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -175,9 +175,12 @@ struct clk_ops {
unsigned long parent_rate);
long(*round_rate)(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
- long(*determine_rate)(struct clk_hw *hw, unsigned long rate,
- unsigned long *best_parent_rate,
- struct clk_hw **best_parent_hw);
+ long(*determine_rate)(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long floor_rate,
+ unsigned long ceiling_rate,
I wonder if we should call this min_rate and max_rate?
+ unsigned long *best_parent_rate,
+ struct clk_hw **best_parent_hw);
int
