* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 18:27 UTC (permalink / raw)
To: Valentine Barshak, jwboyer, Michael Ellerman; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071015175717.GA4602@ru.mvista.com>
Valentine Barshak wrote:
> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC 440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 files changed, 39 insertions(+)
>
> --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
> +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
> @@ -306,8 +306,47 @@
> .ops = &cis8201_phy_ops
> };
>
> +static struct mii_phy_def bcm5248_phy_def = {
> +
> + .phy_id = 0x0143bc00,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "BCM5248 10/100 SMII Ethernet",
> + .ops = &generic_phy_ops
> +};
> +
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> + phy_write(phy, 0x14, 0x0ce3);
> + phy_write(phy, 0x18, 0x4101);
> + phy_write(phy, 0x09, 0x0e00);
> + phy_write(phy, 0x04, 0x01e1);
> + phy_write(phy, 0x00, 0x9140);
> + phy_write(phy, 0x00, 0x1140);
> +
> + return 0;
> +}
> +
> +static struct mii_phy_ops m88e1111_phy_ops = {
> + .init = m88e1111_init,
> + .setup_aneg = genmii_setup_aneg,
> + .setup_forced = genmii_setup_forced,
> + .poll_link = genmii_poll_link,
> + .read_link = genmii_read_link
> +};
> +
> +static struct mii_phy_def m88e1111_phy_def = {
> +
> + .phy_id = 0x01410CC0,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "Marvell 88E1111 Ethernet",
> + .ops = &m88e1111_phy_ops,
> +};
> +
> static struct mii_phy_def *mii_phy_table[] = {
> &cis8201_phy_def,
> + &bcm5248_phy_def,
> + &m88e1111_phy_def,
> &genmii_phy_def,
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple people are actively
working on the same driver.
Please coordinate, and have ONE person send me patches...
^ permalink raw reply
* [PATCH] PowerPC: Enable NEW EMAC support for Sequoia 440EPx.
From: Valentine Barshak @ 2007-10-15 17:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev
In-Reply-To: <20071015122616.08250b54@weaponx.rchland.ibm.com>
This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/platforms/44x/Kconfig | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
--- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30 15:05:50.000000000 +0400
+++ linux/arch/powerpc/platforms/44x/Kconfig 2007-07-30 17:59:05.000000000 +0400
@@ -48,10 +48,9 @@
config 440EPX
bool
select PPC_FPU
-# Disabled until the new EMAC Driver is merged.
-# select IBM_NEW_EMAC_EMAC4
-# select IBM_NEW_EMAC_RGMII
-# select IBM_NEW_EMAC_ZMII
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
config 440GP
bool
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-15 18:07 UTC (permalink / raw)
To: benh
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel,
Steven Rostedt
In-Reply-To: <1190858397.11034.22.camel@pasglop>
Benjamin Herrenschmidt wrote:
>>>I'm about to release a new -rt patch based on -rc8. This patch series
>>>blew up totally in trying to get it applied. I'm leaving it out, so after
>>>I release the next series, could you update these patches.
>> No wonder here: the -rt patch already has much of this code since around
>>2.6.21. They have been submitted by me, mostly... and this patchset is
>>against the Linus' tree.
> Proper approach is to rip off what is altready in -rt there and replace
> it with Tony patch set.
Tony's patchset is broken at places compared to what is in -rt. So that
would be proper *double standard* approach. :-/
> Ben.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-15 18:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linuxppc-dev, Paul Mackerras, Steven Rostedt, Realtime Kernel
In-Reply-To: <1190836713.23376.41.camel@chaos>
Hello.
Thomas Gleixner wrote:
>>> No wonder here: the -rt patch already has much of this code since around
>>>2.6.21. They have been submitted by me, mostly... and this patchset is
>>>against the Linus' tree.
>>That would explain it ;-)
>>I was searching the linux-rt-users mailing list for any patches, and
>>pulled in any that looked legit. These happen to in that mailing list too.
> I'll sort that out along with the other hrt updates.
Eh... poor you. Tony got clockevent driver reengineered for no apparent
reason. And he's introduced the jiffy drift by deleting the main loop from
timer_interrupt(). Yet this borken version was preferred to what was known
working since about 2.6.18 and included into 2.6.21-rt patchset. I don't like
that policy. Will you be pushing fixes from -rt to PowerPC, or will it fall on
my shoulders now?
> tglx
WBR, Sergei
^ permalink raw reply
* my git tree rebased
From: Kumar Gala @ 2007-10-15 18:00 UTC (permalink / raw)
To: linuxppc-dev list
For anyone using my git tree I've rebased it now that the merge
window for 2.6.24 is ongoing and removed all branches.
The master/HEAD now is in sync with Linus's tree. I'll be starting
of a fixes-2.6.24 branch at some point as well as for-2.6.25 branch.
I'll try to keep the master branch as a merge of the various patches
that exist in the other branches. Please use the master to create
any patches against.
- k
^ permalink raw reply
* [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Valentine Barshak @ 2007-10-15 17:57 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, jeff
In-Reply-To: <20071015122616.08250b54@weaponx.rchland.ibm.com>
This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+)
--- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
+++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
@@ -306,8 +306,47 @@
.ops = &cis8201_phy_ops
};
+static struct mii_phy_def bcm5248_phy_def = {
+
+ .phy_id = 0x0143bc00,
+ .phy_id_mask = 0x0ffffff0,
+ .name = "BCM5248 10/100 SMII Ethernet",
+ .ops = &generic_phy_ops
+};
+
+static int m88e1111_init(struct mii_phy *phy)
+{
+ printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
+ phy_write(phy, 0x14, 0x0ce3);
+ phy_write(phy, 0x18, 0x4101);
+ phy_write(phy, 0x09, 0x0e00);
+ phy_write(phy, 0x04, 0x01e1);
+ phy_write(phy, 0x00, 0x9140);
+ phy_write(phy, 0x00, 0x1140);
+
+ return 0;
+}
+
+static struct mii_phy_ops m88e1111_phy_ops = {
+ .init = m88e1111_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def m88e1111_phy_def = {
+
+ .phy_id = 0x01410CC0,
+ .phy_id_mask = 0x0ffffff0,
+ .name = "Marvell 88E1111 Ethernet",
+ .ops = &m88e1111_phy_ops,
+};
+
static struct mii_phy_def *mii_phy_table[] = {
&cis8201_phy_def,
+ &bcm5248_phy_def,
+ &m88e1111_phy_def,
&genmii_phy_def,
NULL
};
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Kumar Gala @ 2007-10-15 18:00 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <4713A474.1000301@ru.mvista.com>
On Oct 15, 2007, at 12:33 PM, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
>> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
>> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/
>> boot/dts/mpc8568mds.dts
>> index 8e15dba..1198363 100644
>> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
>> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
>> @@ -47,12 +47,45 @@
>> #address-cells = <2>;
>> #size-cells = <1>;
>> reg = <e0005000 d8>;
>> - ranges = <1 0 f8000000 0008000>;
>> + ranges = <1 0 f8000000 0008000
>> + 0 0 fe000000 2000000>;
>>
>> bcsr@1,0 {
>> device_type = "board-control";
>> reg = <1 0 8000>;
>> };
>> +
>> + flash@0,0 {
>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>> + reg = <0 0 2000000>;
>> + probe-type = "CFI";
>
> I don't get it -- has physmap_of.c rewrite been already committed?
> If yes, you don't need probe_type; if no, your "compatible" won't
> work...
> Well, I see that the driver rewrite has been committed (when I
> wasn't looking
> 8-)...
Any NOR flash nodes should conform to the "new" bindings from David
Gibson, et al. Not sure about the status of those being in
physmap_of.c w/regards to 2.6.24.
- k
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-15 17:40 UTC (permalink / raw)
To: Tony Breeds
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <20070921032603.0D3EA32C887@thor>
Hello.
Tony Breeds wrote:
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
I don't see my own signoff or at least a reference to my prior work in
this patch or even at -rt patch -- despite this code ha clearly borrowed from
it. And I'm not sure why this crippled version (lacking 40x/ Book E specific
clockevents implementation) is preferred over mine, unless this implementation
was only aimed at PPC64 machines...
> Index: working/arch/powerpc/Kconfig
> ===================================================================
> --- working.orig/arch/powerpc/Kconfig
> +++ working/arch/powerpc/Kconfig
> @@ -30,6 +30,9 @@ config GENERIC_TIME
> config GENERIC_TIME_VSYSCALL
> def_bool y
>
> +config GENERIC_CLOCKEVENTS
> + def_bool y
> +
> config GENERIC_HARDIRQS
> bool
> default y
Also, have the deterministic CPU accounting incompatibility with
clockevents been dealt with?
> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
[...]
> @@ -519,10 +541,12 @@ void __init iSeries_time_init_early(void
> void timer_interrupt(struct pt_regs * regs)
> {
> struct pt_regs *old_regs;
> - int next_dec;
> int cpu = smp_processor_id();
> - unsigned long ticks;
> - u64 tb_next_jiffy;
> + struct clock_event_device *evt = &per_cpu(decrementers, cpu);
> +
> + /* Ensure a positive value is written to the decrementer, or else
> + * some CPUs will continuue to take decrementer exceptions */
> + set_dec(DECREMENTER_MAX);
BookE and 40x CPUs don't need this.
> #ifdef CONFIG_PPC32
> if (atomic_read(&ppc_n_lost_interrupts) != 0)
> @@ -532,7 +556,6 @@ void timer_interrupt(struct pt_regs * re
> old_regs = set_irq_regs(regs);
> irq_enter();
>
> - profile_tick(CPU_PROFILING);
> calculate_steal_time();
>
> #ifdef CONFIG_PPC_ISERIES
> @@ -540,44 +563,20 @@ void timer_interrupt(struct pt_regs * re
> get_lppaca()->int_dword.fields.decr_int = 0;
> #endif
>
> - while ((ticks = tb_ticks_since(per_cpu(last_jiffy, cpu)))
> - >= tb_ticks_per_jiffy) {
> - /* Update last_jiffy */
> - per_cpu(last_jiffy, cpu) += tb_ticks_per_jiffy;
> - /* Handle RTCL overflow on 601 */
> - if (__USE_RTC() && per_cpu(last_jiffy, cpu) >= 1000000000)
> - per_cpu(last_jiffy, cpu) -= 1000000000;
I don't see where the patch removes those variables themselves...
[...]
> - write_seqlock(&xtime_lock);
> - tb_next_jiffy = tb_last_jiffy + tb_ticks_per_jiffy;
> - if (__USE_RTC() && tb_next_jiffy >= 1000000000)
> - tb_next_jiffy -= 1000000000;
> - if (per_cpu(last_jiffy, cpu) >= tb_next_jiffy) {
> - tb_last_jiffy = tb_next_jiffy;
> - do_timer(1);
> - }
> - write_sequnlock(&xtime_lock);
> - }
Again, where those variables are removed?
> -
> - next_dec = tb_ticks_per_jiffy - ticks;
> - set_dec(next_dec);
> + if (evt->event_handler)
> + evt->event_handler(evt);
> + else
> + evt->set_next_event(DECREMENTER_MAX, evt);
We have already set it to DECREMENTER_MAX at the start of the function.
Please remove the 'else' part...
> @@ -797,6 +796,53 @@ void __init clocksource_init(void)
> clock->name, clock->mult, clock->shift);
> }
>
> +static int decrementer_set_next_event(unsigned long evt,
> + struct clock_event_device *dev)
> +{
> + set_dec(evt);
I'd use (evt - 1) since the interrupt gets generated at 0xffffffff count,
not 0 (on classic CPUs). With you removing of the code that compensated for
the errors, they will accumulate. And no, this wouldn't be enough anyway,
since on 40x and Book E you'll need to set it for evt anyway, since the
interrupt happens at 0 count...
NAK the patch. And I really don't understand why you're throwing alway
already tested/working code...
> + return 0;
> +}
> +
> +static void decrementer_set_mode(enum clock_event_mode mode,
> + struct clock_event_device *dev)
> +{
> + if (mode != CLOCK_EVT_MODE_ONESHOT)
> + decrementer_set_next_event(DECREMENTER_MAX, dev);
> +}
> +
> +static void register_decrementer_clockevent(int cpu)
> +{
> + struct clock_event_device *dec = &per_cpu(decrementers, cpu);
> +
> + *dec = decrementer_clockevent;
> + dec->cpumask = cpumask_of_cpu(cpu);
> +
> + printk(KERN_ERR "clockevent: %s mult[%lx] shift[%d] cpu[%d]\n",
This is a mistake indeed. :-P
WBR, Sergei
^ permalink raw reply
* Re: jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails
From: N. van Bolhuis @ 2007-10-15 17:25 UTC (permalink / raw)
To: linux-mtd, linuxppc-embedded
OK, so there's nothing wrong with the linux-mtd mailing
list. It's alive.
I guess the archives are moved to
www.infradead.org/pipermail/linux-mtd and many existing
pages still refer to list.infradead.org/pipermail/linux-mtd
To be complete and to provide an answer (to my own question)
I'll show what I did to make things work.
Btw. in my previous post I mentioned somewhere
"It wants to match with unlock address 0x0aaa 0x0555 (because this is the one
listed in the jedec_table[] entry for cfi->device_type=2=X16) and both pair
of unlock addresses (which do get the chip in autoselect mode) do not match."
This is incorrect.
"0x0aaa 0x0555" is not listed in the jedec_table[] entry for x16. It's selected
because of the finfo_uaddr function having this if statement:
if (uaddr != MTD_UADDR_NOT_SUPPORTED ) {
uaddr = finfo->uaddr[0];
}
return uaddr;
So, in x16 always "0x0aaa 0x0555" (entry for x8) is considered to be the unlock
address.
But this doesn't hurt me since our 16 bit AMD/Spansion flash device needs to
be recognized in 8 bit mode anyway since (obviously) it is used in 8 bit mode.
Looking through the archives shows more developers have dealt with this problem.
The unlock_addr function is suspicious. There's even a patch for this function
to make things work, but dwmw2 rejected it because things are supposed to be shifted
automatically for different device modes (x8, x16, x32).
Somewhere in the archives it is mentioned the device id should be read from
address 2 (and not 1) (for an AM29LV800 in byte mode). I suffer from this problem too.
Also somewhere in the archives the finfo_uaddr function is blamed, in particular
the if statement I showed above.
Obviously the jedec_probe simply doesn't work for all possible flash device and
(embedded) board configurations. This is exactly what the comment
in jedec_probe.c (above the function jedec_match) suggests.
I added the following to jedec_probe.c to make things work:
#define AM29LV160DTBYTE 0x0001
}, {
.mfr_id = MANUFACTURER_AMD,
.dev_id = AM29LV160DTBYTE,
.name = "S29AL016D TB (byte mode)",
.uaddr = {
[0] = MTD_UADDR_0x0AAA_0x0555 /* x8 */
},
.DevSize = SIZE_2MiB,
.CmdSet = P_ID_AMD_STD,
.NumEraseRegions= 4,
.regions = {
ERASEINFO(0x10000,31),
ERASEINFO(0x08000,1),
ERASEINFO(0x02000,2),
ERASEINFO(0x04000,1)
}
Not wanting to break functionality for some native 8 bit flash devices we use
(which do read their device id on address 1) I added device id 0x0001 since
it is guaranteed to be the same as the manfacturer id and was still free.
BR,
N. van Bolhuis.
--
This message has been scanned for viruses and is believed to be clean
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Olof Johansson @ 2007-10-15 17:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710151014q5e151ea9w3f589d9e89e95905@mail.gmail.com>
Hi,
On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> On 10/15/07, Olof Johansson <olof@lixom.net> wrote:
> >
> > The flat device tree is, in spite of what some people would like it to be,
> > not open firmware, nor is it the same as their bindings. So I think we'd
> > be doing ourselves a disservice by continuing to associate them together.
> > All it would take is a rename of the directory, unfortunately i don't
> > have any suggestions on better names though.
>
> I think I need to stick with the of prefix. All the support API in
> include/linux/of_* is prefixed with "of_" already, so convention is
> established.
>
> How about Documentation/of-device-tree?
Sounds good to me, even though it doesn't really address the original
OF separation comment. :)
Maybe it's enough to document the difference between the linux-specific
flat device tree bindings and classic 1275-style bindings in the top
readme in that directory. Either way, it's not worth arguing over,
your suggestion is good enough.
> > Looks reasonable. The other way to cut it would be to slice along vendor
> > boundaries, but I think I like the functional partitioning you suggested
> > better.
>
> I think vendor partitioning makes sense for non-common devices that
> don't easily fit into a particular mold (soc glue nodes come to mind).
> Other than that, the functional partitioning
> lets us start with defining common property usage for a given device
> type and follow up with device specific properties.
Yep, it could always be added down the road in case it's needed.
-Olof
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Sergei Shtylyov @ 2007-10-15 17:33 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071015161631.GB30512@localhost.localdomain>
Anton Vorontsov wrote:
> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
> index 8e15dba..1198363 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -47,12 +47,45 @@
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <e0005000 d8>;
> - ranges = <1 0 f8000000 0008000>;
> + ranges = <1 0 f8000000 0008000
> + 0 0 fe000000 2000000>;
>
> bcsr@1,0 {
> device_type = "board-control";
> reg = <1 0 8000>;
> };
> +
> + flash@0,0 {
> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
> + reg = <0 0 2000000>;
> + probe-type = "CFI";
I don't get it -- has physmap_of.c rewrite been already committed?
If yes, you don't need probe_type; if no, your "compatible" won't work...
Well, I see that the driver rewrite has been committed (when I wasn't looking
8-)...
> + bank-width = <2>;
> + device-width = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + hrcw@0 {
> + label = "hrcw";
> + reg = <0 20001>;
What?! Odd sized partition? Don't try to follow both the old and new
partition device tree specs -- you'll only get yourself into trouble with
this. The size-cell doesn't bear r/o flag in the new paritions spec.
> + read-only;
> + };
> +
> + kernel@20000 {
> + label = "kernel";
> + reg = <20000 200000>;
> + };
> +
> + rootfs@220000 {
> + label = "rootfs";
> + reg = <220000 1d60000>;
> + };
> +
> + uboot@1f80000 {
> + label = "u-boot";
> + reg = <1f80000 80000>;
> + read-only;
Well, this is not even consistent... :-)
> + };
> + };
> };
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] PowerPC: Add NEW EMAC driver support to 440EPx Sequoia board.
From: Josh Boyer @ 2007-10-15 17:26 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071012130305.GA14682@ru.mvista.com>
On Fri, 12 Oct 2007 17:03:05 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> and adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
Could you send the phy part to Jeff Garzik and the netdev list by
itself? That way it will get picked up and we'll update the Kconfig
with a later patch.
josh
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-15 17:17 UTC (permalink / raw)
To: keng_629; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <200710151115352659084@126.com>
keng_629 wrote:
>
> i am proting linux2.63.23 to mpc860t board with uboot1.1.4 as bootloader.
> my bootargs is root=/dev/ram rw init=/linuxrc.
> i use debugger to see the regedits, find pc is run in the cpu_idle().
> what is wrong with my kernel, plese give me some advice.thank you .
Posting the same thing over and over again isn't going to change the
response. Try head-of-Linus's-git, make sure you're using arch/powerpc,
and post the device tree you're using. Without more information, we
can't help you.
-Scott
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-15 17:14 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071015165505.GA16040@lixom.net>
On 10/15/07, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> > Adding the Linux expected device tree bindings to
> > booting-without-of.txt seems to be getting a little unwieldy. Plus
> > with more than one arch using the device tree (powerpc, sparc &
> > microblaze) the device tree bindings aren't necessarily powerpc only
> > (the Xilinx devices certainly fall in this category).
> >
> > Anyone have comments about splitting the expected device tree bindings
> > out of booting-without-of.txt into a separate directory?
>
> The flat device tree is, in spite of what some people would like it to be,
> not open firmware, nor is it the same as their bindings. So I think we'd
> be doing ourselves a disservice by continuing to associate them together.
> All it would take is a rename of the directory, unfortunately i don't
> have any suggestions on better names though.
I think I need to stick with the of prefix. All the support API in
include/linux/of_* is prefixed with "of_" already, so convention is
established.
How about Documentation/of-device-tree?
>
> > Perhaps something like this; each file contains common bindings for
> > the type of device and device specific properties:
> >
> > Documentation/of/
> > Documentation/of/README - Description of the purpose and layout of
> > this directory
> > Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc)
> > Documentation/of/serial.txt - serial device bindings
> > Documentation/of/misc.txt - anything that doesn't fit anywhere else yet.
> > Documentation/of/soc/* - System on chip stuff that doesn't fit will
> > into established device types; possibly a separate file for each chip.
> > Documentation/of/usb.txt - usb blah blah blah
> > Documentation/of/whatever - you get the picture.
> >
> > Thoughts?
>
> Looks reasonable. The other way to cut it would be to slice along vendor
> boundaries, but I think I like the functional partitioning you suggested
> better.
I think vendor partitioning makes sense for non-common devices that
don't easily fit into a particular mold (soc glue nodes come to mind).
Other than that, the functional partitioning
lets us start with defining common property usage for a given device
type and follow up with device specific properties.
Thanks for the feedback,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 16:57 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20071015163216.GA8127@gate.ebshome.net>
On 10/15/07, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Oct 15, 2007 at 03:29:11PM +0200, Stefan Roese wrote:
>
> <snip>
>
> > +#ifdef CONFIG_PPC_MERGE
> > +static int device_idx = -1;
> > +#endif
> > +
>
> <snip>
>
> > + dev->idx = ++device_idx;
> > + adap->nr = dev->idx;
>
> Hmm, this doesn't look right. That mighty powerpc device everybody
> was so excited about for the last years doesn't provide a device
> instance number/index?
>
> I think this approach is wrong, because I want i2c bus numbers for the
> on-chip i2c to be fixed. This code makes it dependent on the order
> devices were described in the device tree; how do you handle a
> situation when only the second i2c adapter is connected? For OCP I
> would just remove ocp_def for the IIC0.
Segher is recommending that we use an aliases node as per the open
firmware example for this. I think in this case it would look
something like this (but I'm not the expert):
aliases {
IIC0 = "/path/to/bus/iic@0x2000";
IIC1 = "/path/to/bus/iic@0x2000";
};
Which seems to make sense to me. And it keeps it easy to have
multiple iic bus types sharing the same IIC bus number space (each
device does not try to maintain it's own little 'next index' value).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Override timer interrupt
From: Rune Torgersen @ 2007-10-15 16:49 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <1192229894.22054.29.camel@pasglop>
> From: Benjamin Herrenschmidt
> In fact, I'm not sure what is your problem with the DEC=20
> proper as the TB
> will be used ultimately and thus it shouldn't drift more than the TB
> does. Can your part use an externally clocked TB ?
>=20
> If not, and you still have a drift despite calibration, you can always
> use NTP services to adjust timekeeping.
We use NTP, which is why I didn't see it until recently. (Happened to
have a board without NTP configured
The main couse is that our main bus frequency cannort be divided into
1kHz evently by the decrementer.
Main bus freq =3D 99532800 Hz.
Decrementer then becomes 24883, which gives us 999991.9624485600nsec per
jiffy.
That is not a number easilly converted into time without drift.
Changing HZ to 100 fixes it, but is for varous reasons not an option
right now.
What I did do is change the timer interrupt to be called by an ecxternal
1kHz interrupt source instead of the decrementer.
The TB register is only ued for offsets from the last jiffie, not as a
continous offset, so then it works out pretty good.
There is a discontinuity in the sub ms resolution of the clock that I
can live with. msec and up are dead accurate.
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Olof Johansson @ 2007-10-15 16:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710150908o55d1f5d2t264cbb8ed800a12f@mail.gmail.com>
On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> Adding the Linux expected device tree bindings to
> booting-without-of.txt seems to be getting a little unwieldy. Plus
> with more than one arch using the device tree (powerpc, sparc &
> microblaze) the device tree bindings aren't necessarily powerpc only
> (the Xilinx devices certainly fall in this category).
>
> Anyone have comments about splitting the expected device tree bindings
> out of booting-without-of.txt into a separate directory?
The flat device tree is, in spite of what some people would like it to be,
not open firmware, nor is it the same as their bindings. So I think we'd
be doing ourselves a disservice by continuing to associate them together.
All it would take is a rename of the directory, unfortunately i don't
have any suggestions on better names though.
> Perhaps something like this; each file contains common bindings for
> the type of device and device specific properties:
>
> Documentation/of/
> Documentation/of/README - Description of the purpose and layout of
> this directory
> Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc)
> Documentation/of/serial.txt - serial device bindings
> Documentation/of/misc.txt - anything that doesn't fit anywhere else yet.
> Documentation/of/soc/* - System on chip stuff that doesn't fit will
> into established device types; possibly a separate file for each chip.
> Documentation/of/usb.txt - usb blah blah blah
> Documentation/of/whatever - you get the picture.
>
> Thoughts?
Looks reasonable. The other way to cut it would be to slice along vendor
boundaries, but I think I like the functional partitioning you suggested
better.
-Olof
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-15 16:46 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200710151529.11485.sr@denx.de>
On 10/15/07, Stefan Roese <sr@denx.de> wrote:
> This patch reworks existing ibm-iic driver to support of_platform_device
> and enables it to talk to device tree directly. The "old" OCP interface
> for arch/ppc is still supported via #ifdef's and shall be removed when
> arch/ppc is gone in a few months.
>
> This is done to enable I2C support for the PPC4xx platforms now
> being moved from arch/ppc (ocp) to arch/powerpc (of).
May I suggest another approach?
Take a look at driver/video/xilinxfb.c.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/video/xilinxfb.c;h=6ef99b2d13ca6f8a4809d5914cbab6309255b3e3;hb=287e5d6fcccfa38b953cebe307e1ddfd32363355
That driver supports both the platform bus and the of_platform bus.
(xilinxfb_of_probe and xilinxfb_platform_probe) and both functions
call a common setup routine (xilinxfb_assign; but I probably should
have named it xilinxfb_setup).
Rather than writing an entirely new probe function; I suggest
splitting the binding code from the initialization code. The binding
code translates from the device description (be that platform bus,
of_platform bus, ocp, whatever) to the values the driver needs. The
initialization code needs to do the same thing for both bus bindings,
and the bus binding code is only concerned with getting the
appropriate values from the device descripton.
It's a little bit more work to refactor the driver to follow this
mode, but it results in far less code which is easier to review and
understand. Plus the device description is incomplete, you can bail
out before you start allocating and mapping memory that needs to be
unwound.
Cheers,
g.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-ibm_iic.c | 209 +++++++++++++++++++++++++++++++++++++-
> drivers/i2c/busses/i2c-ibm_iic.h | 2 +
> 3 files changed, 211 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index de95c75..a47b5e6 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -241,7 +241,7 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on 4xx
> help
> Say Y here if you want to use IIC peripheral found on
> embedded IBM PPC 4xx based systems.
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
> index 956b947..78c6bf4 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -39,8 +39,13 @@
> #include <asm/io.h>
> #include <linux/i2c.h>
> #include <linux/i2c-id.h>
> +
> +#ifdef CONFIG_PPC_MERGE
> +#include <linux/of_platform.h>
> +#else
> #include <asm/ocp.h>
> #include <asm/ibm4xx.h>
> +#endif
>
> #include "i2c-ibm_iic.h"
>
> @@ -57,6 +62,10 @@ static int iic_force_fast;
> module_param(iic_force_fast, bool, 0);
> MODULE_PARM_DESC(iic_fast_poll, "Force fast mode (400 kHz)");
>
> +#ifdef CONFIG_PPC_MERGE
> +static int device_idx = -1;
> +#endif
> +
> #define DBG_LEVEL 0
>
> #ifdef DBG
> @@ -660,8 +669,205 @@ static inline u8 iic_clckdiv(unsigned int opb)
> /*
> * Register single IIC interface
> */
> -static int __devinit iic_probe(struct ocp_device *ocp){
>
> +#ifdef CONFIG_PPC_MERGE
> +/*
> + * device-tree (of) when used from arch/powerpc
> + */
> +static int __devinit iic_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct ibm_iic_private* dev;
> + struct i2c_adapter* adap;
> + struct device_node *np;
> + int ret = -ENODEV;
> + int irq, len;
> + const u32 *prop;
> + struct resource res;
> +
> + np = ofdev->node;
> + if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
> + printk(KERN_CRIT "ibm-iic(%s): failed to allocate device data\n",
> + np->full_name);
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(&ofdev->dev, dev);
> +
> + dev->np = np;
> + irq = irq_of_parse_and_map(np, 0);
> +
> + if (of_address_to_resource(np, 0, &res)) {
> + printk(KERN_ERR "ibd-iic(%s): Can't get registers address\n",
> + np->full_name);
> + goto fail1;
> + }
> + dev->paddr = res.start;
> +
> + if (!request_mem_region(dev->paddr, sizeof(struct iic_regs), "ibm_iic")) {
> + ret = -EBUSY;
> + goto fail1;
> + }
> + dev->vaddr = ioremap(dev->paddr, sizeof(struct iic_regs));
> +
> + if (dev->vaddr == NULL) {
> + printk(KERN_CRIT "ibm-iic(%s): failed to ioremap device regs\n",
> + dev->np->full_name);
> + ret = -ENXIO;
> + goto fail2;
> + }
> +
> + init_waitqueue_head(&dev->wq);
> +
> + dev->irq = iic_force_poll ? -1 : (irq == NO_IRQ) ? -1 : irq;
> + if (dev->irq >= 0){
> + /* Disable interrupts until we finish initialization,
> + * assumes level-sensitive IRQ setup...
> + */
> + iic_interrupt_mode(dev, 0);
> + if (request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)) {
> + printk(KERN_ERR "ibm-iic(%s): request_irq %d failed\n",
> + dev->np->full_name, dev->irq);
> + /* Fallback to the polling mode */
> + dev->irq = -1;
> + }
> + }
> +
> + if (dev->irq < 0)
> + printk(KERN_WARNING "ibm-iic(%s): using polling mode\n",
> + dev->np->full_name);
> +
> + /* Board specific settings */
> + prop = of_get_property(np, "iic-mode", &len);
> + /* use 400kHz only if stated in dts, 100kHz otherwise */
> + dev->fast_mode = (prop && (*prop == 400));
> + /* clckdiv is the same for *all* IIC interfaces,
> + * but I'd rather make a copy than introduce another global. --ebs
> + */
> + /* Parent bus should have frequency filled */
> + prop = of_get_property(of_get_parent(np), "clock-frequency", &len);
> + if (prop == NULL) {
> + printk(KERN_ERR
> + "ibm-iic(%s):no clock-frequency prop on parent bus!\n",
> + dev->np->full_name);
> + goto fail;
> + }
> +
> + dev->clckdiv = iic_clckdiv(*prop);
> + DBG("%s: clckdiv = %d\n", dev->np->full_name, dev->clckdiv);
> +
> + /* Initialize IIC interface */
> + iic_dev_init(dev);
> +
> + /* Register it with i2c layer */
> + adap = &dev->adap;
> + adap->dev.parent = &ofdev->dev;
> + strcpy(adap->name, "IBM IIC");
> + i2c_set_adapdata(adap, dev);
> + adap->id = I2C_HW_OCP;
> + adap->class = I2C_CLASS_HWMON;
> + adap->algo = &iic_algo;
> + adap->client_register = NULL;
> + adap->client_unregister = NULL;
> + adap->timeout = 1;
> + adap->retries = 1;
> +
> + dev->idx = ++device_idx;
> + adap->nr = dev->idx;
> + if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
> + printk(KERN_CRIT"ibm-iic(%s): failed to register i2c adapter\n",
> + dev->np->full_name);
> + goto fail;
> + }
> +
> + printk(KERN_INFO "ibm-iic(%s): using %s mode\n", dev->np->full_name,
> + dev->fast_mode ?
> + "fast (400 kHz)" : "standard (100 kHz)");
> +
> + return 0;
> +
> +fail:
> + if (dev->irq >= 0){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + }
> +
> + iounmap(dev->vaddr);
> +fail2:
> + release_mem_region(dev->paddr, sizeof(struct iic_regs));
> +fail1:
> + dev_set_drvdata(&ofdev->dev, NULL);
> + kfree(dev);
> +
> + return ret;
> +}
> +
> +/*
> + * Cleanup initialized IIC interface
> + */
> +static int __devexit iic_remove(struct of_device *ofdev)
> +{
> + struct ibm_iic_private *dev =
> + (struct ibm_iic_private *)dev_get_drvdata(&ofdev->dev);
> + BUG_ON(dev == NULL);
> + if (i2c_del_adapter(&dev->adap)){
> + printk(KERN_CRIT "ibm-iic(%s): failed to delete i2c adapter\n",
> + dev->np->full_name);
> + /* That's *very* bad, just shutdown IRQ ... */
> + if (dev->irq >= 0){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + dev->irq = -1;
> + }
> + } else {
> + if (dev->irq >= 0){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + }
> + iounmap(dev->vaddr);
> + release_mem_region(dev->paddr, sizeof(struct iic_regs));
> + kfree(dev);
> + }
> + return 0;
> +}
> +
> +static struct of_device_id ibm_iic_match[] = {
> + {
> + .type = "i2c",
> + .compatible = "ibm,iic",
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, ibm_iic_match);
> +
> +static struct of_platform_driver ibm_iic_driver = {
> + .name = "ibm-iic",
> + .match_table = ibm_iic_match,
> + .probe = iic_probe,
> + .remove = iic_remove,
> +#if defined(CONFIG_PM)
> + .suspend = NULL,
> + .resume = NULL,
> +#endif
> +};
> +
> +static int __init iic_init(void)
> +{
> + printk(KERN_INFO "IBM IIC driver v" DRIVER_VERSION "\n");
> + return of_register_platform_driver(&ibm_iic_driver);
> +}
> +
> +static void __exit iic_exit(void)
> +{
> + of_unregister_platform_driver(&ibm_iic_driver);
> +}
> +#else
> +/*
> + * OCP when used from arch/ppc
> + */
> +static int __devinit iic_probe(struct ocp_device *ocp)
> +{
> struct ibm_iic_private* dev;
> struct i2c_adapter* adap;
> struct ocp_func_iic_data* iic_data = ocp->def->additions;
> @@ -828,6 +1034,7 @@ static void __exit iic_exit(void)
> {
> ocp_unregister_driver(&ibm_iic_driver);
> }
> +#endif /* CONFIG_PPC_MERGE */
>
> module_init(iic_init);
> module_exit(iic_exit);
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.h b/drivers/i2c/busses/i2c-ibm_iic.h
> index fdaa482..c15b091 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.h
> +++ b/drivers/i2c/busses/i2c-ibm_iic.h
> @@ -50,6 +50,8 @@ struct ibm_iic_private {
> int irq;
> int fast_mode;
> u8 clckdiv;
> + struct device_node *np;
> + phys_addr_t paddr;
> };
>
> /* IICx_CNTL register */
> --
> 1.5.3.4
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Eugene Surovegin @ 2007-10-15 16:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200710151529.11485.sr@denx.de>
On Mon, Oct 15, 2007 at 03:29:11PM +0200, Stefan Roese wrote:
<snip>
> +#ifdef CONFIG_PPC_MERGE
> +static int device_idx = -1;
> +#endif
> +
<snip>
> + dev->idx = ++device_idx;
> + adap->nr = dev->idx;
Hmm, this doesn't look right. That mighty powerpc device everybody
was so excited about for the last years doesn't provide a device
instance number/index?
I think this approach is wrong, because I want i2c bus numbers for the
on-chip i2c to be fixed. This code makes it dependent on the order
devices were described in the device tree; how do you handle a
situation when only the second i2c adapter is connected? For OCP I
would just remove ocp_def for the IIC0.
--
Eugene
^ permalink raw reply
* [PATCH v2 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Anton Vorontsov @ 2007-10-15 16:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071015155730.GA30008@localhost.localdomain>
MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Patch is against galak/powerpc.git master branch.
arch/powerpc/boot/dts/mpc8568mds.dts | 35 +++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 8e15dba..1198363 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -47,12 +47,45 @@
#address-cells = <2>;
#size-cells = <1>;
reg = <e0005000 d8>;
- ranges = <1 0 f8000000 0008000>;
+ ranges = <1 0 f8000000 0008000
+ 0 0 fe000000 2000000>;
bcsr@1,0 {
device_type = "board-control";
reg = <1 0 8000>;
};
+
+ flash@0,0 {
+ compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
+ reg = <0 0 2000000>;
+ probe-type = "CFI";
+ bank-width = <2>;
+ device-width = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ hrcw@0 {
+ label = "hrcw";
+ reg = <0 20001>;
+ read-only;
+ };
+
+ kernel@20000 {
+ label = "kernel";
+ reg = <20000 200000>;
+ };
+
+ rootfs@220000 {
+ label = "rootfs";
+ reg = <220000 1d60000>;
+ };
+
+ uboot@1f80000 {
+ label = "u-boot";
+ reg = <1f80000 80000>;
+ read-only;
+ };
+ };
};
soc8568@e0000000 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH v2 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Anton Vorontsov @ 2007-10-15 16:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071015155730.GA30008@localhost.localdomain>
This patch creates localbus node, moves bcsr into it, and adds
localbus to the probe path.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Notice that localbus control registers are in the soc address
space, but ranges are not. Just the same situation as with PCI
nodes.
Patch is against galak/powerpc.git master branch.
arch/powerpc/boot/dts/mpc8568mds.dts | 14 +++++++++++---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..8e15dba 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -42,9 +42,17 @@
reg = <00000000 10000000>;
};
- bcsr@f8000000 {
- device_type = "board-control";
- reg = <f8000000 8000>;
+ localbus@e0005000 {
+ compatible = "fsl,mpc8568mds-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <e0005000 d8>;
+ ranges = <1 0 f8000000 0008000>;
+
+ bcsr@1,0 {
+ device_type = "board-control";
+ reg = <1 0 8000>;
+ };
};
soc8568@e0000000 {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 61b3eed..0cf994b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -139,6 +139,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "qe", },
+ { .compatible = "fsl,mpc8568mds-localbus", },
{},
};
--
1.5.0.6
^ permalink raw reply related
* Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-15 16:08 UTC (permalink / raw)
To: linuxppc-dev, microblaze-uclinux
Adding the Linux expected device tree bindings to
booting-without-of.txt seems to be getting a little unwieldy. Plus
with more than one arch using the device tree (powerpc, sparc &
microblaze) the device tree bindings aren't necessarily powerpc only
(the Xilinx devices certainly fall in this category).
Anyone have comments about splitting the expected device tree bindings
out of booting-without-of.txt into a separate directory?
Perhaps something like this; each file contains common bindings for
the type of device and device specific properties:
Documentation/of/
Documentation/of/README - Description of the purpose and layout of
this directory
Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc)
Documentation/of/serial.txt - serial device bindings
Documentation/of/misc.txt - anything that doesn't fit anywhere else yet.
Documentation/of/soc/* - System on chip stuff that doesn't fit will
into established device types; possibly a separate file for each chip.
Documentation/of/usb.txt - usb blah blah blah
Documentation/of/whatever - you get the picture.
Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Anton Vorontsov @ 2007-10-15 15:57 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <47138A54.8030307@ru.mvista.com>
On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
> Anton Vorontsov wrote:
>
>> This patch creates localbus node, moves bcsr into it, and adds
>> localbus to the probe path.
>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
>> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
>> b/arch/powerpc/boot/dts/mpc8568mds.dts
>> index 5439437..296adc3 100644
>> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
>> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
>> @@ -42,9 +42,17 @@
>> reg = <00000000 10000000>;
>> };
>> - bcsr@f8000000 {
Heh, this is wrong.
>> - device_type = "board-control";
>> - reg = <f8000000 8000>;
>> + localbus@f0000000 {
>> + compatible = "fsl,mpc8568mds-localbus";
>
> Is the entity described as "localbus" indeed so *board* specific?
That's what booting-without-of.txt gives as an example.
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + reg = <f0000000 10000000>;
>> + ranges = <0 0 f8000000 0008000>;
>
> Isn't that range a part of "reg"?
Heh. Right you are.
>> +
>> + bcsr@0,0 {
Hrm, wrong.
>> + device_type = "board-control";
>> + reg = <0 0 8000>;
>> + };
>> };
>> soc8568@e0000000 {
>
> WBR, Sergei
I'll repost fixed version shortly.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-15 15:53 UTC (permalink / raw)
To: linuxppc-dev, Wolfgang Reissnegger, Leonid, Stephen Neuendorffer,
microblaze-uclinux
From: Grant Likely <grant.likely@secretlab.ca>
Here's my second version of xilinx device tree bindings. Please review
and comment. I'd like to push these out to Paulus in the next couple
of days.
Cheers,
g.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Documentation/powerpc/booting-without-of.txt | 55 ++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7a6c5f2..21afaea 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2089,6 +2089,61 @@ platforms are moved over to use the flattened-device-tree model.
More devices will be defined as this spec matures.
+ l) Xilinx ML300 Framebuffer
+
+ Simple framebuffer device from the ML300 reference design (also on the
+ ML403 reference design as well as others).
+
+ Required properties:
+ - compatible : Must include "xilinx,ml300-fb"
+ - reg : offset and length of the framebuffer register set
+
+ Optional properties:
+ - resolution : <xres yres> pixel resolution of framebuffer. Some
+ implementations use a different resolution. Default
+ is <d#640 d#480>
+ - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
+ Default is <d#1024 d#480>.
+ - rotate-display (empty) : rotate display 180 degrees.
+
+ m) Xilinx SystemACE
+
+ The Xilinx SystemACE device is used to program FPGAs from an FPGA
+ bitstream stored on a CF card. It can also be used as a generic CF
+ interface device.
+
+ Required properties:
+ - compatible : Must include "xilinx,sysace"
+ - reg : offset and length of SystemACE register set
+
+ Recommended properties:
+ - interrupt-parent, interrupts : Connection of device irq signal.
+
+ Optional properties:
+ - 8-bit (empty) : Set this property if the SystemACE must be in 8 bit mode
+
+ n) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. Uses common properties from other Ethernet
+ devices with the following constraints:
+
+ Required properties:
+ - compatible : Must include one of: "xilinx,plb-temac",
+ "xilinx,plb-emac", "xilinx-opb-emac"
+ - dma-mode : Must be one of "none", "simple", "sg" (sg == scatter gather)
+
+ o) Xilinx Uartlite
+
+ Xilinx uartlite devices are simple fixed speed serial ports. Uartlite
+ ports should be described in a node with the following properties.
+
+ Requred properties:
+ - compatible : Must include "xilinx,uartlite"
+ - reg : offset and length of uartlite register set
+
+ Recommended properties:
+ - interrupt-parent, interrupts : Connection of device irq signal.
+
VII - Specifying interrupt information for devices
===================================================
^ permalink raw reply related
* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Sergei Shtylyov @ 2007-10-15 15:42 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071015153525.GA28761@localhost.localdomain>
Anton Vorontsov wrote:
> This patch creates localbus node, moves bcsr into it, and adds
> localbus to the probe path.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
> index 5439437..296adc3 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -42,9 +42,17 @@
> reg = <00000000 10000000>;
> };
>
> - bcsr@f8000000 {
> - device_type = "board-control";
> - reg = <f8000000 8000>;
> + localbus@f0000000 {
> + compatible = "fsl,mpc8568mds-localbus";
Is the entity described as "localbus" indeed so *board* specific?
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <f0000000 10000000>;
> + ranges = <0 0 f8000000 0008000>;
Isn't that range a part of "reg"?
> +
> + bcsr@0,0 {
> + device_type = "board-control";
> + reg = <0 0 8000>;
> + };
> };
>
> soc8568@e0000000 {
WBR, Sergei
^ 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