Re: [PATCH 0/9] OMAP: HWMOD: DSS patches
Hi Tomi, thanks for cleaning up the commit messages and reposting these so quickly. On Tue, 23 Aug 2011, Tomi Valkeinen wrote: These are the previously sent HWMOD patches split into smaller pieces and with improved commit messages. I'm not sure if these are strictly needed to be sent for -rc. The DSS patches 9ede365aa6f74428a1f69c21ca1cf21213167576 (HACK: OMAP: DSS2: clk hack for OMAP2/3) and df5d3ed23cf73ee0763a8963003bda9b69d9620f (OMAP: DSS2: HDMI: fix hdmi clock name) already circumvent the problems with wrong clocks, and the DSS reset problem on OMAP4 hasn't caused any actual runtime problems as far as I know. Sounds like we should wait until 3.2 for these. The series has been queued for 3.2 in the branch 'hwmod_dss_fixes_3.2' of the git://git.pwsan.com/linux-2.6 repository. - Paul -- 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 v9 00/12] use nonblock mmc requests to minimize latency
On 26 August 2011 18:28, Santosh santosh.shilim...@ti.com wrote:
+ Balaji,
On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
I'm not sure who's responsible for this, but the nonblocking MMC stuff is
broken on OMAPs HSMMC:
mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response
0x900, card status 0xb00
mmcblk0: retrying using single block read
[ cut here ]
WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811
check_unmap+0x1ac/0x764()
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x80933000] [size=20480 bytes]
Modules linked in:
Backtrace:
[c0017874] (dump_backtrace+0x0/0x10c) from [c02ce8ac]
(dump_stack+0x18/0x1c)
r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:032b
[c02ce894] (dump_stack+0x0/0x1c) from [c0039ed4]
(warn_slowpath_common+0x58/0x70)
[c0039e7c] (warn_slowpath_common+0x0/0x70) from [c0039f90]
(warn_slowpath_fmt+0x38/0x40)
r8:c1abfd50 r7: r6:5000 r5: r4:80933000
[c0039f58] (warn_slowpath_fmt+0x0/0x40) from [c0186248]
(check_unmap+0x1ac/0x764)
r3:c0367d55 r2:c037e24d
[c018609c] (check_unmap+0x0/0x764) from [c0186978]
(debug_dma_unmap_sg+0x100/0x134)
[c0186878] (debug_dma_unmap_sg+0x0/0x134) from [c0019770]
(dma_unmap_sg+0x24/0x7c)
[c001974c] (dma_unmap_sg+0x0/0x7c) from [c0207220]
(omap_hsmmc_post_req+0x48/0x54)
[c02071d8] (omap_hsmmc_post_req+0x0/0x54) from [c01fb644]
(mmc_start_req+0x9c/0x128)
r4:c1a76000
[c01fb5a8] (mmc_start_req+0x0/0x128) from [c02049fc]
(mmc_blk_issue_rw_rq+0x80/0x460)
r8:c1ab5c00 r7:0001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00
[c020497c] (mmc_blk_issue_rw_rq+0x0/0x460) from [c02050a8]
(mmc_blk_issue_rq+0x2cc/0x2fc)
[c0204ddc] (mmc_blk_issue_rq+0x0/0x2fc) from [c02056c4]
(mmc_queue_thread+0xa0/0x104)
[c0205624] (mmc_queue_thread+0x0/0x104) from [c0054f8c]
(kthread+0x88/0x90)
[c0054f04] (kthread+0x0/0x90) from [c003d9a4] (do_exit+0x0/0x618)
r7:0013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c
---[ end trace 3314ad56daf5d14f ]---
Luckily thinks continue to work, but clearly releasing DMA mappings which
drivers don't own is bad news. Unfortunately, I don't have the bandwidth
to be able to investigate this at present - well, I could do but then I'd
have to drop working on the OMAP4 vs generic suspend/resume code and learn
about something I've no current clue about.
Please continue your help on generic suspend.
Can someone please investigate and fix whatever is broken.
Will find somebody to look at this issue.
I had a look at this and my guess is that the same mapped DMA memory
is unmapped twice. First the memory is unmapped in
omap_hsmmc_dma_cleanup() due to the mmc error, then later in
omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had
the chance to test it yet though.
---
drivers/mmc/host/omap_hsmmc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..7f40767 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
host-data-sg_len,
omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(dma_ch);
+ data-host_cookie = 0;
}
host-data = NULL;
}
@@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host
*mmc, struct mmc_request *mrq,
struct mmc_data *data = mrq-data;
if (host-use_dma) {
- dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
-omap_hsmmc_get_dma_dir(host, data));
+ if (data-host_cookie)
+ dma_unmap_sg(mmc_dev(host-mmc), data-sg,
+data-sg_len,
+omap_hsmmc_get_dma_dir(host, data));
data-host_cookie = 0;
I also checked the mmci code for this same issue and mmci doesn't have
the same bug.
MMCI works fine in 3.1-rc2 even though the code is wrong. I propose
this change.
@@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host
*mmc, struct mmc_request *mrq,
if (chan) {
if (err)
dmaengine_terminate_all(chan);
- if (err || data-host_cookie)
+ if (data-host_cookie)
I'll post these patches as soon as I have managed to test them or
sooner if I get a tested-by.
Regards,
Per
--
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 v9 00/12] use nonblock mmc requests to minimize latency
On Sun, Aug 28, 2011 at 12:50:54PM +0200, Per Forlin wrote:
On 26 August 2011 18:28, Santosh santosh.shilim...@ti.com wrote:
+ Balaji,
On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
I'm not sure who's responsible for this, but the nonblocking MMC stuff is
broken on OMAPs HSMMC:
mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response
0x900, card status 0xb00
mmcblk0: retrying using single block read
[ cut here ]
WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811
check_unmap+0x1ac/0x764()
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x80933000] [size=20480 bytes]
Modules linked in:
Backtrace:
[c0017874] (dump_backtrace+0x0/0x10c) from [c02ce8ac]
(dump_stack+0x18/0x1c)
r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:032b
[c02ce894] (dump_stack+0x0/0x1c) from [c0039ed4]
(warn_slowpath_common+0x58/0x70)
[c0039e7c] (warn_slowpath_common+0x0/0x70) from [c0039f90]
(warn_slowpath_fmt+0x38/0x40)
r8:c1abfd50 r7: r6:5000 r5: r4:80933000
[c0039f58] (warn_slowpath_fmt+0x0/0x40) from [c0186248]
(check_unmap+0x1ac/0x764)
r3:c0367d55 r2:c037e24d
[c018609c] (check_unmap+0x0/0x764) from [c0186978]
(debug_dma_unmap_sg+0x100/0x134)
[c0186878] (debug_dma_unmap_sg+0x0/0x134) from [c0019770]
(dma_unmap_sg+0x24/0x7c)
[c001974c] (dma_unmap_sg+0x0/0x7c) from [c0207220]
(omap_hsmmc_post_req+0x48/0x54)
[c02071d8] (omap_hsmmc_post_req+0x0/0x54) from [c01fb644]
(mmc_start_req+0x9c/0x128)
r4:c1a76000
[c01fb5a8] (mmc_start_req+0x0/0x128) from [c02049fc]
(mmc_blk_issue_rw_rq+0x80/0x460)
r8:c1ab5c00 r7:0001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00
[c020497c] (mmc_blk_issue_rw_rq+0x0/0x460) from [c02050a8]
(mmc_blk_issue_rq+0x2cc/0x2fc)
[c0204ddc] (mmc_blk_issue_rq+0x0/0x2fc) from [c02056c4]
(mmc_queue_thread+0xa0/0x104)
[c0205624] (mmc_queue_thread+0x0/0x104) from [c0054f8c]
(kthread+0x88/0x90)
[c0054f04] (kthread+0x0/0x90) from [c003d9a4] (do_exit+0x0/0x618)
r7:0013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c
---[ end trace 3314ad56daf5d14f ]---
Luckily thinks continue to work, but clearly releasing DMA mappings which
drivers don't own is bad news. Unfortunately, I don't have the bandwidth
to be able to investigate this at present - well, I could do but then I'd
have to drop working on the OMAP4 vs generic suspend/resume code and learn
about something I've no current clue about.
Please continue your help on generic suspend.
Can someone please investigate and fix whatever is broken.
Will find somebody to look at this issue.
I had a look at this and my guess is that the same mapped DMA memory
is unmapped twice. First the memory is unmapped in
omap_hsmmc_dma_cleanup() due to the mmc error, then later in
omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had
the chance to test it yet though.
---
drivers/mmc/host/omap_hsmmc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..7f40767 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
host-data-sg_len,
omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(dma_ch);
+ data-host_cookie = 0;
}
host-data = NULL;
}
@@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host
*mmc, struct mmc_request *mrq,
struct mmc_data *data = mrq-data;
if (host-use_dma) {
- dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
-omap_hsmmc_get_dma_dir(host, data));
+ if (data-host_cookie)
+ dma_unmap_sg(mmc_dev(host-mmc), data-sg,
+data-sg_len,
+omap_hsmmc_get_dma_dir(host, data));
data-host_cookie = 0;
I also checked the mmci code for this same issue and mmci doesn't have
the same bug.
MMCI works fine in 3.1-rc2 even though the code is wrong. I propose
this change.
@@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host
*mmc, struct mmc_request *mrq,
if (chan) {
if (err)
dmaengine_terminate_all(chan);
- if (err || data-host_cookie)
+ if (data-host_cookie)
I'll post these patches as soon as I have managed to test them or
sooner if I get a tested-by.
Looking at MMCI, are you sure all those DMA engine terminate calls are
correct?
For example, why are we terminating all DMA engine transfers in the
post request function? Surely that should've already been taken care
of by
Re: How to handle named resources with DT?
On Sat, Aug 27, 2011 at 08:13:59PM +0200, Arnd Bergmann wrote:
On Sunday 28 August 2011 00:37:36 David Gibson wrote:
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
On Friday 26 August 2011, Arnd Bergmann wrote:
On Friday 26 August 2011, David Gibson wrote:
If you open code it this way then yes, it's silly. But what about
something like this:
static struct of_device_id foodevice_of_match[] __devinitdata = {
{ .compatible = foocorp,foodevice1234,
.resource_names = {base_regs, extra_regs, }, },
{ .compatible = foocorp,foodevice1239,
.resource_names = {base_regs, extra_regs, more_regs,
}, },
{ },
};
Hmm, I hadn't thought of that. This looks quite nice indeed. No
objections
to this from my side.
Ah well, one objection on second thought:
This assumes that there is just one type of resource, but named resources
may be used for iomem, ioport and irq resources. If you have multiple
IRQs and multiple IOMEM resources, I don't see how the index in the
resource_names array can be used for both of them.
Details, shmetails, so you have both 'reg_names' and 'interrupt_names'.
Right, and I guess we can simply ignore DMA and ioport resources because they
are extremely rare, right?
Well, remember it's where resources can appear in the DT node that
matters, not what the types are in the platform device. ioports will
typically appear suitably encoded in 'reg', so that's covered. I've
never been very clear on what exactly DMA resources cover, but yeah,
you might need something for dma-reg or other device tree properties.
One more detail: IIRC struct of_device_id is exported to module_init_tools
for purposes of autoloading, so changing the structure breaks user
space.
Ah. That is a bit more of a problem.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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 v9 00/12] use nonblock mmc requests to minimize latency
On 28 August 2011 13:11, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sun, Aug 28, 2011 at 12:50:54PM +0200, Per Forlin wrote:
On 26 August 2011 18:28, Santosh santosh.shilim...@ti.com wrote:
+ Balaji,
On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
I'm not sure who's responsible for this, but the nonblocking MMC stuff is
broken on OMAPs HSMMC:
mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response
0x900, card status 0xb00
mmcblk0: retrying using single block read
[ cut here ]
WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811
check_unmap+0x1ac/0x764()
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x80933000] [size=20480
bytes]
Modules linked in:
Backtrace:
[c0017874] (dump_backtrace+0x0/0x10c) from [c02ce8ac]
(dump_stack+0x18/0x1c)
r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:032b
[c02ce894] (dump_stack+0x0/0x1c) from [c0039ed4]
(warn_slowpath_common+0x58/0x70)
[c0039e7c] (warn_slowpath_common+0x0/0x70) from [c0039f90]
(warn_slowpath_fmt+0x38/0x40)
r8:c1abfd50 r7: r6:5000 r5: r4:80933000
[c0039f58] (warn_slowpath_fmt+0x0/0x40) from [c0186248]
(check_unmap+0x1ac/0x764)
r3:c0367d55 r2:c037e24d
[c018609c] (check_unmap+0x0/0x764) from [c0186978]
(debug_dma_unmap_sg+0x100/0x134)
[c0186878] (debug_dma_unmap_sg+0x0/0x134) from [c0019770]
(dma_unmap_sg+0x24/0x7c)
[c001974c] (dma_unmap_sg+0x0/0x7c) from [c0207220]
(omap_hsmmc_post_req+0x48/0x54)
[c02071d8] (omap_hsmmc_post_req+0x0/0x54) from [c01fb644]
(mmc_start_req+0x9c/0x128)
r4:c1a76000
[c01fb5a8] (mmc_start_req+0x0/0x128) from [c02049fc]
(mmc_blk_issue_rw_rq+0x80/0x460)
r8:c1ab5c00 r7:0001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00
[c020497c] (mmc_blk_issue_rw_rq+0x0/0x460) from [c02050a8]
(mmc_blk_issue_rq+0x2cc/0x2fc)
[c0204ddc] (mmc_blk_issue_rq+0x0/0x2fc) from [c02056c4]
(mmc_queue_thread+0xa0/0x104)
[c0205624] (mmc_queue_thread+0x0/0x104) from [c0054f8c]
(kthread+0x88/0x90)
[c0054f04] (kthread+0x0/0x90) from [c003d9a4] (do_exit+0x0/0x618)
r7:0013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c
---[ end trace 3314ad56daf5d14f ]---
Luckily thinks continue to work, but clearly releasing DMA mappings which
drivers don't own is bad news. Unfortunately, I don't have the bandwidth
to be able to investigate this at present - well, I could do but then I'd
have to drop working on the OMAP4 vs generic suspend/resume code and learn
about something I've no current clue about.
Please continue your help on generic suspend.
Can someone please investigate and fix whatever is broken.
Will find somebody to look at this issue.
I had a look at this and my guess is that the same mapped DMA memory
is unmapped twice. First the memory is unmapped in
omap_hsmmc_dma_cleanup() due to the mmc error, then later in
omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had
the chance to test it yet though.
---
drivers/mmc/host/omap_hsmmc.c | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..7f40767 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
host-data-sg_len,
omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(dma_ch);
+ data-host_cookie = 0;
}
host-data = NULL;
}
@@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host
*mmc, struct mmc_request *mrq,
struct mmc_data *data = mrq-data;
if (host-use_dma) {
- dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
- omap_hsmmc_get_dma_dir(host, data));
+ if (data-host_cookie)
+ dma_unmap_sg(mmc_dev(host-mmc), data-sg,
+ data-sg_len,
+ omap_hsmmc_get_dma_dir(host, data));
data-host_cookie = 0;
I also checked the mmci code for this same issue and mmci doesn't have
the same bug.
MMCI works fine in 3.1-rc2 even though the code is wrong. I propose
this change.
@@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host
*mmc, struct mmc_request *mrq,
if (chan) {
if (err)
dmaengine_terminate_all(chan);
- if (err || data-host_cookie)
+ if (data-host_cookie)
I'll post these patches as soon as I have managed to test them or
sooner if I get a tested-by.
Looking at MMCI, are you sure all those DMA engine terminate calls are
correct?
I should probably do so together with adding better
[GIT PULL] Power management fixes for 3.1
Hi Linus, Please pull power management fixes for 3.1 from: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-fixes They include: * Fixes related to the sh-sci driver which uses runtime PM helpers in such a way that they may be run with interrupts off, but it doesn't tell the core about that (so the core happily enables interrupts when they should be off), and which also causes pm_clk_suspend() and pm_clk_resume() to be run with interrupts off (so they shouldn't use a mutex). * shi7372 LCDC suspend fix from Magnus Damm. * OMAP suspend callbacks fix from Kevin Hilman. * Runtime PM documentation correction. Thanks! Documentation/power/runtime_pm.txt |3 +- arch/arm/mach-shmobile/board-ap4evb.c |1 + arch/arm/mach-shmobile/board-mackerel.c |1 + arch/arm/mach-shmobile/clock-sh7372.c |2 + arch/arm/plat-omap/omap_device.c|3 +- drivers/base/power/clock_ops.c | 40 +-- drivers/tty/serial/sh-sci.c |1 + 7 files changed, 30 insertions(+), 21 deletions(-) --- Kevin Hilman (1): OMAP: omap_device: only override _noirq methods, not normal suspend/resume Magnus Damm (2): ARM: mach-shmobile: sh7372 LCDC1 suspend fix ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental) Rafael J. Wysocki (3): PM: Use spinlock instead of mutex in clock management functions sh-sci / PM: Use power.irq_safe PM / Runtime: Correct documentation of pm_runtime_irq_safe() -- 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] usb: ehci: fix update qtd-token in qh_append_tds
On Sun, 28 Aug 2011, Ming Lei wrote: I've been following this whole discussion. �I didn't understand the idea behind the original patch, and I don't understand this. �What reason is there for adding a memory barrier after the dummy-hw_token = token line? �Such a barrier would not accomplish anything useful, because there are no later memory accesses which need to be ordered with respect to that line. Here, mb is used to synchronize between writing of CPU and reading of ehci HC, see below: A memory barrier never synchronizes events between two processors (for example, between the CPU and HC). It only affects ordering for the processor it executes on. That's why you always have to use memory barriers in pairs for inter-CPU synchronization: one memory barrier instruction for each CPU. CPU EHCI dummy-hw_token = token; mb read dummy-hw_token The mb() introduced was supposed to be used to make sure that EHCI can see the correct value of dummy-hw_token. It won't do that. All it will do is guarantee that the CPU writes out dumy-hw_token before it writes out or reads in any values executed after the mb. If EHCI can't get the correct hw_token in time, it will work badly, such as irq delay or irq lost which may be caused by mistaken 'IOC' or 'total bytes to transfer' in hw_token. No. All that will happen is that the HC will execute the qTD a little later, when it does read the correct hw_token. No IRQs will be lost, and there will be no mistaken IOC or total bytes to transfer values. This is just what the patch is to fix. The patch won't fix this. You're trying to force the CPU to write out dummy-hw_token more quickly. A memory barrier won't do that. And even if the CPU does write out the value more quickly, that doesn't guarantee it will be in time for the HC to see the new value right away. But I think the above is still not correct, and the correct way may be like below: CPU EHCI dummy-hw_token = token; wmb qh-hw-hw_qtd_next = QTD_NEXT(ehci, dummy-qtd_dma); If you do this write, you will corrupt the hardware list. You _must_ _not_ modify the hardware fields of an active QH. Besides, qh_link_async() calls qh_refresh() - qh_update(), which does this already. And it does this correctly, with the appropriate checks to make sure the QH isn't active. fetch next qtd from qh-hw-hw_qtd_next read qtd-hw_token The problem is that qh has already linked dummy into its queue before(as did in qh_update), so even after 'dummy-hw_token = token;' is executed on CPU, EHCI still may not fetch the up-to-date value of the qtd(dummy in here), and this should be the root cause, IMO. There's no way to fix this. The CPU and the HC are independent. The HC is allowed to cache values whenever it likes (within certain limits). If it has already cached an old value from the qTD, there's no way to force it to use a new value. You just have to wait until it refreshes its cache. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Sun, 28 Aug 2011, David Gibson wrote: I've never been very clear on what exactly DMA resources cover, DMA resource data are usually DMA request line ID numbers. DMA request lines are dedicated, unidirectional hardware signals from I/O devices to one or more independent DMA controllers[1][2][3]. Request lines indicate when the device is ready to accept data from the DMA controller, or, when the device has data ready for the DMA controller to fetch. On a given DMA controller, each request line has its own unique ID number[4][5][6]. During a DMA transfer, the I/O device asserts or deasserts its DMA request lines as its FIFOs fill or drain[7][8]. This will pause or resume the DMA transfer, if the DMA controller is programmed with the correct DMA request line IDs[9][10][11][12]. In a hardware-synchronized DMA transfer, the DMA controller must be controlled by the device because it is not good to read from an empty device FIFO, or to write to a full device FIFO. There aren't many sane courses of action in those circumstances with most interconnects and DMA controllers. So in terms of Linux kernel code, the driver needs the DMA request line ID numbers so it and the DMA code can program the DMA controller to synchronize DMA transfers with the I/O device(s). Like hardware IRQ IDs, these DMA request line IDs are properties of a DMA controller itself, but are associated with individual I/O devices. And like IRQ IDs, these DMA request line ID mappings may change from chip version to chip version[13], even for the same IP block. So it is useful for device data formats to provide DMA request line IDs dynamically. Several upstream device drivers get their DMA request line IDs from the device data format[14][15][16]. But more drivers should be doing this than currently are[17]: - the device driver author may have hardcoded the DMA request line ID, assuming it would never change - DMA could be broken on the device due to hardware bugs, so it is unused - the driver author may just never have gotten around to implementing DMA, or was reassigned to another project, or couldn't figure it out - the device may have its own internal DMA controller logic, so support for an external DMA controller was simply never added When looking at a driver, it may not be obvious which of the cases apply. (N.B., I/O device IP blocks that contain their own dedicated DMA controllers that are specialized to transfer only to memory don't need DMA request lines.) - Paul All code citations below are of Linux v3.1-rc3. 1. A DMA controller's view of DMA request lines. Figure 9-4, SDMA Controller Integration. _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 2. A simple device's view of DMA request lines, only connected to one DMA controller. Figure 22-17, MMC/SD/SDIO1 Integration. _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 3. A device's view of its DMA request lines connected to two separate DMA controllers, and thus with distinct numbering. Note also that the device refers to its signals with strings, while the DMA controllers refer to the same signals with ID numbers. Figure 21-16, McBSP1 Integration. _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 4. Table 5-1 Peripheral Addresses and Selectors. _RMI Alchemy Au1550 Security Network Processor Data Book Revision E_. May 2007. Available from http://www.poeticmonkey.com/ebay/semiconductors/cpus/au1550/au1550_db_0507e.pdf 5. Table 6-7 Priority and Default Mapping of Peripheral to DMA. _ADSP-BF51x Blackfin Processor Hardware Reference Preliminary Revision 0.1_ (January 2009). Available from http://www.analog.com/static/imported-files/processor_manuals/bf51x_hwr_rev_0-1.pdf 6. Table 16-5 sDMA Controller Request Mapping. _OMAP4460 Multimedia Device Silicon Revision 1.x Version H (Public Version) (SWPU235H)_. Available from http://focus.ti.com/pdfs/wtbu/OMAP4460_ES1.x_PUBLIC_TRM_vH.zip 7. A really nice illustration of the interaction between a FIFO and DMA request line during DMA receive. Figure 17-25 Receive FIFO DMA Request Generation (32 Characters). _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 8. A similarly good illustration of the interaction between a FIFO and DMA request line during DMA transmit. Figure 17-26 Transmit FIFO DMA Request Generation (56 Spaces). _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version).
Re: [PATCH] usb: ehci: fix update qtd-token in qh_append_tds
On Sun, Aug 28, 2011 at 01:00:07PM -0400, Alan Stern wrote: It won't do that. All it will do is guarantee that the CPU writes out dumy-hw_token before it writes out or reads in any values executed after the mb. You're right from the perspective of how things are defined today. However, that isn't how things work on ARM. With ARMv6 and ARMv7, we have weak memory ordering. This includes so called DMA coherent memory. This means that the architecture does not guarantee the order of writes to DMA coherent memory (which is non- cacheable normal memory) without an intervening 'data synchronization barrier' (dsb). Even that may not be sufficient without also poking at the L2 cache controller. We get around some of that by ensuring that our MMIO read/write macros contain the necessary barriers to ensure that DMA memory is up to date before the DMA agent is programmed. However, this doesn't cater for agents which continue to run in the background. These agents will need some kind of barrier to ensure that the write becomes visible - there's no way to get around that. Maybe we need yet another new barrier macro... -- 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: How to handle named resources with DT?
On Sun, Aug 28, 2011 at 05:06:43PM -0600, Paul Walmsley wrote: DMA resource data are usually DMA request line ID numbers. Not always. On ARMs development platforms, we ended up using strings - because we've ended up with a DMA controller with N request signals, where the first three request signals come from a MUX which assigns them to other devices in the system. An opaque number doesn't hack it because you start having to define arbitary ranges for such things, and that very quickly starts getting you into sticky problems when you have to work out that request signal S1 is routed through mux M1 which is connected to DMA request signal D1, and if M1 is in use, then maybe M2 can be used instead which routes to DMA request signal D2. The idea that DMA should be small integers is very limiting. -- 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] usb: ehci: fix update qtd-token in qh_append_tds
On Mon, 29 Aug 2011, Russell King - ARM Linux wrote: On Sun, Aug 28, 2011 at 01:00:07PM -0400, Alan Stern wrote: It won't do that. All it will do is guarantee that the CPU writes out dumy-hw_token before it writes out or reads in any values executed after the mb. You're right from the perspective of how things are defined today. However, that isn't how things work on ARM. With ARMv6 and ARMv7, we have weak memory ordering. This includes so called DMA coherent memory. This means that the architecture does not guarantee the order of writes to DMA coherent memory (which is non- cacheable normal memory) without an intervening 'data synchronization barrier' (dsb). Even that may not be sufficient without also poking at the L2 cache controller. We get around some of that by ensuring that our MMIO read/write macros contain the necessary barriers to ensure that DMA memory is up to date before the DMA agent is programmed. However, this doesn't cater for agents which continue to run in the background. These agents will need some kind of barrier to ensure that the write becomes visible - there's no way to get around that. Maybe we need yet another new barrier macro... Hmmm. Although the semantics of the various mb() macros were originally defined only for inter-CPU synchronization, I believe they are also supposed to work for guaranteeing the order of accesses to DMA-coherent memory. If that's not the case with ARM, something is seriously wrong. (Maybe I'm wrong about this, but if I am then there's currently _no_ way for the kernel to order DMA-coherent accesses on ARM.) You know better than I do what is needed to resolve the ordering issue. However, contrary to what the original patch description said, this isn't entirely a matter of making the write visible to the host controller: No doubt in time the write will eventually become visible anyway. It's a matter of making the write become visible reasonably quickly and in the correct order with respect to other writes. Is this extra L2-cache poke needed for proper ordering, or is it needed merely to flush the write out to memory in a timely manner? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
Hi, one case that I forgot to mention: On Sun, 28 Aug 2011, Paul Walmsley wrote: Several upstream device drivers get their DMA request line IDs from the device data format[14][15][16]. But more drivers should be doing this than currently are[17]: - the device driver author may have hardcoded the DMA request line ID, assuming it would never change - DMA could be broken on the device due to hardware bugs, so it is unused - the driver author may just never have gotten around to implementing DMA, or was reassigned to another project, or couldn't figure it out - the device may have its own internal DMA controller logic, so support for an external DMA controller was simply never added - the driver may be using software-initiated DMA, which doesn't use a DMA request line, nor does it rely on the device to start or stop DMA. Instead, the CPU reprograms the DMA controller when the driver receives an interrupt - Paul -- 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/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK
Hi Benoît, Jon,
On Wed, 27 Jul 2011, Cousson, Benoit wrote:
On 7/15/2011 4:34 PM, Hunter, Jon wrote:
On 7/15/2011 3:21, Paul Walmsley wrote:
On Thu, 14 Jul 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...
ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK
The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However, the dividers for
the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
and the OCP_ABE_ICLK is 1.
Sigh. This type of hardware design makes software design difficult :-(
Hopefully, because this is a interface clock the impact is really
minimal...more below...
The above relationship between the AESS_FCLK and OCP_ABE_ICLK
dividers ensure that the OCP_ABE_ICLK clock is always half the
frequency of the ABE_CLK...
OCP_ABE_ICLK = ABE_FCLK/2
The divider for the OCP_ABE_ICLK is currently missing so add a
divider that will ensure the OCP_ABE_ICLK frequency is always half
the ABE_FCLK frequency.
Signed-off-by: Jon Hunterjon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8c96567..6e158ce 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1301,11 +1301,25 @@ static struct clk mcasp3_fclk = {
.recalc =followparent_recalc,
};
+static const struct clksel_rate div2_2to1_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel ocp_abe_iclk_div[] = {
+ { .parent =aess_fclk, .rates = div2_2to1_rates },
+ { .parent = NULL },
+};
+
static struct clk ocp_abe_iclk = {
.name = ocp_abe_iclk,
.parent =aess_fclk,
+ .clksel = ocp_abe_iclk_div,
+ .clksel_reg = OMAP4430_CM1_ABE_AESS_CLKCTRL,
+ .clksel_mask= OMAP4430_CLKSEL_AESS_FCLK_MASK,
.ops=clkops_null,
- .recalc =followparent_recalc,
+ .recalc =omap2_clksel_recalc,
};
static struct clk per_abe_24m_fclk = {
I guess the reason that this patch can get away with this is because it
doesn't allow software to change the rate of ocp_abe_iclk, and the
ocp_abe_iclk is a child of aess_fclk, so when aess_fclk is changed, it
will recalc ocp_abe_iclk.
Benoît, what do you think? Is this a reasonable approach for the script?
Or do we need to deal with some kind of 'linked clock' implementation...
If you want my two cents on this matter, I would say that...
1). People should not need to configure the ocp_abe_iclk clock
directly, because regardless of the divider setting it is always 1/2 the
abe_fclk. In other words, only the aess_fclk frequency is really
changing because of the divider and the above relationship ensures that
the ocp_abe_iclk is always the same frequency. So a user only cares
about the aess_fclk frequency and the ocp_abe_iclk frequency is
handled for them.
2). The ocp_abe_iclk is an interface clock and is not a parent to any
other functional clock and therefore, is not driving any internal logic
in a peripheral which would have a direct impact of the speed of that
peripheral.
Since both dividers are linked, I exposed only one to SW on purpose to avoid
conflict and confusion.
As you said, we should and can only take care of the intermediate clock node.
The only drawback of not linking both nodes is that the clock rate of the
ocp_abe_iclk will be wrong if the parent clksel is changed.
So if the recalc is working well your patch should fix that.
My only concern is to find a way to generate that kind of hacky clock node:-(
However, there does appear to be another bug here in the
clock44xx_data.c as it shows that the ocp_abe_iclk is parent to the
slimbus1_fck which I believe is incorrect. According to the TRM, the
the ocp_abe_iclk is parent to the slimbus1_iclk. I can send another
patch for this. However, I will let Benoit chime in first.
This is again a consequence of the fake modulemode clock we introduced
initially and I tried to fix in the recent hwmod series.
Since the slimbus1 module does not have any main_clk, but instead a bunch of
optional
Re: [PATCH 0/6] OMAP3+ Clock Fixes
Hi Jon, On Thu, 7 Jul 2011, Jon Hunter wrote: Various clock fixes for OMAP3 and OMAP4 devices. Just doublechecking on these patches, some of them don't have Signed-off-by:'s from you. Seems like we should add those? best regards, - Paul -- 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 6/6] usb: musb: Add support for ti81xx platform
Hi, On Fri, Aug 26, 2011 at 04:41:48PM +0530, Ajay Kumar Gupta wrote: @@ -57,6 +58,10 @@ config USB_MUSB_AM35X tristate AM35x depends on ARCH_OMAP +config USB_MUSB_TI81XX + bool TI81XX + depends on SOC_OMAPTI81XX this *must* be tristate. I can't emphasize enough how important this is. Ok. diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 20a2873..07f3faf 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1014,7 +1014,9 @@ static void musb_shutdown(struct platform_device *pdev) || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\ || defined(CONFIG_USB_MUSB_AM35X) \ - || defined(CONFIG_USB_MUSB_AM35X_MODULE) + || defined(CONFIG_USB_MUSB_AM35X_MODULE)\ + || defined(CONFIG_USB_MUSB_TI81XX) \ + || defined(CONFIG_USB_MUSB_TI81XX_MODULE) we really need to find a better way to handle this :-( How about passing the mode info from musb_config (musb-config-fifo_mode), same way as musb-config-fifo_cfg Infact I think, we can kill musb-config-fifo_cfg and have only musb-config-mode as in this way all the fifo tables will be at one place and should help in maintenance. diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c new file mode 100644 index 000..f95774e --- /dev/null +++ b/drivers/usb/musb/ti81xx.c I still think this should be part of am35x.c It really look like they are very similar. Wrapper registers are different but I will see on this and provide you details On how the merged file would look like. I am afraid that we may have to use Either #ifdef or cpu_is_xxx(). on monday I'll read the rest of the file. Ok. Ajay -- balbi -- 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
