* Re: MPC8260ADS and linux-2.6
From: Scott Wood @ 2008-01-03 17:58 UTC (permalink / raw)
To: suja Baburaj; +Cc: linuxppc-embedded
In-Reply-To: <a3b98ac10801022105w240b0f96race4d3aa84e51f27@mail.gmail.com>
suja Baburaj wrote:
> I have an MPC8260ADS board with (eldk)linux-2.4.25 working fine on it.
> Now i want to try linux-2.6.X on the board.
There's no support for that specific board in mainstream 2.6 yet, but it
should be fairly simple to get it working using the mpc8272ads support
as an example.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 17:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910801020756p18e12ce8o618b8eae5e7c5a53@mail.gmail.com>
Jon Smirl wrote:
> For this model to work you need to split your driver. fsl-ssi and
> mpc8610_hpcd need to be in two separate drivers.
They are two separate drivers. sound/soc/fsl/fsl_ssi.c and
sound/soc/fsl/mpc8610_hpcd.c
> fsl-ssi is easy
> enough to load since it has a device tree entry.
>
> mpc8610_hpcd is the harder one to load since it doesn't have a device
> tree entry. What you want to do it match on the compatible field of
> the root node.
>
> static struct of_device_id fabric_of_match[] = {
> {
> .compatible = "fsl,MPC8610HPCD",
> },
> {},
> };
>
> But this doesn't work since the root is the device tree isn't passed
> down into the device probe code. (Could this be fixed?)
I don't understand that sentence. Is there a typo?
> Instead we could make the separated mpc8610_hpcd fabric driver attach
> to fsl,ssi.
>
> static struct of_device_id fabric_of_match[] = {
> {
> .compatible = "fsl,ssi",
> },
> {},
> };
>
> Then in it's probe code check for the right platform.
That's what I do. I attach to fsl,ssi, gather the information from the device
tree, and then call a private API to initialize the SSI driver.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 17:54 UTC (permalink / raw)
To: Jon Smirl; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <9e4733910801020734n115888cbt86351f67f2311629@mail.gmail.com>
Jon Smirl wrote:
> On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
>> Jon Smirl wrote:
>>> On 1/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
>>>> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
>>>>> + ssi@16000 {
>>>>> + compatible = "fsl,ssi";
>>>>> + cell-index = <0>;
>>>>> + reg = <16000 100>;
>>>>> + interrupt-parent = <&mpic>;
>>>>> + interrupts = <3e 2>;
>>>>> + fsl,mode = "i2s-slave";
>>>>> + codec {
>>>>> + compatible = "cirrus,cs4270";
>>>>> + /* MCLK source is a stand-alone oscillator */
>>>>> + bus-frequency = <bb8000>;
>>>>> + };
>>>>> + };
>>>> Does this need to be bus-frequency? It's always called MCLK in all of
>>>> the literature.
>>>>
>>>> In my case the MCLK comes from a chip on the i2c bus that is
>>>> programmable How would that be encoded?.
>>> Looking at the cs4270 codec driver it is controlled by i2c (supports
>>> SPI too). What happened to the conversation about putting codecs on
>>> the controlling bus and then linking them to the data bus?
>> The current CS4270 driver doesn't support device trees. When I wrote
>> it, the idea of putting I2C info in the device tree was not finalized,
>> and since the driver is supposed to be cross-platform, I decided to do
>> it the old-fashioned way. Before I update the code, however, I'm
>> waiting for:
>>
>> 1) The current code to be accepted into the tree
>> 2) ASoC is updated to V2
>> 3) The current drivers are updated to support ASoC V2.
>
> I've been trying to get the i2c code in for two months. Hopefully it
> will go in soon, no one had made any comments on it recently. Have you
> tried your code with it?
No. I don't like updating my patches with new features while they're
undergoing review. If something is clearly wrong with the patch, then I'll
fix it and resubmit. But I really don't like to support new stuff just
because it's there.
> There is nothing stopping your from putting a node for the CS4270 on
> the i2c bus today. It just won't trigger the loading of the driver.
Yes, the thing that's stopping me is that I don't want to do 20 things at
once. I already have pending patches that I'm trying to get in. Once those
are in, then I will consider additional work.
> Don't we want to follow the device tree policy of putting the device
> on the controlling bus and then link it to the data bus?
Normally, that sounds like a good idea, but the cs4270 is an I2S device first,
and an I2C device second. I need to be able to find that codec from the I2S
node. My I2S driver would not know to scan all I2C devices to find the codec.
> It makes it a little easier but it doesn't fix everything. We need to
> start looking at it since none of the example driver for it are device
> tree based.
I will look at it, *after* my current V1 driver has been applied to the tree.
> It still has problems with wanting 'struct
> platform_device' when we have 'struct of_platform_device' pointers. It
> also doesn't know how to dynamically load codecs based on device
> trees.
I agree that these things need to be fixed. I look forward to thinking about
these problems, *after* my V1 patches have been applied.
> Liam messed up all of my code when he refactored it in late December.
Bummer.
> I've switched over to the current SOC code for the moment. The big
> thing that v2 fixes is that SOC is changed to being a subsystem
> instead of platform driver. Being a subsystem is the correct model.
>
> It would be good if more pieces of v2 get push forward. Then we can
> sort out the device tree issues in it.
I agree.
> Adding the second device tree node doesn't have anything to do with
> ASOC v2. It's specific to powerpc and device trees.
Ok, but making my CS4270 driver device-tree aware is a completely separate
task from what this patchset is addressing.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-03 17:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, olof
In-Reply-To: <20080103173717.GA4287@loki.buserror.net>
On 1/3/08, Scott Wood <scottwood@freescale.com> wrote:
> On Wed, Jan 02, 2008 at 12:32:51PM -0700, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > arch/powerpc/platforms/8xx/ep88xc.c | 5 ++---
> > arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 ++---
>
> How about mpc86xads_setup.c?
Oops. I fixed that one too, but it's in the 8xxx patch by mistake.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/5] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
From: Scott Wood @ 2008-01-03 17:37 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, olof
In-Reply-To: <20080102193233.24178.74501.stgit@trillian.secretlab.ca>
On Wed, Jan 02, 2008 at 12:32:51PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/platforms/8xx/ep88xc.c | 5 ++---
> arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 ++---
How about mpc86xads_setup.c?
-Scott
^ permalink raw reply
* Re: File system problem
From: Grant Likely @ 2008-01-03 17:33 UTC (permalink / raw)
To: mojtaba; +Cc: linuxppc-embedded
In-Reply-To: <004901c84e2a$1cac5c70$56051550$@com>
On 1/3/08, mojtaba <kernelppc@gmail.com> wrote:
> Hi Jean-Samuel,
>
> Actually, I removed the console and null created by buildroot and create
> them manually using make node. This time the system freezes at this point.
> "Freeing unused kernel memory: 76k init"
It looks like your inittab is not setup correctly to me.
Do you have a /dev/ttyS0 device file? Is inittab trying to start a
getty process (getty allows you to log in.)
Try adding "init=/bin/sh" to your kernel boot parameters to prove that
userspace is working.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: File system problem
From: Grant Likely @ 2008-01-03 17:27 UTC (permalink / raw)
To: mojtaba; +Cc: linuxppc-embedded
In-Reply-To: <004801c84e21$59312760$0b937620$@com>
On 1/3/08, mojtaba <kernelppc@gmail.com> wrote:
> Hi,
> Thank you very much for your answers.
>
> But I have both console and null in /dev.
>
> -rw-rw-rw- 1 mojtaba mojtaba 0 2007-12-26 15:50 console
> -rw-rw-rw- 1 mojtaba mojtaba 0 2007-12-26 15:50 null
>
> They have been created by buildroot. Do I need to create them manually?
> Actually the size of both of them is 0 and both are empty files. Is that a
> problem?
They should look like this:
crw------- 1 root root 5, 1 2008-01-03 07:43 /dev/console
crw-rw-rw- 1 root root 1, 3 2007-10-08 18:39 /dev/null
They are not regular files. They are device files created with the
'mknod' command.
Instead of a size, these files have 2 number; the device major and
minor numbers. /dev/console uses major 5, minor 1. /dev/null is
major 1 minor 3.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Drivers' probe function calling order
From: DI BACCO ANTONIO - technolabs @ 2008-01-03 16:57 UTC (permalink / raw)
To: linuxppc-embedded
How can I fix the calling order of two monolithic drivers? I have an spi
driver and a driver for a dataflash, how can I force the system to call
probe function of the spi driver first?
=20
Bye and thanks.
^ permalink raw reply
* RE: File system problem
From: mojtaba @ 2008-01-03 17:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <169c03cb0801021932s6671526dve15d1948da52ae30@mail.gmail.com>
Hi Jean-Samuel,
Actually, I removed the console and null created by buildroot and create
them manually using make node. This time the system freezes at this =
point.
"Freeing unused kernel memory: 76k init"
loaded at: 00400000 004CE1A0 =20
board data at: 004CC120 004CC19C =20
relocated to: 0040405C 004040D8 =20
zimage at: 00404E94 004CB08A =20
avail ram: 004CF000 10000000 =20
Linux/PPC load: console=3DttyS0,9600 root=3D/dev/xsa2 init=3D/bin/sh
Uncompressing Linux...done. =20
Now booting the kernel =20
Linux version 2.6.24-rc3 (mojtaba@ubuntu2) (gcc version 4.2.2) #1 Wed =
Jan 2
14:3
7:58 CET 2008 =20
Xilinx ML300 Reference System (Virtex-II Pro)
Zone PFN ranges: =20
DMA 0 -> 65536 =20
Normal 65536 -> 65536 =20
HighMem 655 =20
Movable zone start PFN for each node =20
early_node_map[1] active PFN ranges =20
0: 0 -> 65536 =20
Built 1 zonelists in Zone order, mobility grouping on. Total pages: =
65024
Kernel command line: console=3DttyS0,9600 root=3D/dev/xsa2 =
init=3D/bin/sh
Xilinx INTC #0 at 0x41200000 mapped to 0xEF5FE000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25 =20
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 258048k available (1288k kernel code, 436k data, 76k init, 0k
highmem)
Mount-cache hash table entries: 512 =20
net_namespace: 64 bytes =20
NET: Registered protocol family 16 =20
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
Call Trace: =20
[cfc1fe20] [c0008148] show_stack+0x58/0x188 (unreliable)
[cfc1fe68] [c0038908] set_fail+0x50/0x68
[cfc1fe80] [c0038f7c] sysctl_check_table+0x65c/0x6ac
[cfc1fee8] [c0038f8c] sysctl_check_table+0x66c/0x6ac
[cfc1ff50] [c0026c58] register_sysctl_table+0x64/0xb4
[cfc1ff50] [c0026c58] register_sysctl_table+0x64/0xb4
[cfc1ff70] [c019b228] kernel_init+0x104/0x290
[cfc1fff0] [c0004af8] kernel_thread+0x44/0x60
io scheduler noop registered =20
io scheduler anticipatory registered =20
io scheduler deadline registered =20
io scheduler cfq registered (default) =
=20
Generic RTC Driver v1.07 =20
Macintosh non-volatile memory driver v1.1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing =
disabled
serial8250.0: ttyS0 at MMIO 0x40401003 (irq =3D 2) is a 16550A
console [ttyS0] enabled =20
xsysace xsysace.0: Xilinx SystemACE revision 1.0.12
xsysace xsysace.0: capacity: 1981728 sectors
xsa: xsa1 xsa2 xsa3 =20
Xilinx SystemACE device driver, major=3D254
i8042.c: No controller found. =20
mice: PS/2 mouse device common for all mice
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init =
=20
Warning: unable to open an initial console.
init has generated signal 11 but has no handler for it
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..<NULL> =20
loaded at: 00400000 004CE1A0 =20
board data at: 004CC120 004CC19C =20
relocated to: 0040405C 004040D8 =20
zimage at: 00404E94 004CB08A =20
avail ram: 004CF000 10000000 =20
Linux/PPC load: console=3DttyS0,9600 root=3D/dev/xsa2 init=3D/bin/sh
Uncompressing Linux...done. =20
Now booting the kernel =20
Linux version 2.6.24-rc3 (mojtaba@ubuntu2) (gcc version 4.2.2) #1 Wed =
Jan 2
14:3
7:58 CET 2008 =20
Xilinx ML300 Reference System (Virtex-II Pro)
Zone PFN ranges: =20
DMA 0 -> 65536 =20
Normal 65536 -> 65536 =20
HighMem 6553 =20
Movable zone start PFN for each node =20
early_node_map[1] active PFN ranges =20
0: 0 -> 65536 =20
Built 1 zonelists in Zone order, mobility grouping on. Total pages: =
65024
Kernel command line: console=3DttyS0,9600 root=3D/dev/xsa2 =
init=3D/bin/sh
Xilinx INTC #0 at 0x41200000 mapped to 0xEF5FE000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25 =20
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 258048k available (1288k kernel code, 436k data, 76k init, 0k
highmem)
Mount-cache hash table entries: 512 =20
net_namespace: 64 bytes =20
NET: Registered protocol family 16 =20
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
Call Trace: =20
[cfc1fe20] [c0008148] show_stack+0x58/0x188 (unreliable)
[cfc1fe68] [c0038908] set_fail+0x50/0x68
[cfc1fe80] [c0038f7c] sysctl_check_table+0x65c/0x6ac
[cfc1fee8] [c0038f8c] sysctl_check_table+0x66c/0x6ac
[cfc1ff50] [c0026c58] register_sysctl_table+0x64/0xb4
[cfc1ff68] [c019ed4c] register_ppc_htab_sysctl+0x18/0x2c
[cfc1ff70] [c019b228] kernel_init+0x104/0x290
[cfc1fff0] [c0004af8] kernel_thread+0x44/0x60
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Generic RTC Driver v1.07
Macintosh non-volatile memory driver v1.1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing =
disabled
serial8250.0: ttyS0 at MMIO 0x40401003 (irq =3D 2) is a 16550A
console [ttyS0] enabled
xsysace xsysace.0: Xilinx SystemACE revision 1.0.12
xsysace xsysace.0: capacity: 1981728 sectors
xsa: xsa1 xsa2 xsa3
Xilinx SystemACE device driver, major=3D254
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init
-----Original Message-----
From: mojtaba [mailto:kernelppc@gmail.com]=20
Sent: Thursday, January 03, 2008 4:58 PM
To: 'linuxppc-embedded@ozlabs.org'
Subject: RE: File system problem
Hi,
Thank you very much for your answers.
But I have both console and null in /dev.
-rw-rw-rw- 1 mojtaba mojtaba 0 2007-12-26 15:50 console
-rw-rw-rw- 1 mojtaba mojtaba 0 2007-12-26 15:50 null
They have been created by buildroot. Do I need to create them manually?
Actually the size of both of them is 0 and both are empty files. Is that =
a
problem?
Thank you in advance and best regards,
Mojtaba
-----Original Message-----
From: jsamch@gmail.com [mailto:jsamch@gmail.com] On Behalf Of =
Jean-Samuel
Chenard
Sent: Thursday, January 03, 2008 4:33 AM
To: linuxppc-embedded@ozlabs.org; kernelppc@gmail.com
Subject: RE: File system problem
> Date: Wed, 2 Jan 2008 19:50:13 +0100
> From: "mojtaba"
> I am trying to boot a root file system build by buildroot. But I got =
this
> error" init has generated signal 11 but has no handler for it".
>
> My kernel version is 2.6.24-rc3
> My target system is PPC 405 (XILINX VIRTEX II pro) I am using the
26-12-2007
> snapshot of buildroot.
[ ... ]
> Warning: unable to open an initial console.
> init has generated signal 11 but has no handler for it Kernel panic - =
not
Hi Mojtaba,
I got a similar error on my ML-310 when I tried a new root filesystem.
As far as I recall, I needed to make sure that two entries existed in
/dev, namely:
crw------- 1 root root 5, 1 Jan 1 05:18 console
crw-rw---- 1 root root 1, 3 Dec 10 2007 null
I think that you are missing /dev/console and then init cannot run
since it has nowhere to put its standard output.
You can make those by mounting your CF card on your development host
and (as root) make the nodes:
# mknod -m 660 /dev/console c 5 1
# mknod -m 660 /dev/null c 1 3
In my case, I use the UartLite (ttyUL0) serial port driver, but I'm
pretty sure this is going to fix the problem you are observing.
Regards,
Jean-Samuel
--=20
Ph.D. candidate
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* Re: Reading a config file in a driver ....
From: Olof Johansson @ 2008-01-03 16:30 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <14591717.post@talk.nabble.com>
On Wed, Jan 02, 2008 at 09:03:20PM -0800, Misbah khan wrote:
>
> Hi all ....
>
> I am writing a LCD driver in which the default configuration for LCD would
> be loded at the Init . This default configuration if keep in the driver then
> for a change in default configuration we need to compile the driver which we
> never want . Hence we want a .config file in /etc/lcd.config dir which could
> be changed and the next boot will take this configuration as the default
> configuration.
>
> I need to know How to read from the config file in the driver form the dir
> /etc/lcd.config. The driver would be installed at boot up
The driver/kernel shouldn't read the file directly, if anything you
should have a userspace tool that reads it and adjusts the driver via
sysfs or similar. That tool can be run from some of the init scripts,
or from the ramdisk in case you want to do it early.
-Olof
^ permalink raw reply
* Re: [PATCH] powerpc: #address-cells & #size-cells properties not inherited
From: Josh Boyer @ 2008-01-03 16:01 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080103153256.GA18716@mag.az.mvista.com>
On Thu, 3 Jan 2008 08:32:56 -0700
"Mark A. Greer" <mgreer@mvista.com> wrote:
> On Wed, Jan 02, 2008 at 07:46:40PM -0600, Josh Boyer wrote:
> > On Wed, 2 Jan 2008 17:07:50 -0700
> > "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > > From: Mark A. Greer <mgreer@mvista.com>
> > >
> > > Fix error in booting-without-of.txt that indicates that a node can inherit
> > > its #address-cells and #size-cells definitions from its parent's parent.
> > > This is not correct and the latest dtc enforces it.
> >
> > I'm lazy so I haven't checked myself, but by "latest dtc" does that
> > mean the DTC that's in the kernel now?
> >
> > Things are going to be fun when we start saying generic things like
> > "latest DTC". And when upstream DTC gets new features or enforcements,
> > we'll have to have all the in-kernel DTS files patched up when that
> > version of DTC gets merged in-kernel. Just something to keep in mind
> > as we move along.
>
> Yeah, I thought about that last night, actually.
> I think I'll just change that sentence to "This is not correct."
>
> Avoid the issue :)
Lazy! I like it ;)
josh
^ permalink raw reply
* RE: File system problem
From: mojtaba @ 2008-01-03 15:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <169c03cb0801021932s6671526dve15d1948da52ae30@mail.gmail.com>
Hi,
Thank you very much for your answers.
But I have both console and null in /dev.
-rw-rw-rw- 1 mojtaba mojtaba 0 2007-12-26 15:50 console
-rw-rw-rw- 1 mojtaba mojtaba 0 2007-12-26 15:50 null
They have been created by buildroot. Do I need to create them manually?
Actually the size of both of them is 0 and both are empty files. Is that =
a
problem?
Thank you in advance and best regards,
Mojtaba
-----Original Message-----
From: jsamch@gmail.com [mailto:jsamch@gmail.com] On Behalf Of =
Jean-Samuel
Chenard
Sent: Thursday, January 03, 2008 4:33 AM
To: linuxppc-embedded@ozlabs.org; kernelppc@gmail.com
Subject: RE: File system problem
> Date: Wed, 2 Jan 2008 19:50:13 +0100
> From: "mojtaba"
> I am trying to boot a root file system build by buildroot. But I got =
this
> error" init has generated signal 11 but has no handler for it".
>
> My kernel version is 2.6.24-rc3
> My target system is PPC 405 (XILINX VIRTEX II pro) I am using the
26-12-2007
> snapshot of buildroot.
[ ... ]
> Warning: unable to open an initial console.
> init has generated signal 11 but has no handler for it Kernel panic - =
not
Hi Mojtaba,
I got a similar error on my ML-310 when I tried a new root filesystem.
As far as I recall, I needed to make sure that two entries existed in
/dev, namely:
crw------- 1 root root 5, 1 Jan 1 05:18 console
crw-rw---- 1 root root 1, 3 Dec 10 2007 null
I think that you are missing /dev/console and then init cannot run
since it has nowhere to put its standard output.
You can make those by mounting your CF card on your development host
and (as root) make the nodes:
# mknod -m 660 /dev/console c 5 1
# mknod -m 660 /dev/null c 1 3
In my case, I use the UartLite (ttyUL0) serial port driver, but I'm
pretty sure this is going to fix the problem you are observing.
Regards,
Jean-Samuel
--=20
Ph.D. candidate
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* [PATCH v2] powerpc: #address-cells & #size-cells properties not inherited
From: Mark A. Greer @ 2008-01-03 15:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080102194640.48c97d0c@vader.jdub.homelinux.org>
From: Mark A. Greer <mgreer@mvista.com>
Fix error in booting-without-of.txt that indicates that a node can inherit
its #address-cells and #size-cells definitions from its parent's parent.
This is not correct.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ee0209a..58db5ea 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -671,10 +671,10 @@ device or bus to be described by the device tree.
In general, the format of an address for a device is defined by the
parent bus type, based on the #address-cells and #size-cells
-property. In the absence of such a property, the parent's parent
-values are used, etc... The kernel requires the root node to have
-those properties defining addresses format for devices directly mapped
-on the processor bus.
+properties. Note that the parent's parent definitions of #address-cells
+and #size-cells are not inhereted so every node with children must specify
+them. The kernel requires the root node to have those properties defining
+addresses format for devices directly mapped on the processor bus.
Those 2 properties define 'cells' for representing an address and a
size. A "cell" is a 32-bit number. For example, if both contain 2
^ permalink raw reply related
* Re: [PATCH] powerpc: #address-cells & #size-cells properties not inherited
From: Mark A. Greer @ 2008-01-03 15:32 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080102194640.48c97d0c@vader.jdub.homelinux.org>
On Wed, Jan 02, 2008 at 07:46:40PM -0600, Josh Boyer wrote:
> On Wed, 2 Jan 2008 17:07:50 -0700
> "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> > From: Mark A. Greer <mgreer@mvista.com>
> >
> > Fix error in booting-without-of.txt that indicates that a node can inherit
> > its #address-cells and #size-cells definitions from its parent's parent.
> > This is not correct and the latest dtc enforces it.
>
> I'm lazy so I haven't checked myself, but by "latest dtc" does that
> mean the DTC that's in the kernel now?
>
> Things are going to be fun when we start saying generic things like
> "latest DTC". And when upstream DTC gets new features or enforcements,
> we'll have to have all the in-kernel DTS files patched up when that
> version of DTC gets merged in-kernel. Just something to keep in mind
> as we move along.
Yeah, I thought about that last night, actually.
I think I'll just change that sentence to "This is not correct."
Avoid the issue :)
Mark
^ permalink raw reply
* Re: [DTC] small ftdump cleanup patch
From: Paul Gortmaker @ 2008-01-03 14:59 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JARRd-0005ED-Qr@jdl.com>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
Jon Loeliger wrote:
> So, like, the other day Paul Gortmaker mumbled:
>
>> Here is a small patch to clean up the usage info and the error returns
>> for ftdump -- not sure what the future holds for ftdump vs. simply using
>> "dtc -I dtb -O dts someblob.dtb" ...
>>
>> Paul.
>>
>
> Paul,
>
> Any chance of a signed-off-by line?
>
Sure, here is the whole thing.
Paul.
[-- Attachment #2: 0001-ftdump-minor-usage-and-error-return-cleanup.txt --]
[-- Type: text/plain, Size: 1381 bytes --]
>From cef80fcd1efddaebcb366fb897430260cebb0c84 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 3 Jan 2008 09:56:09 -0500
Subject: [PATCH] ftdump: minor usage and error return cleanup
Improve the usage info and use standard error return values in ftdump.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
ftdump.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/ftdump.c b/ftdump.c
index 53343d7..49bc7cf 100644
--- a/ftdump.c
+++ b/ftdump.c
@@ -8,6 +8,8 @@
#include <ctype.h>
#include <netinet/in.h>
#include <byteswap.h>
+#include <errno.h>
+#include <libgen.h>
#include <fdt.h>
@@ -165,21 +167,22 @@ int main(int argc, char *argv[])
char buf[16384]; /* 16k max */
int size;
- if (argc < 2) {
- fprintf(stderr, "supply input filename\n");
- return 5;
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s filename.dtb\n", basename(argv[0]));
+ fprintf(stderr, "\t-dump binary device tree blob contents.\n");
+ return EINVAL;
}
fp = fopen(argv[1], "rb");
if (fp == NULL) {
fprintf(stderr, "unable to open %s\n", argv[1]);
- return 10;
+ return errno;
}
size = fread(buf, 1, sizeof(buf), fp);
if (size == sizeof(buf)) { /* too large */
fprintf(stderr, "file too large\n");
- return 10;
+ return EFBIG;
}
dump_blob(buf);
--
1.5.0.rc1.gf4b6c
^ permalink raw reply related
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-03 14:54 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, linuxppc-dev, alsa-devel
In-Reply-To: <20080103044432.GB25357@localhost.localdomain>
On 1/2/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
> > Jon Smirl wrote:
> > > On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> > >> sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++
> > >> sound/soc/fsl/fsl_ssi.h | 224 +++++++
> > >
> > > I'm confused about this part. You built a driver for the mpc8610 ssi
> > > port. This port has a device tree entry.
> > >
> > > + ssi@16000 {
> > > + compatible = "fsl,ssi";
> > > + cell-index = <0>;
> > > + reg = <16000 100>;
> > > + interrupt-parent = <&mpic>;
> > > + interrupts = <3e 2>;
> > > + fsl,mode = "i2s-slave";
> > > + codec {
> > > + compatible = "cirrus,cs4270";
> > > + /* MCLK source is a stand-alone oscillator */
> > > + bus-frequency = <bb8000>;
> > > + };
> > > + };
> > >
> > > But then you don't create an of_platform_driver for this device.
> > > Instead you create one for the fabric driver, struct
> > > of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI
> > > driver into it.
> >
> > That's the best plan I came up with. This is apparently fixed in ASoC
> > V2. From ASoC V1's perspective, the fabric driver must be the master.
> > However, it doesn't make sense to have a node in the device tree for the
> > fabric driver, because there is no such "device". The fabric driver is
> > an abstraction. So I need to chose some other node to probe the fabric
> > driver with. I chose the SSI, since each SSI can have only one
> > codec.
>
> Instantiating the fabric driver off any node is wrong, precisely
> because it is an abstraction. The fabric driver should be
> instantiated by the platform code.
Instantiating it from the platform code forces me to put it either the
of_platform_bus or the platform_bus since there aren't any other buses
around when the platform code runs. Platform bus doesn't implement
dynamic module loading. So that means it has to go onto the
of_platform_bus. That implies that is it a pseudo-device without a
pseudo-device entry in the device tree which is fine with me. I'll
need to poke around in the of_bus code and see if the driver will load
without a device tree entry.
A simple fix to this would be to let me instantiate the driver off
from the root node of the tree. That's the conceptually correct place
for instantiating a driver that extends the platform code. Should I
try adjusting the of probing code to pass the node in, or are there
major objections?
Also, as others have pointed out, this driver is not an abstraction.
It represents the mess of wires hooking the codec up to the jacks on
the back panel and possibly GPIO pins that control the wiring. You
need this because the pins on HD audio codecs are completely
reconfigurable and the same chip can be wired in a thousand different
ways. It lets you have a generic codec driver and the move the
platform specific code out of the driver.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [DTC] small ftdump cleanup patch
From: Jon Loeliger @ 2008-01-03 14:53 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <20080103144056.GB28644@windriver.com>
So, like, the other day Paul Gortmaker mumbled:
> Here is a small patch to clean up the usage info and the error returns
> for ftdump -- not sure what the future holds for ftdump vs. simply using
> "dtc -I dtb -O dts someblob.dtb" ...
>
> Paul.
Paul,
Any chance of a signed-off-by line?
Thanks,
jdl
^ permalink raw reply
* Re: Book-E watchdog driver questions
From: Mike Nuss @ 2008-01-03 14:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list
In-Reply-To: <a340dd0e0709251118n108799adxb60af2afa6ac9a96@mail.gmail.com>
On Sep 25, 2007 1:18 PM, Mike Nuss <mikenuss@gmail.com> wrote:
> > > Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE?
> > >> From the copyright notice at the top it appears to be GPL. As
> > >> written,
> > > it taints the kernel.
> >
> > Odd, no reason. I'll submit a patch for that.
> >
> > > Also, if I test out the driver by killing my process that's doing the
> > > pinging, I get a kernel panic:
> >
> > Its been a while since i've tried this. I'll try it out and see what
> > happens.
The kernel panic was caused because TCR: WIE was set. This bit should
not be set, because it causes the timer to generate an interrupt that
the kernel does not handle.
>
> I also found that GETBOOTSTATUS returns 0 after the reboot. Looking at
> the source code I found the comment "XXX: something is clearing TSR" -
> I take that to mean that the register is being cleared by something
> before the module tries to read it? In my case U-Boot may be clearing
> that - I can take a look.
It turns out that the status bits in TSR are undefined at poweron
reset. Boards require external logic to detect POR - this is described
in AMCC's app note for the WDT. Because of this, U-Boot clears TSR
early on in the standard 4xx firmware (in start.S). To use TSR to
detect a watchdog reset, U-Boot must be modified to check that logic
and only clear the bits at POR. Those bits will be preserved until the
kernel driver looks at them, or until the system is powered off. So
the driver is correct here, but the comment should be updated to
explain why the GETBOOTSTATUS value may not be meaningful - it
requires additional hardware and firmware support.
I can submit a patch for these issues if you like.
Mike
^ permalink raw reply
* [DTC] small ftdump cleanup patch
From: Paul Gortmaker @ 2008-01-03 14:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jdl
Here is a small patch to clean up the usage info and the error returns
for ftdump -- not sure what the future holds for ftdump vs. simply using
"dtc -I dtb -O dts someblob.dtb" ...
Paul.
diff --git a/ftdump.c b/ftdump.c
index 53343d7..49bc7cf 100644
--- a/ftdump.c
+++ b/ftdump.c
@@ -8,6 +8,8 @@
#include <ctype.h>
#include <netinet/in.h>
#include <byteswap.h>
+#include <errno.h>
+#include <libgen.h>
#include <fdt.h>
@@ -165,21 +167,22 @@ int main(int argc, char *argv[])
char buf[16384]; /* 16k max */
int size;
- if (argc < 2) {
- fprintf(stderr, "supply input filename\n");
- return 5;
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s filename.dtb\n", basename(argv[0]));
+ fprintf(stderr, "\t-dump binary device tree blob contents.\n");
+ return EINVAL;
}
fp = fopen(argv[1], "rb");
if (fp == NULL) {
fprintf(stderr, "unable to open %s\n", argv[1]);
- return 10;
+ return errno;
}
size = fread(buf, 1, sizeof(buf), fp);
if (size == sizeof(buf)) { /* too large */
fprintf(stderr, "file too large\n");
- return 10;
+ return EFBIG;
}
dump_blob(buf);
^ permalink raw reply related
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-03 14:33 UTC (permalink / raw)
To: Jon Smirl, Grant Likely, linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <20080103044620.GC25357@localhost.localdomain>
On 1/2/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
> > On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> > > > mpc8610_hpcd is the harder one to load since it doesn't have a device
> > > > tree entry. What you want to do it match on the compatible field of
> > > > the root node.
> > > >
> > > > static struct of_device_id fabric_of_match[] = {
> > > > {
> > > > .compatible = "fsl,MPC8610HPCD",
> > > > },
> > > > {},
> > > > };
> > > >
> > > > But this doesn't work since the root is the device tree isn't passed
> > > > down into the device probe code. (Could this be fixed?)
> > >
> > > The driver can always get the root node. But better yet, instantiate
> > > the correct fabric device (probably as a platform_device) from the
> > > platform code. Then the correct fabric driver can probe against it.
> >
> > The meaning of this has finally sunk into my consciousness. The
> > platform code can create a device that isn't bound to a driver. So why
> > not make this an of_platform_device? This is basically a pseudo
> > device that isn't in the device tree.
> >
> > Alternatively, the best place for this device would be on the ASOC
> > bus, but the ASOC bus hasn't been created when the platform code runs.
> > Maybe I can figure out a place in the platform code to create this
> > device after the ASOC driver has loaded and created the bus. Does the
> > platform code get control back after loading all of the device
> > drivers?
> >
> > In the longer term I'd like to kill platform_bus on powerpc and only
> > use of_platform_bus. Platform_bus seems to be functioning like a
> > catch-all and collecting junk from lots of different platforms.
>
> Not going to happen. of_platform_bus is not the right solution, and
> in fact we're looking at moving (gradually) away from using
> of_platform_bus, and instead using platform devices (along with the
> device node being available for *any* struct device via the
> arch_sysdata).
I do agree that of_platform_bus should have been derived from
platform_bus, not a separate structure. This is causing problems in
the ASLA code where they want typed pointers.
In my little test patch, I disabled platform_bus on my MPC5200. This
generated some compiler errors which exposed a bunch of MPC83xxx and
Apple code that was getting compiled into my MPC5200 kernel. These
were platform bus drivers that weren't properly ifdef'd.
So I guess my objection is more along the lines of getting rid of
driver code inside the arch directory and switching everything to
modules. Then we could periodically turn off platform bus on each
platform and make sure everything still builds.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Outstanding DTC patches?
From: Jon Loeliger @ 2008-01-03 14:14 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20080103044843.GD25357@localhost.localdomain>
So, like, the other day David Gibson mumbled:
>
> I posted this one a while back, but I guess it dropped through the
> cracks.
Yep, sorry.
> There's also the patch I sent you quite a long time ago that
> adds a clarifying readme about the licensing situation - that might be
> an idea for v1.1, too.
I can not find this; neither locally nor on patchworks.
Do you have a Subject: line, a URL, or could you
please repost it?
> dtc: Remove header information dumping
>
> Currently, when used in -Idtb mode, dtc will dump information about
> the input blob's header fields to stderr. This is kind of ugly, and
> can get in the way of dtc's real output.
>
> This patch, therefore, removes this. So that there's still a way of
> getting this information for debugging purposes, it places something
> similar to the removed code into ftdump, replacing the couple of
> header fields it currently prints with a complete header dump.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCHv3] powerpc: DBox2 Board Support
From: Jochen Friedrich @ 2008-01-03 11:46 UTC (permalink / raw)
To: Jochen Friedrich, linuxppc-dev, Scott Wood, linux-kernel,
linuxppc-embedded@ozlabs.org
In-Reply-To: <20080102112030.GB23168@localhost.localdomain>
Hi David,
>> +/ {
>> + model = "unknown,dbox2"; // boot wrapper fills in correct manufacturer
>
> Probably better just to leave model out of the dts and let the
> bootwrapper add it.
Unfortunately, dtc requires a model:
$ dtc arch/powerpc/boot/dts/dbox2.dts
DTC: dts->dts on file "arch/powerpc/boot/dts/dbox2.dts"
ERROR: Missing "model" property in /
>> + flash@0,0 {
>> + compatible = "cfi-flash";
>> + reg = <0 0 800000>;
>> + bank-width = <4>;
>> + device-width = <1>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + partition@0 {
>> + label = "BR bootloader";
>> + reg = <0 20000>;
>> + read-only;
>> + };
>> + partition@20000 {
>> + label = "FLFS (U-Boot)";
>> + reg = <20000 20000>;
>> + };
>> + partition@40000 {
>> + label = "rootfs";
>> + reg = <40000 7c0000>;
>> + };
>> + ovpartition@20000 {
>
> Uh.. I really don't know what the MTD driver will handle these
> overlapping partitions. I suspect it will not be pretty...
>
>> + label = "Flash without bootloader";
>> + reg = <20000 7e0000>;
>> + };
>> + ovpartition@0 {
>> + label = "Complete Flash";
>> + reg = <0 800000>;
>> + read-only;
>> + };
>> + };
>> + };
MTD handles this correctly. dbox2 uses "Flash without bootloader" for flashing image updates and "Complete Flash" for creating a backup of everything.
OpenWRT also uses overlapping partitions BTW (and also for flashing updates).
Thanks,
Jochen
^ permalink raw reply
* Re: (no subject)
From: Misbah khan @ 2008-01-03 10:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <22A704B880BBD94A9E52BD6FA90C63D702F4483A@BUDMLVEM08.e2k.ad.ge.com>
I can tell you from Software point of view ....There should be One Time
Master and others as time slave data would be transmitted via Ethernet and
PPS through OFC ...Ntp should be runing ...I guess this is a way in which we
could Sync all the other boards ....
----Misbah <><
Awad, Sinan (GE Healthcare) wrote:
>
> Hello all
>
> I'm trying to understand if we need to move from MPC8347 to MPC8360 in
> our boards.
> One of the features that most attracts, is the eTSEC which includes
> support for IEEE 1588 PTP time synchronization.
> I need to synchronize the clock of 3 boards via ethernet, I need a time
> resolution of under 1ms.
>
> Has anyone had the pleasure of playing around with time synchronization
> ?
> Do I really need the hardware capabilities for this type of time
> resolution ? or can I implement it in software ?
>
> Thanks in advance.
> Sinan
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/%28no-subject%29-tp14593723p14594687.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Li Li @ 2008-01-03 10:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Phillips Kim, linuxppc-dev, Li Tony, Wood Scott
In-Reply-To: <200801031114.05981.arnd@arndb.de>
On Thu, 2008-01-03 at 18:14 +0800, Arnd Bergmann wrote:
> After some more research, I noticed that the distinction between
> primary and secondary host bridges will go away _anyway_, so
> I guess we shouldn't worry about it too much.
>
> On powerpc64, we already don't care, as the
> arch/powerpc/kernel/isa-bridge.c
> code takes care of legacy I/O areas there, instead of the PCI code.
> It's only needed on machines with legacy ISA devices (PC keyboard,
> floppy, ...), and those can be converted to use the isa-bridge code
> at some point.
>
This is really a good new :)
- Tony
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Arnd Bergmann @ 2008-01-03 10:14 UTC (permalink / raw)
To: Li Li; +Cc: Phillips Kim, linuxppc-dev, Li Tony, Wood Scott
In-Reply-To: <1199349066.4437.5.camel@Guyver>
On Thursday 03 January 2008, Li Li wrote:
>
> > It's easy enough to just panic() if you find more than one primary
> > bus,
> > since the information from the device tree is static enough that one
> > will know how to fix this after seeing the error.
> >
>
> It is just a case. what about if do not find primary pci host.
> The current code can prevent this potential error and make system
> robust.
After some more research, I noticed that the distinction between
primary and secondary host bridges will go away _anyway_, so
I guess we shouldn't worry about it too much.
On powerpc64, we already don't care, as the arch/powerpc/kernel/isa-bridge.c
code takes care of legacy I/O areas there, instead of the PCI code.
It's only needed on machines with legacy ISA devices (PC keyboard,
floppy, ...), and those can be converted to use the isa-bridge code
at some point.
Arnd <><
^ 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