* A FEC problem on fsl_mpc5121e_ads board.
From: Andrew Liu @ 2007-09-30 3:49 UTC (permalink / raw)
To: jrigby, linuxppc-embedded
Hello All,
When I boot from NFS, it doesn't work, so I boot system from NOR flash.
I found FEC hasn't produced any interrupts ( of course, I have plugged
in cable, and make sure the cable works on other boards, what's more, I
can see FEC light blinks)
when system boot up:
-sh-2.05b# cat /proc/interrupts
CPU0
16: 0 IPIC Level fs_enet-mac
17: 36 IPIC Level i2c-mpc
18: 1 IPIC Level i2c-mpc
19: 1 IPIC Level i2c-mpc
40: 1117 IPIC Level mpc512x_psc_uart
BAD: 0
-sh-2.05b# ethtool eth0
Settings for eth0:
Supported ports: [ TP AUI BNC MII FIBRE ]
Supported link modes:
Supports auto-negotiation: No
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Current message level: 0x00000000 (0)
* Link detected: n*
it seems very strange that link detected is no, I have tried the kernel
uImage from Freescale ISO, the thing is same to above.
The part of DTS as bellow:
mdio@2840 {
device_type = "mdio";
compatible = "fs_nocpm_enet";
reg = <2840 4>;
#address-cells = <1>;
#size-cells = <0>;
phy: ethernet-phy@0 {
// interrupt-parent = < &cpld_pic >;
// interrupts = <b 8>;
reg = <1>;
device_type = "ethernet-phy";
};
};
ethernet@2800 {
device_type = "network";
model = "FEC";
compatible = "fs_nocpm_enet";
device-id = <1>;
reg = <2800 800>;
address = [ 00 E0 0C BC E5 40 ];
local-mac-address = [ 00 E0 0C BC E5 40 ];
interrupts = <4 8 >;
interrupt-parent = < &ipic >;
// NOTE: for 7-wire, remove phy-handle
// and add seven-wire
phy-handle = < &phy >;
//seven-wire;
};
when boot from NFS, some information as belows:
011400.serial: ttyPSC1 at MMIO 0x80011400 (irq = 40) is a MPC52xx PSC
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: module loaded
*fs_enet.c:v1.0 (Aug 8, 2005)
FEC MII Bus: probed
...............................
*Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17*
IP-Config: Complete:
device=eth0, addr=128.224.162.57, mask=255.255.254.0,
gw=128.224.162.1,
host=mpc5121e_ads, domain=, nis-domain=(none),
bootserver=128.224.162.142, rootserver=128.224.162.142, rootpath=
*md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.*
Looking up port of RPC 100003/2 on 128.224.162.142
rpcbind: server 128.224.162.142 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 128.224.162.142
rpcbind: server 128.224.162.142 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 128.224.162.142 not responding, timed out
Root-NFS: Server returned error -5 while mounting
Who can give me some advice ?
Thanks in adance.
BRs,
Andrew
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Benjamin Herrenschmidt @ 2007-09-29 22:49 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200709300026.07219.mb@bu3sch.de>
On Sun, 2007-09-30 at 00:26 +0200, Michael Buesch wrote:
> On Sunday 30 September 2007 00:19:53 Benjamin Herrenschmidt wrote:
> >
> > >
> > > This all smells to me like a silicon bug, so I'd start searching
> > > in the silicon erratas. But I'm not sure, of course. It's also strange
> > > that it depends on temperature. (That's why I first expected the PMU
> > > would cause this).
> > >
> > > Thanks for your help.
> >
> > Could be that we are creating a short by driving the output low, thus
> > causing the silicon to heat up, but that's strange.
>
> Well. The machine needs to be hot in the first place to trigger it.
> If it's cold it boots and runs fine even with that patch.
> Even if I run it hot after boot it does not shutdown. It only shuts down
> on boot when this register is written and when it's hot at this point.
Well, it's possible that they have a too weak pull-up resistor on those
lines, and thus when asserted to 0, a significant current goes through
causing the whole thing to heat up. That heat added to the residual heat
of a hot boot becomes then enough to trigger the temperature sensor
threshold... just one possible explanation.
> That's why I thought about some silicon bug. Why only when it's hot? :)
>
> > Also, the other change I made you do turns these into inputs, thus the
>
> The _EN bits are already all cleared, as you can see in my printk dump.
> So clearing them has no effect, of course.
> So the ports are Inputs as default on boot.
Hrm, that's weird then, because in that case, changing the output bits
shouldn't have any effect, unless maybe on some chips, the EN bits are
flipped. I don't have anything specific about the rv350 tho.
Can you print which specific DDC register is doing that (it's called
twice right ?) and maybe do a patch preventing that write only for one
of them and let me know if it makes a difference.
> > DDL lines should be pulled up, unless ... the board doesn't have
> > pullups.
>
> Well, I can't tell you :)
Heh
Ben.
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Michael Buesch @ 2007-09-29 22:26 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191104393.28637.5.camel@pasglop>
On Sunday 30 September 2007 00:19:53 Benjamin Herrenschmidt wrote:
>
> >
> > This all smells to me like a silicon bug, so I'd start searching
> > in the silicon erratas. But I'm not sure, of course. It's also strange
> > that it depends on temperature. (That's why I first expected the PMU
> > would cause this).
> >
> > Thanks for your help.
>
> Could be that we are creating a short by driving the output low, thus
> causing the silicon to heat up, but that's strange.
Well. The machine needs to be hot in the first place to trigger it.
If it's cold it boots and runs fine even with that patch.
Even if I run it hot after boot it does not shutdown. It only shuts down
on boot when this register is written and when it's hot at this point.
That's why I thought about some silicon bug. Why only when it's hot? :)
> Also, the other change I made you do turns these into inputs, thus the
The _EN bits are already all cleared, as you can see in my printk dump.
So clearing them has no effect, of course.
So the ports are Inputs as default on boot.
> DDL lines should be pulled up, unless ... the board doesn't have
> pullups.
Well, I can't tell you :)
--
Greetings Michael.
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Benjamin Herrenschmidt @ 2007-09-29 22:19 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200709292353.06476.mb@bu3sch.de>
>
> This all smells to me like a silicon bug, so I'd start searching
> in the silicon erratas. But I'm not sure, of course. It's also strange
> that it depends on temperature. (That's why I first expected the PMU
> would cause this).
>
> Thanks for your help.
Could be that we are creating a short by driving the output low, thus
causing the silicon to heat up, but that's strange.
Also, the other change I made you do turns these into inputs, thus the
DDL lines should be pulled up, unless ... the board doesn't have
pullups.
Ben.
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Michael Buesch @ 2007-09-29 21:53 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191102715.28637.0.camel@pasglop>
On Saturday 29 September 2007 23:51:55 Benjamin Herrenschmidt wrote:
>
> On Sat, 2007-09-29 at 13:22 +0200, Michael Buesch wrote:
> > On Saturday 29 September 2007 13:06:59 Michael Buesch wrote:
> > > > This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
> > > > VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?
> > >
> > > It still triggers the bug then.
> >
> > I tried something else.
> > I removed the write and only added a printk with a register read
> > to print the contents (DDC REG IS 0x...) . This is the result:
> >
> > [ 0.431304] PCI: Enabling device 0000:00:10.0 (0006 -> 0007)
> > [ 0.626866] radeonfb (0000:00:10.0): Invalid ROM signature 303 should be 0xaa55
> > [ 0.626877] radeonfb: Retrieved PLL infos from Open Firmware
> > [ 0.626887] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz
> > [ 0.626897] radeonfb: PLL min 12000 max 35000
> > [ 0.627194] DDC REG IS 0x00000303
> > [ 0.763751] i2c-adapter i2c-2: unable to read EDID block.
> > [ 0.983746] i2c-adapter i2c-2: unable to read EDID block.
> > [ 1.203745] i2c-adapter i2c-2: unable to read EDID block.
> > [ 1.280001] DDC REG IS 0x00000000
> > [ 1.620189] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036]
> > [ 1.670984] radeonfb: Monitor 1 type LCD found
> > [ 1.670992] radeonfb: EDID probed
> > [ 1.670997] radeonfb: Monitor 2 type no found
> > [ 1.671012] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0
> > [ 1.671075] radeonfb: Dynamic Clock Power Management enabled
> > [ 1.712658] Console: switching to colour frame buffer device 160x53
> > [ 1.735555] radeonfb: Backlight initialized (radeonbl0)
> > [ 1.735746] radeonfb (0000:00:10.0): ATI Radeon NP
> > [ 1.738776] Generic RTC Driver v1.07
> > [ 1.738995] Macintosh non-volatile memory driver v1.1
> > ...
> >
> > Note that the function is called twice. Is that correct?
>
> Yes. That's expected, with different registers though.
>
> I don't quite get what's going on. I'll have to figure that out with ATI
> if they bother helping...
This all smells to me like a silicon bug, so I'd start searching
in the silicon erratas. But I'm not sure, of course. It's also strange
that it depends on temperature. (That's why I first expected the PMU
would cause this).
Thanks for your help.
--
Greetings Michael.
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Benjamin Herrenschmidt @ 2007-09-29 21:51 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200709291322.59607.mb@bu3sch.de>
On Sat, 2007-09-29 at 13:22 +0200, Michael Buesch wrote:
> On Saturday 29 September 2007 13:06:59 Michael Buesch wrote:
> > > This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
> > > VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?
> >
> > It still triggers the bug then.
>
> I tried something else.
> I removed the write and only added a printk with a register read
> to print the contents (DDC REG IS 0x...) . This is the result:
>
> [ 0.431304] PCI: Enabling device 0000:00:10.0 (0006 -> 0007)
> [ 0.626866] radeonfb (0000:00:10.0): Invalid ROM signature 303 should be 0xaa55
> [ 0.626877] radeonfb: Retrieved PLL infos from Open Firmware
> [ 0.626887] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz
> [ 0.626897] radeonfb: PLL min 12000 max 35000
> [ 0.627194] DDC REG IS 0x00000303
> [ 0.763751] i2c-adapter i2c-2: unable to read EDID block.
> [ 0.983746] i2c-adapter i2c-2: unable to read EDID block.
> [ 1.203745] i2c-adapter i2c-2: unable to read EDID block.
> [ 1.280001] DDC REG IS 0x00000000
> [ 1.620189] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036]
> [ 1.670984] radeonfb: Monitor 1 type LCD found
> [ 1.670992] radeonfb: EDID probed
> [ 1.670997] radeonfb: Monitor 2 type no found
> [ 1.671012] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0
> [ 1.671075] radeonfb: Dynamic Clock Power Management enabled
> [ 1.712658] Console: switching to colour frame buffer device 160x53
> [ 1.735555] radeonfb: Backlight initialized (radeonbl0)
> [ 1.735746] radeonfb (0000:00:10.0): ATI Radeon NP
> [ 1.738776] Generic RTC Driver v1.07
> [ 1.738995] Macintosh non-volatile memory driver v1.1
> ...
>
> Note that the function is called twice. Is that correct?
Yes. That's expected, with different registers though.
I don't quite get what's going on. I'll have to figure that out with ATI
if they bother helping...
Ben.
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Kumar Gala @ 2007-09-29 14:34 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <20070929104917.1585737e@kernel.crashing.org>
On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote:
> Hello Kumar,
>
> On Fri, 28 Sep 2007 18:53:38 -0500
> Kumar Gala wrote:
>
>>
>> On Sep 28, 2007, at 3:30 PM, Vitaly Bordug wrote:
>>
>>> Kumar,
>>>
>>> Realizing this may suffer a bit from cleanest-dts flame war, but
>>> anyway I pretty much see a lot of
>>> sense in getting this in during next merge window. Is this possible?
>>
>> Probably, does QE have muram? I can't keep these things straight.
>>
>
> cpms have dpram, qe has muram. these two are the same stuff in
> fact. Or you are asking about have QE stuff utilize such a binding
> at the same pass?
I was asking about both these things.
- k
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Michael Buesch @ 2007-09-29 11:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200709291306.59627.mb@bu3sch.de>
On Saturday 29 September 2007 13:06:59 Michael Buesch wrote:
> > This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
> > VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?
>
> It still triggers the bug then.
I tried something else.
I removed the write and only added a printk with a register read
to print the contents (DDC REG IS 0x...) . This is the result:
[ 0.431304] PCI: Enabling device 0000:00:10.0 (0006 -> 0007)
[ 0.626866] radeonfb (0000:00:10.0): Invalid ROM signature 303 should be 0xaa55
[ 0.626877] radeonfb: Retrieved PLL infos from Open Firmware
[ 0.626887] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=203.00 Mhz, System=392.00 MHz
[ 0.626897] radeonfb: PLL min 12000 max 35000
[ 0.627194] DDC REG IS 0x00000303
[ 0.763751] i2c-adapter i2c-2: unable to read EDID block.
[ 0.983746] i2c-adapter i2c-2: unable to read EDID block.
[ 1.203745] i2c-adapter i2c-2: unable to read EDID block.
[ 1.280001] DDC REG IS 0x00000000
[ 1.620189] ieee1394: Host added: ID:BUS[0-00:1023] GUID[001124fffed98036]
[ 1.670984] radeonfb: Monitor 1 type LCD found
[ 1.670992] radeonfb: EDID probed
[ 1.670997] radeonfb: Monitor 2 type no found
[ 1.671012] radeonfb: Using Firmware dividers 0x0002008e from PPLL 0
[ 1.671075] radeonfb: Dynamic Clock Power Management enabled
[ 1.712658] Console: switching to colour frame buffer device 160x53
[ 1.735555] radeonfb: Backlight initialized (radeonbl0)
[ 1.735746] radeonfb (0000:00:10.0): ATI Radeon NP
[ 1.738776] Generic RTC Driver v1.07
[ 1.738995] Macintosh non-volatile memory driver v1.1
...
Note that the function is called twice. Is that correct?
--
Greetings Michael.
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Michael Buesch @ 2007-09-29 11:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191020653.6158.90.camel@pasglop>
On Saturday 29 September 2007 01:04:13 Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-09-28 at 23:32 +0200, Michael Buesch wrote:
> > Hi,
> >
> > some time ago I already mailed you about this problem.
> > I will quickly describe what's going on, again:
> >
> > My powerbook boots fine when it's cold. You can work with
> > it and you can also run it hot (compile something, etc...).
> > But when you try to boot it while it is hot, it will
> > automatically shutdown hard inside of the boot process.
> > Some part of the hardware is shutting it down.
> > This does not happen when it's getting hot _after_ boot.
> > Only while boot when it's hot.
> >
> > I bisected the problem and found out that the following patch
> > is responsible for this. Yeah, this sounds a little bit
> > crazy, as this patch does not seem to be related to
> > this at all. But I confirmed it by booting kernel
> > 4f71c5de19c27f2198105d3b26b398494d5c353b
> > That kernel triggered the bug. Then I patch -R the patch below
> > and it booted properly, even when hot. I also rechecked
> > that it really was hot enough to trigger the event by
> > immediately rebooting into a known bad kernel, that immediately
> > shut down the pbook, as expected.
> > So I'm pretty sure it's the patch below causing this weird
> > behaviour. Any idea why?
>
> This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
> VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?
It still triggers the bug then.
--
Greetings Michael.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Geert Uytterhoeven @ 2007-09-29 8:00 UTC (permalink / raw)
To: Geoff Levand
Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, Antonino A. Daplas
In-Reply-To: <46FD5604.3060104@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2234 bytes --]
On Fri, 28 Sep 2007, Geoff Levand wrote:
> Michael Ellerman wrote:
> > On Thu, 2007-09-27 at 10:23 -0700, Geoff Levand wrote:
> >> Michael Ellerman wrote:
> >> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> >> >> Question: As several DVI-D displays advertise they support 1080i modes while
> >> >> they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> >> >> modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> >> >> better than 1080i anyway. What do you think?
> >> >
> >> > Definitely. If the autodetection fails Linux is basically unusable on
> >> > PS3 unless you hack the kernel sources and build your own kboot and
> >> > otheros.bld - not entirely trivial for novice users. So it's pretty
> >> > important that it works 100%.
> >>
> >> It is not that bad. If a bootloader is configued to use autodetection
> >> so that it is shown at best video mode, then it should have advertised
> >> key sequences to default to known video modes, with at least a 480p 'safe'
> >> mode.
> >
> > Oh OK, that is a good idea. What's the "safe mode" key sequence for the
> > otheros.bld you provide on kernel.org?
>
> I don't maintain that, and have no idea how it sets its video mode. Did you
> have trouble with it? I know in the past it used a fixed 480p mode.
It uses the autodetect mode. In the past, the kernel defaulted to 480p for
DVI-D/HDMI displays, 480i for other displays.
So far no one complained about the new otheros.bld (AFAIK). Which doesn't mean
that (a) the problem doesn't happen and (b) it wouldn't be nice to have a `safe
mode' key sequence...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Vitaly Bordug @ 2007-09-29 6:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <08C0C9CB-C958-4B95-81B8-D0677CBA4399@kernel.crashing.org>
Hello Kumar,
On Fri, 28 Sep 2007 18:53:38 -0500
Kumar Gala wrote:
>
> On Sep 28, 2007, at 3:30 PM, Vitaly Bordug wrote:
>
> > Kumar,
> >
> > Realizing this may suffer a bit from cleanest-dts flame war, but
> > anyway I pretty much see a lot of
> > sense in getting this in during next merge window. Is this possible?
>
> Probably, does QE have muram? I can't keep these things straight.
>
cpms have dpram, qe has muram. these two are the same stuff in fact. Or you are asking about have QE stuff utilize such a binding at the same pass?
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 1/9] fs_enet: Whitespace cleanup.
From: Jeff Garzik @ 2007-09-29 5:21 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070920220116.GA28784@loki.buserror.net>
Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 85 ++++++++++++++++-------------------
> drivers/net/fs_enet/fs_enet.h | 4 +-
> drivers/net/fs_enet/mac-fcc.c | 1 -
> drivers/net/fs_enet/mii-bitbang.c | 3 -
> drivers/net/fs_enet/mii-fec.c | 1 -
> 5 files changed, 41 insertions(+), 53 deletions(-)
ACK patches 1-2, 4-9
This patch doesn't apply cleanly to netdev-2.6.git#upstream (nor
net-2.6.24.git), so this and the rest of the patch series failed to apply.
Please resend series on top of netdev-2.6.git#upstream or net-2.6.24.git.
^ permalink raw reply
* Re: [PATCH 3/9] fs_enet: Don't share the interrupt.
From: Jeff Garzik @ 2007-09-29 5:18 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070920220118.GC28784@loki.buserror.net>
Scott Wood wrote:
> This driver can't handle an interrupt immediately after request_irq
You MUST assume that you will receive an interrupt immediately after
request_irq(). If fs_enet cannot handle that, then that is what wants
fixing.
Please send along a fix for this, rather than band-aiding the problem.
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Kumar Gala @ 2007-09-28 23:53 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <20070929003005.59afc2a0@kernel.crashing.org>
On Sep 28, 2007, at 3:30 PM, Vitaly Bordug wrote:
> Kumar,
>
> Realizing this may suffer a bit from cleanest-dts flame war, but
> anyway I pretty much see a lot of
> sense in getting this in during next merge window. Is this possible?
Probably, does QE have muram? I can't keep these things straight.
- k
^ permalink raw reply
* Re: [PATCH 01/18] Virtex: Add uartlite bootwrapper driver
From: Arnd Bergmann @ 2007-09-28 23:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070928152651.2e185d15@weaponx.rchland.ibm.com>
On Friday 28 September 2007, Josh Boyer wrote:
>=20
> > Is cpu_relax even implemented in the bootwrapper?
>=20
> No. =A0And it doesn't need to be :)
I think I should learn to read subject lines. You are of course
both right.
Arnd <><
^ permalink raw reply
* Re: Powerbook shuts down hard when hot, patch found
From: Benjamin Herrenschmidt @ 2007-09-28 23:04 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200709282332.52819.mb@bu3sch.de>
On Fri, 2007-09-28 at 23:32 +0200, Michael Buesch wrote:
> Hi,
>
> some time ago I already mailed you about this problem.
> I will quickly describe what's going on, again:
>
> My powerbook boots fine when it's cold. You can work with
> it and you can also run it hot (compile something, etc...).
> But when you try to boot it while it is hot, it will
> automatically shutdown hard inside of the boot process.
> Some part of the hardware is shutting it down.
> This does not happen when it's getting hot _after_ boot.
> Only while boot when it's hot.
>
> I bisected the problem and found out that the following patch
> is responsible for this. Yeah, this sounds a little bit
> crazy, as this patch does not seem to be related to
> this at all. But I confirmed it by booting kernel
> 4f71c5de19c27f2198105d3b26b398494d5c353b
> That kernel triggered the bug. Then I patch -R the patch below
> and it booted properly, even when hot. I also rechecked
> that it really was hot enough to trigger the event by
> immediately rebooting into a known bad kernel, that immediately
> shut down the pbook, as expected.
> So I'm pretty sure it's the patch below causing this weird
> behaviour. Any idea why?
This is very strange... Can you try also clearing VGA_DDC_CLK_OUT_EN and
VGA_DDC_DATA_OUT_EN and the same time and see if that helps ?
>
> commit 4f71c5de19c27f2198105d3b26b398494d5c353b
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Fri Nov 17 15:35:00 2006 +1100
>
> [PATCH] Fix radeon DDC regression
>
> When radeonfb was changed to use the new "generic" ddc, a bit of
> code initializing the GPIO lines was lost, causing it to not work
> if the firmware didn't configure them properly, which seems to
> happen on some cards.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
>
> diff --git a/drivers/video/aty/radeon_i2c.c b/drivers/video/aty/radeon_i2c.c
> index 6767545..869725a 100644
> --- a/drivers/video/aty/radeon_i2c.c
> +++ b/drivers/video/aty/radeon_i2c.c
> @@ -139,7 +139,13 @@ void radeon_delete_i2c_busses(struct rad
> int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
> u8 **out_edid)
> {
> - u8 *edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
> + u32 reg = rinfo->i2c[conn-1].ddc_reg;
> + u8 *edid;
> +
> + OUTREG(reg, INREG(reg) &
> + ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
> +
> + edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
>
> if (out_edid)
> *out_edid = edid;
>
^ permalink raw reply
* Powerbook shuts down hard when hot, patch found
From: Michael Buesch @ 2007-09-28 21:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi,
some time ago I already mailed you about this problem.
I will quickly describe what's going on, again:
My powerbook boots fine when it's cold. You can work with
it and you can also run it hot (compile something, etc...).
But when you try to boot it while it is hot, it will
automatically shutdown hard inside of the boot process.
Some part of the hardware is shutting it down.
This does not happen when it's getting hot _after_ boot.
Only while boot when it's hot.
I bisected the problem and found out that the following patch
is responsible for this. Yeah, this sounds a little bit
crazy, as this patch does not seem to be related to
this at all. But I confirmed it by booting kernel
4f71c5de19c27f2198105d3b26b398494d5c353b
That kernel triggered the bug. Then I patch -R the patch below
and it booted properly, even when hot. I also rechecked
that it really was hot enough to trigger the event by
immediately rebooting into a known bad kernel, that immediately
shut down the pbook, as expected.
So I'm pretty sure it's the patch below causing this weird
behaviour. Any idea why?
commit 4f71c5de19c27f2198105d3b26b398494d5c353b
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri Nov 17 15:35:00 2006 +1100
[PATCH] Fix radeon DDC regression
When radeonfb was changed to use the new "generic" ddc, a bit of
code initializing the GPIO lines was lost, causing it to not work
if the firmware didn't configure them properly, which seems to
happen on some cards.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/drivers/video/aty/radeon_i2c.c b/drivers/video/aty/radeon_i2c.c
index 6767545..869725a 100644
--- a/drivers/video/aty/radeon_i2c.c
+++ b/drivers/video/aty/radeon_i2c.c
@@ -139,7 +139,13 @@ void radeon_delete_i2c_busses(struct rad
int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
u8 **out_edid)
{
- u8 *edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
+ u32 reg = rinfo->i2c[conn-1].ddc_reg;
+ u8 *edid;
+
+ OUTREG(reg, INREG(reg) &
+ ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
+
+ edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
if (out_edid)
*out_edid = edid;
--
Greetings Michael.
^ permalink raw reply related
* Re: Flash paritioning and JFFS2
From: Mirek23 @ 2007-09-28 21:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <12937526.post@talk.nabble.com>
I when through the jffs2 driver code and I have noticed that during the jffs2
initialization It is a problem to access the flash memory (of my board) in
32 bit mode. All what refers to the 32 bit access gets from Flash only 16
(Most significant) bits. The remaining 16 (less significant) bits are simply
filled with 0.
I have noticed that there are two sets of functions which are used to access
Flash memory:
#define cpu_to_je32(x) ((jint32_t){x})
#define je32_to_cpu(x) ((x).v32)
#define cpu_to_je16(x) ((jint16_t){x})
#define je16_to_cpu(x) ((x).v16)
These functions which refer to 16 bits access are working fine in my case
but those which refer to 32 access do not work properly. Does anybody have
some idea how to change those functions which deal with 32 bits to force
them to access the Flash memory in two steps to get twice 16 bits numbers
and at the end form 32 bits value?
Best Regards
Mirek
Mirek23 wrote:
>
> Dear All,
>
> Finally I have sorted out few problems with linux and u-boot and I have
> tried to come back to the jffs2 and mtd partitioning issue.
>
> I am using CFI driver and I pass partitioning information from command
> line via u-boot.
>
> This part works fine:
>
> Unfortunatly I have the problem when accesing the flash partitions because
> my Avnet evaluation board is designet in such a way that the data should
> be accessed in the mode x16 (16 bits in each goal).
>
> Linux CFI driver is able to detect the x16 mode but it does not handle it
> correctly.
>
> I will give you an example:
>
> My mtd1 partition contains the u-boot environment. When I print the mtd1
> contents with (busybox) hexdump I get:
>
> 00000000 eb 92 00 00 62 6f 00 00 61 72 00 00 3d 63 00 00
> |....bo..ar..=c..|
> 00000010 73 6f 00 00 3d 74 00 00 55 4c 00 00 39 36 00 00
> |so..=t..UL..96..|
> 00000020 20 72 00 00 74 3d 00 00 65 76 00 00 66 73 00 00 |
> r..t=..ev..fs..|
> 00000030 77 20 00 00 73 72 00 00 74 3d 00 00 39 2e 00 00 |w
> ..sr..t=..9...|
> 00000040 39 2e 00 00 34 2e 00 00 33 3a 00 00 70 74 00 00
> |9...4...3:..pt..|
> 00000050 6c 64 00 00 31 2f 00 00 63 5f 00 00 78 2c 00 00
> |ld..1/..c_..x,..|
> 00000060 70 20 00 00 70 3d 00 00 3a 3a 00 00 72 74 00 00 |p
> ..p=..::..rt..|
> 00000070 34 2d 00 00 72 65 00 00 65 74 00 00 3a 64 00 00
> |4-..re..et..:d..|
>
> When I copy the contents of the /dev/mtd1 to the file by 2 bytes (bs=2) I
> get correct
> readout:
>
> dd if=/dev/mtd1 of=./u-boot_Env.txt bs=2 count=128k
>
> hexdump ./u-boot_Env.txt
> 00000000 eb 92 c9 6d 62 6f 6f 74 61 72 67 73 3d 63 6f 6e
> |...mbootargs=con|
> 00000010 73 6f 6c 65 3d 74 74 79 55 4c 30 2c 39 36 30 30
> |sole=ttyUL0,9600|
> 00000020 20 72 6f 6f 74 3d 2f 64 65 76 2f 6e 66 73 20 72 |
> root=/dev/nfs r|
> 00000030 77 20 6e 66 73 72 6f 6f 74 3d 31 32 39 2e 31 32 |w
> nfsroot=129.12|
> 00000040 39 2e 31 34 34 2e 31 31 33 3a 2f 6f 70 74 2f 65
> |9.144.113:/opt/e|
> 00000050 6c 64 6b 34 31 2f 70 70 63 5f 34 78 78 2c 74 63
> |ldk41/ppc_4xx,tc|
>
> The real problems begin when I want to deal with jffs2 file system.
>
> I have mtd3 partition which is intended to hold jffs2 fs.
> To create the jffs2 fs I do:
>
> ./mkfs.jffs2 --pad=0xA0000 --eraseblock=0x20000 --root=/tmp/bin/mtd1/work/
> --output=image2.jffs2
> flash_erase /dev/mtd3
> dd if=./image2.jffs2 of=/dev/mtd3 bs=2 count=655360
>
> After that I have jffs2 fs under /dev/mtd3.
>
> When I try to mount the jffs2 partition fun begins:
>
> mount -t jffs2 /dev/mtdblock3 /mnt
>
> [ 2828.462121] jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985,
> 0x2003, 0x00000000) has invalid CRC 0xf0600000 (calculated 0xf9d690b3)
> [ 2828.610485] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
> 0x00000008: 0xf060 instead
> [ 2828.719326] jffs2_scan_eraseblock(): Node at 0x0000000c {0x1985,
> 0xe001, 0x00000000) has invalid CRC 0xc3200000 (calculated 0x92fedd67)
> [ 2828.870047] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
> 0x00000014: 0xc320 instead
> [ 2828.979854] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
> 0x00000024: 0x46fc instead
>
> .
> .
> .
> .
>
> [ 2834.858103] Further such events for this erase block will not be
> printed
> [ 2835.029913] Cowardly refusing to erase blocks on filesystem with no
> valid JFFS2 nodes
> [ 2835.124378] empty_blocks 0, bad_blocks 0, c->nr_blocks 5
> mount: mounting /dev/mtdblock3 on /mnt failed
>
>
> I have examined carefully the above output and what I see is that linux
> does not properly access the flash memory:
>
> I did the hexdump on the image2.jffs2 (which is placed in /dev/mtd3) and
> compared it with the jffs2 mount messages:
>
> hexdump -C image2.jffs2
>
> 00000000 19 85 20 03 00 00 00 0c f0 60 dc 98 19 85 e0 01 |..
> ......`......|
> 00000010 00 00 00 31 c3 20 dd 5d 00 00 00 01 00 00 00 00 |...1.
> .]........|
>
> jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003, 0x00000000)
> has invalid CRC 0xf0600000 (calculated 0xf9d690b3)
>
> The linux mount complains about wrong CRC (invalid CRC 0xf0600000) but in
> the memory it is
> f0 60 dc 98 (so it means that it was read in byte by byte mode but not in
> x16 (2 bytes) mode).
>
> Does somebody know how to fix this problem?
>
> Best Regards
>
> Mirek
>
>
>
>
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Flash-paritioning-and-JFFS2-tf4317566.html#a12948521
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Grant Likely @ 2007-09-28 20:52 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40709281350y63475e93hd18e7da497c6f1b0@mail.gmail.com>
On 9/28/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
> > On Fri, Sep 28, 2007 at 02:42:32PM -0600, Grant Likely wrote:
> > > On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
> > > > Also, I'm not sure you need to cast port->membase to void*, do you? The
> > > > math will still be right since it's declared as char *.
> > >
> > > membase is now defined as u32*, so the cast is needed.
> >
> > Hm, I must have looked at a stale tree.
>
> No, wait. You're right. It is a char*. I'll drop the cast.
Wait, I'm wrong again... it's in/out_be32 that expects an (unsigned*).
The compiler complains without the cast.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Grant Likely @ 2007-09-28 20:50 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070928204749.GD23749@lixom.net>
On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Sep 28, 2007 at 02:42:32PM -0600, Grant Likely wrote:
> > On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
> > > Also, I'm not sure you need to cast port->membase to void*, do you? The
> > > math will still be right since it's declared as char *.
> >
> > membase is now defined as u32*, so the cast is needed.
>
> Hm, I must have looked at a stale tree.
No, wait. You're right. It is a char*. I'll drop the cast.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Olof Johansson @ 2007-09-28 20:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40709281342h4f8ff3fdv265e8098d2da6f52@mail.gmail.com>
On Fri, Sep 28, 2007 at 02:42:32PM -0600, Grant Likely wrote:
> On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
>
> > Hmm, I see the start changed, and you're now reading/writing a full
> > 32-bit word instead of individual bytes. Still, looks a little fishy to
> > me. Wouldn't it be more appropriate to change the ULITE_RX offset to be
> > 3 higher and still read/write bytes?
> >
> > Or are the registers defined as 32-bit ones? (I don't remember, it was
> > so long since I touched uartlite myself. :-)
>
> All the registers are defined as 32 bit ones. I think it makes more
> sense to access the registers as they are documented, and it
> eliminates the 'magic' +3 needed to make it work now.
Ok, thaks for the clarification. Feel free to add it as motivation in
the patch description. :)
> > (Same for the other functions below, but the general principle applies.)
> >
> > Also, I'm not sure you need to cast port->membase to void*, do you? The
> > math will still be right since it's declared as char *.
>
> membase is now defined as u32*, so the cast is needed.
Hm, I must have looked at a stale tree.
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Grant Likely @ 2007-09-28 20:42 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070928203104.GC23749@lixom.net>
On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Sep 28, 2007 at 12:17:13PM -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > Acked-by: John Williams <jwilliams@itee.uq.edu.au>
> > ---
> >
> > arch/ppc/syslib/virtex_devices.c | 2 +-
> > drivers/serial/uartlite.c | 32 ++++++++++++++++----------------
> > 2 files changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
> > index ace4ec0..270ad3a 100644
> > --- a/arch/ppc/syslib/virtex_devices.c
> > +++ b/arch/ppc/syslib/virtex_devices.c
> > @@ -28,7 +28,7 @@
> > .num_resources = 2, \
> > .resource = (struct resource[]) { \
> > { \
> > - .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
> > + .start = XPAR_UARTLITE_##num##_BASEADDR, \
> > .end = XPAR_UARTLITE_##num##_HIGHADDR, \
> > .flags = IORESOURCE_MEM, \
> > }, \
> > diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
> > index f5051cf..59b674a 100644
> > --- a/drivers/serial/uartlite.c
> > +++ b/drivers/serial/uartlite.c
> > @@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
> > /* stats */
> > if (stat & ULITE_STATUS_RXVALID) {
> > port->icount.rx++;
> > - ch = readb(port->membase + ULITE_RX);
> > + ch = in_be32((void*)port->membase + ULITE_RX);
>
> Hmm, I see the start changed, and you're now reading/writing a full
> 32-bit word instead of individual bytes. Still, looks a little fishy to
> me. Wouldn't it be more appropriate to change the ULITE_RX offset to be
> 3 higher and still read/write bytes?
>
> Or are the registers defined as 32-bit ones? (I don't remember, it was
> so long since I touched uartlite myself. :-)
All the registers are defined as 32 bit ones. I think it makes more
sense to access the registers as they are documented, and it
eliminates the 'magic' +3 needed to make it work now.
>
> (Same for the other functions below, but the general principle applies.)
>
> Also, I'm not sure you need to cast port->membase to void*, do you? The
> math will still be right since it's declared as char *.
membase is now defined as u32*, so the cast is needed.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 02/18] Add Kconfig macros for Xilinx Virtex support
From: Grant Likely @ 2007-09-28 20:39 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070928201946.GB23749@lixom.net>
On 9/28/07, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Sep 28, 2007 at 12:16:01PM -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > arch/powerpc/platforms/40x/Kconfig | 30 +++++++++++++++++-------------
> > 1 files changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
> > index c3dce3b..1aae0e6 100644
> > --- a/arch/powerpc/platforms/40x/Kconfig
> > +++ b/arch/powerpc/platforms/40x/Kconfig
> > @@ -61,13 +61,14 @@ config WALNUT
> > help
> > This option enables support for the IBM PPC405GP evaluation board.
> >
> > -#config XILINX_ML300
> > -# bool "Xilinx-ML300"
> > -# depends on 40x
> > -# default y
> > -# select VIRTEX_II_PRO
> > -# help
> > -# This option enables support for the Xilinx ML300 evaluation board.
> > +config XILINX_VIRTEX_GENERIC_BOARD
> > + bool "Generic Xilinx Virtex board"
> > + depends on 40x
> > + default y
> > + select VIRTEX_II_PRO
> > + select VIRTEX_4_FX
> > + help
> > + This option enables generic support for Xilinx Virtex based boards.
>
> I would appreciate a bit verboser help text here, i.e. including what
> boards are considered generic. Maybe something like "...including ML403,
> <x>, <y>, and other 4FX/IIPro-based boards"?
Done.
This option enables generic support for Xilinx Virtex based boards.
+ The generic virtex board support matches any device tree which
+ specifies 'xilinx,virtex' in its compatible field. This includes
+ the Xilinx ML3xx and ML4xx reference designs using the powerpc
+ core.
+
+ Most Virtex designs should use this unless it needs to do some
+ special configuration at board probe time.
+
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Vitaly Bordug @ 2007-09-28 20:30 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <20070928190616.GB20213@loki.buserror.net>
Kumar,
Realizing this may suffer a bit from cleanest-dts flame war, but anyway I pretty much see a lot of
sense in getting this in during next merge window. Is this possible?
On Fri, 28 Sep 2007 14:06:16 -0500
Scott Wood wrote:
> The way the current CPM binding describes available multi-user (a.k.a.
> dual-ported) RAM doesn't work well when there are multiple free regions,
> and it doesn't work at all if the region doesn't begin at the start of
> the muram area (as the hardware needs to be programmed with offsets into
> this area). The latter situation can happen with SMC UARTs on CPM2, as its
> parameter RAM is relocatable, u-boot puts it at zero, and the kernel doesn't
> support moving it.
>
> It is now described with a muram node, similar to QE. The current CPM
> binding is sufficiently recent (i.e. never appeared in an official release)
> that compatibility with existing device trees is not an issue.
>
> The code supporting the new binding is shared between cpm1 and cpm2, rather
> than remain separated. QE should be able to use this code as well, once
> minor fixes are made to its device trees.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
> Documentation/powerpc/booting-without-of.txt | 40 ++++++-
> arch/powerpc/Kconfig.debug | 6 +-
> arch/powerpc/boot/cpm-serial.c | 44 +++++--
> arch/powerpc/boot/dts/ep88xc.dts | 13 ++-
> arch/powerpc/boot/dts/mpc8272ads.dts | 11 ++
> arch/powerpc/boot/dts/mpc885ads.dts | 13 ++-
> arch/powerpc/boot/dts/pq2fads.dts | 13 ++-
> arch/powerpc/sysdev/commproc.c | 11 ++-
> arch/powerpc/sysdev/cpm2_common.c | 36 ++----
> arch/powerpc/sysdev/cpm_common.c | 159 ++++++++++++++++++++++++++
> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 4 +-
> include/asm-powerpc/commproc.h | 12 ++
> include/asm-powerpc/cpm.h | 14 +++
> include/asm-powerpc/cpm2.h | 10 ++
> 14 files changed, 338 insertions(+), 48 deletions(-)
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 06/18] [POWERPC] Fix UARTLITE reg io for little-endian architectures (ie. microblaze)
From: Olof Johansson @ 2007-09-28 20:31 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070928181704.18608.40317.stgit@trillian.cg.shawcable.net>
On Fri, Sep 28, 2007 at 12:17:13PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Acked-by: John Williams <jwilliams@itee.uq.edu.au>
> ---
>
> arch/ppc/syslib/virtex_devices.c | 2 +-
> drivers/serial/uartlite.c | 32 ++++++++++++++++----------------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
> index ace4ec0..270ad3a 100644
> --- a/arch/ppc/syslib/virtex_devices.c
> +++ b/arch/ppc/syslib/virtex_devices.c
> @@ -28,7 +28,7 @@
> .num_resources = 2, \
> .resource = (struct resource[]) { \
> { \
> - .start = XPAR_UARTLITE_##num##_BASEADDR + 3, \
> + .start = XPAR_UARTLITE_##num##_BASEADDR, \
> .end = XPAR_UARTLITE_##num##_HIGHADDR, \
> .flags = IORESOURCE_MEM, \
> }, \
> diff --git a/drivers/serial/uartlite.c b/drivers/serial/uartlite.c
> index f5051cf..59b674a 100644
> --- a/drivers/serial/uartlite.c
> +++ b/drivers/serial/uartlite.c
> @@ -61,7 +61,7 @@ static int ulite_receive(struct uart_port *port, int stat)
> /* stats */
> if (stat & ULITE_STATUS_RXVALID) {
> port->icount.rx++;
> - ch = readb(port->membase + ULITE_RX);
> + ch = in_be32((void*)port->membase + ULITE_RX);
Hmm, I see the start changed, and you're now reading/writing a full
32-bit word instead of individual bytes. Still, looks a little fishy to
me. Wouldn't it be more appropriate to change the ULITE_RX offset to be
3 higher and still read/write bytes?
Or are the registers defined as 32-bit ones? (I don't remember, it was
so long since I touched uartlite myself. :-)
(Same for the other functions below, but the general principle applies.)
Also, I'm not sure you need to cast port->membase to void*, do you? The
math will still be right since it's declared as char *.
-Olof
^ 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