* Re: [PATCH] Add AMCC Arches DTS
From: Josh Boyer @ 2008-07-16 11:39 UTC (permalink / raw)
To: fkan; +Cc: linuxppc-dev, Victor Gallardo, linuxppc-embedded
In-Reply-To: <1216186476-28018-1-git-send-email-fkan@amcc.com>
On Tue, 15 Jul 2008 22:34:36 -0700
fkan@amcc.com wrote:
> From: Victor Gallardo <vgallard@amcc.com>
>
> ppc4xx: Add AMCC Arches DTS
>
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
> ---
> arch/powerpc/boot/dts/arches.dts | 522 ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 522 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/arches.dts
>
> diff --git a/arch/powerpc/boot/dts/arches.dts b/arch/powerpc/boot/dts/arches.dts
> new file mode 100644
> index 0000000..459cec2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/arches.dts
> @@ -0,0 +1,522 @@
> +/*
> + * Device Tree Source for AMCC Arches (dual 460GT board)
> + *
> + * (C) Copyright 2008
> + * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
> + * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
> + *
> + * Based on the glacier.dts file
> + * Stefan Roese <sr@denx.de>
> + * Copyright 2008 DENX Software Engineering
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +/ {
Could you convert this to a dts-v1 file please? All the in-tree DTS
files are dts-v1 and I'd very much like to keep it that way.
> + #address-cells = <2>;
> + #size-cells = <1>;
> + model = "amcc,arches";
> + compatible = "amcc,arches";
> + dcr-parent = <&/cpus/cpu@0>;
> +
> + aliases {
> + ethernet0 = &EMAC0;
> + ethernet1 = &EMAC1;
> + serial0 = &UART0;
> + serial1 = &UART1;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + model = "PowerPC,460GT";
> + reg = <0>;
> + clock-frequency = <0>; /* Filled in by U-Boot */
> + timebase-frequency = <0>; /* Filled in by U-Boot */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> + dcr-controller;
> + dcr-access-method = "native";
> + };
If this is a dual-460GT, why is there only one CPU node listed? Is it
simply because Linux will only see one CPU as it is an AMP
configuration?
josh
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-16 11:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kumar Gala, Linux Kernel list, linuxppc-dev, Dave Jones, akpm,
Linus Torvalds
In-Reply-To: <200807161051.12545.arnd@arndb.de>
On Wed, 2008-07-16 at 10:51 +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Dave Jones wrote:
> > arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> > /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> > /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
>
> FS_ENET and EP8248E both select MDIO_BITBANG, but not PHYLIB or MII, which
> looks broken to me.
>
> Also, I think it would be useful to split out the bitbang
> driver from ep8248e.c, so that you can build it as a loadable
> module if you want to have PHYLIB loadable.
On that note... I already run it through an autobuilder with a bunch of
configs before uploading (though obviously not this one). Kumar, can you
send me 2 or 3 configs you believe cover a reasonable range of the fsl
stuff that I could stick into my list for next time ?
Cheers,
Ben.
^ permalink raw reply
* [RFC] I2C: fsl-i2c: make device probing configurable via FDT
From: Wolfgang Grandegger @ 2008-07-16 10:47 UTC (permalink / raw)
Cc: Jean Delvare, Linuxppc-dev
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property "probe" of the FDT I2C device node:
i2c@3000 {
...
compatible = "fsl-i2c";
probe;
...
};
Assuming that systems using fsl-i2c should have proper platform data,
probing is disabled by default. Unfortunately, that's not the case and
various DTS files would require to be updated.
There have already been some discussion on this subject with Jean
under the following thread:
http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060008.html
Please comment.
Thanks,
Wolfgang.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/sysdev/fsl_soc.c | 4 ++++
drivers/i2c/busses/i2c-mpc.c | 17 ++++++++++++++---
include/linux/fsl_devices.h | 1 +
3 files changed, 19 insertions(+), 3 deletions(-)
Index: linux-2.6-denx/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- linux-2.6-denx.orig/drivers/i2c/busses/i2c-mpc.c
+++ linux-2.6-denx/drivers/i2c/busses/i2c-mpc.c
@@ -306,13 +306,21 @@ static const struct i2c_algorithm mpc_al
.functionality = mpc_functionality,
};
-static struct i2c_adapter mpc_ops = {
+static struct i2c_adapter mpc_probe_ops = {
.owner = THIS_MODULE,
.name = "MPC adapter",
.id = I2C_HW_MPC107,
.algo = &mpc_algo,
.class = I2C_CLASS_HWMON,
- .timeout = 1,
+ .timeout = 1,
+};
+
+static struct i2c_adapter mpc_ops = {
+ .owner = THIS_MODULE,
+ .name = "MPC adapter",
+ .id = I2C_HW_MPC107,
+ .algo = &mpc_algo,
+ .timeout = 1,
};
static int fsl_i2c_probe(struct platform_device *pdev)
@@ -354,7 +362,10 @@ static int fsl_i2c_probe(struct platform
mpc_i2c_setclock(i2c);
platform_set_drvdata(pdev, i2c);
- i2c->adap = mpc_ops;
+ (i2c->flags & FSL_I2C_DEV_PROBE)
+ i2c->adap = mpc_probe_ops;
+ else
+ i2c->adap = mpc_ops;
i2c->adap.nr = pdev->id;
i2c_set_adapdata(&i2c->adap, i2c);
i2c->adap.dev.parent = &pdev->dev;
Index: linux-2.6-denx/arch/powerpc/sysdev/fsl_soc.c
===================================================================
--- linux-2.6-denx.orig/arch/powerpc/sysdev/fsl_soc.c
+++ linux-2.6-denx/arch/powerpc/sysdev/fsl_soc.c
@@ -518,6 +518,10 @@ static int __init fsl_i2c_of_init(void)
if (flags)
i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
+ flags = of_get_property(np, "probe", NULL);
+ if (flags)
+ i2c_data.device_flags |= FSL_I2C_DEV_PROBE;
+
ret =
platform_device_add_data(i2c_dev, &i2c_data,
sizeof(struct
Index: linux-2.6-denx/include/linux/fsl_devices.h
===================================================================
--- linux-2.6-denx.orig/include/linux/fsl_devices.h
+++ linux-2.6-denx/include/linux/fsl_devices.h
@@ -82,6 +82,7 @@ struct fsl_i2c_platform_data {
/* Flags related to I2C device features */
#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
#define FSL_I2C_DEV_CLOCK_5200 0x00000002
+#define FSL_I2C_DEV_PROBE 0x00000004
enum fsl_usb2_operating_modes {
FSL_USB2_MPH_HOST,
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-16 10:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <20080716121059.2dbbfebe@hyperion.delvare>
Jean Delvare wrote:
> On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> The problem is that at this point in time, only a couple hwmon drivers
>>> have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
>>> would break most systems.
>>>
>>> I have a set of patches converting most hwmon drivers to new-style i2c.
>>> I plan to send it to Linus later today. Once all drivers are converted,
>>> everyone can start adding device definitions to platform code. And only
>>> once this is done for all platforms, you may remove I2C_CLASS_HWMON
>>> from the i2c-mpc driver.
>> Of course.
>>
>>> But even then, you can't exclude the possibility that some people want
>>> to keep relying on the auto-detection mode. In that case, the setting
>> I understood that this is only true for the HWMON devices. Why the
>> special treatment?
>
> Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.
>
> What makes hwmon a bit different is the historical context. Originally,
> the hwmon drivers were written for PCs, which have no per-system
> platform code, so declaring the devices was simply not an option.
> Additionally, i2c was maintained as part of the lm-sensors project
> itself. This determined the probe-everything approach that has ruled
> the i2c subsystem until recently. I've spent (with a few other
> developers) the past few years drawing a clear separation between i2c
> and hwmon, and now making it possible to declare i2c devices where
> possible. This is a lot of work if you want to do this without breaking
> any system out there (which is my case.)
I can image. Thanks for the explanation.
>
>>> of the I2C_CLASS_HWMON flag should become an attribute of each i2c-mpc
>>> device.
>> Yep, as probing might not be acceptable in some cases, I makes sense to
>> add a property to suppress probing:
>
> It'd rather make no-probing the default if possible. My understanding
> is that all systems using i2c-mpc should have proper platform data.
Yep, unfortunately, HWMON devices are not defined in most cases.
> But then again, that's not really my business. The decision is left to
> the actual users of this i2c bus driver.
A RFC patch is in preparation.
Wolfgang.
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: dinesh @ 2008-07-16 10:13 UTC (permalink / raw)
To: Nobin Mathew; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <8d6898730807160307g4455597ck921d55da8f51455d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]
no i am working on powerpc. MPC8323
-----Original Message-----
From: Nobin Mathew <nobin.mathew@gmail.com>
To: dinesh <dinesh.dua@coraltele.com>
Cc: Grant Likely <grant.likely@secretlab.ca>, linuxppc-dev@ozlabs.org,
alsa-devel@alsa-project.org, liam.girdwood@wolfsonmicro.com
Subject: Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
Date: Wed, 16 Jul 2008 15:37:54 +0530
Hi dinesh,
If you are working on ARM, see the ARM AACi code, in sound/arm/aaci.c
Thanks
Nobin Mathew.
On 7/16/08, dinesh <dinesh.dua@coraltele.com> wrote:
>
> Hi,
> I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i
> want to do data transfer to and from device myself using BUFFER DESCRIPTOR
> not with the usual DMA transfer.
> Please help me.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[-- Attachment #2: Type: text/html, Size: 2198 bytes --]
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Jean Delvare @ 2008-07-16 10:10 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <487DC457.6000103@grandegger.com>
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > The problem is that at this point in time, only a couple hwmon drivers
> > have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> > would break most systems.
> >
> > I have a set of patches converting most hwmon drivers to new-style i2c.
> > I plan to send it to Linus later today. Once all drivers are converted,
> > everyone can start adding device definitions to platform code. And only
> > once this is done for all platforms, you may remove I2C_CLASS_HWMON
> > from the i2c-mpc driver.
>
> Of course.
>
> > But even then, you can't exclude the possibility that some people want
> > to keep relying on the auto-detection mode. In that case, the setting
>
> I understood that this is only true for the HWMON devices. Why the
> special treatment?
Not really. There are other I2C_CLASS_* flags, just check <linux/i2c.h>.
What makes hwmon a bit different is the historical context. Originally,
the hwmon drivers were written for PCs, which have no per-system
platform code, so declaring the devices was simply not an option.
Additionally, i2c was maintained as part of the lm-sensors project
itself. This determined the probe-everything approach that has ruled
the i2c subsystem until recently. I've spent (with a few other
developers) the past few years drawing a clear separation between i2c
and hwmon, and now making it possible to declare i2c devices where
possible. This is a lot of work if you want to do this without breaking
any system out there (which is my case.)
> > of the I2C_CLASS_HWMON flag should become an attribute of each i2c-mpc
> > device.
>
> Yep, as probing might not be acceptable in some cases, I makes sense to
> add a property to suppress probing:
It'd rather make no-probing the default if possible. My understanding
is that all systems using i2c-mpc should have proper platform data.
But then again, that's not really my business. The decision is left to
the actual users of this i2c bus driver.
--
Jean Delvare
^ permalink raw reply
* Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
From: Nobin Mathew @ 2008-07-16 10:07 UTC (permalink / raw)
To: dinesh; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <1216199130.749.4.camel@dinesh.dua>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi dinesh,
If you are working on ARM, see the ARM AACi code, in sound/arm/aaci.c
Thanks
Nobin Mathew.
On 7/16/08, dinesh <dinesh.dua@coraltele.com> wrote:
>
> Hi,
> I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i
> want to do data transfer to and from device myself using BUFFER DESCRIPTOR
> not with the usual DMA transfer.
> Please help me.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
[-- Attachment #2: Type: text/html, Size: 1025 bytes --]
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-16 9:50 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <20080716113311.384d211e@hyperion.delvare>
Hi Jean;
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> For hwmon chips, probing only occurs if the i2c adapter accepts to be
>>> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
>>> you do not want a given i2c bus to be probed, then do not set the flag
>>> for that bus.
>> I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
>> for the MPC:
>>
>> http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
>>
>> If I disable it, the LM75 driver only probes the addresses of the I2C
>> nodes defined in the FDT DTS file. I wonder if this should not be the
>> default behaviour for kernels using OF platform description. For this
>> reason, I have put Linuxppc-dev ML on CC. I also realized, that there
>> are some patches for OF I2C pending. I will check.
>
> The problem is that at this point in time, only a couple hwmon drivers
> have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
> would break most systems.
>
> I have a set of patches converting most hwmon drivers to new-style i2c.
> I plan to send it to Linus later today. Once all drivers are converted,
> everyone can start adding device definitions to platform code. And only
> once this is done for all platforms, you may remove I2C_CLASS_HWMON
> from the i2c-mpc driver.
Of course.
> But even then, you can't exclude the possibility that some people want
> to keep relying on the auto-detection mode. In that case, the setting
I understood that this is only true for the HWMON devices. Why the
special treatment?
> of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc
> device.
Yep, as probing might not be acceptable in some cases, I makes sense to
add a property to suppress probing:
i2c@3000 {
...
compatible = "fsl-i2c";
dfsrr;
no-probing;
rtc@32 {
compatible = "epson,rx8025";
reg = <0x32>;
};
dtt@4c {
compatible = "dallas,ds75";
reg = <0x4c>;
};
};
> Anyway, this is something for every platform community to decide and
> work on. As the i2c subsystem maintainer, I made my best so that
> everything (sensible) is possible. But in the end it's up to the
> "users" (i.e. platform developers and maintainers) to make the decision
> of how things should work in their area. I can give advice on migration
> paths, but I can't take decisions for them.
I'm going to prepare a patch for that purpose.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Support for DS75 thermal sensor
From: Jean Delvare @ 2008-07-16 9:33 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <487DBB92.1070100@grandegger.com>
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
> Jean Delvare wrote:
> > For hwmon chips, probing only occurs if the i2c adapter accepts to be
> > probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> > you do not want a given i2c bus to be probed, then do not set the flag
> > for that bus.
>
> I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
> for the MPC:
>
> http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
>
> If I disable it, the LM75 driver only probes the addresses of the I2C
> nodes defined in the FDT DTS file. I wonder if this should not be the
> default behaviour for kernels using OF platform description. For this
> reason, I have put Linuxppc-dev ML on CC. I also realized, that there
> are some patches for OF I2C pending. I will check.
The problem is that at this point in time, only a couple hwmon drivers
have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
would break most systems.
I have a set of patches converting most hwmon drivers to new-style i2c.
I plan to send it to Linus later today. Once all drivers are converted,
everyone can start adding device definitions to platform code. And only
once this is done for all platforms, you may remove I2C_CLASS_HWMON
from the i2c-mpc driver.
But even then, you can't exclude the possibility that some people want
to keep relying on the auto-detection mode. In that case, the setting
of the I2C_CLASS_HWMON flag should become an attribute of eacg i2c-mpc
device.
Anyway, this is something for every platform community to decide and
work on. As the i2c subsystem maintainer, I made my best so that
everything (sensible) is possible. But in the end it's up to the
"users" (i.e. platform developers and maintainers) to make the decision
of how things should work in their area. I can give advice on migration
paths, but I can't take decisions for them.
--
Jean Delvare
^ permalink raw reply
* Re: [lm-sensors] [PATCH] Support for DS75 thermal sensor
From: Wolfgang Grandegger @ 2008-07-16 9:12 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev, Alan Clucas, Detlev Zundel, lm-sensors
In-Reply-To: <20080711145613.14380360@hyperion.delvare>
Hi Jean,
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Fri, 11 Jul 2008 14:40:58 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> There's no "detection" involved for the new-style i2c devices.
>>> Presumably you are still using the old binding model, not taking
>>> benefit of the patch at all. Use i2c_register_board_info() to
>>> instantiate your "ds75" i2c device from you board's platform code, and
>>> it should work.
>> I have some general question on I2C device probing. Our board does have
>> two I2C buses. On the first on, there is an RTC at addr 0x32 and a DS75
>> at 0x4c. Both are defined in the Flattened Device Tree and therefore
>> i2c_register_board_info() will be called for them. On the second bus,
>> there are other I2C devices. Nevertheless, probing for RTC and DS75 at
>> addr 0x32 and 0x4c will be performed also on that bus. Is this the
>> normal/intended behavior? Can such probing be suppressed?
>
> Probing isn't supposed to happen at all for RTC chips. There are a few
> drivers which remain to be converted though (rtc-ds1672, rtc-max6900,
> rtc-pcf8583.) If you use one of these and would like to help converting
> it, please tell me (and Alessandro Zummo.)
OK. We ported an old RTC driver for the Epson RX8025 for our board.
Unfortunately, it did not use the new bindings but I fixed that in the
meantime. It will be posted for kernel inclusion soon.
> For hwmon chips, probing only occurs if the i2c adapter accepts to be
> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> you do not want a given i2c bus to be probed, then do not set the flag
> for that bus.
I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
for the MPC:
http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
If I disable it, the LM75 driver only probes the addresses of the I2C
nodes defined in the FDT DTS file. I wonder if this should not be the
default behaviour for kernels using OF platform description. For this
reason, I have put Linuxppc-dev ML on CC. I also realized, that there
are some patches for OF I2C pending. I will check.
Wolfgang.
^ permalink raw reply
* WRITING AN SOC DRIVER WITHOUT DMA
From: dinesh @ 2008-07-16 9:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083939.15025.31192.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]
Hi,
I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i want to do data transfer to and from device myself using BUFFER DESCRIPTOR not with the usual DMA transfer.
Please help me.
[-- Attachment #2: Type: text/html, Size: 444 bytes --]
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Rene Herman @ 2008-07-16 8:09 UTC (permalink / raw)
To: Jean Delvare
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede, David Hubbard
In-Reply-To: <20080716094602.4379e0ff@hyperion.delvare>
On 16-07-08 09:46, Jean Delvare wrote:
> As a conclusion, there is no clear relationship between the presence
> of an ISA or LPC bridge and the presence of a Super-I/O chip. All we
> can say is that apparently all PC systems have an ISA bridge. So
> indeed we can probably make the probes conditional upon the presence
> of an "ISA bridge" PCI device. That's very easy to test. In practice
> it might be equivalent to making the driver x86-only.
And foregoing non (pre-) PCI. Admittedly, that might not be much of an
issue and I don't know if "Super-I/O" is maybe even defined such as to
make it a NON issue but I do for example remember my old 386 chipset
providing for extended serial rates which I thought was way cool back
then. If that's Super-I/O (or something that should/could be covered by
the infrastructure at least) then PCI wouldn't be helpful.
Rene.
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Arnd Bergmann @ 2008-07-16 8:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dave Jones, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <20080716042042.GA13212@redhat.com>
On Wednesday 16 July 2008, Dave Jones wrote:
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
FS_ENET and EP8248E both select MDIO_BITBANG, but not PHYLIB or MII, which
looks broken to me.
Also, I think it would be useful to split out the bitbang
driver from ep8248e.c, so that you can build it as a loadable
module if you want to have PHYLIB loadable.
Arnd <><
^ permalink raw reply
* Re: Videomode 800x480
From: Alex_SYS @ 2008-07-16 8:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <487CEC85.2070801@denx.de>
Hello,
Alex_SYS wrote:
> Hello, I have the problem that I need a Framebuffer resolution 800x480!
> Since now I have filled the fb_info, var and fix Structs!
> But there was the problem with the resolution!
> I have found out that the problem is the videomode!
> In modedb there is unfortunately no 800x480 Videomode, and I have tried my
> own 800x480 Struct, but the Kernel does`t want my settings (I tried to
> change an 800x600 to 800x480 only by changing yres to 480).
> Can someone tell me please a working fb_videomode struct for 800x480?
Values for 800x480 fb_videomode depend on the TFT-panel that
you are using. Without the spec of this panel it is hard to guess.
It is also hard to guess the value for .pixclock as we do not know
if internal or external clock is used as the source for display
reference clock. What is the value of GDC DCM0 register (at
offset 0x1fd0000 or 0x1fd0100 from the GDC base)?
Try something like this:
.xres = 800
.yres = 480
.pixclock = 40000
.left_margin = 86
.right_margin = 42
.upper_margin = 33
.lower_margin = 10
.hsync_len = 128
.vsync_len = 2
> The syncs are setted up by U-Boot .
>then you probably should retrieve proper values for fb_videomode
>from display controller registers set up by U-Boot. If you do not
>have the spec for your panel, it is the way to go. Consult the
>GDC manual (Display control registers section) and
>Documentation/fb/framebuffer.txt in the linux source tree.
Hello, the physical settings for sync are made by U-Boot and working!
But in Lunux when I use 800x480, the screen is well, but the Kernel crashes
at Bootup!
Using 800x600 works!
Now I need only "Dummy" settings, that I can tell Linux I would like 800x480
and the Kernel doesn`t crash!
I don`t know exactly why the Kernel crashes, I know only that the modedB
800x600 and so on work!
I will try your settings immediately!
Thanks
Alex
Best regards,
Anatolij
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/Videomode-800x480-tp18470632p18482586.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Arnd Bergmann @ 2008-07-16 7:54 UTC (permalink / raw)
To: Roland Dreier; +Cc: Mark Nelson, linuxppc-dev, cbe-oss-dev
In-Reply-To: <ada7ibmd115.fsf@cisco.com>
On Wednesday 16 July 2008, Roland Dreier wrote:
> =A0> Strong ordering is only active when both the bridge and the IOMMU en=
able
> =A0> it, but for correctly written drivers, this only results in a slowdo=
wn.
>=20
> So when would someone use this dma attribute? =A0As a hack to fix drivers
> where the real fix is too complicated?
This is used in the Axon PCIe endpoint drivers, e.g. in the Roadrunner
machine. The reason was to improve roundtrip latency by doing only
mmio stores, not loads, on each side of the PCIe connection, which
turn into posted DMA operations on the other end. With relaxed ordering,
the posted writes may be observed out of order. Strong ordering makes
sure they arrive in-order without having to do a non-posted mmio read
or eieio operation on the receiver side.
Arnd <><
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-16 7:46 UTC (permalink / raw)
To: David Hubbard
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede
In-Reply-To: <4dfa50520807150831i519a3a43n635ab7e58d35ba5e@mail.gmail.com>
Hi David,
On Tue, 15 Jul 2008 09:31:29 -0600, David Hubbard wrote:
> On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare <khali@linux-fr.org> wrote:
> > I always assumed that there was no way to know in advance if a
> > Super-I/O (LPC) chip was present or not, let alone the exact model of
> > the chip. The I/O addresses are decoded by the Super-I/O chip itself,
> > and in general it has no relation to PCI. And I've never seen ports
> > 0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports.
> >
> > But of course if there is a way to know, we should use it. Avoiding
> > random access to I/O ports, even if they are relatively standard in
> > this case, is always good.
>
> I looked at my lspci output and did a little researching, and I think
> the only thing we can deduce is that there is an LPC bridge, so
> looking for a SuperIO is a good idea. If there is no LPC bridge
> listed, I can't say whether probing the ports is a good idea or not.
Machines I have here have an "ISA bridge" PCI device. Some of them have
"LPC" in their name, but not all, and anyway the kernel only knows the
device ID, not its user-friendly name:
VIA:
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
Intel:
00:01.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
nVidia:
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
One of these machines has a LPC bridge but no (detected) Super-I/O chip.
The VIA and nVidia machines do not have "LPC" in their bridge name, but
they do have a Super-I/O chip, while the first Intel machine doesn't.
As a conclusion, there is no clear relationship between the presence of
an ISA or LPC bridge and the presence of a Super-I/O chip. All we can
say is that apparently all PC systems have an ISA bridge. So indeed we
can probably make the probes conditional upon the presence of an "ISA
bridge" PCI device. That's very easy to test. In practice it might be
equivalent to making the driver x86-only.
--
Jean Delvare
^ permalink raw reply
* [PATCH] Add AMCC Arches defconfig file
From: fkan @ 2008-07-16 5:37 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Victor Gallardo
From: Victor Gallardo <vgallard@amcc.com>
ppc4xx: Add AMCC Arches defconfig file
Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
arch/powerpc/configs/44x/arches_defconfig | 737 +++++++++++++++++++++++++++++
1 files changed, 737 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/44x/arches_defconfig
diff --git a/arch/powerpc/configs/44x/arches_defconfig b/arch/powerpc/configs/44x/arches_defconfig
new file mode 100644
index 0000000..55396c9
--- /dev/null
+++ b/arch/powerpc/configs/44x/arches_defconfig
@@ -0,0 +1,737 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.26-rc5
+# Mon Jun 30 15:41:11 2008
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+# CONFIG_6xx is not set
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+# CONFIG_40x is not set
+CONFIG_44x=y
+# CONFIG_E200 is not set
+CONFIG_4xx=y
+CONFIG_BOOKE=y
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
+CONFIG_GENERIC_HARDIRQS=y
+# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
+CONFIG_IRQ_PER_CPU=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_OF=y
+CONFIG_PPC_UDBG_16550=y
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+# CONFIG_DEFAULT_UIMAGE is not set
+CONFIG_PPC_DCR_NATIVE=y
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_PPC_DCR=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# General setup
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CGROUPS is not set
+# CONFIG_GROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_SYSFS_DEPRECATED_V2=y
+# CONFIG_RELAY is not set
+# CONFIG_NAMESPACES is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_COMPAT_BRK=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLUB_DEBUG=y
+# CONFIG_SLAB is not set
+CONFIG_SLUB=y
+# CONFIG_SLOB is not set
+# CONFIG_PROFILING is not set
+# CONFIG_MARKERS is not set
+CONFIG_HAVE_OPROFILE=y
+# CONFIG_KPROBES is not set
+CONFIG_HAVE_KPROBES=y
+CONFIG_HAVE_KRETPROBES=y
+# CONFIG_HAVE_DMA_ATTRS is not set
+CONFIG_PROC_PAGE_MONITOR=y
+CONFIG_SLABINFO=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+# CONFIG_MODULE_FORCE_LOAD is not set
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+CONFIG_CLASSIC_RCU=y
+CONFIG_PPC4xx_PCI_EXPRESS=y
+
+#
+# Platform support
+#
+# CONFIG_PPC_MPC512x is not set
+# CONFIG_PPC_MPC5121 is not set
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+# CONFIG_PQ2ADS is not set
+# CONFIG_BAMBOO is not set
+# CONFIG_EBONY is not set
+# CONFIG_SEQUOIA is not set
+# CONFIG_TAISHAN is not set
+# CONFIG_KATMAI is not set
+# CONFIG_RAINIER is not set
+# CONFIG_WARP is not set
+# CONFIG_CANYONLANDS is not set
+CONFIG_ARCHES=y
+# CONFIG_YOSEMITE is not set
+CONFIG_460GT=y
+# CONFIG_IPIC is not set
+# CONFIG_MPIC is not set
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PPC_RTAS is not set
+# CONFIG_MMIO_NVRAM is not set
+# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
+# CONFIG_PPC_INDIRECT_IO is not set
+# CONFIG_GENERIC_IOMAP is not set
+# CONFIG_CPU_FREQ is not set
+# CONFIG_FSL_ULI1575 is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+CONFIG_TICK_ONESHOT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+# CONFIG_SCHED_HRTICK is not set
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_MATH_EMULATION is not set
+# CONFIG_IOMMU_HELPER is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_HAS_WALK_MEMORY=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
+CONFIG_PAGEFLAGS_EXTENDED=y
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
+CONFIG_FORCE_MAX_ZONEORDER=11
+CONFIG_PROC_DEVICETREE=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE=""
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_4xx_SOC=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+CONFIG_PCI_SYSCALL=y
+# CONFIG_PCIEPORTBUS is not set
+CONFIG_ARCH_SUPPORTS_MSI=y
+# CONFIG_PCI_MSI is not set
+CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_DEBUG is not set
+# CONFIG_PCCARD is not set
+# CONFIG_HOTPLUG_PCI is not set
+# CONFIG_HAS_RAPIDIO is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_PAGE_OFFSET=0xc0000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_PHYSICAL_START=0x00000000
+CONFIG_TASK_SIZE=0xc0000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_CAN is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+
+#
+# Wireless
+#
+# CONFIG_CFG80211 is not set
+# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
+# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+CONFIG_FW_LOADER=y
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+# CONFIG_SYS_HYPERVISOR is not set
+CONFIG_CONNECTOR=y
+CONFIG_PROC_EVENTS=y
+# CONFIG_MTD is not set
+CONFIG_OF_DEVICE=y
+# CONFIG_PARPORT is not set
+CONFIG_BLK_DEV=y
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=35000
+# CONFIG_BLK_DEV_XIP is not set
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+# CONFIG_XILINX_SYSACE is not set
+# CONFIG_MISC_DEVICES is not set
+CONFIG_HAVE_IDE=y
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_DMA is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+# CONFIG_MD is not set
+# CONFIG_FUSION is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+# CONFIG_FIREWIRE is not set
+# CONFIG_IEEE1394 is not set
+# CONFIG_I2O is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NETDEVICES_MULTIQUEUE is not set
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+# CONFIG_ARCNET is not set
+# CONFIG_PHYLIB is not set
+CONFIG_NET_ETHERNET=y
+# CONFIG_MII is not set
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=256
+CONFIG_IBM_NEW_EMAC_TXB=256
+CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
+# CONFIG_IBM_NEW_EMAC_DEBUG is not set
+CONFIG_IBM_NEW_EMAC_ZMII=y
+CONFIG_IBM_NEW_EMAC_RGMII=y
+CONFIG_IBM_NEW_EMAC_TAH=y
+CONFIG_IBM_NEW_EMAC_EMAC4=y
+# CONFIG_NET_PCI is not set
+# CONFIG_B44 is not set
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_10000 is not set
+# CONFIG_TR is not set
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 is not set
+# CONFIG_IWLWIFI_LEDS is not set
+# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+# CONFIG_ISDN is not set
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+CONFIG_DEVKMEM=y
+# CONFIG_SERIAL_NONSTANDARD is not set
+# CONFIG_NOZOMI is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+# CONFIG_SERIAL_8250_PCI is not set
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+# CONFIG_RAW_DRIVER is not set
+# CONFIG_TCG_TPM is not set
+CONFIG_DEVPORT=y
+# CONFIG_I2C is not set
+# CONFIG_SPI is not set
+# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
+# CONFIG_HWMON is not set
+# CONFIG_THERMAL is not set
+# CONFIG_WATCHDOG is not set
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
+# CONFIG_HTC_PASIC3 is not set
+
+#
+# Multimedia devices
+#
+
+#
+# Multimedia core support
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+# CONFIG_VIDEO_MEDIA is not set
+
+#
+# Multimedia drivers
+#
+CONFIG_DAB=y
+
+#
+# Graphics support
+#
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_VGASTATE is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=m
+# CONFIG_FB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_MMC is not set
+# CONFIG_MEMSTICK is not set
+# CONFIG_NEW_LEDS is not set
+# CONFIG_ACCESSIBILITY is not set
+# CONFIG_INFINIBAND is not set
+# CONFIG_EDAC is not set
+# CONFIG_RTC_CLASS is not set
+# CONFIG_DMADEVICES is not set
+# CONFIG_UIO is not set
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4DEV_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_OCFS2_FS is not set
+CONFIG_DNOTIFY=y
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_ROMFS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+CONFIG_NETWORK_FILESYSTEMS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+# CONFIG_NLS is not set
+# CONFIG_DLM is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# CONFIG_GENERIC_FIND_FIRST_BIT is not set
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_CRC7 is not set
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_FRAME_WARN=1024
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+CONFIG_DEBUG_FS=y
+# CONFIG_HEADERS_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DETECT_SOFTLOCKUP=y
+CONFIG_SCHED_DEBUG=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
+# CONFIG_DEBUG_OBJECTS is not set
+# CONFIG_SLUB_DEBUG_ON is not set
+# CONFIG_SLUB_STATS is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_DEBUG_KOBJECT is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_WRITECOUNT is not set
+# CONFIG_DEBUG_LIST is not set
+# CONFIG_DEBUG_SG is not set
+# CONFIG_BOOT_PRINTK_DELAY is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_BACKTRACE_SELF_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_SAMPLES is not set
+# CONFIG_KGDB is not set
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+CONFIG_DEBUGGER=y
+# CONFIG_XMON is not set
+# CONFIG_IRQSTACKS is not set
+# CONFIG_VIRQ_DEBUG is not set
+# CONFIG_BDI_SWITCH is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
+# CONFIG_CRYPTO is not set
+# CONFIG_PPC_CLOCK is not set
+# CONFIG_VIRTUALIZATION is not set
--
1.5.5
^ permalink raw reply related
* [PATCH] Add AMCC Arches DTS
From: fkan @ 2008-07-16 5:34 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Victor Gallardo
From: Victor Gallardo <vgallard@amcc.com>
ppc4xx: Add AMCC Arches DTS
Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
arch/powerpc/boot/dts/arches.dts | 522 ++++++++++++++++++++++++++++++++++++++
1 files changed, 522 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/arches.dts
diff --git a/arch/powerpc/boot/dts/arches.dts b/arch/powerpc/boot/dts/arches.dts
new file mode 100644
index 0000000..459cec2
--- /dev/null
+++ b/arch/powerpc/boot/dts/arches.dts
@@ -0,0 +1,522 @@
+/*
+ * Device Tree Source for AMCC Arches (dual 460GT board)
+ *
+ * (C) Copyright 2008
+ * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
+ * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
+ *
+ * Based on the glacier.dts file
+ * Stefan Roese <sr@denx.de>
+ * Copyright 2008 DENX Software Engineering
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,arches";
+ compatible = "amcc,arches";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460GT";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460gt";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460gt";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460gt", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460gt", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460gt", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <20>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ desc-base-addr-high = <8>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460gt", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460gt", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "kernel";
+ reg = <0 1e0000>;
+ };
+ partition@1e0000 {
+ label = "dtb";
+ reg = <1e0000 20000>;
+ };
+ partition@200000 {
+ label = "ramdisk";
+ reg = <200000 1400000>;
+ };
+ partition@1600000 {
+ label = "jffs2";
+ reg = <1600000 400000>;
+ };
+ partition@1a00000 {
+ label = "user";
+ reg = <1a00000 2560000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460gt", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ RGMII1: emac-rgmii@ef601600 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601600 8>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601350 30>;
+ };
+
+ TAH1: emac-tah@ef601450 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601450 30>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+
+ EMAC2: ethernet@ef601100 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC2>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 12 4
+ /*Wake*/ 1 &UIC2 16 4>;
+ reg = <ef601100 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2>;
+ mal-rx-channel = <10>;
+ cell-index = <2>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+
+ EMAC3: ethernet@ef601200 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC3>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 13 4
+ /*Wake*/ 1 &UIC2 17 4>;
+ reg = <ef601200 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <3>;
+ mal-rx-channel = <18>;
+ cell-index = <3>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ mdio-device = <&EMAC0>;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460gt", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.5
^ permalink raw reply related
* [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: fkan @ 2008-07-16 5:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Victor Gallardo
From: Victor Gallardo <vgallard@amcc.com>
ppc4xx: Add AMCC Arches 460GT eval board support
Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
arch/powerpc/platforms/44x/Kconfig | 18 ++++++++
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/arches.c | 76 +++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/arches.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 6abe913..95d1217 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -77,6 +77,16 @@ config CANYONLANDS
help
This option enables support for the AMCC PPC460EX evaluation board.
+config ARCHES
+ bool "Arches"
+ depends on 44x
+ default n
+ select 460GT
+ select PCI
+ select PPC4xx_PCI_EXPRESS
+ help
+ This option enables support for the AMCC PPC460GT Arches board.
+
config YOSEMITE
bool "Yosemite"
depends on 44x
@@ -149,6 +159,14 @@ config 460EX
select IBM_NEW_EMAC_ZMII
select IBM_NEW_EMAC_TAH
+config 460GT
+ bool
+ select PPC_FPU
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
+ select IBM_NEW_EMAC_TAH
+
# 44x errata/workaround config symbols, selected by the CPU models above
config IBM440EP_ERR42
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 774165f..86a4823 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_CANYONLANDS) += canyonlands.o
+obj-$(CONFIG_ARCHES) += arches.o
diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c
new file mode 100644
index 0000000..6d6aa66
--- /dev/null
+++ b/arch/powerpc/platforms/44x/arches.c
@@ -0,0 +1,76 @@
+/*
+ * Arches board specific routines
+ *
+ * (C) Copyright 2008
+ * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
+ * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
+ *
+ * Based on the Canyonlands code by
+ * Stefan Roese <sr@denx.de>
+ * Copyright 2008 DENX Software Engineering
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <linux/init.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+
+static __initdata struct of_device_id arches_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init arches_device_probe(void)
+{
+ of_platform_bus_probe(NULL, arches_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(arches, arches_device_probe);
+
+static int __init arches_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,arches"))
+ return 0;
+
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
+ return 1;
+}
+
+define_machine(arches) {
+ .name = "Arches",
+ .probe = arches_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.5
^ permalink raw reply related
* Re: DTC: libfdt Install Woes
From: David Gibson @ 2008-07-16 5:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1216149974.20700.14.camel@ld0161-tx32>
On Tue, Jul 15, 2008 at 02:26:14PM -0500, Jon Loeliger wrote:
> David,
>
> Somewhat recently, the DTC commit 6a6c972cdf9e
> "dtc: Clean up included Makefile fragments"
> removed this line
>
> LIBFDT_INCLUDES = fdt.h libfdt.h
>
> from the libfdt/Makefile.libfdt. As a result,
> the standalone "make install" is onw failing.
Oops, that was a bit silly of me.
>
> We could put that line back, or remove the
> top-level Makefile install target that is
> trying to use this definition.
>
> I'm not sure which direction you want to head here.
I'd prefer to go with changing the top-level Makefile target.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-16 5:01 UTC (permalink / raw)
To: Dave Jones
Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list,
Kumar Gala
In-Reply-To: <20080716042042.GA13212@redhat.com>
On Wed, 2008-07-16 at 00:20 -0400, Dave Jones wrote:
> On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote:
> > Linus,
> >
> > I apologize in advance for the couple of merge commits in there. I
> > merged your tree yesterday in order to fix a (fairly minor) conflict,
> > and waited for our autobuilder to test a whole bunch of configs
> > overnight before asking you to pull, at which point, sfr informed me of
> > a bunch of this time non-trivial conflicts with whatever you pulled in
> > the meantime...
> >
> > So here it is with 2 merge csets at the top, I'll try to do better next
> > time. I don't want to rebase or my sub-maintainers will hate me.
> >
> > So please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> Boom!
>
> arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
> /builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
>
> .config is at http://davej.fedorapeople.org/kernel-2.6.27-ppc.config
Kumar, I think that's your realm, what's up there ?
Cheers,
Ben.
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Dave Jones @ 2008-07-16 4:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, akpm, Linus Torvalds, Linux Kernel list
In-Reply-To: <1216172043.7740.136.camel@pasglop>
On Wed, Jul 16, 2008 at 11:34:03AM +1000, Ben Herrenschmidt wrote:
> Linus,
>
> I apologize in advance for the couple of merge commits in there. I
> merged your tree yesterday in order to fix a (fairly minor) conflict,
> and waited for our autobuilder to test a whole bunch of configs
> overnight before asking you to pull, at which point, sfr informed me of
> a bunch of this time non-trivial conflicts with whatever you pulled in
> the meantime...
>
> So here it is with 2 merge csets at the top, I'll try to do better next
> time. I don't want to rebase or my sub-maintainers will hate me.
>
> So please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Boom!
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to `alloc_mdio_bitbang'
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to `mdiobus_register'
.config is at http://davej.fedorapeople.org/kernel-2.6.27-ppc.config
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* [PATCH] powerpc: Streamline ret_from_except_lite for non-iSeries platforms
From: Michael Ellerman @ 2008-07-16 4:21 UTC (permalink / raw)
To: linuxppc-dev
There is a small passage of code in ret_from_except_lite which is
only required on iSeries. For a multi-platform kernel on non-iSeries
machines this means we end up executing ~15 nops in ret_from_except_lite.
It would be nicer if non-iSeries could skip the code entirely, and on
iSeries we can jump out of line to execute the code.
I have no performance numbers to justify this, other than the assertion
that executing 15 nops takes longer than executing 0.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
Booted on POWER5 & legacy iSeries.
arch/powerpc/kernel/entry_64.S | 53 ++++++++++++++++++++++------------------
1 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index d736924..fff7490 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -507,31 +507,12 @@ _GLOBAL(ret_from_except_lite)
#endif
restore:
- ld r5,SOFTE(r1)
-#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
- cmpdi 0,r5,0
- beq 4f
- /* Check for pending interrupts (iSeries) */
- ld r3,PACALPPACAPTR(r13)
- ld r3,LPPACAANYINT(r3)
- cmpdi r3,0
- beq+ 4f /* skip do_IRQ if no interrupts */
-
- li r3,0
- stb r3,PACASOFTIRQEN(r13) /* ensure we are soft-disabled */
-#ifdef CONFIG_TRACE_IRQFLAGS
- bl .trace_hardirqs_off
- mfmsr r10
-#endif
- ori r10,r10,MSR_EE
- mtmsrd r10 /* hard-enable again */
- addi r3,r1,STACK_FRAME_OVERHEAD
- bl .do_IRQ
- b .ret_from_except_lite /* loop back and handle more */
-4:
-END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-#endif
+ ld r5,SOFTE(r1)
+FW_FTR_SECTION_ELSE
+ b iseries_check_pending_irqs
+ALT_FW_FTR_SECTION_END_IFCLR(FW_FEATURE_ISERIES)
+2:
TRACE_AND_RESTORE_IRQ(r5);
/* extract EE bit and use it to restore paca->hard_enabled */
@@ -587,6 +568,30 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
rfid
b . /* prevent speculative execution */
+iseries_check_pending_irqs:
+#ifdef CONFIG_PPC_ISERIES
+ ld r5,SOFTE(r1)
+ cmpdi 0,r5,0
+ beq 2b
+ /* Check for pending interrupts (iSeries) */
+ ld r3,PACALPPACAPTR(r13)
+ ld r3,LPPACAANYINT(r3)
+ cmpdi r3,0
+ beq+ 2b /* skip do_IRQ if no interrupts */
+
+ li r3,0
+ stb r3,PACASOFTIRQEN(r13) /* ensure we are soft-disabled */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_off
+ mfmsr r10
+#endif
+ ori r10,r10,MSR_EE
+ mtmsrd r10 /* hard-enable again */
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ bl .do_IRQ
+ b .ret_from_except_lite /* loop back and handle more */
+#endif
+
do_work:
#ifdef CONFIG_PREEMPT
andi. r0,r3,MSR_PR /* Returning to user mode? */
--
1.5.5
^ permalink raw reply related
* Re: Failure of request_irq() for MPC8313 using arch=powerpc
From: Duy-Ky Nguyen @ 2008-07-16 3:43 UTC (permalink / raw)
To: Liu Dave, linuxppc-embedded
In-Reply-To: <58A20A281BAF1047B4EAE68DE5C0BDC2010573E9@zch01exm21.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 3292 bytes --]
Hi Dave,
I've just tried it and it failed.
Before I had tried using the function
int virq = of_irq_to_resource(GPIO_IRQ, 0, NULL);
and it failed the same way
I call request_irq() in the operation init and open, it behaves the same
I greatky appreciate your help, Dave.
Best Regards,
Duy-Ky
//////////////////////////////////////////////////////////////////////////
// Start of capture
Unable to handle kernel paging request for data at address 0x0000005e
Faulting instruction address: 0xc000d1e8
Oops: Kernel access of bad area, sig: 11 [#1]
Modules linked in: ppc_drv
NIP: C000D1E8 LR: C000D274 CTR: C0006088
REGS: c7883d20 TRAP: 0300 Not tainted (2.6.20)
MSR: 00009032 <EE,ME,IR,DR> CR: 22000448 XER: 00000000
DAR: 0000005E, DSISR: 20000000
TASK = c053a810[767] 'rrgg' THREAD: c7882000
GPR00: C000D274 C7883DD0 C053A810 0000004A C0282BA8 C7883E08 C7FD9440 C0273EEC
GPR08: 00000000 00000000 00000100 C0006088 22000448 10018D00 07FFD000 28000422
GPR16: 10090000 100B0000 100B7328 00000000 00000000 00000000 100C8968 100C89A8
GPR24: 100BDFE8 00000000 00000000 C7FD9440 FFFFFFEA C7883E08 C0282BA8 0000004A
Call Trace:
[C7883DD0] [C7FD5EE8] (unreliable)
[C7883DF0] [C000D274]
[C7883E00] [C0009FC8]
[C7883E30] [C000609C]
[C7883E60] [C9072030]
[C7883E70] [C0063E5C]
[C7883EA0] [C005FFAC]
[C7883EC0] [C0060244]
[C7883F20] [C00602B8]
[C7883F40] [C000F540]
--- Exception: c01Instruction dump:
409effc8 80030024 900b0020 4e800020 7d800026 9421ffe0 7c0802a6 bfa10014
7c9e2378 7cbd2b78 91810010 90010024 <83e30014> 2f9f0000 419e0028 2e050000
Segmentation fault
// End of Capture
----- Original Message -----
From: Liu Dave
To: Duy-Ky Nguyen ; linuxppc-embedded@ozlabs.org
Sent: Tuesday, July 15, 2008 7:09 PM
Subject: RE: Failure of request_irq() for MPC8313 using arch=powerpc
Hi Nguyen,
If current PowerPC linux is using the virq to request_irq,
you need do the irq_of_parse_and_map(np, 0) to get the virq.
like.
virq = irq_of_parse_and_map(np, 0)
request_irq(virq,...);
Hope it can help you.
Thanks,
Dave
----------------------------------------------------------------------------
From: linuxppc-embedded-bounces+daveliu=freescale.com@ozlabs.org [mailto:linuxppc-embedded-bounces+daveliu=freescale.com@ozlabs.org] On Behalf Of Duy-Ky Nguyen
Sent: 2008年7月16日 8:59 AM
To: linuxppc-embedded@ozlabs.org
Subject: Failure of request_irq() for MPC8313 using arch=powerpc
Hello,
I had no problem in using request_irq() for MPC8272 with arch=ppc from Montavista Linux
But I have failure for MPC8313 with arch=powerpc from FreeScale LTIB Linux with error code -38
I found its header file mpc83xx.h under include/asm-ppc, while it's supposed to be under include/asm-powerpc.
I did try to copy the header file to directory asm-powerpc
From MPC8313 datasheet, I have
GPIO_IRQ = 74
and I use
DEVICE_NAME = "ppc"
IRQ_FLAG = IRQF_SHARED // use new flag
here my function call
request_irq (GPIO_IRQ,
ppc_ISR,
IRQ_FLAG,
DEVICE_NAME,
NULL);
I'd appreciate any help on this problem.
Best Regards,
Duy-Kyng
[-- Attachment #2: Type: text/html, Size: 9137 bytes --]
^ permalink raw reply
* Re: SW TLB MMU rework and SMP issues
From: Benjamin Herrenschmidt @ 2008-07-16 2:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <BF59BFC7-736B-4D3F-9227-97DC90CE4739@kernel.crashing.org>
On Tue, 2008-07-15 at 16:58 -0500, Kumar Gala wrote:
> Ben,
>
> I've been giving some thought to the new software managed TLBs and SMP
> issues. I was wondering if you had any insights on how we should deal
> with the following issues:
As discussed on IRC (might interest others...)
> * tlb invalidates -- need to ensure we don't have multiple tlbsync's
> on the bus. I'm thinking for e500/fsl we will move to IPI based
> invalidate broadcast and do invalidates locally
> (http://patchwork.ozlabs.org/linuxppc/patch?id=19657 )
Well, you can just have all your invalidations wrapped in a spinlock.
The "trick" of course is for full-mm invalidates such as page tables
teardown or fork, to avoid doing a lock/unlock & IPI for every PTE of
course. A way to do it is to do some batching, though it isn't trivial.
Without support for TLB invalidate all or by PID, what you can do maybe
is to manually do an invalidate by PID with a tlbre/tlbwe loop. Check
the worst case scenario of walking your entire TLB vs. small processes
that carry only a handful of PTEs....
You can use the batch interface to 'count' things on page table teardown
and decide based on a threshold of invalidated PTEs what approach is
more likely to be useful, but can't really use the batch interface for
fork.
> * 64-bit PTEs and reader vs writer hazards. How do we ensure that the
> TLB miss handler samples a consistent view of the pte. pte_updates
> seem ok since we only update the flag word. However set_pte_at seems
> like it could be problematic.
eieio on the writer and a data dependency on the reader. segher
suggested a nice way to do it on the reader side, by doing a subf of the
value from the pointer and then a lwxz using that value as an offset.
ie. something like that, with r3 containing the PTE pointer:
lwz r10,4(r3)
subf r4,r10,r3 <-- you can use r3,r10,r3 if clobber is safe
lwzx r11,r10,r4 <-- in which case you use r3 here too
That ensures that the top half is loaded after the bottom half, which
is what you want if you do the set_pte_at() that way:
stw r11,0(r3) <-- write top half first
eieio <-- maitain order to coherency domain
stw r10,4(r3) <-- write bottom half last
In fact, in the reader case, while at it, you can interleave that with
the testing of the present bit. Assuming _PAGE_PRESENT is in the low
bits and you can clobber r3, you get something like:
lwz r10,4(r3)
<-- can't do much here unless you can do unrelated things -->
andi. r0,r10,_PAGE_PRESENT
subf r3,r10,r3
beq page_fault
lwzx r11,r10,r3
Cheers,
Ben.
^ 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