* Re: [PATCH 0/3] Add device-tree aware NDFC driver
From: Valentine Barshak @ 2007-10-30 14:13 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <alpine.LFD.0.9999.0710300235580.3186@localhost.localdomain>
Thomas Gleixner wrote:
> On Mon, 29 Oct 2007, Valentine Barshak wrote:
>
>> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
>> The code is based on the original NDFC driver by Thomas Gleixner, but
>> since it's been changed much and has initialization/clean-up completely
>> reworked it's been put into a separate ndfc_of.c file. This version
>> supports both separate mtd devices on each chip attached to NDFC banks and
>> single mtd device spread across identical chips (not using mtdconcat) as well.
>> The choice is selected with device tree settings. This has been tested
>> on PowerPC 440EPx Sequoia board.
>> Any comments are greatly appreciated.
>
> Did I express myself not clear enough in my first reply or is this
> just a repeated epiphany in my inbox ?
>
> You got plenty of comments to your patches, but you decided to ignore
> them silently.
>
> Darn, fix it the right way once and forever and please don't try to
> tell me another heartrending "why I did it my way" story.
>
> This all can be done with a nice series of incremental patches
> including a fixup to the existing users.
>
> We have enough dump and run shit in the kernel already.
>
> No thanks,
>
> tglx
You know, you're really too tense Thomas. I'm not sure of the reason why
you're being a complete nerve, but I'm feeling sorry for you.
I'm not saying my approach is the best, but I was hoping for a discussion.
I've reworked the patches according to the comments to the previous
version and used my arguments to explain why I don't see much reason to
mess with the code we currently have and added a separate _of version.
I'm sure you'd find some time to do it yourself "the right way once and
forever" with a "nice series of incremental patches" to fix what we
currently have (call it a "dump" or anything you like) and even maybe
add new device tree support.
I'm sorry if for some reason I've made you feel bad.
This is the last time I disturb you with my e-mail, so please, forget it.
Thank you very much for your comments anyway.
It's been nice talking to you,
Valentine.
^ permalink raw reply
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Sergei Shtylyov @ 2007-10-30 14:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <42A23BAB-6081-41CC-870C-7C7F094D69C3@kernel.crashing.org>
Hello.
Kumar Gala wrote:
>>The decrementer in Book E and 4xx processors interrupts on the
>>transition from 1 to 0, rather than on the 0 to -1 transition as on
>>64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
>>This fixes the problem by making set_dec subtract 1 from the count for
>>server and classic processors. Since set_dec already had a bunch of
>>ifdefs to handle different processor types, there is no net increase
>>in ugliness. :)
>>This also removes a redundant call to set the decrementer to
>>0x7fffffff - it was already set to that earlier in timer_interrupt.
>>Signed-off-by: Paul Mackerras <paulus@samba.org>
>>---
> ...
>>diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
>>index f058955..eed64bd 100644
>>--- a/include/asm-powerpc/time.h
>>+++ b/include/asm-powerpc/time.h
>>@@ -183,6 +183,7 @@ static inline void set_dec(int val)
>> #elif defined(CONFIG_8xx_CPU6)
>> set_dec_cpu6(val);
>> #else
>>+ --val; /* classic decrementer interrupts when dec goes negative */
>> #ifdef CONFIG_PPC_ISERIES
>> int cur_dec;
> Unless I'm reading set_dec() you are getting --val on booke.
You meant "misreading"?
Indeed the patch is decrementing count for *both* book E and classic CPUs
now, and that slipped past my attention the first time. The patch summary
("Fix off-by-one error in setting decrementer on Book E") also looks stange --
there is *no* off-by-one error on Book E, and the description correctly says
that we're fixing off-by-one on classic/server CPUs.
Maybe I should even go and post my patch variant instead...
WBR, Sergei
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-30 14:56 UTC (permalink / raw)
To: David Gibson, Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071030005146.GF29263@localhost.localdomain>
=20
> -----Original Message-----
> From: David Gibson [mailto:david@gibson.dropbear.id.au]=20
> Sent: Monday, October 29, 2007 7:52 PM
> To: Olof Johansson
> Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>=20
> On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote:
> [snip]
> > I don't see how switching the property name from "device_type" to
> > "class" is going to stop people from misunderstanding it's intended
> > use. There's nothing inherently more understandable in calling it
> > "class" -- it also invites people to make up their own class names
> > as they go along, just as what happened to "device_type".
> >=20
> > I also don't understand the people wanting to use "compatible"
> > for _everything_. It's just mashing together two separate pieces of
> > information into one property, and I seriously don't see=20
> how that helps
> > anything or anyone. It's absolutely useless for a driver to=20
> be able to
> > bind to a compatible field of "standard,network" or=20
> whatever it might be,
> > since there's no way that "standard," will imply that the=20
> register layout
> > and programming model is somehow the same as all other=20
> standard-labelled
> > devices.
> >=20
> > So yes, there is a problem with the device trees and how=20
> people build
> > them, and it requires education on how to properly craft=20
> one. I don't
> > think changing the layout to either be flatter (only using=20
> compatible),
> > or changing names of a property (device_type->class) will=20
> help anything
> > at all.
> >=20
> > I actually prefer keeping device_type myself, since it=20
> means existing
> > OF-based device trees will already have some of the labels.
>=20
> Yeah.. what he said.
>=20
> The *only* substantive change with the "class" proposal is the fact
> that multiple classes can be specified. That's nice, but I don't
> think it's worth the trouble of attempting to define a whole new chunk
> of standard for.
I tend to agree, but I think device_type serves a useful
purpose. I don't think we should deprecate it.
> Stuart, I think you overestimate the value of this class property to a
> human reader. The generic names convention (not followed as much as
> it should be) means the name should give the reader some idea of what
> the device is, in most cases. For trickier cases, if we really want
> something for humans reading the tree, we could add an optional
> "comment" or "description" property with purely human readable
> information.
>=20
> I think we should leave existing IEEE1275 defined uses of device_type,
> in order not to make flat trees gratuitously different from real-OF
> trees, but we should avoid any new use of device_type.
I'm fine with keeping device_type, but there are a few
of things I don't like about the 'no new use'.
1. There are types of nodes that don't have a programming
inteface per se and thus no compatible.
"cpu", "memory", "cache" are 3 that come to mind.
What if there is a _new_ class of nodes of this type?
What is wrong with a new use of device_type for something
say like "i2c"?
Conceptually and ideally, what _is_ the right way to
represent these types of devices.
2. 'Existing IEEE1275 defined uses' of device_type is=20
actually very vague. There are a conglomeration of
old bindings, recommended practices, proposals and
it is not clear at all which are useful or not. What
are the existing IEEE1275 uses??? I actually went
through all the OF documents and there are dozens
of device types that have no practical use.
Also, many 'real-OF' trees seem to follow no published
binding at all.
Conceptually, I'd like to a crisp list of 'official'
bindings and hope that the current ePAPR work in
power.org will establish this list. =20
3. You're advocating deprecating device_class, but still
requiring it for certain node types. So a "network"
node is _required_ to have the deprecated
device_type=3D"network". But a "i2c" node is required
_not_ to have device_type. Long term, I'd like to see
any inconsitency be removed. If device_type is=20
deprecated, it's use should be optional in flat=20
device trees. That goes for "cpu", "memory", etc.
I think what we should do is keep device_type, including
permitting new uses of it in a limited way-- only permitting
the use of device_type when there is an official binding
(like in the power.org ePAPR) defined. =20
> Explicitly specifying what device class bindings / conventions the
> node complies with is cute, but not actually all that useful in
> practice. If it looks like a "duck" class device node, and it
> quacks^Whas the properties of a "duck" class device node, it's "duck"
> class compliant.
>=20
> Or to look at it another way, "class bindings" aren't really bindings,
> but rather a set of conventions that device bindings for specific
> devices in that class ought to follow.
I tend to think of a 'binding' as a 'set of conventions'.
^ permalink raw reply
* libfdt as its own repo and submodule of dtc?
From: Kumar Gala @ 2007-10-30 15:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linux-ppc list, Jerry Van Baren, David Gibson
Jon,
It seems like have libfdt as a unique git repo that is a submodule of
the things that need it (dtc, u-boot, etc.) might make some sense and
it easier for the projects that need to pull it in.
Is this something you can take a look at? (or have other ideas on).
- k
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-30 15:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Martin Krause, David Gibson
In-Reply-To: <fa686aa40710290840w41e2ffeo38b9497ce76e155@mail.gmail.com>
Grant Likely wrote:
> On 10/29/07, Marian Balakowicz <m8@semihalf.com> wrote:
>> David Gibson wrote:
>>> On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
>>>> Grant Likely wrote:
>>>>> On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
>>> [snip]
>>>>>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
>>>>>> partition could not be used. "big-fs", because the memory is too small
>>>>>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
>>>>>> flash border. So only the first 9 MiB of the flash could be used in Linux.
>>>>>> The remaining 7 MiB couldn't be accessed.
>>>>> Perhaps it would be better to drop the flash layout from the in-kernel
>>>>> dts files entirely since flash layout can be a fluid thing.
>>>> Well, but that would not be really user friendly, I'd rather stick
>>>> with some default config.
>>> Strictly speaking the device-tree is not the right place for flash
>>> partitioning information. We put it there because it's preferable to
>>> having hardcoded per-board flash layouts in the code itself.
>>>
>>> It only really works well, though, when there are strong conventions
>>> (shared with the firmware) about how to partition the flash.
>>>
>>> Where it's really up to the user to determine how they want to lay out
>>> their flash, putting things in the device tree isn't a really good
>>> idea.
>> In principle, you are right, we should not be putting a user dependent
>> configuration into .dts files. But on the other hand, bindings have
>> been defined for flash-like devices and their partition layouts and
>> physmap_of device driver is expecting to get this information from the
>> blob. So, it is the place for it. But if we are not to put partition
>> layouts into the default kernel .dts files then we should
>> provide/maintain some examples an that may be a even bigger mess.
>>
>>> Incidentally, it's not required that *all* the flash address space be
>>> in partitions, so it is possible only give partitions for those flash
>>> chunks which the firmware needs to know about.
>> That might be nicer solution but different variants of TQM5200 boards
>> do not share the same subset of partitions (default u-boot partitions
>> at least), so it will not help much.
>
> It's probably more appropriate to have the flash partition layout in
> the u-boot environment and have u-boot populate the partition
> information in the device tree.
Yes, it's more appropriate but such feature is not currently available
in U-boot, so it has to be hand crafted until then. It just seemed
more convenient to have some reference example before there is a
support for passing partition layout from firmware.
But all right, will remove flash layouts from in-kernel .dts files.
Cheers,
m.
^ permalink raw reply
* videobuf
From: Robert Woodworth @ 2007-10-30 15:28 UTC (permalink / raw)
To: linuxppc-embedded
I'm working on building a v4l2 driver for an FPGA module on a Xilinx
Virtex4 PPC.
Question:
Why does the v4l2 videobuf *depend* on PCI?
Rob.
^ permalink raw reply
* Re: libfdt as its own repo and submodule of dtc?
From: Jon Loeliger @ 2007-10-30 15:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list, David Gibson, Jerry Van Baren
In-Reply-To: <C98039BC-92DE-4398-B198-EDAD12A3670C@kernel.crashing.org>
So, like, the other day Kumar Gala mumbled:
> Jon,
>
> It seems like have libfdt as a unique git repo that is a submodule of
> the things that need it (dtc, u-boot, etc.) might make some sense and
> it easier for the projects that need to pull it in.
>
> Is this something you can take a look at? (or have other ideas on).
I would be fine with making libfdt a git repository separate
from the DTC repository if that makes it easier to integrate
it with other projects.
jdl
^ permalink raw reply
* [PATCH] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-30 16:09 UTC (permalink / raw)
To: linuxppc-dev
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc-offset: 0x10d40, mdio-offset: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 0x10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..86b73ea 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include "fs_enet.h"
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang->dir, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dir, bitbang->mdio.msk);
else
- bb_clr(bitbang->dir, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dir, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dir);
+ in_be32(bitbang->mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang->dat, bitbang->mdio_msk);
+ return bb_read(bitbang->mdio.dat, bitbang->mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dat, bitbang->mdio.msk);
else
- bb_clr(bitbang->dat, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dat, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdc_msk);
+ bb_set(bitbang->mdc.dat, bitbang->mdc.msk);
else
- bb_clr(bitbang->dat, bitbang->mdc_msk);
+ bb_clr(bitbang->mdc.dat, bitbang->mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -114,23 +118,23 @@ static struct mdiobb_ops bb_ops = {
static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
struct device_node *np)
{
- struct resource res;
+ struct resource res[2];
const u32 *data;
int mdio_pin, mdc_pin, len;
struct bb_info *bitbang = bus->priv;
- int ret = of_address_to_resource(np, 0, &res);
+ int ret = of_address_to_resource(np, 0, &res[0]);
if (ret)
return ret;
- if (res.end - res.start < 13)
+ if (res[0].end - res[0].start < 13)
return -ENODEV;
/* This should really encode the pin number as well, but all
* we get is an int, and the odds of multiple bitbang mdio buses
* is low enough that it's not worth going too crazy.
*/
- bus->id = res.start;
+ bus->id = res[0].start;
data = of_get_property(np, "fsl,mdio-pin", &len);
if (!data || len != 4)
@@ -142,13 +146,27 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
return -ENODEV;
mdc_pin = *data;
- bitbang->dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang->dir)
+ bitbang->mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
+ if (!bitbang->mdc.dir)
return -ENOMEM;
- bitbang->dat = bitbang->dir + 4;
- bitbang->mdio_msk = 1 << (31 - mdio_pin);
- bitbang->mdc_msk = 1 << (31 - mdc_pin);
+ bitbang->mdc.dat = bitbang->mdc.dir + 4;
+ if( !of_address_to_resource(np, 1, &res[1]))
+ {
+ bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
+ if (!bitbang->mdio.dir)
+ {
+ iounmap(bitbang->mdc.dir);
+ return -ENOMEM;
+ }
+ bitbang->mdio.dat = bitbang->mdio.dir + 4;
+ }
+ else{
+ bitbang->mdio.dir = bitbang->mdc.dir;
+ bitbang->mdio.dat = bitbang->mdc.dat;
+ }
+ bitbang->mdio.msk = 1 << (31 - mdio_pin);
+ bitbang->mdc.msk = 1 << (31 - mdc_pin);
return 0;
}
@@ -220,7 +238,9 @@ out_free_irqs:
dev_set_drvdata(&ofdev->dev, NULL);
kfree(new_bus->irq);
out_unmap_regs:
- iounmap(bitbang->dir);
+ if ( bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
out_free_bus:
kfree(new_bus);
out_free_priv:
@@ -238,7 +258,9 @@ static int fs_enet_mdio_remove(struct of_device *ofdev)
free_mdio_bitbang(bus);
dev_set_drvdata(&ofdev->dev, NULL);
kfree(bus->irq);
- iounmap(bitbang->dir);
+ if ( bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
kfree(bitbang);
kfree(bus);
^ permalink raw reply related
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-30 16:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <jey7dlez74.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
>
>> Your mail from 2007-10-29 4:39 pm (CET)
>>
>>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>>> --with-cpu=default32 to make that the default).
>> See the 'still' ?
>
> How would the compiler know whether to generate 64bit or 32bit code??
Andreas, I think we both got a bit lost. Lets take a step back.
The original problem was that after 2.6.23 cross compiling
powerpc/g5_defconfig broke (Regression). Using gcc 4.0.4, powerpc64
target as cross compiler and powerpc target as 32-bit cross compiler.
Since 2.6.23-git1 it is now broken. Using gcc 4.1.2 didn't fix this. Neither
with "--with-cpu=default32" present nor without. So could you please
explain to me how I'm supposed to cross compile powerpc/g5_defconfig now?
Passing CFLAGS=-m32 didn't help too.
Or is it just a new bug in the kernel make system?
Just for reference up till 2.6.23 I used the following command:
make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- \
CROSS32_COMPILE=powerpc-linux-
Thanks,
Jan
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-30 16:18 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <jey7dlez74.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
>
>> Your mail from 2007-10-29 4:39 pm (CET)
>>
>>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>>> --with-cpu=default32 to make that the default).
>> See the 'still' ?
>
> How would the compiler know whether to generate 64bit or 32bit code??
... and it works again with .24-rc1-git6. So whatever the problem
was. Consider it resolved.
Jan
^ permalink raw reply
* Re: videobuf
From: Grant Likely @ 2007-10-30 16:19 UTC (permalink / raw)
To: Robert Woodworth; +Cc: linuxppc-embedded
In-Reply-To: <1193758138.4606.7.camel@PisteOff>
On 10/30/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> I'm working on building a v4l2 driver for an FPGA module on a Xilinx
> Virtex4 PPC.
>
> Question:
> Why does the v4l2 videobuf *depend* on PCI?
You could try dropping the dependency from Kconfig and see what breaks
when you compile the core v4l2 stuff.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-30 16:23 UTC (permalink / raw)
To: David Gibson, Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071030005146.GF29263@localhost.localdomain>
> Explicitly specifying what device class bindings / conventions the
> node complies with is cute, but not actually all that useful in
> practice. If it looks like a "duck" class device node, and it
> quacks^Whas the properties of a "duck" class device node, it's "duck"
> class compliant.
Don't know how cute it is, but I think it is practically=20
helpful. Take another example:
Say you-- a human reader-- see this in a device
tree:
...
interrupts =3D <b 8>;
interrupt-parent =3D < &mpic >;
...
What does the 'b' and '8' mean? You look
at the interrupt controller node--
mpic: pic@40000 {
clock-frequency =3D <0>;
interrupt-controller;
#address-cells =3D <0>;
#interrupt-cells =3D <2>;
reg =3D <40000 40000>;
compatible =3D "fsl,xyz";
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
device_type =3D "open-pic"; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.
Stuart
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Scott Wood @ 2007-10-30 16:33 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev, David Gibson
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F278B@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> mpic: pic@40000 {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <40000 40000>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
The binding for fsl,xyz.
-Scott
^ permalink raw reply
* Re: videobuf
From: Laurent Pinchart @ 2007-10-30 16:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1193758138.4606.7.camel@PisteOff>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Tuesday 30 October 2007 16:28, Robert Woodworth wrote:
> I'm working on building a v4l2 driver for an FPGA module on a Xilinx
> Virtex4 PPC.
>
> Question:
> Why does the v4l2 videobuf *depend* on PCI?
Historical reasons I guess. The videobuf module has been designed for PCI
hardware (bttv if I'm not mistaken). Now that other, non-PCI devices would
benefit from videobuf, PCI-specific support is being moved to a separate
module.
Search the video4linux mailing list archive for discussions about videobuf
cleanup. You can get the latest source tree at www.linuxtv.org.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Add device-tree aware NDFC driver
From: Jörn Engel @ 2007-10-30 15:33 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Thomas Gleixner, sr, linux-mtd
In-Reply-To: <47273BF4.80001@ru.mvista.com>
On Tue, 30 October 2007 17:13:08 +0300, Valentine Barshak wrote:
>
> I'm not saying my approach is the best, but I was hoping for a discussion.
That is good. So please take a moment to listen.
> I've reworked the patches according to the comments to the previous
> version and used my arguments to explain why I don't see much reason to
> mess with the code we currently have and added a separate _of version.
Ok.
> This is the last time I disturb you with my e-mail, so please, forget it.
Thomas words were harsh. Nothing unusual so far. Some people deserve
harsh words, some don't and some simply are doing a good job to invite
them. You mails so far were inviting harsh words.
So how did you invite harsh words and what can you change to prevent
this in the future?
1. Develop a thicker skin. No matter how well you do, there will always
be the occasional harsh words, deserved or not. It is ok to get angry
and call the person names - but do that at home and leave it out of your
responses. Ignore the flamebait, at least in public.
2. Follow local customs. In particular you should follow the style of
discussion commonly used in mailing lists:
>>> I'm doing this.
>> Crap! Never do that!
> Why not? Can you explain?
Because...
>>> Then I do that.
>> Wouldn't ABCD be better?
> ABCD wouldn't work for me because of XYZ.
Fair enough.
Respond to individual comments _directly_following_the_comment_ do not
collect comments from 10 mails, then respond to them all in a long
paragraph. Noone will read that. I didn't read it either.
3. Be concise. When quoting someone, remove everything but the relevant
bits. Respond only with relevant information. People regularly read
10+ mailing lists. Their attention span is short. If you manage to
annoy them with irrelevant information in the first 10 lines, they will
skip any amount of wisdom below.
4. Be polite. Even if the responses you get are not. Flamewars get you
nowhere.
5. Have sound technical arguments. "mtd concat adds a slight overhead"
is not for two reasons. First, it is lacking numbers. People's guesses
about perceived overhead or usually wrong, so knowledgeable readers will
immediately question such arguments. Secondly, you didn't explain _why_
mtdconcat adds overhead. In particular, why didn't you reduce the
mtdconcat overhead instead of essentially copying its functionality?
6. Be structured. Empty lines are cheap. Use them. Add structure to
your mails. Above you can see several paragraphs. You can quickly go
back to a previous one. You can skip one after reading just the first
sentence. After several attempts I still haven't read your 46-line
monologue. I don't even know how far I made it because it is so damn
hard to find the spot again.
If you are willing to change the style of your mails, maybe people will
actually read them and respond to you in ways you expected. Otherwise
it may indeed be a wise choice not to come back. Some people simply
just don't get along. Sometimes a proxy is needed to translate between
people. But my hope is that you are willing and able to work with us
directly.
Jörn
--
There is no worse hell than that provided by the regrets
for wasted opportunities.
-- Andre-Louis Moreau in Scarabouche
^ permalink raw reply
* [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Valentine Barshak @ 2007-10-30 16:45 UTC (permalink / raw)
To: linuxppc-dev
The following patches add PowerPC 440GRx Rainier board support.
The board is almost identical to Sequoia, but doesn't have USB
and FPU is not supported.
Thanks,
Valentine.
^ permalink raw reply
* [PATCH 1/4] PowerPC: 440GRx Rainier bootwrapper.
From: Valentine Barshak @ 2007-10-30 16:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
Bootwrapper code for PowerPC 440GRx Rainier board.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/Makefile | 3 +
arch/powerpc/boot/cuboot-rainier.c | 56 +++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 1 deletion(-)
diff -pruN linux-2.6.orig/arch/powerpc/boot/cuboot-rainier.c linux-2.6/arch/powerpc/boot/cuboot-rainier.c
--- linux-2.6.orig/arch/powerpc/boot/cuboot-rainier.c 1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/arch/powerpc/boot/cuboot-rainier.c 2007-10-30 18:00:15.000000000 +0300
@@ -0,0 +1,56 @@
+/*
+ * Old U-boot compatibility for Rainier
+ *
+ * Valentine Barshak <vbarshak@ru.mvista.com>
+ * Copyright 2007 MontaVista Software, Inc
+ *
+ * Based on Ebony code by David Gibson <david@gibson.dropbear.id.au>
+ * Copyright IBM Corporation, 2007
+ *
+ * Based on Bamboo code by Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright IBM Corporation, 2007
+ *
+ * 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; version 2 of the License
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+
+static void rainier_fixups(void)
+{
+ unsigned long sysclk = 33333333;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200);
+ ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
+ ibm4xx_denali_fixup_memsize();
+ dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = rainier_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ ft_init(_dtb_start, 0, 32);
+ serial_console_init();
+}
diff -pruN linux-2.6.orig/arch/powerpc/boot/Makefile linux-2.6/arch/powerpc/boot/Makefile
--- linux-2.6.orig/arch/powerpc/boot/Makefile 2007-10-30 17:44:27.000000000 +0300
+++ linux-2.6/arch/powerpc/boot/Makefile 2007-10-30 18:00:15.000000000 +0300
@@ -56,7 +56,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c
+ fixed-head.S ep88xc.c cuboot-hpc2.c cuboot-rainier.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -158,6 +158,7 @@ image-$(CONFIG_MPC7448HPC2) += cuImage.
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
+image-$(CONFIG_RAINIER) += cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
endif
^ permalink raw reply
* [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Valentine Barshak @ 2007-10-30 16:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
PowerPC 440GRx Rainier DTS.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/dts/rainier.dts | 312 ++++++++++++++++++++++++++++++++++++++
1 files changed, 312 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts linux-2.6/arch/powerpc/boot/dts/rainier.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts 1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/arch/powerpc/boot/dts/rainier.dts 2007-10-30 18:00:15.000000000 +0300
@@ -0,0 +1,312 @@
+/*
+ * Device Tree Source for AMCC Rainier
+ *
+ * Based on Sequoia code
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ *
+ * FIXME: Draft only!
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,rainier";
+ compatible = "amcc,rainier";
+ dcr-parent = <&/cpus/PowerPC,440GRx@0>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,440GRx@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ 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 zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440grx","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-440grx","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-440grx","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440grx", "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440grx", "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440grx", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ device_type = "memory-controller";
+ compatible = "ibm,sdram-440grx", "ibm,sdram-44x-ddr2denali";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440grx", "ibm,dma-4xx";
+ dcr-reg = <100 027>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-440grx", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-440grx", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <00000000 1 00000000 80000000
+ 80000000 1 80000000 80000000>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <7 4>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-440grx", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ interrupts = <5 1>;
+ 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 180000>;
+ };
+ partition@180000 {
+ label = "ramdisk";
+ reg = <180000 200000>;
+ };
+ partition@380000 {
+ label = "file system";
+ reg = <380000 3aa0000>;
+ };
+ partition@3e20000 {
+ label = "kozio";
+ reg = <3e20000 140000>;
+ };
+ 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 zImage */
+ current-speed = <1c200>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <3 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <4 4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ device_type = "i2c";
+ compatible = "ibm,iic-440grx", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ device_type = "i2c";
+ compatible = "ibm,iic-440grx", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ device_type = "zmii-interface";
+ compatible = "ibm,zmii-440grx", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601000 {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-440grx", "ibm,rgmii";
+ reg = <ef601000 8>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-440grx", "ibm,emac-440epx", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <0>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-440grx", "ibm,emac-440epx", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 19 4
+ /*Wake*/ 1 &UIC1 1f 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <1>;
+ cell-index = <1>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <1>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ };
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/plb/opb/serial@ef600300";
+ bootargs = "console=ttyS0,115200";
+ };
+};
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-30 16:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030163200.GA4470@loki.buserror.net>
Hello Scott.
Thank you for reply.
Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood:
> On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote:
> You could just use of_iomap() for the second one, since we don't need
> the physical address for bus->id.
Nice tip.
Than it would be needless-------
|
\/
> > + iounmap(bitbang->mdc.dir);
> > + return -ENOMEM;
>
> Please use the goto-style error handling that's used elsewhere in the
> function.
Regards
Sergej.
^ permalink raw reply
* [PATCH 3/4] PowerPC: 440GRx Rainier board support.
From: Valentine Barshak @ 2007-10-30 16:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
PowerPC 440GRx Rainier board support.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/platforms/44x/Kconfig | 16 ++++++++-
arch/powerpc/platforms/44x/Makefile | 3 +
arch/powerpc/platforms/44x/rainier.c | 61 +++++++++++++++++++++++++++++++++++
3 files changed, 78 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig linux-2.6/arch/powerpc/platforms/44x/Kconfig
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig 2007-10-30 17:44:42.000000000 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig 2007-10-30 18:04:28.000000000 +0300
@@ -22,6 +22,14 @@ config SEQUOIA
help
This option enables support for the AMCC PPC440EPX evaluation board.
+config RAINIER
+ bool "Rainier"
+ depends on 44x
+ default n
+ select 440GRX
+ help
+ This option enables support for the AMCC PPC440GRX evaluation board.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -52,6 +60,12 @@ config 440EPX
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII
+config 440GRX
+ bool
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
+
config 440GP
bool
select IBM_NEW_EMAC_ZMII
@@ -64,7 +78,7 @@ config 440SP
config 440A
bool
- depends on 440GX || 440EPX
+ depends on 440GX || 440EPX || 440GRX
default y
# 44x errata/workaround config symbols, selected by the CPU models above
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/Makefile linux-2.6/arch/powerpc/platforms/44x/Makefile
--- linux-2.6.orig/arch/powerpc/platforms/44x/Makefile 2007-10-30 17:44:42.000000000 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/Makefile 2007-10-30 18:00:15.000000000 +0300
@@ -1,4 +1,5 @@
obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_EBONY) += ebony.o
-obj-$(CONFIG_BAMBOO) += bamboo.o
+obj-$(CONFIG_BAMBOO) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
+obj-$(CONFIG_RAINIER) += rainier.o
diff -pruN linux-2.6.orig/arch/powerpc/platforms/44x/rainier.c linux-2.6/arch/powerpc/platforms/44x/rainier.c
--- linux-2.6.orig/arch/powerpc/platforms/44x/rainier.c 1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30 18:00:15.000000000 +0300
@@ -0,0 +1,61 @@
+/*
+ * Rainier board specific routines
+ *
+ * Valentine Barshak <vbarshak@ru.mvista.com>
+ * Copyright 2007 MontaVista Software Inc.
+ *
+ * Based on the Bamboo code by
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright 2007 IBM Corporation
+ *
+ * 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.
+ */
+#include <linux/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/of_platform.h>
+#include "44x.h"
+
+static struct of_device_id rainier_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init rainier_device_probe(void)
+{
+ if (!machine_is(rainier))
+ return 0;
+
+ of_platform_bus_probe(NULL, rainier_of_bus, NULL);
+
+ return 0;
+}
+device_initcall(rainier_device_probe);
+
+static int __init rainier_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,rainier"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(rainier) {
+ .name = "Rainier",
+ .probe = rainier_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
^ permalink raw reply
* [PATCH 4/4] PowerPC: 440GRx Rainier default config
From: Valentine Barshak @ 2007-10-30 17:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
PowerPC 440GRx Rainier default config.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/configs/rainier_defconfig | 868 +++++++++++++++++++++++++++++++++
1 files changed, 868 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/configs/rainier_defconfig linux-2.6/arch/powerpc/configs/rainier_defconfig
--- linux-2.6.orig/arch/powerpc/configs/rainier_defconfig 1970-01-01 03:00:00.000000000 +0300
+++ linux-2.6/arch/powerpc/configs/rainier_defconfig 2007-10-30 18:19:59.000000000 +0300
@@ -0,0 +1,868 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.24-rc1
+# Tue Oct 30 18:19:49 2007
+#
+# 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_IRQ_PER_CPU=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_USER_NS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CGROUPS is not set
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
+# CONFIG_FAIR_CGROUP_SCHED is not set
+CONFIG_SYSFS_DEPRECATED=y
+# CONFIG_RELAY 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_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_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=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_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+CONFIG_MODULES=y
+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"
+
+#
+# Platform support
+#
+# CONFIG_PPC_MPC52xx is not set
+# CONFIG_PPC_MPC5200 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_RAINIER=y
+CONFIG_440GRX=y
+CONFIG_440A=y
+# 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_CPM2 is not set
+# CONFIG_FSL_ULI1575 is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+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_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=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=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_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
+CONFIG_VIRT_TO_BUS=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE=""
+CONFIG_SECCOMP=y
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE="rainier.dts"
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+CONFIG_PPC_INDIRECT_PCI=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_DEBUG is not set
+# CONFIG_PCCARD is not set
+# CONFIG_HOTPLUG_PCI is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0xc0000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x01000000
+
+#
+# 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_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL 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_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=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+# CONFIG_MTD_BLKDEVS is not set
+# CONFIG_MTD_BLOCK is not set
+# CONFIG_MTD_BLOCK_RO is not set
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI 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_RAM_BLOCKSIZE=1024
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+# CONFIG_XILINX_SYSACE is not set
+CONFIG_MISC_DEVICES=y
+# CONFIG_PHANTOM is not set
+# CONFIG_EEPROM_93CX6 is not set
+# CONFIG_SGI_IOC4 is not set
+# CONFIG_TIFM_CORE is not set
+# 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=y
+# CONFIG_MAC_EMUMOUSEBTN is not set
+# CONFIG_WINDFARM 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_IP1000 is not set
+# CONFIG_ARCNET is not set
+# CONFIG_NET_ETHERNET is not set
+CONFIG_IBM_NEW_EMAC_ZMII=y
+CONFIG_IBM_NEW_EMAC_RGMII=y
+CONFIG_IBM_NEW_EMAC_EMAC4=y
+CONFIG_NETDEV_1000=y
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+# CONFIG_E1000 is not set
+# CONFIG_E1000E is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SIS190 is not set
+# CONFIG_SKGE is not set
+# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_VIA_VELOCITY is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
+# CONFIG_QLA3XXX is not set
+# CONFIG_ATL1 is not set
+CONFIG_NETDEV_10000=y
+# CONFIG_CHELSIO_T1 is not set
+# CONFIG_CHELSIO_T3 is not set
+# CONFIG_IXGBE is not set
+# CONFIG_IXGB is not set
+# CONFIG_S2IO is not set
+# CONFIG_MYRI10GE is not set
+# CONFIG_NETXEN_NIC is not set
+# CONFIG_NIU is not set
+# CONFIG_MLX4_CORE is not set
+# CONFIG_TEHUTI is not set
+# CONFIG_TR is not set
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 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_SHAPER 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_SERIAL_NONSTANDARD 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
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
+# CONFIG_HWMON 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
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+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=y
+CONFIG_USB_ARCH_HAS_HCD=y
+CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB_ARCH_HAS_EHCI=y
+# CONFIG_USB is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+# CONFIG_MMC is not set
+# CONFIG_NEW_LEDS is not set
+# CONFIG_INFINIBAND is not set
+# CONFIG_EDAC is not set
+# CONFIG_RTC_CLASS is not set
+
+#
+# Userspace I/O
+#
+# 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_GFS2_FS is not set
+# CONFIG_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# 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_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+# CONFIG_JFFS2_LZO is not set
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_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_NFS_DIRECTIO 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
+# CONFIG_UCC_SLOW is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# 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_ZLIB_DEFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+CONFIG_INSTRUMENTATION=y
+# CONFIG_PROFILING is not set
+# CONFIG_KPROBES is not set
+# CONFIG_MARKERS is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_FS is not set
+# 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_SLUB_DEBUG_ON 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_LIST is not set
+# CONFIG_DEBUG_SG is not set
+CONFIG_FORCED_INLINING=y
+# CONFIG_BOOT_PRINTK_DELAY is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_SAMPLES 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_KGDB is not set
+# CONFIG_XMON is not set
+# CONFIG_BDI_SWITCH is not set
+CONFIG_PPC_EARLY_DEBUG=y
+# CONFIG_PPC_EARLY_DEBUG_LPAR is not set
+# CONFIG_PPC_EARLY_DEBUG_G5 is not set
+# CONFIG_PPC_EARLY_DEBUG_RTAS_PANEL is not set
+# CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE is not set
+# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set
+# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set
+# CONFIG_PPC_EARLY_DEBUG_PAS_REALMODE is not set
+# CONFIG_PPC_EARLY_DEBUG_BEAT is not set
+CONFIG_PPC_EARLY_DEBUG_44x=y
+# CONFIG_PPC_EARLY_DEBUG_CPM is not set
+CONFIG_PPC_EARLY_DEBUG_44x_PHYSLOW=0xef600300
+CONFIG_PPC_EARLY_DEBUG_44x_PHYSHIGH=0x1
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_BLKCIPHER=y
+CONFIG_CRYPTO_MANAGER=y
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+CONFIG_CRYPTO_MD5=y
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=y
+# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_XTS is not set
+# CONFIG_CRYPTO_CRYPTD is not set
+CONFIG_CRYPTO_DES=y
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_SEED is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_TEST is not set
+# CONFIG_CRYPTO_AUTHENC is not set
+CONFIG_CRYPTO_HW=y
+# CONFIG_PPC_CLOCK is not set
^ permalink raw reply
* Re: videobuf
From: Robert Woodworth @ 2007-10-30 17:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40710300919y4f231eb4w4ba4bc0c8d9260ff@mail.gmail.com>
That does work and nothing seams to be broken just yet.
I also removed the dependency from the vivi (virtual video) module and
that modules works fine.
However, I tried to enable PCI support and that failed with undefined
PCI addresses. (duh. I have no PCI on the board)
RJW.
On Tue, 2007-10-30 at 10:19 -0600, Grant Likely wrote:
> On 10/30/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > I'm working on building a v4l2 driver for an FPGA module on a Xilinx
> > Virtex4 PPC.
> >
> > Question:
> > Why does the v4l2 videobuf *depend* on PCI?
>
> You could try dropping the dependency from Kconfig and see what breaks
> when you compile the core v4l2 stuff.
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports
From: Scott Wood @ 2007-10-30 17:16 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1193763517.6244.33.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
> Hello Scott.
> Thank you for reply.
> Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood:
>> On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote:
>
>> You could just use of_iomap() for the second one, since we don't need
>> the physical address for bus->id.
> Nice tip.
> Than it would be needless-------
> |
> \/
>>> + iounmap(bitbang->mdc.dir);
>>> + return -ENOMEM;
>> Please use the goto-style error handling that's used elsewhere in the
>> function.
Hmm... in this case, it'd be impossible to tell using of_iomap() whether
a failure was due to reg only having one resource (and thus meaning the
same one should be used for both), or due to ioremap() failure. Maybe
we should keep it separate.
-Scott
^ permalink raw reply
* Re: libfdt as its own repo and submodule of dtc?
From: Jerry Van Baren @ 2007-10-30 17:14 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linux-ppc list, David Gibson
In-Reply-To: <E1ImtSB-0003vC-0j@jdl.com>
Jon Loeliger wrote:
> So, like, the other day Kumar Gala mumbled:
>> Jon,
>>
>> It seems like have libfdt as a unique git repo that is a submodule of
>> the things that need it (dtc, u-boot, etc.) might make some sense and
>> it easier for the projects that need to pull it in.
>>
>> Is this something you can take a look at? (or have other ideas on).
>
> I would be fine with making libfdt a git repository separate
> from the DTC repository if that makes it easier to integrate
> it with other projects.
>
> jdl
That sounds like a good idea to me. I would really prefer pulling
patches out of a libfdt repo into the u-boot repo rather than trying to
kerchunk upgrade lumps. While we can do this with a dtc repo, it
potentially makes it a lot more difficult.
gvb
^ permalink raw reply
* Gianfar skb panic when bonding a VLAN interface
From: Demke Torsten-atd012 @ 2007-10-30 17:28 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I tried to ping over a bonded VLAN tagged interface.
(e.g -> ifenslave bond0 eth3.24)
This fails with following output:
root@myBoard:/root> ping 192.168.24.101
PING 192.168.24.skb_under_panic: text:c01bbdf8 len:50 put:8
head:dd27a3a0 data:dd27a39a tail:dd27a3cc end:dd27a3e0 dev:eth3
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C01E9110 LR: C01E9110 SP: C03479F0 REGS: c0347940 TRAP: 0700
Tainted: PF =20
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK =3D c03031a0[0] 'swapper' THREAD: c0346000
Last syscall: 120=20
GPR00: C01E9110 C03479F0 C03031A0 00000072 00002D03 FFFFFFFF 00000030
00003FFF=20
GPR08: C037D0AC C0340000 FFFFFFFF 00000000 65F51C00 60000000 0FFE3900
C0347A7C=20
GPR16: DFC1FD60 C0347DD0 C0B94800 0FFF3D0C C0347A80 00000000 007FD890
00000000=20
GPR24: 00000000 C0A81865 C0A81805 00000000 C0B94800 DFC1FD60 C0B94A40
DF10C128=20
NIP [c01e9110] skb_under_panic+0x50/0x64
LR [c01e9110] skb_under_panic+0x50/0x64
Call trace:
[c01bbe0c] gfar_add_fcb+0x7c/0xb4
[c01bbfc0] gfar_start_xmit+0x160/0x268
[c01ffffc] qdisc_restart+0x100/0x1fc
[c01f04c4] dev_queue_xmit+0xc88/0xde0
[c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0
[c01f054c] dev_queue_xmit+0xd10/0xde0
[c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4
[c01b4464] bond_xmit_roundrobin+0x94/0x108
[c01f054c] dev_queue_xmit+0xd10/0xde0
[c022f6cc] arp_xmit+0x5c/0x6c
[c022f704] arp_send+0x28/0x38
[c022ef48] arp_solicit+0x1a0/0x1c0
[c01f81b0] neigh_timer_handler+0x294/0x31c
[c0043310] run_timer_softirq+0xa7c/0xaec
[c0039b68] __do_softirq+0xabc/0x15a0
101 (192.168.24.Kernel panic - not syncing: Aiee, killing interrupt
handler!
101) 56(84) byte s of data.
Call trace:
[c0008258] dump_stack+0x18/0x28
[c002fa50] panic+0xa8/0x190
[c0033690] do_exit+0x3c/0xdec
[c0002fb4] _exception+0x0/0x1558
[c0002ff0] _exception+0x3c/0x1558
[c0004d70] ProgramCheckException+0x11c/0x1c4
[c00029ac] ret_from_except_full+0x0/0x4c
[c01e9110] skb_under_panic+0x50/0x64
[c01bbe0c] gfar_add_fcb+0x7c/0xb4
[c01bbfc0] gfar_start_xmit+0x160/0x268
[c01ffffc] qdisc_restart+0x100/0x1fc
[c01f04c4] dev_queue_xmit+0xc88/0xde0
[c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0
[c01f054c] dev_queue_xmit+0xd10/0xde0
[c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4
Rebooting in 180 seconds..
It seems that the skb headroom is to small. How can I solve this?
I could insert skb_realloc_headroom() call, but where it's the best
place then?
What about alignement?
Regards,
Torsten
^ 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