* Re: use of fsl, in lite5200b.dts in git current
From: Jon Smirl @ 2007-11-08 20:40 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910711071418u5914f188nffc7ab50e62cc88e@mail.gmail.com>
No one has answered this yet. It makes no sense at all to mix use of
the vendor prefix on some compatible entries and not on others. The
syntax of compatible entries needs to be consistent.
On 11/7/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> > Jon Smirl wrote:
> > > Sometimes the fsl prefix is being used and sometimes it isn't. Look at
> > > the two compatible strings. Which way is it going to be? Is
> > > fsl,has-wdt right?
> >
> > fsl,has-wdt is right, at least since someone changed it.
>
> What's the story with compatible?
> I would think the gdt entries are wrong.
>
> gpt@600 { // General Purpose Timer
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>
> code in drivers/watchdog/mpc5200_wdt.c would need to be changed to.
>
> drivers/watchdog/mpc5200_wdt.c: { .compatible = "fsl,mpc5200-gpt", },
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Jon Smirl @ 2007-11-08 20:39 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <47336805.4040807@genesi-usa.com>
On 11/8/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> >
> >> I think you may be placing too much faith in the vendors.
> >> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)
> >
> > There has to be more to the part number for the Freescale powerpc chip
> > than just 7400. 7400 is a shorthand name, it is not an orderable part number.
>
> The orderable part numbers add 3 or 4 characters to the front and about
> 8 after. There is a difference between MPC7400 and PPC7400, and the
> low voltage versions, and the different clock speeds. Orderable part
> number for a recent G4 might be PPC7448B1333NL - this is a ridiculous
> amount of specificity in a device tree, and it also does not match the
> datasheet (MPC7448 is the name of the chip).
>
> What people usually do is use what's in the datasheet.
Data sheet part number is fine, you don't need all that specificity.
The point is that the data sheet part number is sufficient, there is
no need for a vendor prefix. And these vendor prefixes can and do end
up being wrong when the chips families get sold. The datasheet part
numbers are maintained when a product line is sold.
>
> >> If you want to argue that the "MPC" part differentiates them, that's
> >> just a less readable and more obsolete vendor prefix.
> >
> > The MPC is what is printed on the chip. fsl is not printed there. MPC
> > is part of the orderable part number.
>
> Not all of them *ahem* :)
>
> Like I said, trust the datasheet, not the number on the chip.
>
> >> Vendor prefixes on properties are useful in that it might not mean
> >> exactly the same thing as a similar property that gets standardized
> >> later on.
> >>
> >>> That's life in the Linux world, no backwards binary compatibility.
> >> There's a huge difference between compatibility of kernel interfaces and
> >> compatibility of interfaces between the kernel and something else --
> >> whether it be userspace or firmware.
>
> Indeed, so.. at some point we should all sit down and hammer out the
> major issues in describing something like the MPC5121E because right
> now Genesi has a vested interest in that. Thanks Grant for your
> discussion on it, I agree of course :)
>
> One thing we don't want to go through again is the complaints we got
> because we named the chip node "/builtin" rather than "/soc". My fixup
> script is still handling that mess because you guys refused to
> accept it (and some drivers were coded to map from the MBAR contained
> in device_type soc's reg property rather than find a real device).
>
> If we could all agree on how it should be mapped out, with an example
> tree which shows *every damn thing available* so platform developers
> can pick and choose and OF developers can use it as a reference, it
> would make a much happier process.
>
> And then we can fix up the Efika to fit some definition of the new
> MPC5200 tree too.
>
> By the way while I was poking around the tree today I noticed that
> there is a PCI errata fixup handled by a Kconfig in there. Why? Surely
> this is something you check the PVR/SVR for and switch on that for
> a runtime solution, and not trick users with the possibility of
> forgetting to enable some obscure "PCI errata fix" configuration
> item? (CONFIG_PPC_MPC5200_BUGFIX)
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] powerpc: mpc8xxx MDS board RTC fixes
From: Kim Phillips @ 2007-11-08 20:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F67D40A1-D8C9-4F96-A526-E848FDFDEA0B@kernel.crashing.org>
On Thu, 8 Nov 2007 13:57:59 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Nov 8, 2007, at 1:37 PM, Kim Phillips wrote:
>
> > Now the rtc class ds1374 driver has been added,
> > remove the old rtc driver hookup code, add rtc node
> > to device trees, and turn on the new driver in the defconfigs.
> >
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > ---
> > arch/powerpc/boot/dts/mpc832x_mds.dts | 7 ++++
> > arch/powerpc/boot/dts/mpc834x_mds.dts | 9 +++++
> > arch/powerpc/boot/dts/mpc836x_mds.dts | 9 +++++
> > arch/powerpc/configs/mpc832x_mds_defconfig | 48 +++++++++++++++++
> > ++++++++++-
> > arch/powerpc/configs/mpc834x_mds_defconfig | 48 +++++++++++++++++
> > ++++++++++-
> > arch/powerpc/configs/mpc836x_mds_defconfig | 48 +++++++++++++++++
> > ++++++++++-
> > arch/powerpc/configs/mpc8568mds_defconfig | 48 +++++++++++++++++
> > ++++++++++-
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 --------------
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 --------------
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 --------------
> > 10 files changed, 213 insertions(+), 76 deletions(-)
>
> should the mpc8568mds.dts be updated?
it already has the rtc node.
> Also, what code is parsing the device tree for the rtc node?
>
the i2c code in fsl_soc.c.
Kim
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Scott Wood @ 2007-11-08 20:20 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1194442844.3571.14.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
> If both mdio and mdc controlling pins are on the same processor port,
> one resource should be used.
> Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
How about:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
We also need to change the reference to port C in fsl,mdio-pin and
fsl,mdc-pin.
-Scott
^ permalink raw reply
* Re: [RFC] powermac: proper sleep management
From: Scott Wood @ 2007-11-08 19:15 UTC (permalink / raw)
To: Johannes Berg
Cc: linuxppc-dev list, linux-pm, David Woodhouse, Paul Mackerras
In-Reply-To: <1194523729.6294.18.camel@johannes.berg>
Johannes Berg wrote:
> +/*
> + * overrides the weak arch_suspend_disable_irqs in kernel/power/main.c
> + *
> + * XXX: Once Scott Wood's patch is merged, this needs to use the ppc_md
> + * hooks that patch adds!
> + */
> +void arch_suspend_disable_irqs(void)
> +{
> +#ifdef CONFIG_PMAC_BACKLIGHT
> + /* Tell backlight code not to muck around with the chip anymore */
> + pmu_backlight_set_sleep(1);
> +#endif
> +
> + /* Call platform functions marked "on sleep" */
> + pmac_pfunc_i2c_suspend();
> + pmac_pfunc_base_suspend();
Shouldn't these be done from suspend methods of the relevant drivers?
I don't understand why this needs to go in the disable IRQ hook.
-Scott
^ permalink raw reply
* RE: [PATCH] powerpc: mpc8xxx MDS board RTC fixes
From: Wang Haiying @ 2007-11-08 20:10 UTC (permalink / raw)
To: Kumar Gala, Phillips Kim; +Cc: linuxppc-dev
In-Reply-To: <F67D40A1-D8C9-4F96-A526-E848FDFDEA0B@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]
Yes, 8568mds dts should be updated. And I tested this ds1374 driver on 8568mds board a couple of months ago, it worked fine. Code to parse device tree should be in fsl_soc.c.
Haiying
________________________________
From: linuxppc-dev-bounces+haiying.wang=freescale.com@ozlabs.org on behalf of Kumar Gala
Sent: Thu 11/8/2007 12:57 PM
To: Phillips Kim
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc: mpc8xxx MDS board RTC fixes
On Nov 8, 2007, at 1:37 PM, Kim Phillips wrote:
> Now the rtc class ds1374 driver has been added,
> remove the old rtc driver hookup code, add rtc node
> to device trees, and turn on the new driver in the defconfigs.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc832x_mds.dts | 7 ++++
> arch/powerpc/boot/dts/mpc834x_mds.dts | 9 +++++
> arch/powerpc/boot/dts/mpc836x_mds.dts | 9 +++++
> arch/powerpc/configs/mpc832x_mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/configs/mpc834x_mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/configs/mpc836x_mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/configs/mpc8568mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 --------------
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 --------------
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 --------------
> 10 files changed, 213 insertions(+), 76 deletions(-)
should the mpc8568mds.dts be updated?
Also, what code is parsing the device tree for the rtc node?
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 2858 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: mpc8xxx MDS board RTC fixes
From: Scott Wood @ 2007-11-08 20:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F67D40A1-D8C9-4F96-A526-E848FDFDEA0B@kernel.crashing.org>
Kumar Gala wrote:
> should the mpc8568mds.dts be updated?
It already has been.
> Also, what code is parsing the device tree for the rtc node?
There's code in fsl_soc.c (which should be made more generic).
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: mpc8xxx MDS board RTC fixes
From: Kumar Gala @ 2007-11-08 19:57 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20071108133706.961af8d2.kim.phillips@freescale.com>
On Nov 8, 2007, at 1:37 PM, Kim Phillips wrote:
> Now the rtc class ds1374 driver has been added,
> remove the old rtc driver hookup code, add rtc node
> to device trees, and turn on the new driver in the defconfigs.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc832x_mds.dts | 7 ++++
> arch/powerpc/boot/dts/mpc834x_mds.dts | 9 +++++
> arch/powerpc/boot/dts/mpc836x_mds.dts | 9 +++++
> arch/powerpc/configs/mpc832x_mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/configs/mpc834x_mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/configs/mpc836x_mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/configs/mpc8568mds_defconfig | 48 +++++++++++++++++
> ++++++++++-
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 --------------
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 --------------
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 --------------
> 10 files changed, 213 insertions(+), 76 deletions(-)
should the mpc8568mds.dts be updated?
Also, what code is parsing the device tree for the rtc node?
- k
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Jon Loeliger @ 2007-11-08 19:57 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <47336805.4040807@genesi-usa.com>
Matt Sealey wrote:
> The orderable part numbers add 3 or 4 characters to the front and about
> 8 after. There is a difference between MPC7400 and PPC7400, and the
> low voltage versions, and the different clock speeds. Orderable part
> number for a recent G4 might be PPC7448B1333NL -
Yeah, part, stepping, variant, speed, etc.
> this is a ridiculous
> amount of specificity in a device tree,
Except that some of that information _is_ specified
elsewhere in other properties. Speed, for example.
> and it also does not match the
> datasheet (MPC7448 is the name of the chip).
Because the data sheets are _soooo_ reliable. :-)
> Indeed, so.. at some point we should all sit down and hammer out the
> major issues in describing something like the MPC5121E because right
> now Genesi has a vested interest in that.
You understand that _that_ is being worked on as we, er, speak?
> If we could all agree on how it should be mapped out, with an example
> tree which shows *every damn thing available* so platform developers
> can pick and choose and OF developers can use it as a reference, it
> would make a much happier process.
Right. It's being nailed down, but it is a slow, community process...
> And then we can fix up the Efika to fit some definition of the new
> MPC5200 tree too.
*gasp*
> By the way while I was poking around the tree today I noticed that
> there is a PCI errata fixup handled by a Kconfig in there. Why?
Happens occasionally. And other places as well.
> Surely
> this is something you check the PVR/SVR for and switch on that for
> a runtime solution,
That's not always fine-grained enough to base a decision on it.
> and not trick users with the possibility of
> forgetting to enable some obscure "PCI errata fix" configuration
> item? (CONFIG_PPC_MPC5200_BUGFIX)
It should be in the defconfig. :-)
jdl
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Matt Sealey @ 2007-11-08 19:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910711080904h7d0dfb90o61d15d0326aedbf9@mail.gmail.com>
Jon Smirl wrote:
> On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
>
>> I think you may be placing too much faith in the vendors.
>> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)
>
> There has to be more to the part number for the Freescale powerpc chip
> than just 7400. 7400 is a shorthand name, it is not an orderable part number.
The orderable part numbers add 3 or 4 characters to the front and about
8 after. There is a difference between MPC7400 and PPC7400, and the
low voltage versions, and the different clock speeds. Orderable part
number for a recent G4 might be PPC7448B1333NL - this is a ridiculous
amount of specificity in a device tree, and it also does not match the
datasheet (MPC7448 is the name of the chip).
What people usually do is use what's in the datasheet.
>> If you want to argue that the "MPC" part differentiates them, that's
>> just a less readable and more obsolete vendor prefix.
>
> The MPC is what is printed on the chip. fsl is not printed there. MPC
> is part of the orderable part number.
Not all of them *ahem* :)
Like I said, trust the datasheet, not the number on the chip.
>> Vendor prefixes on properties are useful in that it might not mean
>> exactly the same thing as a similar property that gets standardized
>> later on.
>>
>>> That's life in the Linux world, no backwards binary compatibility.
>> There's a huge difference between compatibility of kernel interfaces and
>> compatibility of interfaces between the kernel and something else --
>> whether it be userspace or firmware.
Indeed, so.. at some point we should all sit down and hammer out the
major issues in describing something like the MPC5121E because right
now Genesi has a vested interest in that. Thanks Grant for your
discussion on it, I agree of course :)
One thing we don't want to go through again is the complaints we got
because we named the chip node "/builtin" rather than "/soc". My fixup
script is still handling that mess because you guys refused to
accept it (and some drivers were coded to map from the MBAR contained
in device_type soc's reg property rather than find a real device).
If we could all agree on how it should be mapped out, with an example
tree which shows *every damn thing available* so platform developers
can pick and choose and OF developers can use it as a reference, it
would make a much happier process.
And then we can fix up the Efika to fit some definition of the new
MPC5200 tree too.
By the way while I was poking around the tree today I noticed that
there is a PCI errata fixup handled by a Kconfig in there. Why? Surely
this is something you check the PVR/SVR for and switch on that for
a runtime solution, and not trick users with the possibility of
forgetting to enable some obscure "PCI errata fix" configuration
item? (CONFIG_PPC_MPC5200_BUGFIX)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* [PATCH] powerpc: mpc8xxx MDS board RTC fixes
From: Kim Phillips @ 2007-11-08 19:37 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala
Now the rtc class ds1374 driver has been added,
remove the old rtc driver hookup code, add rtc node
to device trees, and turn on the new driver in the defconfigs.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 7 ++++
arch/powerpc/boot/dts/mpc834x_mds.dts | 9 +++++
arch/powerpc/boot/dts/mpc836x_mds.dts | 9 +++++
arch/powerpc/configs/mpc832x_mds_defconfig | 48 +++++++++++++++++++++++++++-
arch/powerpc/configs/mpc834x_mds_defconfig | 48 +++++++++++++++++++++++++++-
arch/powerpc/configs/mpc836x_mds_defconfig | 48 +++++++++++++++++++++++++++-
arch/powerpc/configs/mpc8568mds_defconfig | 48 +++++++++++++++++++++++++++-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 --------------
arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 --------------
arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 --------------
10 files changed, 213 insertions(+), 76 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fcd333c..650a50c 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -57,12 +57,19 @@
};
i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = < &ipic >;
dfsrr;
+
+ rtc@68 {
+ compatible = "dallas,ds1374";
+ reg = <68>;
+ };
};
serial@4500 {
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index e5a84ef..49363f8 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -57,15 +57,24 @@
};
i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = < &ipic >;
dfsrr;
+
+ rtc@68 {
+ compatible = "dallas,ds1374";
+ reg = <68>;
+ };
};
i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3100 100>;
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index fbd1573..0b2d2b5 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -62,15 +62,24 @@
};
i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = < &ipic >;
dfsrr;
+
+ rtc@68 {
+ compatible = "dallas,ds1374";
+ reg = <68>;
+ };
};
i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3100 100>;
diff --git a/arch/powerpc/configs/mpc832x_mds_defconfig b/arch/powerpc/configs/mpc832x_mds_defconfig
index dd68d18..e069018 100644
--- a/arch/powerpc/configs/mpc832x_mds_defconfig
+++ b/arch/powerpc/configs/mpc832x_mds_defconfig
@@ -774,7 +774,53 @@ CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_LIB=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+# CONFIG_RTC_DEBUG is not set
+
+#
+# RTC interfaces
+#
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
+# CONFIG_RTC_DRV_TEST is not set
+
+#
+# I2C RTC drivers
+#
+# CONFIG_RTC_DRV_DS1307 is not set
+CONFIG_RTC_DRV_DS1374=y
+# CONFIG_RTC_DRV_DS1672 is not set
+# CONFIG_RTC_DRV_MAX6900 is not set
+# CONFIG_RTC_DRV_RS5C372 is not set
+# CONFIG_RTC_DRV_ISL1208 is not set
+# CONFIG_RTC_DRV_X1205 is not set
+# CONFIG_RTC_DRV_PCF8563 is not set
+# CONFIG_RTC_DRV_PCF8583 is not set
+# CONFIG_RTC_DRV_M41T80 is not set
+
+#
+# SPI RTC drivers
+#
+
+#
+# Platform RTC drivers
+#
+# CONFIG_RTC_DRV_CMOS is not set
+# CONFIG_RTC_DRV_DS1553 is not set
+# CONFIG_RTC_DRV_STK17TA8 is not set
+# CONFIG_RTC_DRV_DS1742 is not set
+# CONFIG_RTC_DRV_M48T86 is not set
+# CONFIG_RTC_DRV_M48T59 is not set
+# CONFIG_RTC_DRV_V3020 is not set
+
+#
+# on-CPU RTC drivers
+#
#
# DMA Engine support
diff --git a/arch/powerpc/configs/mpc834x_mds_defconfig b/arch/powerpc/configs/mpc834x_mds_defconfig
index e59a88e..356f736 100644
--- a/arch/powerpc/configs/mpc834x_mds_defconfig
+++ b/arch/powerpc/configs/mpc834x_mds_defconfig
@@ -721,7 +721,53 @@ CONFIG_USB_EHCI_FSL=y
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_LIB=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+# CONFIG_RTC_DEBUG is not set
+
+#
+# RTC interfaces
+#
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
+# CONFIG_RTC_DRV_TEST is not set
+
+#
+# I2C RTC drivers
+#
+# CONFIG_RTC_DRV_DS1307 is not set
+CONFIG_RTC_DRV_DS1374=y
+# CONFIG_RTC_DRV_DS1672 is not set
+# CONFIG_RTC_DRV_MAX6900 is not set
+# CONFIG_RTC_DRV_RS5C372 is not set
+# CONFIG_RTC_DRV_ISL1208 is not set
+# CONFIG_RTC_DRV_X1205 is not set
+# CONFIG_RTC_DRV_PCF8563 is not set
+# CONFIG_RTC_DRV_PCF8583 is not set
+# CONFIG_RTC_DRV_M41T80 is not set
+
+#
+# SPI RTC drivers
+#
+
+#
+# Platform RTC drivers
+#
+# CONFIG_RTC_DRV_CMOS is not set
+# CONFIG_RTC_DRV_DS1553 is not set
+# CONFIG_RTC_DRV_STK17TA8 is not set
+# CONFIG_RTC_DRV_DS1742 is not set
+# CONFIG_RTC_DRV_M48T86 is not set
+# CONFIG_RTC_DRV_M48T59 is not set
+# CONFIG_RTC_DRV_V3020 is not set
+
+#
+# on-CPU RTC drivers
+#
#
# DMA Engine support
diff --git a/arch/powerpc/configs/mpc836x_mds_defconfig b/arch/powerpc/configs/mpc836x_mds_defconfig
index 7565752..1b4d375 100644
--- a/arch/powerpc/configs/mpc836x_mds_defconfig
+++ b/arch/powerpc/configs/mpc836x_mds_defconfig
@@ -773,7 +773,53 @@ CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_LIB=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+# CONFIG_RTC_DEBUG is not set
+
+#
+# RTC interfaces
+#
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
+# CONFIG_RTC_DRV_TEST is not set
+
+#
+# I2C RTC drivers
+#
+# CONFIG_RTC_DRV_DS1307 is not set
+CONFIG_RTC_DRV_DS1374=y
+# CONFIG_RTC_DRV_DS1672 is not set
+# CONFIG_RTC_DRV_MAX6900 is not set
+# CONFIG_RTC_DRV_RS5C372 is not set
+# CONFIG_RTC_DRV_ISL1208 is not set
+# CONFIG_RTC_DRV_X1205 is not set
+# CONFIG_RTC_DRV_PCF8563 is not set
+# CONFIG_RTC_DRV_PCF8583 is not set
+# CONFIG_RTC_DRV_M41T80 is not set
+
+#
+# SPI RTC drivers
+#
+
+#
+# Platform RTC drivers
+#
+# CONFIG_RTC_DRV_CMOS is not set
+# CONFIG_RTC_DRV_DS1553 is not set
+# CONFIG_RTC_DRV_STK17TA8 is not set
+# CONFIG_RTC_DRV_DS1742 is not set
+# CONFIG_RTC_DRV_M48T86 is not set
+# CONFIG_RTC_DRV_M48T59 is not set
+# CONFIG_RTC_DRV_V3020 is not set
+
+#
+# on-CPU RTC drivers
+#
#
# DMA Engine support
diff --git a/arch/powerpc/configs/mpc8568mds_defconfig b/arch/powerpc/configs/mpc8568mds_defconfig
index 883d8af..d665e7a 100644
--- a/arch/powerpc/configs/mpc8568mds_defconfig
+++ b/arch/powerpc/configs/mpc8568mds_defconfig
@@ -768,7 +768,53 @@ CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_LIB=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+# CONFIG_RTC_DEBUG is not set
+
+#
+# RTC interfaces
+#
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
+# CONFIG_RTC_DRV_TEST is not set
+
+#
+# I2C RTC drivers
+#
+# CONFIG_RTC_DRV_DS1307 is not set
+CONFIG_RTC_DRV_DS1374=y
+# CONFIG_RTC_DRV_DS1672 is not set
+# CONFIG_RTC_DRV_MAX6900 is not set
+# CONFIG_RTC_DRV_RS5C372 is not set
+# CONFIG_RTC_DRV_ISL1208 is not set
+# CONFIG_RTC_DRV_X1205 is not set
+# CONFIG_RTC_DRV_PCF8563 is not set
+# CONFIG_RTC_DRV_PCF8583 is not set
+# CONFIG_RTC_DRV_M41T80 is not set
+
+#
+# SPI RTC drivers
+#
+
+#
+# Platform RTC drivers
+#
+# CONFIG_RTC_DRV_CMOS is not set
+# CONFIG_RTC_DRV_DS1553 is not set
+# CONFIG_RTC_DRV_STK17TA8 is not set
+# CONFIG_RTC_DRV_DS1742 is not set
+# CONFIG_RTC_DRV_M48T86 is not set
+# CONFIG_RTC_DRV_M48T59 is not set
+# CONFIG_RTC_DRV_V3020 is not set
+
+#
+# on-CPU RTC drivers
+#
#
# DMA Engine support
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..66382df 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -145,30 +145,6 @@ static void __init mpc832x_sys_init_IRQ(void)
#endif /* CONFIG_QUICC_ENGINE */
}
-#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
-
-static int __init mpc832x_rtc_hookup(void)
-{
- struct timespec tv;
-
- if (!machine_is(mpc832x_mds))
- return 0;
-
- ppc_md.get_rtc_time = ds1374_get_rtc_time;
- ppc_md.set_rtc_time = ds1374_set_rtc_time;
-
- tv.tv_nsec = 0;
- tv.tv_sec = (ppc_md.get_rtc_time) ();
- do_settimeofday(&tv);
-
- return 0;
-}
-
-late_initcall(mpc832x_rtc_hookup);
-#endif
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 00aed7c..a81bb3c 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -106,30 +106,6 @@ static void __init mpc834x_mds_init_IRQ(void)
ipic_set_default_priority();
}
-#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
-
-static int __init mpc834x_rtc_hookup(void)
-{
- struct timespec tv;
-
- if (!machine_is(mpc834x_mds))
- return 0;
-
- ppc_md.get_rtc_time = ds1374_get_rtc_time;
- ppc_md.set_rtc_time = ds1374_set_rtc_time;
-
- tv.tv_nsec = 0;
- tv.tv_sec = (ppc_md.get_rtc_time) ();
- do_settimeofday(&tv);
-
- return 0;
-}
-
-late_initcall(mpc834x_rtc_hookup);
-#endif
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0f3855c..8d87b9c 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -152,30 +152,6 @@ static void __init mpc836x_mds_init_IRQ(void)
#endif /* CONFIG_QUICC_ENGINE */
}
-#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
-extern ulong ds1374_get_rtc_time(void);
-extern int ds1374_set_rtc_time(ulong);
-
-static int __init mpc8360_rtc_hookup(void)
-{
- struct timespec tv;
-
- if (!machine_is(mpc836x_mds))
- return 0;
-
- ppc_md.get_rtc_time = ds1374_get_rtc_time;
- ppc_md.set_rtc_time = ds1374_set_rtc_time;
-
- tv.tv_nsec = 0;
- tv.tv_sec = (ppc_md.get_rtc_time) ();
- do_settimeofday(&tv);
-
- return 0;
-}
-
-late_initcall(mpc8360_rtc_hookup);
-#endif
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
--
1.5.2.2
^ permalink raw reply related
* Re: DTS Bytestrings Representation in /dts-v1/ files
From: Josh Boyer @ 2007-11-08 19:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IqCtu-0000ZE-Vi@jdl.com>
On Thu, 08 Nov 2007 13:18:50 -0600
Jon Loeliger <jdl@jdl.com> wrote:
>
> Folks,
>
> When the new DTS /dts-v1/ support is released Real Soon Now,
> it will support C-like literal constants. Hex values will be
> prefixed with 0x, binary with 0b, and bare numbers will be
> decimal unless they start with a leading 0.
>
> One outstanding question on which I'd like some feedback
> is the issue of bytestring value representation.
>
> Currently they look like this:
>
> stuff = [ 0b 31 22 de ea ad be ef ];
>
> One opinion is to have them continue to look like that
> and be in hex only.
>
> Another opinion is to allow the new, consistent C-style
> literals and expressions so that one could have:
>
> new_stuff = [ 0x31 49 '1' 23 17 ];
>
> Opinions?
My off-the-cuff opinion is to leave them as they are today. They seem
to mostly be used for MAC addresses, and you don't really see a whole
lot of those with the 0x prefix before every number.
At the same time, inconsistency sucks.
josh
^ permalink raw reply
* DTS Bytestrings Representation in /dts-v1/ files
From: Jon Loeliger @ 2007-11-08 19:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <E1Iplfp-0003WY-MB@jdl.com>
Folks,
When the new DTS /dts-v1/ support is released Real Soon Now,
it will support C-like literal constants. Hex values will be
prefixed with 0x, binary with 0b, and bare numbers will be
decimal unless they start with a leading 0.
One outstanding question on which I'd like some feedback
is the issue of bytestring value representation.
Currently they look like this:
stuff = [ 0b 31 22 de ea ad be ef ];
One opinion is to have them continue to look like that
and be in hex only.
Another opinion is to allow the new, consistent C-style
literals and expressions so that one could have:
new_stuff = [ 0x31 49 '1' 23 17 ];
Opinions?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-08 19:11 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108183952.GA18117@localhost.localdomain>
On Thu, 8 Nov 2007 21:39:52 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> > On Thu, 8 Nov 2007 17:16:11 +0300
> > Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > > Hello all,
> > > >
> > > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > > according to erratum #2 (erratum text included below). Basically the
> > > > most intrusive part is the addition of two new RGMII Internal Delay
> > > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > > both at the same time).
> > > >
> > > > Please review, and since this affects both netdev and powerpc trees,
> > > > one maintainer should ack them for the other to push upstream (i.e,
> > > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > > other way around; either way is fine with me). I'm hoping they're
> > > > trivial enough to go in 2.6.24.
> > > >
> > > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > > sent out that fixes up the phy-connection-type in the device tree (from
> > > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> > >
> > > I've upgraded CPU to rev2.1, board rev0.3.
> > >
> > thanks for testing this. I tested these patches on a "pilot assy 0.3".
>
> Same here.
>
> > > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > > the results:
> > >
> > > If I use -rxid, then geth not able to transmit anything.
> > > With -txid geth not able to receive anything.
> > >
> > > With just -id everything works fine though...
> > >
> > >
> > > Maybe there should be another condition, in addition to cpu rev2.1?
> > >
> > the errata simply states 'pilot boards', but we can probably modify
> > u-boot to look at the cpu rev and the board rev (BCSR 12).
> >
> > My bcsr12 looks like:
> >
> > => md.b f800000c 1
> > f800000c: 10 .
> >
> > what is yours?
>
> => md.b f800000c 1
> f800000c: 10 .
>
> :-/
>
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
> CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
>
> root@b1:~# cat /proc/cpuinfo
> processor : 0
> cpu : e300c1
> clock : 528.000000MHz
> revision : 3.1 (pvr 8083 0031)
> bogomips : 131.58
> timebase : 66000000
> platform : MPC836x MDS
>
check. :/
>
> + /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
> + svid = mfspr(SPRN_SVR);
> + if (svid == 0x80480021) {
>
> ^^ that branch executes on the board I'm testing.
right, but whether it does or not doesn't affect your failure outcome
either I'm assuming.
> > If it's something like 0x03, the u-boot patch will probably look like:
> >
> > if ((bcsr[12] == 0x10) &&
> > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > immr->sysconf.spridr == SPR_8360E_REV21))
> > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > ...
> >
> > but these linux patches would remain the same (the clk and data delay
> > settings for the UCC's are still valid; it's just the PHY config
> > that is triggering your problem from what I can tell).
>
> Yup, most likely this is not UCC specific, but PHY. For some reason
> delays making harm here...
hmm..
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
I have jumper JP1 set to 3.3V.
can you send me your:
=> md.b f8000000 15
f8000000: 04 04 00 c6 94 60 00 00 ac 2f 00 b8 10 3f 30 02 .....`.../...?0.
f8000010: 05 07 05 15 11 .....
and maybe try the following on top of these 5 patches (to specify rgmii
mode in the bcsr's):
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0a72260..753071e 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -98,6 +98,11 @@ static void __init mpc836x_mds_setup_arch(void)
!= NULL){
uint svid;
+ /* configure RGMII mode for both GETH ports */
+#define BCSR8_TSECXM_RGMII 0xf0
+ clrbits8(&bcsr_regs[8], BCSR8_TSECXM_RGMII);
+
+
/* Reset the Ethernet PHY */
#define BCSR9_GETHRST 0x20
clrbits8(&bcsr_regs[9], BCSR9_GETHRST);
Thanks,
Kim
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-08 18:39 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108121508.39a65c33.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> On Thu, 8 Nov 2007 17:16:11 +0300
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > Hello all,
> > >
> > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > according to erratum #2 (erratum text included below). Basically the
> > > most intrusive part is the addition of two new RGMII Internal Delay
> > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > both at the same time).
> > >
> > > Please review, and since this affects both netdev and powerpc trees,
> > > one maintainer should ack them for the other to push upstream (i.e,
> > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > other way around; either way is fine with me). I'm hoping they're
> > > trivial enough to go in 2.6.24.
> > >
> > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > sent out that fixes up the phy-connection-type in the device tree (from
> > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> >
> > I've upgraded CPU to rev2.1, board rev0.3.
> >
> thanks for testing this. I tested these patches on a "pilot assy 0.3".
Same here.
> > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > the results:
> >
> > If I use -rxid, then geth not able to transmit anything.
> > With -txid geth not able to receive anything.
> >
> > With just -id everything works fine though...
> >
> >
> > Maybe there should be another condition, in addition to cpu rev2.1?
> >
> the errata simply states 'pilot boards', but we can probably modify
> u-boot to look at the cpu rev and the board rev (BCSR 12).
>
> My bcsr12 looks like:
>
> => md.b f800000c 1
> f800000c: 10 .
>
> what is yours?
=> md.b f800000c 1
f800000c: 10 .
:-/
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
root@b1:~# cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.000000MHz
revision : 3.1 (pvr 8083 0031)
bogomips : 131.58
timebase : 66000000
platform : MPC836x MDS
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
^^ that branch executes on the board I'm testing.
> If it's something like 0x03, the u-boot patch will probably look like:
>
> if ((bcsr[12] == 0x10) &&
> (immr->sysconf.spridr == SPR_8360_REV21 ||
> immr->sysconf.spridr == SPR_8360E_REV21))
> /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> ...
>
> but these linux patches would remain the same (the clk and data delay
> settings for the UCC's are still valid; it's just the PHY config
> that is triggering your problem from what I can tell).
Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-08 18:15 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108141611.GA5770@localhost.localdomain>
On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > Hello all,
> >
> > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > according to erratum #2 (erratum text included below). Basically the
> > most intrusive part is the addition of two new RGMII Internal Delay
> > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > both at the same time).
> >
> > Please review, and since this affects both netdev and powerpc trees,
> > one maintainer should ack them for the other to push upstream (i.e,
> > Kumar acks them, and Leo picks them up to go through netdev or the
> > other way around; either way is fine with me). I'm hoping they're
> > trivial enough to go in 2.6.24.
> >
> > Depending on how the review goes, a follow-on patch to u-boot will be
> > sent out that fixes up the phy-connection-type in the device tree (from
> > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
>
> I've upgraded CPU to rev2.1, board rev0.3.
>
thanks for testing this. I tested these patches on a "pilot assy 0.3".
> Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> the results:
>
> If I use -rxid, then geth not able to transmit anything.
> With -txid geth not able to receive anything.
>
> With just -id everything works fine though...
>
>
> Maybe there should be another condition, in addition to cpu rev2.1?
>
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).
My bcsr12 looks like:
=> md.b f800000c 1
f800000c: 10 .
what is yours?
If it's something like 0x03, the u-boot patch will probably look like:
if ((bcsr[12] == 0x10) &&
(immr->sysconf.spridr == SPR_8360_REV21 ||
immr->sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
...
but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).
Thanks,
Kim
> > mpc8360 rev 2.1 erratum #2:
> > -----------
> > Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII when working
> > with Rev Pilot MDS for proper RGMII operation:
> >
> > IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> > IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> > IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)
> >
> > The Phy (Marvell 88e1111) should be configured NOT to work with RGMII
> > delay for TxD.
^ permalink raw reply
* Re: [PATCH 1/2] pasemi_mac: Don't set replace-source-address descriptor bits
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071107042039.GD22637@lixom.net>
On Tue, Nov 06, 2007 at 10:20:39PM -0600, Olof Johansson wrote:
> Don't use the "replace source address with local MAC address" bits, since
> it causes problems on some variations of the hardware due to an erratum.
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
applied 1-2
^ permalink raw reply
* Re: libfdt: Add more documentation (path the fifth)
From: Jon Loeliger @ 2007-11-08 17:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071107005414.GE553@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch documents a few more functions in libfdt.h. All the
> read-only functions are now documented.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Jon Smirl @ 2007-11-08 17:04 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <47333939.6050106@freescale.com>
On 11/8/07, Scott Wood <scottwood@freescale.com> wrote:
> Jon Smirl wrote:
> > On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> >> Jon Smirl wrote:
> >>> I'm not in favor of all these fsl prefixes. These chip families
> >>> do get sold. What would we have done with intel,pxa320 all over
> >>> the place when they sold it to marvell? mass changes to
> >>> marvell,pxa320?
> >> That's the idea, and there'd be a compatible entry for
> >> intel,pxa320.
> >
> > The vendor part really isn't needed and it is going to be a source of
> > trouble. The vendors are smart enough not to create two chips with
> > the same part number. Adding a vendor qualifier complicates things
> > needlessly.
>
> I think you may be placing too much faith in the vendors.
> Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)
There has to be more to the part number for the Freescale powerpc chip
than just 7400.
7400 is a shorthand name, it is not an orderable part number.
> If you want to argue that the "MPC" part differentiates them, that's
> just a less readable and more obsolete vendor prefix.
The MPC is what is printed on the chip. fsl is not printed there. MPC
is part of the orderable part number.
>
> And not all compatible entries are part numbers; many are descriptions
> of programming interfaces (such as cpm2 or gianfar). I'm not inclined
> to bet that there will never be a conflict in such a namespace.
>
> >> Actually the spec says you should use the stock ticker (IBM, FSL,
> >> INTC, JAVA, MRVL) if they have one and if not, the company name in
> >> lower case.
> >>
> >> Freescale are a funny one because they used to have a stock ticker
> >> as MOT and then FSL but now they're privately owned, so it's gonna
> >> have to be lower case :]
>
> Well, technically the recommended prefix is an OUI number, and those are
> less likely to change due to corporate shuffling, but they suck from a
> readability perspective.
>
> > Another example of how these vendor prefixes can change. The chip
> > numbers are never going to change. Just use them and drop these
> > vendor prefixes.
>
> No. :-)
>
> >> functionality. fsl,has-wdt differs from has-wdt ideally because
> >
> > This one I can buy, but it should be fsl-has-wdt. Drop the vendor
> > prefixes.
>
> How is fsl-has-wdt any better, other than it obscures namespace issues?
>
> Vendor prefixes on properties are useful in that it might not mean
> exactly the same thing as a similar property that gets standardized
> later on.
>
> > That's life in the Linux world, no backwards binary compatibility.
>
> There's a huge difference between compatibility of kernel interfaces and
> compatibility of interfaces between the kernel and something else --
> whether it be userspace or firmware.
>
> -Scott
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: inbalanced ioremap/iounmap? in cpm_pic_init(); arch/powerpc/sysdev/commproc.c
From: Scott Wood @ 2007-11-08 16:55 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <473235C6.2050104@tiscali.nl>
On Wed, Nov 07, 2007 at 11:01:42PM +0100, Roel Kluin wrote:
> It appears to me that ioremap/iounmap in cpm_pic_init() is imbalanced. I
> am not certain about this, nor was the patch tested. please review.
You missed several error paths... and if we're going to clean up the error
handling for this function, we might as well free cpm_pic_host, and do an
of_node_put() before the second of_find_compatible_node(), as well.
> @@ -187,13 +187,15 @@ unsigned int cpm_pic_init(void)
> goto end;
>
> if (setup_irq(eirq, &cpm_error_irqaction))
> printk(KERN_ERR "Could not allocate CPM error IRQ!");
>
> setbits32(&cpic_reg->cpic_cicr, CICR_IEN);
> -
> + goto end;
> +io_out:
> + iounmap(cpic_reg);
> end:
> of_node_put(np);
> return sirq;
> }
Ick. Maybe better to just duplicate the of_node_put().
-Scott
^ permalink raw reply
* Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Valentine Barshak @ 2007-11-08 16:52 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev
In-Reply-To: <47333A69.3030606@tiscali.nl>
Roel Kluin wrote:
> I guess it should be done after the last usage of kb_data or fpga_status?
I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs
= kb_data + 1) is used by the serio driver
(drivers/input/serio/i8042-ppcio.h).
Please note that we just ioremap and assign pointers here, not actually
reading the registers.
Also, looks like you unmap the fpga registers too early.
Thanks,
Valentine.
> --
> Balance ioremap/iounmap
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
> ---
> diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
> index 8689f3e..4f3bac1 100644
> --- a/arch/ppc/platforms/4xx/sycamore.c
> +++ b/arch/ppc/platforms/4xx/sycamore.c
> @@ -99,28 +99,30 @@ sycamore_setup_arch(void)
> kb_data = ioremap(SYCAMORE_PS2_BASE, 8);
> if (!kb_data) {
> printk(KERN_CRIT
> "sycamore_setup_arch() kb_data ioremap failed\n");
> return;
> }
>
> kb_cs = kb_data + 1;
> + iounmap(kb_data);
>
> fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
> if (!fpga_status) {
> printk(KERN_CRIT
> "sycamore_setup_arch() fpga_status ioremap failed\n");
> return;
> }
>
> fpga_enable = fpga_status + 1;
> fpga_polarity = fpga_status + 2;
> fpga_trigger = fpga_status + 3;
> fpga_brdc = fpga_status + 4;
> + iounmap(fpga_status);
>
> /* split the keyboard and mouse interrupts */
> fpga_brdc_data = readb(fpga_brdc);
> fpga_brdc_data |= 0x80;
> writeb(fpga_brdc_data, fpga_brdc);
>
> writeb(0x3, fpga_enable);
>
> diff --git a/arch/ppc/platforms/4xx/walnut.c b/arch/ppc/platforms/4xx/walnut.c
> index 2f97723..8cfeb94 100644
> --- a/arch/ppc/platforms/4xx/walnut.c
> +++ b/arch/ppc/platforms/4xx/walnut.c
> @@ -81,28 +81,30 @@ walnut_setup_arch(void)
> kb_data = ioremap(WALNUT_PS2_BASE, 8);
> if (!kb_data) {
> printk(KERN_CRIT
> "walnut_setup_arch() kb_data ioremap failed\n");
> return;
> }
>
> kb_cs = kb_data + 1;
> + iounmap(kb_data);
>
> fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
> if (!fpga_status) {
> printk(KERN_CRIT
> "walnut_setup_arch() fpga_status ioremap failed\n");
> return;
> }
>
> fpga_enable = fpga_status + 1;
> fpga_polarity = fpga_status + 2;
> fpga_trigger = fpga_status + 3;
> fpga_brdc = fpga_status + 4;
> + iounmap(fpga_status);
>
> /* split the keyboard and mouse interrupts */
> fpga_brdc_data = readb(fpga_brdc);
> fpga_brdc_data |= 0x80;
> writeb(fpga_brdc_data, fpga_brdc);
>
> writeb(0x3, fpga_enable);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Roel Kluin @ 2007-11-08 16:33 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev
I guess it should be done after the last usage of kb_data or fpga_status?
--
Balance ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
index 8689f3e..4f3bac1 100644
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -99,28 +99,30 @@ sycamore_setup_arch(void)
kb_data = ioremap(SYCAMORE_PS2_BASE, 8);
if (!kb_data) {
printk(KERN_CRIT
"sycamore_setup_arch() kb_data ioremap failed\n");
return;
}
kb_cs = kb_data + 1;
+ iounmap(kb_data);
fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
if (!fpga_status) {
printk(KERN_CRIT
"sycamore_setup_arch() fpga_status ioremap failed\n");
return;
}
fpga_enable = fpga_status + 1;
fpga_polarity = fpga_status + 2;
fpga_trigger = fpga_status + 3;
fpga_brdc = fpga_status + 4;
+ iounmap(fpga_status);
/* split the keyboard and mouse interrupts */
fpga_brdc_data = readb(fpga_brdc);
fpga_brdc_data |= 0x80;
writeb(fpga_brdc_data, fpga_brdc);
writeb(0x3, fpga_enable);
diff --git a/arch/ppc/platforms/4xx/walnut.c b/arch/ppc/platforms/4xx/walnut.c
index 2f97723..8cfeb94 100644
--- a/arch/ppc/platforms/4xx/walnut.c
+++ b/arch/ppc/platforms/4xx/walnut.c
@@ -81,28 +81,30 @@ walnut_setup_arch(void)
kb_data = ioremap(WALNUT_PS2_BASE, 8);
if (!kb_data) {
printk(KERN_CRIT
"walnut_setup_arch() kb_data ioremap failed\n");
return;
}
kb_cs = kb_data + 1;
+ iounmap(kb_data);
fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
if (!fpga_status) {
printk(KERN_CRIT
"walnut_setup_arch() fpga_status ioremap failed\n");
return;
}
fpga_enable = fpga_status + 1;
fpga_polarity = fpga_status + 2;
fpga_trigger = fpga_status + 3;
fpga_brdc = fpga_status + 4;
+ iounmap(fpga_status);
/* split the keyboard and mouse interrupts */
fpga_brdc_data = readb(fpga_brdc);
fpga_brdc_data |= 0x80;
writeb(fpga_brdc_data, fpga_brdc);
writeb(0x3, fpga_enable);
^ permalink raw reply related
* Problems booting custom kernel and device tree on custom 85xx board
From: robert lazarski @ 2007-11-08 16:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I finished the main part of porting u-boot 1.3 rc3 to our custon 8548
board and am now trying to boot our 2.6.22 kernel and device tree:
=> bootm 1000000 - c00000
## Booting image at 01000000 ...
Image Name: Linux-2.6.22.2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1302607 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x1FF9DD50 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF00
bd address = 0x1FF9DFB0
memstart = 0x00000000
memsize = 0x20000000
flashstart = 0xF8000000
flashsize = 0x08000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xE0000000
bootflags = 0xE4013F80
intfreq = 888.888 MHz
busfreq = 355.555 MHz
ethaddr = 00:E0:0C:00:00:FD
eth1addr = 00:E0:0C:00:01:FD
eth2addr = 00:E0:0C:00:02:FD
eth3addr = 00:E0:0C:00:03:FD
IP addr = 10.101.43.142
baudrate = 115200 bps
Skipping initrd
Booting using the fdt at 0xc00000
No initrd
## device tree at 0x00C00000 ... 0x00C00CD3 (len=3284=0xCD4)
Loading Device Tree to 007fd000, end 007fdcd3 ... OK
## Transferring control to Linux (at address 00000000) ...
Where it hangs. I configured early serial output in the kernel, and
looking at the buffers after a soft reset we see:
grep __log_buf System.map
c029f424 b __log_buf
=> md 29f424 200
0029f424: 3c363e55 73696e67 204d5043 38357878 <6>Using MPC85xx
0029f434: 20415455 4d206d61 6368696e 65206465 ATUM machine de
0029f444: 73637269 7074696f 6e0a3c36 3e4d656d scription.<6>Mem
0029f454: 6f727920 43414d20 6d617070 696e673a ory CAM mapping:
0029f464: 2043414d 303d3235 364d622c 2043414d CAM0=256Mb, CAM
0029f474: 313d3235 364d622c 2043414d 323d304d 1=256Mb, CAM2=0M
0029f484: 62207265 73696475 616c3a20 304d620a b residual: 0Mb.
0029f494: 3c353e4c 696e7578 20766572 73696f6e <5>Linux version
0029f4a4: 20322e36 2e32322e 32202872 6f6f7440 2.6.22.2 (root@
0029f4b4: 6c696e75 782d726f 62657274 29202867 linux-robert) (g
0029f4c4: 63632076 65727369 6f6e2034 2e302e30 cc version 4.0.0
0029f4d4: 20284445 4e582045 4c444b20 342e3120 (DENX ELDK 4.1
0029f4e4: 342e302e 30292920 23312057 6564204e 4.0.0)) #1 Wed N
0029f4f4: 6f762037 2031363a 30393a34 30204553 ov 7 16:09:40 ES
0029f504: 54203230 30370a3c 373e466f 756e6420 T 2007.<7>Found
0029f514: 6c656761 63792073 65726961 6c20706f legacy serial po
0029f524: 72742030 20666f72 202f736f 63383534 rt 0 for /soc854
0029f534: 38406530 30303030 30302f73 65726961 8@e0000000/seria
0029f544: 6c403435 30300a3c 373e2020 6d656d3d l@4500.<7> mem=
0029f554: 65303030 34353030 2c207461 6464723d e0004500, taddr=
0029f564: 65303030 34353030 2c206972 713d302c e0004500, irq=0,
0029f574: 20636c6b 3d333535 35353535 34302c20 clk=355555540,
0029f584: 73706565 643d300a 3c373e46 6f756e64 speed=0.<7>Found
0029f594: 206c6567 61637920 73657269 616c2070 legacy serial p
0029f5a4: 6f727420 3120666f 72202f73 6f633835 ort 1 for /soc85
0029f5b4: 34384065 30303030 3030302f 73657269 48@e0000000/seri
0029f5c4: 616c4034 3630300a 3c373e20 206d656d al@4600.<7> mem
0029f5d4: 3d653030 30343630 302c2074 61646472 =e0004600, taddr
0029f5e4: 3d653030 30343630 302c2069 72713d30 =e0004600, irq=0
0029f5f4: 2c20636c 6b3d3335 35353535 3534302c , clk=355555540,
0029f604: 20737065 65643d30 0a3c373e 456e7465 speed=0.<7>Ente
0029f614: 72696e67 20616464 5f616374 6976655f ring add_active_
0029f624: 72616e67 6528302c 20302c20 31333130 range(0, 0, 1310
0029f634: 37322920 3020656e 74726965 73206f66 72) 0 entries of
0029f644: 20323536 20757365 640a3c37 3e546f70 256 used.<7>Top
0029f654: 206f6620 52414d3a 20307832 30303030 of RAM: 0x20000
0029f664: 3030302c 20546f74 616c2052 414d3a20 000, Total RAM:
0029f674: 30783230 30303030 30300a3c 373e4d65 0x20000000.<7>Me
0029f684: 6d6f7279 20686f6c 65207369 7a653a20 mory hole size:
0029f694: 304d420a 3c343e5a 6f6e6520 50464e20 0MB.<4>Zone PFN
0029f6a4: 72616e67 65733a0a 3c343e20 20444d41 ranges:.<4> DMA
0029f6b4: 20202020 20202020 20202020 2030202d 0 -
0029f6c4: 3e202020 31333130 37320a3c 343e2020 > 131072.<4>
0029f6d4: 4e6f726d 616c2020 20202031 33313037 Normal 13107
0029f6e4: 32202d3e 20202031 33313037 320a3c34 2 -> 131072.<4
0029f6f4: 3e656172 6c795f6e 6f64655f 6d61705b >early_node_map[
0029f704: 315d2061 63746976 65205046 4e207261 1] active PFN ra
0029f714: 6e676573 0a3c343e 20202020 303a2020 nges.<4> 0:
0029f724: 20202020 20203020 2d3e2020 20313331 0 -> 131
0029f734: 3037320a 3c373e4f 6e206e6f 64652030 072.<7>On node 0
0029f744: 20746f74 616c7061 6765733a 20313331 totalpages: 131
0029f754: 3037320a 3c373e20 20444d41 207a6f6e 072.<7> DMA zon
0029f764: 653a2031 30323420 70616765 73207573 e: 1024 pages us
0029f774: 65642066 6f72206d 656d6d61 700a3c37 ed for memmap.<7
0029f784: 3e202044 4d41207a 6f6e653a 20302070 > DMA zone: 0 p
0029f794: 61676573 20726573 65727665 640a3c37 ages reserved.<7
0029f7a4: 3e202044 4d41207a 6f6e653a 20313330 > DMA zone: 130
0029f7b4: 30343820 70616765 732c204c 49464f20 048 pages, LIFO
0029f7c4: 62617463 683a3331 0a000000 00000000 batch:31
0029f7d4: 00000000 00000000 00000000 00000000 ................
I'm not sure where to start looking at this point. Device tree issues?
gdb and the kernel? Any suggestions?
Robert
^ permalink raw reply
* RE: ML405 gigabit ethernet with kernel 2.6.23
From: Rick Moleres @ 2007-11-08 16:29 UTC (permalink / raw)
To: MingLiu, kentaro, linuxppc-embedded
In-Reply-To: <BAY138-W3232BA0AE8C193E22B5011B28B0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
Hi,
Yes, for 1500 MTU these aren’t too bad. One thing to note, using the TCP_STREAM option does not take advantage of zero-copy and possibly checksum offload on the transmit side. You should use the TCP_SENDFILE option for that. We typically use options such as:
netperf -c -C -H 192.168.1.1 -t TCP_STREAM -- -s131072 -S131072 -m65536
netperf -c -C -H 192.168.1.1 -t UDP_STREAM -- -s131072 -S131072 -m8192 (if using jumbo frames of 8982)
-Rick
________________________________
From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org [mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On Behalf Of MingLiu
Sent: Thursday, November 08, 2007 2:32 AM
To: kentaro; linuxppc-embedded@ozlabs.org
Subject: RE: ML405 gigabit ethernet with kernel 2.6.23
Dear Kentaro,
> -------------------------------------------------------------
> "netperf -H 192.168.1.1 -t TCP_STREAM" 110 Mbps
> "netperf -H 192.168.1.1 -t UDP_STREAM" 210 Mbps
> -------------------------------------------------------------
Are these results the ones with or without Jumbo-frame enabled? If no, they are quite good I think. The results from Montavista probably are the ones with Jumbo-frame enabled.
For anybody who has interest on this topic, I have recently an accepted paper which has part of the content on this. The link is http://web.it.kth.se/~mingliu/publications/co_design(icfpt07).pdf and in 6.2 section, I listed our measurement results. 300Mbps for TCP and 400Mbps for UDP, with Jumbo-frame enabled. Unfortunately I did not explain the details and detailed configurations on our case. So these results are only for your reference.
BR
Ming
________________________________
用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！ <http://spaces.live.com/?page=HP>
[-- Attachment #2: Type: text/html, Size: 6630 bytes --]
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Scott Wood @ 2007-11-08 16:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910711071815x344319ebye89168320dd53c0@mail.gmail.com>
Jon Smirl wrote:
> On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
>> Jon Smirl wrote:
>>> I'm not in favor of all these fsl prefixes. These chip families
>>> do get sold. What would we have done with intel,pxa320 all over
>>> the place when they sold it to marvell? mass changes to
>>> marvell,pxa320?
>> That's the idea, and there'd be a compatible entry for
>> intel,pxa320.
>
> The vendor part really isn't needed and it is going to be a source of
> trouble. The vendors are smart enough not to create two chips with
> the same part number. Adding a vendor qualifier complicates things
> needlessly.
I think you may be placing too much faith in the vendors.
Is a 7400 a Freescale powerpc chip, or a quad 2-input NAND gate? :-)
If you want to argue that the "MPC" part differentiates them, that's
just a less readable and more obsolete vendor prefix.
And not all compatible entries are part numbers; many are descriptions
of programming interfaces (such as cpm2 or gianfar). I'm not inclined
to bet that there will never be a conflict in such a namespace.
>> Actually the spec says you should use the stock ticker (IBM, FSL,
>> INTC, JAVA, MRVL) if they have one and if not, the company name in
>> lower case.
>>
>> Freescale are a funny one because they used to have a stock ticker
>> as MOT and then FSL but now they're privately owned, so it's gonna
>> have to be lower case :]
Well, technically the recommended prefix is an OUI number, and those are
less likely to change due to corporate shuffling, but they suck from a
readability perspective.
> Another example of how these vendor prefixes can change. The chip
> numbers are never going to change. Just use them and drop these
> vendor prefixes.
No. :-)
>> functionality. fsl,has-wdt differs from has-wdt ideally because
>
> This one I can buy, but it should be fsl-has-wdt. Drop the vendor
> prefixes.
How is fsl-has-wdt any better, other than it obscures namespace issues?
Vendor prefixes on properties are useful in that it might not mean
exactly the same thing as a similar property that gets standardized
later on.
> That's life in the Linux world, no backwards binary compatibility.
There's a huge difference between compatibility of kernel interfaces and
compatibility of interfaces between the kernel and something else --
whether it be userspace or firmware.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox