Re: Enabling MBX in MPC5121 - OGLES kernel modules
Einar, On Fri, Nov 25, 2011 at 08:20:30AM +, Einar Már Björgvinsson wrote: Wanted to repeat my previous email about enabling MBX in MPC5121. Anybody out there who can assist me? This list is about open source software. The core you are using is from Imagination Technologies, they do not give out any documentation. This means that the community on this mailing list cannot help you. Please go to the Imagination or Freescale support and tell them that you want to use their graphics core with the mainline kernel. Maybe they can help you. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
Robin, On Tue, Aug 09, 2011 at 10:06:04PM -0500, Robin Holt wrote: In working with the socketcan developers, we have come to the conclusion the Documentation...fsl-flexcan.txt device tree documentation needs to be cleaned up. The driver does not depend upon any properties other than the required properties so we are removing the file. Additionally, the p1010*dts* files are not following the standard for node naming in that they have a trailing -v1.0. Signed-off-by: Robin Holt h...@sgi.com To: Marc Kleine-Budde m...@pengutronix.de, To: Wolfgang Grandegger w...@grandegger.com, To: U Bhaskar-B22300 b22...@freescale.com To: Scott Wood scottw...@freescale.com Cc: socketcan-c...@lists.berlios.de, Cc: net...@vger.kernel.org, Cc: PPC list linuxppc-dev@lists.ozlabs.org Cc: Kumar Gala ga...@kernel.crashing.org --- .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 arch/powerpc/boot/dts/p1010rdb.dts |8 --- arch/powerpc/boot/dts/p1010si.dtsi |8 +- 3 files changed, 4 insertions(+), 73 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt I suggest that you set devicetree-disc...@lists.ozlabs.org and Grant Likely on Cc: for this patch. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc5200 fec error
Wolfram, have you seen this mail? You recently tested -rt on 2.6.29, right? Did you only test that on the customer hardware or also on the phyCORE-MPC5200B? rsc On Mon, May 18, 2009 at 01:36:27PM -0400, Eric Millbrandt wrote: Hello all, I am testing a 2.6.29.3 (with preempt_rt patches) kernel on a phytec pcm030 and am getting a kernel hang when testing the fec Ethernet controller. The error only occurs when running the preempt-patched kernel, an unmodified kernel works fine. Is anyone out there using preempt_rt on an MPC5200 successfully? Eric r...@rudolph-ui:/root iperf -c linux-5200bdevl01 -P 2 -i 1 -p 5001 -f k -t 600 Client connecting to linux-5200bdevl01, TCP port 5001 TCP window size: 36.2 KByte (default) [ 4] local 10.1.4.88 port 37872 connected with 10.1.5.234 port 5001 [ 3] local 10.1.4.88 port 37871 connected with 10.1.5.234 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 3824 KBytes 31326 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 3656 KBytes 29950 Kbits/sec [SUM] 0.0- 1.0 sec 7480 KBytes 61276 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 1.0- 2.0 sec 3760 KBytes 30802 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 1.0- 2.0 sec 3752 KBytes 30736 Kbits/sec [SUM] 1.0- 2.0 sec 7512 KBytes 61538 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 2.0- 3.0 sec 3728 KBytes 30540 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 2.0- 3.0 sec 3816 KBytes 31261 Kbits/sec [SUM] 2.0- 3.0 sec 7544 KBytes 61800 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 3.0- 4.0 sec 3712 KBytes 30409 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 3.0- 4.0 sec 3824 KBytes 31326 Kbits/sec [SUM] 3.0- 4.0 sec 7536 KBytes 61735 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 4.0- 5.0 sec 3968 KBytes 32506 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 4.0- 5.0 sec 3624 KBytes 29688 Kbits/sec [SUM] 4.0- 5.0 sec 7592 KBytes 62194 Kbits/sec [ 5761.999175] net eth0: transmit queue overrun [ 5762.003591] net eth0: transmit queue overrun [ 5762.007948] net eth0: transmit queue overrun [ 5762.012302] net eth0: transmit queue overrun [ 5762.016658] net eth0: transmit queue overrun [ 5762.021013] net eth0: transmit queue overrun [ 5762.025381] net eth0: transmit queue overrun [ 5762.029735] net eth0: transmit queue overrun [ 5762.034090] net eth0: transmit queue overrun [ 5762.038445] net eth0: transmit queue overrun [ 5767.000928] net eth0: transmit queue overrun [ 5767.005278] net eth0: transmit queue overrun [ 5767.009634] net eth0: transmit queue overrun [ 5767.013990] net eth0: transmit queue overrun [ 5767.018345] net eth0: transmit queue overrun [ 5767.022701] net eth0: transmit queue overrun ?. _ This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx: add Phytec phyCORE-MPC5200B-IO board (pcm032)
On Sun, Mar 01, 2009 at 09:33:16PM -0700, Grant Likely wrote: On Sun, Mar 1, 2009 at 7:19 PM, Jon Smirl jonsm...@gmail.com wrote: Would it be easier to get Pengutronix to release a new u-boot for the pcm030? I'm using U-Boot 1.2.0-mpc5200b-tiny-2 (Apr 17 2007 - 11:49:20). Only if it is a chip IO setup problem (like port_config or clock setup). Otherwise the kernel should be setting up the PCI controller correctly. Regardless, I don't think the kernel should be crashing when PCI is in a funny state. Ack; I didn't follow the thread in detail, but if possible I'd like to avoid bootloader updates; it's quite a lot of effort because there are thousends of devices in the field, not to mention the whole qualification mechanics at Phytec. Wolfram can check the issue when being back in the office. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rt on PowerPC
Frank, On Thu, Jan 29, 2009 at 03:21:55PM -0800, Frank Rowand wrote: Thanks! I have not yet had the chance to apply any arch patches yet. I do plan on doing so after getting the code mostly working on x86. Your email can at an opportune time for me... I was starting to try 2.6.28-rt on ARM and quickly came to the conclusion that the arch patches weren't the focus yet. But I'm currently side-tracked with getting my board to even boot a vanilla 2.6.28 kernel first. Do you expect to get to the arches in the next week or two? If not, I may head down that path for ARM myself. Uwe has collected some patches for ARM here: http://thread.gmane.org/gmane.linux.ports.arm.kernel/52108/focus=787937 You might want to try them before starting, in order to avoid duplicate work. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: toolchain for building linux-2.6.27.8 or 2.6.28.1 ...
Hi Mike, On Thu, Jan 29, 2009 at 01:52:00PM -0600, Mike Timmons wrote: Questions: 1) if I want to cross-compile a kernel later than 2.6.24 to hopefully get better WAN device support (and clearer options for fw loading), which kernel should I try, and which toolchain? OSELAS.Toolchain-1.99.2 is known to build working kernels for powerpc, currently tested for 603e (MPC5200B). We have gcc-4.3.2 at the moment. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200B and the CAN interface
On Sat, Nov 08, 2008 at 05:32:35AM -0700, Gary Thomas wrote: I'm pretty sure this is just the SocketCAN interface. You still need a hardware driver (and one which is SocketCAN compatible). I don't see such a driver for the MSCAN (the hardware on the MPC5200) in the stock 2.6.27 tree. The drivers for MPC5200B's mscan are still in the SocketCAN repository, right. The team is working on getting the patches ready for mainline. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Mon, Jun 09, 2008 at 11:13:35AM +0200, Sascha Hauer wrote: I think partitions shouldn't go into the default device tree, as people may have different partitioning. It is also a chicken-and-egg thing, because the oftree would describe the partition it is in. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comments on device tree for pcm030
On Sun, Jun 08, 2008 at 03:08:33PM -0400, Jon Smirl wrote: There should be an i2c entry for the eeprom but I don't know the part number for it. Wolfram has oftree bindings for the new at24 driver which will be used in combination with this board. For patches, please see the i2c list. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote: Update dts files to current format Is it somehow possible that this device tree stuff is *not* changed over and over again and break everything out there? When people have not even agreed on basic things like decimal vs. hex numbers, the whole idea should be developed out-of-tree, then stabilize and *then* be submitted to the Linux mainline. Is it also really necessary to change like gpt vs. timer and pic vs. interrupt-controller all the time? If you compare the last mainline kernels, each one got a fundamental change in the naming, each time breaking anyone who doesn't have his stuff in the mainline yet. Sorry, but this is simply annoying, and the whole the only thing we have to do is to define it once and be done then is crap. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc5200: add interrupt type function
On Tue, Apr 15, 2008 at 05:29:54PM +0200, Robert Schwebel wrote: From: Sascha Hauer [EMAIL PROTECTED] Add a set_type function for external (GPIO) interrupts. Signed-off-by: Juergen Beisert [EMAIL PROTECTED] Signed-off-by: Sascha Hauer [EMAIL PROTECTED] As we didn't get negative feedback yet, could this go into the 2.6.26 merge window? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
fec_mpc5200: reset FEC on error
From: Sascha Hauer [EMAIL PROTECTED]
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): When this
occurs, software must ensure both the FIFO Controller and BestComm are
soft-reset.
* On any other error (non-TFINT) interrupt, just issue a debug message.
Signed-off-by: Sascha Hauer [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
Index: drivers/net/fec_mpc52xx.c
===
--- drivers/net/fec_mpc52xx.c.orig
+++ drivers/net/fec_mpc52xx.c
@@ -491,20 +491,23 @@
out_be32(fec-ievent, ievent); /* clear pending events */
- if (ievent ~(FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
- if (ievent ~FEC_IEVENT_TFINT)
- dev_dbg(dev-dev, ievent: %08x\n, ievent);
+ /* on fifo error, soft-reset fec */
+ if (ievent (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
+
+ if (net_ratelimit() (ievent FEC_IEVENT_RFIFO_ERROR))
+ dev_warn(dev-dev, FEC_IEVENT_RFIFO_ERROR\n);
+ if (net_ratelimit() (ievent FEC_IEVENT_XFIFO_ERROR))
+ dev_warn(dev-dev, FEC_IEVENT_XFIFO_ERROR\n);
+
+ mpc52xx_fec_reset(dev);
+
+ netif_wake_queue(dev);
return IRQ_HANDLED;
}
- if (net_ratelimit() (ievent FEC_IEVENT_RFIFO_ERROR))
- dev_warn(dev-dev, FEC_IEVENT_RFIFO_ERROR\n);
- if (net_ratelimit() (ievent FEC_IEVENT_XFIFO_ERROR))
- dev_warn(dev-dev, FEC_IEVENT_XFIFO_ERROR\n);
-
- mpc52xx_fec_reset(dev);
+ if (ievent ~FEC_IEVENT_TFINT)
+ dev_dbg(dev-dev, ievent: %08x\n, ievent);
- netif_wake_queue(dev);
return IRQ_HANDLED;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
mpc5200: add interrupt type function
From: Sascha Hauer [EMAIL PROTECTED]
Add a set_type function for external (GPIO) interrupts.
Signed-off-by: Juergen Beisert [EMAIL PROTECTED]
Signed-off-by: Sascha Hauer [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 ++
1 file changed, 38 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_pic.c
===
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c.orig2008-04-15
11:25:29.0 +0200
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c 2008-04-15 11:25:39.0
+0200
@@ -18,6 +18,7 @@
#undef DEBUG
+#include linux/interrupt.h
#include linux/irq.h
#include linux/of.h
#include asm/io.h
@@ -109,11 +110,48 @@
io_be_setbit(intr-ctrl, 27-l2irq);
}
+static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ u32 ctrl_reg, type;
+ int irq;
+ int l2irq;
+
+ irq = irq_map[virq].hwirq;
+ l2irq = (irq MPC52xx_IRQ_L2_MASK) MPC52xx_IRQ_L2_OFFSET;
+
+ pr_debug(%s: irq=%x. l2=%d flow_type=%d\n, __func__, irq, l2irq,
flow_type);
+
+ switch (flow_type) {
+ case IRQF_TRIGGER_HIGH:
+ type = 0;
+ break;
+ case IRQF_TRIGGER_RISING:
+ type = 1;
+ break;
+ case IRQF_TRIGGER_FALLING:
+ type = 2;
+ break;
+ case IRQF_TRIGGER_LOW:
+ type = 3;
+ break;
+ default:
+ type = 0;
+ }
+
+ ctrl_reg = in_be32(intr-ctrl);
+ ctrl_reg = ~(0x3 (22 - (l2irq * 2)));
+ ctrl_reg |= (type (22 - (l2irq * 2)));
+ out_be32(intr-ctrl, ctrl_reg);
+
+ return 0;
+}
+
static struct irq_chip mpc52xx_extirq_irqchip = {
.typename = MPC52xx IRQ[0-3] ,
.mask = mpc52xx_extirq_mask,
.unmask = mpc52xx_extirq_unmask,
.ack = mpc52xx_extirq_ack,
+ .set_type = mpc52xx_extirq_set_type,
};
/*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fec_mpc5200: reset FEC on error
On Tue, Apr 15, 2008 at 10:29:26AM -0500, Kumar Gala wrote: You really need to also copy netdev and patches to drivers/net. Hm? Sorry, don't understand what you mean. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
fec_mpc5200: reset FEC on error
From: Sascha Hauer [EMAIL PROTECTED]
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): When this
occurs, software must ensure both the FIFO Controller and BestComm are
soft-reset.
* On any other error (non-TFINT) interrupt, just issue a debug message.
v2 changed to -p1 and posted on linuxppc list (2008-04-15).
v1 posted on linuxppc list (2008-04-15).
Signed-off-by: Sascha Hauer [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
Index: drivers/net/fec_mpc52xx.c
===
--- a/drivers/net/fec_mpc52xx.c.orig
+++ b/drivers/net/fec_mpc52xx.c
@@ -491,20 +491,23 @@
out_be32(fec-ievent, ievent); /* clear pending events */
- if (ievent ~(FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
- if (ievent ~FEC_IEVENT_TFINT)
- dev_dbg(dev-dev, ievent: %08x\n, ievent);
+ /* on fifo error, soft-reset fec */
+ if (ievent (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
+
+ if (net_ratelimit() (ievent FEC_IEVENT_RFIFO_ERROR))
+ dev_warn(dev-dev, FEC_IEVENT_RFIFO_ERROR\n);
+ if (net_ratelimit() (ievent FEC_IEVENT_XFIFO_ERROR))
+ dev_warn(dev-dev, FEC_IEVENT_XFIFO_ERROR\n);
+
+ mpc52xx_fec_reset(dev);
+
+ netif_wake_queue(dev);
return IRQ_HANDLED;
}
- if (net_ratelimit() (ievent FEC_IEVENT_RFIFO_ERROR))
- dev_warn(dev-dev, FEC_IEVENT_RFIFO_ERROR\n);
- if (net_ratelimit() (ievent FEC_IEVENT_XFIFO_ERROR))
- dev_warn(dev-dev, FEC_IEVENT_XFIFO_ERROR\n);
-
- mpc52xx_fec_reset(dev);
+ if (ievent ~FEC_IEVENT_TFINT)
+ dev_dbg(dev-dev, ievent: %08x\n, ievent);
- netif_wake_queue(dev);
return IRQ_HANDLED;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: State of the MPC5200 PSC AC97 driver
Hi Matt, On Thu, Apr 10, 2008 at 04:25:20PM +0100, Matt Sealey wrote: I have a copy of the driver I hacked to work with the new PSC framework but it doesn't work anymore - I have no idea why. Mail me privately if you want it, I have no time to make patches or look for a good reason for the breakages, but it compiles at least. The Efika hack should be gone now (irrelevant since we released a firmware that obseletes it) and the other fixmes should be by the wayside considering the fscking thing doesn't play sound anymore... I'd be interested as well; do I read your mail right that you have already managed to hear sound coming out of the MPC5200B PSC AC97 interface? You would be the first one I've heared of, so it would definitely be interesting to see your code. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
Hi Grant, On Tue, Apr 08, 2008 at 03:26:11PM -0600, Grant Likely wrote: I disagree and that is not my point. Well, having something like a device tree that describes the hardware is definitely a good thing, in general. Now, if out-of-tree ports continue to break then we've got a problem that needs to be fixed. Right, that's the point. Don't get me wrong, I'm deeply against maintaining large code bases out-of-tree. But it shows in this case that we have a maintenance problem with the current oftree concept. When a simple BSP that supports almost nothing than CPU, mem, serial console and flash needs 1 week of hacking from an experienced kernel hacker, just in order to get all the string changes right, something is wrong. Once a binding is established (which usually takes a few kernel releases) it should be very stable and even if the definition of ideal is changed, backwards compatibility must be maintained. That's theory, but in practise we see it changing every second day. The ARM method of using just a device number is so much easier ... Only if the assumption is made that very little data needs to be shared between the kernel and the firmware. The moment you try to do something more complex you either have the nightmare of bd_info or you use a structured data format (like the device tree) I agree that the usual ARM hardwares are much less complicated and configurable than what's available elsewhere. We usually need the information this is board FOO_BAR, maybe, if it is a module, on a BAZ baseboard, and this is everything we need to register the platform devices in some arch/arm/mach-*/my_cpu.c and arch/arm/mach-*/my_board.c file. On another node, there are platforms where a device number is unworkable. For example, for Linux on an FPGA like the Xilinx Virtex, there would need to be a new platform number every time the FPGA bitstream was updated because it is effectively an entirely different platform. Well, we have done FPGA based boards with ARM in the past, and we've just added hardware auto-detection to the IP cores. Finally, using a device number means you need to encode into the kernel the exact layout of every platform it supports. That adds up to a lot of code in a real hurry; even if most of it is just boilerplate instantiations. You are right in general. However, it doesn't change the fact that we are living in maintenance-nightmare land right now ... Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: State of the MPC5200 PSC AC97 driver
On Thu, Apr 10, 2008 at 12:44:43PM +0200, Marian Balakowicz wrote: Last year you have posted a MPC5200 PSC AC97 driver patch [PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface. with the following comment: Not quite a clean driver, but it get things done (well, mostly). Only included to be able to test functionalityi/usage of the BestComm driver. There are various FIXMEs and commented out code here and there. Could you elaborate a bit on the overall state of the driver's functionality, which areas need improvement and attention? Seems that you mainly tested BestComm with this driver, what was the overall BestComm performance, any issues here? Did you use any specific test setup involving some dedicated application, etc.? Did anyone else tried it and/or has a updated version or can share experience? Sidenote: last time we tried (2.6.23.1), the AC97 driver didn't work, tested on the phyCORE-MPC5200B-tiny board. No sound, just a little bit noise which can be muted with the mixer. And music finishes about 7 times as fast as it usually should. So we didn't manage to make it work yet. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote: It may be ideal, but I don't think it is realistic. I'm now of the firm opinion that device trees and firmware are *never* perfect. Especially when the definition of perfect is a moving target. Well observed; isn't this the prove of the assumption that the whole device tree idea is not working? It is *always* inconsistent and it is *maintenance hell* because out-of-tree ports do *always* breakt because of string inconsistencies. We have just ported a 8260 board from 2.6.22 to 2.6.25 and it is almost 100% oftree porting. And you do not even have a single point of a parser, because all this string parsing is completely scattered all over the tree. The ARM method of using just a device number is so much easier ... Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Generic MMC-over-SPI binding?
On Tue, Jan 08, 2008 at 03:22:00PM +0100, Simon Richter wrote: in an embedded system similar to the lite5200 board, there is an MMC card socket connected to one of the PSCs. Ideally, I'd like to express this fact via the device tree and have the kernel bind the mmc-spi driver to the SPI interface, but I cannot find any place where to insert this code that I feel comfortable with. - It is not a board-specific thing, because any board can just use any SPI bus for MMC. - The mmc-spi driver appears to be platform independent, so I'm not sure OF bindings should be added to it. - The generic device tree scanning does not contain any special cases yet, so I don't want to add one. My current thought is to create a new driver that just handles MMC on PSCs in SPI mode by gluing all the relevant drivers together, but that doesn't seem optimal to me either. You know this driver? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/mmc/host/mmc_spi.c;h=365024b83d3da9df9b6e4f7a9d4cf6d216ba523d;hb=HEAD Or is your question how to express this in the device tree? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC5200] problem running FEC and ATA
On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote: does any one succeed running a functional FEC and ATA (pata) running together? Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here: http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/ We've recently made the -6 release which supports ATA; although I'm not sure if the tests were done with networking ATA at the same time I assume yes (at least while doing nfsroot). We'll re-check your scenario. Note that there has been quite some activity wrt. MPC5200, bestcom and fec in the mainline recently. You should test the latest 2.6.24-rc kernel. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC5200] problem running FEC and ATA
On Sun, Dec 16, 2007 at 07:28:40PM +0200, Arnon Kaufman wrote: Robert Schwebel wrote: On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote: does any one succeed running a functional FEC and ATA (pata) running together? Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here: http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/ thanks, my kernels are already patched and still observing that kind of behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2. playing with the XLB Master's enable and priority lead to significant changes (good ones) in the rate of corruption appearance. I'm afraid of the new priority I've set, as that may lead to lockups on the XLB, still investigating. Do you have a reproducable test scenario we can try on our hardware? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote: diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 9f3a4cd..12453e2 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -220,7 +220,17 @@ config I2C_PIIX4 config I2C_IBM_IIC tristate IBM PPC 4xx on-chip I2C interface - depends on IBM_OCP + depends on !PPC_MERGE + help + Say Y here if you want to use IIC peripheral found on + embedded IBM PPC 4xx based systems. Can we agree on one nomenclature - either i2c or iic? + This driver can also be built as a module. If so, the module + will be called i2c-ibm_iic. Are these drivers the same functionality (host i2c driver for 4xx)? If yes, shouldn't all in-tree users be migrated over and the old style driver be removed (with deprecation period)? +#define DBG_LEVEL 0 + +#ifdef DBG +#undef DBG +#endif + +#ifdef DBG2 +#undef DBG2 +#endif + +#if DBG_LEVEL 0 +# define DBG(f,x...)printk(KERN_DEBUG ibm-iic f, ##x) +#else +# define DBG(f,x...)((void)0) +#endif +#if DBG_LEVEL 1 +# define DBG2(f,x...) DBG(f, ##x) +#else +# define DBG2(f,x...) ((void)0) +#endif Any reason why you can't use pr_debug? Robert -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SYSFS: need a noncaching read
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote: I have developed a device driver and use the sysFS to export some registers to userspace. Uuuh, uggly. Don't do that. Device drivers are there to abstract things, not to play around with registers from userspace. I opened the sysFS File for one register and did some reads from this File, but I alwas becoming the same value from the register, whats not OK, because they are changing. So I found out that the sysFS caches the reads ... :-( Yes, it does. What you can do is close()ing the file handle between accesses, which makes it work but is slow. Is there a way to retrigger the reads (in that way, that the sysFS rereads the values from the driver), without closing and opening the sysFS Files? Or must I better use the ioctl () Driver-interface for exporting these registers? What kind of problem do you want to solve? Userspace is for applications, and applications usually don't have to know about hardware details like registers. So if you have to do something every 10 ms from userspace, your design is probably wrong. If you absolutely need to do such things from userspace, have a look at uio. But in most cases the answer is: make a proper abstraction for the problem you wanna solve and write a proper driver. Robert -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote: Your approach would work I suppose though it's a bit ugly. Speaking of uggly, I'm still wondering why this oftree stuff for powerpc must be s complicated. If you come from the ARM-linux world like we do, the whole powerpc BSP stuff looks like a completely overengineered piece of code, introducing complexity where it isn't necessary. But it may be that it's just me not knowing powerpc kernel requirements deeply enough :) For most of the devices on for example the MPC5200B and MPC8260 I would just model them as platform devices; there could be a simple oftree - oftree-interpreter - bunch of platform devices mapping. Is there a reason why there is sooo much interaction of the platform code with the oftree? We usually have the situation that, if something goes wrong, you have to change - the driver - the platform code - the oftree and they often contain redundant information (like names of oftree nodes, which change more often than some people's panties). Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
