Re: [PATCH 0/2] pci: am57xx-evm: Fix PCIe card enumeration issue
On Tue, Jul 28, 2015 at 07:09:08PM +0530, Kishon Vijay Abraham I wrote: This series fixes PCIe card enumeration issue in am57xx-evm. In the case of am57xx-evm, the PERST# line is connected to a gpio line and this has to be driven low in order to perform a fundamental reset of the card. If the gpio line is driven high, there is no way the card can come out of reset. Add support in the pcie-dra7xx driver to make gpio drive PERST# line. The PERST# line can be used to perform reset not during the power on sequence too (warm reset) but we are not adding support for this as the PCIe express base sepcification doesn't explain how to perform warm reset In some cases, it may be possible for the Fundamental Reset mechanism to be triggered by hardware without the removal and re-application of power to the component. This is called a warm reset. This document does not specify a means for generating a warm reset. Kishon Vijay Abraham I (2): pci: host: pci-dra7xx: Add support to make gpio drive PERST# line ARM: dts: am57xx-evm: Add 'gpios' property with gpio2_8 Documentation/devicetree/bindings/pci/ti-pci.txt |3 +++ arch/arm/boot/dts/am57xx-beagle-x15.dts |5 + arch/arm/boot/dts/dra7.dtsi |2 +- drivers/pci/host/pci-dra7xx.c| 24 -- 4 files changed, 31 insertions(+), 3 deletions(-) Applied with Tony's ack (for patch 2) to pci/host-dra7xx for v4.3, thanks! -- 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 v5 0/3] dra7xx: Add PM support to PCIe
On Fri, Jul 31, 2015 at 05:55:09PM +0530, Kishon Vijay Abraham I wrote: This series adds PM support to pci-dra7xx so that PCI clocks can be disabled during suspend and enabled back during resume without affecting PCI functionality. Changes from v4: *) Fixed a bug caused by sending incomplete patch. Changes from v3: *) Fix compilation errors when individual patches are applied Changes from v2: *) Used SET_SYSTEM_SLEEP_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS for populating PM ops. Changes from v1: *) Moved resetting and setting of MSE bit to pci-dra7xx. The comment to reset and set ISE is not done now since I don't have a card with IO space. Once I get to test that, I'll post a separate patch for handling that. Kishon Vijay Abraham I (3): PCI: host: pci-dra7xx: Disable pm_runtime on get_sync failure PCI: host: pci-dra7xx: add pm support to pci dra7xx PCI: host: pci-dra7xx: Idle the module by disabling MSE bit drivers/pci/host/pci-dra7xx.c | 95 - 1 file changed, 94 insertions(+), 1 deletion(-) Applied with Jingoo's Reviewed-by to pci/host-dra7xx for v4.3, thanks! I tweaked the changelogs as follows: commit 0e2bdb0e7abf4b5170874e415ec42df547916dd3 Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jul 31 17:55:10 2015 +0530 PCI: dra7xx: Disable pm_runtime on get_sync failure Fix the error handling when pm_runtime_get_sync() fails. If pm_runtime_get_sync() fails, call pm_runtime_disable() so there are no unbalanced pm_runtime_enable() calls. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Reviewed-by: Jingoo Han jingooh...@gmail.com commit e52eb445ea1d97bf7fb92d2297e487a305392136 Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jul 31 17:55:11 2015 +0530 PCI: dra7xx: Add PM support Add PM support to pci-dra7xx so PCI clocks can be disabled during suspend and enabled during resume without affecting PCI functionality. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Reviewed-by: Jingoo Han jingooh...@gmail.com commit 389c7094ec241ee8ebe358ba10fe392018692c8c Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jul 31 17:55:12 2015 +0530 PCI: dra7xx: Clear MSE bit during suspend so clocks will idle DRA7xx requires the MSE bit to be cleared to set the master in standby mode. (In DRA7xx TRM_vE, section 24.9.4.5.2.2.1 PCIe Controller Master Standby Behavior advises to use the clearing of the local MSE bit to set the master in standby. Without this some of the clocks do not idle). Clear the MSE bit on suspend and enable it on resume. Clearing MSE bit is required to get clocks to be idled after suspend. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Reviewed-by: Jingoo Han jingooh...@gmail.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] ARM: dts: am335x-phycore-som: Move NAND partition table into board files
Hello Matthias,
Am Freitag, den 07.08.2015, 11:09 +0200 schrieb Matthias Klein:
Partitions which are defined in the som file can not be deleted in the
board file.
Signed-off-by: Matthias Klein matthias.kl...@optimeas.de
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 37 -
arch/arm/boot/dts/am335x-wega.dtsi| 45
+++
2 files changed, 45 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 4d28fc3..8f12bd54 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -189,43 +189,6 @@
#address-cells = 1;
#size-cells = 1;
-
- partition@0 {
- label = xload;
- reg = 0x0 0x2;
- };
- partition@1 {
- label = xload_backup1;
- reg = 0x2 0x2;
- };
- partition@2 {
- label = xload_backup2;
- reg = 0x4 0x2;
- };
- partition@3 {
- label = xload_backup3;
- reg = 0x6 0x2;
- };
- partition@4 {
- label = barebox;
- reg = 0x8 0x8;
- };
- partition@5 {
- label = bareboxenv;
- reg = 0x10 0x4;
- };
- partition@6 {
- label = oftree;
- reg = 0x14 0x4;
- };
- partition@7 {
- label = kernel;
- reg = 0x18 0x80;
- };
- partition@8 {
- label = root;
- reg = 0x98 0x0;
- };
};
};
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi
b/arch/arm/boot/dts/am335x-wega.dtsi
index 5e541bd..945a41d 100644
--- a/arch/arm/boot/dts/am335x-wega.dtsi
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -149,3 +149,48 @@
usb1_phy {
status = okay;
};
I don't think that moving the nand partition to the carrier board dtsi is
correct.
The nand partition does not have anything to do with the carrier board in first
place.
So they should rather be moved to the am335x-wega-rdk.dts which does describe
the
board in a whole.
If you do this, you should remove the spi partitions from the SoM dtsi also.
And it is generally possible to delete nodes from a device tree with
/delete-node/ my_node;
But I have actually not tested this when overwriting partitions. Neither know
if this whould
be a sane solution.
Regards
Teresa
+
+nandflash {
+ partition@0 {
+ label = xload;
+ reg = 0x0 0x2;
+ };
+
+ partition@1 {
+ label = xload_backup1;
+ reg = 0x2 0x2;
+ };
+
+ partition@2 {
+ label = xload_backup2;
+ reg = 0x4 0x2;
+ };
+
+ partition@3 {
+ label = xload_backup3;
+ reg = 0x6 0x2;
+ };
+
+ partition@4 {
+ label = barebox;
+ reg = 0x8 0x8;
+ };
+
+ partition@5 {
+ label = bareboxenv;
+ reg = 0x10 0x4;
+ };
+
+ partition@6 {
+ label = oftree;
+ reg = 0x14 0x4;
+ };
+ partition@7 {
+ label = kernel;
+ reg = 0x18 0x80;
+ };
+ partition@8 {
+ label = root;
+ reg = 0x98 0x0;
+ };
+};
--
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/3] tty: serial: 8250_omap: do not use RX DMA if pause is not supported
On Sat, Aug 08, 2015 at 10:03:43AM +0100, Russell King - ARM Linux wrote: On Fri, Aug 07, 2015 at 08:28:57PM -0400, Peter Hurley wrote: Even dma_get_slave_caps() returns _true_ for cmd_pause support; ok, that interface is pointless. How about reporting that as a bug then, because if you look back in the git history, as you are fully capable of, you will find that the slave capability stuff went in _after_ omap-dma, and *many* DMA engine drivers have not been updated. Here, let me do _your_ work for you: commit cb8cea513c80db1dfe2dce468d2d0772005bb9a1 Author: Maxime Ripard maxime.rip...@free-electrons.com Date: Mon Nov 17 14:42:04 2014 +0100 dmaengine: Create a generic dma_slave_caps callback commit 2dcdf570936168d488acf90be9b04a3d32dafce7 Author: Peter Ujfalusi peter.ujfal...@ti.com Date: Fri Sep 14 15:05:45 2012 +0300 dmaengine: omap: Add support for pause/resume in cyclic dma mode Oh look, omap-dma pre-dates the creation of dma_slave_caps by over two years! However, it's *not* as trivial as you think: the dma_slave_caps() call has no knowledge whether a channel will be used in cyclic mode or not, or which direction it will be used. So, it really _can't_ report whether pause mode is supported or not. So actually, this is something that can't be fixed trivially, and was a detail missed when the slave caps was reviewed (I probably missed the review or missed the point.) The API queries the capabilities for a channel. So a channel has been allocated. BUT it would not imply the direction as that is descriptor based, so should we query the capabilities for a descriptor and use those in clients ? Also the current dma_slave_caps() has been moved to framework and reports based on driver callbacks. Now we have a hardware which supports pause for one direction only so we should model it bit differently Thoughts... ?? -- ~Vinod -- 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] ARM: OMAP: irqdomain_hierarchy: fix arm gic irq type configuration
It's observed that ARM GIC IRQ triggering type is not configured
properly when IRQ is routed through IRQ domains hierarchy and
system started using DT. As result, system will start using default
ARM GIC configuration, ignore DT IRQ type configuration,
and value of desc-irq_data.state_use_accessors = 0.
In case of TI OMAP the following IRQ hierarchy is defined:
ARM GIC - OMAP wakeupgen - TI CBAR
Failed call chain:
irq_create_of_mapping
irq_set_irq_type
__irq_set_trigger
if (!chip || !chip-irq_set_type) {
return 0; - return here
}
CBAR has no .irq_set_type() defined and, so, IRQ triggering
configuration will not be propagated to parent IRQ domain.
Hence, fix it by introducing irq_chip_set_type_parent(), in the
same manner as irq_chip_set_wake_parent(), and use it for IRQ
triggering type propagation to the parent IRQ domain in
irq-crossbar and omap-wakeupgen.
/ # cat /proc/interrupts -- before
230: 0 0 CBAR 30 Edge- 48051000.gpio
263: 0 0 CBAR 116 Edge- 48053000.gpio
296:246 0 CBAR 67 Edge- OMAP UART0
311:341 0 CBAR 51 Edge- 4807.i2c
312: 3 0 CBAR 52 Edge- 48072000.i2c
313: 0 0 CBAR 56 Edge- 4806.i2c
314:255 0 CBAR 78 Edge- mmc0
315: 40 0 CBAR 81 Edge- mmc1
316: 13 0 CBAR 91 Edge- mmc2
320: 0 0 CBAR 49 Edge- 4a14.sata
324: 0 0 CBAR 1 Edge- 48078000.elm
325: 0 0 CBAR 15 Edge- gpmc
333: 0 0 CBAR 335 Edge- 48484000.ethernet
334: 0 0 CBAR 336 Edge- 48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 0 0 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.seria
/ # cat /proc/interrupts -- after
230: 0 0 CBAR 30 Level -2004 48051000.gpio
263: 0 0 CBAR 116 Level -2004 48053000.gpio
296:567 0 CBAR 67 Level -2004 OMAP UART0
311:363 0 CBAR 51 Level -2004 4807.i2c
312: 3 0 CBAR 52 Level -2004 48072000.i2c
313: 0 0 CBAR 56 Level -2004 4806.i2c
314:197 0 CBAR 78 Level -2004 mmc0
315: 40 0 CBAR 81 Level -2004 mmc1
316: 13 0 CBAR 91 Level -2004 mmc2
320: 0 0 CBAR 49 Level -2004 4a14.sata
324: 0 0 CBAR 1 Level -2004 48078000.elm
325: 0 0 CBAR 15 Level -2004 gpmc
333: 0 0 CBAR 335 Level -2004 48484000.ethernet
334: 0 0 CBAR 336 Level -2004 48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 4 2 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.serial
Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar to stacked
domains')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Hi All,
I can split patch if required and overall solution acceptable.
arch/arm/mach-omap2/omap-wakeupgen.c | 1 +
drivers/irqchip/irq-crossbar.c | 1 +
include/linux/irq.h | 1 +
kernel/irq/chip.c| 16
4 files changed, 19 insertions(+)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index 8e52621..e1d2e99 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -392,6 +392,7 @@ static struct irq_chip wakeupgen_chip = {
.irq_mask = wakeupgen_mask,
.irq_unmask = wakeupgen_unmask,
.irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_set_type = irq_chip_set_type_parent,
.flags = IRQCHIP_SKIP_SET_WAKE |
IRQCHIP_MASK_ON_SUSPEND,
#ifdef CONFIG_SMP
.irq_set_affinity = irq_chip_set_affinity_parent,
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 692fe2b..3ba58e7 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -69,6 +69,7 @@ static struct irq_chip crossbar_chip = {
.irq_unmask = irq_chip_unmask_parent,
.irq_retrigger = irq_chip_retrigger_hierarchy,
.irq_set_wake = irq_chip_set_wake_parent,
+ .irq_set_type = irq_chip_set_type_parent,
#ifdef CONFIG_SMP
Re: [PATCH 2/3] dma: add __must_check annotation for dmaengine_pause()
On Tue, Aug 11, 2015 at 03:28:52PM +0530, Vinod Koul wrote:
On Fri, Aug 07, 2015 at 10:00:18PM +0200, Sebastian Andrzej Siewior wrote:
In 8250-omap I learned it the hard way that ignoring the return code
of dmaengine_pause() might be bad because the underlying DMA driver
might not support the function at all and so not doing what one is
expecting.
This patch adds the __must_check annotation as suggested by Russell King.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
include/linux/dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8ad9a4e839f6..4eac4716bded 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -825,7 +825,7 @@ static inline int dmaengine_terminate_all(struct
dma_chan *chan)
return -ENOSYS;
}
-static inline int dmaengine_pause(struct dma_chan *chan)
+static inline int __must_check dmaengine_pause(struct dma_chan *chan)
{
if (chan-device-device_pause)
return chan-device-device_pause(chan);
Give that there are bunch of users of this call which may or maynot be using
this, I think putting this check is too stringent
I think what people need to learn is that an API in the kernel which
returns an int _can_ fail - it returns an int so it _can_ return an
error code. If it _can_ return an error code, there _will_ be
implementations which _do_.
If you don't check the return code, either your code doesn't care whether
the function was successful or not, or you're playing with fire. This is
a prime example of playing with fire.
Let's leave the crappy userspace laziness with regard to error checking
to userspace, and keep it out of the kernel.
Yes, the DMA engine capabilities may not be sufficient to describe every
detail of DMA engines, but that's absolutely no reason to skimp on error
checking. Had there been some kind of error checking at the site, this
problem would have been spotted before the 8250-omap driver was merged.
--
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 2/3] dma: add __must_check annotation for dmaengine_pause()
On Fri, Aug 07, 2015 at 10:00:18PM +0200, Sebastian Andrzej Siewior wrote:
In 8250-omap I learned it the hard way that ignoring the return code
of dmaengine_pause() might be bad because the underlying DMA driver
might not support the function at all and so not doing what one is
expecting.
This patch adds the __must_check annotation as suggested by Russell King.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
include/linux/dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8ad9a4e839f6..4eac4716bded 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -825,7 +825,7 @@ static inline int dmaengine_terminate_all(struct dma_chan
*chan)
return -ENOSYS;
}
-static inline int dmaengine_pause(struct dma_chan *chan)
+static inline int __must_check dmaengine_pause(struct dma_chan *chan)
{
if (chan-device-device_pause)
return chan-device-device_pause(chan);
Give that there are bunch of users of this call which may or maynot be using
this, I think putting this check is too stringent
--
~Vinod
--
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 00/22] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros rog...@ti.com [150807 02:15]: Hi, We do a couple of things in this series which result in cleaner device tree implementation, faster perfomance and multi-platform support. As an added bonus we get new GPI/Interrupt pins for use in the system. - Establish a custom interface between NAND and GPMC driver. This is needed because all of the NAND registers sit in the GPMC register space. Some bits like NAND IRQ are even shared with GPMC. - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ with the omap2-nand driver and handle NAND IRQ events in the NAND driver. This causes performance increase when using prefetch-irq mode. 30% increase in read, 17% increase in write in prefetch-irq mode. - Clean up device tree support so that omap-gpmc IP and the omap2 NAND driver can be used on non-OMAP platforms. e.g. Keystone. - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain 2 to 4 of these and most of them would be unused otherwise. It also allows a cleaner implementation of NAND Ready pin status for the NAND driver. - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver. Nice job :) Using GPIOCHIP + IRQCHIP allows us to make the GPMC using drivers pretty much generic eventually. NOTE: I've only adapted dra7.dtsi and dra7x-evms for this series. I will adapt all other boards when the series is in a shape to be accepted. OK. Yeah let's make sure no regressions are caused by this.. We also still have the omap3 legacy booting around, have you checked that it keeps on working? 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] ARM: OMAP: irqdomain_hierarchy: fix arm gic irq type configuration
On Tue, 11 Aug 2015 10:25:47 +0100
Grygorii Strashko grygorii.stras...@ti.com wrote:
Hi Grygorii,
It's observed that ARM GIC IRQ triggering type is not configured
properly when IRQ is routed through IRQ domains hierarchy and
system started using DT. As result, system will start using default
ARM GIC configuration, ignore DT IRQ type configuration,
and value of desc-irq_data.state_use_accessors = 0.
In case of TI OMAP the following IRQ hierarchy is defined:
ARM GIC - OMAP wakeupgen - TI CBAR
Failed call chain:
irq_create_of_mapping
irq_set_irq_type
__irq_set_trigger
if (!chip || !chip-irq_set_type) {
return 0; - return here
}
CBAR has no .irq_set_type() defined and, so, IRQ triggering
configuration will not be propagated to parent IRQ domain.
Hence, fix it by introducing irq_chip_set_type_parent(), in the
same manner as irq_chip_set_wake_parent(), and use it for IRQ
triggering type propagation to the parent IRQ domain in
irq-crossbar and omap-wakeupgen.
/ # cat /proc/interrupts -- before
230: 0 0 CBAR 30 Edge- 48051000.gpio
263: 0 0 CBAR 116 Edge- 48053000.gpio
296:246 0 CBAR 67 Edge- OMAP UART0
311:341 0 CBAR 51 Edge- 4807.i2c
312: 3 0 CBAR 52 Edge- 48072000.i2c
313: 0 0 CBAR 56 Edge- 4806.i2c
314:255 0 CBAR 78 Edge- mmc0
315: 40 0 CBAR 81 Edge- mmc1
316: 13 0 CBAR 91 Edge- mmc2
320: 0 0 CBAR 49 Edge- 4a14.sata
324: 0 0 CBAR 1 Edge- 48078000.elm
325: 0 0 CBAR 15 Edge- gpmc
333: 0 0 CBAR 335 Edge- 48484000.ethernet
334: 0 0 CBAR 336 Edge- 48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 0 0 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.seria
/ # cat /proc/interrupts -- after
230: 0 0 CBAR 30 Level -2004 48051000.gpio
263: 0 0 CBAR 116 Level -2004 48053000.gpio
296:567 0 CBAR 67 Level -2004 OMAP UART0
311:363 0 CBAR 51 Level -2004 4807.i2c
312: 3 0 CBAR 52 Level -2004 48072000.i2c
313: 0 0 CBAR 56 Level -2004 4806.i2c
314:197 0 CBAR 78 Level -2004 mmc0
315: 40 0 CBAR 81 Level -2004 mmc1
316: 13 0 CBAR 91 Level -2004 mmc2
320: 0 0 CBAR 49 Level -2004 4a14.sata
324: 0 0 CBAR 1 Level -2004 48078000.elm
325: 0 0 CBAR 15 Level -2004 gpmc
333: 0 0 CBAR 335 Level -2004 48484000.ethernet
334: 0 0 CBAR 336 Level -2004 48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 4 2 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.serial
Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar to stacked
domains')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Hi All,
I can split patch if required and overall solution acceptable.
This looks good to me. Please repost it after splitting it in two
patches.
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 v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs
* Keerthy j-keer...@ti.com [150810 02:31]: @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430) #ifdef CONFIG_SOC_AM43XX # undef soc_is_am43xx # undef soc_is_am437x -# define soc_is_am43xx() is_am43xx() -# define soc_is_am437x() is_am437x() +# undef soc_is_am438x +# define soc_is_am43xx() of_machine_is_compatible(ti,am43) +# define soc_is_am437x() of_machine_is_compatible(ti,am4372) +# define soc_is_am438x() of_machine_is_compatible(ti,am438x) #endif Hmm didn't I already comment on this change? I don't want to do it for one SoC. Please add the SoC detection the old way for am43xx, then do another series that changes all the DT only SoCs to use of_machine_is_compatible() after it's been properly tested so now regressions are caused for the early init code. 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 v3 3/3] dma: omap-dma: add support for pause of non-cyclic transfers
On 08/07/2015 11:00 PM, Sebastian Andrzej Siewior wrote:
-static void omap_dma_stop(struct omap_chan *c)
+static void omap_dma_drain_chan(struct omap_chan *c)
+{
+ int i;
+ uint32_t val;
+
+ /* Wait for sDMA FIFO to drain */
+ for (i = 0; ; i++) {
+ val = omap_dma_chan_read(c, CCR);
+ if (!(val (CCR_RD_ACTIVE | CCR_WR_ACTIVE)))
+ break;
+
+ if (i 100)
+ break;
+
+ udelay(5);
+ }
+
+ if (val (CCR_RD_ACTIVE | CCR_WR_ACTIVE))
+ dev_err(c-vc.chan.device-dev,
+ DMA drain did not complete on lch %d\n,
+ c-dma_ch);
+}
+
+static int omap_dma_stop(struct omap_chan *c)
{
struct omap_dmadev *od = to_omap_dma_dev(c-vc.chan.device);
uint32_t val;
@@ -312,7 +335,6 @@ static void omap_dma_stop(struct omap_chan *c)
val = omap_dma_chan_read(c, CCR);
if (od-plat-errata DMA_ERRATA_i541 val CCR_TRIGGER_SRC) {
uint32_t sysconfig;
- unsigned i;
sysconfig = omap_dma_glbl_read(od, OCP_SYSCONFIG);
val = sysconfig ~DMA_SYSCONFIG_MIDLEMODE_MASK;
@@ -323,27 +345,18 @@ static void omap_dma_stop(struct omap_chan *c)
val = ~CCR_ENABLE;
omap_dma_chan_write(c, CCR, val);
- /* Wait for sDMA FIFO to drain */
- for (i = 0; ; i++) {
- val = omap_dma_chan_read(c, CCR);
- if (!(val (CCR_RD_ACTIVE | CCR_WR_ACTIVE)))
- break;
-
- if (i 100)
- break;
-
- udelay(5);
- }
-
- if (val (CCR_RD_ACTIVE | CCR_WR_ACTIVE))
- dev_err(c-vc.chan.device-dev,
- DMA drain did not complete on lch %d\n,
- c-dma_ch);
+ omap_dma_drain_chan(c);
omap_dma_glbl_write(od, OCP_SYSCONFIG, sysconfig);
} else {
+
+ if (!(val CCR_ENABLE))
+ return -EINVAL;
+
val = ~CCR_ENABLE;
omap_dma_chan_write(c, CCR, val);
+
+ omap_dma_drain_chan(c);
Note that the FIFO drain only applies to source synchronized transfers... When
the BUFFERING is _not_ disabled - in most of the cases this is true.
+ /*
+ * We do not allow DMA_MEM_TO_DEV transfers to be paused.
+ * From the AM572x TRM, 16.1.4.18 Disabling a Channel During Transfer:
+ * When a channel is disabled during a transfer, the channel undergoes
+ * an abort, unless it is hardware-source-synchronized ….
+ * A source-synchronised channel is one where the fetching of data is
+ * under control of the device. In other words, a device-to-memory
+ * transfer. So, a destination-synchronised channel (which would be a
+ * memory-to-device transfer) undergoes an abort if the the CCR_ENABLE
+ * bit is cleared.
+ * From 16.1.4.20.4.6.2 Abort: If an abort trigger occurs, the channel
+ * aborts immediately after completion of current read/write
+ * transactions and then the FIFO is cleaned up. The term cleaned up
+ * is not defined. TI recommends to check that RD_ACTIVE and WR_ACTIVE
+ * are both clear _before_ disabling the channel, otherwise data loss
+ * will occur.
+ * The problem is that if the channel is active, then device activity
+ * can result in DMA activity starting between reading those as both
+ * clear and the write to DMA_CCR to clear the enable bit hitting the
+ * hardware. If the DMA hardware can't drain the data in its FIFO to the
+ * destination, then data loss might occur (say if we write to an UART
+ * and the UART is not accepting any further data).
I don't know if you have checked it, but probably the TX DMA could be also
used when the PRZEFETCH is disabled for the channel? Just a guess
+ */
+ else if (c-desc-dir == DMA_DEV_TO_MEM)
+ can_pause = true;
+
+ if (can_pause !c-paused) {
+ ret = omap_dma_stop(c);
+ if (!ret)
+ c-paused = true;
}
+out:
+ spin_unlock_irqrestore(od-irq_lock, flags);
- return 0;
+ return ret;
}
static int omap_dma_resume(struct dma_chan *chan)
{
struct omap_chan *c = to_omap_dma_chan(chan);
+ struct omap_dmadev *od = to_omap_dma_dev(chan-device);
+ unsigned long flags;
+ int ret = -EINVAL;
- /* Pause/Resume only allowed with cyclic mode */
- if (!c-cyclic)
- return -EINVAL;
+ spin_lock_irqsave(od-irq_lock, flags);
- if (c-paused) {
+ if (c-paused c-desc) {
mb();
/* Restore channel link register */
@@ -1082,9 +1134,11 @@ static int omap_dma_resume(struct
Re: [PATCH v3 3/3] dma: omap-dma: add support for pause of non-cyclic transfers
On 08/11/2015 03:30 PM, Russell King - ARM Linux wrote: On Tue, Aug 11, 2015 at 03:02:44PM +0300, Peter Ujfalusi wrote: On 08/07/2015 11:00 PM, Sebastian Andrzej Siewior wrote: + /* +* We do not allow DMA_MEM_TO_DEV transfers to be paused. +* From the AM572x TRM, 16.1.4.18 Disabling a Channel During Transfer: +* When a channel is disabled during a transfer, the channel undergoes +* an abort, unless it is hardware-source-synchronized …. +* A source-synchronised channel is one where the fetching of data is +* under control of the device. In other words, a device-to-memory +* transfer. So, a destination-synchronised channel (which would be a +* memory-to-device transfer) undergoes an abort if the the CCR_ENABLE +* bit is cleared. +* From 16.1.4.20.4.6.2 Abort: If an abort trigger occurs, the channel +* aborts immediately after completion of current read/write +* transactions and then the FIFO is cleaned up. The term cleaned up +* is not defined. TI recommends to check that RD_ACTIVE and WR_ACTIVE +* are both clear _before_ disabling the channel, otherwise data loss +* will occur. +* The problem is that if the channel is active, then device activity +* can result in DMA activity starting between reading those as both +* clear and the write to DMA_CCR to clear the enable bit hitting the +* hardware. If the DMA hardware can't drain the data in its FIFO to the +* destination, then data loss might occur (say if we write to an UART +* and the UART is not accepting any further data). I don't know if you have checked it, but probably the TX DMA could be also used when the PRZEFETCH is disabled for the channel? Just a guess The docs aren't very clear on that... and iirc Santosh's reply didn't suggest that the prefetch bit had any influence on this behaviour. Given the wording in the documentation which seems to be quite explicit about the conditions, and it omits talking about the prefetch bit, I can only assume that the prefetch bit has no influence over this behaviour. For example, what happens if the DMA to the device has started - the device has raised its DMA request line. The DMA controller has then gone to memory and has fetched some data and incremented the source address. Meanwhile, we've cleared the ENABLE bit. What happens then? Does the DMA controller drain the read data to the device, or does it clean up the FIFO by discarding the data? Hrm, yes. If we do not have prefetch and the destination is using FIFO - so DMA pushes multiple elemets per DMA request this might be the case. But I think - nothing backs this up - if the transfer is element syncronized than we would not loose data if the prefetch is not enabled. If we have prefetch then the DMA is prefetching data to it's FIFO and an abort will just send the content of the FIFO to /dev/null (or something). Given that the conditions under which the FIFO is drained to the destination are very specific, and which explicitly excludes destination- synchronised transfers, the only conclusion that's possible without knowing the implementation intimately is that the FIFO is cleaned up which suggests that it's discarded rather than drained to the destination. Yes, the wording is not explicit and this is also my take on the issue - the content of the FIFO is just dropped after it finished the ongoing element. As this DMA controller is in all of the OMAP devices and similar, I don't think we can rely on the behaviour of any one implementation either - we don't know what the differences are between the implementations in different generations of devices without TI providing more detailed documentation in this area across their various devices. Yep. Let me try to get more information if I can. -- 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 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms
* Kevin Hilman khil...@kernel.org [150807 16:10]: Tony Lindgren t...@atomide.com writes: Ping, looks like these are still pending. Probably should be applied directly by the arm-soc maintainers. If these should go through arm-soc, please resend to:a...@kernel.org so they make it into our queue of stuff to be reviewed/applied. OK thanks, up to Nihshant to resend. 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 00/11] omap_hsmmc: voltage switching and tuning
* Kishon Vijay Abraham I kis...@ti.com [150807 07:48]: Hi, On Thursday 06 August 2015 12:18 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150805 08:03]: Hi, On Wednesday 05 August 2015 04:13 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150730 00:49]: Patch series implements voltage switching and tuning for omap_hsmmc driver. Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, Beaglebone black, OMAP5 uEVM and OMAP4 PANDA. Your tests are missing omap3? I don't have one at my disposal :-( I'll try to find one and add omap3 tests. Great :) Beagle xm is a good one to test the USB PHY stuff on and also MMC. Having USB cable connected or EHCI loaded blocks the PM though, so NFSroot is not very usable for testing on it. I found a beagle xm. So I should be able to get back to this early next week. OK 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
Re: [PATCH 2/3] dma: add __must_check annotation for dmaengine_pause()
On 08/11/2015 12:06 PM, Russell King - ARM Linux wrote: I think what people need to learn is that an API in the kernel which returns an int _can_ fail - it returns an int so it _can_ return an error code. If it _can_ return an error code, there _will_ be implementations which _do_. If you don't check the return code, either your code doesn't care whether the function was successful or not, or you're playing with fire. This is a prime example of playing with fire. Let's leave the crappy userspace laziness with regard to error checking to userspace, and keep it out of the kernel. Yes, the DMA engine capabilities may not be sufficient to describe every detail of DMA engines, but that's absolutely no reason to skimp on error checking. Had there been some kind of error checking at the site, this problem would have been spotted before the 8250-omap driver was merged. Let me disable RX-DMA in 8250-omap code and push that stable. Then we won't need a special annotation for pause support because it remains off and is currently about one user. I browsed each driver in drivers/dma each one which does support pause supports it and all of them implement it unconditionally (ipu_idmac grabs a mutex first but this is another story). Adding error checking to 8250-omap like I have it in #1 and disabling RX-DMA in case pause fails looks be reasonable since there is nothing else that can be done I guess. Once we have the missing piece in omap-dma the RX-DMA can be enabled in 8250-omap. Does this sound like a plan we can agree on? Sebastian -- 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/3] dma: omap-dma: add support for pause of non-cyclic transfers
On Tue, Aug 11, 2015 at 03:02:44PM +0300, Peter Ujfalusi wrote: On 08/07/2015 11:00 PM, Sebastian Andrzej Siewior wrote: + /* +* We do not allow DMA_MEM_TO_DEV transfers to be paused. +* From the AM572x TRM, 16.1.4.18 Disabling a Channel During Transfer: +* When a channel is disabled during a transfer, the channel undergoes +* an abort, unless it is hardware-source-synchronized …. +* A source-synchronised channel is one where the fetching of data is +* under control of the device. In other words, a device-to-memory +* transfer. So, a destination-synchronised channel (which would be a +* memory-to-device transfer) undergoes an abort if the the CCR_ENABLE +* bit is cleared. +* From 16.1.4.20.4.6.2 Abort: If an abort trigger occurs, the channel +* aborts immediately after completion of current read/write +* transactions and then the FIFO is cleaned up. The term cleaned up +* is not defined. TI recommends to check that RD_ACTIVE and WR_ACTIVE +* are both clear _before_ disabling the channel, otherwise data loss +* will occur. +* The problem is that if the channel is active, then device activity +* can result in DMA activity starting between reading those as both +* clear and the write to DMA_CCR to clear the enable bit hitting the +* hardware. If the DMA hardware can't drain the data in its FIFO to the +* destination, then data loss might occur (say if we write to an UART +* and the UART is not accepting any further data). I don't know if you have checked it, but probably the TX DMA could be also used when the PRZEFETCH is disabled for the channel? Just a guess The docs aren't very clear on that... and iirc Santosh's reply didn't suggest that the prefetch bit had any influence on this behaviour. Given the wording in the documentation which seems to be quite explicit about the conditions, and it omits talking about the prefetch bit, I can only assume that the prefetch bit has no influence over this behaviour. For example, what happens if the DMA to the device has started - the device has raised its DMA request line. The DMA controller has then gone to memory and has fetched some data and incremented the source address. Meanwhile, we've cleared the ENABLE bit. What happens then? Does the DMA controller drain the read data to the device, or does it clean up the FIFO by discarding the data? Given that the conditions under which the FIFO is drained to the destination are very specific, and which explicitly excludes destination- synchronised transfers, the only conclusion that's possible without knowing the implementation intimately is that the FIFO is cleaned up which suggests that it's discarded rather than drained to the destination. As this DMA controller is in all of the OMAP devices and similar, I don't think we can rely on the behaviour of any one implementation either - we don't know what the differences are between the implementations in different generations of devices without TI providing more detailed documentation in this area across their various devices. -- 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] ARM: OMAP: irqdomain_hierarchy: fix arm gic irq type configuration
On 08/11/2015 02:24 PM, Marc Zyngier wrote:
On Tue, 11 Aug 2015 10:25:47 +0100
Grygorii Strashko grygorii.stras...@ti.com wrote:
Hi Grygorii,
It's observed that ARM GIC IRQ triggering type is not configured
properly when IRQ is routed through IRQ domains hierarchy and
system started using DT. As result, system will start using default
ARM GIC configuration, ignore DT IRQ type configuration,
and value of desc-irq_data.state_use_accessors = 0.
In case of TI OMAP the following IRQ hierarchy is defined:
ARM GIC - OMAP wakeupgen - TI CBAR
Failed call chain:
irq_create_of_mapping
irq_set_irq_type
__irq_set_trigger
if (!chip || !chip-irq_set_type) {
return 0; - return here
}
CBAR has no .irq_set_type() defined and, so, IRQ triggering
configuration will not be propagated to parent IRQ domain.
Hence, fix it by introducing irq_chip_set_type_parent(), in the
same manner as irq_chip_set_wake_parent(), and use it for IRQ
triggering type propagation to the parent IRQ domain in
irq-crossbar and omap-wakeupgen.
/ # cat /proc/interrupts -- before
230: 0 0 CBAR 30 Edge- 48051000.gpio
263: 0 0 CBAR 116 Edge- 48053000.gpio
296:246 0 CBAR 67 Edge- OMAP UART0
311:341 0 CBAR 51 Edge- 4807.i2c
312: 3 0 CBAR 52 Edge- 48072000.i2c
313: 0 0 CBAR 56 Edge- 4806.i2c
314:255 0 CBAR 78 Edge- mmc0
315: 40 0 CBAR 81 Edge- mmc1
316: 13 0 CBAR 91 Edge- mmc2
320: 0 0 CBAR 49 Edge- 4a14.sata
324: 0 0 CBAR 1 Edge- 48078000.elm
325: 0 0 CBAR 15 Edge- gpmc
333: 0 0 CBAR 335 Edge- 48484000.ethernet
334: 0 0 CBAR 336 Edge- 48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 0 0 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.seria
/ # cat /proc/interrupts -- after
230: 0 0 CBAR 30 Level -2004 48051000.gpio
263: 0 0 CBAR 116 Level -2004 48053000.gpio
296:567 0 CBAR 67 Level -2004 OMAP UART0
311:363 0 CBAR 51 Level -2004 4807.i2c
312: 3 0 CBAR 52 Level -2004 48072000.i2c
313: 0 0 CBAR 56 Level -2004 4806.i2c
314:197 0 CBAR 78 Level -2004 mmc0
315: 40 0 CBAR 81 Level -2004 mmc1
316: 13 0 CBAR 91 Level -2004 mmc2
320: 0 0 CBAR 49 Level -2004 4a14.sata
324: 0 0 CBAR 1 Level -2004 48078000.elm
325: 0 0 CBAR 15 Level -2004 gpmc
333: 0 0 CBAR 335 Level -2004 48484000.ethernet
334: 0 0 CBAR 336 Level -2004 48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 4 2 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.serial
Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar to stacked
domains')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Hi All,
I can split patch if required and overall solution acceptable.
This looks good to me. Please repost it after splitting it in two
patches.
just to clarify - Do you want to see two or three patches?
2) or 3) arch/arm/mach-omap2/omap-wakeupgen.c | 1 +
2) drivers/irqchip/irq-crossbar.c | 1 +
1) include/linux/irq.h | 1 +
1) kernel/irq/chip.c| 16
--
regards,
-grygorii
--
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: [GIT PULL] omap dts changes for v4.3 merge window, part 3
On Thu, Aug 06, 2015 at 03:45:16AM -0700, Tony Lindgren wrote: The following changes since commit f5887fe5d14181aef0653ab04f60988252d42461: ARM: OMAP2+: Add custom abort handler for t410 (2015-07-23 22:33:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.3/dt-pt3 for you to fetch changes up to ed05637c30e6d13e5793aab64d6a6e57e30228af: ARM: dts: omap3-devkit8000: Add ADS7846 Touchscreen support (2015-08-06 02:43:09 -0700) Thanks, merged. -Olof -- 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: [GIT PULL] omap pbias regulator regression fixes against v4.2-rc5
On Thu, Aug 06, 2015 at 03:40:31AM -0700, Tony Lindgren wrote: The following changes since commit 9908ac3daa3da2d236b5406b95d0865ddb8b29c4: ARM: dts: Correct audio input route set mic bias for am335x-pepper (2015-07-15 03:03:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.2/fixes-rc5 for you to fetch changes up to cd4556733b30cc363adc7b1cea3bffa7e2dd0c7c: ARM: dts: dra7: Fix broken pbias device creation (2015-08-05 03:04:07 -0700) Thanks, merged. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
Hi,
This seems better but:
On 10/08/2015 at 14:58:22 +0530, Keerthy wrote :
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d99b2ee..756819f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -336,6 +336,8 @@
interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = rtc;
+ clocks = clk_32768_ck, clk_32k_rtc;
+ clock-names = int-clk, ext-clk;
status = disabled;
};
This change has to be part of another patch.
@@ -698,6 +706,7 @@ static int __exit omap_rtc_remove(struct platform_device
*pdev)
static int omap_rtc_suspend(struct device *dev)
{
struct omap_rtc *rtc = dev_get_drvdata(dev);
+ u8 reg;
rtc-interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
@@ -711,6 +720,18 @@ static int omap_rtc_suspend(struct device *dev)
enable_irq_wake(rtc-irq_alarm);
else
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
+
+ /*
+ * If we have the luxury of external clock then
+ * Switch to external clock so we can keep ticking
+ * acorss suspend
+ */
+ if (rtc-has_ext_clk) {
+ reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
+ rtc_write(rtc, OMAP_RTC_OSC_REG, reg |
+ OMAP_RTC_OSC_SEL_32KCLK_SRC);
+ }
+
You should probably prepare/enable the clock before switching to it. I
know it doesn't matter right now but that may not be the case on other
boards.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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] ARM: OMAP: irqdomain_hierarchy: fix arm gic irq type configuration
On Tue, 11 Aug 2015 13:16:13 +0100
Grygorii Strashko grygorii.stras...@ti.com wrote:
On 08/11/2015 02:24 PM, Marc Zyngier wrote:
On Tue, 11 Aug 2015 10:25:47 +0100
Grygorii Strashko grygorii.stras...@ti.com wrote:
Hi Grygorii,
It's observed that ARM GIC IRQ triggering type is not configured
properly when IRQ is routed through IRQ domains hierarchy and
system started using DT. As result, system will start using default
ARM GIC configuration, ignore DT IRQ type configuration,
and value of desc-irq_data.state_use_accessors = 0.
In case of TI OMAP the following IRQ hierarchy is defined:
ARM GIC - OMAP wakeupgen - TI CBAR
Failed call chain:
irq_create_of_mapping
irq_set_irq_type
__irq_set_trigger
if (!chip || !chip-irq_set_type) {
return 0; - return here
}
CBAR has no .irq_set_type() defined and, so, IRQ triggering
configuration will not be propagated to parent IRQ domain.
Hence, fix it by introducing irq_chip_set_type_parent(), in the
same manner as irq_chip_set_wake_parent(), and use it for IRQ
triggering type propagation to the parent IRQ domain in
irq-crossbar and omap-wakeupgen.
/ # cat /proc/interrupts -- before
230: 0 0 CBAR 30 Edge- 48051000.gpio
263: 0 0 CBAR 116 Edge- 48053000.gpio
296:246 0 CBAR 67 Edge- OMAP UART0
311:341 0 CBAR 51 Edge- 4807.i2c
312: 3 0 CBAR 52 Edge- 48072000.i2c
313: 0 0 CBAR 56 Edge- 4806.i2c
314:255 0 CBAR 78 Edge- mmc0
315: 40 0 CBAR 81 Edge- mmc1
316: 13 0 CBAR 91 Edge- mmc2
320: 0 0 CBAR 49 Edge- 4a14.sata
324: 0 0 CBAR 1 Edge- 48078000.elm
325: 0 0 CBAR 15 Edge- gpmc
333: 0 0 CBAR 335 Edge-
48484000.ethernet
334: 0 0 CBAR 336 Edge-
48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 0 0 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.seria
/ # cat /proc/interrupts -- after
230: 0 0 CBAR 30 Level -2004 48051000.gpio
263: 0 0 CBAR 116 Level -2004 48053000.gpio
296:567 0 CBAR 67 Level -2004 OMAP UART0
311:363 0 CBAR 51 Level -2004 4807.i2c
312: 3 0 CBAR 52 Level -2004 48072000.i2c
313: 0 0 CBAR 56 Level -2004 4806.i2c
314:197 0 CBAR 78 Level -2004 mmc0
315: 40 0 CBAR 81 Level -2004 mmc1
316: 13 0 CBAR 91 Level -2004 mmc2
320: 0 0 CBAR 49 Level -2004 4a14.sata
324: 0 0 CBAR 1 Level -2004 48078000.elm
325: 0 0 CBAR 15 Level -2004 gpmc
333: 0 0 CBAR 335 Level -2004
48484000.ethernet
334: 0 0 CBAR 336 Level -2004
48484000.ethernet
415: 0 0 pcf857x 2 Edge- btnUser1
416: 4 2 pcf857x 3 Edge- btnUser2
445: 0 0 pinctrl 992 Edge-0001 4806a000.serial
Fixes: 783d31863fb8 ('irqchip: crossbar: Convert dra7 crossbar to stacked
domains')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
Hi All,
I can split patch if required and overall solution acceptable.
This looks good to me. Please repost it after splitting it in two
patches.
just to clarify - Do you want to see two or three patches?
2) or 3) arch/arm/mach-omap2/omap-wakeupgen.c | 1 +
2) drivers/irqchip/irq-crossbar.c | 1 +
1) include/linux/irq.h | 1 +
1) kernel/irq/chip.c| 16
Ah, I forgot wakeupgen lived in the omap-specific directory.
Please cut it in 3 then (generic implementation, crossbar and
wakeupgen).
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 v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs
On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote: * Keerthy j-keer...@ti.com [150810 02:31]: @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430) #ifdefCONFIG_SOC_AM43XX # undef soc_is_am43xx # undef soc_is_am437x -# define soc_is_am43xx() is_am43xx() -# define soc_is_am437x() is_am437x() +# undef soc_is_am438x +# define soc_is_am43xx() of_machine_is_compatible(ti,am43) +# define soc_is_am437x() of_machine_is_compatible(ti,am4372) +# define soc_is_am438x() of_machine_is_compatible(ti,am438x) #endif Hmm didn't I already comment on this change? I don't want to do it for one SoC. Please add the SoC detection the old way for am43xx, then do another series that changes all the DT only SoCs to use of_machine_is_compatible() after it's been properly tested so now regressions are caused for the early init code. Okay. I misinterpreted your earlier comment. Thanks for clarifying. I will re-do. 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 v3] PCI: kill off set_irq_flags usage
On Mon, Jul 27, 2015 at 03:55:21PM -0500, Rob Herring wrote:
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.
Signed-off-by: Rob Herring r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Cc: Murali Karicheri m-kariche...@ti.com
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Jingoo Han jingooh...@gmail.com
Cc: Pratyush Anand pratyush.an...@gmail.com
Cc: Simon Horman ho...@verge.net.au
Cc: Michal Simek michal.si...@xilinx.com
Cc: Sören Brinkmann soren.brinkm...@xilinx.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.
Applied with Jingoo's ack to pci/irq for v4.3, thanks!
drivers/pci/host/pci-dra7xx.c | 1 -
drivers/pci/host/pci-keystone-dw.c | 2 --
drivers/pci/host/pci-tegra.c | 1 -
drivers/pci/host/pci-xgene-msi.c | 1 -
drivers/pci/host/pcie-designware.c | 1 -
drivers/pci/host/pcie-rcar.c | 1 -
drivers/pci/host/pcie-xilinx.c | 2 --
7 files changed, 9 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..1a0d124 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -155,7 +155,6 @@ static int dra7xx_pcie_intx_map(struct irq_domain
*domain, unsigned int irq,
{
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pci-keystone-dw.c
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..f1d0749 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -196,7 +196,6 @@ static int ks_dw_pcie_msi_map(struct irq_domain *domain,
unsigned int irq,
irq_set_chip_and_handler(irq, ks_dw_pcie_msi_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
@@ -277,7 +276,6 @@ static int ks_dw_pcie_init_legacy_irq_map(struct
irq_domain *d,
irq_set_chip_and_handler(irq, ks_dw_pcie_legacy_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, d-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 10c0571..81df0c1 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1248,7 +1248,6 @@ static int tegra_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, tegra_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
tegra_cpuidle_pcie_irqs_in_use();
diff --git a/drivers/pci/host/pci-xgene-msi.c
b/drivers/pci/host/pci-xgene-msi.c
index 2d31d4d..8e559d1 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -223,7 +223,6 @@ static int xgene_irq_domain_alloc(struct irq_domain
*domain, unsigned int virq,
irq_domain_set_info(domain, virq, msi_irq,
xgene_msi_bottom_irq_chip, domain-host_data,
handle_simple_irq, NULL, NULL);
- set_irq_flags(virq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 69486be..5c6b562 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -350,7 +350,6 @@ static int dw_pcie_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, dw_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..7678fe0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -664,7 +664,6 @@ static int
Re: [PATCH v5 0/3] dra7xx: Add PM support to PCIe
On Wednesday 12 August 2015 02:22 AM, Bjorn Helgaas wrote: On Fri, Jul 31, 2015 at 05:55:09PM +0530, Kishon Vijay Abraham I wrote: This series adds PM support to pci-dra7xx so that PCI clocks can be disabled during suspend and enabled back during resume without affecting PCI functionality. Changes from v4: *) Fixed a bug caused by sending incomplete patch. Changes from v3: *) Fix compilation errors when individual patches are applied Changes from v2: *) Used SET_SYSTEM_SLEEP_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS for populating PM ops. Changes from v1: *) Moved resetting and setting of MSE bit to pci-dra7xx. The comment to reset and set ISE is not done now since I don't have a card with IO space. Once I get to test that, I'll post a separate patch for handling that. Kishon Vijay Abraham I (3): PCI: host: pci-dra7xx: Disable pm_runtime on get_sync failure PCI: host: pci-dra7xx: add pm support to pci dra7xx PCI: host: pci-dra7xx: Idle the module by disabling MSE bit drivers/pci/host/pci-dra7xx.c | 95 - 1 file changed, 94 insertions(+), 1 deletion(-) Applied with Jingoo's Reviewed-by to pci/host-dra7xx for v4.3, thanks! I tweaked the changelogs as follows: commit 0e2bdb0e7abf4b5170874e415ec42df547916dd3 Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jul 31 17:55:10 2015 +0530 PCI: dra7xx: Disable pm_runtime on get_sync failure Fix the error handling when pm_runtime_get_sync() fails. If pm_runtime_get_sync() fails, call pm_runtime_disable() so there are no unbalanced pm_runtime_enable() calls. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Reviewed-by: Jingoo Han jingooh...@gmail.com commit e52eb445ea1d97bf7fb92d2297e487a305392136 Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jul 31 17:55:11 2015 +0530 PCI: dra7xx: Add PM support Add PM support to pci-dra7xx so PCI clocks can be disabled during suspend and enabled during resume without affecting PCI functionality. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Reviewed-by: Jingoo Han jingooh...@gmail.com commit 389c7094ec241ee8ebe358ba10fe392018692c8c Author: Kishon Vijay Abraham I kis...@ti.com Date: Fri Jul 31 17:55:12 2015 +0530 PCI: dra7xx: Clear MSE bit during suspend so clocks will idle DRA7xx requires the MSE bit to be cleared to set the master in standby mode. (In DRA7xx TRM_vE, section 24.9.4.5.2.2.1 PCIe Controller Master Standby Behavior advises to use the clearing of the local MSE bit to set the master in standby. Without this some of the clocks do not idle). Clear the MSE bit on suspend and enable it on resume. Clearing MSE bit is required to get clocks to be idled after suspend. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Reviewed-by: Jingoo Han jingooh...@gmail.com Thanks Bjorn! -Kishon -- 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
