* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 16:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BADF5.9060003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> 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.
Does that mean with ASoC V2 you can instantiate it with the board
specific platform code instead? I think that is the consensus we were
leaning towards in the last discussion about this issue.
> > But that doesn't work in my environment. My generic channel is
> > "fsl,i2s". I have four different systems booting off from a shared
> > network drive. Each of these systems needs the common "fsl,i2s" driver
> > but they all four need different fabric drivers.
>
> That, I don't understand. fsl,ssi is pretty much the same thing as
> fsl,i2s, since the SSI *is* an I2S device. It's also an AC97 device,
> which is why I added the fsl,mode property.
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? What happens when Freescale produces another
peripheral that can do ssi but isn't register level compatible?
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 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.
>
> 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.
> Are you saying that you want to use the same kernel on four different
> systems? If so, then you need to find a way to compile all fabric
> drivers together, and at boot time each fabric driver will decide
> whether it will do anything.
Yes! That is exactly what we want to support in arch/powerpc. Use
platform code to select the correct fabric driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 16:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801020756p18e12ce8o618b8eae5e7c5a53@mail.gmail.com>
On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> mpc8610_hpcd is the harder one to load since it doesn't have a device
> tree entry. What you want to do it match on the compatible field of
> the root node.
>
> static struct of_device_id fabric_of_match[] = {
> {
> .compatible = "fsl,MPC8610HPCD",
> },
> {},
> };
>
> But this doesn't work since the root is the device tree isn't passed
> down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate
the correct fabric device (probably as a platform_device) from the
platform code. Then the correct fabric driver can probe against it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 17:12 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801020832y373c091dn925bfe64afddcb81@mail.gmail.com>
On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> > mpc8610_hpcd is the harder one to load since it doesn't have a device
> > tree entry. What you want to do it match on the compatible field of
> > the root node.
> >
> > static struct of_device_id fabric_of_match[] = {
> > {
> > .compatible = "fsl,MPC8610HPCD",
> > },
> > {},
> > };
> >
> > But this doesn't work since the root is the device tree isn't passed
> > down into the device probe code. (Could this be fixed?)
>
> The driver can always get the root node. But better yet, instantiate
> the correct fabric device (probably as a platform_device) from the
> platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The
platform code can create a device that isn't bound to a driver. So why
not make this an of_platform_device? This is basically a pseudo
device that isn't in the device tree.
Alternatively, the best place for this device would be on the ASOC
bus, but the ASOC bus hasn't been created when the platform code runs.
Maybe I can figure out a place in the platform code to create this
device after the ASOC driver has loaded and created the bus. Does the
platform code get control back after loading all of the device
drivers?
In the longer term I'd like to kill platform_bus on powerpc and only
use of_platform_bus. Platform_bus seems to be functioning like a
catch-all and collecting junk from lots of different platforms.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 17:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801020912k50dceaebm11b59c1cee571e56@mail.gmail.com>
On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> > > mpc8610_hpcd is the harder one to load since it doesn't have a device
> > > tree entry. What you want to do it match on the compatible field of
> > > the root node.
> > >
> > > static struct of_device_id fabric_of_match[] = {
> > > {
> > > .compatible = "fsl,MPC8610HPCD",
> > > },
> > > {},
> > > };
> > >
> > > But this doesn't work since the root is the device tree isn't passed
> > > down into the device probe code. (Could this be fixed?)
> >
> > The driver can always get the root node. But better yet, instantiate
> > the correct fabric device (probably as a platform_device) from the
> > platform code. Then the correct fabric driver can probe against it.
>
> The meaning of this has finally sunk into my consciousness. The
> platform code can create a device that isn't bound to a driver. So why
> not make this an of_platform_device? This is basically a pseudo
> device that isn't in the device tree.
Simply because it doesn't have a device node. That's the prime
characteristc that differentiates platform_bus from of_platform_bus.
What do you bind against in of_platform_bus if you don't have a
specific node for it?
> 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?
Yes, but it requires the core ASoC code to not be a module. Then you
can use machine_device_initcall() to register the device at a later
time.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] [POWERPC] Sequoia: typo in calling machine_device_initcall()
From: Grant Likely @ 2008-01-02 17:23 UTC (permalink / raw)
To: jwboyer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/44x/sequoia.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
index 374f8c7..d279db4 100644
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ b/arch/powerpc/platforms/44x/sequoia.c
@@ -38,7 +38,7 @@ static int __init sequoia_device_probe(void)
return 0;
}
-machien_device_initcall(sequoia, sequoia_device_probe);
+machine_device_initcall(sequoia, sequoia_device_probe);
static int __init sequoia_probe(void)
{
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Sequoia: typo in calling machine_device_initcall()
From: Josh Boyer @ 2008-01-02 17:37 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080102172356.26645.63895.stgit@trillian.secretlab.ca>
On Wed, 02 Jan 2008 10:23:56 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Oh, that's fun... my build scripts say this passed. Looking at
powerpc.sequoia_defconfig.log.passed shows it obviously failed. I hate
it when automated tools suck.
Thanks Grant. Applied to my for-2.6.25 branch
josh
> ---
>
> arch/powerpc/platforms/44x/sequoia.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
> index 374f8c7..d279db4 100644
> --- a/arch/powerpc/platforms/44x/sequoia.c
> +++ b/arch/powerpc/platforms/44x/sequoia.c
> @@ -38,7 +38,7 @@ static int __init sequoia_device_probe(void)
>
> return 0;
> }
> -machien_device_initcall(sequoia, sequoia_device_probe);
> +machine_device_initcall(sequoia, sequoia_device_probe);
>
> static int __init sequoia_probe(void)
> {
>
^ permalink raw reply
* Re: [PATCH/RFC] Add support for freescale watchdog to CPM serial driver.
From: Scott Wood @ 2008-01-02 17:45 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <477513CC.3060109@scram.de>
On Fri, Dec 28, 2007 at 04:18:36PM +0100, Jochen Friedrich wrote:
> If a freescale watchdog device node is present, reset the watchdog
> while waiting for serial input.
Hmm... I don't like combining the watchdog and serial code together. What
if some other serial device is used with this watchdog? The serial driver
should only have to call an externally provided poke_watchdog() function.
-Scott
^ permalink raw reply
* Re: How to creat a .config file for a driver and How to use it in adevice driver?????
From: Sean MacLennan @ 2008-01-02 17:47 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-dev
In-Reply-To: <14576412.post@talk.nabble.com>
Misbah khan wrote:
> Hi all ...
>
> i am writing a device driver in which the default configuration for LCD
> display i need to keep it in a .config file so that as the system boots it
> take the value from this file and does the initial configuration in the init
> of the driver. If user changes the .config file content in the next boot the
> LCD driver should take the new default configuration
>
> There will also be a run time config which could be changed at the rum time
> but will not change the default configuration.
>
>
> i am writing a LCD driver for PPC arch i need to know that how should i
> creat a .config file and How should i use it my device driver. ??????
>
> If you had an exprience in this regard please do share with me ...
>
> ----Misbah <><
>
You don't. The safe way is to have sane defaults in the driver. Then
write a user mode app that reads the config file and configures the
driver properly, probably through ioctls.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] mpc85xx_ads: add in missing of_node_put()
From: Paul Gortmaker @ 2008-01-02 17:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071223095038.ce1ad7a5.sfr@canb.auug.org.au>
In message: Re: [PATCH] mpc85xx_ads: add in missing of_node_put()
on 23/12/2007 Stephen Rothwell wrote:
> On Fri, 21 Dec 2007 10:40:09 -0500 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > cpm2_pic_init() does its own of_node_get() so we should do an of_node_put()
> > before calling it.
>
> The of_node_put() should really go after the call to cpm2_pic_init(), that
> way you retain a raised ref count at all times. Sorry fo not being
> entirely clear before.
No problem. Updated version below.
Thanks,
Paul.
>From eea2826182b4b732ded224240ef9dc89a881ce4b Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 21 Dec 2007 10:12:38 -0500
Subject: [PATCH] mpc85xx_ads: add in missing of_node_put()
Add in missing of_node_put() after cpm2_pic_init(). This and other coding
style cleanups as suggested by Stephen Rothwell.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index bccdc25..91781a9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -52,9 +52,9 @@ static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
{
int cascade_irq;
- while ((cascade_irq = cpm2_get_irq()) >= 0) {
+ while ((cascade_irq = cpm2_get_irq()) >= 0)
generic_handle_irq(cascade_irq);
- }
+
desc->chip->eoi(irq);
}
@@ -70,13 +70,12 @@ static void __init mpc85xx_ads_pic_init(void)
#endif
np = of_find_node_by_type(np, "open-pic");
-
- if (np == NULL) {
+ if (!np) {
printk(KERN_ERR "Could not find open-pic node\n");
return;
}
- if(of_address_to_resource(np, 0, &r)) {
+ if (of_address_to_resource(np, 0, &r)) {
printk(KERN_ERR "Could not map mpic register space\n");
of_node_put(np);
return;
@@ -100,6 +99,7 @@ static void __init mpc85xx_ads_pic_init(void)
irq = irq_of_parse_and_map(np, 0);
cpm2_pic_init(np);
+ of_node_put(np);
set_irq_chained_handler(irq, cpm2_cascade);
#endif
}
@@ -112,7 +112,7 @@ struct cpm_pin {
int port, pin, flags;
};
-static struct cpm_pin mpc8560_ads_pins[] = {
+static const struct cpm_pin mpc8560_ads_pins[] = {
/* SCC1 */
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
--
1.5.0.rc1.gf4b6c
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-02 17:23 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BA974.8010308@freescale.com>
On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote:
> Jon Smirl wrote:
> > Does this need to be bus-frequency? It's always called MCLK in all of
> > the literature.
> I'm trying to make this node as generic as possible. The fabric driver
> is the one that will parse this node and pass the data to the codec
> driver, so I can't use any codec-specific terms.
> The API from the fabric driver for passing clock information includes a
> clock ID, a direction, and a frequency. I can do something like this:
> 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...
> > In my case the MCLK comes from a chip on the i2c bus that is
> > programmable How would that be encoded?.
> I'm going under the assumption that MCLK does not change once the board
> is up and running. In your case, you'd need to do something quite
> different, because you're not reading the clock info from the device
> tree and passing it to the codec at initialization once. If you want to
> define an extension to the 'codec' child node that handles that, I'll
> add it to the documentation.
According to the documentation in your patch the bus frequency should
already be optional (though I don't immediately see that in the code,
but then I'm entirely unfamiliar with OpenFirmware device trees).
Boards that reconfigure the clocking at run time can then provide
code to set the clocking up at the appropriate times, which is probably
what they want anyway.
^ permalink raw reply
* Re: [2.6.24 patch] Fix Cell OProfile support
From: Mathieu Desnoyers @ 2008-01-02 17:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Randy Dunlap, phil.el, linux-kernel, linuxppc-dev, paulus,
oprofile-list, Adrian Bunk
In-Reply-To: <200712311710.08869.arnd@arndb.de>
* Arnd Bergmann (arnd@arndb.de) wrote:
> On Saturday 29 December 2007, Mathieu Desnoyers wrote:
> > This patch restores the Cell OProfile support that was killed by
> > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
> >
> > It puts it in arch/powerpc/Kconfig. Since I don't see any good reason to leave
> > this as a supplementary user-selectable option, it is now automatically enabled
> > whenever SPU_FS and OPROFILE are enabled.
>
> This one has already been superceded by the fix in
> aed3a8c9bb1a8623a618232087c5ff62718e3b9a, which made CONFIG_OPROFILE_CELL an
> automatically selected option, from arch/powerpc/platforms/cell/Kconfig.
>
Great, so my patch should be dropped. Thanks!
Mathieu
> Arnd <><
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: Differences between git tree
From: Jon Loeliger @ 2008-01-02 18:04 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A907@xmb-sjc-212.amer.cisco.com>
On Thu, 2007-12-20 at 07:11, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi,
> Could someone let me know what is the each of these git tree are?
>
> http://opensource.freescale.com/pub/scm/linux-2.6-jdl.git
> AND
> http://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Hrm. I suppose I should answer that one...
Use Paul's tree from kernel.org.
My tree on opensource.freescale.com was my random patches
and crud, being published so others could get a hold of them.
Anything of value there has been moved or integrated into
Paul or Linus' tree by now.
HTH,
jdl
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Scott Wood @ 2008-01-02 18:06 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <476D61DB.2090201@scram.de>
On Sat, Dec 22, 2007 at 08:13:31PM +0100, Jochen Friedrich wrote:
> + gtx@0 {
> + compatible = "c-cube,gtx";
> + reg = <400000 3000 0 200000>;
> + interrupts = <2 2>;
> + interrupt-parent = <&PIC>;
> + };
> +
> + fp@0 {
> + compatible = "betaresearch,dbox2-fp";
> + interrupts = <4 2>;
> + interrupt-parent = <&PIC>;
> + gpios = <0 e>;
> + gpio-parent = <&CPM1_PIO>;
> + };
> +
> + fe@0 {
> + compatible = "betaresearch,dbox2-fe";
> + interrupts = <e 2>;
> + interrupt-parent = <&PIC>;
> + };
These unit addresses look wrong.
> + cam@4000000 {
> + compatible = "betaresearch,dbox2-cam";
> + reg = <4000000 20000>;
> + interrupts = <6 2>;
> + interrupt-parent = <&PIC>;
> + gpios = <1 1c 1 1d 1 1e 1 1f>;
> + gpio-parent = <&CPM1_PIO>;
> + };
> +
> + cam@4040000 {
> + compatible = "betaresearch,dbox2-cam";
> + reg = <4040000 20000>;
> + interrupts = <6 2>;
> + interrupt-parent = <&PIC>;
> + gpios = <1 1c 1 1d 1 1e 1 1f>;
> + gpio-parent = <&CPM1_PIO>;
> + };
Maybe gpios should have a length field? Or maybe we should just
phandle to a separate node under the gpio controller node. What happens if
a device sits on two different gpio-parents?
> + flash@8000000 {
> + // Flash also has info about model needed by setup
> + compatible = "cfi-flash",
> + "betaresearch,dbox2-config";
What does dbox2-config mean?
> + ovpartition@20000 {
> + label = "Flash without bootloader";
> + reg = <20000 7e0000>;
> + };
> + ovpartition@0 {
> + label = "Complete Flash";
> + reg = <0 800000>;
> + read-only;
> + };
What is "ovpartition"?
> + wdt@0 {
> + device_type = "watchdog";
> + compatible = "fsl,mpc823-wdt",
> + "fsl,pq1-wdt";
> + reg = <0 10>;
> + };
No device_type.
> + cpm@9c0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + reg = <9c0 40>;
> + command-proc = <9c0>;
command-proc is obsolete.
> + muram@2000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 2000 2000>;
> +
> + data@0 {
> + compatible = "fsl,cpm-muram-data";
> + reg = <0 1c00>;
> + };
> + };
Should have compatible of fsl,cpm-muram on the muram node as well, even
though the current code doesn't use it.
> + // Port D is LCD exclusive. Don't export as GPIO
> + CPM1_PIO: pio@970 {
> + compatible = "fsl,cpm1-pario";
> + reg = <970 180>;
> + num-ports = <3>;
> + #gpio-cells = <2>;
> + };
Why are we doing things differently just because all of the pins on this
port happen to be directed to one device? If it's because the Linux GPIO
API sucks, then either fix the API, or work around the suckage in software,
not the device tree.
> + lcd@970 {
> + reg = <970 10>;
> + compatible = "samsung,ks0713";
> + };
So some driver that matches on samsung,ks0713 has to know the details of the
mpc8xx GPIO registers?
> + brg@9f0 {
> + compatible = "fsl,mpc823-brg",
> + "fsl,cpm1-brg",
> + "fsl,cpm-brg";
> + reg = <9f0 10>;
> + };
Should have clock-frequency in the brg node.
> + i2c@860 {
> + compatible = "fsl,mpc823-i2c",
> + "fsl,cpm1-i2c",
> + "fsl,cpm-i2c";
> + reg = <860 20 3c80 30>;
> + interrupts = <10 3>;
> + interrupt-parent = <&CPM_PIC>;
> + fsl,cpm-command = <0010>;
> + };
Should have #address-cells and #size-cells.
> +enum dbox2_mid dbox2_get_mid(void)
> +{
> + return dbox2_manuf_id;
> +}
> +EXPORT_SYMBOL_GPL(dbox2_get_mid);
Honestly, you're claiming derived-work status by calling a function that
returns an integer, that was read directly from hardware?
> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
> + np = of_find_node_by_path("/localbus@8000000/enx@0");
> + else
> + np = of_find_node_by_path("/localbus@8000000/gtx@0");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +
> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
> + np = of_find_node_by_path("/localbus@8000000/cam@4000000");
> + else
> + np = of_find_node_by_path("/localbus@8000000/cam@4040000");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +}
I'd use separate device trees (I only did this kind of thing in mpc885ads
because it's dip-switchable), but whatever...
> diff --git a/include/asm-powerpc/mpc8xx.h b/include/asm-powerpc/mpc8xx.h
> index 2be014b..b6fd7d6 100644
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include <platforms/8xx/mpc885ads.h>
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include <platforms/8xx/dbox2.h>
> +#endif
This shouldn't be needed.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Scott Wood @ 2008-01-02 18:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: Olof Johansson, linuxppc-dev, alsa-devel
In-Reply-To: <476DCECD.6040008@freescale.com>
On Sat, Dec 22, 2007 at 08:58:21PM -0600, Timur Tabi wrote:
> Scott Wood wrote:
>
>>> None of the SOC nodes in any DTS have a "compatible" entry.
>>
>> Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
>
> Ah ok. So what should the compatible entry for 8641 be?
>
> compatible = "fsl,mpc8641"
Yes.
> That looks a lot like what a compatible entry for the CPU should be.
I guess technically the cpu should list something like fsl,e600 (or
whatever suffix is relevant).
-Scott
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Scott Wood @ 2008-01-02 18:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4776C5EE.70004@freescale.com>
On Sat, Dec 29, 2007 at 04:10:54PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >> + ucc@2400 {
> >> + device_type = "serial";
> >> + compatible = "ucc_uart";
> >> + model = "UCC";
> >
> > model isn't used, is it needed at all?
>
> I have no idea, but all the other UCC nodes have it, so I'm going to
> keep it. Maybe one day we'll merge QE and CPM drivers, so this would be
> useful.
No, it wouldn't -- that's what compatible is for.
> >> +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.
> The CPM serial driver uses "cpm_uart" and the QE ethernet driver uses
> "ucc_geth", so ucc_uart matches the pattern.
cpm_uart is a legacy match -- the current binding specifies
fsl,cpm1-smc-uart, fsl,cpm2-scc-uart, etc.
-Scott
^ permalink raw reply
* Re:
From: rsa @ 2008-01-02 18:16 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 6 bytes --]
What?
[-- Attachment #2: Original Message.B64 --]
[-- Type: application/x-msdownload, Size: 134041 bytes --]
^ permalink raw reply
* Outstanding DTC patches?
From: Jon Loeliger @ 2008-01-02 18:21 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
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 jdl@jdl.com!
Thanks!
jdl
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Fix NMI handling check
From: Olof Johansson @ 2008-01-02 18:45 UTC (permalink / raw)
To: linuxppc-dev
[POWERPC] pasemi: Fix NMI handling check
The logic that checks to see if a machine check is caused by an NMI will
always match when NMI hasn't been initialized, since the mpic routine
will return NO_IRQ (and that's what the nmi_virq value is as well).
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 1940e67..a89d098 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -264,7 +264,7 @@ static int pas_machine_check_handler(struct pt_regs *regs)
srr0 = regs->nip;
srr1 = regs->msr;
- if (mpic_get_mcirq() == nmi_virq) {
+ if (nmi_virq != NO_IRQ && mpic_get_mcirq() == nmi_virq) {
printk(KERN_ERR "NMI delivered\n");
debugger(regs);
mpic_end_irq(nmi_virq);
^ permalink raw reply related
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 18:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801020922q6fbda176l5fc7c80b5e61281f@mail.gmail.com>
On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > 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?
>
> Yes, but it requires the core ASoC code to not be a module. Then you
> can use machine_device_initcall() to register the device at a later
> time.
How about this for a simpler solution? My mpc5200-psc-ac97 and
mpc5200-psc-i2c drivers can create a device on the ASOC bus named
after the first entry in the compatible field of the root node. That
will cause the correct driver to get activated. I'm in the process of
making ASOC drivers dynamically loadable like the i2c ones.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-02 18:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801020828u5103d09cn2aa5eab7dda2fcff@mail.gmail.com>
On Wed, Jan 02, 2008 at 09:28:12AM -0700, Grant Likely wrote:
> On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> > 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.
I'm not sure I'd go so far as to say that the fabric/machine driver is
purely an abstraction. It does represent real hardware, often with
software control.
> Does that mean with ASoC V2 you can instantiate it with the board
> specific platform code instead? I think that is the consensus we were
> leaning towards in the last discussion about this issue.
With ASoC v2 rather than having a single monolithic ASoC device which
probes everything ASoC is converted into a proper subsystem with each
component (codec, SoC CPU port, whatever) having a sysfs-visible driver.
These drivers register with the core as they are probed with the probing
happening through whatever mechanism is appropriate for the driver.
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.
^ permalink raw reply
* File system problem
From: mojtaba @ 2008-01-02 18:50 UTC (permalink / raw)
To: Linuxppc-embedded
Dear all,
I am trying to boot a root file system build by buildroot. But I got this
error" init has generated signal 11 but has no handler for it".
My kernel version is 2.6.24-rc3
My target system is PPC 405 (XILINX VIRTEX II pro) I am using the 26-12-2007
snapshot of buildroot.
This is what I get on terminal:
loaded at: 00400000 004CE1A0
board data at: 004CC120 004CC19C
relocated to: 0040405C 004040D8
zimage at: 00404E94 004CB08A
avail ram: 004CF000 10000000
Linux/PPC load: console=ttyS0,9600 root=/dev/xsa2 init=/bin/sh
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.24-rc3 (mojtaba@ubuntu2) (gcc version 4.2.2) #1 Wed Jan 2
14:3
7:58 CET 2008
Xilinx ML300 Reference System (Virtex-II Pro)
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
HighMem 655
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS0,9600 root=/dev/xsa2 init=/bin/sh
Xilinx INTC #0 at 0x41200000 mapped to 0xEF5FE000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 258048k available (1288k kernel code, 436k data, 76k init, 0k
highmem)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
Call Trace:
[cfc1fe20] [c0008148] show_stack+0x58/0x188 (unreliable)
[cfc1fe68] [c0038908] set_fail+0x50/0x68
[cfc1fe80] [c0038f7c] sysctl_check_table+0x65c/0x6ac
[cfc1fee8] [c0038f8c] sysctl_check_table+0x66c/0x6ac
[cfc1ff50] [c0026c58] register_sysctl_table+0x64/0xb4
[cfc1ff68] [c019ed4c] register_ppc_htab_sysctl+0x18/0x2c
[cfc1ff70] [c019b228] kernel_init+0x104/0x290 [cfc1fff0] [c0004af8]
kernel_thread+0x44/0x60 io scheduler noop registered io scheduler
anticipatory registered io scheduler deadline registered io scheduler cfq
registered (default) Generic RTC Driver v1.07 Macintosh non-volatile memory
driver v1.1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 2) is a 16550A console [ttyS0]
enabled xsysace xsysace.0: Xilinx SystemACE revision 1.0.12 xsysace
xsysace.0: capacity: 1981728 sectors
xsa: xsa1 xsa2 xsa3
Xilinx SystemACE device driver, major=254
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 76k init
Warning: unable to open an initial console.
init has generated signal 11 but has no handler for it Kernel panic - not
syncing: Attempted to kill init!
Rebooting in 180 seconds..
Regards,
Mojtaba
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 18:50 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801021043l7571ea00o7b8072b04ca68ad5@mail.gmail.com>
On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > 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?
> >
> > Yes, but it requires the core ASoC code to not be a module. Then you
> > can use machine_device_initcall() to register the device at a later
> > time.
>
> How about this for a simpler solution? My mpc5200-psc-ac97 and
> mpc5200-psc-i2c drivers can create a device on the ASOC bus named
> after the first entry in the compatible field of the root node. That
> will cause the correct driver to get activated. I'm in the process of
> making ASOC drivers dynamically loadable like the i2c ones.
I little icky, but it doesn't sound dangerous (as in shouldn't cause
any name conflicts). That may be the best we can do for the time
being. But I don't think it is a good idea for the long term.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 18:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801021050v7476fe54uc5589092d0661ac5@mail.gmail.com>
On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > > 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?
> > >
> > > Yes, but it requires the core ASoC code to not be a module. Then you
> > > can use machine_device_initcall() to register the device at a later
> > > time.
> >
> > How about this for a simpler solution? My mpc5200-psc-ac97 and
> > mpc5200-psc-i2c drivers can create a device on the ASOC bus named
> > after the first entry in the compatible field of the root node. That
> > will cause the correct driver to get activated. I'm in the process of
> > making ASOC drivers dynamically loadable like the i2c ones.
>
> I little icky, but it doesn't sound dangerous (as in shouldn't cause
> any name conflicts). That may be the best we can do for the time
> being. But I don't think it is a good idea for the long term.
Simplest long term fix is to allow drivers to bind on the root node.
Make this work:
> static struct of_device_id fabric_of_match[] = {
> {
> .compatible = "fsl,MPC8610HPCD",
> },
> {},
> };
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/3] mpc82xx: Embedded Planet EP8248E support
From: Jon Loeliger @ 2008-01-02 19:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <5898D87A-231D-4CCB-9538-808562F08D57@kernel.crashing.org>
On Fri, 2007-12-14 at 10:28, Kumar Gala wrote:
> > Are there any tools to autoconvert (preferably without losing
> > comments)?
>
> Not sure of jon had a perl script or something.
No, I don't. It's hard to tell what should conceptually
remain hex, and what might need to be decimalized.
Sure, hard lists of properties could be done and all...
One can do a "-I dts -O dts" and get it all converted
to /dts-v1/, but with comments dropped on the floor.
Sorry.
jdl
^ permalink raw reply
* [PATCH 0/5] Make platform code use machine_*_initcall() macros
From: Grant Likely @ 2008-01-02 19:14 UTC (permalink / raw)
To: linuxppc-dev, benh, vitb, galak, olof
This series makes the platform code use the new machine-specific initcall
hooks. This has the advantage of not needing to explicitly test
machine_is() at the top of every initcall function.
This time I split the changes out into separate patches so each platform
maintainer can pick up the ones they are responsible for. Please note;
these are untested as I don't have any of the hardware.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ 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