Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver
On Wed, 2012-04-11 at 20:44 -0600, Paul Walmsley wrote: This is useful not only for OMAP4 and AM3517/3505, but also will probably be useful for the C6x chips that Mark Salter is working on. I have been keeping an occasional eye on these patches but I don't see any usefulness for the currently supported C6X chips. The current set of supported chips use a completely different DDR controller. There is an EMIF controller on some which provides a parallel bus for connecting to external devices (NOR flash, etc) but it looks completely different from the OMAP EMIF. I think the TI DaVinci chips have EMIF (and other IO blocks) similar to C6X which could use common drivers. --Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] clk: basic gateable and fixed-rate clks
On Tue, 2011-11-22 at 13:11 +, Arnd Bergmann wrote:
On Tuesday 22 November 2011, Mike Turquette wrote:
+static void clk_hw_gate_set_bit(struct clk *clk)
+{
+ struct clk_hw_gate *gate = to_clk_hw_gate(clk);
+ u32 reg;
+
+ reg = __raw_readl(gate-reg);
+ reg |= BIT(gate-bit_idx);
+ __raw_writel(reg, gate-reg);
+}
You cannot rely on __raw_readl() to do the right thing, especially
in architecture independent code. The safe (but slightly inefficient)
solution would be readl/writel. For ARM-only code, it would be best
to use readl_relaxed()/writel_relaxed(), but most architectures do
not implement that. We can probably add a set of helpers in asm-generic/
to define them to the default functions, like #define readl_relaxed(x)
readl(x), which I think is a good idea anyway.
readl/writel won't work for big endian CPU when the registers are on a
bus that does the endian swabbing in hardware.
--Mark
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 2011-08-31 at 20:35 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 07:19:33PM +0100, Rob Herring wrote: On 08/31/2011 12:51 PM, Will Deacon wrote: Another thing that Marc and I tried on OMAP4 was not bringing up the secondary CPU during boot (by commenting out most of smp_init). In this case, I/O performance was good until we tried to online the secondary CPU. The online failed but after that the I/O performance was certainly degraded. Was the SCU enabled at that point? One diff between nosmp boot and offlining the 2nd core would be that the SCU remains enabled in the latter case. I think the SCU does not get enabled for nosmp. Our rudimentary test (printing out the SCU control register during boot) showed that it *was* enabled for nosmp. I think this is due to the secure world having to do that on OMAP so it's probably not true for other platforms. I've done a little test and found that turning on the MMU of the second core causes the problem to show up. I patched head.S so I stopped the second core in an infinite loop just before turning on the MMU. The system continues booting on core#0 and I see ~20MB/s with hdparm -t to an attached usb disk. Same setup but with second core being stopped with infinite loop just after MMU is enabled shows ~5MB/s. So whatever is going wrong, its not because of anything the second core is doing beyond turning on its MMU and doing an empty loop. --Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote: One question: why this write buffer issue did not happen at UP ARM V7 platform, whose dma buffer also uncache, but bufferable? Which CPU was on this platform? Using a 3.1.0-rc4+ kernel on a Pandaboard, and running 'hdparm -t' on a usb disk drive, I see ~5.8MB/s read speed. Same kernel, but passing nosmp on the commandline, I see 20.3MB/s. Can someone explain why nosmp would make such a difference? --Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 2011-08-31 at 16:21 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote: On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote: One question: why this write buffer issue did not happen at UP ARM V7 platform, whose dma buffer also uncache, but bufferable? Which CPU was on this platform? Using a 3.1.0-rc4+ kernel on a Pandaboard, and running 'hdparm -t' on a usb disk drive, I see ~5.8MB/s read speed. Same kernel, but passing nosmp on the commandline, I see 20.3MB/s. Can someone explain why nosmp would make such a difference? Oh gawd, that's horrible. I have a feeling it's probably a separate issue though, caused by: omap_modify_auxcoreboot0(0x200, 0xfdff); in boot_secondary for OMAP. Unfortunately I have no idea what that line is doing because it ends up talking to the secure monitor. Okay, I may poke around a bit with that to see I can get a better understanding. With the patched ehci-q.c, I see no noticeable difference between smp and nosmp. Both get me around 23.5MB/s with my setup. --Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 2011-08-31 at 13:49 -0500, Rob Herring wrote: An outer_sync will only drain the write buffer of the L2. It does not flush the cache though. If the write buffer does in fact keep data as long as possible (until it needs a free slot or the line is full), then long delays to write out data are certainly possible. The exact operation is not documented AFAIR. Ah, thanks for that. I really haven't been paying close attention to ARMv6/7 hardware and I'm in the process of playing catch up. --Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
--Mark
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Tue, 2011-08-30 at 13:15 -0400, Alan Stern wrote:
On Tue, 30 Aug 2011, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
This would be a good thing to define centrally. Would you like to
post an RFC on LKML?
Yes, I can take a stab at that.
Do you know of any other examples of hardware that polls shared DMA
memory?
Not offhand nor after a quick search. I don't think it is a common
way of doing things.
--Mark
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: fix update qtd-token in qh_append_tds
On Mon, 2011-08-29 at 23:55 +0800, Ming Lei wrote: If writing to coherent memory can't reach physical memory immediately on other ARCHs, the problem can still happen on these ARCHs. But I am not sure if there are these kind of ARCHs except for ARM. If there is write buffering which prevents outside bus masters from seeing the data, can we really call it coherent memory? --Mark -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
