mpc8xx and ld.so problem
On Fri, 2005-07-01 at 06:44 -0300, Marcelo Tosatti wrote: Hi Anton, (moving to ppc-embedded since it might be of interesting for other 8xx users) Apply this patch to glibc, and recompile: rm -f glibc/sysdeps/powerpc/powerpc32/memset.S The PPC32 dbcz semantics don't seem to work properly on 8xx in all cases. Removing the '.S' file makes glibc fall back on the .c implementation. -- Jason McMullan jason.mcmullan at gmail.com Sure, send me the latest Knoppix DVD as an attachment... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050701/d36f7b32/attachment.pgp
mpc8xx and ld.so problem
On Fri, 2005-07-01 at 07:17 -0300, Marcelo Tosatti wrote: That was a quick response - thanks. Two questions: - Do you happen to know about details of dcbz's (mis)behaviour on 8xx? I ask that mainly because I worry about in-kernel dcbz users. IIRC, it isn't used in any 8xx code paths. - Shouldnt upstream glibc have that fixed for 8xx by now? Ha. Funny. The glibc powerpc maintainer doesn't want any embedded fixes in the mainline. Last I checked, that was for 'the tools vendors' to fix. We won't work around processor bugs is their philosophy. I went through a similar (unsuccessful) battle with the amcc 440ep's blrl errata and gcc/glibc. It would be nice if the politics there have changed (maybe they just didn't like me personally), but I don't have much hope. -- Jason McMullan jason.mcmullan at gmail.com Sure, send me the latest Knoppix DVD as an attachment... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050701/3582fda4/attachment.pgp
PQ2FADS PCI Interrupts
On Fri, 2005-06-24 at 11:25 -0400, McMullan, Jason wrote: Given your latest MPC82xx PCI patches to the list, PCI support is *better*, but interrupts are *not* delivered on the PQ2FADS Solved my own problem: Clear SIUMCR_DPPC11 in immap-im_siu_conf.siu_82xx.sc_siumcr Otherwise, IRQ6 is not routed to the SIU. -- Jason McMullan jason.mcmullan at gmail.com Sure, send me the latest Knoppix DVD as an attachment... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050624/424d94d0/attachment.pgp
RFC: cpm2_devices.c
My personal opinions: * Use macro-offsets into a cpm2_map_t struct * Put fcc_c regs back in * dpram[PROFF_*] should be in the resources list * cpm2_* is a better name than MPC82xx_* or MPC85xx_* * Keep CPM2_DMA, etc, as these *should* be showing up in /proc/iomem, since, IIRC, the platform layer does reserve them upon registration. (And I *do* have a DMA layer then uses CPM2_DMA as a driver-ish thing) -- Jason McMullan jason.mcmullan at gmail.com Sure, send me the latest Knoppix DVD as an attachment... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050615/3558728f/attachment.pgp
RFC: cpm2_devices.c
On Wed, 2005-06-15 at 09:25 -0500, Kumar Gala wrote: Yes, I removed the fcc_regs_c since its not always true. Please don't rename the file to cpm2_. I think I'm going to end up renaming them to pq2_ since that is the most appropriate name. I'd say we are about 80% PQ2_? But all these devices are on PQ3 also! -- Jason McMullan jason.mcmullan at gmail.com Sure, send me the latest Knoppix DVD as an attachment... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050615/e290f0d8/attachment.pgp
CPM2 vs PQ2: The Naming Issue
I think the issue with naming is that there are people that consider the 'part name' to be CPM2 (the macrocell), and other consider the 'part name' to be the whole SoC. Both are valid concepts, I just tend to go towards the macrocell side of the fence. If we consider the CPM2 to be a 'part' that dispenses other 'parts', we could actually consider the CPM2 to be a bus-type object. Hmm. I kinda like that, actually. (But then, I'm a crazy nutball) -- Jason McMullan jason.mcmullan at gmail.com Sure, send me the latest Knoppix DVD as an attachment... -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050615/b435290f/attachment.pgp
MPC8xx Platformization
The following is a rough skeleton of platformization for the mpc8xx series, in the same technique as Kumar's 85xx platformization. This rough cut will be followed up later with specific driver platformization fixes. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: mpc8xx-platformize.patch Type: text/x-patch Size: 11907 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050427/f39c3150/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050427/f39c3150/attachment.pgp
[PATCH 2.6.11.6] CPM2 Timers API
And here's the test-case kernel module -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpm_timer_test.c Type: text/x-csrc Size: 3852 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050401/82c57629/attachment.c -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050401/82c57629/attachment.pgp
[PATCH 2.6.11.6] CPM2 Timers API
Two patches: cpm-timer.patch: The base timers API for CPM2 timers cpm-timer.mpc85xx-devices.patch: MPC85xx support -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.mpc85xx-devices.patch Type: text/x-patch Size: 4739 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/399f76d1/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.patch Type: text/x-patch Size: 16394 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/399f76d1/attachment-0001.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/399f76d1/attachment.pgp
[PATCH 2.6.11.6] CPM2 Timers API
A brown bag error handling and Lindent patch, to be applied in that order, to my previous CPM timers patch. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.brown-bag.patch Type: text/x-patch Size: 638 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/31718842/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.lindent.patch Type: text/x-patch Size: 7152 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/31718842/attachment-0001.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/31718842/attachment.pgp
[PATCH] Updated: CPM2 I2C (SDMA and BitBang)
On Sun, 2005-03-27 at 20:11 -0800, Eugene Surovegin wrote: Jason, another thought. Do we really need all this mess with separate algo and bus drivers? Could you make just a bus driver like we have for 4xx, Keywest and 85xx/52xx/MPC107? It's much cleaner and less confusing IMHO. I made it separate algo/bus in case you had a PCI-card 85xx design where: a) You booted the card with firmware b) The firmware made the card a PCI device with the CPM exposed before you booted the kernel. c) The PCI host had to program an EEPROM on the CPM I2C bus for configuration to tell it where to get the kernel. Admittedly, a little far out, but then you could make a CPM-exposed-by-PCI I2C bus driver. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050328/94305ffc/attachment.pgp
[PATCH] CPM2 cleanups
On Tue, 2005-03-22 at 23:53 -0600, Kumar Gala wrote: Some additional comments: * Did you actually try setting CPM_IRQ_OFFSET to a non-zero value? I'm guessing this doesnt work since you are not offset the irq passed into the other functions. For example, if CPM_IRQ_OFFSET is 64, will cpm2_mask_irq() work? YAA! Good catch! (fix fix fix fix) * what is SA_NOTHREAD all about? Stale debugging code. Will be removed on the next patch. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050323/9e81d943/attachment.pgp
[PATCH] CPM2 cleanups
On Tue, 2005-03-22 at 23:46 -0600, Kumar Gala wrote: Jason, why did you bother to implement these functions, they dont provide any value for us? It looks like startup() shutdown() are only used in IRQ probing code or code in which enable/disable will be used instead. startup/shutdown is used in the 'IRQ threads' patch we use at TimeSys. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050323/6d8beea4/attachment.pgp
[PATCH] Updated: CPM2 Cleanup
Here is the CPM2 cleanup patch again, with galak's recommended fixes. This is versus kernel 2.6.11.4 vanilla -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-cpm2.patch Type: text/x-patch Size: 12294 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050323/d9f89201/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050323/d9f89201/attachment.pgp
[PATCH] CPM2 cleanups
This patch cleans up CPM2 interrupt controller usage in the mpc8260/mpc8560, and adds the cpm_cp_command() convenience function. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-cpm2.patch Type: text/x-patch Size: 11744 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/4ec5be50/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/4ec5be50/attachment.pgp
[PATCH] CPM2 I2C (SDMA and Bit-Banger)
This patch adds CPM2 I2C support, both in bit-bang and CPM SDMA modes. Lightly tested, and should be easily ported to the MPC8xx's CPM. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: driver-i2c-cpm.patch Type: text/x-patch Size: 24305 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/81f8ec8d/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/81f8ec8d/attachment.pgp
[PATCH] MPC85xx FCC and I2C platform device support
Adds platform support for default FCC mac addresses/phy information, and I2C param info -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-mpc85xx.patch Type: text/x-patch Size: 6370 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/603aa5f9/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/603aa5f9/attachment.pgp
[PATCH] MPC85xx CDS - Time Of Day, Cache settings, CPM IRQs
Some minor fixes for: MPC85xx CDS Time of Day Clock /proc/cpuinfo shows cache settings CPM IRQs are allocated more sanely. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: board-ppc-mpc85xx-cds.patch Type: text/x-patch Size: 7872 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/1e7df1f6/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/1e7df1f6/attachment.pgp
[PATCH] Updated: CPM2 I2C (SDMA and BitBang)
Updated (thanks to a quick eye by ebs) patch to add CPM2 SDMA and BitBang I2C support to the MPC85xx This patch gets rid of some really stupid cut paste errors during initialization. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: driver-i2c-cpm.patch Type: text/x-patch Size: 24409 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/1468ffae/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050322/1468ffae/attachment.pgp
440EP FPU patch
On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: Can you build your patch for the lopec_defconfig and fix the errors associated with enabling altivec. Looks like you need to include asm/offset.h asm/page.h in vector.S, however there is another build error after that. Thanks! That also found a linking bug, fixed in this patch.. Please double check the call in 'AltiVecUnavalible' in head.S, and the re-load of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec machine here. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-fpu.patch Type: text/x-patch Size: 21743 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050318/819e4fb5/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050318/819e4fb5/attachment.pgp
[PATCH 1/3] PPC440EP SoC and Bamboo board support
Do you need a 'special' toolchain to work around Errata 42 (isync before blrl) for user-space, or are the kernel-land fixes sufficient? -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050316/f96821c8/attachment.pgp
[PATCH 1/3] PPC440EP SoC and Bamboo board support
I think your setup for BAMBOO_PCIL0_PTM1MS is actually incorrect. According to the AMCC 440EP docs, BAMBOO_PCIL0_PTM1MS is a mask, so the correct code should look more like: memory_size = 0x - (memory_size - 1); PCI_WRITEL(memory_size | 1, BAMBOO_PCIL0_PTM1MS); (assuming 'memory_size' is a power of 2) -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/df535600/attachment.pgp
440EP FPU patch
On Tue, 2005-03-15 at 15:09 -0600, Kumar Gala wrote: 1. Change config option to CONFIG_PPC_FPU 2. split out altivec support into a separate file, most likely just move it into vector.S 3. Get ride of the C++ comments Changes made, as per your suggestions, and new patch attached. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpu-ppc-fpu.patch Type: text/x-patch Size: 19842 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/b1694b75/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050315/b1694b75/attachment.pgp
[PATCH] include/asm-ppc/dma-mapping.h macro patch
On Tue, 2004-12-07 at 15:03 +, Christoph Hellwig wrote:
+#define dma_cache_inv(_start,_size) do { (void)(_start);
(void)(_size); } while (0)
this looks really horrible. What about turning these into inlines?
Sure thing:
Signed-off-by: Jason McMullan jason.mcmullan at timesys.com
Summary: [ppc] dma-mapping.h - Fix macro semantics
Release: Dec 8, 2004
Description:
This patch makes the macros for dma_* semantically
equivalent to the functions they mask. For example,
dma_cache_inv(func_with_side_effects(), sizeof(foo))
will execure 'func_with_side_effects()' in the function
case, but would not execute it in the macro case.
This patch fixes this discrepancy using 'static inline'
functions.
--- linux-orig/include/asm-ppc/dma-mapping.h
+++ linux/include/asm-ppc/dma-mapping.h
@@ -24,34 +24,43 @@
extern void __dma_sync(void *vaddr, size_t size, int direction);
extern void __dma_sync_page(struct page *page, unsigned long offset,
size_t size, int direction);
-#define dma_cache_inv(_start,_size) \
- invalidate_dcache_range(_start, (_start + _size))
-#define dma_cache_wback(_start,_size) \
- clean_dcache_range(_start, (_start + _size))
-#define dma_cache_wback_inv(_start,_size) \
- flush_dcache_range(_start, (_start + _size))
+
+static inline void dma_cache_inv(unsigned long _start,size_t _size)
+{
+ invalidate_dcache_range(_start, (_start + _size));
+}
+
+static inline void dma_cache_wback(unsigned long _start,size_t _size)
+{
+ clean_dcache_range(_start, (_start + _size));
+}
+
+static inline void dma_cache_wback_inv(unsigned long _start,size_t _size)
+{
+ flush_dcache_range(_start, (_start + _size));
+}
#else /* ! CONFIG_NOT_COHERENT_CACHE */
/*
* Cache coherent cores.
*/
-#define dma_cache_inv(_start,_size)do { } while (0)
-#define dma_cache_wback(_start,_size) do { } while (0)
-#define dma_cache_wback_inv(_start,_size) do { } while (0)
+static inline void dma_cache_inv(unsigned long _start,size_t _size) {}
+static inline void dma_cache_wback(unsigned long _start,size_t _size) {}
+static inline void dma_cache_wback_inv(unsigned long _start,size_t _size) {}
-#define __dma_alloc_coherent(gfp, size, handle)NULL
-#define __dma_free_coherent(size, addr)do { } while (0)
-#define __dma_sync(addr, size, rw) do { } while (0)
-#define __dma_sync_page(pg, off, sz, rw) do { } while (0)
+static inline void *__dma_alloc_coherent(size_t size, dma_addr_t handle, int
gfp) { return NULL; }
+static inline void __dma_free_coherent(size_t size, void *vaddr) {}
+static inline void __dma_sync(void *vaddr, size_t size, int rw) {}
+static inline void __dma_sync_page(struct page *pg, unsigned long off, size_t
sz, int rw) {}
#endif /* ! CONFIG_NOT_COHERENT_CACHE */
-#define dma_supported(dev, mask) (1)
+static inline int dma_supported(struct device *dev, u64 dma_mask) { return 1; }
static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
- if (!dev-dma_mask || !dma_supported(dev, mask))
+ if (!dev-dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
*dev-dma_mask = dma_mask;
@@ -106,7 +115,11 @@
}
/* We do nothing. */
-#define dma_unmap_single(dev, addr, size, dir) do { } while (0)
+static inline void
+dma_unmap_single(struct device *dev, unsigned long addr, size_t size,
+enum dma_data_direction direction)
+{
+}
static inline dma_addr_t
dma_map_page(struct device *dev, struct page *page,
@@ -121,7 +134,9 @@
}
/* We do nothing. */
-#define dma_unmap_page(dev, handle, size, dir) do { } while (0)
+static inline void
+dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction direction) {}
static inline int
dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
@@ -141,7 +156,9 @@
}
/* We don't do anything here. */
-#define dma_unmap_sg(dev, sg, nents, dir) do { } while (0)
+static inline void
+dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
+enum dma_data_direction dir) {}
static inline void
dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
@@ -190,9 +207,9 @@
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
#ifdef CONFIG_NOT_COHERENT_CACHE
-#define dma_is_consistent(d) (0)
+static inline int dma_is_consistent(dma_addr_t dma_handle) { return 0; }
#else
-#define dma_is_consistent(d) (1)
+static inline int dma_is_consistent(dma_addr_t dma_handle) { return 1; }
#endif
static inline int dma_get_cache_alignment(void)
--
Jason McMullan jason.mcmullan at timesys.com
TimeSys Corporation
Second Attempt: Driver model usage on embedded processors
On Mon, 2004-12-06 at 23:03 -0600, Kumar Gala wrote: The intent was that I would use the platform_data pointer to pass board specific information to the driver. We would have board specific code which would fill in the information. The question I have is how to handle the device variant information which is really static? I use a 'struct device_ethernet_data' in my MPC85xx platform-device patches at http://www.evillabs.net/~gus/patches That seems to work well, and we could move it from include/asm-ppc/device-ethernet.h to include/linux/device-ethernet.h to make it more arch-independant. That covers MAC addrs and phy locations. As for PHY IRQ, that's a thornier issue. For now, I put that in the ethernet device's resource list. -- Jason McMullan jason.mcmullan at timesys.com
[PATCH] include/asm-ppc/dma-mapping.h macro patch
Signed-off-by: Jason McMullan jason.mcmullan at timesys.com
Summary: [ppc] dma-mapping.h - Fix macro semantics
Description:
This patch makes the macros for dma_* semantically
equivalent to the functions they mask. For example,
dma_cache_inv(func_with_side_effects(), sizeof(foo))
will execure 'func_with_side_effects()' in the function
case, but would not execute it in the macro case.
This patch fixes this discrepancy.
Comment: More landmines like this may be all over the kernel.
Janitor project, anyone?
--- linux-2.6.9.old/include/asm-ppc/dma-mapping.h 2004-12-07
08:14:32.769502853 -0500
+++ linux-2.6.9/include/asm-ppc/dma-mapping.h 2004-12-07 08:14:02.777362775
-0500
@@ -36,22 +36,22 @@
* Cache coherent cores.
*/
-#define dma_cache_inv(_start,_size)do { } while (0)
-#define dma_cache_wback(_start,_size) do { } while (0)
-#define dma_cache_wback_inv(_start,_size) do { } while (0)
-
-#define __dma_alloc_coherent(gfp, size, handle)NULL
-#define __dma_free_coherent(size, addr)do { } while (0)
-#define __dma_sync(addr, size, rw) do { } while (0)
-#define __dma_sync_page(pg, off, sz, rw) do { } while (0)
+#define dma_cache_inv(_start,_size)do { (void)(_start);
(void)(_size); } while (0)
+#define dma_cache_wback(_start,_size) do { (void)(_start);
(void)(_size); } while (0)
+#define dma_cache_wback_inv(_start,_size) do { (void)(_start);
(void)(_size); } while (0)
+
+#define __dma_alloc_coherent(gfp, size, handle)
((void)(gfp),(void)(size),(void)(handle),NULL)
+#define __dma_free_coherent(size, addr)do { (void)(size);
(void)(addr); } while (0)
+#define __dma_sync(addr, size, rw) do { (void)(addr);
(void)(size); (void)(rw); } while (0)
+#define __dma_sync_page(pg, off, sz, rw) do { (void)(pg); (void)(off);
(void)(sz); (void)(rw); } while (0)
#endif /* ! CONFIG_NOT_COHERENT_CACHE */
-#define dma_supported(dev, mask) (1)
+#define dma_supported(dev, mask) ((void)(dev), (void)(mask), 1)
static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
- if (!dev-dma_mask || !dma_supported(dev, mask))
+ if (!dev-dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
*dev-dma_mask = dma_mask;
@@ -121,7 +121,7 @@
}
/* We do nothing. */
-#define dma_unmap_page(dev, handle, size, dir) do { } while (0)
+#define dma_unmap_page(dev, handle, size, dir) do { (void)(dev);
(void)(handle); (void)(size); (void)(dir); } while (0)
static inline int
dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
@@ -141,7 +141,7 @@
}
/* We don't do anything here. */
-#define dma_unmap_sg(dev, sg, nents, dir) do { } while (0)
+#define dma_unmap_sg(dev, sg, nents, dir) do { (void)(dev); (void)(sg);
(void)(nents); (void)(dir); } while (0)
static inline void
dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle,
@@ -190,9 +190,9 @@
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
#ifdef CONFIG_NOT_COHERENT_CACHE
-#define dma_is_consistent(d) (0)
+#define dma_is_consistent(d) ((void)(d), 0)
#else
-#define dma_is_consistent(d) (1)
+#define dma_is_consistent(d) ((void)(d), 1)
#endif
static inline int dma_get_cache_alignment(void)
--
Jason McMullan jason.mcmullan at timesys.com
TimeSys Corporation
MPC8560 FCCs
Out of curiosity, has *anyone* gotten the MPC8560's (rev 1 OR Rev 2) FCCs to generate proper ethernet frames? I am having a lot of trouble with them. The TSECs work just fine. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC85xx support
On Thu, 2004-04-15 at 11:35, Kumar Gala wrote: We have been keeping the linuxppc-2.4 bitkeeper in sync with our work for 85xx. See http://penguinppc.org/dev/kernel.shtml on how to get access. I have a raft of MPC85xx (specifically, MPC8560ADS support) for 2.6.4 if anyone wants them. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8560ADS issues
On Thu, 2004-03-11 at 10:43, Matthew S. McClintock wrote: What version of u-boot are you using? There was a patch around Feb. 24th that fixed some things in the ethernet driver for u-boot. Although since you seem to have the TSEC ports working it seems you have the latest version. Latest CVS. But my questions are about *Linux*. I'm running Linux 2.6.0 with a port of the MPC8560 support from LinuxPPC 2.4.x. Got the Gianfar (TSEC) port to work just fine, and I can see the PHYs for the FCCs, and I get *TX* interrupts, and *sometimes* get packets out the wire, but no RX, and often TXs with no packets. -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8560ADS issues
I'm trying to work with FCCs on my PowerQuick III with a MPC8560 Rev 1, and I'm having quite a difficult time attempting to get the FCC ethernet ports to work. The GigE (TSEC) ports work just fine, but the FCC ports don't seem to TX or RX anything. No IRQs from the FCC, but I get IRQs from the PHYs Switch settings: SW4: 1-4 ON, 5-8 OFF SW10: 1 ON, 2-6 OFF, 7-8 ON SW13: 1 OFF, 2-3 ON J23,J22: MII(std) J27,J31: MII I have also verified that both of the FCC PHY's on the MII bus are visible (at PHY IDs 2 and 3). Has anyone had any success with the MPC8560ADS and FCCs? In either Linux or u-boot? -- Jason McMullan jason.mcmullan at timesys.com TimeSys Corporation ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
