* Re: [patch 01/35] pasemi: rename platform
From: Olof Johansson @ 2007-07-09 0:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070709095259.0720669b.sfr@canb.auug.org.au>
On Mon, Jul 09, 2007 at 09:52:59AM +1000, Stephen Rothwell wrote:
> On Thu, 05 Jul 2007 12:02:34 -0500 Olof Johansson <olof@lixom.net> wrote:
> >
> > Rename the pasemi platform to "pasemi" to be in line with the platforms
> > directory name.
>
> This should also fix a problem further up in that file (in
> pasemi_publish_devices) where we check for "machine_is(pasemi)".
Yup, that's how I discovered the machine name being less than intuitive.
-Olof
^ permalink raw reply
* Re: [patch 01/35] pasemi: rename platform
From: Stephen Rothwell @ 2007-07-08 23:52 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070705170233.671358000@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
On Thu, 05 Jul 2007 12:02:34 -0500 Olof Johansson <olof@lixom.net> wrote:
>
> Rename the pasemi platform to "pasemi" to be in line with the platforms
> directory name.
This should also fix a problem further up in that file (in
pasemi_publish_devices) where we check for "machine_is(pasemi)".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Segher Boessenkool @ 2007-07-08 23:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200707082236.36722.arnd@arndb.de>
>>>>>> + 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.
>
> But still, it's what got used in what appears to be all ISA based
> machines
> with such a keyboard controller, both PowerPC and i386 ones.
For PowerPC, I only know about CHRP, which has its own binding
for 8042. For i386 I think you refer to the OLPC? It does _not_
comply with this #381 (it has a different unit address text
representation, for one thing). Also, it has "ps2-interrupt-controller"
in its "compatible" property, which is a much nicer thing to match
drivers on for the OS.
> Are you suggesting that we should declare all existing machines
> wrong and do
> our own thing instead?
You can read in my words whatever you want, but the only thing
I suggested was what I wrote: drop the device_type. It is
completely useless in a flat device tree whatever binding you
follow here.
And put something more useful than a bare number in the "compatible"
property. If you feel you really need to you can _also_ put the
number there, but I think you'll find you don't really want to.
And the "name" should be "keyboard-controller" or something like
that, following the generic names recommended practice.
I would argue the 8042 node shouldn't have a device_type at all
btw, since there is no defined effect of "open"ing this node; but
that is a completely separate discussion.
Segher
^ permalink raw reply
* Re: [PATCH 2/5] Add legacy devices to mpc8641_hpcn.dts
From: Arnd Bergmann @ 2007-07-08 20:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <3D4AB802-A3D2-46CC-9BD1-1064EE0AC84C@kernel.crashing.org>
On Sunday 08 July 2007, Segher Boessenkool wrote:
> >>>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A08042@60 {
> >>>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0device_type =3D "8042";
> >
> >> Drop the device_type. =A0A number as a name isn't
> >> all that great, either.
> >
> > =A0 Yet it's kinda accepted years ago, see:
> >
> > http://playground.sun.com/1275/proposals/Closed/Accepted/381-it.txt
>=20
> That's not a published recommendation or anything like that.
>=20
But still, it's what got used in what appears to be all ISA based machines
with such a keyboard controller, both PowerPC and i386 ones.
Are you suggesting that we should declare all existing machines wrong and do
our own thing instead?
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Bartlomiej Zolnierkiewicz @ 2007-07-08 13:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <200707072007.10448.arnd@arndb.de>
Hi,
On Saturday 07 July 2007, Arnd Bergmann wrote:
> 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
linux/drivers/ide/pci/scc_pata.c
New IDE host drivers are still fine.
> on the argument that drivers/ide/ is going away soon. Most
> current distros have already moved over to using libata
> exclusively.
The in-kernel default for PATA systems is still IDE subsystem.
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Segher Boessenkool @ 2007-07-08 13:31 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <468FC376.2040405@ru.mvista.com>
>> + ide@10000000 {
>> + #interrupt-cells = <2>;
>
> Hm, why define that prop for a node with no children?
>
>> + interrupts = <17 8>;
>> + interrupt-map = <0 0 0 1 700 17 8>;
>> + interrupt-map-mask = <0>;
This map-mask makes no sense either. And neither does
the map itself.
>> +
>> + #size-cells = <1>;
>> + #address-cells = <1>;
>
> Same question here.
The ide node might want children, namely disks or optical
drives or such, but #size-cells should be 0.
>> + reg = <10000000 10 10000200 10>;
>> +
>> + device_type = "ide";
>
> I think that already adopted device type is "ata", not "ide".
"ata" is not a hardware thing, "ide" is. Or so I'm told.
I'd leave out the "device_type" completely though, certainly
if you can't point me at a published device binding :-)
Segher
^ 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
* 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] 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] 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] 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] 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: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: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: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] 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 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 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 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 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: 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 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: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 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 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
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