* Re: Device trees and audio codecs
From: Timur Tabi @ 2007-10-21 13:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710200833x5d1c55b5l2cd400f77c13ec87@mail.gmail.com>
Jon Smirl wrote:
> I'm working on ALSA ASoC support for a codec chip on my mpc5200 based
> target hardware. How should the codec be represented in the device
> tree?
I'm also working on an ASoC driver, but for the 8610. I have a similar problem.
> Under ASoC the device drivers for the codec chips are platform
> independent. In the current ASoC model there are three device
> drivers: i2s (or spi, etc), the generic codec, and a platform specific
> 'fabric' driver. Some codecs are linked to both i2c and i2s.
Annoying, isn't it? :-)
You can use phandles to cross-reference nodes. I suggest putting the codec
node under the i2s node (and containing I2S-specific information), and then
putting another codec node under the i2c node (this is a new layout proposed
by Scott Wood), and use a phandle to let the i2s-codec node point to the
i2c-codec node.
> The fabric driver corresponds to the 'layout-id' in the Apple model.
> It tells how to configure the generic codec driver for the specific
> configuration needed by the actual platform hardware.
>
> For development purposes I'm using an Efika as a target platform. It
> is easy enough to load the i2s driver using the device tree. I can add
> entries to the i2s node to trigger loading of the generic sta9766
> codec driver. How do I trigger loading the Efika specific fabric
> driver?
You don't need a device tree entry to trigger loading a driver. You can just
load the driver and initialize it in its __init function.
However, in this case, you might want to do what I'm doing -- putting a probe
function in the fabric driver for the i2s device (which gets its own node
under the SOC node), and then in that probe function search for all the other
nodes that you need.
> My target hardware has a codec that is linked to both i2s and i2c. How
> should it be represented?
>
> Apple has three entries. One for i2s, one for the codec, and one for
> soundchip. What is the soundchip entry, does it correspond to real
> hardware?
Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay
attention to what they do.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [bug] block subsystem related crash on Legacy iSeries viodasd.c
From: Jens Axboe @ 2007-10-21 12:44 UTC (permalink / raw)
To: Will Schmidt; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev
In-Reply-To: <1192829614.11003.30.camel@farscape.rchland.ibm.com>
On Fri, Oct 19 2007, Will Schmidt wrote:
> Hi Jens, Stephen, and Everyone else.
>
> I am seeing this crash on a legacy iSeries box. Bisect points at
> 70eb8040dc81212c884a464b75e37dca8014f3ad (Add chained sg support to
> linux/scatterlist.h).
>
> I see there were some related troubles discussed a couple days back.
> I've refreshed my tree, so believe I should have pulled in all the
> changes that fixed those issues by now, so this is an additional problem
> (viodasd funkyness), or I've screwed something up in my pulls, or fixes
> are still pending in another tree.
>
> >From the register dump, looks like sg passed into memset was a -2.
>
> (from blk_rq_map_sg()) if (!sg)
> sg = sglist;
> else
> sg = sg_next(sg);
>
> memset(sg, 0, sizeof(*sg)); <--
>
>
> linux-2.6.git tree at
> commit 4fa4d23fa20de67df919030c1216295664866ad7
> Merge: a9e82d3... 4f1e5ba...
> Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
> Date: Thu Oct 18 19:31:54 2007 -0700
> Merge branch 'upstream-linus' of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
>
> > git log drivers/scsi/scsi_lib.c
> commit a3bec5c5aea0da263111c4d8f8eabc1f8560d7bf
> Author: Jens Axboe <axboe@carl.home.kernel.dk>
> Date: Wed Oct 17 19:33:05 2007 +0200
>
> Revert "[SCSI] Remove full sg table memset()"
>
> > > git log block/ll_rw_blk.c
> commit ba951841ceb7fa5b06ad48caa5270cc2ae17941e
> Author: Jens Axboe <jens.axboe@oracle.com>
> Date: Wed Oct 17 19:34:11 2007 +0200
>
> [BLOCK] blk_rq_map_sg() next_sg fixup
>
> -- The panic is:
> Freeing unused kernel memory: 224k freed
> Unable to handle kernel paging request for data at address 0xfffffffffffffffe
> Faulting instruction address: 0xc0000000000282f0
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 iSeries
> Modules linked in:
> NIP: c0000000000282f0 LR: c0000000001c772c CTR: 0000000000000000
> REGS: c000000002026b00 TRAP: 0300 Not tainted (2.6.23)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 44000022 XER: 00000008
> DAR: fffffffffffffffe, DSISR: 0000000042000000
> TASK = c000000002022000[1] 'swapper' THREAD: c000000002024000 CPU: 1
> GPR00: 0000000000000002 c000000002026d80 c0000000005168c8 fffffffffffffffe
> GPR04: 0000000000000000 000000000000001e fffffffffffffffe 0000000000000000
> GPR08: 0000000000000000 0000000000000001 6db6db6db6db6db7 0000000001491000
> GPR12: c00000000058d000 c000000000464f80 0000000000000000 c000000002027780
> GPR16: c00000000300a0c8 0000000000000001 c0000000004d4dd0 c00000000297e868
> GPR20: c000000002720000 c000000002026ec0 0000000000000001 0000000000000003
> GPR24: 0000000000000000 c000000002720000 0000000000001000 0000000000000003
> GPR28: fffffffffffffffe c000000002a61000 c0000000004c2510 c0000000027f64b0
> NIP [c0000000000282f0] .memset+0x3c/0xfc
> LR [c0000000001c772c] .blk_rq_map_sg+0x154/0x1e8
> Call Trace:
> [c000000002026d80] [c0000000004d4ed8] 0xc0000000004d4ed8 (unreliable)
> [c000000002026e50] [c0000000002283d8] .do_viodasd_request+0xb4/0x448
> [c0000000020270a0] [c0000000001c8ddc] .__generic_unplug_device+0x54/0x6c
> [c000000002027120] [c0000000001ca438] .generic_unplug_device+0x30/0x78
> [c0000000020271b0] [c0000000001c5888] .blk_backing_dev_unplug+0x34/0x48
> [c000000002027230] [c0000000000cf75c] .block_sync_page+0x78/0x90
> [c0000000020272b0] [c000000000074d50] .sync_page+0x74/0x98
> [c000000002027330] [c000000000344538] .__wait_on_bit_lock+0x8c/0x110
> [c0000000020273d0] [c000000000074c94] .__lock_page+0x70/0x90
> [c0000000020274a0] [c0000000000758b4] .do_generic_mapping_read+0x248/0x47c
> [c0000000020275a0] [c000000000077644] .generic_file_aio_read+0x144/0x1d4
> [c000000002027680] [c0000000000a3ad8] .do_sync_read+0xc4/0x124
> [c000000002027820] [c0000000000a4350] .vfs_read+0xd8/0x1a4
> [c0000000020278c0] [c0000000000a965c] .kernel_read+0x38/0x5c
> [c000000002027960] [c0000000000aad18] .do_execve+0xe8/0x208
> [c000000002027a10] [c00000000000e0b4] .sys_execve+0x6c/0xf0
> [c000000002027ab0] [c000000000007540] syscall_exit+0x0/0x40
> --- Exception: c01 at .kernel_execve+0x8/0x14
> LR = .run_init_process+0x28/0x40
> [c000000002027da0] [c0000000000b35ec] .sys_dup+0x2c/0x44 (unreliable)
> [c000000002027e20] [c000000000007fb4] .init_post+0xc4/0xe8
> [c000000002027ea0] [c000000000407978] .kernel_init+0x384/0x3b8
> [c000000002027f90] [c000000000020000] .kernel_thread+0x4c/0x68
> Instruction dump:
> 5084801e 7c850040 7884000e 7c001120 7c661b78 418400ac 41a2002c 7ca02850
> 409f000c 98860000 38c60001 409e000c <b0860000> 38c60002 409d000c 90860000
> Kernel panic - not syncing: Attempted to kill init!
> Rebooting in 180 seconds..
You need this, will remember to fix that up for the new branch as well.
diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c
index e824b67..2ce3622 100644
--- a/drivers/block/viodasd.c
+++ b/drivers/block/viodasd.c
@@ -270,6 +270,7 @@ static int send_request(struct request *req)
d = req->rq_disk->private_data;
/* Now build the scatter-gather list */
+ memset(sg, 0, sizeof(sg));
nsg = blk_rq_map_sg(req->q, req, sg);
nsg = dma_map_sg(d->dev, sg, nsg, direction);
--
Jens Axboe
^ permalink raw reply related
* Re: FDT bindings for I2C devices
From: Wolfgang Grandegger @ 2007-10-21 12:19 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0710192150561.8474@axis700.grange>
Hi Guennadi,
Guennadi Liakhovetski wrote:
> (it was suggested to deprecate -embedded in favour of -dev, so, added to
> cc:)
>
> On Fri, 19 Oct 2007, Grant Likely wrote:
>
>> On 10/19/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> Hello,
>>>
>>> is it forseen to define and configure devices like RTC, temperature
>>> sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
>>> would the DTS entries look like?
>> booting-without-of.txt has some information about describing the controller.
>>
>> Scott Wood made an attempt at defining a device binding for I2C
>> devices, but it has not been merged into booting-without-of.txt yet.
>> I've copied what he wrote below. I would add to his definition the
>> following:
>> - If compatible is missing, driver should *not* fall back to the device name.
>> - 'compatible' list should include the exact device in the form "<mfg>,<part>"
>
> There are also already working examples in powerpc: look at
> arch/powerpc/sysdev/fsl_soc.c at the i2c_devices[] array and how it is
> used below. There are also some .dts examples upstream already, e.g.,
> arch/powerpc/boot/dts/kuroboxH[GD].dts. There also have been more patches
> recently to add further devices to the table and further .dts entries.
> Notice however, it would be good to move the generic code out of
> fsl_soc.c, as there seems to be increasing interest in describing i2c
> buses in .dts.
Ah, nice. I checked a few dts files but obviously missed the one for the
kuroboxH[GD].
Thanks,
Wolfgang.
^ permalink raw reply
* RE: [PATCH] Fix ethernet multicast for ucc_geth.
From: Joakim Tjernlund @ 2007-10-21 9:45 UTC (permalink / raw)
To: 'Li Yang-r58472', 'Netdev', linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5BD2@zch01exm26.fsl.freescale.net>
> -----Original Message-----
> From: Li Yang-r58472 [mailto:LeoLi@freescale.com]
> Sent: den 18 oktober 2007 16:24
> To: joakim.tjernlund@transmode.se; Netdev; linuxppc-dev@ozlabs.org
> Subject: RE: [PATCH] Fix ethernet multicast for ucc_geth.
>
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Wednesday, October 17, 2007 5:06 PM
> > To: Netdev; Li Yang-r58472
> > Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> >
> > >From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17
> > 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Wed, 17 Oct 2007 11:01:44 +0200
> > Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> > hw_add_addr_in_hash() already swaps byte order, don't do it
> > in ucc_geth_set_multi() too.
> >
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Acked-by: Li Yang <leoli@freescale.com>
>
Ping? Did this make into a someones tree?
Jocke
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: Segher Boessenkool @ 2007-10-21 5:32 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20071020084737.GG26642@localhost.localdomain>
>> Use of "d#', "o#", "h#" and "b#" are gone in version 1.
>
> Also good. We might want to keep b#, since there's no C way of doing
> binary literals,
GCC supports "0b...", and it is proposed new ISO C syntax, too.
Segher
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: Segher Boessenkool @ 2007-10-21 5:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Iivsg-00078a-Vp@jdl.com>
> Property names have been limited to start with
> characters from the set [a-zA-Z,._#?]. That is, the
> digits and the expression symbols have been removed.
This cannot work; many property names start with a digit,
for example.
Segher
^ permalink raw reply
* vijay is your Yaar! :)
From: vijay @ 2007-10-21 2:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 2695 bytes --]
^ permalink raw reply
* Re: rtlinux rtai interrupt latency
From: Josh Boyer @ 2007-10-21 3:24 UTC (permalink / raw)
To: Bai Shuwei; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <f3566d60710201945m3d29830if274e61356c0179@mail.gmail.com>
On Sun, 2007-10-21 at 10:45 +0800, Bai Shuwei wrote:
> all, hi
> does anyone knows RTLinux, RTAI interrupt latency and schedule
> latency on the PPC440, PPC405?
You'd have to ask Wind River.
josh
^ permalink raw reply
* rtlinux rtai interrupt latency
From: Bai Shuwei @ 2007-10-21 2:45 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
all, hi
does anyone knows RTLinux, RTAI interrupt latency and schedule latency on
the PPC440, PPC405?
Thanks!
buroc
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 490 bytes --]
^ permalink raw reply
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Chan @ 2007-10-20 22:50 UTC (permalink / raw)
To: michael; +Cc: netdev, mcarlson, linuxppc-dev, linux-pci, David Miller
In-Reply-To: <1192862606.7688.4.camel@concordia>
On Sat, 2007-10-20 at 16:43 +1000, Michael Ellerman wrote:
> On Fri, 2007-10-19 at 17:53 -0700, David Miller wrote:
> > I don't see this, in all cases write_msi_msg() will transfer
> > the given "*msg" to entry->msg by this assignment in
> > drivers/pci/msi.c:
> >
> > void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> > {
> > ...
> > entry->msg = *msg;
> > }
> >
> > So as long as write_msi_msg() is invoked, it will be saved
> > properly.
> >
> > Platforms need not do this explicitly.
>
> I'm short on context here, and it's Saturday, so excuse me if I'm
> missing the point somewhere.
>
> On pseries machines we don't call write_msi_msg(), because we don't
> control the contents of the message, firmware does. So entry->msg will
> be bogus.
>
> That's a pity, but AFAIK it shouldn't be a problem because we don't
> enable CONFIG_PM on those machines anyway. If we ever want to we'll need
> to sort out with firmware how that will work WRT restoring MSI state.
>
The PCI error recovery that Linas is working on requires the MSI state
to be restored after we do PCI reset to recover from PCI errors.
^ permalink raw reply
* Re: rtlinux rtai interrupt latency
From: Nicholas Mc Guire @ 2007-10-20 20:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <1192937066.19375.0.camel@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> On Sun, 2007-10-21 at 10:45 +0800, Bai Shuwei wrote:
>> all, hi
>> does anyone knows RTLinux, RTAI interrupt latency and schedule
>> latency on the PPC440, PPC405?
>
> You'd have to ask Wind River.
>
There are free variants around as well - XtratuM/PPC (RTLinux-4.0) is
running on 440EP/GR and 405 Octobus, im quite sur RTAI also is available
for AMCC CPUs - check RTAI.org (mailing list link is to be found there)
and rtlinux-gpl.org (mailing list link) - those lists are most likely the
best source for the free-software hard-realtime Linux variants.
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD4DBQFHGmZZnU7rXZKfY2oRArrjAJ9WXETFjALA52TRuRtDRSm4x3DcZACYgylW
60r4W0r6+LtMv+UBK+5h9A==
=Eb2V
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] pasemi_mac: fix typo
From: Olof Johansson @ 2007-10-20 19:10 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
Add missing &:
drivers/net/pasemi_mac.c: In function 'pasemi_mac_clean_rx':
drivers/net/pasemi_mac.c:553: warning: passing argument 1 of 'prefetch'
makes pointer from integer without a cast
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 9f9a421..ab4d309 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -550,7 +550,7 @@ static int pasemi_mac_clean_rx(struct pasemi_mac *mac, int limit)
n = mac->rx->next_to_clean;
- prefetch(RX_RING(mac, n));
+ prefetch(&RX_RING(mac, n));
for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
^ permalink raw reply related
* Re: [PATCH] restore arch/ppc/boot cflags
From: Sam Ravnborg @ 2007-10-20 18:47 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-kernel, linux-kbuild
In-Reply-To: <200710200858.l9K8w3Nn064775@sullivan.realtime.net>
On Sat, Oct 20, 2007 at 03:58:03AM -0500, Milton Miller wrote:
> Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
> addition to CFLAGS that was being used by the subdirectory builds. For the
> other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
> sets that to empty as it is explicitly for a single directory only.
> Append to KBUILD_CFLAGS instead.
Neat - I had not figured out that the assignmnet took effect
recursively.
I have applied following patch.
Sam
>From 437374e9a95062fe310b901e48585691edaf5dd0 Mon Sep 17 00:00:00 2001
From: Milton Miller <miltonm@bga.com>
Date: Sat, 20 Oct 2007 03:58:03 -0500
Subject: [PATCH] kbuild: restore arch/{ppc/xtensa}/boot cflags
Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
addition to CFLAGS that was being used by the subdirectory builds. For the
other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
sets that to empty as it is explicitly for a single directory only.
Append to KBUILD_CFLAGS instead.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
arch/ppc/boot/Makefile | 2 ++
arch/xtensa/boot/Makefile | 3 ++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/boot/Makefile b/arch/ppc/boot/Makefile
index 487dc66..500497e 100644
--- a/arch/ppc/boot/Makefile
+++ b/arch/ppc/boot/Makefile
@@ -13,6 +13,8 @@
# modified by Cort (cort@cs.nmt.edu)
#
+# KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
+KBUILD_CFLAGS += -fno-builtin -D__BOOTER__ -Iarch/$(ARCH)/boot/include
HOSTCFLAGS += -Iarch/$(ARCH)/boot/include
BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd
diff --git a/arch/xtensa/boot/Makefile b/arch/xtensa/boot/Makefile
index 9c5185f..40aa55b 100644
--- a/arch/xtensa/boot/Makefile
+++ b/arch/xtensa/boot/Makefile
@@ -8,7 +8,8 @@
#
-EXTRA_CFLAGS += -fno-builtin -Iarch/$(ARCH)/boot/include
+# KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
+KBUILD_CFLAGS += -fno-builtin -Iarch/$(ARCH)/boot/include
HOSTFLAGS += -Iarch/$(ARCH)/boot/include
BIG_ENDIAN := $(shell echo -e __XTENSA_EB__ | $(CC) -E - | grep -v "\#")
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Device trees and audio codecs
From: Jon Smirl @ 2007-10-20 15:33 UTC (permalink / raw)
To: PowerPC dev list
I'm working on ALSA ASoC support for a codec chip on my mpc5200 based
target hardware. How should the codec be represented in the device
tree?
Under ASoC the device drivers for the codec chips are platform
independent. In the current ASoC model there are three device
drivers: i2s (or spi, etc), the generic codec, and a platform specific
'fabric' driver. Some codecs are linked to both i2c and i2s.
The fabric driver corresponds to the 'layout-id' in the Apple model.
It tells how to configure the generic codec driver for the specific
configuration needed by the actual platform hardware.
For development purposes I'm using an Efika as a target platform. It
is easy enough to load the i2s driver using the device tree. I can add
entries to the i2s node to trigger loading of the generic sta9766
codec driver. How do I trigger loading the Efika specific fabric
driver?
My target hardware has a codec that is linked to both i2s and i2c. How
should it be represented?
Apple has three entries. One for i2s, one for the codec, and one for
soundchip. What is the soundchip entry, does it correspond to real
hardware?
/proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000:
name "i2s-a"
device_type "soundbus"
compatible "i2sbus"
built-in
reg 00010000 00001000 00008000 00000100 00008100 00000100
interrupts 0000001e 00000001 00000001 00000000 00000002 00000000
interrupt-parent ff981a38
platform-headphone-mute ff9828a0
platform-amp-mute ff9829f8
platform-hw-reset ff982b48
platform-linein-detect ff982c98
platform-headphone-detect ff982e58
platform-get-enable ff97c3b0
platform-enable ff97c3b0
platform-disable ff97c3b0
platform-get-clock-enable ff97c3b0
platform-clock-enable ff97c3b0
platform-clock-disable ff97c3b0
platform-get-sw-reset ff97c3b0
platform-clear-sw-reset ff97c3b0
platform-sw-reset ff97c3b0
platform-get-cell-enable ff97c3b0
platform-cell-enable ff97c3b0
platform-cell-disable ff97c3b0
linux,phandle ff985b88
/proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound:
name "sound"
device_type "soundchip"
compatible "AOAbase"
built-in
layout-id 00000046 (70)
object-model-version 00000002
vendor-id 0000106b (4203)
platform-tas-codec-ref ff98cba8
linux,phandle ff985d48
/proc/device-tree/pci@f2000000/mac-io@17/i2c@18000/i2c-bus@0/codec@6a:
name "codec"
device_type "codec"
compatible "tas3004"
"codec"
""
reg 0000006a (106)
built-in
platform-do-tas-codec-ref ff985d48 08000000 00000027
linux,phandle ff98cba8
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: David Woodhouse @ 2007-10-20 12:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Stefan Roese
In-Reply-To: <BFBB503A-57F8-4DD4-BD4A-A2519E88F140@kernel.crashing.org>
On Wed, 2007-10-17 at 19:54 -0500, Kumar Gala wrote:
> This really cracked me up. I have to ask what the sbc8560 was doing
> in the boot of your car?
The Land Rover was full.
--
dwmw2
^ permalink raw reply
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: David Gibson @ 2007-10-20 9:06 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <jesl46yxri.fsf@sykes.suse.de>
On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote:
> David Gibson <david@gibson.dropbear.id.au> writes:
>
> > What compiler/platform is this? I can't off the top of my head think
> > of one where size_t shouldn't be promoted to int automatically.
>
> Only types narrower than int are subject to integer promotion.
Duh, yes. Sorry.
--
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
^ permalink raw reply
* [PATCH] restore arch/ppc/boot cflags
From: Milton Miller @ 2007-10-20 8:58 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, linux-kernel, linux-kbuild
Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
addition to CFLAGS that was being used by the subdirectory builds. For the
other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
sets that to empty as it is explicitly for a single directory only.
Append to KBUILD_CFLAGS instead.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
The commit also changed xtensia to export EXTRA_CFLAGS from its boot
directory, that needs to be fixed too.
from ARCH=ppc prep_defconfig:
/data/home/miltonm/work.git/arch/ppc/boot/of1275/write.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/read.c:11:20:/data/home/miltonm/work.git/arch/ppc/boot/of1275/ofstdio.c:11:20: error: error: of1275.h: No such file or directoryof1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/release.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/ofinit.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/map.c:12:22: error: nonstdio.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/map.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/getprop.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/common/ns16550.c:14:20: error: serial.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/common/ns16550.c:13:22: error: nonstdio.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/enter.c:11:20: error: of1275.h: No such file or directory
error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/claim.c:12:22: error: nonstdio.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/claim.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/of1275/finddevice.c:11:20: error: of1275.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/common/bootinfo.c:14:22: error: nonstdio.h: No such file or directory
/data/home/miltonm/work.git/arch/ppc/boot/common/misc-common.c:18:22: error: nonstdio.h: No such file or directory
of1275.h: No such file or directory
diff --git a/arch/ppc/boot/Makefile b/arch/ppc/boot/Makefile
index 487dc66..52a0d38 100644
--- a/arch/ppc/boot/Makefile
+++ b/arch/ppc/boot/Makefile
@@ -13,6 +13,7 @@
# modified by Cort (cort@cs.nmt.edu)
#
+KBUILD_CFLAGS += -fno-builtin -D__BOOTER__ -Iarch/$(ARCH)/boot/include
HOSTCFLAGS += -Iarch/$(ARCH)/boot/include
BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd
^ permalink raw reply related
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: Andreas Schwab @ 2007-10-20 8:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <20071020071920.GF26642@localhost.localdomain>
David Gibson <david@gibson.dropbear.id.au> writes:
> What compiler/platform is this? I can't off the top of my head think
> of one where size_t shouldn't be promoted to int automatically.
Only types narrower than int are subject to integer promotion.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: David Gibson @ 2007-10-20 8:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Iivsg-00078a-Vp@jdl.com>
On Fri, Oct 19, 2007 at 12:43:30PM -0500, Jon Loeliger wrote:
>
> Add support for the "/dts-version/ <number>;" statment.
> Make legacy DTS files version 0 whether explicitly stated
> or implied by a lack of /dts-version/ statement.
>
> Begin supporting a new /dts-version/ 1 that changes the
> format of the literals in a DTS source file. In the new
> format, hex constants are prefixed with 0x or 0X, and
> bare numbers are decimal or octal according to standard
> conventions.
Hurrah! Except that there's a few small details, and one biggish
detail that concern me.
> Property names have been limited to start with
> characters from the set [a-zA-Z,._#?]. That is, the
> digits and the expression symbols have been removed.
Good call. Note that the rationale for the property and node name
regexes is a bit fuzzy: there's a standard for what's allowed in
IEEE1275, but existing IBM and Apple device trees break it in a number
of ways.
> Use of "d#', "o#", "h#" and "b#" are gone in version 1.
Also good. We might want to keep b#, since there's no C way of doing
binary literals, but in that case I'd suggest recognizing it at the
lexical level, not the grammar level as we do now (which would mean a
space between the b# and the digits would no longer be permissible).
> Several warnings are introduced for debatable constructs.
>
> - Only /dts-version/ 0 and 1 are supported yet.
>
> - A missing /dts-version/ statement garners a
> suggestion to add one, and defaults to verion 0.
>
> - The /memreserve/ construct using "-" for ranges looks
> suspiciously like the subtraction of two expressions,
> so its syntax has been changed to use ".." as the range
> indicator.
Ah, yes. An irritating change, but a necessary one, I agree.
Now my big concern with this patch: the dts_version global, set by the
parser, used by the lexer. I assume you've tested this and it works
in practice, but you're relying on the semantic action from the .y
file being executed before the lexer meets any token that depends on
it.
I don't know about you, but I have to think pretty hard about how flow
of control will move between lexer and parser rules in a shift-reduce
parser at the best of times. With the %glr-parser option, bison will
use the Tomita algorithm. That means the parser state could be split
if there are ambiguities, or non-LALR(1) portions of the grammar
(which there are). In that case the execution of the parser rules
will be delayed until after the split is resolved again, however many
tokens down the track.
Now, I'll grant that such a grammar ambiguity is unlikely around the
version statement. But given the complexity of the situation, it
seems pretty risky to rely on execution ordering between parser and
lexer - I don't even know if there's a guarantee that bison won't
buffer lexer tokens before parsing them, which would screw us up in a
much less involved way.
Therefore, I'd prefer that instead of having this general version
number, we introduce a separate token for each new version. So
/dts-version-1/ or whatever. Any new, incompatible, dts version is a
big deal in any case - not something we want to happen often - so a
new token for each version is not a big deal, I think. With this
approach, the version flag can be tripped in the lexer, and the
ordering of lexer rule execution is obvious.
A few more minor comments below:
[snip]
> diff --git a/dtc-lexer.l b/dtc-lexer.l
> index 278a96e..a1c52c4 100644
> --- a/dtc-lexer.l
> +++ b/dtc-lexer.l
> @@ -22,12 +22,19 @@
>
> %x INCLUDE
> %x CELLDATA
> +%x CELLDATA_LEGACY
> %x BYTESTRING
> +%x BYTESTRING_LEGACY
> %x MEMRESERVE
> +%x MEMRESERVE_LEGACY
With the new syntax, integeral literals should no longer be ambiguous
with property or node names. Therefore, we should only need legacy
CELLDATA and MEMRESERVE states, new-style literals can be recognized
in INITIAL state.
I'm also inclined to leave the syntax for bytestrings as it is, in
whichcase we should only need one lexical state for that, too.
[snip]
> +<*>{DOT}{DOT} {
You should be able to just use \.\. or ".." here rather than having to
indirect through a character class.
[snip]
> +0(x|X){HEXDIGIT}+ {
Does C recognize both 0x and 0X, or just 0x? I don't remember off the
top of my head.
[snip]
> +u64 expr_from_string(char *s, unsigned int base)
> +{
> + u64 v;
> + char *e;
> +
> + v = strtoull(s, &e, base);
> + if (*e) {
> + fprintf(stderr,
> + "Line %d: Invalid literal value '%s' : "
> + "%c is not a base %d digit; %lld assumed\n",
> + yylloc.first_line, s, *e,
> + base == 0 ? expr_default_base : base,
> + (unsigned long long) v);
Do we need this error checking? Won't the regexes mean that the
string *must* be a valid literal by this point?
[snip]
> @@ -46,25 +47,27 @@ extern struct boot_info *the_boot_info;
> int hexlen;
> u64 addr;
> struct reserve_info *re;
> + u64 ire;
What's "ire" supposed to be short for?
[snip]
> + | label DT_MEMRESERVE expr '-' expr ';'
Oh.. you haven't actually abolished the '-' syntax, even in version 1
mode. Since we're already making an incompatible syntax change, we
should really make this one at the same time.
[snip]
> +cell:
> + expr
> + {
> + $$ = expr_cell_value($1);
> + }
> + ;
> +
> +expr:
> + expr_primary
> + ;
> +
> +expr_primary:
> + opt_cell_base DT_LITERAL
> + {
> + $$ = $2;
> + }
Hrm. I realise you haven't actually implemented expressions here, but
I think these names suggest a wrong direction. I think we should only
allow literals and bracketed expressions in celldata, not bare
expressions. Why? Because mistaking the following:
<0x00000000 0xf0000000 + 0x00001000 0x80000000>
as being 4 rather than 3 cells long is rather easier than mistaking:
<0x00000000 (0xf0000000 + 0x00001000) 0x80000000>
[snip[
> bytestring:
> - bytestring DT_BYTE
> + bytestring expr
Urg... I don't know that allowing expressions in bytestrings is not a
very good idea. Better, I think to keep the existing syntax here, and
just think of [abcd1234deadbeef] as a rather long sort of literal
itself.
[snip]
> +void yywarn(char const *s, ...)
Ick.. we can tolerate yyblah() names for the things we inherit from
yacc, but lets not introduce our own, hey.
[snip]
> +unsigned int dts_version = 0;
> +unsigned int expr_default_base = 10;
> +
> +
> +void set_dts_version(u64 vers)
> +{
> + if (vers > 1) {
> + yywarn("Unknown version %lld; 0 assumed\n", vers);
> + dts_version = 0;
> + } else {
> + dts_version = vers;
> + }
> +
> + if (dts_version == 0) {
> + expr_default_base = 16;
> + in_lexer_use_base = 16;
> + } else {
> + expr_default_base = 10;
> + in_lexer_use_base = 10;
Uh.. I don't think we should need either of expr_default_base and
in_lexer_use_base, let alone both..
[snip]
> - fprintf(f, "%x", be32_to_cpu(*cp++));
> + if (dts_version == 0) {
Where does dts_version get set in the -Odts case?
--
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
^ permalink raw reply
* Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
From: David Gibson @ 2007-10-20 7:19 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IivsP-00078Q-Hf@jdl.com>
On Fri, Oct 19, 2007 at 12:43:13PM -0500, Jon Loeliger wrote:
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Hrm.... I'm very dubious about this.
What compiler/platform is this? I can't off the top of my head think
of one where size_t shouldn't be promoted to int automatically.
Or there's the %z modifier, which explicitly specifies a size_t, but
I'm not sure if that's C99 or a glibc extension.
> ---
> tests/get_name.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tests/get_name.c b/tests/get_name.c
> index 2481741..a76bdf8 100644
> --- a/tests/get_name.c
> +++ b/tests/get_name.c
> @@ -55,7 +55,7 @@ void check_name(void *fdt, const char *path)
>
> if (len != strlen(getname))
> FAIL("fdt_get_name(%s) returned length %d instead of %d",
> - path, len, strlen(getname));
> + path, len, (int) strlen(getname));
>
> /* Now check that it doesn't break if we omit len */
> getname2 = fdt_get_name(fdt, offset, NULL);
--
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
^ permalink raw reply
* Re: [PATCH 2/4] DTC: Quiet a bogus "May be used uninitialized" warning.
From: David Gibson @ 2007-10-20 7:16 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IivsA-00078F-ST@jdl.com>
On Fri, Oct 19, 2007 at 12:42:58PM -0500, Jon Loeliger wrote:
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
I don't like this one much. The warning is indeed bogus, and my
compiler version, at least, doesn't generate it
mulberryst:~/dtc$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Putting in the initializer would mean that even on non-broken
compilers, we wouldn't get the warning if we ever changed the
contained code so that it really should generate an unitialized
variable warning.
--
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
^ permalink raw reply
* Re: [PATCH 1/4] DTC: Reformat grammar rules to not mix language syntax and yacc syntax.
From: David Gibson @ 2007-10-20 7:12 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Iivrk-000784-OB@jdl.com>
On Fri, Oct 19, 2007 at 12:42:32PM -0500, Jon Loeliger wrote:
>
> Use consistent indenting on all rule actions.
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Meh, I kind of did it that way to keep the simple rules less bulky,
but I don't really care much either way.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
^ permalink raw reply
* Re: embedded a default dtb in the kernel (was merge dtc)
From: David Gibson @ 2007-10-20 7:11 UTC (permalink / raw)
To: Leisner, Martin; +Cc: linuxppc-dev
In-Reply-To: <556445368AFA1C438794ABDA8901891C075945FD@USA0300MS03.na.xerox.net>
On Fri, Oct 19, 2007 at 02:30:28PM -0400, Leisner, Martin wrote:
> Is there a way to embed a default dtb into the kernel?
> When I build a kernel, I want to embed a dtb into it --
> so I don't have to deal with the headaches of finding the
> right file to match the right board (its always easier to
> deal with 1 file than 2).
You can't embed a dtb in the vmlinux, but zImages routinely contain an
embedded dtb.
--
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
^ permalink raw reply
* Re: embedded a default dtb in the kernel (was merge dtc)
From: David Gibson @ 2007-10-20 7:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Leisner, Martin
In-Reply-To: <fa686aa40710191209u883b3d0r954e7b3d6d1b8d12@mail.gmail.com>
On Fri, Oct 19, 2007 at 01:09:39PM -0600, Grant Likely wrote:
> On 10/19/07, Leisner, Martin <Martin.Leisner@xerox.com> wrote:
> > Is there a way to embed a default dtb into the kernel?
> > When I build a kernel, I want to embed a dtb into it --
> > so I don't have to deal with the headaches of finding the
> > right file to match the right board (its always easier to
> > deal with 1 file than 2).
> >
> > If there is, it makes sense to put dtc into the tree.
> > If there's not, there should be a way to embed dtb's; and put
> > dtc and dts's into the tree.
> > If there can't be (I haven't examined this but relaying my
> > experiences), then it should be in a separate repository
> > (but the DTS and DTC should be in one place).
> > It was a little difficult to cobble together a working
> > system the first time.
> >
> > Also, mkimage SHOULD definitely go in the tree. Its necessary
> > to build, hence should be in the tree...
>
> Why? mkimage is u-boot specific, and hence is maintained by u-boot.
> If you're not using u-boot, then you don't need mkimage. What is
> wrong with it being a prereq like all the other tools we use? If
> you're doing embedded development, you're installing non-distribution
> cross toolchain anyway.
The problem is that we build uImages at present, without option, for a
bunch of targets that don't necessarily have u-boot.
> dtc and mkimage are embedded development tools. They belong with the
> embedded development toolchain. mkimage is already part of ELDK.
dtc isn't just for embedded. ps3 uses it already, and more may well
do so in future.
--
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
^ permalink raw reply
* Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Michal Simek @ 2007-10-20 7:05 UTC (permalink / raw)
To: Grant Likely
Cc: Leonid, Arnd Bergmann, microblaze-uclinux, linuxppc-dev,
Wolfgang Reissnegger
In-Reply-To: <fa686aa40710192247u294b9329p538bbaf715610040@mail.gmail.com>
Hi Grant,
>> Hi Steve and all,
>> >Here's a full .dts generated using an updated version of
>> >gen_mhs_devtree.py, following the proposal.
>> >It happens to be a microblaze system, but you get the idea.
>>
>> I think that is no good idea generate dts with all information.
>> Especially information about PVR - number 2 means - Full PVR and you can
>> obtain information directly from PVR. It is waste of memory space.
>> xilinx,pvr = <2>;
>>
>> In my opinion will be better generate only parameters which you want not all.
>> That smells with unusable parameters.
>
>That is the hard part about crafting the dts; deciding which
>parameters the OS is going to care about and which ones are
>irrelevant. The goal is to sufficiently and uniquely describe the
>board so that the OS can easily figure out what exactly what it needs
>to do to drive the board, but not to try and describe every aspect
>which it knows about. Anything that is pollable (ie. USB devices)
>doesn't need to be in the tree.
>
>It's also important to remember that the device tree will *never* be
>perfect. Eventually something will come up that the device tree
>doesn't describe well(a bug/quirk, something described poorly, etc).
>In this case, as long as the device tree is specific enough to
>identify which version of the board it is running on; we can alwasy
>add platform specific fixups for that unique system.
>
yes, but I think that is the right time to specify which parameters are relevant.
I will focus on in EDK renerator.
Michal Simek
^ 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