Re: [microblaze-uclinux] Re: Request review of device tree documentation
On Sat, Jun 12, 2010 at 05:09:36PM -0600, Grant Likely wrote: On Sat, Jun 12, 2010 at 4:15 PM, Olof Johansson o...@lixom.net wrote: On Sat, Jun 12, 2010 at 12:53:59AM -0600, Grant Likely wrote: I also changed the property in the cpu nodes from model to compatible so that the exact CPU version can be specified. This isn't actually in any spec anywhere, but I need something to properly identify the different ARM cores. I don't see why this has to be in the device tree. It's not there on PPC. The exact CPU version is found through the PVR register on PPC, ARM also has cpu version and feature registers for runtime probing. I had been told that they runtime registers weren't reliable. If I'm misinformed, then yes the compatible value can be dropped from the cpu nodes. Hi all, If it's not too painful to keep, I think it will be valuable if one want's to instantiate HW based/from this same device tree. For example for emulators. Cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver
On Mon, Mar 15, 2010 at 03:39:49PM +0100, Michal Simek wrote: John Linn wrote: -Original Message- From: Michal Simek [mailto:michal.si...@petalogix.com] Sent: Monday, March 15, 2010 2:40 AM To: John Linn Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org; grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com; John Tyner Subject: Re: [PATCH] [V2] Add non-Virtex5 support for LL TEMAC driver John Linn wrote: This patch adds support for using the LL TEMAC Ethernet driver on non-Virtex 5 platforms by adding support for accessing the Soft DMA registers as if they were memory mapped instead of solely through the DCR's (available on the Virtex 5). The patch also updates the driver so that it runs on the MicroBlaze. The changes were tested on the PowerPC 440, PowerPC 405, and the MicroBlaze platforms. Which git-tree have you tested on? (Of course microblaze) It was tested on the Xilinx tree for MicroBlaze which is based on the mainline and the Petalogix tree as DMA was needed. I tried to build against the mainline head but got errors with the DMA routines. I guess it's possible that it was a configuration issue there as I didn't dig real deep. New dma api is in for-linus branch. I tested it on that version and I am seeing some weird things. :-( Access to bad area. I will try your tree. The second thing which I see is in ll_temac_recv function. On the following line is read a packet length which could be 0-16k. length = cur_p-app4 0x3FFF; But allocated skb has max size XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN. What happen if driver get packet greater than 9kB? I got it (I don't know how) but skb_put has one checking mechanism which will cal skb_over_panic which caused panic. That's why I think that will be good always to check that length is less than XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN. What do you think? I agree. IIRC the LLTEMAC when configured to accept jumboframes will accepts packets up to 16K and the driver should handle that without raising panics. I remeber beeing a bit surprised about that when hacking the QEMU model. Not sure if I remember correctly though. Cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [microblaze-uclinux] Re: [PATCH 6/6] Add support for __read_mostly to linux/cache.h
On Fri, May 01, 2009 at 09:52:18AM -0400, Christoph Lameter wrote: On Fri, 1 May 2009, Sam Ravnborg wrote: Are there any specific reason why we do not support read_mostly on all architectures? Not that I know of. read_mostly is about grouping rarely written data together so what is needed is to introduce this section in the remaining archtectures. Christoph - git log says you did the inital implmentation. Do you agree? Yes. There is some concern that __read_mostly is needlessly applied to numerous variables that are not used in hot code paths. This may make __read_mostly ineffective and actually increase the cache footprint of a function since global variables are no longer in the same cacheline. If such a function is called and the caches are cold then two cacheline fetches have to be done instead of one. FWIW I think that's a valid concern. Also, I think one can question the value of __read_mostly for write-through caches, given the mentioned concern it probably makes things worse for those. IMO there should be a way to turn it off for arch's that know it's no good for them. Cheers ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
