* Re: [PATCH 01/11] [POWERPC] Add 'machine: ...' line to common show_cpuinfo()
From: Marian Balakowicz @ 2007-10-25 14:17 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20071023232303.GA10595@localhost.localdomain>
David Gibson wrote:
> On Wed, Oct 24, 2007 at 01:13:09AM +0200, Marian Balakowicz wrote:
>> Print out '/model' property as a machine name in generic
>> show_cpuinfo() routine.
>
> There's no such thing as /model; subnodes and properties have a
> different namespace, so the root node, /, has a property named
> 'model'.
>
> Yes, it's clear what you mean in this context, but it's a bad habit to
> get into.
Right, I'll try to make it more clear, thanks for pointing this out.
Cheers,
m.
^ permalink raw reply
* PCI on Lite5200/Icecube, known issues?
From: Wolfgang Grandegger @ 2007-10-25 14:20 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
The access to PCI memory space does not to work (I allways read 0xff) on
my Icecube-Eval-Board. Are there any known issues/bugs with using the
PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
realized, that CONFIG_PCI is not set in the default configuration.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Grant Likely @ 2007-10-25 14:21 UTC (permalink / raw)
To: Valentine Barshak; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <47208273.8050601@ru.mvista.com>
On 10/25/07, Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Grant Likely wrote:
> > On 10/24/07, David Brownell <david-b@pacbell.net> wrote:
> >> On Wednesday 24 October 2007, Matt Sealey wrote:
> >>> Can we just make sure real quickly that the changing of compatibles
> >>> doesn't break existing, not-easily-flashable firmwares?
> >> Yeah, I'm not keen on such breakage either...
> >
> > Add my voice to the chorus. It's okay to change the binding, but make
> > sure the old binding is still supported.
> >
> > Cheers,
> > g.
> >
>
> Actually, I thought that changing the DTS stuff for mpc52xx boards would
> suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
> bindings as well.
Even if that were the case; I'm nervous about breaking compatibility
with old device trees.
We probably need a formal guideline here. ie. When is it okay to drop
compatibility with old dts files?
> Does the device tree have "ohci-bigendian" or "ohci-be" compatible
> property on Efika?
If it doesn't, it can be added during prom_init.c We're already doing
a bunch of efika fixups there anyway.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ioctl32 unknown cmds with 2.6.24-rc1
From: Arnd Bergmann @ 2007-10-25 14:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, Johannes Berg
In-Reply-To: <Pine.LNX.4.62.0710251542500.3812@pademelon.sonytel.be>
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> If you want to look into this, the question is just why these messages are
> printed now, while they weren't printed before. I don't think any other
> behavior got changed.
I'm not so sure about that. The reason that the messages are printed now
is that there is no fallback handler for these ioctl numbers any more,
but they are instead expected to be handled by the compat_blkdev_ioctl()
function, which is only called for block devices.
My first idea was that the ioctl numbers are used on files that are
not block devices, in this case the warning message would be (somewhat)
appropriate.
Whenever we get one of these messages on a real block device, that is
supposed to mean that an ioctl that was actually valid could not be
executed, and compat_blkdev_ioctl() returned -ENOIOCTLCMD.
Arnd <><
^ permalink raw reply
* Re: USB Host Controller MPC875 Linux 2.6
From: hamed khateb @ 2007-10-25 14:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Can I accept the email address of Henrik , I would like to ask him about driver for USB Host Controlle for MPC8xx in linux 2.4
Best regards
Hamid
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RFS for PPC
From: vishnuvaradan vishnuvaradan @ 2007-10-25 14:36 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
Hi
I can able to find RFS for ppc in denx website
But that RFS does not support X windows
Any Pre-compiled RFS for ppc is available ?
or
Help me to create RFS including X window support for ppc
Regards
Vishnu
[-- Attachment #2: Type: text/html, Size: 248 bytes --]
^ permalink raw reply
* USB Host Controlle for MPC855/MPC8xx in linux 2.4?
From: hamed khateb @ 2007-10-25 14:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi
anyone has driver for USB Host Controlle for MPC855/MPC8xx in linux 2.4?
I read in the Archives mail which was sended by Henrik , Henrink use the driver of Brad Parker's for MPC875 (or MPC8xx) , so any one know how I can contact Henrik or Brad Parker's?
this is the link of the email of Henrik : http://ozlabs.org/pipermail/linuxppc-embedded/2007-October/028566.html
Best Regards
Hamid
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: libfdt: Documentation (patch the second)
From: Jon Loeliger @ 2007-10-25 14:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071025012731.GA24856@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Add documentation for another handful of libfdt functions to libfdt.h
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Grant Likely @ 2007-10-25 14:45 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4720A628.8010108@grandegger.com>
On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hello,
>
> The access to PCI memory space does not to work (I allways read 0xff) on
> my Icecube-Eval-Board. Are there any known issues/bugs with using the
> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
> realized, that CONFIG_PCI is not set in the default configuration.
arch/ppc or arch/powerpc?
I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
eth adapters plugged in and the devices are usable. This is a
2.6.24-rc1 arch/powerpc kernel.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] Add 'machine: ...' line to common show_cpuinfo()
From: Marian Balakowicz @ 2007-10-25 14:47 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <200710250433.l9P4XE8N038953@sullivan.realtime.net>
Milton Miller wrote:
> On Wed Oct 24 17:11:29 EST 2007, Stephen Rothwell wrote:
>> On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz wrote:
>>> + root = of_find_node_by_path("/");
>>> + if (root)
>>> + model = of_get_property(root, "model", NULL);
>>> + of_node_put(root);
>> The paranoid part of me says:
>>
>> if (model)
>>
>>> + seq_printf(m, "machine\t\t: %s\n", model);
>
> My thoughts too (don't fail if no model property in /), and that
> means that
>
>>> + const char *model = "";
>
> can change to
> + const char *model = NULL;
>
>
>
> However, a quick grep shows there are several platforms that print
> out machine\t\t: something in show_cpuinfo. Some are fixed strings
> (eg linkstation, holly, iSeries), some print model with a fallback
> (powermac), some augment the model (chrp, pseries, cell), some print
> something else (52xx/efika). There are others. All of those need
> to be dealt with or another tag chosen.
That's true, there is pretty wide range of different approaches. I
would opt for using a different tag and letting the platforms use
their custom machine string if they desire so. How about "model\t\t:
..."? It's not conflicting and self-explanatory too.
Cheers,
m.
^ permalink raw reply
* Re: libfdt: Remove un-const-safe fdt_set_header macro
From: Jon Loeliger @ 2007-10-25 14:49 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071025042938.GD24856@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The fdt_set_header() macro casts an arbitrary pointer into (struct
> fdt_header *) to set fdt header fields. While we need to change the
> type, so that we can use this macro on the usual (void *) used to
> represent a device tree blob, the current macro also casts away any
> const on the input pointer, which loses an important check.
>
> This patch replaces the fdt_set_header() macro with a set of inline
> functions, one for each header field which do a similar thing, but
> which won't silently remove const from a given pointer. This approach
> is also more in keeping with the individual accessor macros we use for
> reading fdt header fields.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: ioctl32 unknown cmds with 2.6.24-rc1
From: Geert Uytterhoeven @ 2007-10-25 14:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <200710251620.50218.arnd@arndb.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1797 bytes --]
On Thu, 25 Oct 2007, Arnd Bergmann wrote:
> On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> > If you want to look into this, the question is just why these messages are
> > printed now, while they weren't printed before. I don't think any other
> > behavior got changed.
>
> I'm not so sure about that. The reason that the messages are printed now
> is that there is no fallback handler for these ioctl numbers any more,
> but they are instead expected to be handled by the compat_blkdev_ioctl()
> function, which is only called for block devices.
>
> My first idea was that the ioctl numbers are used on files that are
> not block devices, in this case the warning message would be (somewhat)
> appropriate.
>
> Whenever we get one of these messages on a real block device, that is
> supposed to mean that an ioctl that was actually valid could not be
> executed, and compat_blkdev_ioctl() returned -ENOIOCTLCMD.
In many cases these ioctls can indeed not be handled.
E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
cache. But this ioctl is not supported, not before and not after 2.6.23.
Before 2.6.23, it didn't print the message, in 2.6.23, it does.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 02/11] [POWERPC] Add 'lpb' bus type for MPC5200 LocalPlus Bus
From: Marian Balakowicz @ 2007-10-25 14:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071024000941.GA10926@lixom.net>
Olof Johansson wrote:
>
> On Wed, Oct 24, 2007 at 01:13:15AM +0200, Marian Balakowicz wrote:
>> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
>> ---
>
> Your patch lacks any kind of description beyond the title. (I know, it's a
> real simple patch, but a real simple description would do too :)
All right, will add one.
>
>> --- a/arch/powerpc/kernel/of_platform.c
>> +++ b/arch/powerpc/kernel/of_platform.c
>> @@ -49,6 +49,7 @@ static struct of_device_id of_default_bus_ids[] = {
>> { .type = "plb4", },
>> { .type = "opb", },
>> { .type = "ebc", },
>> + { .type = "lpb", },
>
> I thought it was consensus to keep the new bus ids only in platform
> code and not add them to the default list, and just pass that list in
> to of_platform_bus_probe().
Sounds reasonable, will move it to the 5xxx platform code.
Cheers,
m.
^ permalink raw reply
* Re: libfdt: Test on trees with different block layouts
From: Jon Loeliger @ 2007-10-25 14:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071025050558.GE24856@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> At present, all the example dtbs we use in the testsuite are version
> 17 and have reservation map, then structure block then strings block
> (the natural ordering based on alignment constraints). However, all
> libfdt's read-only and in-place write functions should also work on
> v16 trees, and on trees with other layouts.
>
> This patch adds a testcase / utility function to rearrange the blocks
> of a dtb and/or regress a v17 tree to v16, and uses it to run tests on
> trees with different layouts and versions.
>
> Signed-off-by: David Gibson <david@tgibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Wolfgang Grandegger @ 2007-10-25 15:11 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40710250745i57f2a88sbc08478738ee382a@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Hello,
>>
>> The access to PCI memory space does not to work (I allways read 0xff) on
>> my Icecube-Eval-Board. Are there any known issues/bugs with using the
>> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
>> realized, that CONFIG_PCI is not set in the default configuration.
>
> arch/ppc or arch/powerpc?
>
> I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
> eth adapters plugged in and the devices are usable. This is a
> 2.6.24-rc1 arch/powerpc kernel.
I'm using a 2.6.23 arch/powerpc kernel. And my eepro100 card does not
work either:
e100: probe of 0000:00:18.0 failed with error -11
It looks like that 2.6.23 needs some more patches.
Thanks.
Wolfgang.
^ permalink raw reply
* Re: USB Host Controlle for MPC855/MPC8xx in linux 2.4?
From: Gerhard Jaeger @ 2007-10-25 14:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <741129.8675.qm@web55901.mail.re3.yahoo.com>
On Donnerstag, 25. Oktober 2007, hamed khateb wrote:
> Hi
>
> anyone has driver for USB Host Controlle for MPC855/MPC8xx in linux 2.4?
>
> I read in the Archives mail which was sended by Henrik , Henrink use the driver of Brad Parker's for MPC875 (or MPC8xx) , so any one know how I can contact Henrik or Brad Parker's?
>
> this is the link of the email of Henrik : http://ozlabs.org/pipermail/linuxppc-embedded/2007-October/028566.html
>
You might have a look here:
http://www.heeltoe.com/software/usb/usb.html
HTH
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: ioctl32 unknown cmds with 2.6.24-rc1
From: Arnd Bergmann @ 2007-10-25 15:19 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <Pine.LNX.4.62.0710251649520.3812@pademelon.sonytel.be>
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> In many cases these ioctls can indeed not be handled.
> E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
> cache. But this ioctl is not supported, not before and not after 2.6.23.
> Before 2.6.23, it didn't print the message, in 2.6.23, it does.
What I would expect to happen here is:
compat_blkdev_ioctl gets into the BLKFLSBUF case and calls blkdev_ioctl,
which calls blkdev_driver_ioctl, which returns -ENOTTY because
ps3disk_fops does not contain an unlocked_ioctl() or ioctl() method.
compat_sys_ioctl then detects that BLKFLSBUF was already handled by
compat_blkdev_ioctl (it did not return -ENOIOCTLCMD) and propagates
the error code to user space, without printing the message.
Whatever is different from that description must be what goes wrong.
Arnd <><
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-25 15:23 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20071024015115.GK10595@localhost.localdomain>
David Gibson wrote:
> On Wed, Oct 24, 2007 at 01:13:33AM +0200, Marian Balakowicz wrote:
>
> [snip]
>> + lpb@fc000000 {
>> + model = "fsl,lpb";
>> + compatible = "lpb";
>
> Not nearly specific enough. Must include a vendor prefix at least,
> and should have a lot more revision information. You should always be
> able to pick the right driver with compatible alone, "model" should
> generally be for human consumption, the driver shouldn't need it.
>
>> + device_type = "lpb";
>
> Drop this. Again, presence of a device_type property is the
> exception, not the rule.
>
>> + ranges = <0 fc000000 02000000>;
>
> You need #address-cells and #size-cells properties, too.
>
> [snip]
OK, will update that. I guess I'll also need to use 'compatible' and
skip type when passing bus ids to of_platform_bus_probe().
m.
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-25 15:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Martin Krause
In-Reply-To: <fa686aa40710250653o6e7df26y1890d5c485a6d508@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
>>
>> < + flash@00000000 {
>> < + compatible = "cfi-flash";
>> < + reg = <00000000 02000000>;
>> < + bank-width = <4>;
>> < + device-width = <2>;
>> < + #size-cells = <1>;
>> < + #address-cells = <1>;
>> < + partition@0 {
>> < + label = "firmware";
>> < + reg = <0 a0000>;
>> < + };
>> < + partition@a0000 {
>> < + label = "dtb";
>> < + reg = <a0000 20000>;
>> < + };
>> < + partition@c0000 {
>> < + label = "kernel";
>> < + reg = <c0000 240000>;
>> < + };
>> < + partition@300000 {
>> < + label = "initrd";
>> < + reg = <300000 200000>;
>> < + };
>> < + partition@500000 {
>> < + label = "small-fs";
>> < + reg = <500000 400000>;
>> < + };
>> < + partition@900000 {
>> < + label = "misc";
>> < + reg = <900000 800000>;
>> < + };
>> < + partition@1100000 {
>> < + label = "big-fs";
>> < + reg = <1100000 f00000>;
>> < + };
>> < + };
>> < + };
>>
>> This MTD layout only works on boards with 32 MiB (or 64 MiB) flash
>> memory. On TQM5200 boards with smaller Flashes (16 MiB, 8 MiB and 4 MiB)
>> the MTD partition borders do not match with the physikal memory borders.
>
> If there is a variant board with a different configuration, then the
> device tree needs to be changed for that variant board; either by
> having multiple .dts files in arch/powerpc/boot/dts or by having the
> bootloader populate the correct information. A dtb as passed to the
> kernel must exactly represent the hardware.
>
> That also means that there is going to be a different flash map for
> each possible flash size configuration.
Agree, that's one particular configuration (I guess I should add
proper comment), that should be updated if needed. But I'am not sure
if we should have multiple .dts files if it's only flash layout that
changes.
>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
>> partition could not be used. "big-fs", because the memory is too small
>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
>> flash border. So only the first 9 MiB of the flash could be used in Linux.
>> The remaining 7 MiB couldn't be accessed.
>
> Perhaps it would be better to drop the flash layout from the in-kernel
> dts files entirely since flash layout can be a fluid thing.
Well, but that would not be really user friendly, I'd rather stick
with some default config.
m.
^ permalink raw reply
* Re: [PATCH 09/11] [POWERPC] Motion-PRO: Add LED support.
From: Marian Balakowicz @ 2007-10-25 15:53 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710240718t202a8d14lab24f11e8d53e0eb@mail.gmail.com>
Grant Likely wrote:
...
>> +
>> +static int __init mpled_init(void)
>> +{
>> + int i, error;
>> +
>> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
>> + led[i].reg_addr = mpc52xx_find_and_map(led[i].reg_compat);
>
> Please use of-platform-bus bindings instead. Let the of-platform bus
> take care of scanning the tree for you. Don't do it manually.
Hm, let me try that instead, thanks for the suggestion.
Cheers,
m.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-25 16:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710242011y771d5cbbuaa1eb274672ccb48@mail.gmail.com>
Jon Smirl wrote:
> This could work. The generic codec is a alsa soc_device_driver, not a
> of_device_driver. The codec node could instantiate the fabric as a
> of_device_driver which could then instantiate the soc_device_driver
> for the generic codec.
>
> The generic codecs are supposed to work cross platform so they can't
> include code that munges the of device tree.
My understanding of ASoC is that the fabric driver is supposed to be OF-aware,
and the codec and other drivers are not. The other drivers have ASoC entry
points that the fabric driver calls to provide information.
Example:
Fabric driver:
static int mpc8610hpcd_startup(struct snd_pcm_substream *substream)
{
...
if (codec_dai->dai_ops.set_fmt) {
ret = codec_dai->dai_ops.set_fmt(codec_dai, machine_data->dai_format);
if (ret < 0) {
printk(KERN_ERR "mpc8610-hpcd: could not set codec "
"driver audio format (ret=%i)\n", ret);
return ret;
}
}
codec driver:
static int cs4270_set_dai_fmt(struct snd_soc_codec_dai *codec_dai,
unsigned int format)
{
...
switch (format & SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
case SND_SOC_DAIFMT_LEFT_J:
cs4270->mode = format & SND_SOC_DAIFMT_FORMAT_MASK;
break;
In my device tree, the I2S node specifies the interface (this node layout is
what I came up with 6 months ago when I started working on this.)
ssi@16000 {
compatible = "fsl,ssi";
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
/* This is probably not the right way to tell the
SSI driver how to configure the interface */
fsl,mode = "i2s-slave";
codec {
compatible = "cs4270";
};
};
The fabric driver reads "i2s-slave" and converts that to SND_SOC_DAIFMT_I2S.
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Wolfgang Grandegger @ 2007-10-25 16:21 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4720B218.80607@grandegger.com>
Wolfgang Grandegger wrote:
> Grant Likely wrote:
>> On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> Hello,
>>>
>>> The access to PCI memory space does not to work (I allways read 0xff) on
>>> my Icecube-Eval-Board. Are there any known issues/bugs with using the
>>> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
>>> realized, that CONFIG_PCI is not set in the default configuration.
>> arch/ppc or arch/powerpc?
>>
>> I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
>> eth adapters plugged in and the devices are usable. This is a
>> 2.6.24-rc1 arch/powerpc kernel.
>
> I'm using a 2.6.23 arch/powerpc kernel. And my eepro100 card does not
> work either:
>
> e100: probe of 0000:00:18.0 failed with error -11
>
> It looks like that 2.6.23 needs some more patches.
Indeed, it works with 2.6.24-rc1:
e100: eth0: e100_probe: addr 0xa0000000, irq 16, MAC addr 00:0e:0c:74:8c:f2
Wolfgang.
^ permalink raw reply
* Re: PCI on Lite5200/Icecube, known issues?
From: Grant Likely @ 2007-10-25 16:24 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4720C27B.7020408@grandegger.com>
On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Wolfgang Grandegger wrote:
> > Grant Likely wrote:
> >> On 10/25/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> >>> Hello,
> >>>
> >>> The access to PCI memory space does not to work (I allways read 0xff) on
> >>> my Icecube-Eval-Board. Are there any known issues/bugs with using the
> >>> PCI on the Lite5200/Icecube board with 2.6.23? Has it been tested? I
> >>> realized, that CONFIG_PCI is not set in the default configuration.
> >> arch/ppc or arch/powerpc?
> >>
> >> I'm not a PCI expert, but I just fired up my Lite5200 with a couple of
> >> eth adapters plugged in and the devices are usable. This is a
> >> 2.6.24-rc1 arch/powerpc kernel.
> >
> > I'm using a 2.6.23 arch/powerpc kernel. And my eepro100 card does not
> > work either:
> >
> > e100: probe of 0000:00:18.0 failed with error -11
> >
> > It looks like that 2.6.23 needs some more patches.
>
> Indeed, it works with 2.6.24-rc1:
>
> e100: eth0: e100_probe: addr 0xa0000000, irq 16, MAC addr 00:0e:0c:74:8c:f2
Okay, when I get a chance I'll try 2.6.23 on my lite5200
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-10-25 17:11 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <fa686aa40710250721m54dda956qe7c8986416d0dfa2@mail.gmail.com>
Grant Likely wrote:
> On 10/25/07, Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>> Grant Likely wrote:
>>> On 10/24/07, David Brownell <david-b@pacbell.net> wrote:
>>>> On Wednesday 24 October 2007, Matt Sealey wrote:
>>>>> Can we just make sure real quickly that the changing of compatibles
>>>>> doesn't break existing, not-easily-flashable firmwares?
>>>> Yeah, I'm not keen on such breakage either...
>>> Add my voice to the chorus. It's okay to change the binding, but make
>>> sure the old binding is still supported.
>>>
>>> Cheers,
>>> g.
>>>
>> Actually, I thought that changing the DTS stuff for mpc52xx boards would
>> suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
>> bindings as well.
>
> Even if that were the case; I'm nervous about breaking compatibility
> with old device trees.
If we keep the old bindings intact in the driver code then the old dts
files should work fine. But I'm starting to doubt we really need any new
bindings for this if we still have to keep the old ones.
BTW, does anybody know of any ohci-le devices on OF bus?
Thanks,
Valentine.
>
> We probably need a formal guideline here. ie. When is it okay to drop
> compatibility with old dts files?
>
>> Does the device tree have "ohci-bigendian" or "ohci-be" compatible
>> property on Efika?
>
> If it doesn't, it can be added during prom_init.c We're already doing
> a bunch of efika fixups there anyway.
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-25 18:01 UTC (permalink / raw)
To: Valentine Barshak; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <47208273.8050601@ru.mvista.com>
Compatible property on /builtin@F0000000/usb@F0001000 is
ohci-bigendian
ohci-be
mpc5200-ohci
mpc5200-usb
device_type is "usb", model is "mpc5200-ohci".
Although I worry about cluttering up the cleanup, it is probably just
adding an "if property(big-endian) OR compatible(mpc5200-ohci)"
to that small big-endian check there.
I am currently moving on the assumption that the "correct" device
tree for the Efika (notwithstanding the above) would be
usb@F0001000 {
device-type = "usb-ohci"
compatible = "mpc5200-ohci,mpc5200-usb-ohci"
big-endian
}
Or some variation including all the relevant checked-for
properties.
I don't like the old "ohci-bigendian" and "ohci-be" properties.
Picking out "ohci-bigendian" and "ohci-be" was someone's drunken
idea, I'm sure, so I am happy to let them die a horrible death
and never rear up ever again.
Using mpc5200-ohci out is by far the safest idea, although it
leaves in a rather platform-specific fix, I prefer singling out that
platform and potentially causing nasty looks towards the
direction of Genesi/bplan, than having ohci-bigendian continue
to exist for the sake of it :D
There is another solution; change the properties in the Linux
device tree fixups, but I would loathe that solution as it adds
yet another part of the kernel to track.
Unfortunately the current device tree is a complete, stupid mess,
a result of a bunch of guys not looking at the problem, and I
have said this before (rant mode :) - I think device_type,
compatible should report the KIND of device it is, and the model
property should be used to pick out the particular quirks of
the chipset. We could have had a nice system where "usb" is paired
with compatible "ohci", and model is "mpc5200". No dashes or
spaces or 10 strings to compare..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Valentine Barshak wrote:
> Grant Likely wrote:
>> On 10/24/07, David Brownell <david-b@pacbell.net> wrote:
>>> On Wednesday 24 October 2007, Matt Sealey wrote:
>>>> Can we just make sure real quickly that the changing of compatibles
>>>> doesn't break existing, not-easily-flashable firmwares?
>>> Yeah, I'm not keen on such breakage either...
>>
>> Add my voice to the chorus. It's okay to change the binding, but make
>> sure the old binding is still supported.
>>
>> Cheers,
>> g.
>>
>
> Actually, I thought that changing the DTS stuff for mpc52xx boards would
> suffice. Sorry, I was unaware of Efika firmware here. I'll keep old
> bindings as well.
> Does the device tree have "ohci-bigendian" or "ohci-be" compatible
> property on Efika?
> Thanks,
> Valentine.
^ 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