RE: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Anton/Tabi I am not sure which is the best place to configure the pins. Because some drivers do it in one way and some in the other. I actually tried to make the driver similar to ucc_geth because it is a QE driver. The driver has no platform code in the platform files similar to ucc_geth. It is probed along with all the QE devices thorugh of_platform_bus_probe. And the pins are configured for all the QE devices using par_io_init. I thought this to be the most consistent way at that time. How should we close this point? Can we go ahead with the pio-map? Infact the discussion in this thread was very good and I got to know a lot of rationales behind this. Please suggest. Thanks and Regards Poonam From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 10:53 PM To: Tabi Timur Cc: Aggrwal Poonam; Gala Kumar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael; Cutler Richard; Kalra Ashish Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries. On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Are you saying that TDM is sharing same pins with the other QE > >device, and we can choose to use/not use some device depending on > >which driver is loaded? > > No. I'd have to closely examine the DTS, but I don't think that UCC > devices share pins at all. But that isn't my point. > > >In that particular case UCC configuration is static, for every UCC. > >So, we can set up all pins in the firmware/board file. > > Yes, but deciding what the UCC does might not be static. At what > point do we declare, "UCC5 is for eth0 and eth0 only"? > > The advantage of putting the pin configurations in the device tree is > that they now become configurable. I can envision a scenario where > UCC5 could be either an Ethernet or a UART, depending on the setting > of some jumpers on the board. That's what the QE was designed for: any > UCC can do any task, and you can even have a UCC change its purpose while the system is running. > So I don't want the pin configurations hard-coded into the kernel. > Having them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. > For instance, I have a plan (that I keep postponing) to introduce a > new feature in U-Boot where U-Boot can determine the settings of some > board jumpers and modify the device tree accordingly. The instructions > on how to modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... > I can't > support this feature if the kernel calls par_io_config_pin() > regardless of what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Yes, but > deciding what the UCC does might not be static. At what point do we > declare, "UCC5 is for eth0 and eth0 only"? When the board designer decides to hook eth0 up to UCC5. If the board designer decides to hook multiple devices up to UCC5, we first smack the board designer, and then set it up to whichever configuration has been jumpered. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Are you saying that TDM is sharing same pins with the other QE device, > >and we can choose to use/not use some device depending on which driver > >is loaded? > > No. I'd have to closely examine the DTS, but I don't think that UCC > devices share pins at all. But that isn't my point. > > >In that particular case UCC configuration is static, for every UCC. > >So, we can set up all pins in the firmware/board file. > > Yes, but deciding what the UCC does might not be static. At what point do > we declare, "UCC5 is for eth0 and eth0 only"? > > The advantage of putting the pin configurations in the device tree is that > they now become configurable. I can envision a scenario where UCC5 could > be either an Ethernet or a UART, depending on the setting of some jumpers > on the board. That's what the QE was designed for: any UCC can do any task, > and you can even have a UCC change its purpose while the system is running. > So I don't want the pin configurations hard-coded into the kernel. Having > them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. > For instance, I have a plan (that I keep postponing) to introduce a new > feature in U-Boot where U-Boot can determine the settings of some board > jumpers and modify the device tree accordingly. The instructions on how to > modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... > I can't > support this feature if the kernel calls par_io_config_pin() regardless of > what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Anton Vorontsov wrote: Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? No. I'd have to closely examine the DTS, but I don't think that UCC devices share pins at all. But that isn't my point. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Yes, but deciding what the UCC does might not be static. At what point do we declare, "UCC5 is for eth0 and eth0 only"? The advantage of putting the pin configurations in the device tree is that they now become configurable. I can envision a scenario where UCC5 could be either an Ethernet or a UART, depending on the setting of some jumpers on the board. That's what the QE was designed for: any UCC can do any task, and you can even have a UCC change its purpose while the system is running. So I don't want the pin configurations hard-coded into the kernel. Having them in the device tree gives me some flexibility. For instance, I have a plan (that I keep postponing) to introduce a new feature in U-Boot where U-Boot can determine the settings of some board jumpers and modify the device tree accordingly. The instructions on how to modify the device tree would be embedded in the tree itself. I can't support this feature if the kernel calls par_io_config_pin() regardless of what's in the device tree. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 09:55:31AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Can we not introduce new pio-maps in the device trees? There > >were debates regarding this, and if I understood everything > >correctly, pio-maps considered as a bad taste. Better > >do bunch of par_io_config_pin() in the board file. Better > >yet fixup the firmware (u-boot) to set up dedicated pins > >correctly. > > I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. > The problem is that the configuration of these pins is board-specific, but > pins are used by devices. A device driver can't call par_io_config_pin(), > because the calls are different depending on which SoC and which UCC you're > using. The platform code can't call par_io_config_pin(), because that > configuration depends on which drivers are loaded. Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? I think this particular board and patch isn't that case. Even if someday there will be the case when drivers are mutually exclusive, i.e. presence of some driver should trigger pins reconfiguration, then anyway this should be handled differently. That is, we should not _register_ two mutually exclusive devices in the first place, so drivers will not probe them. That's board setup code authority, and pins configuration still should happen there. [ Irrelevant to UCCs and this particular case: lately I've encountered one interesting case of Par IO usage. FHCI USB needs switching between pin's dedicated functions and GPIO functions. So, firstly it is using pins as dedicated, and later (at the bus reset) driver turns them to act as GPIOs. This is still handled without pio-map though, via gpios = <> property for that driver. ] > In other words, the pin configurations are dependent on the UCC > configurations, and the UCC configurations are stored in the device tree. > So it makes sense to put the pin configurations in the device tree, too. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Please correct me if I'm wrong. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Anton Vorontsov wrote: Can we not introduce new pio-maps in the device trees? There were debates regarding this, and if I understood everything correctly, pio-maps considered as a bad taste. Better do bunch of par_io_config_pin() in the board file. Better yet fixup the firmware (u-boot) to set up dedicated pins correctly. I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. The problem is that the configuration of these pins is board-specific, but pins are used by devices. A device driver can't call par_io_config_pin(), because the calls are different depending on which SoC and which UCC you're using. The platform code can't call par_io_config_pin(), because that configuration depends on which drivers are loaded. In other words, the pin configurations are dependent on the UCC configurations, and the UCC configurations are stored in the device tree. So it makes sense to put the pin configurations in the device tree, too. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Poonam,
On Thu, Jan 24, 2008 at 04:00:06PM +0530, Poonam_Aggrwal-b10812 wrote:
> Thanks Stephen for your comments, incorporated them.
> From: Poonam Aggrwal <[EMAIL PROTECTED]>
>
> This patch makes necessary changes in the QE and UCC framework to support
> TDM. It also adds support to configure the BRG properly through device
> tree entries. Includes the device tree changes for UCC TDM driver as well.
> It also includes device tree entries for UCC TDM driver.
>
> Tested on MPC8323ERDB platform.
>
> Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
> Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
> Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
> Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
> arch/powerpc/sysdev/qe_lib/qe.c | 184 +--
> arch/powerpc/sysdev/qe_lib/ucc.c | 265
> +
> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
> include/asm-powerpc/qe.h |8 +
> include/asm-powerpc/ucc.h |4 +
> include/asm-powerpc/ucc_fast.h|4 +
> 7 files changed, 548 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> index 388c8a7..c0e6283 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -105,6 +105,17 @@
> device_type = "par_io";
> num-ports = <7>;
>
> + ucc1pio:[EMAIL PROTECTED] {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 e 2 0 1 0/* CLK11 */
> + 3 16 1 0 2 0/* BRG9 */
> + 3 1b 1 0 2 0/* BRG3 */
> + 0 0 3 0 2 0/* TDMATxD0 */
> + 0 4 3 0 2 0/* TDMARxD0 */
> + 3 1b 2 0 1 0>; /* CLK1 */
> + };
> +
Can we not introduce new pio-maps in the device trees? There
were debates regarding this, and if I understood everything
correctly, pio-maps considered as a bad taste. Better
do bunch of par_io_config_pin() in the board file. Better
yet fixup the firmware (u-boot) to set up dedicated pins
correctly.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Poonam,
On Thu, Jan 24, 2008 at 04:00:06PM +0530, Poonam_Aggrwal-b10812 wrote:
Thanks Stephen for your comments, incorporated them.
From: Poonam Aggrwal [EMAIL PROTECTED]
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal [EMAIL PROTECTED]
Signed-off-by: Ashish Kalra [EMAIL PROTECTED]
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
Signed-off-by: Michael Barkowski [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
arch/powerpc/sysdev/qe_lib/qe.c | 184 +--
arch/powerpc/sysdev/qe_lib/ucc.c | 265
+
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
include/asm-powerpc/qe.h |8 +
include/asm-powerpc/ucc.h |4 +
include/asm-powerpc/ucc_fast.h|4 +
7 files changed, 548 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..c0e6283 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = par_io;
num-ports = 7;
+ ucc1pio:[EMAIL PROTECTED] {
+ pio-map =
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0/* CLK11 */
+ 3 16 1 0 2 0/* BRG9 */
+ 3 1b 1 0 2 0/* BRG3 */
+ 0 0 3 0 2 0/* TDMATxD0 */
+ 0 4 3 0 2 0/* TDMARxD0 */
+ 3 1b 2 0 1 0; /* CLK1 */
+ };
+
Can we not introduce new pio-maps in the device trees? There
were debates regarding this, and if I understood everything
correctly, pio-maps considered as a bad taste. Better
do bunch of par_io_config_pin() in the board file. Better
yet fixup the firmware (u-boot) to set up dedicated pins
correctly.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Anton Vorontsov wrote: Can we not introduce new pio-maps in the device trees? There were debates regarding this, and if I understood everything correctly, pio-maps considered as a bad taste. Better do bunch of par_io_config_pin() in the board file. Better yet fixup the firmware (u-boot) to set up dedicated pins correctly. I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. The problem is that the configuration of these pins is board-specific, but pins are used by devices. A device driver can't call par_io_config_pin(), because the calls are different depending on which SoC and which UCC you're using. The platform code can't call par_io_config_pin(), because that configuration depends on which drivers are loaded. In other words, the pin configurations are dependent on the UCC configurations, and the UCC configurations are stored in the device tree. So it makes sense to put the pin configurations in the device tree, too. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 09:55:31AM -0600, Timur Tabi wrote: Anton Vorontsov wrote: Can we not introduce new pio-maps in the device trees? There were debates regarding this, and if I understood everything correctly, pio-maps considered as a bad taste. Better do bunch of par_io_config_pin() in the board file. Better yet fixup the firmware (u-boot) to set up dedicated pins correctly. I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. The problem is that the configuration of these pins is board-specific, but pins are used by devices. A device driver can't call par_io_config_pin(), because the calls are different depending on which SoC and which UCC you're using. The platform code can't call par_io_config_pin(), because that configuration depends on which drivers are loaded. Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? I think this particular board and patch isn't that case. Even if someday there will be the case when drivers are mutually exclusive, i.e. presence of some driver should trigger pins reconfiguration, then anyway this should be handled differently. That is, we should not _register_ two mutually exclusive devices in the first place, so drivers will not probe them. That's board setup code authority, and pins configuration still should happen there. [ Irrelevant to UCCs and this particular case: lately I've encountered one interesting case of Par IO usage. FHCI USB needs switching between pin's dedicated functions and GPIO functions. So, firstly it is using pins as dedicated, and later (at the bus reset) driver turns them to act as GPIOs. This is still handled without pio-map though, via gpios = property for that driver. ] In other words, the pin configurations are dependent on the UCC configurations, and the UCC configurations are stored in the device tree. So it makes sense to put the pin configurations in the device tree, too. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Please correct me if I'm wrong. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Anton Vorontsov wrote: Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? No. I'd have to closely examine the DTS, but I don't think that UCC devices share pins at all. But that isn't my point. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Yes, but deciding what the UCC does might not be static. At what point do we declare, UCC5 is for eth0 and eth0 only? The advantage of putting the pin configurations in the device tree is that they now become configurable. I can envision a scenario where UCC5 could be either an Ethernet or a UART, depending on the setting of some jumpers on the board. That's what the QE was designed for: any UCC can do any task, and you can even have a UCC change its purpose while the system is running. So I don't want the pin configurations hard-coded into the kernel. Having them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. For instance, I have a plan (that I keep postponing) to introduce a new feature in U-Boot where U-Boot can determine the settings of some board jumpers and modify the device tree accordingly. The instructions on how to modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... I can't support this feature if the kernel calls par_io_config_pin() regardless of what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Yes, but deciding what the UCC does might not be static. At what point do we declare, UCC5 is for eth0 and eth0 only? When the board designer decides to hook eth0 up to UCC5. If the board designer decides to hook multiple devices up to UCC5, we first smack the board designer, and then set it up to whichever configuration has been jumpered. -Scott -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Anton/Tabi I am not sure which is the best place to configure the pins. Because some drivers do it in one way and some in the other. I actually tried to make the driver similar to ucc_geth because it is a QE driver. The driver has no platform code in the platform files similar to ucc_geth. It is probed along with all the QE devices thorugh of_platform_bus_probe. And the pins are configured for all the QE devices using par_io_init. I thought this to be the most consistent way at that time. How should we close this point? Can we go ahead with the pio-map? Infact the discussion in this thread was very good and I got to know a lot of rationales behind this. Please suggest. Thanks and Regards Poonam From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 10:53 PM To: Tabi Timur Cc: Aggrwal Poonam; Gala Kumar; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael; Cutler Richard; Kalra Ashish Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries. On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Anton Vorontsov wrote: Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? No. I'd have to closely examine the DTS, but I don't think that UCC devices share pins at all. But that isn't my point. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Yes, but deciding what the UCC does might not be static. At what point do we declare, UCC5 is for eth0 and eth0 only? The advantage of putting the pin configurations in the device tree is that they now become configurable. I can envision a scenario where UCC5 could be either an Ethernet or a UART, depending on the setting of some jumpers on the board. That's what the QE was designed for: any UCC can do any task, and you can even have a UCC change its purpose while the system is running. So I don't want the pin configurations hard-coded into the kernel. Having them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. For instance, I have a plan (that I keep postponing) to introduce a new feature in U-Boot where U-Boot can determine the settings of some board jumpers and modify the device tree accordingly. The instructions on how to modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... I can't support this feature if the kernel calls par_io_config_pin() regardless of what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
