* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Laurent Pinchart @ 2008-04-03 13:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb
In-Reply-To: <20080311191744.GA10518@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Hi Anton,
On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote:
> This is patch adds support for the FHCI USB controller, as found
> in the Freescale MPC836x and MPC832x processors. It can support
> Full or Low speed modes.
>
> Quite a lot hardware is doing by itself (SOF generation, CRC generation
> and checking), though scheduling and retransmission is on the software
> shoulders.
>
> This controller does not integrate the root hub, so this driver also
> fakes an one-port hub. External hub is required to support more than
> one device.
Would it be possible to use the driver for CPM2-based devices ? The only
difference I found between the CPM2 and QE USB controllers is the SOF
handling. The QE USB controller increments the frame number itself, while the
CPM USB controller requires the host to increment the frame number.
At first sight the driver depends on qe_lib for:
- muram allocation (qe_muram_alloc/free, qe_muram_offset/addr)
- GPIO access (qe_gpio_set_dedicated)
- clock routing (qe_clock_source, qe_usb_clock_set)
- QE commands execution (qe_issue_cmd)
It shouldn't be too difficult to abstract those operation in a fashion similar
to the cpm_uart driver.
Have you already worked on CPM2 support, or thought about any particular issue
I should pay attention to ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Some EMAC related changes in Canyonlands & Glacier dts files
From: Stefan Roese @ 2008-04-03 13:35 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes some problems in the Canyonlands 460EX and Glacier 460GT
dts files:
- Add "mdio-device = <&EMAC0>" to all all EMAC's except for EMAC0 itself
(the 460EX/GT only can access the PHY via the EMAC0 instance)
- Add TAH support to Canyonlands dts
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/canyonlands.dts | 19 +++++++++++++++----
arch/powerpc/boot/dts/glacier.dts | 5 ++++-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 657f2b4..6f3d38a 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -215,6 +215,16 @@
has-mdio;
};
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460ex", "ibm,tah";
+ reg = <ef601350 30>;
+ };
+
+ TAH1: emac-tah@ef601450 {
+ compatible = "ibm,tah-460ex", "ibm,tah";
+ reg = <ef601450 30>;
+ };
+
EMAC0: ethernet@ef600e00 {
device_type = "network";
compatible = "ibm,emac-460ex", "ibm,emac4";
@@ -236,10 +246,10 @@
tx-fifo-size = <800>;
phy-mode = "rgmii";
phy-map = <00000000>;
- zmii-device = <&ZMII0>;
- zmii-channel = <0>;
rgmii-device = <&RGMII0>;
rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
@@ -265,12 +275,13 @@
tx-fifo-size = <800>;
phy-mode = "rgmii";
phy-map = <00000000>;
- zmii-device = <&ZMII0>;
- zmii-channel = <1>;
rgmii-device = <&RGMII0>;
rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <1>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
};
};
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
index 7a7c9bf..958a5ca 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -287,9 +287,10 @@
rgmii-device = <&RGMII0>;
rgmii-channel = <1>;
tah-device = <&TAH1>;
- tah-channel = <0>;
+ tah-channel = <1>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
};
EMAC2: ethernet@ef601100 {
@@ -317,6 +318,7 @@
rgmii-channel = <0>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
};
EMAC3: ethernet@ef601200 {
@@ -344,6 +346,7 @@
rgmii-channel = <1>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
};
};
--
1.5.4.5
^ permalink raw reply related
* RE: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-03 13:29 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
In-Reply-To: <200804030616.09825.arnd@arndb.de>
Thanks Arnd, I apologize for not keeping you in the loop on this.
I'm still learning the process and appreciate your help and patience.
Thanks to all for the work to get consensus on this,
John
-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de]=20
Sent: Wednesday, April 02, 2008 10:16 PM
To: linuxppc-dev@ozlabs.org
Cc: Grant Likely; John Linn; Segher Boessenkool; Josh Boyer
Subject: Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for =
Xilinx uart 16550.
On Thursday 03 April 2008, Grant Likely wrote:
> >
> > =A0Since it is not really compatible with ns16550, shouldn't you at =
least specify
> > =A0a different "compatible" property? That way, the driver won't do =
incorrect
> > =A0accesses when you try to use an old driver with a device tree =
that specifies
> > =A0one of these.
>=20
> Heh; we've gone back and forth on this issue. =A0The problem is that =
we
> have a common case of ns16550 like devices that require a little bit
> of register address tweaking that spans a whole range of vendors (so
> adding a compatible match with each of those vendor's prefixes is
> probably non-scalable). =A0So, if "ns16550" is not a good idea, then
> what should be used? =A0"sparse16550" has been suggested more than =
once.
After another IRC discussion between Grant, Segher and myself, we =
concluded
that we don't need to invent a new "compatible" value, as only new =
device
trees with old kernels will have a problem with this, and they don't =
work
in the first place.
The devices will still have their specific "compatible" value, e.g.
"xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly
"ns16450" and "i8250", although the last two do not have an effect
on Linux.
Josh, can you please forward all three patches in their latest version?
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* RE: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: John Linn @ 2008-04-03 13:28 UTC (permalink / raw)
To: Johann Baudy; +Cc: linuxppc-dev
In-Reply-To: <7e0dd21a0804030623s3571716fk8585b517c9aac1ed@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4539 bytes --]
Hi Johann,
You're right about it being missing. I have another patch for virtex
specific initialization that handles that. I have not submitted it yet
as I was trying to get these patches thru the system.
I have been told in this forum that the bootstrap loader should not be
setting up the baud rate and that normally the boot loader does it.
In the case of FPGAs, we don't always use a boot loader so we need this
to happen in the bootstrap loader. I can forward that patch to you if
you're interested before it goes to this group.
Thanks,
John
________________________________
From: Johann Baudy [mailto:johaahn@gmail.com]
Sent: Thursday, April 03, 2008 7:23 AM
To: John Linn
Cc: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca
Subject: Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx
uart 16550.
Hi John,
I've a small question about ns16550 boot support.
I can't see any code related to either "clock-frequency" or
"current-speed" key words.
Such actions are performed in of_serial.c to get appropriate baud rate
(update of UART_DLL and UART_DLM).
Is it needed or is it a misunderstanding?
Personally, I have added this below debug code (dirty :)) to make it
work.
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..850e223 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -26,6 +26,9 @@
#define UART_MSR 6 /* In: Modem Status Register */
#define UART_SCR 7 /* I/O: Scratch Register */
+#define UART_LCR_DLAB 0x80 /* Divisor latch access */
+#define UART_LCR_8_DATA_BITS 0x03
+
static unsigned char *reg_base;
static u32 reg_shift;
@@ -56,6 +59,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ unsigned long divisor=0;
+ unsigned long spd=0, clk=0;
+
+
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -75,5 +82,23 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
scdp->tstc = ns16550_tstc;
scdp->close = NULL;
+ n = getprop(devp, "current-speed", &spd, sizeof(spd));
+
+
+ n = getprop(devp, "clock-frequency", &clk, sizeof(clk));
+
+
+ if(spd&&clk)
+ {
+
+ divisor = clk / (spd * 16UL);
+
+ out_8(reg_base + (UART_FCR << reg_shift), 0x06);
+ out_8(reg_base + (UART_LCR << reg_shift),
UART_LCR_8_DATA_BITS|UART_LCR_DLAB);
+ out_8(reg_base + (UART_DLL << reg_shift), divisor&0xff);
+ out_8(reg_base + (UART_DLM << reg_shift), (divisor>>8)&0xff);
+ out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_8_DATA_BITS);
+
+ }
return 0;
Best regards,
Johann
On Wed, Apr 2, 2008 at 4:52 PM, John Linn <john.linn@xilinx.com> wrote:
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that the Xilinx UART 16550 can be used with it. The reg-shift
was already being handled.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
arch/powerpc/boot/ns16550.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..da9d2c2 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 reg_offset;
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
+ n = getprop(devp, "reg-offset", ®_offset,
sizeof(reg_offset));
+ if (n == sizeof(reg_offset))
+ reg_base += reg_offset;
+
n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
--
1.5.2.1
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Johann Baudy
johaahn@gmail.com
[-- Attachment #2: Type: text/html, Size: 15859 bytes --]
^ permalink raw reply related
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: Johann Baudy @ 2008-04-03 13:23 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.C835D1CF8088@mail12-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]
Hi John,
I've a small question about ns16550 boot support.
I can't see any code related to either "clock-frequency" or "current-speed"
key words.
Such actions are performed in of_serial.c to get appropriate baud rate
(update of UART_DLL and UART_DLM).
Is it needed or is it a misunderstanding?
Personally, I have added this below debug code (dirty :)) to make it work.
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..850e223 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -26,6 +26,9 @@
#define UART_MSR 6 /* In: Modem Status Register */
#define UART_SCR 7 /* I/O: Scratch Register */
+#define UART_LCR_DLAB 0x80 /* Divisor latch access */
+#define UART_LCR_8_DATA_BITS 0x03
+
static unsigned char *reg_base;
static u32 reg_shift;
@@ -56,6 +59,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ unsigned long divisor=0;
+ unsigned long spd=0, clk=0;
+
+
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -75,5 +82,23 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
scdp->tstc = ns16550_tstc;
scdp->close = NULL;
+ n = getprop(devp, "current-speed", &spd, sizeof(spd));
+
+
+ n = getprop(devp, "clock-frequency", &clk, sizeof(clk));
+
+
+ if(spd&&clk)
+ {
+
+ divisor = clk / (spd * 16UL);
+
+ out_8(reg_base + (UART_FCR << reg_shift), 0x06);
+ out_8(reg_base + (UART_LCR << reg_shift),
UART_LCR_8_DATA_BITS|UART_LCR_DLAB);
+ out_8(reg_base + (UART_DLL << reg_shift), divisor&0xff);
+ out_8(reg_base + (UART_DLM << reg_shift), (divisor>>8)&0xff);
+ out_8(reg_base + (UART_LCR << reg_shift), UART_LCR_8_DATA_BITS);
+
+ }
return 0;
Best regards,
Johann
On Wed, Apr 2, 2008 at 4:52 PM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> arch/powerpc/boot/ns16550.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
> +
> n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
> if (n != sizeof(reg_shift))
> reg_shift = 0;
> --
> 1.5.2.1
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Johann Baudy
johaahn@gmail.com
[-- Attachment #2: Type: text/html, Size: 5376 bytes --]
^ permalink raw reply related
* Re: [PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
From: Benjamin Herrenschmidt @ 2008-04-03 13:10 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200804031435.39999.sr@denx.de>
On Thu, 2008-04-03 at 14:35 +0200, Stefan Roese wrote:
> On Thursday 03 April 2008, Benjamin Herrenschmidt wrote:
> > On Thu, 2008-04-03 at 13:45 +0200, Stefan Roese wrote:
> > > On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
> > > of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
> > > the divided by 8 value for the bitmask.
> >
> > Sounds ok, but I wonder if we ever have a MAL with more than 8 chans, do
> > we need to make this shift conditional to some device tree prop ?
>
> I suggest we postpone such a conditional setup until we see such a MAL. OK?
Agreed. I got a bit carried away..
Ben.
^ permalink raw reply
* interrupt latency spi
From: mejjad lahcen @ 2008-04-03 13:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
hi all of you ,
I am wndering if someone has already done test for interrupt latency on
linx 2.6.23 mpc5200b.
I am working on writing a driver which is get SPi involved on design, and I
know that the spi interrupt will occurs at every 2 us ( speed 4 MHz
interupt occurs when It recieves on bytes) so I am worring about interrupt
latency.
I dont know if someone has any suggestions or a litle advice.
cheers
[-- Attachment #2: Type: text/html, Size: 534 bytes --]
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
From: Stefan Roese @ 2008-04-03 12:35 UTC (permalink / raw)
To: benh; +Cc: netdev, linuxppc-dev
In-Reply-To: <1207225740.10388.321.camel@pasglop>
On Thursday 03 April 2008, Benjamin Herrenschmidt wrote:
> On Thu, 2008-04-03 at 13:45 +0200, Stefan Roese wrote:
> > On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
> > of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
> > the divided by 8 value for the bitmask.
>
> Sounds ok, but I wonder if we ever have a MAL with more than 8 chans, do
> we need to make this shift conditional to some device tree prop ?
I suggest we postpone such a conditional setup until we see such a MAL. OK?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
From: Jochen Friedrich @ 2008-04-03 12:31 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <200804031319.12715.laurentp@cse-semaphore.com>
Hi Laurent,
> I haven't checked all CPM1-based parts, but for the MPC855 family this doesn't
> look right. The MPC855 has two 32-bit ports, port B and port E. Registers for
> port B are dir, par, odr and dat, and registers for port E are dir, par, sor,
> odr and dat.
You probably mean MPC885. Thanks for catching this, the 32bit registers really
are a mess on CPM1 platforms.
> Are you working on a similar patch for the CPM2 ? CPM2 I/O ports are 32 bit
> wide and their registers are layed out like for port E on the MPC855. It
> should thus be possible to share code between CPM1 and CPM2.
Yes, some common port setup code could probably be moved to cpm.c.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
From: Benjamin Herrenschmidt @ 2008-04-03 12:29 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <1207223110-27281-1-git-send-email-sr@denx.de>
On Thu, 2008-04-03 at 13:45 +0200, Stefan Roese wrote:
> On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
> of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
> the divided by 8 value for the bitmask.
Sounds ok, but I wonder if we ever have a MAL with more than 8 chans, do
we need to make this shift conditional to some device tree prop ?
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/net/ibm_newemac/mal.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
> index 6869f08..fb9c9eb 100644
> --- a/drivers/net/ibm_newemac/mal.c
> +++ b/drivers/net/ibm_newemac/mal.c
> @@ -136,6 +136,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int channel)
> {
> unsigned long flags;
>
> + /*
> + * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
> + * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
> + * for the bitmask
> + */
> + if (!(channel % 8))
> + channel >>= 3;
> +
> spin_lock_irqsave(&mal->lock, flags);
>
> MAL_DBG(mal, "enable_rx(%d)" NL, channel);
> @@ -148,6 +156,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int channel)
>
> void mal_disable_rx_channel(struct mal_instance *mal, int channel)
> {
> + /*
> + * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
> + * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
> + * for the bitmask
> + */
> + if (!(channel % 8))
> + channel >>= 3;
> +
> set_mal_dcrn(mal, MAL_RXCARR, MAL_CHAN_MASK(channel));
>
> MAL_DBG(mal, "disable_rx(%d)" NL, channel);
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-04-03 12:25 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402232213.5D87515B8067@mail37-sin.bigfish.com>
Hello.
John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..73c47a5 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,7 +31,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> struct resource resource;
> struct device_node *np = ofdev->node;
> const unsigned int *clk, *spd;
> - int ret;
> + const u32 *prop;
> + int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> spd = of_get_property(np, "current-speed", NULL);
> @@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
>
> spin_lock_init(&port->lock);
> port->mapbase = resource.start;
> +
> + /* Check for shifted address mapping */
> + prop = of_get_property(np, "reg-offset", &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + port->mapbase += *prop;
I disagree. That trick leads to I/O resource misaccounting/misreporting.
You should teach 8250.c about the offset trick instead, just as it's been
taught the shift trick in its time.
> +
> + /* Check for registers offset within the devices address range */
> + prop = of_get_property(np, "reg-shift", &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + port->regshift = *prop;
> +
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/4] [POWERPC] Implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-04-03 12:18 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804031305.53469.laurentp@cse-semaphore.com>
On Thu, Apr 03, 2008 at 01:05:51PM +0200, Laurent Pinchart wrote:
> Hi Anton,
>
> On Tuesday 11 March 2008 19:42, Anton Vorontsov wrote:
> > This patch implements support for the GPIO LIB API. Two calls
> > unimplemented though: irq_to_gpio and gpio_to_irq.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > Documentation/powerpc/booting-without-of.txt | 52 ++++++++++++++++++++++++
> > arch/powerpc/Kconfig | 5 ++
> > include/asm-powerpc/gpio.h | 55 ++++++++++++++++++++++++++
> > 3 files changed, 112 insertions(+), 0 deletions(-)
> > create mode 100644 include/asm-powerpc/gpio.h
>
> [snip]
>
> > diff --git a/include/asm-powerpc/gpio.h b/include/asm-powerpc/gpio.h
> > new file mode 100644
> > index 0000000..057840d
> > --- /dev/null
> > +++ b/include/asm-powerpc/gpio.h
> > @@ -0,0 +1,55 @@
> > +/*
> > + * Generic GPIO API implementation for PowerPC.
> > + *
> > + * Copyright (c) 2007-2008 MontaVista Software, Inc.
> > + *
> > + * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#ifndef __ASM_POWERPC_GPIO_H
> > +#define __ASM_POWERPC_GPIO_H
> > +
> > +#include <asm-generic/gpio.h>
> > +
> > +#ifdef CONFIG_HAVE_GPIO_LIB
> > +
> > +/*
> > + * We don't (yet) implement inlined/rapid versions for on-chip gpios.
> > + * Just call gpiolib.
> > + */
> > +static inline int gpio_get_value(unsigned int gpio)
> > +{
> > + return __gpio_get_value(gpio);
> > +}
> > +
> > +static inline void gpio_set_value(unsigned int gpio, int value)
> > +{
> > + __gpio_set_value(gpio, value);
> > +}
> > +
> > +static inline int gpio_cansleep(unsigned int gpio)
> > +{
> > + return __gpio_cansleep(gpio);
> > +}
> > +
> > +/*
> > + * Not implemented, yet.
> > + */
> > +static inline int gpio_to_irq(unsigned int gpio)
> > +{
> > + return -ENOSYS;
> > +}
> > +
> > +static inline int irq_to_gpio(unsigned int irq)
> > +{
> > + return -EINVAL;
> > +}
>
> You should include <linux/errno.h>.
Yeah, much thanks for catching this!
--
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-04-03 11:59 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, linuxppc-dev
In-Reply-To: <20080402213919.C261F5E007F@mail91-dub.bigfish.com>
Hello.
Stephen Neuendorffer wrote:
> I don't think big-endian has the same context as reg-shift/reg-offset.
The "big-endian" is about how the byte addresses are laid out, so the
context is the same -- in this case, it would determine where each UART
register is located within the address stride specified by "reg-shift".
It'll alwaay be at offset 0 or (2 << reg-shift) - 1 (unless some vendor goes
and implements something with "middle-endian" layout of course :-)
> The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If
So what?
> we were talking about a 32 bit device, then I'd probably agree with you,
There are 16550 clones that *are* 32-bit.
> but in this case, the reg-shift
I'm not arguing about "reg-shift" already -- look like it's been spec'ed. :-)
> (and to some extent) reg-offset have
> been used before and probably make more sense, I think.
The "reg-offset" has been used before? Where?
> Steve
WBR, Sergei
^ permalink raw reply
* [PATCH] ibm_newemac: Add support for 460EX/GT-type MAL rx-channel handling
From: Stefan Roese @ 2008-04-03 11:45 UTC (permalink / raw)
To: netdev, linuxppc-dev
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/mal.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 6869f08..fb9c9eb 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -136,6 +136,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int channel)
{
unsigned long flags;
+ /*
+ * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+ * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+ * for the bitmask
+ */
+ if (!(channel % 8))
+ channel >>= 3;
+
spin_lock_irqsave(&mal->lock, flags);
MAL_DBG(mal, "enable_rx(%d)" NL, channel);
@@ -148,6 +156,14 @@ void mal_enable_rx_channel(struct mal_instance *mal, int channel)
void mal_disable_rx_channel(struct mal_instance *mal, int channel)
{
+ /*
+ * On some 4xx PPC's (e.g. 460EX/GT), the rx channel is a multiple
+ * of 8, but enabling in MAL_RXCASR needs the divided by 8 value
+ * for the bitmask
+ */
+ if (!(channel % 8))
+ channel >>= 3;
+
set_mal_dcrn(mal, MAL_RXCARR, MAL_CHAN_MASK(channel));
MAL_DBG(mal, "disable_rx(%d)" NL, channel);
--
1.5.4.5
^ permalink raw reply related
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-04-03 11:33 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug fixes for powerpc, mostly for various embedded
platforms. The bulk of the changes are once again in the defconfigs.
Thanks,
Paul.
arch/powerpc/boot/dts/cm5200.dts | 37 +++++++++++++++-
arch/powerpc/boot/dts/lite5200.dts | 15 ++++++
arch/powerpc/boot/dts/motionpro.dts | 63 +++++++++++++++----=
--------
arch/powerpc/boot/dts/mpc8377=5Fmds.dts | 4 +-
arch/powerpc/boot/dts/mpc8377=5Frdb.dts | 3 -
arch/powerpc/boot/dts/mpc8378=5Frdb.dts | 3 -
arch/powerpc/boot/dts/mpc8379=5Fmds.dts | 8 ++-
arch/powerpc/boot/dts/mpc8379=5Frdb.dts | 3 -
arch/powerpc/boot/dts/tqm5200.dts | 42 ++++++++++++++++++
arch/powerpc/configs/mpc832x=5Fmds=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc834x=5Fmds=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc836x=5Fmds=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc837x=5Frdb=5Fdefconfig | 24 ++++++++++
arch/powerpc/configs/mpc83xx=5Fdefconfig | 24 ++++++++++
arch/powerpc/configs/mpc8544=5Fds=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc8568mds=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc8572=5Fds=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc85xx=5Fdefconfig | 11 +----
arch/powerpc/configs/mpc8641=5Fhpcn=5Fdefconfig | 11 +----
arch/powerpc/configs/prpmc2800=5Fdefconfig | 11 +----
arch/powerpc/configs/storcenter=5Fdefconfig | 11 +----
arch/powerpc/kernel/head=5F64.S | 13 +++---
arch/powerpc/kernel/irq.c | 1=20
arch/powerpc/kernel/rtas=5Fflash.c | 2 -
arch/powerpc/mm/hash=5Flow=5F32.S | 8 +++
arch/powerpc/sysdev/cpm2.c | 1=20
drivers/ata/sata=5Ffsl.c | 5 --
drivers/dma/fsldma.c | 8 ++-
drivers/net/fec=5Fmpc52xx.c | 1=20
drivers/net/fec=5Fmpc52xx=5Fphy.c | 1=20
30 files changed, 234 insertions(+), 142 deletions(-)
commit 8d813941b17626a7610342325be63435282bac02
Author: Ren=E9 B=FCrgel <r.buergel@unicontrol.de>
Date: Thu Apr 3 19:58:37 2008 +1100
[POWERPC] Fix MPC5200 (not B!) device tree so FEC ethernet works
=20
This gets the FEC ethernet driver working again on the lite5200
platform.
=20
The FEC driver is also compatible with the MPC5200, not only with t=
he
MPC5200B, so this adds a suitable entry to the driver's match list.=
Furthermore this adds the settings for the PHY in the dts file for =
the
Lite5200. Note, that this is not exactly the same as in the
Lite5200B, because the PHY is located at f0003000:01 for the 5200, =
and
at :00 for the 5200B. This was tested on a Lite5200 and a Lite5200=
B,
both booted a kernel via tftp and mounted the root via nfs
successfully.
=20
Signed-off-by: Ren=E9 B=FCrgel <r.buergel@unicontrol.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 115e1adca3b75a82f24da8b2cc9386eb5b7e2cff
Author: Bartlomiej Sieka <tur@semihalf.com>
Date: Thu Apr 3 01:26:02 2008 +1100
[POWERPC] mpc5200: Amalgamated DTS fixes and updates
=20
DTS updates that fix booting problems on mpc5200-based boards:
- change to ethernet reg property
- addition of mdio and phy nodes
- removal of pci node (Motion-Pro board)
=20
Other DTS updates:
- update i2c device tree nodes
- add lpb bus node and flash device (without partitions defined)
- add rtc i2c nodes
=20
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 7484839850d826e14b8b024bb048dca8489140ae
Author: Maxim Shchetynin <maxim@de.ibm.com>
Date: Wed Apr 2 00:12:20 2008 +1100
[POWERPC] Fix rtas=5Fflash procfs interface
=20
Handling of the proc=5Fdir=5Fentry->count was changed in 2.6.24-rc5=
=2E
After this change, the default value for pde->count is 1 and not 0 =
as
before. Therefore, if we want to check whether our procfs file is
already opened (already in use), we have to check if pde->count is
greater than 2 rather than 1.
=20
Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
Signed-off-by: Jens Osterkamp <jens@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b991f05f1326fd9e6212851d0f2099875906dd16
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon Mar 31 07:49:27 2008 +1100
[POWERPC] Fix deadlock with mmu=5Fhash=5Flock in hash=5Fpage=5Fsync=
=20
hash=5Fpage=5Fsync() takes and releases the low level mmu hash
lock in order to sync with other processors disposing of page
tables. Because that lock can be needed to service hash misses
triggered by interrupt handlers, taking it must be done with
interrupts off. However, hash=5Fpage=5Fsync() appears to be called=
with interrupts enabled, thus causing occasional deadlocks.
=20
We fix it by making sure hash=5Fpage=5Fsync() masks interrupts whil=
e
holding the lock.
=20
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ff3da2e0938bae36d10d69c22bce0177b067a9e2
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed Apr 2 15:58:40 2008 +1100
[POWERPC] Fix iSeries hard irq enabling regression
=20
A subtle bug sneaked into iSeries recently. On this platform, we m=
ust
not normally clear MSR:EE (the hardware external interrupt enable)
except for short periods of time. Taking an interrupt while
soft-disabled doesn't cause us to clear it for example.
=20
The iSeries kernel expects to mostly run with MSR:EE enabled at all=
times except in a few exception entry/exit code paths. Thus
local=5Firq=5Fenable() doesn't check if it needs to hard-enable as =
it
expects this to be unnecessary on iSeries.
=20
However, hard=5Firq=5Fdisable() =5Fdoes=5F cause MSR:EE to be clear=
ed,
including on iSeries. A call to it was recently added to the
context switch code, thus causing interrupts to become disabled
for a long periods of time, causing the iSeries watchdog to kick
in under some circumstances and other nasty things.
=20
This patch fixes it by making local=5Firq=5Fenable() properly re-en=
able
MSR:EE on iSeries. It basically removes a return statement here
to make iSeries use the same code path as everybody else. That doe=
s
mean that we might occasionally get spurious decrementer interrupts=
but I don't think that matters.
=20
Another option would have been to make hard=5Firq=5Fdisable() a nop=
on iSeries but I didn't like it much, in case we have good reasons
to hard-disable.
=20
Part of the patch is fixes to make sure the hard=5Fenabled PACA fie=
ld
is properly set on iSeries as it used not to be before, since it
was mostly unused.
=20
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 025306f30948836a743eb68a7cbaf4ab0bfb5f47
Author: Laurent Pinchart <laurentp@cse-semaphore.com>
Date: Wed Apr 2 16:46:31 2008 +0200
[POWERPC] Fix CPM2 SCC1 clock initialization.
=20
A missing break statement in a switch caused cpm2=5Fclk=5Fsetup() t=
o initialize
SCC2 instead of SCC1.
=20
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 1e85d89fa3954eff332033c0e75f6e2442be44ed
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Mar 31 11:53:46 2008 -0500
[POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB
=20
The new rtc subsystem conflicts with genrtc so don't enable GENRTC
if RTCLIB is enabled.
=20
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 049c9d45531d9825bf737891163a794fca1421c5
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Mar 31 11:13:21 2008 -0500
[POWERPC] fsldma: Use compatiable binding as spec
=20
Documentation/powerpc/booting-without-of.txt specifies the
compatiables we should bind to for this driver (elo, eloplus).
Use these instead of the extremely specific 'mpc8540' and 'mpc8349'=
compatiables.
=20
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 96ce1b6dc5824cc6027c954b9a2e4717c70e01b5
Author: Kim Phillips <kim.phillips@freescale.com>
Date: Fri Mar 28 10:51:33 2008 -0500
[POWERPC] sata=5Ffsl: reduce compatibility to fsl,pq-sata
=20
as prescribed in Documentation/powerpc/booting-without-of.txt.
=20
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 58bb7a973b1d3c0a5127477fb049bbfc5ce02fb5
Author: Kim Phillips <kim.phillips@freescale.com>
Date: Fri Mar 28 10:51:29 2008 -0500
[POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs
=20
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 8e8ff3a309ebdaad51fd7a64a6fd2a2f88b30d87
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed Mar 12 23:02:13 2008 +0300
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
=20
Due to chip constraint MPC837x USB DR module can only use
ULPI and serial PHY interfaces. The patch fixes the wrong
type in dts.
=20
This patch fixes USB malfunctioning on the MPC837xE-RDB boards.
=20
Similar patch has been already applied for the MDS boards:
=20
commit 28b958859206b7010d03129611c2e444898e3ee4
Author: Li Yang <leoli@freescale.com>
Date: Thu Mar 6 18:42:26 2008 +0800
=20
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
=20
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: printk time confusion?
From: Andreas Schwab @ 2008-04-03 11:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Arnd Bergmann, Benjamin Herrenschmidt
In-Reply-To: <1207221159.3636.44.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
>> >> [ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
>
>> > Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
>> > the pty stuff to find out which ones it is and if it can be a problem...
>>
>> 0x53xx is claimed by cdrom.h, and 0x530b is CDROMSUBCHNL. Of course, a
>> tty does not implement cdrom ioctls.
>
> Humm ok, then the first question is why gnome-terminal tries that
Perhaps some misconfiguration, I can't reproduce that here (with
2.18.2).
> and the second why it would printk something?
To ease finding missing compat ioctl handlers.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
From: Laurent Pinchart @ 2008-04-03 11:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, linux-kernel
In-Reply-To: <47E92EC8.7010700@scram.de>
[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]
Hi Jochen,
On Tuesday 25 March 2008 17:56, Jochen Friedrich wrote:
> Implement GPIO LIB API on CPM1 Freescale SoC.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
>
> This is based on the series starting at
http://patchwork.ozlabs.org/linuxppc/patch?id=17299
>
> arch/powerpc/platforms/8xx/Kconfig | 2 +
> arch/powerpc/sysdev/cpm1.c | 240
+++++++++++++++++++++++++++++++++++-
> 2 files changed, 241 insertions(+), 1 deletions(-)
>
[snip]
> diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
> index df8bd2b..c3d5df8 100644
> --- a/arch/powerpc/sysdev/cpm1.c
> +++ b/arch/powerpc/sysdev/cpm1.c
> @@ -30,11 +30,14 @@
> #include <linux/interrupt.h>
> #include <linux/irq.h>
> #include <linux/module.h>
> +#include <linux/spinlock.h>
> +#include <linux/of_gpio.h>
> #include <asm/page.h>
> #include <asm/pgtable.h>
> #include <asm/8xx_immap.h>
> #include <asm/cpm1.h>
> #include <asm/io.h>
> +#include <asm/gpio.h>
> #include <asm/tlbflush.h>
> #include <asm/rheap.h>
> #include <asm/prom.h>
> @@ -403,7 +406,7 @@ struct cpm_ioport16 {
> };
>
> struct cpm_ioport32 {
> - __be32 dir, par, sor;
> + __be32 dir, par, sor, dat;
> };
I haven't checked all CPM1-based parts, but for the MPC855 family this doesn't
look right. The MPC855 has two 32-bit ports, port B and port E. Registers for
port B are dir, par, odr and dat, and registers for port E are dir, par, sor,
odr and dat.
Are you working on a similar patch for the CPM2 ? CPM2 I/O ports are 32 bit
wide and their registers are layed out like for port E on the MPC855. It
should thus be possible to share code between CPM1 and CPM2.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: printk time confusion?
From: Johannes Berg @ 2008-04-03 11:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list, Arnd Bergmann, Benjamin Herrenschmidt
In-Reply-To: <jehcejqjpj.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
> >> [ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
> > Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
> > the pty stuff to find out which ones it is and if it can be a problem...
>
> 0x53xx is claimed by cdrom.h, and 0x530b is CDROMSUBCHNL. Of course, a
> tty does not implement cdrom ioctls.
Humm ok, then the first question is why gnome-terminal tries that, and
the second why it would printk something?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: printk time confusion?
From: Andreas Schwab @ 2008-04-03 11:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Johannes Berg, Arnd Bergmann
In-Reply-To: <1207219724.10388.319.camel@pasglop>
Benjamin Herrenschmidt <benh@ozlabs.org> writes:
> On Wed, 2008-04-02 at 16:23 +0200, Johannes Berg wrote:
>> [...]
>> [ 176.440255] iwl4965: No space for Tx
>> [...]
>> [ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
>> [...]
>> [ 173.589209] BUG kmalloc-2048: Poison overwritten
>> [...]
>> [ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
>> [...]
>> [ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
>> [...]
>> [ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
>> [...]
>> [ 218.918388] tg3: eth0: Link is down.
>> [...]
>>
>> Yes, these entries really were printed in that order. Btw, what's with
>> the unknown ioctls?
>
> Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
> the pty stuff to find out which ones it is and if it can be a problem...
0x53xx is claimed by cdrom.h, and 0x530b is CDROMSUBCHNL. Of course, a
tty does not implement cdrom ioctls.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: printk time confusion?
From: Johannes Berg @ 2008-04-03 11:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Arnd Bergmann
In-Reply-To: <1207219724.10388.319.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
> > Not sure whether the lockdep patches or something else is causing this
> > as I haven't checked w/o the patches yet, but I seem to be having some
> > confusion of printk timestamps:
>
> Tried reverting the patches ?
No, not yet, I'll do that later today.
> > [ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
> > Yes, these entries really were printed in that order. Btw, what's with
> > the unknown ioctls?
>
> Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
> the pty stuff to find out which ones it is and if it can be a problem...
Yeah, I'll have to see, I just thought Arnd might already know :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] [POWERPC] Implement support for the GPIO LIB API
From: Laurent Pinchart @ 2008-04-03 11:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080311184220.GB32164@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
Hi Anton,
On Tuesday 11 March 2008 19:42, Anton Vorontsov wrote:
> This patch implements support for the GPIO LIB API. Two calls
> unimplemented though: irq_to_gpio and gpio_to_irq.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 52 ++++++++++++++++++++++++
> arch/powerpc/Kconfig | 5 ++
> include/asm-powerpc/gpio.h | 55 ++++++++++++++++++++++++++
> 3 files changed, 112 insertions(+), 0 deletions(-)
> create mode 100644 include/asm-powerpc/gpio.h
[snip]
> diff --git a/include/asm-powerpc/gpio.h b/include/asm-powerpc/gpio.h
> new file mode 100644
> index 0000000..057840d
> --- /dev/null
> +++ b/include/asm-powerpc/gpio.h
> @@ -0,0 +1,55 @@
> +/*
> + * Generic GPIO API implementation for PowerPC.
> + *
> + * Copyright (c) 2007-2008 MontaVista Software, Inc.
> + *
> + * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __ASM_POWERPC_GPIO_H
> +#define __ASM_POWERPC_GPIO_H
> +
> +#include <asm-generic/gpio.h>
> +
> +#ifdef CONFIG_HAVE_GPIO_LIB
> +
> +/*
> + * We don't (yet) implement inlined/rapid versions for on-chip gpios.
> + * Just call gpiolib.
> + */
> +static inline int gpio_get_value(unsigned int gpio)
> +{
> + return __gpio_get_value(gpio);
> +}
> +
> +static inline void gpio_set_value(unsigned int gpio, int value)
> +{
> + __gpio_set_value(gpio, value);
> +}
> +
> +static inline int gpio_cansleep(unsigned int gpio)
> +{
> + return __gpio_cansleep(gpio);
> +}
> +
> +/*
> + * Not implemented, yet.
> + */
> +static inline int gpio_to_irq(unsigned int gpio)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline int irq_to_gpio(unsigned int irq)
> +{
> + return -EINVAL;
> +}
You should include <linux/errno.h>.
> +#endif /* CONFIG_HAVE_GPIO_LIB */
> +
> +#endif /* __ASM_POWERPC_GPIO_H */
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: make mem_map allocation continuous v2.
From: Kamalesh Babulal @ 2008-04-03 10:49 UTC (permalink / raw)
To: Yinghai Lu
Cc: kernel list, Yinghai Lu, linuxppc-dev, Badari Pulavarty,
Andrew Morton, Ingo Molnar, Balbir Singh
In-Reply-To: <86802c440804022116j2a8fb745pf734f61542a8e287@mail.gmail.com>
Yinghai Lu wrote:
> On Wed, Apr 2, 2008 at 7:22 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
>>
>> > v2 replace:
>> > [PATCH] mm: make mem_map allocation continuous.
>> > [PATCH] mm: allocate section_map for sparse_init
>> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>> >
>>
>> err, no.
>>
>>
>> >
>> > diff --git a/mm/sparse.c b/mm/sparse.c
>> > index f6a43c0..2881222 100644
>> > --- a/mm/sparse.c
>> > +++ b/mm/sparse.c
>>
>> Sorry, but I'd rather not do it this way. We presently have this:
>>
>
> it replaces
>
>> mm-make-mem_map-allocation-continuous.patch
>> mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch
>> mm-allocate-section_map-for-sparse_init.patch
>> mm-allocate-section_map-for-sparse_init-update.patch
>> mm-allocate-section_map-for-sparse_init-update-fix.patch
>> mm-allocate-section_map-for-sparse_init-powerpc-fix.patch
>
> others still needed
>
> so mm-make-mem-map-allocation-continuous.patch will not break powerpc and ia64
>
> YH
Hi,
Thanks, the patch fixes the issue. I am able to bootup without the kernel panic.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: printk time confusion?
From: Benjamin Herrenschmidt @ 2008-04-03 10:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Arnd Bergmann
In-Reply-To: <1207146186.3957.11.camel@johannes.berg>
On Wed, 2008-04-02 at 16:23 +0200, Johannes Berg wrote:
> Hi,
>
> Not sure whether the lockdep patches or something else is causing this
> as I haven't checked w/o the patches yet, but I seem to be having some
> confusion of printk timestamps:
Tried reverting the patches ?
> [...]
> [ 176.440255] iwl4965: No space for Tx
> [...]
> [ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
> [...]
> [ 173.589209] BUG kmalloc-2048: Poison overwritten
> [...]
> [ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
> [...]
> [ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
> [...]
> [ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
> [...]
> [ 218.918388] tg3: eth0: Link is down.
> [...]
>
> Yes, these entries really were printed in that order. Btw, what's with
> the unknown ioctls?
Proably ioctl's that lack a 32 bits conversion, you'll have to dig in
the pty stuff to find out which ones it is and if it can be a problem...
> Kernel version is 2.6.25-rc8-wl-04519-g6648ff7-dirty where -wl/-dirty
> refers to wireless patches and the lockdep patches and otherwise it's
> just -rc8.
>
> johannes
^ permalink raw reply
* Re: [PATCHv2] powerpc: Describe memory-mapped RAM&ROM chips OF bindings
From: Laurent Pinchart @ 2008-04-03 10:15 UTC (permalink / raw)
To: Grant Likely; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <fa686aa40804010616v4d6a2c8at5d3be8c32f316494@mail.gmail.com>
On Tuesday 01 April 2008 15:16, Grant Likely wrote:
> On Mon, Mar 31, 2008 at 10:39 AM, Laurent Pinchart
> <laurentp@cse-semaphore.com> wrote:
> >
> > Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> > ---
> > Documentation/powerpc/booting-without-of.txt | 13 ++++++++++++-
> > 1 files changed, 12 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/powerpc/booting-without-of.txt=20
> > b/Documentation/powerpc/booting-without-of.txt=20
> > index 7b4e8a7..3e1963b 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -57,7 +57,8 @@ Table of Contents
> > n) 4xx/Axon EMAC ethernet nodes
> > o) Xilinx IP cores
> > p) Freescale Synchronous Serial Interface
> > - q) USB EHCI controllers
> > + q) USB EHCI controllers
> > + r) Memory-mapped RAM & ROM
> >
> > VII - Specifying interrupt information for devices
> > 1) interrupts property
> > @@ -2816,6 +2817,16 @@ platforms are moved over to use the
> > flattened-device-tree model.=20
> > big-endian;
> > };
> >
> > + r) Memory-mapped RAM & ROM
> > +
> > + Dedicated RAM and ROM chips are often used as storage for tempora=
ry
> > or=20
> > + permanent data in embedded devices. Possible usage include
> > non-volatile=20
> > + storage in battery-backed SRAM, semi-permanent storage in dedicat=
ed
> > SRAM=20
> > + to preserve data accross reboots and firmware storage in dedicated
> > ROM.=20
> > +
> > + - name : should be either "ram" or "rom"
> > + - reg : Address range of the RAM/ROM chip
> > +
>=20
> No compatible prop? How does the OS know what the node is to be used for?
If I understood Sergei's arguments properly, the device tree should describ=
e=20
device properties and not their intended usage. With generic devices such a=
s=20
RAM chips, platform code is responsible for binding the device to the=20
appropriate driver (mtd-ram for instance).
Cheers,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Problems with busybox or filesystem ...
From: Georg Schardt @ 2008-04-03 10:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi again,
its strange, now i have a filesystem with busybox 1.7.0 working if i
boot from systemace - module.
if i create a jffs2 image with the same filesystem, put it into flash
and try to boot from flash busybox hangs after a few bytes of output.
using kernel 2.6 from git.xilinx.com on a virtex4fx12 minimodul:
Output from kernel, and a few Bytes from busybox:
[ 2.219956] VFS: Mounted root (jffs2 filesystem).
[ 2.224084] Freeing unused kernel memory: 100k init
init
2.6. Lin
and then nothing :)
i tried a few other things:
- put the rootfs in a ramdisk -> same problem, but sometimes a few bytes
more output :)
- change busybox version -> same problem
- change to secretlab kernel -> same problem
- use another gcc glibc version on crosscompiler -> same version
Whats wrong ? Its just a device missing ? Does the kernel unmounts the
rootfs after starting init or something like this ? i this a problem
with the console/serial device ? i have no idea what i can try next.
its very frustrating :)
thanks
georg
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
^ 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