* 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: [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/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: 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: [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: [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: [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: 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/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: [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
* [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] 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
* 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 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: 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:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BAB67.4080003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
> > If that's the case the cs4270 should be in the i2c bus node (missing
> > currently) and then a link from the SSI bus would point to it.
>
> The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs
> to have two nodes, one under each. Your're right in that there needs to
> be a link, but until the code is updated to ASoC V2, I think it's
> premature to add that support.
Why not be a child of the i2c bus with a phandle to the ssi bus? That
is the direction we've gone with other multi attachment devices. (ie.
Ethernet PHYs. Child of the MDIO node, phandle to link the Ethernet
controller with the PHY)
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 15:56 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:
> 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, I have four different but similar systems. They only differer in
the codec chips used. I want to make a single kernel image and then
use the device tree to dynamically load the correct codec driver from
initrd. That will let me ship a single kernel image that services all
four machines. The codecs implement different sound systems from low
end to high end.
The correct solution for this is to use kernel modules and trigger
their loading based on the device tree. This is the same mechanism
used by USB and PCI.
For this model to work you need to split your driver. fsl-ssi and
mpc8610_hpcd need to be in two separate drivers. 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?)
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.
unsigned long node = of_get_flat_dt_root();
if (!of_flat_dt_is_compatible(node, "fsl,MPC8610HPCD"))
return 0;
.. activate the code ...
You also need a static flag to make sure you don't active the driver
more than once.
This isn't the best solution since my four fabric drivers will still
load and check what platform they are on before exiting but at least
it works.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Olof Johansson @ 2008-01-02 15:51 UTC (permalink / raw)
To: Li Li; +Cc: Wood Scott, linuxppc-dev, kim phillips
In-Reply-To: <1199272605.22416.8.camel@Guyver>
On Wed, Jan 02, 2008 at 07:16:45PM +0800, Li Li wrote:
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 1ee009e..f84caa7 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2111,6 +2111,10 @@
> #define PCI_DEVICE_ID_TDI_EHCI 0x0101
>
> #define PCI_VENDOR_ID_FREESCALE 0x1957
> +#define PCI_DEVICE_ID_MPC8378E 0x00c4
> +#define PCI_DEVICE_ID_MPC8378 0x00c5
> +#define PCI_DEVICE_ID_MPC8377E 0x00c6
> +#define PCI_DEVICE_ID_MPC8377 0x00c7
> #define PCI_DEVICE_ID_MPC8548E 0x0012
> #define PCI_DEVICE_ID_MPC8548 0x0013
> #define PCI_DEVICE_ID_MPC8543E 0x0014
In general it's not needed to add device ID's to the global table,
especially when they're only used once or twice. Just use the hex constant
in the driver instead.
-Olof
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 15:34 UTC (permalink / raw)
To: Timur Tabi, Liam Girdwood; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BAB67.4080003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
> > On 1/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> >>> + ssi@16000 {
> >>> + compatible = "fsl,ssi";
> >>> + cell-index = <0>;
> >>> + reg = <16000 100>;
> >>> + interrupt-parent = <&mpic>;
> >>> + interrupts = <3e 2>;
> >>> + fsl,mode = "i2s-slave";
> >>> + codec {
> >>> + compatible = "cirrus,cs4270";
> >>> + /* MCLK source is a stand-alone oscillator */
> >>> + bus-frequency = <bb8000>;
> >>> + };
> >>> + };
> >> Does this need to be bus-frequency? It's always called MCLK in all of
> >> the literature.
> >>
> >> In my case the MCLK comes from a chip on the i2c bus that is
> >> programmable How would that be encoded?.
> >
> > Looking at the cs4270 codec driver it is controlled by i2c (supports
> > SPI too). What happened to the conversation about putting codecs on
> > the controlling bus and then linking them to the data bus?
>
> The current CS4270 driver doesn't support device trees. When I wrote
> it, the idea of putting I2C info in the device tree was not finalized,
> and since the driver is supposed to be cross-platform, I decided to do
> it the old-fashioned way. Before I update the code, however, I'm
> waiting for:
>
> 1) The current code to be accepted into the tree
> 2) ASoC is updated to V2
> 3) The current drivers are updated to support ASoC V2.
I've been trying to get the i2c code in for two months. Hopefully it
will go in soon, no one had made any comments on it recently. Have you
tried your code with it?
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.
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?
> I think ASoC V2 will make it easier to support device trees, but I'm not
> ready yet for that.
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. 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.
Liam messed up all of my code when he refactored it in late December.
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.
>
> > If that's the case the cs4270 should be in the i2c bus node (missing
> > currently) and then a link from the SSI bus would point to it.
>
> The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs
> to have two nodes, one under each. Your're right in that there needs to
> be a link, but until the code is updated to ASoC V2, I think it's
> premature to add that support.
Adding the second device tree node doesn't have anything to do with
ASOC v2. It's specific to powerpc and device trees.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-02 15:29 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910801012027p4be16b92r43af773f4e5ae531@mail.gmail.com>
Jon Smirl wrote:
> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
>> sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++
>> sound/soc/fsl/fsl_ssi.h | 224 +++++++
>
> I'm confused about this part. You built a driver for the mpc8610 ssi
> port. This port has a device tree entry.
>
> + ssi@16000 {
> + compatible = "fsl,ssi";
> + cell-index = <0>;
> + reg = <16000 100>;
> + interrupt-parent = <&mpic>;
> + interrupts = <3e 2>;
> + fsl,mode = "i2s-slave";
> + codec {
> + compatible = "cirrus,cs4270";
> + /* MCLK source is a stand-alone oscillator */
> + bus-frequency = <bb8000>;
> + };
> + };
>
> But then you don't create an of_platform_driver for this device.
> Instead you create one for the fabric driver, struct
> of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI
> driver into it.
That's the best plan I came up with. This is apparently fixed in ASoC
V2. From ASoC V1's perspective, the fabric driver must be the master.
However, it doesn't make sense to have a node in the device tree for the
fabric driver, because there is no such "device". The fabric driver is
an abstraction. So I need to chose some other node to probe the fabric
driver with. I chose the SSI, since each SSI can have only one codec.
>
> +static struct of_device_id mpc8610_hpcd_match[] = {
> + {
> + .compatible = "fsl,ssi",
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, mpc8610_hpcd_match);
> +
> +static struct of_platform_driver mpc8610_hpcd_of_driver = {
> + .owner = THIS_MODULE,
> + .name = "mpc8610_hpcd",
> + .match_table = mpc8610_hpcd_match,
> + .probe = mpc8610_hpcd_probe,
> + .remove = mpc8610_hpcd_remove,
> +};
>
> static int mpc8610_hpcd_probe(struct of_device *ofdev,
> const struct of_device_id *match)
> {
> .....
> machine_data->dai.cpu_dai = fsl_ssi_create_dai(&ssi_info);
>
> Isn't this two separate drivers that have been combined into one
> driver? Or does the fsl_ssi channel only work on the mpc8610_hpcd?
Sorry, I don't understand your question.
> This is the problem of knowing how to load the fabric driver that I
> was talking about in the other threads.
Yes, and the decision I made on this topic is to have the fabric driver
probed on the SSI node.
For ASoC V1, I believe the problem is undefined and each driver should
be implemented in whatever way works best.
> A device that can occur on
> more than one chip ".compatible = "fsl,ssi"," is being used to pull in
> a platform specific fabric driver, "mpc8610_hpcd". You can use the
> kernel config system to select the right driver for ".compatible =
> "fsl,ssi"," that matches you hardware and compile it in.
Ok, I think I understand that.
> 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.
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.
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.
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Kumar Gala @ 2008-01-02 15:23 UTC (permalink / raw)
To: Li Li; +Cc: Wood Scott, linuxppc-dev, kim phillips
In-Reply-To: <1199272605.22416.8.camel@Guyver>
On Jan 2, 2008, at 5:16 AM, Li Li wrote:
> * The MPC837x PCIE controller hardware resources and SerDes are
> initiated in u-boot.
> * Merge the MPC837x PCIE code into arch/powerpc/sysdev/fsl_pci.c
> * The MPC837x PCIE controller`s configure address bit field is uniqe:
> bus number: bits 31-24
> device number: bits 23-19
> function number: bits 18-16
> ext reg number: bits 11-8
> reg number: bits 7-2
> * Add mpc837x_exclude_device to fixup a controller bug.
what is the bug that is being worked around?
- k
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-02 15:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910801010942y47e4cdbfge5e0d3e44ab96760@mail.gmail.com>
Jon Smirl wrote:
> On 1/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
>>> + ssi@16000 {
>>> + compatible = "fsl,ssi";
>>> + cell-index = <0>;
>>> + reg = <16000 100>;
>>> + interrupt-parent = <&mpic>;
>>> + interrupts = <3e 2>;
>>> + fsl,mode = "i2s-slave";
>>> + codec {
>>> + compatible = "cirrus,cs4270";
>>> + /* MCLK source is a stand-alone oscillator */
>>> + bus-frequency = <bb8000>;
>>> + };
>>> + };
>> Does this need to be bus-frequency? It's always called MCLK in all of
>> the literature.
>>
>> In my case the MCLK comes from a chip on the i2c bus that is
>> programmable How would that be encoded?.
>
> Looking at the cs4270 codec driver it is controlled by i2c (supports
> SPI too). What happened to the conversation about putting codecs on
> the controlling bus and then linking them to the data bus?
The current CS4270 driver doesn't support device trees. When I wrote
it, the idea of putting I2C info in the device tree was not finalized,
and since the driver is supposed to be cross-platform, I decided to do
it the old-fashioned way. Before I update the code, however, I'm
waiting for:
1) The current code to be accepted into the tree
2) ASoC is updated to V2
3) The current drivers are updated to support ASoC V2.
I think ASoC V2 will make it easier to support device trees, but I'm not
ready yet for that.
> If that's the case the cs4270 should be in the i2c bus node (missing
> currently) and then a link from the SSI bus would point to it.
The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs
to have two nodes, one under each. Your're right in that there needs to
be a link, but until the code is updated to ASoC V2, I think it's
premature to add that support.
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-02 15:10 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910801010925j67192427o4e0e824b9d7e0ad0@mail.gmail.com>
Jon Smirl wrote:
> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
>> + ssi@16000 {
>> + compatible = "fsl,ssi";
>> + cell-index = <0>;
>> + reg = <16000 100>;
>> + interrupt-parent = <&mpic>;
>> + interrupts = <3e 2>;
>> + fsl,mode = "i2s-slave";
>> + codec {
>> + compatible = "cirrus,cs4270";
>> + /* MCLK source is a stand-alone oscillator */
>> + bus-frequency = <bb8000>;
>> + };
>> + };
>
> Does this need to be bus-frequency? It's always called MCLK in all of
> the literature.
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?
>
> 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.
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Arnd Bergmann @ 2008-01-02 11:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wood Scott, kim phillips, Li Li
In-Reply-To: <1199272605.22416.8.camel@Guyver>
On Wednesday 02 January 2008, Li Li wrote:
> =A0#ifdef CONFIG_PCI
> -=A0=A0=A0=A0=A0=A0=A0for_each_compatible_node(np, "pci", "fsl,mpc8349-pc=
i")
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0mpc83xx_add_bridge(np);
> +=A0=A0=A0=A0=A0=A0=A0for_each_compatible_node(np, "pci", "fsl,mpc8349-pc=
i") {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (primary_pci_bus) {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0mpc=
83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pri=
mary_pci_bus =3D 0;
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0} else
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0mpc=
83xx_add_bridge(np, PPC_83XX_PCI);
> +=A0=A0=A0=A0=A0=A0=A0}
> +
> +=A0=A0=A0=A0=A0=A0=A0for_each_compatible_node(np, "pci", "fsl,mpc8377-pc=
ie") {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (primary_pci_bus) {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0mpc=
83xx_add_bridge(np, PPC_83XX_PCIE | PPC_83XX_PCI_PRIMARY);
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pri=
mary_pci_bus =3D 0;
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0} else
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0mpc=
83xx_add_bridge(np, PPC_83XX_PCIE);
> +=A0=A0=A0=A0=A0=A0=A0}
> +
> +=A0=A0=A0=A0=A0=A0=A0ppc_md.pci_exclude_device =3D mpc837x_exclude_devic=
e;
> =A0#endif
A few comments on how I think this can be improved:
* Instead of duplicating this code across all platforms, make a single
function that does the probing in one place (including the #ifdef
CONFIG_PCI).
* Better yet, get rid of mpc83xx_add_bridge and make it possible for the
mpc83xx code to use the of_pci_phb_driver from
arch/powerpc/kernel/of_platform.c. This used to be impossible because
of the differences between 32 and 64 bit code for PCI probing, but
I think with the work than benh put into unifying the two, we should
be pretty close now.
* 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.
* Since you are using exactly the same probing code for pci and pcie,
you may want to check for a more generic "compatible" property than
the specific model, so you can use the same code for both.
Arnd <><
^ permalink raw reply
* [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Li Li @ 2008-01-02 11:16 UTC (permalink / raw)
To: Kumar Gala, kim phillips, Wood Scott, linuxppc-dev
* The MPC837x PCIE controller hardware resources and SerDes are initiated in u-boot.
* Merge the MPC837x PCIE code into arch/powerpc/sysdev/fsl_pci.c
* The MPC837x PCIE controller`s configure address bit field is uniqe:
bus number: bits 31-24
device number: bits 23-19
function number: bits 18-16
ext reg number: bits 11-8
reg number: bits 7-2
* Add mpc837x_exclude_device to fixup a controller bug.
* Add flag variant to mpc83xx_add_bridge function.
Signed-off-by: Tony Li <tony.li@freescale.com>
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 54 ++++++++--
arch/powerpc/boot/dts/mpc8378_mds.dts | 54 ++++++++--
arch/powerpc/platforms/83xx/Kconfig | 2 +
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 10 ++-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 12 ++-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 10 ++-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 10 ++-
arch/powerpc/platforms/83xx/mpc834x_mds.c | 10 ++-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 12 ++-
arch/powerpc/platforms/83xx/mpc837x_mds.c | 39 +++++++-
arch/powerpc/platforms/83xx/mpc83xx.h | 6 +-
arch/powerpc/platforms/83xx/pci.c | 29 ++++--
arch/powerpc/sysdev/fsl_pci.c | 159 +++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_pci.h | 3 +
include/asm-powerpc/pci-bridge.h | 1 +
include/linux/pci_ids.h | 4 +
16 files changed, 375 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 4402e39..4af3802 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -197,14 +197,6 @@
clock = <d#100>;
};
- serdes2:serdes@e3100 {
- compatible = "fsl,serdes";
- reg = <e3100 100>;
- vdd-1v;
- protocol = "pcie";
- clock = <d#100>;
- };
-
/* IPIC
* interrupts cell = <intr #, sense>
* sense values match linux IORESOURCE_IRQ_* defines:
@@ -279,4 +271,50 @@
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
+
+ pcie@e0009000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &ipic 1 8
+ 0000 0 0 2 &ipic 1 8
+ 0000 0 0 3 &ipic 1 8
+ 0000 0 0 4 &ipic 1 8
+ >;
+ interrupt-parent = < &ipic >;
+ interrupts = <1 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 A0000000 A0000000 0 10000000
+ 01000000 0 00000000 B1000000 0 00800000>;
+ clock-frequency = <0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <e0009000 00001000
+ b0000000 01000000>;
+ compatible = "fsl,mpc8377-pcie";
+ device_type = "pci";
+ };
+
+ pcie@e000a000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &ipic 2 8
+ 0000 0 0 2 &ipic 2 8
+ 0000 0 0 3 &ipic 2 8
+ 0000 0 0 4 &ipic 2 8
+ >;
+ interrupt-parent = < &ipic >;
+ interrupts = <2 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 C0000000 C0000000 0 10000000
+ 01000000 0 00000000 D1000000 0 00800000>;
+ clock-frequency = <0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <e000a000 00001000
+ d0000000 01000000>;
+ compatible = "fsl,mpc8377-pcie";
+ device_type = "pci";
+ };
};
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/boot/dts/mpc8378_mds.dts
index 54171f4..de9d40c 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -179,14 +179,6 @@
clock = <d#100>;
};
- serdes2:serdes@e3100 {
- compatible = "fsl,serdes";
- reg = <e3100 100>;
- vdd-1v;
- protocol = "pcie";
- clock = <d#100>;
- };
-
/* IPIC
* interrupts cell = <intr #, sense>
* sense values match linux IORESOURCE_IRQ_* defines:
@@ -261,4 +253,50 @@
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
+
+ pcie@e0009000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &ipic 1 8
+ 0000 0 0 2 &ipic 1 8
+ 0000 0 0 3 &ipic 1 8
+ 0000 0 0 4 &ipic 1 8
+ >;
+ interrupt-parent = < &ipic >;
+ interrupts = <1 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 A0000000 A0000000 0 10000000
+ 01000000 0 00000000 B1000000 0 00800000>;
+ clock-frequency = <0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <e0009000 00001000
+ b0000000 01000000>;
+ compatible = "fsl,mpc8377-pcie";
+ device_type = "pci";
+ };
+
+ pcie@e000a000 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &ipic 2 8
+ 0000 0 0 2 &ipic 2 8
+ 0000 0 0 3 &ipic 2 8
+ 0000 0 0 4 &ipic 2 8
+ >;
+ interrupt-parent = < &ipic >;
+ interrupts = <2 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 C0000000 C0000000 0 10000000
+ 01000000 0 00000000 D1000000 0 00800000>;
+ clock-frequency = <0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <e000a000 00001000
+ d0000000 01000000>;
+ compatible = "fsl,mpc8377-pcie";
+ device_type = "pci";
+ };
};
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 0c61e7a..0b4bfb5 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -86,4 +86,6 @@ config PPC_MPC837x
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
select FSL_SERDES
+ select FSL_PCI if PCI
default y if MPC837x_MDS
+
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 33766b8..25d8df4 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -37,14 +37,20 @@ static void __init mpc8313_rdb_setup_arch(void)
{
#ifdef CONFIG_PCI
struct device_node *np;
+ int primary_pci_bus = 1;
#endif
if (ppc_md.progress)
ppc_md.progress("mpc8313_rdb_setup_arch()", 0);
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
#endif
mpc831x_usb_cfg();
}
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 972fa85..ddb0b2e 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -58,6 +58,9 @@ static u8 *bcsr_regs = NULL;
static void __init mpc832x_sys_setup_arch(void)
{
struct device_node *np;
+#ifdef CONFIG_PCI
+ int primary_pci_bus = 1;
+#endif
if (ppc_md.progress)
ppc_md.progress("mpc832x_sys_setup_arch()", 0);
@@ -73,8 +76,13 @@ static void __init mpc832x_sys_setup_arch(void)
}
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
#endif
#ifdef CONFIG_QUICC_ENGINE
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index fbca336..aef35f5 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -87,14 +87,20 @@ static void __init mpc832x_rdb_setup_arch(void)
{
#if defined(CONFIG_PCI) || defined(CONFIG_QUICC_ENGINE)
struct device_node *np;
+ int primary_pci_bus = 1;
#endif
if (ppc_md.progress)
ppc_md.progress("mpc832x_rdb_setup_arch()", 0);
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
#endif
#ifdef CONFIG_QUICC_ENGINE
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..c428f62 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -46,14 +46,20 @@ static void __init mpc834x_itx_setup_arch(void)
{
#ifdef CONFIG_PCI
struct device_node *np;
+ int primary_pci_bus = 1;
#endif
if (ppc_md.progress)
ppc_md.progress("mpc834x_itx_setup_arch()", 0);
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
#endif
mpc834x_usb_cfg();
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 00aed7c..e86dce8 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -77,14 +77,20 @@ static void __init mpc834x_mds_setup_arch(void)
{
#ifdef CONFIG_PCI
struct device_node *np;
+ int primary_pci_bus = 1;
#endif
if (ppc_md.progress)
ppc_md.progress("mpc834x_mds_setup_arch()", 0);
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
#endif
mpc834xemds_usb_cfg();
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0f3855c..6e6670c 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -64,6 +64,9 @@ static u8 *bcsr_regs = NULL;
static void __init mpc836x_mds_setup_arch(void)
{
struct device_node *np;
+#ifdef CONFIG_PCI
+ int primary_pci_bus = 1;
+#endif
if (ppc_md.progress)
ppc_md.progress("mpc836x_mds_setup_arch()", 0);
@@ -79,8 +82,13 @@ static void __init mpc836x_mds_setup_arch(void)
}
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
#endif
#ifdef CONFIG_QUICC_ENGINE
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 166c111..ec2fa9f 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -25,8 +25,27 @@
#ifndef CONFIG_PCI
unsigned long isa_io_base = 0;
unsigned long isa_mem_base = 0;
+
#endif
+#ifdef CONFIG_PCI
+static int mpc837x_exclude_device(struct pci_controller *hose,
+ u_char bus, u_char devfn)
+{
+ struct pci_bus *pci_bus;
+
+ if (hose->indirect_type & PPC_INDIRECT_TYPE_MPC83XX_PCIE) {
+ pci_bus = pci_find_bus(hose->global_number, bus);
+ if ((bus == hose->first_busno) ||
+ (pci_bus->primary == hose->first_busno)) {
+ if (devfn & 0xf8)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+#endif
/* ************************************************************************
*
* Setup the architecture
@@ -36,14 +55,30 @@ static void __init mpc837x_mds_setup_arch(void)
{
#ifdef CONFIG_PCI
struct device_node *np;
+ int primary_pci_bus = 1;
#endif
if (ppc_md.progress)
ppc_md.progress("mpc837x_mds_setup_arch()", 0);
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
- mpc83xx_add_bridge(np);
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCI | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCI);
+ }
+
+ for_each_compatible_node(np, "pci", "fsl,mpc8377-pcie") {
+ if (primary_pci_bus) {
+ mpc83xx_add_bridge(np, PPC_83XX_PCIE | PPC_83XX_PCI_PRIMARY);
+ primary_pci_bus = 0;
+ } else
+ mpc83xx_add_bridge(np, PPC_83XX_PCIE);
+ }
+
+ ppc_md.pci_exclude_device = mpc837x_exclude_device;
#endif
}
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index b778cb4..552e9bf 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -47,8 +47,10 @@
* Declaration for the various functions exported by the
* mpc83xx_* files. Mostly for use by mpc83xx_setup
*/
-
-extern int mpc83xx_add_bridge(struct device_node *dev);
+#define PPC_83XX_PCI_PRIMARY 0x1
+#define PPC_83XX_PCI 0x2
+#define PPC_83XX_PCIE 0x4
+extern int mpc83xx_add_bridge(struct device_node *dev, int flags);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
extern int mpc834x_usb_cfg(void);
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
index 80425d7..7a3382a 100644
--- a/arch/powerpc/platforms/83xx/pci.c
+++ b/arch/powerpc/platforms/83xx/pci.c
@@ -24,6 +24,9 @@
#include <asm/pci-bridge.h>
#include <asm/prom.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+
+#include "mpc83xx.h"
#undef DEBUG
@@ -33,13 +36,13 @@
#define DBG(x...)
#endif
-int __init mpc83xx_add_bridge(struct device_node *dev)
+int __init mpc83xx_add_bridge(struct device_node *dev, int flags)
{
int len;
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
- int primary = 1, has_address = 0;
+ int has_address = 0;
phys_addr_t immr = get_immrbase();
DBG("Adding PCI host bridge %s\n", dev->full_name);
@@ -63,16 +66,23 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
hose->last_busno = bus_range ? bus_range[1] : 0xff;
/* MPC83xx supports up to two host controllers one at 0x8500 from immrbar
- * the other at 0x8600, we consider the 0x8500 the primary controller
+ * the other at 0x8600.
*/
/* PCI 1 */
- if ((rsrc.start & 0xfffff) == 0x8500) {
+ if ((rsrc.start & 0xfffff) == 0x8500)
setup_indirect_pci(hose, immr + 0x8300, immr + 0x8304, 0);
- }
/* PCI 2 */
- if ((rsrc.start & 0xfffff) == 0x8600) {
+ if ((rsrc.start & 0xfffff) == 0x8600)
setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384, 0);
- primary = 0;
+
+ if (flags & PPC_83XX_PCIE) {
+ struct resource cfg_space;
+
+ if (of_address_to_resource(dev, 1, &cfg_space)) {
+ printk("PCIE RC losts configure space. Skip it\n");
+ return 1;
+ }
+ mpc83xx_setup_pcie(hose, &rsrc, &cfg_space);
}
printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
@@ -85,7 +95,10 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
/* Interpret the "ranges" property */
/* This also maps the I/O region and sets isa_io/mem_base */
- pci_process_bridge_OF_ranges(hose, dev, primary);
+ if (flags & PPC_83XX_PCI_PRIMARY)
+ pci_process_bridge_OF_ranges(hose, dev, 1);
+ else
+ pci_process_bridge_OF_ranges(hose, dev, 0);
return 0;
}
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 33df4c3..dfd9a40 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -240,6 +240,165 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
return 0;
}
+/* MPC83xx PCIE routines*/
+/* PCIE Registers */
+#define PEX_LTSSM_STAT 0x404
+#define PEX_LTSSM_STAT_L0 0x16
+#define PEX_GCLK_RATIO 0x440
+
+/* With the convention of u-boot, the PCIE outbound window 0 serves
+ * as configuration transactions outbound */
+#define PEX_OUTWIN0_TAL 0xCA8
+#define PEX_OUTWIN0_TAH 0xCAC
+
+void remap_cfg_outbound(void * __iomem reg_base, u32 tal, u32 tah)
+{
+ out_le32(reg_base + PEX_OUTWIN0_TAL, tal);
+ out_le32(reg_base + PEX_OUTWIN0_TAH, tah);
+}
+
+static int mpc83xx_read_config_pcie(struct pci_bus *bus,
+ uint devfn, int offset, int len, u32 *val)
+{
+ struct pci_controller *hose = bus->sysdata;
+ void __iomem *cfg_addr;
+ static u32 orig_busno = 0;
+ u32 bus_no;
+
+ if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (ppc_md.pci_exclude_device)
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ switch (len) {
+ case 2:
+ if (offset & 1)
+ return -EINVAL;
+ break;
+ case 4:
+ if (offset & 3)
+ return -EINVAL;
+ break;
+ }
+
+ if ((bus->number == hose->first_busno) &&
+ (hose->indirect_type & PPC_INDIRECT_TYPE_MPC83XX_PCIE))
+ cfg_addr = (void __iomem *)((ulong) hose->cfg_data + (offset & 0xfff));
+ else {
+ bus_no = bus->number - hose->first_busno;
+ if (bus_no != orig_busno) {
+ remap_cfg_outbound((void __iomem *)hose->cfg_data, bus_no, 0);
+ orig_busno = bus_no;
+ }
+ cfg_addr = (void __iomem *)((ulong) hose->cfg_addr +
+ ((devfn << 16) | (offset & 0xfff)));
+ }
+
+ switch (len) {
+ case 1:
+ *val = in_8(cfg_addr);
+ break;
+ case 2:
+ *val = in_le16(cfg_addr);
+ break;
+ default:
+ *val = in_le32(cfg_addr);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int mpc83xx_write_config_pcie(struct pci_bus *bus,
+ uint devfn, int offset, int len, u32 val)
+{
+ struct pci_controller *hose = bus->sysdata;
+ void __iomem *cfg_addr;
+ static u32 orig_busno = 0;
+ u32 bus_no;
+
+ if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (ppc_md.pci_exclude_device)
+ if (ppc_md.pci_exclude_device(hose, bus->number, devfn))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ switch (len) {
+ case 2:
+ if (offset & 1)
+ return -EINVAL;
+ break;
+ case 4:
+ if (offset & 3)
+ return -EINVAL;
+ break;
+ }
+
+
+ if ((bus->number == hose->first_busno) &&
+ (hose->indirect_type & PPC_INDIRECT_TYPE_MPC83XX_PCIE))
+ cfg_addr = (void __iomem *)((ulong) hose->cfg_data + (offset & 0xfff));
+ else {
+ bus_no = bus->number - hose->first_busno;
+ if (bus_no != orig_busno) {
+ remap_cfg_outbound((void __iomem *)hose->cfg_data, bus_no, 0);
+ orig_busno = bus_no;
+ }
+ cfg_addr = (void __iomem *)((ulong) hose->cfg_addr +
+ ((devfn << 16) | (offset & 0xfff)));
+ }
+
+ switch (len) {
+ case 1:
+ out_8(cfg_addr, val);
+ break;
+ case 2:
+ out_le16(cfg_addr, val);
+ break;
+ default:
+ out_le32(cfg_addr, val);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops mpc83xx_pcie_ops = {
+ mpc83xx_read_config_pcie,
+ mpc83xx_write_config_pcie
+};
+
+void __init mpc83xx_setup_pcie(struct pci_controller *hose,
+ struct resource *reg, struct resource *cfg_space)
+{
+ void __iomem *hose_cfg_header, *mbase;
+ u32 val;
+
+ hose_cfg_header = ioremap(reg->start, reg->end - reg->start + 1);
+
+ val = in_le32(hose_cfg_header + PEX_LTSSM_STAT);
+ if (val < PEX_LTSSM_STAT_L0)
+ hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
+ hose->indirect_type |= PPC_INDIRECT_TYPE_MPC83XX_PCIE;
+
+ mbase = ioremap(cfg_space->start & PAGE_MASK, cfg_space->end - cfg_space->start + 1);
+ hose->ops = &mpc83xx_pcie_ops;
+ hose->cfg_addr = mbase + (cfg_space->start & ~PAGE_MASK);
+
+ /* The MPC83xx PCIE implements direct access configure space
+ * routines instead of indirect ones. So, the cfg_data field is free.
+ * The MPC83xx PCIE RC configure header is memory-mapped,
+ * we use cfg_data as this header pointer */
+ hose->cfg_data = hose_cfg_header;
+}
+
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8377E, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8377, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8378E, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8378, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8548E, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8548, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8543E, quirk_fsl_pcie_transparent);
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index 37b04ad..a70ee0f 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -84,5 +84,8 @@ struct ccsr_pci {
extern int fsl_add_bridge(struct device_node *dev, int is_primary);
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
+extern void mpc83xx_setup_pcie(struct pci_controller *hose,
+ struct resource *reg, struct resource *cfg_space);
+
#endif /* __POWERPC_FSL_PCI_H */
#endif /* __KERNEL__ */
diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
index dc31845..372598b 100644
--- a/include/asm-powerpc/pci-bridge.h
+++ b/include/asm-powerpc/pci-bridge.h
@@ -56,6 +56,7 @@ struct pci_controller {
#define PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS (0x00000004)
#define PPC_INDIRECT_TYPE_NO_PCIE_LINK (0x00000008)
#define PPC_INDIRECT_TYPE_BIG_ENDIAN (0x00000010)
+#define PPC_INDIRECT_TYPE_MPC83XX_PCIE (0x00000020)
u32 indirect_type;
/* Currently, we limit ourselves to 1 IO range and 3 mem
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 1ee009e..f84caa7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2111,6 +2111,10 @@
#define PCI_DEVICE_ID_TDI_EHCI 0x0101
#define PCI_VENDOR_ID_FREESCALE 0x1957
+#define PCI_DEVICE_ID_MPC8378E 0x00c4
+#define PCI_DEVICE_ID_MPC8378 0x00c5
+#define PCI_DEVICE_ID_MPC8377E 0x00c6
+#define PCI_DEVICE_ID_MPC8377 0x00c7
#define PCI_DEVICE_ID_MPC8548E 0x0012
#define PCI_DEVICE_ID_MPC8548 0x0013
#define PCI_DEVICE_ID_MPC8543E 0x0014
--
1.5.3
^ permalink raw reply related
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