Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
On Thursday 03 January 2008, Li Li wrote: * The detection method for the primary bus is somewhat fragile, because we depend on the order of the nodes in the device tree, which is not specified to have a meaning. /Maybe/ there could be a property in (at most) one of the PCI host bridge nodes saying that this specific bus is the primary one. Put this primary in code is more save than in dts. The dts lacks error checking function. If provide error dts such as two pci hosts both has primary property will occur chaos. 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. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
On Thu, 2008-01-03 at 16:14 +0800, Arnd Bergmann wrote: On Thursday 03 January 2008, Li Li wrote: * The detection method for the primary bus is somewhat fragile, because we depend on the order of the nodes in the device tree, which is not specified to have a meaning. /Maybe/ there could be a property in (at most) one of the PCI host bridge nodes saying that this specific bus is the primary one. Put this primary in code is more save than in dts. The dts lacks error checking function. If provide error dts such as two pci hosts both has primary property will occur chaos. 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. - Tony ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
On 1/2/08, Grant Likely [EMAIL PROTECTED] wrote:
On 1/2/08, Jon Smirl [EMAIL PROTECTED] wrote:
On 1/2/08, Timur Tabi [EMAIL PROTECTED] 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).
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Outstanding DTC patches?
On Wed, Jan 02, 2008 at 12:21:02PM -0600, Jon Loeliger wrote:
Folks,
I'd like to release a DTC 1.1 Real Soon Now!
However, I've been back-logged due to the holidays.
If you have any outstanding DTC or libfdt patches
that I have not yet applied and that you would like
in that release, please remind me by reposting it
and CC:'ing [EMAIL PROTECTED]
I posted this one a while back, but I guess it dropped through the
cracks. 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.
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 [EMAIL PROTECTED]
Index: dtc/flattree.c
===
--- dtc.orig/flattree.c 2007-12-08 12:06:11.0 +1100
+++ dtc/flattree.c 2007-12-08 12:13:15.0 +1100
@@ -898,15 +898,6 @@
off_mem_rsvmap = be32_to_cpu(fdt-off_mem_rsvmap);
version = be32_to_cpu(fdt-version);
- fprintf(stderr, \tmagic:\t\t\t0x%x\n, magic);
- fprintf(stderr, \ttotalsize:\t\t%d\n, totalsize);
- fprintf(stderr, \toff_dt_struct:\t\t0x%x\n, off_dt);
- fprintf(stderr, \toff_dt_strings:\t\t0x%x\n, off_str);
- fprintf(stderr, \toff_mem_rsvmap:\t\t0x%x\n, off_mem_rsvmap);
- fprintf(stderr, \tversion:\t\t0x%x\n, version );
- fprintf(stderr, \tlast_comp_version:\t0x%x\n,
- be32_to_cpu(fdt-last_comp_version));
-
if (off_mem_rsvmap = totalsize)
die(Mem Reserve structure offset exceeds total size\n);
@@ -916,21 +907,15 @@
if (off_str totalsize)
die(String table offset exceeds total size\n);
- if (version = 2)
- fprintf(stderr, \tboot_cpuid_phys:\t0x%x\n,
- be32_to_cpu(fdt-boot_cpuid_phys));
-
size_str = -1;
if (version = 3) {
size_str = be32_to_cpu(fdt-size_dt_strings);
- fprintf(stderr, \tsize_dt_strings:\t%d\n, size_str);
if (off_str+size_str totalsize)
die(String table extends past total size\n);
}
if (version = 17) {
size_dt = be32_to_cpu(fdt-size_dt_struct);
- fprintf(stderr, \tsize_dt_struct:\t\t%d\n, size_dt);
if (off_dt+size_dt totalsize)
die(Structure block extends past total size\n);
}
Index: dtc/ftdump.c
===
--- dtc.orig/ftdump.c 2007-12-08 12:06:23.0 +1100
+++ dtc/ftdump.c2007-12-08 12:15:09.0 +1100
@@ -81,11 +81,13 @@
static void dump_blob(void *blob)
{
struct fdt_header *bph = blob;
+ uint32_t off_mem_rsvmap = be32_to_cpu(bph-off_mem_rsvmap);
+ uint32_t off_dt = be32_to_cpu(bph-off_dt_struct);
+ uint32_t off_str = be32_to_cpu(bph-off_dt_strings);
struct fdt_reserve_entry *p_rsvmap =
- (struct fdt_reserve_entry *)(blob
-+
be32_to_cpu(bph-off_mem_rsvmap));
- char *p_struct = blob + be32_to_cpu(bph-off_dt_struct);
- char *p_strings = blob + be32_to_cpu(bph-off_dt_strings);
+ (struct fdt_reserve_entry *)(blob + off_mem_rsvmap);
+ char *p_struct = blob + off_dt;
+ char *p_strings = blob + off_str;
uint32_t version = be32_to_cpu(bph-version);
uint32_t totalsize = be32_to_cpu(bph-totalsize);
uint32_t tag;
@@ -98,8 +100,26 @@
depth = 0;
shift = 4;
- printf(// Version 0x%x tree\n, version);
- printf(// Totalsize 0x%x(%d)\n, totalsize, totalsize);
+ printf(// magic:\t\t0x%x\n, be32_to_cpu(bph-magic));
+ printf(// totalsize:\t\t0x%x (%d)\n, totalsize, totalsize);
+ printf(// off_dt_struct:\t0x%x\n, off_dt);
+ printf(// off_dt_strings:\t0x%x\n, off_str);
+ printf(// off_mem_rsvmap:\t0x%x\n, off_mem_rsvmap);
+ printf(// version:\t\t%d\n, version);
+ printf(// last_comp_version:\t%d\n,
+ be32_to_cpu(bph-last_comp_version));
+ if (version = 2)
+ printf(// boot_cpuid_phys:\t0x%x\n,
+ be32_to_cpu(bph-boot_cpuid_phys));
+
+ if (version = 3)
+ printf(// size_dt_strings:\t0x%x\n,
+ be32_to_cpu(bph-size_dt_strings));
+ if (version = 17)
+ printf(// size_dt_struct:\t0x%x\n,
+ be32_to_cpu(bph-size_dt_struct));
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
On 12/19/07, Timur Tabi [EMAIL PROTECTED] 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.
+ [EMAIL PROTECTED] {
+ 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.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Test (Was: Re: [PATCH] [POWERPC] Check that the syscall table matches the syscall )
On Thu, 3 Jan 2008 01:32:21 -0600 Milton Miller [EMAIL PROTECTED] wrote: Hmmm, in-reply-to on the web archive is broken again, sfr alerted. Just a test ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv3] powerpc: DBox2 Board Support
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 /
+[EMAIL PROTECTED],0 {
+compatible = cfi-flash;
+reg = 0 0 80;
+bank-width = 4;
+device-width = 1;
+#address-cells = 1;
+#size-cells = 1;
+[EMAIL PROTECTED] {
+label = BR bootloader;
+reg = 0 2;
+read-only;
+};
+[EMAIL PROTECTED] {
+label = FLFS (U-Boot);
+reg = 2 2;
+};
+[EMAIL PROTECTED] {
+label = rootfs;
+reg = 4 7c;
+};
+[EMAIL PROTECTED] {
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 = 2 7e;
+};
+[EMAIL PROTECTED] {
+label = Complete Flash;
+reg = 0 80;
+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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Outstanding DTC patches?
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 [EMAIL PROTECTED] Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/2/08, David Gibson [EMAIL PROTECTED] wrote:
On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
On 1/2/08, Grant Likely [EMAIL PROTECTED] wrote:
On 1/2/08, Jon Smirl [EMAIL PROTECTED] wrote:
On 1/2/08, Timur Tabi [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Book-E watchdog driver questions
On Sep 25, 2007 1:18 PM, Mike Nuss [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC] small ftdump cleanup patch
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/2/08, David Gibson [EMAIL PROTECTED] wrote:
On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
On 12/19/07, Timur Tabi [EMAIL PROTECTED] 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.
+ [EMAIL PROTECTED] {
+ 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
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[DTC] small ftdump cleanup patch
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);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC] small ftdump cleanup patch
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.
From cef80fcd1efddaebcb366fb897430260cebb0c84 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: #address-cells #size-cells properties not inherited
From: Mark A. Greer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] --- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: #address-cells #size-cells properties not inherited
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 [EMAIL PROTECTED] wrote: From: Mark A. Greer [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: #address-cells #size-cells properties not inherited
On Thu, 3 Jan 2008 08:32:56 -0700 Mark A. Greer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: From: Mark A. Greer [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
On Wed, Jan 02, 2008 at 12:32:51PM -0700, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] Signed-off-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/platforms/8xx/ep88xc.c |5 ++--- arch/powerpc/platforms/8xx/mpc885ads_setup.c |5 ++--- How about mpc86xads_setup.c? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
On 1/3/08, Scott Wood [EMAIL PROTECTED] wrote: On Wed, Jan 02, 2008 at 12:32:51PM -0700, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] Signed-off-by: Grant Likely [EMAIL PROTECTED] --- 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. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Jon Smirl wrote:
On 1/2/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 1/1/08, Jon Smirl [EMAIL PROTECTED] wrote:
On 12/19/07, Timur Tabi [EMAIL PROTECTED] wrote:
+ [EMAIL PROTECTED] {
+ 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/3/08, Timur Tabi [EMAIL PROTECTED] 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. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/3/08, Timur Tabi [EMAIL PROTECTED] 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. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: 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. I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so the only way to make this code work is to bend some rules. Right now, the CS4270 driver does not support platform drivers or the device tree, so there's no point in putting a child I2C node for it. As I mentioned in other posts, I will be more than happy to update the CS4270 driver to support this new paradigm (which was invented after the CS4270 driver was written) *after* this current patchset is applied. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Mark Brown wrote: clock1 = 0, bb8000 Would that be better? To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like... The ASoC V1 API for communicating clock data from the fabric driver to the codec driver only allows for three parameters. According to the documentation in your patch the bus frequency should already be optional My code does not currently support that configuration, and I don't have any hardware that works that way, so I don't know what it would look like. I'm just trying to make the driver as flexible as possible, given ASoC V1 constraints. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
Scott Wood wrote:
+static struct of_platform_driver ucc_uart_of_driver = {
+ .owner = THIS_MODULE,
+ .name = ucc_uart,
Maybe better fsl,ucc_uart?
fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
Wait, I'm confused. What does the of_platform_driver.name string have to do
with the compatible field in the device tree? Like I said earlier, I'm just
following the example of the other QE device drivers. If you want me to break
that example, I'm going to need an explanation why the other drivers do it
wrong.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/3/08, Timur Tabi [EMAIL PROTECTED] wrote: 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. Heh, I've seen enough to know that it's virtually impossible for a company to maintain a consistent naming scheme all the time. Better to be specific now and add generic names sometime in the future rather than the other way around. 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. The have the device trees claim compatibility with the older fsl,mpc8610-ssi device specifically. ie: compatible = fsl,mpc83whatever-ssi,ac97, fsl,mpc8610-ssi,ac97; 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? Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = fsl,mpc8610-ssi,i2s. Or for AC7, compatible = fsl,mpc8610-ssi,ac97 Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
Timur Tabi wrote:
Scott Wood wrote:
+static struct of_platform_driver ucc_uart_of_driver = {
+.owner = THIS_MODULE,
+.name = ucc_uart,
Maybe better fsl,ucc_uart?
fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
Wait, I'm confused. What does the of_platform_driver.name string have
to do with the compatible field in the device tree?
Bah. Details.
/me resolves to read the context next time.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/3/08, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: 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. I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so the only way to make this code work is to bend some rules. Right now, the CS4270 driver does not support platform drivers or the device tree, so there's no point in putting a child I2C node for it. As I mentioned in other posts, I will be more than happy to update the CS4270 driver to support this new paradigm (which was invented after the CS4270 driver was written) *after* this current patchset is applied. If you need to bend rules, then do it in a place where it won't bite us in the butt down the road. (ie. not with the device tree). Do hacky stuff in the platform code if you need to because it can be changed easily down the road. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/3/08, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = fsl,mpc8610-ssi,i2s. Or for AC7, compatible = fsl,mpc8610-ssi,ac97 That won't work. There are too many variations. I think a separate property just makes more sense. Frankly, I don't see what's wrong with it. Sure it will, that's exactly what I'm doing with the 5200, but I won't argue the point. My *opinion* is that using compatible is a more elegant approach for this type of multifunction device, but using a mode property is neither wrong or bad. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: On 1/3/08, Timur Tabi [EMAIL PROTECTED] 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. I'd just link in both directions, and let software follow it in whichever direction it prefers. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = fsl,mpc8610-ssi,i2s. Or for AC7, compatible = fsl,mpc8610-ssi,ac97 That won't work. There are too many variations. I think a separate property just makes more sense. Frankly, I don't see what's wrong with it. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: On 1/3/08, Scott Wood [EMAIL PROTECTED] wrote: I'd just link in both directions, and let software follow it in whichever direction it prefers. Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings. Software is, however, lousy at correctly wading through poorly-structured data (which device trees are full of) to figure out how to locate the link it wants to follow backwards. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/3/08, Scott Wood [EMAIL PROTECTED] wrote: Grant Likely wrote: On 1/3/08, Timur Tabi [EMAIL PROTECTED] 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. I'd just link in both directions, and let software follow it in whichever direction it prefers. Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings. Don't put that burden on the dts author. (the software principle of defining things in one place only applies here) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: #address-cells #size-cells properties not inherited
On Wed, Jan 02, 2008 at 05:07:50PM -0700, Mark A. Greer wrote: From: Mark A. Greer [EMAIL PROTECTED] 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. For small values of enforce; it's a warning only. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Forward event client-reregister-required to registered clients
Hi Roland, Just want to make sure you've seen this patch and if it looks ok for you. Thanks Nam On Thursday 20 December 2007 15:06, Hoang-Nam Nguyen wrote: This patch allows ehca to forward event client-reregister-required to registered clients. Such one event is generated by the switch eg. after its reboot. Signed-off-by: Hoang-Nam Nguyen [EMAIL PROTECTED] --- drivers/infiniband/hw/ehca/ehca_irq.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCh v3] powerpc: add hugepagesz boot-time parameter
Paul, please include this in 2.6.25 if there are no objections.
This patch adds the hugepagesz boot-time parameter for ppc64. It lets
one pick the size for huge pages. The choices available are 64K and 16M
when the base page size is 4k. It defaults to 16M (previously the only
only choice) if nothing or an invalid choice is specified.
Tested 64K huge pages successfully with the libhugetlbfs 1.2.
Changes from v2:
Moved functions from header file into hugetlbpage.c where they are used.
Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 33121d6..2fc1fb8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in
the file
See Documentation/isdn/README.HiSax.
hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
+ hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
i8042.direct[HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index cbbd8b0..9326a69 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -369,18 +369,11 @@ static void __init htab_init_page_sizes(void)
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
- mmu_huge_psize = MMU_PAGE_16M;
+ set_huge_psize(MMU_PAGE_16M);
/* With 4k/4level pagetables, we can't (for now) cope with a
* huge page size PMD_SIZE */
else if (mmu_psize_defs[MMU_PAGE_1M].shift)
- mmu_huge_psize = MMU_PAGE_1M;
-
- /* Calculate HPAGE_SHIFT and sanity check it */
- if (mmu_psize_defs[mmu_huge_psize].shift MIN_HUGEPTE_SHIFT
- mmu_psize_defs[mmu_huge_psize].shift SID_SHIFT)
- HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift;
- else
- HPAGE_SHIFT = 0; /* No huge pages dude ! */
+ set_huge_psize(MMU_PAGE_1M);
#endif /* CONFIG_HUGETLB_PAGE */
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 71efb38..a02266d 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -24,18 +24,17 @@
#include asm/cputable.h
#include asm/spu.h
+#define HPAGE_SHIFT_64K16
+#define HPAGE_SHIFT_16M24
+
#define NUM_LOW_AREAS (0x1UL SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE HTLB_AREA_SHIFT)
-#ifdef CONFIG_PPC_64K_PAGES
-#define HUGEPTE_INDEX_SIZE (PMD_SHIFT-HPAGE_SHIFT)
-#else
-#define HUGEPTE_INDEX_SIZE (PUD_SHIFT-HPAGE_SHIFT)
-#endif
-#define PTRS_PER_HUGEPTE (1 HUGEPTE_INDEX_SIZE)
-#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) HUGEPTE_INDEX_SIZE)
+unsigned int hugepte_shift;
+#define PTRS_PER_HUGEPTE (1 hugepte_shift)
+#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) hugepte_shift)
-#define HUGEPD_SHIFT (HPAGE_SHIFT + HUGEPTE_INDEX_SIZE)
+#define HUGEPD_SHIFT (HPAGE_SHIFT + hugepte_shift)
#define HUGEPD_SIZE(1UL HUGEPD_SHIFT)
#define HUGEPD_MASK(~(HUGEPD_SIZE-1))
@@ -82,11 +81,35 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t
*hpdp,
return 0;
}
+/* Base page size affects how we walk hugetlb page tables */
+#ifdef CONFIG_PPC_64K_PAGES
+#define hpmd_offset(pud, addr) pmd_offset(pud, addr)
+#define hpmd_alloc(mm, pud, addr) pmd_alloc(mm, pud, addr)
+#else
+static inline
+pmd_t *hpmd_offset(pud_t *pud, unsigned long addr)
+{
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ return pmd_offset(pud, addr);
+ else
+ return (pmd_t *) pud;
+}
+static inline
+pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr)
+{
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ return pmd_alloc(mm, pud, addr);
+ else
+ return (pmd_t *) pud;
+}
+#endif
+
/* Modelled after find_linux_pte() */
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pg;
pud_t *pu;
+ pmd_t *pm;
BUG_ON(get_slice_psize(mm, addr) != mmu_huge_psize);
@@ -96,14 +119,9 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long
addr)
if (!pgd_none(*pg)) {
pu = pud_offset(pg, addr);
if (!pud_none(*pu)) {
-#ifdef CONFIG_PPC_64K_PAGES
- pmd_t *pm;
- pm = pmd_offset(pu, addr);
+ pm = hpmd_offset(pu, addr);
if (!pmd_none(*pm))
return hugepte_offset((hugepd_t *)pm, addr);
-#else
- return hugepte_offset((hugepd_t *)pu, addr);
-#endif
}
}
@@ -114,6 +132,7 @@ pte_t
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote: Mark Brown wrote: To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like... The ASoC V1 API for communicating clock data from the fabric driver to the codec driver only allows for three parameters. Each individual call to set_sysclk() only takes three parameters but it can be called repeatedly and some configurations are going to require this. There's also the set_pll() call which will be required by some things too (and again that can support multiple PLLs). For example, something like this isn't unknown: - Set PLL input to pin A. - Configure PLL input/output frequencies. - Set codec system clock source to be the PLL and of course the ordering matters. You can also have other dividers and clock sources within the codec which need configuring and other components outside the codec which need configuring to supply the clocks to the codec. According to the documentation in your patch the bus frequency should already be optional My code does not currently support that configuration, and I don't have any hardware that works that way, so I don't know what it would look like. I'm just trying to make the driver as flexible as possible, given ASoC V1 constraints. Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 01:18:31PM -0600, Scott Wood wrote: Grant Likely wrote: Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings. Software is, however, lousy at correctly wading through poorly-structured data (which device trees are full of) to figure out how to locate the link it wants to follow backwards. Thinking about that from an ASoC v2 perspective the approach that this immediately suggests is to represent the links between the devices in the device tree and then have those links reference the attached devices. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] Add yyerrorf() for formatted error messages.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
dtc-parser.y | 16 +---
srcpos.h |1 +
treesource.c |1 -
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 002ea7f..ddb7f27 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -307,15 +307,25 @@ label:
%%
-void yyerror (char const *s)
+void yyerrorf(char const *s, ...)
{
const char *fname = srcpos_filename_for_num(yylloc.filenum);
+ va_list va;
+ va_start(va, s);
if (strcmp(fname, -) == 0)
fname = stdin;
- fprintf(stderr, %s:%d %s\n,
- fname, yylloc.first_line, s);
+ fprintf(stderr, %s:%d , fname, yylloc.first_line);
+ vfprintf(stderr, s, va);
+ fprintf(stderr, \n);
+
+ va_end(va);
+}
+
+void yyerror (char const *s)
+{
+ yyerrorf(%s, s);
}
unsigned long long eval_literal(const char *s, int base, int bits)
diff --git a/srcpos.h b/srcpos.h
index ce7ab5b..e59c788 100644
--- a/srcpos.h
+++ b/srcpos.h
@@ -63,6 +63,7 @@ typedef struct YYLTYPE {
extern void yyerror(char const *);
+extern void yyerrorf(char const *, ...) __attribute__((format(printf, 1, 2)));
extern int srcpos_filenum;
diff --git a/treesource.c b/treesource.c
index a6a7767..e7d580f 100644
--- a/treesource.c
+++ b/treesource.c
@@ -23,7 +23,6 @@
extern FILE *yyin;
extern int yyparse(void);
-extern void yyerror(char const *);
struct boot_info *the_boot_info;
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] Return a non-zero exit code if an error occurs during dts parsing.
Previously, only failure to parse caused the reading of the tree to fail;
semantic errors that called yyerror() but not YYERROR only emitted a message,
without signalling make to stop the build.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
dtc-parser.y |2 ++
dtc.c|2 +-
dtc.h|1 +
livetree.c |1 +
treesource.c |3 +++
5 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index 8ed58e8..da7f6f5 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -28,6 +28,7 @@ int yylex(void);
unsigned long long eval_literal(const char *s, int base, int bits);
extern struct boot_info *the_boot_info;
+extern int treesource_error;
%}
@@ -320,6 +321,7 @@ void yyerrorf(char const *s, ...)
vfprintf(stderr, s, va);
fprintf(stderr, \n);
+ treesource_error = 1;
va_end(va);
}
diff --git a/dtc.c b/dtc.c
index fb716f3..c1814c1 100644
--- a/dtc.c
+++ b/dtc.c
@@ -205,7 +205,7 @@ int main(int argc, char *argv[])
if (inf inf-file != stdin)
fclose(inf-file);
- if (! bi || ! bi-dt)
+ if (! bi || ! bi-dt || bi-error)
die(Couldn't read input tree\n);
process_checks(force, bi);
diff --git a/dtc.h b/dtc.h
index 9b89689..cba9d28 100644
--- a/dtc.h
+++ b/dtc.h
@@ -233,6 +233,7 @@ struct reserve_info *add_reserve_entry(struct reserve_info
*list,
struct boot_info {
struct reserve_info *reservelist;
struct node *dt;/* the device tree */
+ int error;
};
struct boot_info *build_boot_info(struct reserve_info *reservelist,
diff --git a/livetree.c b/livetree.c
index 6ba0846..7610e78 100644
--- a/livetree.c
+++ b/livetree.c
@@ -172,6 +172,7 @@ struct boot_info *build_boot_info(struct reserve_info
*reservelist,
bi = xmalloc(sizeof(*bi));
bi-reservelist = reservelist;
bi-dt = tree;
+ bi-error = 0;
return bi;
}
diff --git a/treesource.c b/treesource.c
index e7d580f..980bda7 100644
--- a/treesource.c
+++ b/treesource.c
@@ -25,10 +25,12 @@ extern FILE *yyin;
extern int yyparse(void);
struct boot_info *the_boot_info;
+int treesource_error;
struct boot_info *dt_from_source(const char *fname)
{
the_boot_info = NULL;
+ treesource_error = 0;
push_input_file(fname);
@@ -37,6 +39,7 @@ struct boot_info *dt_from_source(const char *fname)
fill_fullpaths(the_boot_info-dt, );
+ the_boot_info-error = treesource_error;
return the_boot_info;
}
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] Look for include files in the directory of the including file.
Looking in the diretory dtc is invoked from is not very useful behavior.
As part of the code reorganization to implement this, I removed the
uniquifying of name storage -- it seemed a rather dubious optimization
given likely usage, and some aspects of it would have been mildly awkward
to integrate with the new code.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
dtc-lexer.l | 64 +
dtc-parser.y |2 +-
dtc.c| 14 --
srcpos.c | 126 +++---
srcpos.h | 28 +
5 files changed, 134 insertions(+), 100 deletions(-)
diff --git a/dtc-lexer.l b/dtc-lexer.l
index c811b22..bfb996e 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -74,7 +74,7 @@ static int dts_version; /* = 0 */
}
*\([^\\]|\\.)*\ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT(String: %s\n, yytext);
yylval.data = data_copy_escape_string(yytext+1,
@@ -84,7 +84,7 @@ static int dts_version; /* = 0 */
}
*/dts-v1/ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT(Keyword: /dts-v1/\n);
dts_version = 1;
@@ -93,7 +93,7 @@ static int dts_version; /* = 0 */
}
*/memreserve/ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT(Keyword: /memreserve/\n);
BEGIN_DEFAULT();
@@ -101,7 +101,7 @@ static int dts_version; /* = 0 */
}
*{LABEL}:{
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT(Label: %s\n, yytext);
yylval.labelref = strdup(yytext);
@@ -110,7 +110,7 @@ static int dts_version; /* = 0 */
}
INITIAL[bodh]# {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
if (*yytext == 'b')
yylval.cbase = 2;
@@ -125,7 +125,7 @@ static int dts_version; /* = 0 */
}
INITIAL[0-9a-fA-F]+ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yylval.literal = strdup(yytext);
DPRINT(Literal: '%s'\n, yylval.literal);
@@ -133,7 +133,7 @@ static int dts_version; /* = 0 */
}
V1[0-9]+|0[xX][0-9a-fA-F]+ {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yylval.literal = strdup(yytext);
DPRINT(Literal: '%s'\n, yylval.literal);
@@ -141,7 +141,7 @@ static int dts_version; /* = 0 */
}
\{LABEL} { /* label reference */
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT(Ref: %s\n, yytext+1);
yylval.labelref = strdup(yytext+1);
@@ -149,7 +149,7 @@ static int dts_version; /* = 0 */
}
{/{PATHCHAR}+\} { /* new-style path reference */
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yytext[yyleng-1] = '\0';
DPRINT(Ref: %s\n, yytext+2);
@@ -158,7 +158,7 @@ static int dts_version; /* = 0 */
}
INITIAL/{PATHCHAR}+ { /* old-style path reference */
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
DPRINT(Ref: %s\n, yytext+1);
yylval.labelref = strdup(yytext+1);
@@ -166,7 +166,7 @@ static int dts_version; /* = 0 */
}
BYTESTRING[0-9a-fA-F]{2} {
- yylloc.filenum = srcpos_filenum;
+ yylloc.file = srcpos_file;
yylloc.first_line = yylineno;
yylval.byte = strtol(yytext, NULL, 16);
DPRINT(Byte: %02x\n, (int)yylval.byte);
@@ -174,7 +174,7 @@ static int dts_version; /* = 0 */
}
BYTESTRING]{
-
Re: [PATCH 1/3] Add yyerrorf() for formatted error messages.
Scott Wood wrote: Signed-off-by: Scott Wood [EMAIL PROTECTED] --- dtc-parser.y | 16 +--- srcpos.h |1 + treesource.c |1 - 3 files changed, 14 insertions(+), 4 deletions(-) I forgot to tag them as such, but these are of course dtc patches and not Linux patches. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
On Thu, Jan 03, 2008 at 12:26:27PM -0600, Timur Tabi wrote:
Scott Wood wrote:
+static struct of_platform_driver ucc_uart_of_driver = {
+.owner = THIS_MODULE,
+.name = ucc_uart,
Maybe better fsl,ucc_uart?
fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
Wait, I'm confused. What does the of_platform_driver.name string have to do
with the compatible field in the device tree? Like I said earlier, I'm just
Eh, initially I meant compatible stuff, not the driver name. I've quoted
wrong code snippet, thus the confusion.
You're using ucc_uart for compatible matching:
+static struct of_device_id ucc_uart_match[] = {
+ {
+ .type = serial,
+ .compatible = ucc_uart,
here fsl,qe-uart will look better, no?
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ucc_uart_match);
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCh v3] powerpc: add hugepagesz boot-time parameter
On Thursday 03 January 2008, Jon Tollefson wrote: Paul, please include this in 2.6.25 if there are no objections. No objections to this version from me, just questions. This patch adds the hugepagesz boot-time parameter for ppc64. It lets one pick the size for huge pages. The choices available are 64K and 16M when the base page size is 4k. It defaults to 16M (previously the only only choice) if nothing or an invalid choice is specified. We started discussing this in v1, but the discussion got sidetracked: Is there a technical reason why you don't also allow 1M pages, which may be useful in certain scenarios? On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the second large page size is an option that can be set in a HID SPR to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously, but the firmware can change the default and put it into the device tree, or you could have the kernel override the firmware settings. Going a lot further, do you have plans for a fully dynamic hugepage size, e.g. using a mount option for hugetlbfs? I can see that as rather useful, but at the same time it's probably much more complicated than the boot time option. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC] small ftdump cleanup patch
On Thu, Jan 03, 2008 at 09:40:57AM -0500, Paul Gortmaker wrote: 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 ... I expect ftdump to stay around for the forseeable future as a hacking/debugging tool; the idea is that it will be able to tell you at least something about a malformed or corrupted dtb, whereas dtc is likely to choke before producing any output. Any non-debugging use is likely a mistake, though. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv3] powerpc: DBox2 Board Support
On Thu, Jan 03, 2008 at 12:46:23PM +0100, Jochen Friedrich wrote:
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 /
Ah. That should be gone in newer dtc versions. I'm pretty sure I got
rid of all checks that enforced the presence of particular properties,
precisely because they give frequent spurious errors when things are
supposed to be filled in by the bootloader.
[snip]
+ label = Flash without bootloader;
+ reg = 2 7e;
+ };
+ [EMAIL PROTECTED] {
+ label = Complete Flash;
+ reg = 0 80;
+ 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).
Heh. Wow. Safely? i.e. if you access one partition then later an
overlapping partition, is mtd guaranteed to get the necessary
synchronization right?
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote: 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. Nice idea in principle, and may be the way to go ultimately, but very tricky in practice. The whole reason the fabric driver concept exists (from other archs) is that there are an awful lot of variants on how to wire the sound components together. Devising a way of expressing those connections in the device tree that's sufficient will be very curly. Then we'd have to build the fabric driver that can parse and process them all. And then, people will no doubt produce device trees with errors in the connection information, so we'll still need platform-specific workarounds. If we want sound working any time soon, we'll want to stick with the platform based fabric drivers for the time being. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Outstanding DTC patches?
On Thu, Jan 03, 2008 at 08:14:53AM -0600, Jon Loeliger wrote: 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? Ah, I think I sent it by private mail, so it won't be in patchwork. Here you are: dtc/libfdt: Add README clarifying licensing The fact the dtc are distributed together, but have different licenses can be a bit confusing. Several people have enquired as to what the deal is with the libfdt licensing, so this patch adds a README clarifying the situation with a rationale. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/README.license === --- /dev/null 1970-01-01 00:00:00.0 + +++ dtc/README.license 2007-11-02 11:43:19.0 +1100 @@ -0,0 +1,56 @@ +Licensing and contribution policy of dtc and libfdt +=== + +This dtc package contains two pieces of software: dtc itself, and +libfdt which comprises the files in the libfdt/ subdirectory. These +two pieces of software, although closely related, are quite distinct. +dtc does not incoporate or rely on libfdt for its operation, nor vice +versa. It is important that these two pieces of software have +different license conditions. + +As the copyright banners in each source file attest, dtc is licensed +under the GNU GPL. The full text of the GPL can be found in the file +entitled 'GPL' which should be included in this package. dtc code, +therefore, may not be incorporated into works which do not have a GPL +compatible license. + +libfdt, however, is GPL/BSD dual-licensed. That is, it may be used +either under the terms of the GPL, or under the terms of the 2-clause +BSD license (aka the ISC license). The full terms of that license are +given in the copyright banners of each of the libfdt source files. +This is, in practice, equivalent to being BSD licensed, since the +terms of the BSD license are strictly more permissive than the GPL. + +I made the decision to license libfdt in this way because I want to +encourage widespread and correct usage of flattened device trees, +including by proprietary or otherwise GPL-incompatible firmware or +tools. Allowing libfdt to be used under the terms of the BSD license +makes that it easier for vendors or authors of such software to do so. + +This does mean that libfdt code could be stolen - say, included in a +proprietary fimware and extended without contributing those extensions +back to the libfdt mainline. While I hope that doesn't happen, I +believe the goal of allowing libfdt to be widely used is more +important than avoiding that. libfdt is quite small, and hardly +rocket science; so the incentive for such impolite behaviour is small, +and the inconvenience caused therby is not dire. + +Licenses such as the LGPL which would allow code to be used in non-GPL +software, but also require contributions to be returned were +considered. However, libfdt is designed to be used in firmwares and +other environments with unusual technical constraints. It's difficult +to anticipate all possible changes which might be needed to meld +libfdt into such environments and so difficult to suitably word a +license that puts the boundary between what is and isn't permitted in +the intended place. Again, I judged encouraging widespread use of +libfdt by keeping the license terms simple and familiar to be the more +important goal. + +**IMPORTANT** It's intended that all of libfdt as released remain +permissively licensed this way. Therefore only contributions which +are released under these terms can be merged into the libfdt mainline. + + +David Gibson [EMAIL PROTECTED] +(principal original author of dtc and libfdt) +2 November 2007 -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ofa-general] [PATCH] IB/ehca: Forward event client-reregister-required to registered clients
thanks, applied. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
