* RE: MPC8260ADS and linux-2.6
From: Rune Torgersen @ 2008-01-03 18:18 UTC (permalink / raw)
To: Scott Wood, suja Baburaj; +Cc: linuxppc-embedded
In-Reply-To: <477D2255.3040803@freescale.com>
> From: Scott Wood
> Sent: Thursday, January 03, 2008 11:59 AM
> To: suja Baburaj
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC8260ADS and linux-2.6
>=20
> suja Baburaj wrote:
> > I have an MPC8260ADS board with (eldk)linux-2.4.25 working=20
> fine on it.
> > Now i want to try linux-2.6.X on the board.
>=20
> There's no support for that specific board in mainstream 2.6=20
> yet, but it=20
> should be fairly simple to get it working using the=20
> mpc8272ads support=20
> as an example.
There is support, but it is in arch/ppc not arch/powerpc
(PQ2FADS support works for this board in arch/ppc)
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:17 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D24AA.4050804@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > Why not be a child of the i2c bus with a phandle to the ssi bus?
>
> Because when I probe the SSI node, I want to know what the attached codec is.
> So if anything, I would need a pointer from the SSI bus *to* the respective
> child on the I2C bus.
That's fine too (it's what is done with Ethernet PHYs). My preference
is the other way around, but it's not a big issue in this 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] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:16 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, linuxppc-dev, alsa-devel
In-Reply-To: <20080103044432.GB25357@localhost.localdomain>
David Gibson wrote:
> 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.
Can you tell me how to do that?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:16 UTC (permalink / raw)
To: Grant Likely, Timur Tabi, linuxppc-dev, alsa-devel
In-Reply-To: <20080102184957.GB2007@sirena.org.uk>
Mark Brown wrote:
> The machine support code (fabric driver in PowerPC terms, I think?)
> tells the core how everything is connected together by registering
> devices representing the links (eg, I2S) between the codecs, CPU and
> other devices. The ASoC core is then responsible for ensuring that all
> the required components are present before it registers with the ALSA
> core.
I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal*
situation would be if the ASoC fabric driver were generic, maybe even part of
ASoC itself, and everything it needed could be obtained from the device tree.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <477D2150.4020506@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
> > 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.
The device tree is a description of the hardware; not software. It's
not a good idea to break with convention due to current driver
architecture.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40801020828u5103d09cn2aa5eab7dda2fcff@mail.gmail.com>
Grant Likely wrote:
> Does that mean with ASoC V2 you can instantiate it with the board
> specific platform code instead?
I don't know. I haven't really looked at V2 yet. You'll have to ask Liam
Girdwood.
> This is one of the examples of where the compatible properties are
> trying to be far to generic about what they are. How do you define
> what "fsl,ssi" is?
The SSI is a specific Freescale device, so I think it's pretty well defined.
> What happens when Freescale produces another
> peripheral that can do ssi but isn't register level compatible?
It won't be called the SSI. It will be called something else.
> In my opinion, it is far better to be specific in the device tree and
> teach the driver about what versions it is able to bind against. In
> this case, I would use "fsl,mpc8610-ssi" or maybe better yet:
> "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I can work with that, but the SSI could be placed into any future 83xx, 85xx,
or 86xx SOC, and the driver will still work with it as-is.
> I don't like the idea of a separate fsl,mode property to describe the
> behaviour of multifunction peripherals. It makes probing more
> difficult when there is a different driver for each mode.
Can you propose an alternative? The driver needs to know what mode to use
when communicating with its codec. How am I supposed to know if I have an I2S
codec or an AC97 codec?
>> The fabric driver is specific to the board. So you should be using
>> Kconfig to select the fabric driver. There is no node in the device
>> tree for fabric drivers. I thought that was the consensus.
>
> No, the desire is to go multiplatform in ppc. That means you cannot
> use Kconfig to select the correct fabric driver.
I don't see any way of avoiding this with ASoC V1.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40801020812o471e18e6u9fe20676d320e958@mail.gmail.com>
Grant Likely wrote:
> Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is.
So if anything, I would need a pointer from the SSI bus *to* the respective
child on the I2C bus.
I know little about platform devices/drivers, so I don't know how to use them.
Currently, I have a design flaw in my driver in that if I have two SSIs, and
each one is attached to a CS4270, I don't have any way of making sure that the
right CS4270 is using the right I2C address. I'm guessing that if I switch to
a platform-based model, I can resolve this issue. But for now, the CS4270
doesn't support that, so that patchset I have submitted works with what I
have. After my patchset has been applied, I'll be more than happy to look
into updating the CS4270 (and everything else) to use the platform model for I2C.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Drivers' probe function calling order
From: Jeff Mock @ 2008-01-03 18:04 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EC2DE1E@aquib01a>
The only way I've know to do this is to build the drivers as modules and
load them in the desired order from the startup scripts called from init.
If there's a better way I would like to know about it also...
jeff
DI BACCO ANTONIO - technolabs wrote:
> 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?
>
> Bye and thanks.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* 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
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