* 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: [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: 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: 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: [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: [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
* [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
* 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
* 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
* 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
* [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] 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
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-15 18:33 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <4713A616.3090103@ru.mvista.com>
Hello, I wrote:
>>@@ -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...
What that means is that the off-by-one-clock drift is introduced for
classic CPUs (not 40x or Book E which interrupt at 0). And this has dealt
with months ago in the clockevent driver in the -rt patch. So much for my
efforts...
> NAK the patch.
It's too late for NAKs -- I should've given these patches more attention
(yet I was in hospital for 1.5 months).
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/5] Update ibm_newemac to use dcr_host_t.base
From: Jeff Garzik @ 2007-10-15 18:34 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <33ee227bae85a8d7ccde69a717cff47000888354.1192440801.git.michael@ellerman.id.au>
Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the
> ibm_newemac code, rather than storing it separately.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> drivers/net/ibm_newemac/mal.c | 9 +++++----
> drivers/net/ibm_newemac/mal.h | 5 ++---
> 2 files changed, 7 insertions(+), 7 deletions(-)
applied 1-5
^ permalink raw reply
* Re: [PATCH take2] [POWERPC] i2c: adds support for i2c bus on 8xx
From: Scott Wood @ 2007-10-15 18:31 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Carsten Juttner, linux-kernel, i2c, linuxppc-embedded@ozlabs.org
In-Reply-To: <47134A94.60606@scram.de>
On Mon, Oct 15, 2007 at 01:10:12PM +0200, Jochen Friedrich wrote:
> Using the port of 2.4 code from Vitaly Bordug <vitb@kernel.crashing.org>
> and the actual algorithm used by the i2c driver of the DBox code on
> cvs.tuxboc.org from Tmbinc, Gillem (htoa@gmx.net). Renamed
> i2c-algo-8xx.c to i2c-algo-cpm.c and i2c-rpx.c to i2c-8xx.c. Added
> original i2c-rpx.c as i2c-8xx-ppc.c for pre-OF (arch ppc) devices.
Do we really need to be adding features for arch/ppc at this point? It'll
be going away in June. arch/ppc-specific things outside of arch/ppc itself
will also be more likely to be missed in the removal.
Also, please post inline rather than as an attachment; attachments are
harder to quote in a reply.
> diff --git a/arch/powerpc/boot/dts/mpc885ads.dts b/arch/powerpc/boot/dts/mpc885ads.dts
> index 8848e63..a526c02 100644
> --- a/arch/powerpc/boot/dts/mpc885ads.dts
> +++ b/arch/powerpc/boot/dts/mpc885ads.dts
> @@ -213,6 +213,15 @@
> fsl,cpm-command = <0080>;
> linux,network-index = <2>;
> };
> +
> + i2c@860 {
> + device_type = "i2c";
No device_type.
> + compatible = "fsl-i2c-cpm";
Should be fsl,cpm-i2c. Is cpm2 i2c the same? If not, it should be
fsl,cpm1-i2c. It's probably best to specify it anyway, along with
fsl,mpc885-i2c.
> diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> index 2cf1b6a..350018b 100644
> --- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> @@ -175,6 +175,12 @@ static void __init init_ioports(void)
>
> /* Set FEC1 and FEC2 to MII mode */
> clrbits32(&mpc8xx_immr->im_cpm.cp_cptr, 0x00000180);
> +
> +#ifdef CONFIG_I2C_8XX
> + setbits32(&mpc8xx_immr->im_cpm.cp_pbpar, 0x00000030);
> + setbits32(&mpc8xx_immr->im_cpm.cp_pbdir, 0x00000030);
> + setbits16(&mpc8xx_immr->im_cpm.cp_pbodr, 0x0030);
> +#endif
Please add this to mpc885ads_pins, rather than poking the registers
directly. The relevant lines are:
{CPM_PORTB, 26, CPM_PIN_OUTPUT},
{CPM_PORTB, 27, CPM_PIN_OUTPUT},
> +static const char *i2c_regs = "regs";
> +static const char *i2c_pram = "pram";
> +static const char *i2c_irq = "interrupt";
> +
> +static int __init fsl_i2c_cpm_of_init(void)
> +{
> + struct device_node *np;
> + unsigned int i;
> + struct platform_device *i2c_dev;
> + int ret;
> +
> + for (np = NULL, i = 0;
> + (np = of_find_compatible_node(np, "i2c", "fsl-i2c-cpm")) != NULL;
> + i++) {
Why not just make an of_platform device instead of this glue code?
> diff --git a/drivers/i2c/algos/Kconfig b/drivers/i2c/algos/Kconfig
> index 014dfa5..7a8200e 100644
> --- a/drivers/i2c/algos/Kconfig
> +++ b/drivers/i2c/algos/Kconfig
> @@ -14,6 +14,18 @@ config I2C_ALGOBIT
> This support is also available as a module. If so, the module
> will be called i2c-algo-bit.
>
> +config I2C_ALGOCPM
> + tristate "I2C MPC8xx CPM and MPC8260 CPM2 interfaces"
> + depends on ( 8xx || 8260 ) && I2C
> + help
> + CPM I2C Algorithm, supports the CPM I2C interface for mpc8xx
> + and mpc8260 CPUs. Say Y if you own a CPU of this class
What if I'm just borrowing it? :-)
> +static irqreturn_t cpm_iic_interrupt(int irq, void *dev_id)
> +{
> + struct i2c_adapter *adap;
> + struct i2c_algo_cpm_data *cpm;
> + i2c8xx_t *i2c;
> + int i;
> +
> + adap = (struct i2c_adapter *) dev_id;
> + cpm = adap->algo_data;
> + i2c = cpm->i2c;
> +
> + /* Clear interrupt.
> + */
> + i = in_8(&i2c->i2c_i2cer);
> + out_8(&i2c->i2c_i2cer, i);
> +
> + if (cpm_debug)
> + dev_dbg(&adap->dev, "Interrupt: %x\n", i);
> +
> + /* Get 'me going again.
> + */
> + wake_up_interruptible(&cpm->iic_wait);
> +
> + return IRQ_HANDLED;
> +}
Should only return IRQ_HANDLED if the event register was non-zero.
> +static int cpm_iic_init(struct i2c_adapter *adap)
> +{
> + struct i2c_algo_cpm_data *cpm = adap->algo_data;
> + iic_t *iip = cpm->iip;
> + i2c8xx_t *i2c = cpm->i2c;
> + unsigned char brg;
> + int ret, i;
> +
> + if (cpm_debug)
> + dev_dbg(&adap->dev, "cpm_iic_init()\n");
Can you fold the if statement into a macro? Or just do a raw dev_dbg with
no test, like most drivers do.
> + ret = 0;
> + init_waitqueue_head(&cpm->iic_wait);
> + mutex_init(&cpm->iic_mutex);
> + /* Initialize the parameter ram.
> + * We need to make sure many things are initialized to zero,
> + * especially in the case of a microcode patch.
> + */
> + out_be32(&iip->iic_rstate, 0);
> + out_be32(&iip->iic_rdp, 0);
> + out_be16(&iip->iic_rbptr, 0);
> + out_be16(&iip->iic_rbc, 0);
> + out_be32(&iip->iic_rxtmp, 0);
> + out_be32(&iip->iic_tstate, 0);
> + out_be32(&iip->iic_tdp, 0);
> + out_be16(&iip->iic_tbptr, 0);
> + out_be16(&iip->iic_tbc, 0);
> + out_be32(&iip->iic_txtmp, 0);
This appears to be done twice, here and in cpm_reset_iic_params.
> + u16 v = mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_INIT_TRX) | CPM_CR_FLG;
Should use fsl,cpm-command rather than hardcoded constants.
> + /* Select an arbitrary address. Just make sure it is unique.
> + */
> + out_8(&i2c->i2c_i2add, 0xfe);
It's a 7-bit address... and are you sure that 0x7e is unique? Does this
driver even support slave operation?
> + /* Make clock run at 60 kHz.
> + */
> + /* brg = ppc_proc_freq / (32 * 2 * 60000) - 3; */
> + brg = 7;
> + out_8(&i2c->i2c_i2brg, brg);
Why is this hardcoded?
> + out_8(&i2c->i2c_i2mod, 0x00);
> + out_8(&i2c->i2c_i2com, 0x01); /* Master mode */
> +
> + /* Disable interrupts.
> + */
> + out_8(&i2c->i2c_i2cmr, 0);
> + out_8(&i2c->i2c_i2cer, 0xff);
> +
> + /* Allocate TX and RX buffers */
> + for (i = 0; i < CPM_MAXBD; i++) {
> + cpm->rxbuf[i] = (unsigned char *)dma_alloc_coherent(
> + NULL, CPM_MAX_READ + 1, &cpm->rxdma[i], GFP_KERNEL);
> + if (!cpm->rxbuf[i]) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + cpm->txbuf[i] = (unsigned char *)dma_alloc_coherent(
> + NULL, CPM_MAX_READ + 1, &cpm->txdma[i], GFP_KERNEL);
> + if (!cpm->txbuf[i]) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + }
> +
> + /* Install interrupt handler.
> + */
> + if (request_irq(cpm->irq, cpm_iic_interrupt, 0, "8xx_i2c", adap)) {
cpm-i2c, not 8xx.
> + ret = -EIO;
> + goto out;
> + }
> +
> + return 0;
> +out:
> + for (i = 0; i < CPM_MAXBD; i++) {
> + if (cpm->rxbuf[i]) dma_free_coherent(NULL, CPM_MAX_READ + 1,
> + cpm->rxbuf[i], cpm->rxdma[i]);
> + if (cpm->txbuf[i]) dma_free_coherent(NULL, CPM_MAX_READ + 1,
> + cpm->txbuf[i], cpm->txdma[i]);
> + }
Please put a newline between the if test and the if body.
> +static void force_close(struct i2c_adapter *adap)
> +{
> + struct i2c_algo_cpm_data *cpm = adap->algo_data;
> + i2c8xx_t *i2c = cpm->i2c;
> + if (cpm->reloc == 0) { /* micro code disabled */
> + cpm8xx_t *cp = cpm->cp;
> + u16 v =
> + mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_CLOSE_RXBD) | CPM_CR_FLG;
Why only if there's no microcode relocation?
> +static void cpm_parse_message(struct i2c_adapter *adap, struct i2c_msg *pmsg,
> + int num, int tx, int rx)
> +{
> + cbd_t *tbdf, *rbdf;
> + u_char addr;
> + u_char *tb;
> + u_char *rb;
> + struct i2c_algo_cpm_data *cpm = adap->algo_data;
> + iic_t *iip = cpm->iip;
> + int i, dscan;
> +
> + tbdf = (cbd_t *) cpm_dpram_addr(in_be16(&iip->iic_tbase));
> + rbdf = (cbd_t *) cpm_dpram_addr(in_be16(&iip->iic_rbase));
> +
> + /* This chip can't do zero lenth writes. However, the i2c core uses
s/lenth/length/
> + if (pmsg->flags & I2C_M_RD) {
> + if (cpm_debug)
> + dev_dbg(&adap->dev, "rx sc %04x, rx sc %04x\n",
> + tbdf[tx].cbd_sc, rbdf[rx].cbd_sc);
> + if (tbdf[tx].cbd_sc & BD_SC_NAK) {
> + if (cpm_debug)
> + dev_dbg(&adap->dev, "IIC read; no ack\n");
> + if (pmsg->flags & I2C_M_IGNORE_NAK)
> + return 0;
> + else
> + return -EREMOTEIO;
s/EREMOTEIO/EIO/
> +static int cpm_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +{
> + struct i2c_algo_cpm_data *cpm = adap->algo_data;
> + i2c8xx_t *i2c = cpm->i2c;
> + iic_t *iip = cpm->iip;
> + struct i2c_msg *pmsg, *rmsg;
> + int ret, i;
> + int tptr;
> + int rptr;
> + cbd_t *tbdf, *rbdf;
> +
> + if (num > CPM_MAXBD)
> + return -EREMOTEIO;
> +
> + /* Check if we have any oversized READ requests */
> + for (i = 0; i < num; i++) {
> + pmsg = &msgs[i];
> + if (pmsg->len >= CPM_MAX_READ)
> + return -EREMOTEIO;
> + }
s/EREMOTEIO/EINVAL/
> +
> + mutex_lock(&cpm->iic_mutex);
> +
> + /* check for and use a microcode relocation patch */
> + if (cpm->reloc)
> + cpm_reset_iic_params(cpm);
On every transfer?
> + while (tptr < num) {
> + /* Check for outstanding messages */
> + dev_dbg(&adap->dev, "test ready.\n");
> + if (!(tbdf[tptr].cbd_sc & BD_SC_READY)) {
> + dev_dbg(&adap->dev, "ready.\n");
> + rmsg = &msgs[tptr];
> + ret = cpm_check_message(adap, rmsg, tptr, rptr);
> + tptr++;
> + if (rmsg->flags & I2C_M_RD)
> + rptr++;
> + if (ret) {
> + force_close(adap);
> + mutex_unlock(&cpm->iic_mutex);
> + return -EREMOTEIO;
s/-EREMOTEIO/ret/
> +config I2C_8XX
> + tristate "MPC8xx CPM with Open Firmware"
It's not really Open Firmware... just a flat device tree.
> diff --git a/drivers/i2c/busses/i2c-8xx.c b/drivers/i2c/busses/i2c-8xx.c
> new file mode 100644
> index 0000000..c38b52e
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-8xx.c
> @@ -0,0 +1,170 @@
> +/*
> + * Embedded Planet RPX Lite MPC8xx CPM I2C interface.
> + * Copyright (c) 1999 Dan Malek (dmalek@jlc.net).
> + *
> + * moved into proper i2c interface;
> + * Brad Parker (brad@heeltoe.com)
> + *
> + * (C) 2007 Montavista Software, Inc.
> + * Vitaly Bordug <vitb@kernel.crashing.org>
> + *
> + * RPX lite specific parts of the i2c interface
> + * Update: There actually isn't anything RPXLite-specific about this module.
> + * This should work for most any 8xx board. The console messages have been
> + * changed to eliminate RPXLite references.
So let's change the title at the top of the file...
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/stddef.h>
> +#include <linux/platform_device.h>
> +#include <linux/i2c.h>
> +#include <linux/i2c-algo-cpm.h>
> +#include <linux/of_device.h>
Why are you including platform_device, and running glue code in fsl_soc.c,
if this is an of_platform driver?
> +#include <linux/of_platform.h>
> +#include <asm/mpc8xx.h>
> +#include <asm/commproc.h>
> +#include <asm/fs_pd.h>
> +
> +
> +struct m8xx_i2c {
> + char *base;
> + struct of_device *ofdev;
> + struct i2c_adapter adap;
> + struct i2c_algo_cpm_data *algo_8xx;
> +};
> +
> +static struct i2c_algo_cpm_data m8xx_data;
> +
> +static const struct i2c_adapter m8xx_ops = {
> + .owner = THIS_MODULE,
> + .name = "i2c-8xx",
> + .id = I2C_HW_MPC8XX_EPON,
> + .algo_data = &m8xx_data,
> + .dev.parent = &platform_bus,
> + .class = I2C_CLASS_HWMON,
> +};
It's not on the platform bus; it's on the soc of_platform bus. Why is this
embedded in the i2c_adapter struct anyway? i2c_adapter should hold a
pointer to whatever the probe function gives you.
> + data->irq = irq_of_parse_and_map(np, 0);
> + if (data->irq < 0)
> + return -EINVAL;
> +
> + if (of_address_to_resource(np, 1, &r))
> + return -EINVAL;
> +
> + data->iip = ioremap(r.start, r.end - r.start + 1);
> + if (data->iip == NULL)
> + return -EINVAL;
> +
> + /* Check for and use a microcode relocation patch.
> + */
> + data->reloc = data->iip->iic_rpbase;
> + if (data->reloc)
> + data->iip = (iic_t *)&cp->cp_dpmem[data->iip->iic_rpbase];
> +
> + if (of_address_to_resource(np, 0, &r))
> + return -EINVAL;
> +
> + data->i2c = ioremap(r.start, r.end - r.start + 1);
Use of_iomap.
> + if (data->i2c == NULL)
> + return -EINVAL;
> +
> + /* Allocate space for two transmit and two receive buffer
> + * descriptors in the DP ram.
> + */
> + data->dp_addr = cpm_dpalloc(sizeof(cbd_t) * 4, 8);
Please use the new muram_dpalloc name.
> + if (!data->dp_addr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +static int i2c_8xx_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + int result;
> + struct m8xx_i2c *i2c;
> +
> + i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
> + if (!i2c)
> + return -ENOMEM;
> +
> + i2c->ofdev = ofdev;
> + i2c->algo_8xx = &m8xx_data;
> +
> + m8xx_iic_init(i2c);
> +
> + dev_set_drvdata(&ofdev->dev, i2c);
> +
> + i2c->adap = m8xx_ops;
> + i2c_set_adapdata(&i2c->adap, i2c);
> + i2c->adap.dev.parent = &ofdev->dev;
> +
> + result = i2c_cpm_add_bus(&i2c->adap);
> + if (result < 0) {
> + printk(KERN_ERR "i2c-8xx: Unable to register with I2C\n");
> + kfree(i2c);
> + }
> +
> + return result;
> +}
> +
> +static int i2c_8xx_remove(struct of_device *ofdev)
> +{
> + struct m8xx_i2c *i2c = dev_get_drvdata(&ofdev->dev);
> +
> + i2c_cpm_del_bus(&i2c->adap);
> + dev_set_drvdata(&ofdev->dev, NULL);
> +
> + kfree(i2c);
> + return 0;
> +}
> +
> +static struct of_device_id i2c_8xx_match[] = {
> + {
> + .type = "i2c",
> + .compatible = "fsl,i2c-cpm",
> + },
> + {},
> +};
> +
Why is an 8xx driver matching all i2c cpm (i.e. what about cpm2)?
-Scot
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-15 18:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <12696686.post@talk.nabble.com>
Hello
I'm also working with ML403 board from Xilinx and have the same problem as
you. The boot process stops after decompressing with the message "Now
booting the kernel". We also used gcc-4.1.0 for the cross compilation. So, I
would be glad to know, which gcc version have you used to get a working
kernel!
Thanks,
Andreas
Junqiang Hu wrote:
>
>
> Hi Grant,
>
> Thank you so much for the reply! Fortunately I got it work now -- it's
> the crosstool compiler problem. Originally I was using gcc-4.1.0, yet
> when compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will
> miscompile the kernel, so I changed to another version, and now I can let
> it go!
>
> Right now still not fully booted because of the SystemACE problem, or
> maybe the partition is not correct. I'm still working on it, hopefully to
> get it solved soon :-)
>
> Thanks,
> -J.
>
>
> Grant Likely-2 wrote:
>>
>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>
>>>
>>> Dear friends,
>>>
>>> I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>> board. The Linux version I'm using is 2.4; the cross-compiler is
>>> gcc-4.1.0, glibc 2.3.6. When booting the kernel, it shows:
>>> loaded at: 00400000 004B51E4
>>> board data at: 00000000 00000018
>>> relocated to: 0040526C 00405284
>>> zimage at: 00405B2B 004B177C
>>> avail ram: 004B6000 60000000
>>
>> I strongly recommend moving to a 2.6 kernel. Recent mainline has
>> support for the Xilinx ppc built in.
>>>
>>> Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3
>>> rw
>>> Uncompressing Linux...done.
>>> Now booting the kernel
>>>
>>> Then it hangs. First it seems to me that the "avail ram" is not correct,
>>> since I configured only 32MB SDRAM. Moreover, if it's first powered on,
>>> the
>>> end address of "avail ram" would be FFD9FBED. Then I tried to
>>> investigate
>>> the problem using xmd. When launched, it says:
>>
>> (If you're using u-boot) You might have a mismatch between the board
>> info structure used by u-boot and the one used by Linux.
>>
>> Also, you should use your debugger to inspect the __log_buf memory of
>> the kernel. A common problem is the kernel starts booting, but the
>> console is setup incorrectly and so you see nothing. But, you can
>> read the console output directly from memory if you look at the
>> __log_buf region (find the address in the System.map file; you might
>> need to subtract 0xC0000000 from the address to view the memory)
>>
>> Cheers,
>> g.
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>> grant.likely@secretlab.ca
>> (403) 399-0195
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13219154
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Scott Wood @ 2007-10-15 18:47 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071015155730.GA30008@localhost.localdomain>
On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
> > Is the entity described as "localbus" indeed so *board* specific?
>
> That's what booting-without-of.txt gives as an example.
The board should have been left out of that. Your compatible should be
something like "fsl,mpc8568-localbus", possibly with some canonical mpc85xx
chip as well, chosen to represent 85xx localbus in general.
-Scott
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-15 18:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <4713B10B.5000607@garzik.org>
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> 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...
Who else is sending you patches? Valentine is the only one I've seen
send patches recently...
josh
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] ucc_geth: Fix build break introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
From: Jeff Garzik @ 2007-10-15 18:51 UTC (permalink / raw)
To: Emil Medve; +Cc: netdev, akpm, leoli, linuxppc-dev
In-Reply-To: <1192455830-1028-1-git-send-email-Emilian.Medve@Freescale.com>
Emil Medve wrote:
> drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
> drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this function)
> drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported only once
> drivers/net/ucc_geth.c:3483: error: for each function it appears in.)
> make[2]: *** [drivers/net/ucc_geth.o] Error 1
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
>
> Here is a convenient link for the culprit patch: http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commit;h=09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
>
> netdev-2.6> scripts/checkpatch.pl 0001-POWERPC-ucc_geth-Fix-build-break-introduced-by-co.patch
> Your patch has no obvious style problems and is ready for submission.
applied
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 18:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071015134813.6aacdcca@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:27:23 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
>> 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...
>
> Who else is sending you patches? Valentine is the only one I've seen
> send patches recently...
It's a zoo :)
Al Viro (3):
typo in ibm_newemac/rgmii.c
skb->tail in ibm_newemac should be skb_tail_pointer()
ibm_newemac annotations (iomem, NULL noise)
David Gibson (1):
Device tree aware EMAC driver
Michael Ellerman (3):
Update ibm_newemac to use dcr_host_t.base
Add dcr_host_t.base in dcr_read()/dcr_write()
Use dcr_host_t.base in dcr_unmap()
Roland Dreier (2):
ibm_new_emac: Nuke SET_MODULE_OWNER() use
ibm_emac: Convert to use napi_struct independent of struct net_device
vbarshak@ru.mvista.com (1):
Fix typo in new EMAC driver.
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-15 18:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <4713B726.6080404@garzik.org>
On Mon, 15 Oct 2007 14:53:26 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> >> 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...
> >
> > Who else is sending you patches? Valentine is the only one I've seen
> > send patches recently...
>
> It's a zoo :)
Wow, indeed.
> Al Viro (3):
> typo in ibm_newemac/rgmii.c
Val sent this as well. Either one works.
> skb->tail in ibm_newemac should be skb_tail_pointer()
> ibm_newemac annotations (iomem, NULL noise)
Ack on those.
> David Gibson (1):
> Device tree aware EMAC driver
That's the initial commit :)
> Michael Ellerman (3):
> Update ibm_newemac to use dcr_host_t.base
> Add dcr_host_t.base in dcr_read()/dcr_write()
> Use dcr_host_t.base in dcr_unmap()
Missed those, but I see you applied them which is good.
> Roland Dreier (2):
> ibm_new_emac: Nuke SET_MODULE_OWNER() use
> ibm_emac: Convert to use napi_struct independent of struct net_device
I never saw either of these. I'm also beginning to wonder if one of
them broke things because I can't currently get ibm_newemac to work.
> vbarshak@ru.mvista.com (1):
> Fix typo in new EMAC driver.
Same fix as Al's.
Anyway, we can queue patches to this through me if you'd like.
josh
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Scott Wood @ 2007-10-15 18:53 UTC (permalink / raw)
To: Grant Likely; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <fa686aa40710150957s74693835g257b376adfdb4e90@mail.gmail.com>
On Mon, Oct 15, 2007 at 10:57:48AM -0600, Grant Likely wrote:
> 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";
> };
I think this is overly complicated; something like linux,i2c-index in the
i2c adapter node would be simpler.
Though, I don't see what the problem with the original approach is, as long
as the numbers are chosen in the same way when registering i2c clients based
on the children of the adapter node. There's no concept in the hardware
itself of a bus number.
-Scott
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 19:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071015135959.5b603d7d@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:53:26 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>>>> 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...
>>> Who else is sending you patches? Valentine is the only one I've seen
>>> send patches recently...
>> It's a zoo :)
>
> Wow, indeed.
>
>> Al Viro (3):
>> typo in ibm_newemac/rgmii.c
>
> Val sent this as well. Either one works.
>
>> skb->tail in ibm_newemac should be skb_tail_pointer()
>> ibm_newemac annotations (iomem, NULL noise)
>
> Ack on those.
>
>> David Gibson (1):
>> Device tree aware EMAC driver
>
> That's the initial commit :)
>
>> Michael Ellerman (3):
>> Update ibm_newemac to use dcr_host_t.base
>> Add dcr_host_t.base in dcr_read()/dcr_write()
>> Use dcr_host_t.base in dcr_unmap()
>
> Missed those, but I see you applied them which is good.
>
>> Roland Dreier (2):
>> ibm_new_emac: Nuke SET_MODULE_OWNER() use
>> ibm_emac: Convert to use napi_struct independent of struct net_device
>
> I never saw either of these. I'm also beginning to wonder if one of
> them broke things because I can't currently get ibm_newemac to work.
>
>> vbarshak@ru.mvista.com (1):
>> Fix typo in new EMAC driver.
>
> Same fix as Al's.
All those are what's upstream, except for the Michael Ellerman patches.
FWIW it was generated using
git log drivers/net/ibm_newemac | git shortlog
> Anyway, we can queue patches to this through me if you'd like.
I would ideally like a single active patch generator (even if they are
merely reviewed others work sometimes).
Outside of that, I'm hoping you and the other people listed making
changes will self-organize without my help :)
Jeff
^ permalink raw reply
* Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
From: Jeff Garzik @ 2007-10-15 19:06 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071014075511.GC3000@nd47.coderock.org>
Domen Puncer wrote:
> Hello!
>
> If there are no objections, I would like to get this merged
> when bestcomm goes in (any time now?).
>
> It's split into four parts:
> 1 - device tree
> 2 - small bestcomm change
> 3 - the actual driver
> 4 - phy part of the driver
patches #3 and #4 need to be combined together.
Are the arch people OK with patches #1 and #2?
Jeff
^ permalink raw reply
* Re: [PATCH 1/2] [RFC][POWERPC] MPC8568E-MDS: create localbus node
From: Kumar Gala @ 2007-10-15 19:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071015184743.GA4474@loki.buserror.net>
On Oct 15, 2007, at 1:47 PM, Scott Wood wrote:
> On Mon, Oct 15, 2007 at 07:57:30PM +0400, Anton Vorontsov wrote:
>> On Mon, Oct 15, 2007 at 07:42:12PM +0400, Sergei Shtylyov wrote:
>>> Is the entity described as "localbus" indeed so *board* specific?
>>
>> That's what booting-without-of.txt gives as an example.
>
> The board should have been left out of that. Your compatible
> should be
> something like "fsl,mpc8568-localbus", possibly with some canonical
> mpc85xx
> chip as well, chosen to represent 85xx localbus in general.
Lets be careful, there are at least two forms of localbus on 85xx.
- k
^ 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