Re: [PATCH] arm/dts: OMAP3: fix pinctrl-single configuration
On Thu, 2013-03-28 at 09:38 -0700, Tony Lindgren wrote:
* Christoph Fritz chf.fr...@googlemail.com [130328 01:12]:
- Fix 'function-mask' referring to TRM Section 7.4.4:
Pad Functional Multiplexing and Configuration.
- Fix 'omap3_pmx_core' referring to TRM Table 7-4:
Core Control Module Pad Configuration Register Fields
- Fix 'omap3_pmx_wkup' referring to TRM Table 7-6:
Wake-Up Control Module Pad Configuration Register Fields.
Maybe mention which TRM this is so people will know.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6ce3b5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -27,7 +27,7 @@
};
/*
-* The soc node represents the soc top level view. It is uses for IPs
+* The soc node represents the soc top level view. It is used for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
@@ -77,20 +77,20 @@
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002030 0x05cc;
+ reg = 0x48002030 0x234;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
Changing the size from 0x5cc to 0x234 misses the range ending at
CONTROL_PADCONF_ETK_D14[31:16] 0x480025f8 that's listed at least in
the 3630 TRM. Which TRM are you looking at?
I used TRM Omap35xx, and yes in the TRM Omap36xx 0x234 is fine. I'll fix
this in the next revision of this patch.
Ack for the function-mask change for omap3, looks like those bits are not
used.
- omap3_pmx_wkup: pinmux@0x48002a58 {
+ omap3_pmx_wkup: pinmux@0x48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002a58 0x5c;
+ reg = 0x48002a00 0x54;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
Hmm I think I converted these from the legacy mux framework, that seems
to be missing the wkup range between 0x2a00 - 0x2a58. So yes 0x2a00
is the right start as otherwise we're missing some wkup registers.
But the size should be 0x50 instead of 0x54 as the JTAG_TDO[31:16] is
already un-used in TRM?
Or it could be 0x60 if we want to map also the reserved GPIO128[31:16].
Why not 0x5c ? GPIO128[31:16] starts at 0x2a5a and its size is 2 bytes.
Thanks
-- Christoph
--
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
NAND: ecc-opt=hw-romcode == OMAP_ECC_HAMMING_CODE_HW_ROMCODE
Hi, Just wanted to enquire, if someone has used following configuration with earlier OMAP devices. ti,nand-ecc-opt = hw-romcode; Documentation/devicetree/bindings/mtd/gpmc-nand.txt hw-romcodegpmc hamming mode method romcode layout which in earlier non-DT kernels would map to: ecc_opt == ' OMAP_ECC_HAMMING_CODE_HW_ROMCODE' with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm/dts: OMAP3: fix pinctrl-single configuration
On Fri, 2013-03-29 at 10:37 +0100, Christoph Fritz wrote:
On Thu, 2013-03-28 at 09:38 -0700, Tony Lindgren wrote:
* Christoph Fritz chf.fr...@googlemail.com [130328 01:12]:
- Fix 'function-mask' referring to TRM Section 7.4.4:
Pad Functional Multiplexing and Configuration.
- Fix 'omap3_pmx_core' referring to TRM Table 7-4:
Core Control Module Pad Configuration Register Fields
- Fix 'omap3_pmx_wkup' referring to TRM Table 7-6:
Wake-Up Control Module Pad Configuration Register Fields.
Maybe mention which TRM this is so people will know.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6ce3b5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -27,7 +27,7 @@
};
/*
- * The soc node represents the soc top level view. It is uses for IPs
+ * The soc node represents the soc top level view. It is used for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
@@ -77,20 +77,20 @@
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002030 0x05cc;
+ reg = 0x48002030 0x234;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
Changing the size from 0x5cc to 0x234 misses the range ending at
CONTROL_PADCONF_ETK_D14[31:16] 0x480025f8 that's listed at least in
the 3630 TRM. Which TRM are you looking at?
I used TRM Omap35xx, and yes in the TRM Omap36xx 0x234 is fine. I'll fix
this in the next revision of this patch.
I mean 0x5cc is fine :)
Ack for the function-mask change for omap3, looks like those bits are not
used.
- omap3_pmx_wkup: pinmux@0x48002a58 {
+ omap3_pmx_wkup: pinmux@0x48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002a58 0x5c;
+ reg = 0x48002a00 0x54;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
Hmm I think I converted these from the legacy mux framework, that seems
to be missing the wkup range between 0x2a00 - 0x2a58. So yes 0x2a00
is the right start as otherwise we're missing some wkup registers.
But the size should be 0x50 instead of 0x54 as the JTAG_TDO[31:16] is
already un-used in TRM?
Or it could be 0x60 if we want to map also the reserved GPIO128[31:16].
Why not 0x5c ? GPIO128[31:16] starts at 0x2a5a and its size is 2 bytes.
Thanks
-- Christoph
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] dmaengine: omap-dma: Start DMA without delay
Remove the use of a tasklet to start the DMA channel when issue_pending is
called.
The use of tasklet delays the DMA start which can cause issues at drivers,
for example the audio drivers expect that the DMA is started right away.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Russell,
I know you are against removing the tasklet since you have planed to move the
omap-dma to use runtime/dynamic DMA channel use.
I have looked at the amba-pl08x.c driver which is doing that exactly (as you
pointed out that to me). AMBA did not use tasklet either and I'm sure we can
change the omap-dma driver to do the same in a same way as we could have done it
with the tasklet use.
I have tested the patch on OMAP3/4 devices and have not seen any ill effects of
this patch.
Currently OMAP audio is affected by the taskelt: we have random channel
switch/shift
when starting audio. This is because the DMA is started after (because of the
tasklet)
the audio IPs.
We probably need to backport this patch to 3.7 and 3.8 as well after the review
rounds.
Regards,
Peter
drivers/dma/omap-dma.c | 51 ++
1 file changed, 2 insertions(+), 49 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c4b4fd2..d6a1dc0 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -22,13 +22,10 @@
struct omap_dmadev {
struct dma_device ddev;
spinlock_t lock;
- struct tasklet_struct task;
- struct list_head pending;
};
struct omap_chan {
struct virt_dma_chan vc;
- struct list_head node;
struct dma_slave_config cfg;
unsigned dma_sig;
@@ -153,33 +150,6 @@ static void omap_dma_callback(int ch, u16 status, void
*data)
spin_unlock_irqrestore(c-vc.lock, flags);
}
-/*
- * This callback schedules all pending channels. We could be more
- * clever here by postponing allocation of the real DMA channels to
- * this point, and freeing them when our virtual channel becomes idle.
- *
- * We would then need to deal with 'all channels in-use'
- */
-static void omap_dma_sched(unsigned long data)
-{
- struct omap_dmadev *d = (struct omap_dmadev *)data;
- LIST_HEAD(head);
-
- spin_lock_irq(d-lock);
- list_splice_tail_init(d-pending, head);
- spin_unlock_irq(d-lock);
-
- while (!list_empty(head)) {
- struct omap_chan *c = list_first_entry(head,
- struct omap_chan, node);
-
- spin_lock_irq(c-vc.lock);
- list_del_init(c-node);
- omap_dma_start_desc(c);
- spin_unlock_irq(c-vc.lock);
- }
-}
-
static int omap_dma_alloc_chan_resources(struct dma_chan *chan)
{
struct omap_chan *c = to_omap_dma_chan(chan);
@@ -275,14 +245,8 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
unsigned long flags;
spin_lock_irqsave(c-vc.lock, flags);
- if (vchan_issue_pending(c-vc) !c-desc) {
- struct omap_dmadev *d = to_omap_dma_dev(chan-device);
- spin_lock(d-lock);
- if (list_empty(c-node))
- list_add_tail(c-node, d-pending);
- spin_unlock(d-lock);
- tasklet_schedule(d-task);
- }
+ if (vchan_issue_pending(c-vc) !c-desc)
+ omap_dma_start_desc(c);
spin_unlock_irqrestore(c-vc.lock, flags);
}
@@ -456,17 +420,11 @@ static int omap_dma_slave_config(struct omap_chan *c,
struct dma_slave_config *c
static int omap_dma_terminate_all(struct omap_chan *c)
{
- struct omap_dmadev *d = to_omap_dma_dev(c-vc.chan.device);
unsigned long flags;
LIST_HEAD(head);
spin_lock_irqsave(c-vc.lock, flags);
- /* Prevent this channel being scheduled */
- spin_lock(d-lock);
- list_del_init(c-node);
- spin_unlock(d-lock);
-
/*
* Stop DMA activity: we assume the callback will not be called
* after omap_stop_dma() returns (even if it does, it will see
@@ -562,7 +520,6 @@ static int omap_dma_chan_init(struct omap_dmadev *od, int
dma_sig)
c-dma_sig = dma_sig;
c-vc.desc_free = omap_dma_desc_free;
vchan_init(c-vc, od-ddev);
- INIT_LIST_HEAD(c-node);
od-ddev.chancnt++;
@@ -571,7 +528,6 @@ static int omap_dma_chan_init(struct omap_dmadev *od, int
dma_sig)
static void omap_dma_free(struct omap_dmadev *od)
{
- tasklet_kill(od-task);
while (!list_empty(od-ddev.channels)) {
struct omap_chan *c = list_first_entry(od-ddev.channels,
struct omap_chan, vc.chan.device_node);
@@ -603,11 +559,8 @@ static int omap_dma_probe(struct platform_device *pdev)
od-ddev.device_control = omap_dma_control;
od-ddev.dev = pdev-dev;
INIT_LIST_HEAD(od-ddev.channels);
- INIT_LIST_HEAD(od-pending);
spin_lock_init(od-lock);
- tasklet_init(od-task,
Re: [RFC] dmaengine: omap-dma: Start DMA without delay
Remove the use of a tasklet to start the DMA channel when issue_pending is called. The use of tasklet delays the DMA start which can cause issues at drivers, for example the audio drivers expect that the DMA is started right away. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I've reported the problem and now tested the patch applied on top of 3.8.5, running on beagle-xm; sounds good, so Tested-by: Peter Meerwald p.meerw...@bct-electronic.com -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support
-Original Message- From: Cousson, Benoit Sent: Thursday, March 28, 2013 5:57 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree-disc...@lists.ozlabs.org; Porter, Matt; jac...@sunsite.dk Subject: Re: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support Hi Vaibhav, The series looks good to me, but unfortunately does not apply cleanly on top of the latest for_3.10/dts branch. Could you rebase it? Benoit, You can simply skip below two patches, [PATCH 1/6] ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM [PATCH 3/6] ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM You have already merged Anil Kumar's patch into your branch. commit 9115b7c03565b5797714b2e819f6a79f040d8782 Author: AnilKumar Ch anilku...@ti.com Date: Wed Nov 21 17:22:17 2012 +0530 ARM: dts: AM33XX: Rename I2C and GPIO nodes NOTE: I have build and boot tested by skipping above 2 patches. Thanks, Vaibhav -- 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: OMAP3: fix pinctrl-single configuration
* Christoph Fritz chf.fr...@googlemail.com [130329 02:41]:
On Thu, 2013-03-28 at 09:38 -0700, Tony Lindgren wrote:
* Christoph Fritz chf.fr...@googlemail.com [130328 01:12]:
- Fix 'function-mask' referring to TRM Section 7.4.4:
Pad Functional Multiplexing and Configuration.
- Fix 'omap3_pmx_core' referring to TRM Table 7-4:
Core Control Module Pad Configuration Register Fields
- Fix 'omap3_pmx_wkup' referring to TRM Table 7-6:
Wake-Up Control Module Pad Configuration Register Fields.
Maybe mention which TRM this is so people will know.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6ce3b5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -27,7 +27,7 @@
};
/*
- * The soc node represents the soc top level view. It is uses for IPs
+ * The soc node represents the soc top level view. It is used for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
@@ -77,20 +77,20 @@
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002030 0x05cc;
+ reg = 0x48002030 0x234;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
Changing the size from 0x5cc to 0x234 misses the range ending at
CONTROL_PADCONF_ETK_D14[31:16] 0x480025f8 that's listed at least in
the 3630 TRM. Which TRM are you looking at?
I used TRM Omap35xx, and yes in the TRM Omap36xx 0x234 is fine. I'll fix
this in the next revision of this patch.
OK
Ack for the function-mask change for omap3, looks like those bits are not
used.
- omap3_pmx_wkup: pinmux@0x48002a58 {
+ omap3_pmx_wkup: pinmux@0x48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002a58 0x5c;
+ reg = 0x48002a00 0x54;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
Hmm I think I converted these from the legacy mux framework, that seems
to be missing the wkup range between 0x2a00 - 0x2a58. So yes 0x2a00
is the right start as otherwise we're missing some wkup registers.
But the size should be 0x50 instead of 0x54 as the JTAG_TDO[31:16] is
already un-used in TRM?
Or it could be 0x60 if we want to map also the reserved GPIO128[31:16].
Why not 0x5c ? GPIO128[31:16] starts at 0x2a5a and its size is 2 bytes.
Oops yes 0x5c as it's 2 bytes. So the original value is fine then.
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 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
* Tomi Valkeinen tomi.valkei...@ti.com [130328 21:32]: On 2013-03-28 23:28, Tony Lindgren wrote: How do you plan to change between LCD and DVI with DT? By using some custom driver modules? I don't know, but I guess we need board specific drivers. Do you know if there are other similar cases for other busses? I mean, I think this is a similar case than, say, having two i2c devices with the same i2c-id on the same bus. Only one of the devices can be enabled, the other must be disconnected. And how the connect/disconnect is made is board specific. No good ideas, unless it all can be controlled via pinctrl framework? With pinctrl framework the dss driver could request named modes like dvi and lcd for sets of pins. And the panel driver could implement pinctrl functions, so when a named mode lcd is requested by the dss driver, the data lines configured and GPIO and regulators get set. If we are really muxing the dss data lines, then using that might make sense. Note that there may be issues related to waiting sleeping regulators etc. There's the capebus coming that can be used for that too, but in most cases all the hardware is permanently connected with LCD and DVI. So sounds like capebus should only be needed for the add on boards. True. Well, depends on how you look at it. From one point of view there's no real difference whether the disabled device is physically on the board or not, as it has to be disconnected. The details depend on the bus, but for example for DSI I think the disabled device has to be totally removed from the DSI bus with some mux or such. Yes, so if we're really muxing lines, then maybe using the pinctrl framework makes sense until we have the capebus available? But, from the other point of view, the devices are there, on the board, and in some cases the HW has been designed to support switching the displays during runtime. So what I wish is that I could make the linux device for the display to be removed when it's disabled. I believe that can be done, but I guess it requires a board specific driver, with some custom user interface to do that. Sounds like capebus will do that when it's available. And it would be different user interface than currently, which is again not so nice. Currently the devices are always there, with their sysfs files, and those sysfs files are used to enable/disable the devices. If the device is removed, the sysfs files get removed also... You can probably keep the user interface the same if the dss driver requests changing the panels, and can probably support both pinctrl muxing and capebus pretty easily. The biggest change would be that when capebus is available there's more than one struct device for the panels, so the .dts files would have to be updated for that. Or maybe the pinctrl handler could already easily add and remove devices depending which named mode is requested by the dss driver, I don't know. But I would really like to get rid of the current model, which I think was a very bad design decision. Yes agreed, we need to get rid of the board-*.c file callback functions. 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
[PATCH v2] arm/dts: OMAP3: fix pinctrl-single configuration
- Fix 'function-mask' referring to TRM (Omap 36xx) Section 13.4.4:
Pad Functional Multiplexing and Configuration.
- Fix 'omap3_pmx_wkup' referring to TRM Table 13-6:
Wkup Control Module Pad Configuration Register Fields.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
arch/arm/boot/dts/omap3.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..1997b41 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -27,7 +27,7 @@
};
/*
-* The soc node represents the soc top level view. It is uses for IPs
+* The soc node represents the soc top level view. It is used for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
*/
soc {
@@ -81,16 +81,16 @@
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
- omap3_pmx_wkup: pinmux@0x48002a58 {
+ omap3_pmx_wkup: pinmux@0x48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002a58 0x5c;
+ reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7fff;
+ pinctrl-single,function-mask = 0x7f1f;
};
gpio1: gpio@4831 {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On 03/27/2013 02:55 PM, Linus Walleij wrote: On Wed, Mar 27, 2013 at 5:09 PM, Stephen Warren swar...@wwwdotorg.org wrote: It's simply that if a device emits an IRQ, there's no reason to assume that the IRQ is in fact a GPIO. It might be a dedicated IRQ input pin and not something that gpiolib (or any other GPIO API) knows about. OK (following the first example, that's what I have in the Nomadik or Snowball already). Another possibility: (Device IRQ output wired directly into dedicated IRQ input pin, and that pin has no GPIO capabilities) ++ | SoC| ++ | IRQ 5 | DEV_IRQ | Device | | GIC --|-|-IRQ| || ++ ++ As such, the driver /must/ receive an int irq in platform data. Nah. Lets pass a struct resource * of type IORESOURCE_IRQ. But I understand the necessity to pass the IRQ number somehow. Oh sure. I tend to consider the resources part of platform data, although I agree they really aren't. If it received an int gpio, then there would be no way for the driver to support boards that routed that interrupt signal to a dedicated IRQ pin on the SoC, rather than to a GPIO pin that just happened to have interrupt generation capabilities. This is the case for some SMSC911x clients like the snowball routing it to a GPIO, whereas I think the RealView and Integrator/CP has a dedicated IRQ line for it on the FPGA so it's a good example. In such cases the right thing to do is for the platform code populating the platform data with the int irq field, or device tree core, or whatever piece of code that knows about the actual GPIO shall start from the GPIO, request it and then convert it to an IRQ. So board code could easily do that; plenty of opportunity to put whatever custom code is needed right there. For DT core code to do that, we'd need some alternative way of specifying interrupts. That would change the DT bindings for interrupts. I don't think we can do that... If it seems like identical boilerplate in every machine we can simply centralize it to gpiolib. Something like int gpio_add_single_irq_resource(struct platform_device *pdev, int gpio, unsigned flags) ... [code to convert GPIO to IRQ and create IORESOURCE_IRQ from it] int gpio_populate_irq_resource(struct platform_device *pdev, int gpio, unsigned flags, struct resource *r) ... [code to create IORESOURCE_IRQ from the IRQ] ... gpio_populate_irq_resource(ethernet, 17, IORESOURCE_IRQ_HIGHEDGE, ethernet_res[1]); platform_device_register(ethernet); That populates the device with the single GPIO IRQ from the GPIO number in a smooth way. Of course it has to be done after the GPIO driver is up and running so may require some other refactoring, but it should work. That latter issue also somewhat scuppers this approach; then you have to somehow run a bunch of your board file code inter-mixed with various driver probe() calls. That will quickly get nasy. And it doesn't address how the DT core will know when to call gpio_add_single_irq_resource() vs. gpio_populate_irq_resource() without changing the DT binding for interrupts. And then, given that irq_to_gpio() isn't semantically possible, there's no way for the driver to be able to gpio_request() anything, since it doesn't, can't, and shouldn't know whether there is in fact any GPIO ID that it should request, let alone what that GPIO ID is. That's cool. The driver does not have to know the IRQ is backed by a GPIO, but somewhere in the system something should know this. Something already does; the irqchip driver for the IRQ in question would always know whether it's programming a plain IRQ controller, or an IRQ controller that's part of a GPIO controller. In the GPIO case, the irqchip driver also has enought HW-specific information to perform whatever GPIO-IRQ number conversion is needed. Such as board code or DT core (I'm thinking drivers/of/platform.c code calling gpiolib-of.c to do this mapping for DT, for example). And by introducing the requirement that such GPIO lines be GPIO input hogs in the device tree else warn we can get a nice closure in the DT case: the GPIO subsystem knows the actual GPIO line as a hog that is request and sets as input at probe, the referencing device node only gets the IRQ but at runtime the device node instatiation for the IRQ consumer will ask the gpiolib to check its hog list to make sure one of these will match that IRQ, then request it. Hogs sounds like pinctrl. pinctrl doesn't support the concept of hogs on GPIOs, since it only knows about pins not GPIOs really; even with the integration with gpiolib, pinctrl gets informed when GPIOs are requested, not when setting up pinctrl states ahead of time, and also this notification is only so we can mark the pin related to
[PATCH v3 0/1] usb: musb: improve throughput in HOST mode
Hi guys, This is a resend (and v3) of my patch: http://permalink.gmane.org/gmane.linux.usb.general/67238 At this moment it has been successfully tested and used on top of 3.0 and 3.4 kernels on omap4 devices so it would be great to have it in upstream too. Regards, Ruslan v3: Implementation has been little bit changed to keep MUSB struct hc_driver as 'const' (as per Felipe's comments). Verified on top of 3.9-rc4. Ruslan Bilovol (1): usb: musb: implement (un)map_urb_for_dma hooks drivers/usb/musb/musb_host.c | 117 ++ 1 file changed, 117 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] usb: musb: implement (un)map_urb_for_dma hooks
MUSB controller cannot work in DMA mode with misaligned buffers,
switching in PIO mode.
HCD core has hooks that allow to override the default DMA
mapping and unmapping routines for host controllers that have
special DMA requirements, such as alignment constraints.
It is observed that work in PIO mode is slow and it's better
to align buffers properly before passing them to MUSB
This increased throughput 80-120 MBits/s over musb@omap4 with
USB Gigabit Ethernet adapter attached.
Some ideas are taken from ehci-tegra.c
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/usb/musb/musb_host.c | 117 ++
1 file changed, 117 insertions(+)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 1ce1fcf..33277c9 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2465,6 +2465,118 @@ static int musb_bus_resume(struct usb_hcd *hcd)
return 0;
}
+
+#ifndef CONFIG_MUSB_PIO_ONLY
+
+#define MUSB_USB_DMA_ALIGN 4
+
+struct musb_temp_buffer {
+ void *kmalloc_ptr;
+ void *old_xfer_buffer;
+ u8 data[0];
+};
+
+static void musb_free_temp_buffer(struct urb *urb)
+{
+ enum dma_data_direction dir;
+ struct musb_temp_buffer *temp;
+
+ if (!(urb-transfer_flags URB_ALIGNED_TEMP_BUFFER))
+ return;
+
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ temp = container_of(urb-transfer_buffer, struct musb_temp_buffer,
+ data);
+
+ if (dir == DMA_FROM_DEVICE) {
+ memcpy(temp-old_xfer_buffer, temp-data,
+ urb-transfer_buffer_length);
+ }
+ urb-transfer_buffer = temp-old_xfer_buffer;
+ kfree(temp-kmalloc_ptr);
+
+ urb-transfer_flags = ~URB_ALIGNED_TEMP_BUFFER;
+}
+
+static int musb_alloc_temp_buffer(struct urb *urb, gfp_t mem_flags)
+{
+ enum dma_data_direction dir;
+ struct musb_temp_buffer *temp;
+ void *kmalloc_ptr;
+ size_t kmalloc_size;
+
+ if (urb-num_sgs || urb-sg ||
+ urb-transfer_buffer_length == 0 ||
+ !((uintptr_t)urb-transfer_buffer (MUSB_USB_DMA_ALIGN - 1)))
+ return 0;
+
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ /* Allocate a buffer with enough padding for alignment */
+ kmalloc_size = urb-transfer_buffer_length +
+ sizeof(struct musb_temp_buffer) + MUSB_USB_DMA_ALIGN - 1;
+
+ kmalloc_ptr = kmalloc(kmalloc_size, mem_flags);
+ if (!kmalloc_ptr)
+ return -ENOMEM;
+
+ /* Position our struct temp_buffer such that data is aligned */
+ temp = PTR_ALIGN(kmalloc_ptr, MUSB_USB_DMA_ALIGN);
+
+
+ temp-kmalloc_ptr = kmalloc_ptr;
+ temp-old_xfer_buffer = urb-transfer_buffer;
+ if (dir == DMA_TO_DEVICE)
+ memcpy(temp-data, urb-transfer_buffer,
+ urb-transfer_buffer_length);
+ urb-transfer_buffer = temp-data;
+
+ urb-transfer_flags |= URB_ALIGNED_TEMP_BUFFER;
+
+ return 0;
+}
+
+static int musb_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
+ gfp_t mem_flags)
+{
+ struct musb *musb = hcd_to_musb(hcd);
+ int ret;
+
+ /*
+* The DMA engine in RTL1.8 and above cannot handle
+* DMA addresses that are not aligned to a 4 byte boundary.
+* For such engine implemented (un)map_urb_for_dma hooks.
+* Do not use these hooks for RTL1.8
+*/
+ if (musb-hwvers MUSB_HWVERS_1800)
+ return usb_hcd_map_urb_for_dma(hcd, urb, mem_flags);
+
+ ret = musb_alloc_temp_buffer(urb, mem_flags);
+ if (ret)
+ return ret;
+
+ ret = usb_hcd_map_urb_for_dma(hcd, urb, mem_flags);
+ if (ret)
+ musb_free_temp_buffer(urb);
+
+ return ret;
+}
+
+static void musb_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+ struct musb *musb = hcd_to_musb(hcd);
+
+ usb_hcd_unmap_urb_for_dma(hcd, urb);
+
+ /* Do not use this hook for RTL1.8 (see description above) */
+ if (musb-hwvers MUSB_HWVERS_1800)
+ return;
+
+ musb_free_temp_buffer(urb);
+}
+#endif /* !CONFIG_MUSB_PIO_ONLY */
+
const struct hc_driver musb_hc_driver = {
.description= musb-hcd,
.product_desc = MUSB HDRC host driver,
@@ -2484,6 +2596,11 @@ const struct hc_driver musb_hc_driver = {
.urb_dequeue= musb_urb_dequeue,
.endpoint_disable = musb_h_disable,
+#ifndef CONFIG_MUSB_PIO_ONLY
+ .map_urb_for_dma= musb_map_urb_for_dma,
+ .unmap_urb_for_dma = musb_unmap_urb_for_dma,
+#endif
+
.hub_status_data= musb_hub_status_data,
.hub_control= musb_hub_control,
.bus_suspend= musb_bus_suspend,
--
1.7.9.5
--
To unsubscribe from this list:
[PATCH 0/2] ARM: OMAP2+: AM33xx: Add sysconf info to wdt1 hwmod data
With the recent submitted patch from Santosh Shilimkar, ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc (commit: 4a98c2d89), kernel is crashing while accessing wdt1 module without sysconf information, so add sysconf information to the wdt1 hwmod data. And also switch wdt1 parent clock to PRCM generated 32K clock-source during boot-time, as default On-Chip 32K RC Osc clock is not an accurate by design. Vaibhav Hiremath (2): ARM: OMAP2+: AM33xx: hwmod: Add missing sysc definition to wdt1 entry ARM: OMAP2+: am335x: Change the wdt1 func clk src to per_32k clk arch/arm/mach-omap2/cclock33xx_data.c |8 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 15 +++ 2 files changed, 23 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: am335x: Change the wdt1 func clk src to per_32k clk
WDT1 module can take one of the below clocks as input functional clock - - On-Chip 32K RC Osc [default/reset] - 32K from PRCM The On-Chip 32K RC Osc clock is not an accurate clock-source as per the design/spec, so as a result, for example, timer which supposed to get expired @60Sec, but will expire somewhere ~@40Sec, which is not expected by any use-case. The solution here is to switch the input clock-source to PRCM generated 32K clock-source during boot-time itself. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/cclock33xx_data.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c index 8327721..11e07b1 100644 --- a/arch/arm/mach-omap2/cclock33xx_data.c +++ b/arch/arm/mach-omap2/cclock33xx_data.c @@ -978,6 +978,14 @@ int __init am33xx_clk_init(void) clk_set_parent(timer3_fck, sys_clkin_ck); clk_set_parent(timer6_fck, sys_clkin_ck); + /* +* The On-Chip 32K RC Osc clock is not an accurate clock-source as per +* the design/spec, so as a result, for example, timer which supposed +* to get expired @60Sec, but will expire somewhere ~@40Sec, which is +* not expected by any use-case, so change WDT1 clock source to PRCM +* 32KHz clock. +*/ + clk_set_parent(wdt1_fck, clkdiv32k_ick); return 0; } -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: AM33xx: hwmod: Add missing sysc definition to wdt1 entry
This patch adds sysc definitions to the wdt1 hwmod entry, which in-turn
makes sure that sysc idle bit-fields are configured to valid state on
enable/disable callbacks.
With the recent submitted patch from Santosh Shilimkar,
ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc
(commit: 4a98c2d89), it is required to add sysconf
information to each valid hwmod entry, else device will not be
come out from idle state properly and leads to below kernel
crash -
[2.190237] Unhandled fault: external abort on non-linefetch (0x1028) at
0xf9e35034
[2.198325] Internal error: : 1028 [#1] SMP ARM
[2.203101] Modules linked in:
[2.206334] CPU: 0Not tainted (3.9.0-rc3-00059-gd114294#1)
[2.212679] PC is at omap_wdt_disable.clone.5+0xc/0x60
[2.218090] LR is at omap_wdt_probe+0x184/0x1fc
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson benoit.cous...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 61c98f1..3ce2ff8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -28,6 +28,7 @@
#include prm-regbits-33xx.h
#include i2c.h
#include mmc.h
+#include wd_timer.h
/*
* IP blocks
@@ -2087,8 +2088,21 @@ static struct omap_hwmod am33xx_uart6_hwmod = {
};
/* 'wd_timer' class */
+static struct omap_hwmod_class_sysconfig wdt_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x10,
+ .syss_offs = 0x14,
+ .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
static struct omap_hwmod_class am33xx_wd_timer_hwmod_class = {
.name = wd_timer,
+ .sysc = wdt_sysc,
+ .pre_shutdown = omap2_wd_timer_disable,
};
/*
@@ -2099,6 +2113,7 @@ static struct omap_hwmod am33xx_wd_timer1_hwmod = {
.name = wd_timer2,
.class = am33xx_wd_timer_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE,
.main_clk = wdt1_fck,
.prcm = {
.omap4 = {
--
1.7.0.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: [RFC] dmaengine: omap-dma: Start DMA without delay
On Fri, Mar 29, 2013 at 03:12:03PM +0100, Peter Ujfalusi wrote: Remove the use of a tasklet to start the DMA channel when issue_pending is called. The use of tasklet delays the DMA start which can cause issues at drivers, for example the audio drivers expect that the DMA is started right away. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Russell, I know you are against removing the tasklet since you have planed to move the omap-dma to use runtime/dynamic DMA channel use. I have looked at the amba-pl08x.c driver which is doing that exactly (as you pointed out that to me). AMBA did not use tasklet either and I'm sure we can change the omap-dma driver to do the same in a same way as we could have done it with the tasklet use. It's rather sad that you're ignoring what I'm saying, and going by what another DMA engine driver - which is self contained - is doing, rather than listening to my arguments against that approach. I think in return I'll just ignore this patch, showing you the same respect you show me. Congratuations. -- 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
