* Re: [PATCH] Handle reg-shift property for of_serial ports
From: David Woodhouse @ 2007-07-07 16:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
On Sat, 2007-07-07 at 14:10 +0200, Arnd Bergmann wrote:
> Given the existence of the boards, it looks correct to do this.
> However, I wonder if it was correct for the MV64660 to claim
> compatibily witn ns16550 if the programming model is not exactly
> the same. The official OF serial port bindings don't mention the
> reg-shift property, so it maybe would have been better to have
> a different value for the "compatible" property, in order not
> to confuse existing operating systems that implement the standard.
Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
the reg-shift property. I'll send a patch shortly, and I'll reorder the
match table -- if something claims compatibility with both 8250 and
16550, shouldn't we drive it as the latter?
Can we add properties to indicate the common high-speed modes too? The
Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
--
dwmw2
^ permalink raw reply
* [PATCH 1/2] Add 'sparse16550' to of_serial.c and handle 'reg-shift' property.
From: David Woodhouse @ 2007-07-07 16:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
Some boards have UARTs which are mostly compatible with a 16550, but
with registers spaced more widely. This isn't strictly compatible with
ns16550, so introduce a new 'compatible' type for it: sparse16550. The
'reg-shift' property indicates how far the registers are separated.
Also, reorder the match table to favour better modes if a device claims
compatibility with both 8250 and 16550, for example.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 7ffdaea..6ae1b5e 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -25,12 +25,13 @@ 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;
+ const unsigned int *clk, *spd, *rs;
int ret;
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
clk = of_get_property(np, "clock-frequency", NULL);
+ rs = of_get_property(np, "reg-shift", NULL);
if (!clk) {
dev_warn(&ofdev->dev, "no clock-frequency property set\n");
return -ENODEV;
@@ -48,6 +49,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->iotype = UPIO_MEM;
port->type = type;
port->uartclk = *clk;
+ if (rs)
+ port->regshift = *rs;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
@@ -111,11 +114,12 @@ static int of_platform_serial_remove(struct of_device *ofdev)
* A few common types, add more as needed.
*/
static struct of_device_id __devinitdata of_platform_serial_table[] = {
- { .type = "serial", .compatible = "ns8250", .data = (void *)PORT_8250, },
- { .type = "serial", .compatible = "ns16450", .data = (void *)PORT_16450, },
- { .type = "serial", .compatible = "ns16550", .data = (void *)PORT_16550, },
- { .type = "serial", .compatible = "ns16750", .data = (void *)PORT_16750, },
- { .type = "serial", .data = (void *)PORT_UNKNOWN, },
+ { .type = "serial", .compatible = "sparse16550", .data = (void *)PORT_16550, },
+ { .type = "serial", .compatible = "ns16750", .data = (void *)PORT_16750, },
+ { .type = "serial", .compatible = "ns16550", .data = (void *)PORT_16550, },
+ { .type = "serial", .compatible = "ns16450", .data = (void *)PORT_16450, },
+ { .type = "serial", .compatible = "ns8250", .data = (void *)PORT_8250, },
+ { .type = "serial", .data = (void *)PORT_UNKNOWN, },
{ /* end of list */ },
};
--
dwmw2
^ permalink raw reply related
* [PATCH 2/2] Add 'sparse16550' support to PowerPC bootwrapper
From: David Woodhouse @ 2007-07-07 16:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
The bootwrapper already handles a 'reg-shift' property on serial ports
and does the right thing. However, these ports really shouldn't be
claiming to be compatible with 'ns16550'. Introduce a new 'sparse16550'
type for them instead.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 7fd3233..6d9f3f8 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -123,7 +123,7 @@ int serial_console_init(void)
if (getprop(devp, "compatible", compat, sizeof(compat)) < 0)
goto err_out;
- if (!strcmp(compat, "ns16550"))
+ if (!strcmp(compat, "ns16550") || !strcmp(compat, "sparse16550"))
rc = ns16550_console_init(devp, &serial_cd);
else if (!strcmp(compat, "marvell,mpsc"))
rc = mpsc_console_init(devp, &serial_cd);
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Sergei Shtylyov @ 2007-07-07 17:07 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1183827083.3066.64.camel@shinybook.infradead.org>
Hello.
David Woodhouse wrote:
>>Given the existence of the boards, it looks correct to do this.
>>However, I wonder if it was correct for the MV64660 to claim
>>compatibily witn ns16550 if the programming model is not exactly
>>the same. The official OF serial port bindings don't mention the
>>reg-shift property, so it maybe would have been better to have
I'd preferred "reg-stride" or "reg-size" but see below...
>>a different value for the "compatible" property, in order not
>>to confuse existing operating systems that implement the standard.
> Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
Erm, wouldn't it be *too* generic approach? I'd suggest to name the
device with its own name and make of_serial.c recognize it and register with
8250.c as needed.
> the reg-shift property. I'll send a patch shortly, and I'll reorder the
> match table -- if something claims compatibility with both 8250 and
> 16550, shouldn't we drive it as the latter?
Certainly. BTW, was there really "ns8250" -- 8250 is Intel's chip?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Arnd Bergmann @ 2007-07-07 17:52 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Woodhouse, paulus
In-Reply-To: <468FC849.20801@ru.mvista.com>
On Saturday 07 July 2007, Sergei Shtylyov wrote:
> > the reg-shift property. I'll send a patch shortly, and I'll reorder the
> > match table -- if something claims compatibility with both 8250 and
> > 16550, shouldn't we drive it as the latter?
>=20
> =A0 =A0 Certainly. BTW, was there really "ns8250" -- 8250 is Intel's chip?
>=20
No, you're right. http://playground.sun.com/1275/proposals/Closed/Accepted/=
384-it.txt
actually mentions that the the name should be "i8250". It also mentions
that the compatible property should contain "pnpPNP,501" for ns16450 and=20
higher, and "pnpPNP,500" for all serial ports starting from i8250.
Arnd <><
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Arnd Bergmann @ 2007-07-07 17:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, David Woodhouse
In-Reply-To: <1183827083.3066.64.camel@shinybook.infradead.org>
On Saturday 07 July 2007, David Woodhouse wrote:
> Can we add properties to indicate the common high-speed modes too? The
> Natsemi baud-base thing could be autodetected by 8250.c if you'd let it,
> but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
Yes, that sounds good. I do not have enough understanding about the
extra feature to know which ones should get detected with their own
property, so I left that out for the next person that needs it...
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Sergei Shtylyov @ 2007-07-07 18:15 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707094852.9473.21013.stgit@localhost.localdomain>
Hello.
Vitaly Bordug wrote:
> This adds support for MMIO IDE device like CompactFlash
> in TrueIDE mode.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
[...]
> diff --git a/drivers/ide/legacy/mmio-ide.c b/drivers/ide/legacy/mmio-ide.c
> new file mode 100644
> index 0000000..77fb7dd
> --- /dev/null
> +++ b/drivers/ide/legacy/mmio-ide.c
[...]
> + hwif->mmio = 2;
That hwif->mmio is single-bit field now, so can only be 0 or 1.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Arnd Bergmann @ 2007-07-07 18:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide, linux-kernel
In-Reply-To: <468FC4AC.9030701@ru.mvista.com>
On Saturday 07 July 2007, Sergei Shtylyov wrote:
> Arnd Bergmann wrote:
>
> >>This adds support for MMIO IDE device like CompactFlash
> >>in TrueIDE mode.
>
> >>Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >>Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
> > Hmm, are we still adding new IDE drivers? Do you also have a
>
> Yes, why not?
The last time someone (I think Akira Iguchi) wanted to add
a new powerpc specific IDE driver, that was rejected based
on the argument that drivers/ide/ is going away soon. Most
current distros have already moved over to using libata
exclusively.
> > about to add the electra_ide.c driver in 2.6.23, I guess there
> > should really be _one_ driver that is able to handle all
> > of_device based ATA hosts.
>
> One driver to rule them all. :-)
> That may be not so simple as it seems...
It's certainly not easy to support all ATA chips that
have special capabilities and bugs, but the electra and the
mpc8349-itx both seem to support only the most basic ATA
PIO mode anyway, which does not require much special
handling beyond finding the right mmio addresses.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Sergei Shtylyov @ 2007-07-07 18:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b77c4b3dd22795a73cd32a0623722e51@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>+ isa@f0 {
> isa@1e
>>>+ 8042@60 {
>>>+ device_type = "8042";
> Drop the device_type. A number as a name isn't
> all that great, either.
Yet it's kinda accepted years ago, see:
http://playground.sun.com/1275/proposals/Closed/Accepted/381-it.txt
Ugh, it's hard to find these documents... All "name", "device_type", and
"compatible" must all be "8042".
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Arnd Bergmann @ 2007-07-07 18:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <468FDB8F.4050007@ru.mvista.com>
On Saturday 07 July 2007, Sergei Shtylyov wrote:
> =A0 =A0Yet it's kinda accepted years ago, see:
>=20
> http://playground.sun.com/1275/proposals/Closed/Accepted/381-it.txt
>=20
> =A0 =A0 Ugh, it's hard to find these documents... All "name", "device_typ=
e", and=20
> "compatible" must all be "8042".
>=20
Right. I've just checked an OF based machine that has 8042 keyboard
controller (the OLPC laptop), to see what's in there.
Here, we have=20
8042@i60 {
device_type =3D "8042";
reg =3D <1 60 1 1 64 1>;
interrupts <1 3 c 3>;
/* no interrupt-parent, this gets inherited from ISA node */
model =3D "INT,80c42";
compatible =3D "ps2-keyboard-controller" "INTC,80c42";
name =3D "8042"
#size-cells <0>;
#address-cells <1>;
mouse@aux {
reg =3D <1>;
compatible =3D "pnpPNP,f03";
device_type =3D "mouse";
name =3D "mouse";
}
keyboard@ {
reg =3D <0>;
language =3D "EN";
keyboard-type =3D "us";
device-type =3D "keyboard";
compatible =3D "pnpPNP,303";
name =3D "keyboard";
}
}
My interpretation of the document you cited is that the #size-cells and
#address-cells as well as the child nodes are actually required by the
standard, but it seems that Linux doesn't care.
The model and compatible properties in the 8042 node are not standard
compliant in my machine, so I'm not sure what to best put in there.
It is very clear on name and device-type though.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Sergei Shtylyov @ 2007-07-07 18:59 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1179246470.8132.112.camel@rhino>
Wade Farnsworth wrote:
> This adds device nodes for the ISA devices on the MPC8641 HPCN to the
> dts. Additionally, it moves the node for the i8259 to the isa bus,
> since the i8259 is actually on that bus.
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
Sorry for the belated comments... :-<
> Index: linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> ===================================================================
> --- linux-2.6-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ linux-2.6-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -285,17 +285,45 @@
> f800 0 0 3 &i8259 0 0
> f800 0 0 4 &i8259 0 0
> >;
> - i8259: i8259@4d0 {
> - clock-frequency = <0>;
> - interrupt-controller;
> - device_type = "interrupt-controller";
> - #address-cells = <0>;
> +
> + isa@f0 {
> + device_type = "isa";
> #interrupt-cells = <2>;
> - built-in;
> - compatible = "chrp,iic";
> - big-endian;
> - interrupts = <49 2>;
> - interrupt-parent = <&mpic>;
> + #size-cells = <1>;
> + #address-cells = <2>;
> + reg = <f000 0 0 0 0>;
> + ranges = <1 0 01000000 0 0 00001000>;
> + interrupt-parent = <4d0>;
> +
> + 8042@60 {
> + device_type = "8042";
> + reg = <1 60 1 1 64 1>;
What does that leading 1 in the address signify?
> + interrupts = <1 3 c 3>;
> + interrupt-parent = <4d0>;
> + };
> +
> + rtc@70 {
> + device_type = "rtc";
> + reg = <1 70 2>;
> + };
> +
> + gpio@400 {
> + device_type = "gpio";
> + reg = <1 400 80>;
> + };
> +
> + i8259: i8259@4d0 {
> + clock-frequency = <0>;
I don't think it's at all applicable here.
> + interrupt-controller;
> + device_type = "interrupt-controller";
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + built-in;
> + compatible = "chrp,iic";
> + big-endian;
Really?
> + interrupts = <49 2>;
> + interrupt-parent = <&mpic>;
> + };
The "reg" property is missing here. And "reserved-interrupts" accordig to:
http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
BTW, I've found the offisial 8042 binding is here:
http://playground.sun.com/1275/bindings/devices/html/8042.html
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 00/11] dtc: some fixes, and make asm labels for data
From: Jon Loeliger @ 2007-07-07 19:24 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <dtc-5-00.miltonm@bga.com>
So, like, the other day Milton Miller mumbled:
> The following series adds the features of labeling memory reserve
> slots and labeling specific bytes or cells of property data. When
> translating from dts to asm, a global symbol is created with the
> name matching the label in the dts file.
Milton,
I applied the whole lot.
Minor English typo corrections in commit log messages.
Also, I added two patches on top of these to reorganize
the Makefile into a better top-down layout and added
some Version string support, borrowed almost verbatim
from the Linux Makefiles. We're going to arbitrarily
start with 1.0.0 unless someone has a good argument for
something else!
And, for those keeping track, my "To Do" list here still
contains the notion of breaking the booting-without-of.txt
file into two parts. The technical descriptions of the DTC
and its file (blob) layout will move to the DTC repository
while the descriptions of nodes and properties will remain
in the kernel repository.
Let me know what you think...
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Arnd Bergmann @ 2007-07-07 19:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <468FE27F.4090105@ru.mvista.com>
T24gU2F0dXJkYXkgMDcgSnVseSAyMDA3LCBTZXJnZWkgU2h0eWx5b3Ygd3JvdGU6Cj4gPiAroKCg
oKCgoKCgoKCgoKCgoKCgoKCgaXNhQGYwIHsKPiA+ICugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoGRldmljZV90eXBlID0gImlzYSI7Cj4gPiCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKAjaW50ZXJydXB0LWNlbGxzID0gPDI+Owo+ID4gLaCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgYnVpbHQtaW47Cj4gPiAtoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBjb21wYXRpYmxl
ID0gImNocnAsaWljIjsKPiA+IC0goCCgIKAgoCCgIKAgoCCgoKCgoKAgoCCgIKAgoGJpZy1lbmRp
YW47Cj4gPiAtoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBpbnRlcnJ1cHRzID0gPDQ5IDI+
Owo+ID4gLaCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgaW50ZXJydXB0LXBhcmVudCA9IDwm
bXBpYz47Cj4gPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAjc2l6ZS1jZWxscyA9IDwx
PjsKPiA+ICugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCNhZGRyZXNzLWNlbGxzID0gPDI+
Owo+ID4gK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgcmVnID0gPGYwMDAgMCAwIDAgMD47
Cj4gPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKByYW5nZXMgPSA8MSAwIDAxMDAwMDAw
IDAgMCAwMDAwMTAwMD47Cj4gPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBpbnRlcnJ1
cHQtcGFyZW50ID0gPDRkMD47Cj4gPiArCj4gPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKA4MDQyQDYwIHsKPiA+ICugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgZGV2
aWNlX3R5cGUgPSAiODA0MiI7Cj4gPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoHJlZyA9IDwxIDYwIDEgMSA2NCAxPjsKPiAKPiCgIKAgV2hhdCBkb2VzIHRoYXQgbGVhZGlu
ZyAxIGluIHRoZSBhZGRyZXNzIHNpZ25pZnk/CgpJdCBzaWduaWZpZXMgYW4gSS9PIHBvcnQgYWRk
cmVzcyBpbnN0ZWFkIG9mIGFuIE1NSU8gYWRkcmVzcywgbm90ZSBob3cKPDEgNjA+IGlzIHRyYW5z
Zm9ybWVkIHRvIDwxMDAwMDAwIDAgNjA+IG9uIFBDSSwgd2hpY2ggaXMgdHJhbnNmb3JtZWQKdG8g
bW1pbyBhZGRyZXNzIDxlMjAwMDAwMCA2MD4gaW4gdGhlIGhvc3QgdGhyb3VnaCB0aGUgdmFyaW91
cyByYW5nZXMKcHJvcGVydGllcy4KCglBcm5kIDw+PAo=
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Alan Cox @ 2007-07-07 20:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-ide, linuxppc-dev, linux-kernel
In-Reply-To: <200707071419.52650.arnd@arndb.de>
> You could also make it an of_platform_driver at the same time
> instead of adding more cruft to fsl_soc.c. Since we're already
> about to add the electra_ide.c driver in 2.6.23, I guess there
> should really be _one_ driver that is able to handle all
> of_device based ATA hosts.
and do so using libata. Preferably ata_platform but it does look like
ata_of would make sense as a companion.
Alan
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Alan Cox @ 2007-07-07 20:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707094852.9473.21013.stgit@localhost.localdomain>
On Sat, 07 Jul 2007 13:48:52 +0400
Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> This adds support for MMIO IDE device like CompactFlash
> in TrueIDE mode.
Really we should be working towards libata support for all new devices.
This looks like a candidate for the existing (or a little enhanced)
pata_platform driver.
> +config BLK_DEV_MMIOIDE
> + tristate "Memory Mapped IDE support"
Please pick a better description. This isn't a generic option for
enabling MMIO based IDE as you make it sound.
Also we have an accepted match name for ATA platform devices - and adding
another one messes it up irrespective of whether you want libata or
legacy IDE support. If you use the same matches then your platform code,
and everyone elses platform code can work with both drivers, except for
hotpluggability.
Other bugs
- Your remove code releases the resources before the hwif which means it
races another user trying to claim the resource
- Be careful with ide_unregister. It exists and you can call it but its
actually not very safe and there are lots of unfixed races in the IDE
layer if you do
The "should we have a legacy ide driver that matches the libata
pata_platform" question I don't really care about. Its a waste of effort
in many ways but if you've written the code the work is done so why not
use it.
However it needs to be *compatible* so that platform devices can be
claimed by either so the kernel build can pick legacy IDE v libata and
not have to #ifdef all the platform code.
Alan
^ permalink raw reply
* Re: [PATCH] pseries: Re: Minor: Removed double return.
From: Manish Ahuja @ 2007-07-07 20:26 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev
In-Reply-To: <20070706225826.GE4457@austin.ibm.com>
Ah yes, my mistake. Does it require a repost then ?
Thanks,
Manish
Linas Vepstas wrote:
> You want to say its a patch in the subject line.
>
> --linas
>
> On Fri, Jul 06, 2007 at 04:59:55PM -0500, Manish Ahuja wrote:
>
>> Found 2 instances of return one right after each other in
>> arch_add_memory(). This minor patch fixes it.
>> Signed-off-by:Manish Ahuja <mahuja@us.ibm.com>
>>
>>
>>
>
>
>> Index: 2.6.22-rc4/arch/powerpc/mm/mem.c
>> ===================================================================
>> --- 2.6.22-rc4.orig/arch/powerpc/mm/mem.c 2007-06-11 21:10:46.000000000 -0500
>> +++ 2.6.22-rc4/arch/powerpc/mm/mem.c 2007-06-29 22:52:42.000000000 -0500
>> @@ -129,8 +129,6 @@
>> zone = pgdata->node_zones;
>>
>> return __add_pages(zone, start_pfn, nr_pages);
>> -
>> - return 0;
>> }
>>
>> /*
>>
>
>
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Segher Boessenkool @ 2007-07-07 22:06 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1183827083.3066.64.camel@shinybook.infradead.org>
> Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
> the reg-shift property. I'll send a patch shortly, and I'll reorder
> the
> match table -- if something claims compatibility with both 8250 and
> 16550, shouldn't we drive it as the latter?
>
> Can we add properties to indicate the common high-speed modes too? The
> Natsemi baud-base thing could be autodetected by 8250.c if you'd
> let it,
> but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
So just use "compatible" = "smsc,blablabla". Your device
has extra features over a 16550, namely that extra multiplier
or whatever; so just match those new features from the device
name (i.e., "compatible" property), don't try to retrofit those
features onto an existing driver.
And don't make up names for devices (like "sparse16550") unless
you really really have to, it definitely isn't needed here.
For your new device name, you can either have the register
spacing an implicit property of the device, or you can put
it in a "reg-shift" property if you want.
Segher
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Segher Boessenkool @ 2007-07-07 22:12 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Woodhouse, Arnd Bergmann, paulus
In-Reply-To: <468FC849.20801@ru.mvista.com>
>>> Given the existence of the boards, it looks correct to do this.
>>> However, I wonder if it was correct for the MV64660 to claim
>>> compatibily witn ns16550 if the programming model is not exactly
>>> the same. The official OF serial port bindings don't mention the
>>> reg-shift property, so it maybe would have been better to have
>
> I'd preferred "reg-stride" or "reg-size" but see below...
It is not the register size. "Register spacing" is the most
common name I believe, but "register shift" is nicer for
computer programs.
>>> a different value for the "compatible" property, in order not
>>> to confuse existing operating systems that implement the standard.
>
>> Ok, how about 'sparse16550'? Otherwise identical to ns16550, but with
>
> Erm, wouldn't it be *too* generic approach? I'd suggest to
> name the
> device with its own name and make of_serial.c recognize it and
> register with
> 8250.c as needed.
Yes, name the device by its real name, *please*.
>> the reg-shift property. I'll send a patch shortly, and I'll
>> reorder the
>> match table -- if something claims compatibility with both 8250 and
>> 16550, shouldn't we drive it as the latter?
>
> Certainly. BTW, was there really "ns8250" -- 8250 is Intel's chip?
It should be "i8250" yes. Not that you'd ever find any anymore
of course. And in many cases, it should be "pnpPNP,xxx" anyway.
Segher
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Segher Boessenkool @ 2007-07-07 22:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, David Woodhouse, paulus
In-Reply-To: <200707071952.44524.arnd@arndb.de>
> No, you're right. http://playground.sun.com/1275/proposals/Closed/
> Accepted/384-it.txt
> actually mentions that the the name should be "i8250". It also
> mentions
> that the compatible property should contain "pnpPNP,501" for
> ns16450 and
> higher,
16550 and higher
> and "pnpPNP,500" for all serial ports starting from i8250.
Yup.
Segher
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Segher Boessenkool @ 2007-07-07 22:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, David Woodhouse
In-Reply-To: <200707071955.07910.arnd@arndb.de>
>> Can we add properties to indicate the common high-speed modes too?
>> The
>> Natsemi baud-base thing could be autodetected by 8250.c if you'd
>> let it,
>> but the SMSC trick just has to be set as a UPF_MAGIC_MULTIPLIER flag.
>
> Yes, that sounds good. I do not have enough understanding about the
> extra feature to know which ones should get detected with their own
> property, so I left that out for the next person that needs it...
Since these devices will work (just not with the extra-high
baudrates) when driven as a "standard" 16550, you can indeed
just add a property to declare the device supports this stuff.
But please also declare the device to be such a special device
in its "compatible" property. So you end up with something like
serial@i3f8
{
reg = <1 3f8>;
device_type = "serial";
compatible = "smsc,12345", "ns16550a", "pnpPNP,501";
clock-frequency = 1843200;
smsc-multipliers; # <--- there's the new thing
}
Segher
^ permalink raw reply
* Re: [PATCH] Handle reg-shift property for of_serial ports
From: Segher Boessenkool @ 2007-07-07 22:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, David Woodhouse, paulus
In-Reply-To: <200707071410.14998.arnd@arndb.de>
>> The MV64660 has reg-shift==2 for its otherwise 16550-compatible
>> uarts.
>> While the bootwrapper copes with this, of_serial.c doesn't. (The udbg
>> code doesn't either, but I'll fix that later).
>>
>> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
So let me just say NAK so this doesn't accidentally get
applied :-)
Segher
^ permalink raw reply
* Re: [PATCH] Add USB support to mpc8349-mitx board port
From: John Rigby @ 2007-07-08 0:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, leoli, paulus, Timur Tabi, Arnd Bergmann
In-Reply-To: <fa686aa40707062246j71a347acje8559b7b6be9d38b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]
On 7/6/07, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> On 7/6/07, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Saturday 07 July 2007, Grant Likely wrote:
> > > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > @@ -63,6 +63,8 @@ static void __init mpc834x_itx_setup_arch(void)
> > >
> > > ppc_md.pci_exclude_device = mpc83xx_exclude_device;
> > > #endif
> > > +
> > > +mpc834x_usb_cfg();
> > > }
> >
> > Why is that necessary? Shouldn't there be an of_platform_driver that
> > simply does all the setup automatically if the device is present?
>
> This call is actually for SoC setup stuff. There are actually 2 USB
> engines on the SoC, and this call figures out what mode the pins are
> supposed to be in. I think this stuff firmly falls into the platform
> setup arena since it is highly chip specific.
>
> You bring up a good point though. The current usb support code in
> sysdev/fsl_soc.c uses arch_initcall(fsl_usb_of_init) to go searching
> for USB interfaces in the device tree, which are EHCI (and sometimes
> OTG) compatible. fsl_usb_of_init calls
> platform_device_register_simple() for each USB device found which is
> kind of a round about way of doing things. That should probably be
> depreciated and an of_platform_device binding should be added to the
> EHCI driver.
>
> This same comment probably goes for the other arch_initcall functions
> in fsl_soc.c which do exactly the same thing for other devices.
This depends, some devices in fsl_soc.c may exist on non-powerpc SoCs
that do not have OF. The USB core in 8349 for example also is in the
arm based mx27 and mx31. These devices should remain platform devices
and the glue in fls_soc.c will continure to be needed.
Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 2887 bytes --]
^ permalink raw reply
* Re: [PATCH] Add USB support to mpc8349-mitx board port
From: Grant Likely @ 2007-07-08 0:48 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev, leoli, paulus, Timur Tabi, Arnd Bergmann
In-Reply-To: <4b73d43f0707071734yeedd7e6g53101d45fbec899e@mail.gmail.com>
On 7/7/07, John Rigby <jcrigby@gmail.com> wrote:
> > This same comment probably goes for the other arch_initcall functions
> > in fsl_soc.c which do exactly the same thing for other devices.
>
> This depends, some devices in fsl_soc.c may exist on non-powerpc SoCs
> that do not have OF. The USB core in 8349 for example also is in the
> arm based mx27 and mx31. These devices should remain platform devices
> and the glue in fls_soc.c will continure to be needed.
I disagree; the current method is "glue for the glue". There is no
reason why the driver cannot have two bindings; one for
platform_device and one for of_platform_device. It's about the same
amount of code, but uses less indirection for the device tree case.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Benjamin Herrenschmidt @ 2007-07-08 0:54 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide, linux-kernel, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20070707210234.6aed88bb@the-village.bc.nu>
On Sat, 2007-07-07 at 21:02 +0100, Alan Cox wrote:
> > You could also make it an of_platform_driver at the same time
> > instead of adding more cruft to fsl_soc.c. Since we're already
> > about to add the electra_ide.c driver in 2.6.23, I guess there
> > should really be _one_ driver that is able to handle all
> > of_device based ATA hosts.
>
> and do so using libata. Preferably ata_platform but it does look like
> ata_of would make sense as a companion.
I wouldn't push for it too much tho. It's perfectly fine to have
"helpers" generate xx_platform from the device-tree. Since I added the
generic dev_archdata to struct device, it's easy for the arch to keep
track of OF devices for anything, it doesn't have to be an of_platform
device or anything like that anymore.
One of the things I have in mind is to provide a way to register
"constructors" that are based on an OF match set. Those would then be
called by the arch code for every OF node that matches, and would then
"construct" the appropriate linux device. Could be some kind of platform
device, could even be PCI devs.
Ben.
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Segher Boessenkool @ 2007-07-08 13:13 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <468FDB8F.4050007@ru.mvista.com>
>>>> + 8042@60 {
>>>> + device_type = "8042";
>
>> Drop the device_type. A number as a name isn't
>> all that great, either.
>
> Yet it's kinda accepted years ago, see:
>
> http://playground.sun.com/1275/proposals/Closed/Accepted/381-it.txt
That's not a published recommendation or anything like that.
Segher
^ 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