Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
Henk, On Montag, 9. März 2009, Henk Stegeman wrote: I don't understand how this would work, Now I do one byte-swap, which works. -I byteswap in software, for 16-bit cycles by byte swapping and for 8 bit cycles by adding an offset of 1. (The byte swapping on the chipselect is off) Your advice includes two byteswaps, one by re-routing the data bus and one by enabling the byte swap on the chip-select. My experience is the chip select byte swap feature only works correctly if you connect a little endian device like I showed you. Or does one of them not really swap bytes? Let me show you how it works. You must ensure you can write/read data in any data width, but at the side of the little endian device it always must be in the correct endianess. This example uses a 32 bit data width, but it works for 16 bit, too. - LE shows how a real litte endian CPU would write data - MPC1 shows how MPC5200 will do it, without any byte swap and DO at the MPC5200 side is also D0 at the little endian device - MPC2 shows how MPC5200 will do it, with D0 at the MPC5200 side is D24 at the little endian device - MPC3 shows how MPC5200 will do it, connected like MPC2 but also the chip select byte swap feature enabled - LE DEV shows how the little endian device expects the data You want to write this data at the given offset into the little endian device: Bytes: 0:0x34, 1:0x12, 2:0x78, 3:0x56 Worte: 0:0x1234 2:0x5678 LONG:0:0x56781234 Writing as bytes: Bytes: 0:0x34, 1:0x12, 2:0x78, 3:0x56 Offset LEMPC1 MPC2 MPC3 LE DEV 0 0x34 0x56 0x34 0x34 0x34 1 0x12 0x78 0x12 0x12 0x12 2 0x78 0x12 0x78 0x78 0x78 3 0x56 0x34 0x56 0x56 0x56 ------ these are correct this is wrong Writing as words: Words: 0:0x1234 2:0x5678 Offset LE MPC1 MPC2 MPC3 LE DEV 0 0x34 0x78 0x12 0x34 0x34 (1) 0x12 0x56 0x34 0x12 0x12 2 0x78 0x34 0x56 0x78 0x78 (3) 0x56 0x12 0x78 0x56 0x56 ------- these are correct ---- these are wrong Writing as longs: LONG: 0:0x56781234 Offset LE MPC1 MPC2 MPC3 LE DEV 0 0x34 0x34 0x56 0x34 0x34 (1) 0x12 0x12 0x78 0x12 0x12 (2) 0x78 0x78 0x12 0x78 0x78 (3) 0x56 0x56 0x34 0x56 0x56 --- ------- these are correct -- this is wrong So, the MPC3 example always writes correct data. Hope it helps, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
Henk, On Freitag, 20. Februar 2009, Henk Stegeman wrote: - Any suggestions to what could be wrong here? Or does the MPC5200 in this case only byte swap u16 reads, but a u8 read is unchanged? You should not follow the Freescale bus signal names when you connect your external little endian device. Otherwise the offsets are always wrong. Do it in this way instead: MPC LE Device D[0..7] - D[24..31] D[8..15] - D[16..23] D[16..23] - D[8..15] D[24..31] - D[0..7] If you connect your device in such a way, just enable CS's byte swap feature depending on your bus size and you are done (no additional software manipulation required). Now you can write bytes, words or longs and you will always write the correct data into the corresponding device register. Hope it helps Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] powerpc/5200: Stop using device_type and port-number properties
Am Mittwoch, 21. Januar 2009 21:55 schrieb Grant Likely: [...] The whole 'port-number' scheme for assigning numbers to PSC uarts was always rather half baked and just adds complexity. Remove it from the driver. After this patch is applied, PSC UART numbers are simply assigned from the order they are found in the device tree (just like all the other devices). Userspace can query sysfs to determine what ttyPSC number is assigned to each PSC instance. Arrghh, the next time we have to touch every oftree of our supported boards to keep it work. Does it ever end? Juergen -- Pengutronix e.K. | Dipl.-Ing. Juergen Beisert | Industrial Linux Solutions | http://www.pengutronix.de/ | Vertretung Sued/Muenchen, Germany | Phone: +49-5121-206917-7| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: R: Installation on a MPC5200 based custom board
On Freitag, 5. Dezember 2008, [EMAIL PROTECTED] wrote: Now plugging-in USB: [EMAIL PROTECTED]: ~ #[ 17.228078] hub 1-0:1.0: state 7 ports 2 chg evt 0004 [EMAIL PROTECTED]: ~ #[ 17.233798] ppc-of-ohci f0001000.usb: GetStatus roothub.portstatus [1] = 0x00010101 CSC PPS CCS [EMAIL PROTECTED]: ~ #[ 17.242776] hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s [EMAIL PROTECTED]: ~ #[ 17.374796] hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 [EMAIL PROTECTED]: ~ #[ 17.450780] ppc-of-ohci f0001000.usb: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS [EMAIL PROTECTED]: ~ #[ 17.514787] usb 1-2: new full speed USB device using ppc-of-ohci and address 2 [EMAIL PROTECTED]: ~ #[ 24.027842] usb 1-2: khubd timed out on ep0in len=0/64 [EMAIL PROTECTED]: ~ #[ 29.199841] usb 1-2: khubd timed out on ep0in len=0/64 [EMAIL PROTECTED]: ~ #[ 34.307841] usb 1-2: khubd timed out on ep0in len=0/64 [EMAIL PROTECTED]: ~ #[ 34.382786] ppc-of-ohci f0001000.usb: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS [EMAIL PROTECTED]: ~ #[ 34.446789] usb 1-2: device descriptor read/64, error -110 [EMAIL PROTECTED]: ~ # [EMAIL PROTECTED]: ~ #cat /proc/interrupts CPU0 134: 5689 MPC52xx Peripherals Edge ohci_hcd:usb1 139:207 MPC52xx Peripherals Edge mpc52xx_psc_uart 143: 0 MPC52xx Peripherals Edge i2c-mpc 144: 0 MPC52xx Peripherals Edge i2c-mpc BAD: 0 [EMAIL PROTECTED]: ~ # we were thinking to some problem like: http://www.nabble.com/USB-support-on-mpc5200-broken-td19658810.html or http://www.nabble.com/MPC5200-PCI-interrupt-routing-p19608472.html Sounds like a wrong or missed clock configuration. Is your CDM 48 MHz Fractional Divider Configuration Register Field Descriptions (0x0210) setup correctly? Some kernel revisions guesses and fixes the setting, some other not. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200B: Trouble with config pins
Hi all, we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B CPU. These pins act as the interface to an external phy and also act as configurations pins to configure the size of the flash and other things. While the reset is active these pins should be in their high impedance state and the externally connected pull down resistors should define wire's voltage level. With the rising edge of the reset signal these levels will be latched into internal config registers. We are in trouble when we want to reboot the system (also watchdog based) or the internal watchdog barks and generates the CPU internal reset signal. In these cases these config pins will not change their level! So the wrong settings are latched in and our CPU is dead (misconfigured), sometimes a second reset helps, but most of the time only power cycling helps. What we see is: - at the pins ETH_0 and ETH_3 (both are output only, when used for ethernet) * With an external 10k pulldown these lines never change their 3.3V level even if the reset is active! * With an external 1k pulldown these lines change their 3.3V level down to something about 2.5V when the falling edge of the reset signal occurs. * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge to 0V occures. Problem here is, the internal watchdog's generated reset signal is much shorter, so the rising edge of this reset signal also latches in the wrong settings and the CPU is dead. Some other things we see. A reset while: - a running tftp command in U-Boot with disconnected network - system is always dead - a running tftp command in U-Boot with connected network - system restarts We can see in this case, the ETH_0 and ETH_3 are switching to low level *immediatly* with the falling edge of the reset signal - an activated interface (ifconfig up) in Linux with *disconnected* network - system is always dead - an activated interface (ifconfig up) in Linux with *connected* network - system is always dead Does anybody see a behaviour like ours on his/her MPC5200B based system? Does anybody have an idea what the difference between U-Boot und Linux could be? Bug? Feature? Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200B: Trouble with config pins
Hi Andre, On Freitag, 21. November 2008, Andre Schwarz wrote: Have a look at the manual chapter 4 (=Reset + Config). SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware reset. Looks like you should make use of the SRESET and trigger HRESET accordingly. I could solve this with _not_ using the internal watchdog but an external one (TPS3828), i.e. watchdog timeouts and reboots are always issued by PORESET. We are using an external watchdog now. But same behaviour. It hurts less, because we increase the length of the active reset signal to add more time to let the pin find its low level. But I'm not really happy about this solution... Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Using gpiolib to power off my system
Hi list, I want to use the gpiolib API in a routine that should poweroff the system (MPC5200B). I register my poweroff routine in the define_machine() macro as: [...] .power_off = my_power_off, [...] In this routine I'm using gpio_request(...), gpio_direction_output(...) and gpio_set_value(...) but nothing happens. When I set the GPIOs in the hard way (ioremap() + playing with the registers) the system switches off as expected. How to get some useful debug output at this late system state (printk does not work anymore)? Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
Benjamin, On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote: On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote: On Dienstag, 23. September 2008, Juergen Beisert wrote: What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. One should enable the internal USB clock. If done, it works... In 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24. It was removed because some 5200 platform do not use USB and should not enable the internal clock. In general, it is not the kernel's job to configure clocking and pin usage on the chip. Instead, it should be set correctly at power up by U-Boot. Or by the USB host driver :-) But how to deal with platform specific things like (in this case) unknown external clock or usage of the internal clock generator (= how to setup the frequency divider)? However, if firmware *cannot* be changed, there is a workaround. You can create a new platform specific board support file in arch/powerpc/platforms/52xx/ that matches against your specific board and performs the needed fixups. An example of this is lite5200.c. Many lite5200 boards have older versions of U-Boot installed which does not correctly configure clocks or port-config. So, lite5200.c matches to the board instead of mpc5200_simple.c so that the board specific fixups can be performed easily. You should do the same for your board. I tend to thing that drivers should deal with their own clocks. ACK. But only to switch them on and off. Not to configure them. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? ACK. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Dienstag, 23. September 2008, Juergen Beisert wrote: Matt, On Montag, 22. September 2008, Matt Sealey wrote: Juergen Beisert wrote: Hi, $ lspci 00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) USB driver (endianess???) or oftee or hardware problem? Anyone experience with VIA USB hardware on PowerPc? The USB driver should work fine, I have an Efika (MPC5200B) with that exact USB controller and revision and it's just fine and dandy. We also used to ship Via-based USB cards in the Pegasos Open Desktop Workstation (using Marvell Discovery II northbridge). The major difference here would be that PCI tree entries were created by a real OF implementation so may have reflected some hardware better; it is dynamically created on boot to a certain point, rather than a fixed device tree which may contain some errors. There seems to be a lot less data in our tree... What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. One should enable the internal USB clock. If done, it works... In 2.6.23 is was done in mpc52xx_common.c. It was removed in 2.6.24. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
Matt, On Montag, 22. September 2008, Matt Sealey wrote: Juergen Beisert wrote: Hi, $ lspci 00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) USB driver (endianess???) or oftee or hardware problem? Anyone experience with VIA USB hardware on PowerPc? The USB driver should work fine, I have an Efika (MPC5200B) with that exact USB controller and revision and it's just fine and dandy. We also used to ship Via-based USB cards in the Pegasos Open Desktop Workstation (using Marvell Discovery II northbridge). The major difference here would be that PCI tree entries were created by a real OF implementation so may have reflected some hardware better; it is dynamically created on boot to a certain point, rather than a fixed device tree which may contain some errors. There seems to be a lot less data in our tree... What Kernel do you run on your target? On my hardware a 2.6.23 still work as expected, but a 2.6.26 fails all the time. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 PCI interrupt routing
Hi,
my MPC5200 based platform has one PCI slot, with the following interrupt
routing:
PCI slot MPC5200
INT A IRQ0
INT B IRQ1
INT C IRQ2
INT D IRQ3
In my oftree I'm using these lines to describe this routing (slot's IDSEL is
0x18)
[...]
[EMAIL PROTECTED] {
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
device_type = pci;
compatible = fsl,mpc5200b-pci,fsl,mpc5200-pci;
reg = 0xfd00 0x100;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map = 0xc000 0x0 0x0 0x1 mpc5200_pic 0x0 0x0 0x3
0xc000 0x0 0x0 0x2 mpc5200_pic 0x1 0x1 0x3
0xc000 0x0 0x0 0x3 mpc5200_pic 0x1 0x2 0x3
0xc000 0x0 0x0 0x4 mpc5200_pic 0x1 0x3 0x3
;
clock-frequency = 0; // From boot loader
interrupts = 0x2 0x8 0x0 0x2 0x9 0x0 0x2 0xa 0x0;
interrupt-parent = mpc5200_pic;
bus-range = 0 0;
ranges = 0x4200 0x0 0x8000 0x8000 0x0 0x2000
0x0200 0x0 0xa000 0xa000 0x0 0x1000
0x0100 0x0 0x 0xb000 0x0 0x0100;
};
[...]
First: But /proc/interrupts states Edge type. From the documentation 0x3
(the last number per interrupt-map-line) should be low level, not edge.
$ cat /proc/interrupts
CPU0
16: 0 MPC52xx IRQ[0-3] Edge uhci_hcd:usb3
65: 0 MPC52xx IRQ[0-3] Edge uhci_hcd:usb4
66: 5 MPC52xx IRQ[0-3] Edge ehci_hcd:usb2
131: 58585 MPC52xx Peripherals Edge mpc52xx_psc_uart
133: 0 MPC52xx Peripherals Edge mpc52xx-fec_ctrl
134: 34 MPC52xx Peripherals Edge ohci_hcd:usb1
135: 0 MPC52xx Peripherals Edge mpc52xx_ata
143: 0 MPC52xx Peripherals Edge i2c-mpc
144: 36 MPC52xx Peripherals Edge i2c-mpc
192: 5815 MPC52xx SDMA Edge mpc52xx-fec_rx
193: 4512 MPC52xx SDMA Edge mpc52xx-fec_tx
BAD: 0
Second: When I load the drivers for the uhci/ehci PCI card I get:
[...]
usb 1-1: new high speed USB device using ehci_hcd and address 2
usb 1-1: device not accepting address 2, error -110
usb 1-1: new high speed USB device using ehci_hcd and address 3
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new high speed USB device using ehci_hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new high speed USB device using ehci_hcd and address 5
usb 1-1: device not accepting address 5, error -110
hub 1-0:1.0: unable to enumerate USB device on port 1
usb 1-2: new high speed USB device using ehci_hcd and address 6
usb 1-2: device descriptor read/64, error -110
[...]
uhci_hcd :00:18.0: Unlink after no-IRQ? Controller is probably using the
wrong IRQ.
[...]
$ lspci
00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 61)
00:18.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 61)
00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
USB driver (endianess???) or oftee or hardware problem?
Anyone experience with VIA USB hardware on PowerPc?
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Montag, 22. September 2008, Juergen Beisert wrote: $ lspci 00:18.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 61) 00:18.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) USB driver (endianess???) or oftee or hardware problem? Seems more a kernel problem. With a 2.6.23.1 at least MPC5200's internal OHCI still works (EHCI and UHCI unchecked yet). With a 2.6.26.3 also this OHCI fails. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] fec_mpc52xx: Don't call mpc52xx_fec_reset() in ISR
On Donnerstag, 10. Juli 2008, Grant Likely wrote: On Thu, Jul 10, 2008 at 02:39:09PM +0200, Wolfram Sang wrote: Hello, today, I was debugging a kernel crash on a board with a MPC5200B using 2.6.26-rc9. I found the following code in drivers/net/fec_mpc52xx.c: snip I assume the proper thing to do is to set a flag in the ISR and handle the soft reset later in some other context. Having never dealt with the network core and its drivers so far, I am not sure which place would be the right one to perform the soft reset. To not make things worse, I hope people with more insight to network stuff can deliver a suitable solution to this problem. Thanks for the bug report. I'll take a look. Some update: Enabling XLB pipelining let occure this error less often. Kernel disables this feature by default yet. The comment talks about cfr errate 292. that is valid for MPC5200A, but _it_seems_ no longer for MPC5200B. Has anybody experience if we can enabling pipelining on MPC5200B CPUs without triggering this bug? We currently are playing with this setting: Index: arch/powerpc/platforms/52xx/mpc52xx_common.c === --- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig +++ arch/powerpc/platforms/52xx/mpc52xx_common.c @@ -99,11 +99,11 @@ out_be32(xlb-master_pri_enable, 0xff); out_be32(xlb-master_priority, 0x); - /* Disable XLB pipelining -* (cfr errate 292. We could do this only just before ATA PIO -* transaction and re-enable it afterwards ...) + /* +* Enable pipelining, fixes FEC problems. The previous workaround seems +* not needed, as we have an MPC5200B (not A). */ - out_be32(xlb-config, in_be32(xlb-config) | MPC52xx_XLB_CFG_PLDIS); + out_be32(xlb-config, in_be32(xlb-config) ~MPC52xx_XLB_CFG_PLDIS); iounmap(xlb); } jbe -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerpc and ioremap
Am Donnerstag, 7. August 2008 11:54 schrieb Sébastien Chrétien:
Hello,
I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26 and
gcc 3.4.5.
I have used Uboot 1.2.
Linux seems running from _start to udbg_early_init(). That's why I
develloped a udbg_driver.
It must write in a register which is located at 0x2001b044. So I wrote :
void __iomem *p;
p=ioremap(0x2001b044,4);
iowrite32('O',p);
iowrite32('K',p);
try
p=ioremap(0x2001b000, 0x1000);
iowrite32('O',p + 0x44);
iowrite32('K',p + 0x44);
instead.
jbe
--
Dipl.-Ing. Juergen Beisert | 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-7 | 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
Jon, hmm, I tried the same, but with a 32MiB flash instead. And Linux-2.6.26-rc5 and the dtc-1.1.0. On Monday 09 June 2008 23:30, Jon Smirl wrote: This is my boot log: ff00.flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled RedBoot partition parsing not available Creating 6 MTD partitions on ff00.flash: 0x-0x0004 : ubootl 0x0004-0x0020 : kernel 0x0020-0x00f0 : jffs2 0x00f0-0x00f4 : uboot 0x00f4-0x00f8 : oftree 0x00f8-0x0100 : space Here is mine (with DEBUG on in physmap_of.c): [...] mpc52xx MII bus: probed net eth0: Using PHY at MDIO address 0 of-flash fe00.flash: of_flash device: fe00-fdff of-flash: probe of fe00.flash failed with error -16 TCP cubic registered [...] I'm confused about the fe0-fdff. These are the return values from the of_address_to_resource() call (in of_flash_probe() ). It should be fe0- instead. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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
Maybe everything in this small piece of my dts is wrong. But I don't know how
the correct way is. All I want is to define a 32MiB flash at the end if the
address space of my MPC5200B based system.
[...]
[EMAIL PROTECTED] {
model = fsl,lpb;
compatible = fsl,lpb;
ranges = 0x0 0xfe00 0x0200;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0x 0x0200;
bank-width = 4;
};
};
The dtc gives me the follwing output:
Warning (reg_format): reg property in /[EMAIL PROTECTED]/[EMAIL PROTECTED]
has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
Warning (ranges_format): ranges property in /[EMAIL PROTECTED] has invalid
length (12 bytes) (parent #address-cells == 1, child #address-cells == 2,
#size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value for
/[EMAIL PROTECTED]/[EMAIL PROTECTED]
Warning (avoid_default_addr_size): Relying on default #size-cells value for
/[EMAIL PROTECTED]/[EMAIL PROTECTED]
What does it mean?
At runtime I get:
[...]
of-flash fe00.flash: of_flash device: fe00-
CFI: Found no fe00.flash device at location zero
of-flash fe00.flash: do_map_probe() failed
[...]
What's going wrong? Any hint?
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | 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 Monday 09 June 2008 01:28, Grant Likely wrote: On Sun, Jun 8, 2008 at 1:08 PM, Jon Smirl [EMAIL PROTECTED] wrote: Why not a compatible field in the top of the tree? Then you wouldn't need to list the boards in mpc5200_simple.c. compatible = phytec,pcm030,simple-mpc5200; Here's the problem; what does compatible really mean at the board level? Does it mean the board has 100% of the same capabilities? Does it mean that it uses the same chip? Does it mean that the chip is configured in a particular way? It is really hard to define what a compatible value means at the board level. The meaning of compatible at the device level is very well defined, but that meaning does not extend well to the board level. Therefore, it is best to be conservative here and require a specific list of supported boards in platform code. Besides, it is really a Linux specific thing that is trying to be described. In Linux, we've decided to support as many 5200 boards as possible using the same platform code, but that may not be true, or it may be a different set of boards, when a different OS is used. To attempt to encode those decisions is overreaching the intent of using the device tree. Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... The RTC chip says pcf8563, phytec doc says it is a pcf8564. Sounds like a bug These devices are mostly the same. You can use the pcf8563 driver for the pcf8564. There should be an i2c entry for the eeprom but I don't know the part number for it. Yes, i2c devices should be described. Its a 24C32. I believe Wolfram has a newer OFtree for the pcm030 so I add him as CC. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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
Jon, On Monday 09 June 2008 14:37, Jon Smirl wrote: On 6/9/08, Juergen Beisert [EMAIL PROTECTED] wrote: Device tree has an entry for AC97 on PSC1. I don't think the Phytec module or carrier board has AC97 hardware. Might be a bug NACK. The baseboard for the pcm030 CPU board has AC97 hardware connected to PSC1. And it plays audio... I'm staring at a baseboard for the pcm030 in my hand, I don't see any AC97 hardware. It has two serial, two CAN, ethernet and power. Where's the AC97? It seems you have an old development hardware. Here I have the PCM-030-02REI (=CPU card) and PCM-973-tiny (=baseboard). The PCM-973-tiny comes with a Wolfson AC97 sound device. This is the current combination everyone can buy. http://www.phytec.com/products/rdk/PowerPC/phyCORE-MPC5200B-tinyRDK.html Yes. This kit contains the PCM-973-tiny with AC97 sound. Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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 Sunday 08 June 2008 21:08, Jon Smirl wrote:
What about the flash on the local bus? Could we use something like
this, or the same without the partition data?
[EMAIL PROTECTED] {
compatible = fsl,lpb;
ranges = 0 ff00 0100;
[EMAIL PROTECTED] {
compatible = cfi-flash;
reg = 0100;
bank-width = 2;
#size-cells = 1;
#address-cells = 1;
[EMAIL PROTECTED] {
label = ubootl;
reg = 0004;
};
[EMAIL PROTECTED] {
label = kernel;
reg = 0004 001c;
};
[EMAIL PROTECTED] {
label = jffs2;
reg = 0020 00D0;
};
[EMAIL PROTECTED] {
label = uboot;
reg = 00f0 0004;
};
[EMAIL PROTECTED] {
label = oftree;
reg = 00f4 0004;
};
[EMAIL PROTECTED] {
label = space;
reg = 00f8 0008;
};
};
};
Hmm, I tried with these setting (and many others) to make the flash on my
board work again.
But the physmap_of.c driver always fails. It tries to request the region
0xfe00 to 0x (my flash is 32MiB in size at 0xfe0 to
0x) and fails badly. What are the correct settings in the OFTree to
make the physmap_of.c driver work?
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
Matt, On Saturday 19 April 2008 14:02, Matt Sealey wrote: Grant Likely wrote: On Fri, Apr 18, 2008 at 12:11 PM, Matt Sealey [EMAIL PROTECTED] wrote: Juergen Beisert wrote: BTW, is anyone trying to shepherd this driver into the ALSA tree? Its out of my area of expertise and responsibility, so I haven't been pursuing it. We (well, I) were going to try but we got some oopses; from one thing or another, but with Juergen's fixes and cell-index in place, now it plays audio. Now it can be pushed to ALSA on that basis, but I'm still trying to get my head around where we need to throw patches and if it goes into ALSA Drivers first or the kernel or both? It's kind of convoluted compared to the ease of just CC'ing netdev or linux-ide.. Please don't forget what Sylvian said about this driver: I also completely skipped the 5200 (not B) support ... and your own I think it should be left noted here that the CCR size changed from 16 bits to 32 bits from 5200 to 5200B in order to reduce confusion.. Its not solved yet. So any user of an old MPC5200 will be surprised... Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
On Friday 18 April 2008 17:43, Peter Czanik wrote:
Hello,
Juergen Beisert írta:
Hi,
if someone is interested: Here the full patch to get sound support for
MPC5200b and a current 2.6.25 kernel.
First of all, thanks for fixing the driver. I just tested it on the
EFIKA, it (almost) works. In its current state loading the kernel module
results in a segfault and oops. The fix is to add a missing line to the
device-tree. The forth version of the EFIKA fix works fine (taken from
http://www.powerdeveloper.org/platforms/efika/devicetree ):
efika:~ # cat /mnt/sound.forth
\ FORTH
s /builtin/sound find-device
\ Audio is on PSC2, just for informational purposes
1 encode-int s cell-index property
device-end
efika:~ #
But trying to fix it up from prom_init.c does not seem to work, the
missing 'cell-index' property does not show up. Please let me know, how
to add it properly. Here is what I tried:
factory:/usr/src/linux-2.6.25 # diff -u
arch/powerpc/kernel/prom_init.c.orig arch/powerpc/kernel/prom_init.c
--- arch/powerpc/kernel/prom_init.c.orig2008-04-18
13:55:07.0 +0200
+++ arch/powerpc/kernel/prom_init.c 2008-04-18 16:26:51.0 +0200
@@ -2212,6 +2212,7 @@
static void __init fixup_device_tree_efika(void)
{
+ int sound_ci = 1;
int sound_irq[3] = { 2, 2, 0 };
int bcomm_irq[3*16] = { 3,0,0, 3,1,0, 3,2,0, 3,3,0,
3,4,0, 3,5,0, 3,6,0, 3,7,0,
@@ -2257,6 +2258,8 @@
rv = prom_getprop(node, interrupts, prop, sizeof(prop));
if (rv == PROM_ERROR) {
prom_printf(Adding sound interrupts property\n);
+prom_setprop(node, /builtin/sound, cell-index,
+ sound_ci, sizeof(int));
prom_setprop(node, /builtin/sound, interrupts,
sound_irq, sizeof(sound_irq));
}
factory:/usr/src/linux-2.6.25 #
Bye,
CzP
I'm not sure if cell-index is a correct property. I copied it from the uart
driver, because this driver needs something to distinguish between PSC1 and
PSC2. Maybe there is a better and correct oftree solution? Any oftree expert
here?
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RFC: MPC5200 PSC AC97 driver
)
+{
+ struct mpc52xx_ac97_priv *priv;
+
+ dev_dbg(op-dev, removing MPC52xx PSC AC97 driver\n);
+
+ priv = dev_get_drvdata(op-dev);
+ if (priv) {
+ /* Sound subsys shutdown */
+ snd_card_free(priv-card);
+
+ /* Low level HW shutdown */
+ mpc52xx_ac97_hwshutdown(priv);
+
+ /* Release bestcomm tasks */
+ free_irq(bcom_get_task_irq(priv-tsk_tx), priv);
+ bcom_gen_bd_tx_release(priv-tsk_tx);
+
+ /* Release resources */
+ iounmap(priv-psc);
+ free_irq(priv-irq, priv);
+ irq_dispose_mapping(priv-irq);
+ release_mem_region(priv-mem_start, priv-mem_len);
+ }
+
+ dev_set_drvdata(op-dev, NULL);
+
+ return 0;
+}
+
+
+static struct of_device_id mpc52xx_ac97_of_match[] = {
+ {
+ .type = sound,
+ .compatible = mpc5200b-psc-ac97, /* B only for now */
+ },
+};
+
+static struct of_platform_driver mpc52xx_ac97_of_driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
+ .match_table= mpc52xx_ac97_of_match,
+ .probe = mpc52xx_ac97_probe,
+ .remove = mpc52xx_ac97_remove,
+ .driver = {
+ .name = DRV_NAME,
+ },
+};
+
+/* */
+/* Module */
+/* */
+
+static int __init mpc52xx_ac97_init(void)
+{
+ int rv;
+
+ printk(KERN_INFO Sound: MPC52xx PSC AC97 driver\n);
+
+ rv = of_register_platform_driver(mpc52xx_ac97_of_driver);
+ if (rv) {
+ printk(KERN_ERR DRV_NAME :
+ of_register_platform_driver failed (%i)\n, rv);
+ return rv;
+ }
+
+ return 0;
+}
+
+static void __exit mpc52xx_ac97_exit(void)
+{
+ of_unregister_platform_driver(mpc52xx_ac97_of_driver);
+}
+
+module_init(mpc52xx_ac97_init);
+module_exit(mpc52xx_ac97_exit);
+
+MODULE_AUTHOR(Sylvain Munaut [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(DRV_NAME : Freescale MPC52xx PSC AC97 driver);
+MODULE_LICENSE(GPL);
+
Index: include/asm-powerpc/mpc52xx_psc.h
===
--- include/asm-powerpc/mpc52xx_psc.h.orig 2008-04-17 16:12:09.0
+0200
+++ include/asm-powerpc/mpc52xx_psc.h 2008-04-17 16:13:38.0 +0200
@@ -28,6 +28,10 @@
#define MPC52xx_PSC_MAXNUM 6
/* Programmable Serial Controller (PSC) status register bits */
+#define MPC52xx_PSC_SR_UNEX_RX 0x0001
+#define MPC52xx_PSC_SR_DATA_VAL0x0002
+#define MPC52xx_PSC_SR_DATA_OVR0x0004
+#define MPC52xx_PSC_SR_CMDSEND 0x0008
#define MPC52xx_PSC_SR_CDE 0x0080
#define MPC52xx_PSC_SR_RXRDY 0x0100
#define MPC52xx_PSC_SR_RXFULL 0x0200
@@ -132,8 +136,10 @@ struct mpc52xx_psc {
u8 reserved5[3];
u8 ctlr; /* PSC + 0x1c */
u8 reserved6[3];
- u16 ccr;/* PSC + 0x20 */
- u8 reserved7[14];
+ u32 ccr;/* PSC + 0x20 */
+ u32 ac97_slots; /* PSC + 0x24 */
+ u32 ac97_cmd; /* PSC + 0x28 */
+ u32 ac97_data; /* PSC + 0x2c */
u8 ivr;/* PSC + 0x30 */
u8 reserved8[3];
u8 ip; /* PSC + 0x34 */
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
On Thursday 17 April 2008 17:10, Matt Sealey wrote: Juergen Beisert wrote: Hi, + /* the fifo starts right after psc ends */ + priv-fifo = (struct mpc52xx_psc_fifo*)priv-psc[1]; /* FIXME */ Wouldn't priv-fifo = (struct mpc52xx_psc_fifo*) (priv-psc + sizeof(struct mpc52xx_psc)); Be a little less obtuse use of C? priv-psc is of type struct mpc52xx_ac97_priv*. If I add 0x58 to it, wouldn't I add 0x58 times the size of struct mpc52xx_ac97_priv? Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
On Thursday 17 April 2008 17:05, Matt Sealey wrote: + help + Say Y or M if you want to support any AC97 codec attached to + the Freescqle MPC52xx AC97 interface. Also this; Freescale :) yes. ;-) -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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 Tuesday 15 April 2008 10:03, Juergen Beisert wrote:
Currently it fails to play anything with an external Wolfson WM9712
connected to it. It seems the current AC97 reset sequence switches the
WM9712 into testmode due to SDATA_OUT and Sync are not held low while the
reset is active. Any idea to solve this? Switching both signals to GPIO and
force them to low level while reset is active? How to cover PSC1 and PSC2
with different GPIOs for this case?
Cannot reproduce the reset issue now, but in my case the bestcomm was
programmed to service the wrong PSC unit. That was the reason I never heard
any sound.
Can us give the oftree a better differentiation to program the bestcomm in a
correct manner?
Subject: [EMAIL PROTECTED]@/@[EMAIL PROTECTED] mpc52xx: Change the AC97 driver
to be more generic
From: Juergen Beisert [EMAIL PROTECTED]
The current AC97 driver for the mpc52xx CPU is fixed to work on PSC2. This
patch tries to make it more generic, as it detects the PSC unit for AC97 usage
to forward this information into the Bestcomm-API.
Signed-off-by: Juergen Beisert [EMAIL PROTECTED]
---
sound/ppc/mpc52xx_ac97.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
Index: sound/ppc/mpc52xx_ac97.c
===
--- sound/ppc/mpc52xx_ac97.c.orig
+++ sound/ppc/mpc52xx_ac97.c
@@ -651,6 +651,7 @@ mpc52xx_ac97_probe(struct of_device *op,
struct mpc52xx_ac97_priv *priv;
struct snd_card *card;
struct resource res;
+ int tx_initiator;
int rv;
dev_dbg(op-dev, probing MPC52xx PSC AC97 driver\n);
@@ -699,10 +700,27 @@ mpc52xx_ac97_probe(struct of_device *op,
/* Setup Bestcomm tasks */
spin_lock_init(priv-dma_lock);
+ /*
+* PSC1 or PSC2 can be configured for AC97 usage. Select the right
+* channel, to let the BCOMM unit does its job correctly.
+*/
+ switch (priv-mem_start 0x) {
+ case 0x2000:/* PSC1 */
+ tx_initiator = 14;
+ break;
+ case 0x2200:/* PSC2 */
+ tx_initiator = 12;
+ break;
+ default:
+ dev_dbg(priv-dev, Unknown PSC unit for AC97 usage!\n);
+ rv - ENODEV;
+ goto err_irq;
+ }
+
priv-tsk_tx = bcom_gen_bd_tx_init(AC97_TX_NUM_BD,
priv-mem_start + offsetof(struct mpc52xx_psc,
tfdata),
- 12, /* initiator : FIXME */
+ tx_initiator,
2); /* ipr : FIXME */
if (!priv-tsk_tx) {
printk(KERN_ERR DRV_NAME : bcom_gen_bd_tx_init failed\n);
@@ -759,6 +777,7 @@ err_irqreq:
bcom_gen_bd_tx_release(priv-tsk_tx);
err_bcomm:
mpc52xx_ac97_hwshutdown(priv);
+err_irq:
irq_dispose_mapping(priv-irq);
err_irqmap:
iounmap(priv-psc);
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | 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 Friday 11 April 2008 09:29, Sylvain Munaut 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. Yes ... and it still applies. 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? It's a minimum boiler plate. I filled the function at the minimum to get some sound output and being able to hear music coming out of it :) I also completely skipped the 5200 (not B) support ... At first there was no DMA at all (full software copy). I added some simple DMA later just to prove it could work and how to use the API. I just wrote it to get some sound, prove the interface could work under linux and to show how to use DMA. I had hoped someone else would finish it ... (yeah, I know ... big mistake). 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.? My test was listening to Gorrillaz Feel Good inc using mplayer ... Did anyone else tried it and/or has a updated version or can share experience? At the time several other people tried it and it worked ... unless you did lots of harddrive IO and then it crumbled ... Currently it fails to play anything with an external Wolfson WM9712 connected to it. It seems the current AC97 reset sequence switches the WM9712 into testmode due to SDATA_OUT and Sync are not held low while the reset is active. Any idea to solve this? Switching both signals to GPIO and force them to low level while reset is active? How to cover PSC1 and PSC2 with different GPIOs for this case? Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200B AC97 support for recent kernel
Hi, I'm using a 2.6.23 kernel and trying to get the AC97 running on my MPC5200B based CPU card. I'm using a patch stack posted here last year. FEC and ATA seems running correctly. Also the AC97 seems to run, but I can hear some noise only. But ALSA does detect the external Wolfson codec and its capabilities correctly, so I think the AC97 link works as expected. Some things I noticed: - I can control the volume of the noise with alsamixer - the external codes outputs the correct clock (~12 MHz) - the MPC5200B AC97 driver receives interrupts from the bestcomm unit (to report progress to the pcm framework) - everything seems ways too fast. A four minutes mp3 song is ready after 40 seconds - I'm not sure: What type of data wants the AC97 PCS unit? AC97 data slots are 20 bits wide. int32_t or 24 bits per sample? Big endian? - does it use interleave? Left, right, left, right, ... to be fed into AC97 data slot 3 and 4? Any ideas? Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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
Wolfgang, On Wednesday 23 January 2008 01:20, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Is anybody out there with more MPC5200B experience? Can someone tell me why some MPC5200B are need this patch and others not? We have two different systems here (cards from different vendors) with the same processor, one needs this BSDIS-patch and the other not. ??? Is it really exactly the same CPU revision? My guess is that one is rev. B and the other one is older... The one who needs this patch (CPU card vendor 1): MPC5200CVR400B, M62C REV 1, QCW0723T The CPUs who do not need this patch (CPU card vendor 2): SPC5200CBV400B, M62C REV 1, QAG0610C MPC5200CVR400B, M62C REV 1, QAJ0613F Best regards Juergen Beisert -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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
Markus, On Monday 21 January 2008 08:10, Mehlan, Markus (Ritter Elektronik) wrote: i have the same problem with the fec driver. See my posting at http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html Arnon, have you already fixed the FEC problem? Can you check this? http://ozlabs.org/pipermail/linuxppc-embedded/2007-May/027046.html Regards, Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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 Monday 21 January 2008 14:01, Mehlan, Markus (Ritter Elektronik) wrote: -Ursprüngliche Nachricht- Von: Juergen Beisert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 21. Januar 2008 09:58 An: linuxppc-dev@ozlabs.org Cc: Mehlan, Markus (Ritter Elektronik) Betreff: Re: [MPC5200] problem running FEC and ATA Markus, On Monday 21 January 2008 08:10, Mehlan, Markus (Ritter Elektronik) wrote: i have the same problem with the fec driver. See my posting at http://ozlabs.org/pipermail/linuxppc-embedded/2008-January/029466.html Arnon, have you already fixed the FEC problem? Can you check this? http://ozlabs.org/pipermail/linuxppc-embedded/2007-May/027046.html I have checked the article. To set the BSDIS bit in the XLB config register during initialization fixes my problem: xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB; out_be32(xlb-config, in_be32(xlb-config) | MPC52xx_XLB_CFG_BSDIS); Is anybody out there with more MPC5200B experience? Can someone tell me why some MPC5200B are need this patch and others not? We have two different systems here (cards from different vendors) with the same processor, one needs this BSDIS-patch and the other not. ??? Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | 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 Sunday 16 December 2007 18:28, 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. I tried our kernel (see link above) with an external harddisk and NFS. I copied various files from the harddisk to NFS root and vice versa. No data corruption. Can you check our patch stack on your hardware? Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Configuration-Problem ext-interrupt on mpc52xx
Silvio,
On Wednesday 19 September 2007 13:59, S. Fricke wrote:
how can i configure an ext interrupt to high-level? I want a interruption
on IRQ2, but I checked with an oscilloscope that the pin has a low state
and I needs a high state.
I have tried, after I got the irq (with irq_of_parse_and_map), set it with
set_irq_type(irq, IRQ_TYPE_LEVEL_HIGH);
But I think it is a system-configuration (irq_desc) and no
device-configuration.
Try with the attached patch.
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 ++
1 file changed, 38 insertions(+)
Index: arch/powerpc/platforms/52xx/mpc52xx_pic.c
===
--- arch/powerpc/platforms/52xx/mpc52xx_pic.c.orig
+++ arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -25,6 +25,7 @@
#include linux/stddef.h
#include linux/delay.h
#include linux/irq.h
+#include linux/interrupt.h
#include linux/hardirq.h
#include asm/io.h
@@ -107,11 +108,48 @@ static void mpc52xx_extirq_ack(unsigned
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
oftree and external connected devices
Hi, I'm using an MPC5200B based system with various external connected devices to its LocalPlusBus. On other architectures I would register them as platform devices (no chance to autodetect these devices). But on PowerPC architecture? Is the oftree description also intended to describe these kind of external devices, or only SoC's internal devices? If its also intended for external devices, how to do so? Are there any examples? I didn't find anything useful yet. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Fwd: Re: Kernel Bug when entering something after login
On Thursday 26 July 2007 10:47, Juergen Beisert wrote: FYI. Valid for current 2.6.22.1 kernel. Sorry for the noise, tglx sent it allready. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Fwd: Re: Kernel Bug when entering something after login
FYI. Valid for current 2.6.22.1 kernel. -- Forwarded Message -- Subject: Re: Kernel Bug when entering something after login Date: Wednesday 25 July 2007 21:06 From: Thomas Gleixner [EMAIL PROTECTED] To: Juergen Beisert [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On Wed, 2007-07-25 at 19:00 +0200, Juergen Beisert wrote: [c0245db0] [c01bdb98] rt_spin_lock_slowlock+0x4c/0x224 (unreliable) [c0245e10] [c011823c] uart_start+0x24/0x48 [c0245e30] [c0113ff4] n_tty_receive_buf+0x170/0xfd4 [c0245ef0] [c010f0dc] flush_to_ldisc+0xe0/0x130 [c0245f20] [c011b51c] mpc52xx_uart_int+0x194/0x350 [c0245f50] [c0046dfc] handle_IRQ_event+0x6c/0x110 [c0245f80] [c00475ec] thread_simple_irq+0x90/0xf8 [c0245fa0] [c00479a0] do_irqd+0x34c/0x3cc [c0245fd0] [c0033380] kthread+0x48/0x84 [c0245ff0] [c00104ac] kernel_thread+0x44/0x60 Instruction dump: 70090008 40820144 80010064 bb410048 38210060 7c0803a6 4e800020 801c0010 543a 7c001278 7c34 5400d97e 0f00 3964 91610008 80010008 note: IRQ-131[93] exited with preempt_count 1 Yup. That's a deadlock. In mainline this does not happen, as the spinlock is a NOP. Turn on CONFIG_PROVE_LOCKING in mainline and you see the problem as well. Solution below tglx Index: linux-2.6.22/drivers/serial/mpc52xx_uart.c === --- linux-2.6.22.orig/drivers/serial/mpc52xx_uart.c 2007-07-09 01:32:17.0 +0200 +++ linux-2.6.22/drivers/serial/mpc52xx_uart.c 2007-07-25 21:06:11.0 +0200 @@ -501,7 +501,9 @@ mpc52xx_uart_int_rx_chars(struct uart_po } } + spin_unlock(port-lock); tty_flip_buffer_push(tty); + spin_lock(port-lock); return in_be16(PSC(port)-mpc52xx_psc_status) MPC52xx_PSC_SR_RXRDY; } - To unsubscribe from this list: send the line unsubscribe linux-rt-users in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html --- -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
