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
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)? You can always use the platform feature hacks like I do on powermac but we should definitely find something better. Maybe some hook in the OF wrapper ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 07:22:25AM +1000, 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 :-) I hadn't really wanted to go down this route because the calculation of the clock, or the decision to use an external clock or calculate an internal clock is very board specific. I'll need to take another look to decide if it is reasonable to encode it into the device tree. I tend to thing that drivers should deal with their own clocks. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? Yeah, but in this case the clock can't actually be turned off. It's just a select bit between internal or external clock and a calculation value on the divider. Since it's a one-time board level setup config in a big block of shared chip level registers I'd rather just leave it in the domain of firmware. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote: 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)? The external clock would need to be encoded in the device tree. Internal clock would need to read/detect the CDM config and make a decision based on that. Certainly possible, but I just don't think that it is really important. (And even if it is, I think it should be done in common platform setup code, not the driver, because it is very MPC5200 SoC specific). g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 12:57 PM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote: 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. I got the attached diagram from Freescale on how to program the divider. It's not in the user manual. Freescale is recommending a 33.333Mhz crystal for the mpc5200 now. If you use 33.Mhz you won't be able to set a 48Mhz internal clock. Closest you can get is 48.4848Mhz. Sticking with a 33Mhz crystal allow an accurate 48Mhz clock. Clocking USB at the wrong clock rate will make some devices not function or get errors. The new mpc5200 datasheet has removed the option of using a 16x multiplier on a 33Mhz crystal and running the core at 528Mhz. The new datasheet only allows up to 400Mhz for the core. Anyone know what is going on? -- Jon Smirl [EMAIL PROTECTED] fractinal_div.pdf Description: Adobe PDF document ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Thu, Sep 25, 2008 at 12:02 PM, Jon Smirl [EMAIL PROTECTED] wrote: The new mpc5200 datasheet has removed the option of using a 16x multiplier on a 33Mhz crystal and running the core at 528Mhz. The new datasheet only allows up to 400Mhz for the core. Anyone know what is going on? You mean other than the 5200b being a slighly dodgy chip to work with? -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
I hadn't really wanted to go down this route because the calculation of the clock, or the decision to use an external clock or calculate an internal clock is very board specific. I'll need to take another look to decide if it is reasonable to encode it into the device tree. Could be done using the feature call mechanism that I have for powermac... though using a proper clock framework might be better in the long run. I tend to thing that drivers should deal with their own clocks. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? Yeah, but in this case the clock can't actually be turned off. It's just a select bit between internal or external clock and a calculation value on the divider. Since it's a one-time board level setup config in a big block of shared chip level registers I'd rather just leave it in the domain of firmware. Ah ok, makes more sense to keep it there then, or in platform init. Ben. ___ 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
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. 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. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
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 :-) 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. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 PCI interrupt routing
On Wed, Sep 24, 2008 at 5:22 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] 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 :-) 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. In fact it would be nice if one could stop the clocks while the host port is in suspend no ? There's a nice skeleton in arch/powerpc/kernel/clock.c for tracking who is using a clock and disabling it when not in use. Nobody is using it on PowerPC. It is used all over the place on ARM. -- Jon Smirl [EMAIL PROTECTED] ___ 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
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: MPC5200 PCI interrupt routing
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... I can't vouch for the correctness of your tree, though, or tell you what might be wrong (looks fine as far as I am concerned, but what do I know? :) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
