RE: [patch 1/2] powerpc: Sky CPU: redundant or incorrect tests on unsigned
We don't plan on carrying it forward, so I assume that ripping it out will not affect us. Anything new would be completely new development. -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Wednesday, February 03, 2010 9:01 PM To: support Cc: a...@linux-foundation.org; linuxppc-...@ozlabs.org; roel.kl...@gmail.com; ga...@gate.crashing.org; gorcu...@gmail.com; wa...@skycomputers.com Subject: Re: [patch 1/2] powerpc: Sky CPU: redundant or incorrect tests on unsigned On Wed, 2010-02-03 at 20:47 -0500, support wrote: I doubt we'll be going to be using 7448's any more for future product lines. Hi ! Well, that isn't really the question :-) Is there any interest in ensuring that your current Sky is supported by upstream linux kernels or not ? As I said, the current kernel seems to contain code relative to the Sky CPU that is never enabled and potentially has issue. Are you guys interested in fixing this so that upstream linux supports your existing products, or should we just rip the code out ? Cheers, Ben. Dave Bushee Director OEM Sales and Services SKY Computers Inc. 27 Industrial Ave. 978-250-2420 x232 www.skycomputers.com - Original Message - From: Benjamin Herrenschmidt b...@kernel.crashing.org To: support supp...@skycomputers.com Cc: a...@linux-foundation.org; linuxppc-...@ozlabs.org; roel.kl...@gmail.com; ga...@gate.crashing.org; gorcu...@gmail.com; wa...@skycomputers.com Sent: Wednesday, February 03, 2010 7:18 PM Subject: Re: [patch 1/2] powerpc: Sky CPU: redundant or incorrect tests on unsigned On Wed, 2010-02-03 at 19:10 -0500, support wrote: The sky cpu is a PPC7448. I'm actually amazed that you guys are still working on a problem for a product that was finished a number of years ago, at the request of someone who hasn't worked here for years. I sorry you, seem to have been wasting your time. I think, but am NOT sure, that our HAA function sets it off. http://www.skycomputers.com/Systems/HAA_HMM.php Still, we have finished the product some time ago, and as far as reported have no problems. Again, I'm sorry you have wasted any time on this, we just recently found these emails. Well, there seem to be some code in the Linux kernel related to that CPU that is either dead or incomplete. So if you guys have no interest in it, we might just rip it out completely. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 2/2] kbuild: move -fno-dwarf2-cfi-asm to powerpc only
On 4.2.2010 00:22, Benjamin Herrenschmidt wrote: On Tue, 2010-02-02 at 14:40 -0800, a...@linux-foundation.org wrote: From: Andi Kleen a...@firstfloor.org Better dwarf2 unwind information is a good thing, it allows better debugging with kgdb and crash and helps systemtap. Commit 003086497f07f7f1e67c0c295e261740f822b377 (Build with -fno-dwarf2-cfi-asm) disabled some CFI information globally to work around a module loader bug on powerpc. But this disables the better unwind tables for all architectures, not just powerpc. Move the workaround to powerpc and also add a suitable comment that's it really a workaround. This improves dwarf2 unwind tables on x86 at least. Signed-off-by: Andi Kleen a...@linux.intel.com Cc: Kyle McMartin k...@mcmartin.ca Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org Do you want me to carry that in powerpc-next ? I can add it to kbuild-next. Changes to the top-level Makefile usually go through kbuild, so it will avoid potential conflicts. Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
resurrecting the mvme5100 ppc platform
Hello, I'm just started working on some mvme5100 boards, and so I discovered that support for these cards has been dropped with linux-2.6.27 due to lack of interest. Here is the relevent post on linuxppc-embedded: http://www.mail-archive.com/linuxppc-embed...@ozlabs.org/msg30049.html Well, I'd really like to see support for the mvme5100 to be reintegrated in the kernel. I'm willing to help on this, but at the moment I don't know how much work is to be done, as I don't know how the switch from ppc to powerpc changed things. If anybody of you is interested please drop me an email. Thank you, Paride ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix ioremap_flags() with book3e pte definition
We can't just clear the user read permission in book3e pte, because that will also clear supervisor read permission. This surely isn't desired. Fix the problem by adding the supervisor read back. Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/mm/pgtable_32.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index cb96cb2..aff7c04 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -144,6 +144,11 @@ ioremap_flags(phys_addr_t addr, unsigned long size, unsigned long flags) /* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */ flags = ~(_PAGE_USER | _PAGE_EXEC); +#if defined(CONFIG_FSL_BOOKE) defined(CONFIG_PTE_64BIT) + /* supervisor read permission has just been cleared, add back */ + flags |= _PAGE_BAP_SR; +#endif + return __ioremap_caller(addr, size, flags, __builtin_return_address(0)); } EXPORT_SYMBOL(ioremap_flags); -- 1.6.6-rc1.GIT ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: emaclite: adding MDIO and phy lib support
Hi John and Sadanand. Looks like a good patch, but a few issues to
resolve. Comments below.
g.
On Wed, Feb 3, 2010 at 5:49 PM, John Linn john.l...@xilinx.com wrote:
These changes add MDIO and phy lib support to the driver as the
IP core now supports the MDIO bus.
The MDIO bus and phy are added as a child to the emaclite in the device
tree as illustrated below.
mdio {
#address-cells = 1;
#size-cells = 0;
phy0: p...@7 {
reg = 7;
For completeness, phy node need a compatible property.
} ;
}
Signed-off-by: Sadanand Mutyala sadanand.muty...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/net/Kconfig | 1 +
drivers/net/xilinx_emaclite.c | 362
-
2 files changed, 319 insertions(+), 44 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 396fd38..2056cd2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1947,6 +1947,7 @@ config ATL2
config XILINX_EMACLITE
tristate Xilinx 10/100 Ethernet Lite support
depends on PPC32 || MICROBLAZE
+ select PHYLIB
help
This driver supports the 10/100 Ethernet Lite from Xilinx.
Patch appears to be whitespace damaged. All tabs have been converted to spaces.
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 83a044d..8c7d7ae 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -22,11 +22,17 @@
#include linux/of_device.h
#include linux/of_platform.h
+#include linux/of_mdio.h
+#include linux/phy.h
#define DRIVER_NAME xilinx_emaclite
/* Register offsets for the EmacLite Core */
#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
+#define XEL_MDIOADDR_OFFSET 0x07E4 /* MDIO Address Register */
+#define XEL_MDIOWR_OFFSET 0x07E8 /* MDIO Write Data Register */
+#define XEL_MDIORD_OFFSET 0x07EC /* MDIO Read Data Register */
+#define XEL_MDIOCTRL_OFFSET 0x07F0 /* MDIO Control Register */
#define XEL_GIER_OFFSET 0x07F8 /* GIE Register */
#define XEL_TSR_OFFSET 0x07FC /* Tx status */
#define XEL_TPLR_OFFSET 0x07F4 /* Tx packet length */
@@ -37,6 +43,22 @@
#define XEL_BUFFER_OFFSET 0x0800 /* Next Tx/Rx buffer's offset
*/
+/* MDIO Address Register Bit Masks */
+#define XEL_MDIOADDR_REGADR_MASK 0x001F /* Register Address */
+#define XEL_MDIOADDR_PHYADR_MASK 0x03E0 /* PHY Address */
+#define XEL_MDIOADDR_PHYADR_SHIFT 5
+#define XEL_MDIOADDR_OP_MASK 0x0400 /* RD/WR Operation */
+
+/* MDIO Write Data Register Bit Masks */
+#define XEL_MDIOWR_WRDATA_MASK 0x /* Data to be Written */
+
+/* MDIO Read Data Register Bit Masks */
+#define XEL_MDIORD_RDDATA_MASK 0x /* Data to be Read */
+
+/* MDIO Control Register Bit Masks */
+#define XEL_MDIOCTRL_MDIOSTS_MASK 0x0001 /* MDIO Status Mask */
+#define XEL_MDIOCTRL_MDIOEN_MASK 0x0008 /* MDIO Enable */
+
/* Global Interrupt Enable Register (GIER) Bit Masks */
#define XEL_GIER_GIE_MASK 0x8000 /* Global Enable */
@@ -87,6 +109,12 @@
* @reset_lock: lock used for synchronization
* @deferred_skb: holds an skb (for transmission at a later time) when
the
* Tx buffer is not free
+ * @phy_dev: pointer to the PHY device
+ * @phy_node: pointer to the PHY device node
+ * @mii_bus: pointer to the MII bus
+ * @mdio_irqs: IRQs table for MDIO bus
+ * @last_link: last link status
+ * @has_mdio: indicates whether MDIO is included in the HW
*/
struct net_local {
@@ -100,6 +128,15 @@ struct net_local {
spinlock_t reset_lock;
struct sk_buff *deferred_skb;
+
+ struct phy_device *phy_dev;
+ struct device_node *phy_node;
+
+ struct mii_bus *mii_bus;
+ int mdio_irqs[PHY_MAX_ADDR];
+
+ int last_link;
+ bool has_mdio;
};
@@ -431,7 +468,7 @@ static u16 xemaclite_recv_data(struct net_local *drvdata,
u8 *data)
}
/**
- * xemaclite_set_mac_address - Set the MAC address for this device
+ * xemaclite_update_address - Update the MAC address in the device
* @drvdata: Pointer to the Emaclite device private data
* @address_ptr:Pointer to the MAC address (MAC address is a 48-bit value)
*
@@ -441,8 +478,8 @@ static u16 xemaclite_recv_data(struct net_local *drvdata,
u8 *data)
* The MAC address can be programmed using any of the two transmit
* buffers (if configured).
*/
-static void xemaclite_set_mac_address(struct net_local *drvdata,
- u8 *address_ptr)
+static void xemaclite_update_address(struct net_local *drvdata,
+ u8 *address_ptr)
{
void __iomem
Re: [RFC PATCH 1/2] USB: add HCD_BOUNCE_BUFFERS host controller driver flag
Hi Alan,
Alan Stern wrote:
This description sounds hopelessly confused. Maybe you're just
misusing the term coherent. The patch itself doesn't affect the
coherent DMA mappings anyway; it affects the streaming mappings. Or to
put it another way, what's the justification for replacing a call to
dma_map_single() with a call to dma_alloc_coherent()?
Since the patch doesn't affect any of the coherent mappings (see for
example the calls to dma_pool_create() in ehci-mem.c), I don't see how
it can possibly do what you claim.
Thanks for your comments. Let's try to hopefully clarify this a bit.
I've used the term coherent as described in Documentation/DMA-API.txt (aka
consistent as used in PCI-related functions).
I've tried to describe first the limitations of the platform that I'm working
on. Basically, one of the annoying things of that platform is that writes to
uncached memory (as used in coherent memory) can only be reliably performed
in 32-bit accesses.
The USB subsystem ends up using coherent memory for buffers and/or other
structures in different ways.
The coherent memory allocated in dma_pool_create() in ehci-mem.c that you
report is not a problem at all because it is always accessed in 32-bit chunks
(it hasn't been always like that but since commit
3807e26d69b9ad3864fe03224ebebc9610d5802e USB: EHCI: split ehci_qh into hw and
sw parts this got addressed as a side effect, so I didn't need to post another
patch for that).
Other possible interactions with coherent memory are those involving buffers
used in USB transactions, which may be allocated via the USB subsystem (at
usb_buffer_alloc() or when bounced via hcd_alloc_coherent()) or which may come
already allocated and ready for use (URB_NO_{SETUP,TRANSFER}_DMA_MAP).
The patch, as posted, allocates normal memory for USB buffers _within_ the USB
subsystem and invariably bounces all buffers to new coherent buffers.
So, basically, what the patch claims (avoid 32-bit writes for coherent memory
within the USB subsystem) is done (hey, it actually works ;-).
But I think you have raised valid points here :)
If the coherent memory is already allocated and passed (as already
dma-mapped) to the USB subsystem then there is no gain in bouncing the buffer:
- if a non-32 bit write was done to that coherent memory the damage is
already done
- if the coherent memory was written always in 32-bit accesses then we can
just safely use it
So bouncing here should be avoided as it is unneeded.
On the other hand, we can control USB buffers managed by the USB subsystem
itself.
That's what the patch does. It avoids access restrictions to USB buffers by
allocating them from normal memory (leaving USB drivers free to access those
buffers in whatever bus width they need, as they do today) ... and bouncing
them.
The thing here is that it makes no sense to bounce them to coherent memory if
they can be dma-mapped directly (as you point in your
dma_map_single-vs-dma_alloc_coherent comment).
So... that's what RFCs are for :)
I'll take a look again at the patch.
+/**
+ * hcd_memcpy32_to_coherent - copy data to a bounce buffer
+ * @dst: destination dma bounce buffer
+ * @src: source buffer
+ * @len: number of bytes to copy
+ *
+ * This function copies @len bytes from @src to @dst in 32 bit chunks.
+ * The caller must guarantee that @dst length is 4 byte aligned and
+ * that @dst length is greater than or equal to @src length.
+ */
+static void *hcd_memcpy32_to_coherent(void *dst, const void *src, size_t
len)
+{
+u32 *q = dst, *p = (void *)src;
+u8 *s;
+
+while (len = 4) {
+*q++ = *p++;
+len -= 4;
+}
+s = (u8 *)p;
+switch (len) {
+case 3:
+*q = s[0] 24 | s[1] 16 | s[2] 8;
+break;
+case 2:
+*q = s[0] 24 | s[1] 16;
+break;
+case 1:
+*q = s[0] 24;
+break;
+default:
+break;
+}
+return dst;
+}
What happens if somebody tries to use this code on a little-endian CPU?
It will fail.
It seems that every time somebody comes up with a new kind of
memory-access restriction, this function grows by a factor of 2. After
a few more iterations it will be larger than the rest of the kernel!
There must be a better way to structure the requirements here.
Hopefully I didn't miss any of your concerns and managed to explain the problem.
Alan Stern
Thanks,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/2] USB: add HCD_BOUNCE_BUFFERS host controller driver flag
On Thu, 4 Feb 2010, Albert Herranz wrote:
Hi Alan,
Alan Stern wrote:
This description sounds hopelessly confused. Maybe you're just
misusing the term coherent. The patch itself doesn't affect the
coherent DMA mappings anyway; it affects the streaming mappings. Or to
put it another way, what's the justification for replacing a call to
dma_map_single() with a call to dma_alloc_coherent()?
Since the patch doesn't affect any of the coherent mappings (see for
example the calls to dma_pool_create() in ehci-mem.c), I don't see how
it can possibly do what you claim.
Thanks for your comments. Let's try to hopefully clarify this a bit.
I've used the term coherent as described in Documentation/DMA-API.txt (aka
consistent as used in PCI-related functions).
I've tried to describe first the limitations of the platform that I'm working
on. Basically, one of the annoying things of that platform is that writes to
uncached memory (as used in coherent memory) can only be reliably performed
in 32-bit accesses.
The USB subsystem ends up using coherent memory for buffers and/or other
structures in different ways.
The coherent memory allocated in dma_pool_create() in ehci-mem.c that you
report is not a problem at all because it is always accessed in 32-bit chunks
(it hasn't been always like that but since commit
3807e26d69b9ad3864fe03224ebebc9610d5802e USB: EHCI: split ehci_qh into hw
and sw parts this got addressed as a side effect, so I didn't need to post
another patch for that).
On a 64-bit processor, some of the accesses will be 64 bits wide
instead of 32. Does that matter for your purposes?
What about ohci-hcd and uhci-hcd? They both use non-32-bit accesses to
structures in coherent memory.
Other possible interactions with coherent memory are those involving
buffers used in USB transactions, which may be allocated via the USB
subsystem (at usb_buffer_alloc() or when bounced via hcd_alloc_coherent()) or
which may come already allocated and ready for use
(URB_NO_{SETUP,TRANSFER}_DMA_MAP).
Ah yes, quite correct. And this indicates that you need to concentrate
on usb_buffer_alloc(). On your system (or rather, whenever the
HCD_NO_COHERENT_MEM flag is set) it should allocate normal memory and
set the DMA pointer to NULL.
Then map_urb_for_dma() should check the urb-setup_dma and
urb-transfer_dma pointers; if a pointer is NULL then the
corresponding urb-URB_NO_SETUP_DMA_MAP or urb-NO_TRANSFER_DMA_MAP
flag should be ignored (and probably should be cleared so as to
avoid confusing unmap_urb_for_dma()).
The patch, as posted, allocates normal memory for USB buffers _within_ the
USB subsystem and invariably bounces all buffers to new coherent buffers.
So, basically, what the patch claims (avoid 32-bit writes for coherent
memory within the USB subsystem) is done (hey, it actually works ;-).
But I think you have raised valid points here :)
If the coherent memory is already allocated and passed (as already
dma-mapped) to the USB subsystem then there is no gain in bouncing the buffer:
- if a non-32 bit write was done to that coherent memory the damage is
already done
- if the coherent memory was written always in 32-bit accesses then we can
just safely use it
So bouncing here should be avoided as it is unneeded.
On the other hand, we can control USB buffers managed by the USB subsystem
itself.
That's what the patch does. It avoids access restrictions to USB buffers by
allocating them from normal memory (leaving USB drivers free to access those
buffers in whatever bus width they need, as they do today) ... and bouncing
them.
The thing here is that it makes no sense to bounce them to coherent memory
if they can be dma-mapped directly (as you point in your
dma_map_single-vs-dma_alloc_coherent comment).
So... that's what RFCs are for :)
If you do it as described above then the buffers you're worried about
won't be allocated in coherent memory to begin with, so no problems
will arise.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
Hi Roman: Am 03.02.10 07:16 schrieb(en) Roman Fietze: Sorry for the delay ... your mail got stuck in a Notes spam filter. Never mind. I didn't know yet that I'm *such* a nasty guy... ;-) Are you using MWDMA2 with the compact flash cards? What is the load on the different (DMA) channels? ATA reads or writes? Actually, I forgot that I have to explicitly enable libata dma on the 5200b, due to the known silicon bugs... I will repeat my tests with the proper configuration, stay tuned. ... a signal processor attached to the localbus, using bestcomm and the fifo for the bulk transfer Are you using an own driver, or are you using Grant's SCLPC+SDMA driver? BD task? Basically Grant's driver, but with a slightly modified variant of the gen_bd task. The signal processor is a LE, and I managed to insert the LE/BE conversion into the bestcomm task (see also http://patchwork.ozlabs.org/patch/35038/). Unfortunately, there is no good documentation of the engine; I would like to also shift crc calculation into bestcomm, which seems to be possible in principle, but I never got it running. The best thing is to run very ugly tests with very high load for at least 24h. Thanks again for this tip! I hope I manage to run a test over the weekend. Throughput onto the cf cards is not critical for me (so I could live with pio there), but I'm a little afraid I might also see similar effects with fec and the signal processor (in particular, the latter *is* critical). Thanks, Albrecht. pgpYvbtKoluWE.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
