* Re: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-12 21:56 UTC (permalink / raw)
To: Mark Brown
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <20090812214444.GA4731@sirena.org.uk>
On Wed, 2009-08-12 at 22:44 +0100, Mark Brown wrote:
> On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
>
> > > What happens if another clock gets added or the list gets reordered for
> > > some reason?
>
> > The device-tree is mostly static in that regard. I'm not sure what you
> > mean. Clocks are referenced by IDs so if you want to add more clocks you
> > can just add them to the end. The "NULL" case is typically for things
> > that have only one clock (which seems to be reasonably common in ARM
> > land).
>
> The issue I'm worrying about here is what happens if the device has only
> one clock in current revisions of the hardware but another revision of
> the same hardware is produced which adds another clock. When that
> happens your NULL lookup gets confused.
Well, then don't use clk_get() with NULL :-) I mean, ARM devices do that
today (ie, calling with NULL), it makes sense in the context of a
device-tree binding to provide a defined behaviour for it (pick the
first clock in the order it appears in the device-tree is one way to do
it), but we can also recommend to driver writers not to do it :-)
But if one was to use an existing driver that does it, then we need to
cater for it.
Note that adding a new clock in the future isn't a big deal. As long as
the first one in the list is the one the driver that calls clk_get with
NULL expects to obtain.
Maybe we can make clock-names non-optional though in the DT as an
incentive not to use the simple 1-clock "NULL" path.
> > I think it's reasonable to ask whoever produces the device-tree to keep
> > the two properties in sync.
>
> It's not just the device tree, it's also the drivers which have to be
> able to cope with whatever random device tree that's thrown at them.
Well, the clocks are named. At some stage, the binding for a given
device will define what clock names it expects. I don't see that
differing from what the ARM folks do.
> This is less of a problem on ARM where it's fairly straightforward to
> adjust the users at the same time as the driver but if you've got a
> device tree delivered via a completely different distribution mechanism
> it gets more sticky.
Possibly yes, and that's a reason why we tend to discourage that ;-) But
again, it boils down to settling with a naming convention for a given
device. If clocks are added later on, the driver will have to cope with
the new clocks not existing, of course, or the platform can cater for
it.
That's also one of the reason why I want to make clk_get() go through
ppc_md. first, so that the platform can always override the behaviour,
and for example, fill-in in case the device-tree is incomplete or
incorrect.
> The problem with the API at the minute in this regard is that there is
> no standard way of registering new clocks. Only something that knows
> about the magic sauce for a given architecture (if any) is able to add
> clocks. My concern here is that if PowerPC moves in this direction
> without some general agreement from elsewhere then there may be problems
> for drivers.
Well, the idea is to allow to register clock-providers associated with
device nodes. I think we should keep the rest in the hand of platforms
for now, and possibly make it evolve later.
Do you have maybe a precise example scenario where your above statement
about the lack of facility for registering new clocks is a problem ? I'm
curious to see a real life example so I can think better about how it
can be solved (or whether it needs to be solved).
Cheers,
Ben.
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Mark Brown @ 2009-08-12 21:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <1250112847.3587.26.camel@pasglop>
On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
> > What happens if another clock gets added or the list gets reordered for
> > some reason?
> The device-tree is mostly static in that regard. I'm not sure what you
> mean. Clocks are referenced by IDs so if you want to add more clocks you
> can just add them to the end. The "NULL" case is typically for things
> that have only one clock (which seems to be reasonably common in ARM
> land).
The issue I'm worrying about here is what happens if the device has only
one clock in current revisions of the hardware but another revision of
the same hardware is produced which adds another clock. When that
happens your NULL lookup gets confused.
> I think it's reasonable to ask whoever produces the device-tree to keep
> the two properties in sync.
It's not just the device tree, it's also the drivers which have to be
able to cope with whatever random device tree that's thrown at them.
This is less of a problem on ARM where it's fairly straightforward to
adjust the users at the same time as the driver but if you've got a
device tree delivered via a completely different distribution mechanism
it gets more sticky.
> > Note that the present ARM implementations don't handle anything except
> > the core SoC normally.
> Ok, interesting. I don't see why the API would prevent going further
> tho. In any case, that isn't a big deal, at least until somebody proves
> me wrong, I believe what I proposed remains simple enough and leaves
> enough to the actual implementations to allow pretty much anything in
> that area.
The problem with the API at the minute in this regard is that there is
no standard way of registering new clocks. Only something that knows
about the magic sauce for a given architecture (if any) is able to add
clocks. My concern here is that if PowerPC moves in this direction
without some general agreement from elsewhere then there may be problems
for drivers.
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-12 21:34 UTC (permalink / raw)
To: Mark Brown
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <20090812123551.GC11227@sirena.org.uk>
On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
> On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
>
> > - From the above, question: Do we want to keep that parent pointer ?
> > Does it make sense ? Will we have objects that are clock providers and
> > themselves source from multiple parent ? Or we don't care and it becomes
>
> That happens and at times one or more of the sources is off-chip.
Right. That's somewhat what I thought. I think the best approach
initially is not to impose a hierarchy in our "core" and keep that to
the actual clock provider implementation. We'll see in the long term
with practice whether we then want to move some of that back into core.
> What happens if another clock gets added or the list gets reordered for
> some reason?
The device-tree is mostly static in that regard. I'm not sure what you
mean. Clocks are referenced by IDs so if you want to add more clocks you
can just add them to the end. The "NULL" case is typically for things
that have only one clock (which seems to be reasonably common in ARM
land).
I think it's reasonable to ask whoever produces the device-tree to keep
the two properties in sync.
> Note that the present ARM implementations don't handle anything except
> the core SoC normally.
Ok, interesting. I don't see why the API would prevent going further
tho. In any case, that isn't a big deal, at least until somebody proves
me wrong, I believe what I proposed remains simple enough and leaves
enough to the actual implementations to allow pretty much anything in
that area.
Cheers,
Ben.
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-12 21:30 UTC (permalink / raw)
To: Mitch Bradley
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <4A82FC63.7020705@firmworks.com>
On Wed, 2009-08-12 at 07:31 -1000, Mitch Bradley wrote:
> Padding a string violates a core principle of property representation,
> namely the "no alignment assumptions" one. The reason for that
> principle was the fact that alignment needs are not stable across
> processor families, or even within a processor family .
Right, which is why I replied to myself with a different idea :-)
> This approach finesses the problem nicely.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Benjamin Herrenschmidt @ 2009-08-12 21:29 UTC (permalink / raw)
To: Kumar Gala
Cc: devicetree-discuss, John Jacques, linuxppc-dev list, Torez Smith,
Russell King
In-Reply-To: <4A90486C-8BF5-428C-9FD8-830D822C0D40@kernel.crashing.org>
On Wed, 2009-08-12 at 08:40 -0500, Kumar Gala wrote:
> I'm in the same boat as you Josh. I think there is value and utility
> here but not sure what problem Ben's trying to solve.
Well, there's several things here.
First, it would be nice to improve clock management on some existing
SoCs. I'm not going to rewrite the powermac clock handling though :-)
But it might allow to cleanup some hacks we have there or add dynamic
clock handling in areas where we could improve power consumption etc...
by doing it but aren't today. Not critical but it's nice to have the
base layout there.
Don't you have parts where you'd like some more dynamic clock
management ? This API is a reasonably simple and nice way to get there.
Now, I know there is at least one person on earth contemplating sharing
some drivers between PPC and ARM. I won't tell much more at this stage,
but it makes sense in the grand scheme of things to see SoC vendors put
similar IO cores into either PPC or ARM and providing that clock API is
a good way to also allow these drivers to work since the drivers in
questions make use of it.
Also, note that the clk API is in include/linux/clk.h, ie, it's not
really ARM specific anymore in that sense, it's also very simple (it
leaves a lot to the implementation which is good) and thus my proposal
resolves in very little support code for us (mostly the clk_get()
implementation that hooks into ppc_md, the wrappers to call the
"methods" of struct clk, and the helper to parse the OF bits).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
From: Michael Barkowski @ 2009-08-12 20:58 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, Andrew Morton, David Woodhouse
In-Reply-To: <20090812205800.GA27074@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
>> Hello Anton,
>>
>> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>>
>> Then shouldn't you have the following change as well, near the end of
>> the function?
>>
>> - } else if (data->nr_parts)
>> + } else if (data && data->nr_parts)
>> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
>> data->nr_parts, data->name);
>>
>> Or am I misunderstanding something?
>
> Yeah, you missed this patch:
> http://patchwork.kernel.org/patch/38179/
>
>
> Thanks,
>
Beautiful - thanks - sorry to interrupt
--
Michael Barkowski
905-482-4577
^ permalink raw reply
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
From: Anton Vorontsov @ 2009-08-12 20:58 UTC (permalink / raw)
To: Michael Barkowski
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, Andrew Morton, David Woodhouse
In-Reply-To: <4A832A03.6020507@ruggedcom.com>
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
> Hello Anton,
>
> Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
>
> Then shouldn't you have the following change as well, near the end of
> the function?
>
> - } else if (data->nr_parts)
> + } else if (data && data->nr_parts)
> dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
> data->nr_parts, data->name);
>
> Or am I misunderstanding something?
Yeah, you missed this patch:
http://patchwork.kernel.org/patch/38179/
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/6] mtd: m25p80: Convert to device table matching
From: Michael Barkowski @ 2009-08-12 20:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, linux-mtd, linux-kernel, lm-sensors
In-Reply-To: <20090731004100.GB8371@oksana.dev.rtsoft.ru>
Hello Anton,
Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
- } else if (data->nr_parts)
+ } else if (data && data->nr_parts)
dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
data->nr_parts, data->name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Dipankar Sarma @ 2009-08-12 19:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar,
linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <20090812115806.GK24339@elf.ucw.cz>
On Wed, Aug 12, 2009 at 01:58:06PM +0200, Pavel Machek wrote:
> Hi!
>
> > May be having (to pick a number) 3 possible offline states for all
> > platforms with one for halt equivalent and one for deepest possible that
> > CPU can handle and one for deepest possible that platform likes for
> > C-states may make sense. Will keeps things simpler in terms of usage
> > expectations and possibly reduce the misuse oppurtubity?
>
> Maybe just going to the deepest offline state automatically is the
> easiest option?
In a native system, I think we should the platform-specific code
export what makes sense. That may be just the lowest possible
state only. Or may be more than one.
In a virtualized system, we would want to do at least the following -
1. An offline configuration state where the hypervisor can
take the cpu back and allocate it to another VM.
2. A low-power state where the guest indicates it doesn't need the
CPU (and can be put in low power state) but doesn't want to give up
its allocated cpu share. IOW, no visible configuration changes.
So, in any case we would probably want more than one states.
> cpu hotplug/unplug should be rare-enough operation that the latencies
> do not really matter, right?
As of now, from the platform perspective, I don't think low-power
state latencies matter in this code path. The only thing that might
have any relevance is electrical power-off technology and whether
there may be any h/w specific issues restricting its use. I don't know
that there will be any, but it may not be a good idea to prevent
platforms from requiring the use of multiple "offline" states.
Thanks
Dipankar
^ permalink raw reply
* Re: [PATCH] usb/gadget: Update Freescale UDC entry in MAINTAINERS
From: Guennadi Liakhovetski @ 2009-08-12 19:40 UTC (permalink / raw)
To: Li Yang; +Cc: joe, linuxppc-dev, gregkh, linux-usb
In-Reply-To: <1249960271-3400-1-git-send-email-leoli@freescale.com>
On Tue, 11 Aug 2009, Li Yang wrote:
> Change the F entry for file rename, and make it also cover fsl_qe_udc
> driver. Update the name accordingly.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> Liakhovetski,
>
> Is it ok that it also covers your fsl_mx3_udc.c file. It's much easier
> to use the wildcard.
Sure, no problem, if you like
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> MAINTAINERS | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b1114cf..cf1e22c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2067,12 +2067,12 @@ S: Supported
> F: arch/powerpc/sysdev/qe_lib/
> F: arch/powerpc/include/asm/*qe.h
>
> -FREESCALE HIGHSPEED USB DEVICE DRIVER
> +FREESCALE USB PERIPHERIAL DRIVERS
> M: Li Yang <leoli@freescale.com>
> L: linux-usb@vger.kernel.org
> L: linuxppc-dev@ozlabs.org
> S: Maintained
> -F: drivers/usb/gadget/fsl_usb2_udc.c
> +F: drivers/usb/gadget/fsl*
>
> FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
> M: Li Yang <leoli@freescale.com>
> --
> 1.6.3.1.6.g4bf1f
>
>
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* The infamous ppc_spurious_interrupt
From: Leonardo Chiquitto @ 2009-08-12 19:40 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm trying to understand the rationale behind "ppc_spurious_interrupts" without
luck so far. I'm seeing the BAD interrupt counter incrementing with kernels of
different ages (2.6.5, 2.6.16, 2.6.27) and on different hardware (IBM P5 and P6
64 bit, Apple PPC 32 bit). Here is the code snip that performs the increment:
void do_IRQ(struct pt_regs *regs)
{
(...)
irq = ppc_md.get_irq();
if (irq != NO_IRQ && irq != NO_IRQ_IGNORE)
handle_one_irq(irq);
else if (irq != NO_IRQ_IGNORE)
/* That's not SMP safe ... but who cares ? */
ppc_spurious_interrupts++;
(...)
}
I see that the counter is incremented only when ppc_md.get_irq() returns NO_IRQ.
This seems to happen with some frequency here (32 million "bad" interrupts in
~16 days of uptime, or ~23 int/sec).
I did some research in the archives and found some references, like this comment
from Rob Baxter (http://marc.info/?l=linuxppc-dev&m=119579052741562&w=2):
> A good example is an interrupt request from a PCI bus device. Many device
> driver interrupt handlers will clear the source of the interrupt by either
> reading or writing some register within the device, perform some necessary
> actions, and return from the handler. The PCI device is slow to negate its
> interrupt request and the interrupt controller sees the interrupt request
> from the device again. With the platforms that I'm associated with I've
> seen this happen more frequently (i.e., BAD interrupts) as processor
> internal core frequencies increase, especially with the 7457.
Is this correct? Why we see this behavior only on PPC and not on all
architectures
that support the PCI bus?
If the "bad interrupts" are harmless (I suppose they are), why are we counting
them and displaying the counter as BAD in /proc/interrupts?
Best regards,
Leonardo
^ permalink raw reply
* [PATCH] fix book E watchdog to take WDIOC_SETTIMEOUT arg in seconds
From: Chris Friesen @ 2009-08-12 18:02 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala, wim, Linux kernel
The WDIOC_SETTIMEOUT argument is supposed to be a "seconds" value.
However, the book E wdt currently treats it as a "period" which is
interpreted in a board-specific way.
This patch allows the user to pass in a "seconds" value and the driver
will set the smallest timeout that is at least as large as specified
by the user. It's been tested on e500 hardware and works as
expected.
The patch only modifies the CONFIG_FSL_BOOKE case, the CONFIG_4xx case
is left unmodified as I don't have any hardware to test it on.
Signed-off-by: Chris Friesen <cfriesen@nortel.com>
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 225398f..f1a3617 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -22,6 +22,8 @@
#include <asm/reg_booke.h>
#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/div64.h>
/* If the kernel parameter wdt=1, the watchdog will be enabled at boot.
* Also, the wdt_period sets the watchdog timer period timeout.
@@ -32,7 +34,7 @@
*/
#ifdef CONFIG_FSL_BOOKE
-#define WDT_PERIOD_DEFAULT 63 /* Ex. wdt_period=28 bus=333Mhz,reset=~40sec */
+#define WDT_PERIOD_DEFAULT 38 /* Ex. wdt_period=28 bus=333Mhz,reset=~40sec */
#else
#define WDT_PERIOD_DEFAULT 3 /* Refer to the PPC40x and PPC4xx manuals */
#endif /* for timing information */
@@ -41,7 +43,7 @@ u32 booke_wdt_enabled;
u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
#ifdef CONFIG_FSL_BOOKE
-#define WDTP(x) ((((63-x)&0x3)<<30)|(((63-x)&0x3c)<<15))
+#define WDTP(x) ((((x)&0x3)<<30)|(((x)&0x3c)<<15))
#define WDTP_MASK (WDTP(0))
#else
#define WDTP(x) (TCR_WP(x))
@@ -50,6 +52,45 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
static DEFINE_SPINLOCK(booke_wdt_lock);
+/* For the specified period, determine the number of seconds
+ * corresponding to the reset time. There will be a watchdog
+ * exception at approximately 3/5 of this time.
+ *
+ * The formula to calculate this is given by:
+ * 2.5 * (2^(63-period+1)) / timebase_freq
+ *
+ * In order to simplify things, we assume that period is
+ * at least 1. This will still result in a very long timeout.
+ */
+static unsigned long long period_to_sec(unsigned int period)
+{
+ unsigned long long tmp = 1ULL << (64 - period);
+ unsigned long tmp2 = ppc_tb_freq;
+
+ /* tmp may be a very large number and we don't want to overflow,
+ * so divide the timebase freq instead of multiplying tmp
+ */
+ tmp2 = tmp2 / 5 * 2;
+
+ do_div(tmp, tmp2);
+ return tmp;
+}
+
+/*
+ * This procedure will find the highest period which will give a timeout
+ * greater than the one required. e.g. for a bus speed of 66666666 and
+ * and a parameter of 2 secs, then this procedure will return a value of 38.
+ */
+static unsigned int sec_to_period(unsigned int secs)
+{
+ unsigned int period;
+ for (period = 63; period > 0; period--) {
+ if (period_to_sec(period) >= secs)
+ return period;
+ }
+ return 0;
+}
+
static void __booke_wdt_ping(void *data)
{
mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
@@ -93,7 +134,7 @@ static long booke_wdt_ioctl(struct file *file,
switch (cmd) {
case WDIOC_GETSUPPORT:
- if (copy_to_user(arg, &ident, sizeof(struct watchdog_info)))
+ if (copy_to_user((void *)arg, &ident, sizeof(struct watchdog_info)))
return -EFAULT;
case WDIOC_GETSTATUS:
return put_user(ident.options, p);
@@ -115,8 +156,16 @@ static long booke_wdt_ioctl(struct file *file,
booke_wdt_ping();
return 0;
case WDIOC_SETTIMEOUT:
- if (get_user(booke_wdt_period, p))
+ if (get_user(tmp, p))
return -EFAULT;
+#ifdef CONFIG_FSL_BOOKE
+ /* period of 1 gives the largest possible timeout */
+ if (tmp > period_to_sec(1))
+ return -EINVAL;
+ booke_wdt_period = sec_to_period(tmp);
+#else
+ booke_wdt_period = tmp;
+#endif
mtspr(SPRN_TCR, (mfspr(SPRN_TCR) & ~WDTP_MASK) |
WDTP(booke_wdt_period));
return 0;
^ permalink raw reply related
* Re: ARM clock API to PowerPC
From: Mitch Bradley @ 2009-08-12 17:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <1250065762.15143.47.camel@pasglop>
>
> On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
>
>
>> > - Device-tree: The idea on top of my mind would be to define a
>> > clock-map property that has the following format:
>> >
>> > A list of:
>> > - zero terminated string clock ID, padded with zeros
>> > to a cell boundary
>>
Padding a string violates a core principle of property representation,
namely the "no alignment assumptions" one. The reason for that
principle was the fact that alignment needs are not stable across
processor families, or even within a processor family .
>> > - a phandle to the clock provider
>> > - a numerical (string ?) ID for that clock within that provider
>> >
>> > The core would thus be able to do a search in that list based on the
>> > clock-id passed in, or if clk_get(dev, NULL), then, use the first one.
>>
>
> Thinking a bit more about that one, mixing strings and numbers in a
> property sucks. What about instead:
>
> clock-map is a list of phandle, id
>
> clock-names is an optional list of 0 terminated strings
>
This approach finesses the problem nicely.
> If there's only one clock, and the ID can be ommited, then the
> clock-names property can be ommited completely too. Else, the
> entries in clock-names match the entries in clock-map.
>
> It's a bit strange to separate the list into two properties but
> I think it will generally suck less than having them mixed, especially
> with ASCII representations such as lsprop output.
>
> Cheers,
> Ben
>
^ permalink raw reply
* [PATCH 4/4] sbc8349: update defconfig, enable MTD, USB storage
From: Paul Gortmaker @ 2009-08-12 13:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <87b9869d069308d2ed12324ea924e284c85a6765.1250036189.git.paul.gortmaker@windriver.com>
With flash partition entries in the DTS file, MTD might as well
be enabled in the defconfig. In a similar vein, enable USB and
enough related options (SCSI/ext2/ext3) so that a user can read
and write to a generic USB flash drive as well.
Also, this board only has the two default SOC UARTs, so adjust the
UART config accordingly.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/configs/83xx/sbc834x_defconfig | 320 ++++++++++++++++++++++++++-
1 files changed, 308 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/configs/83xx/sbc834x_defconfig b/arch/powerpc/configs/83xx/sbc834x_defconfig
index a592b5e..3a68f86 100644
--- a/arch/powerpc/configs/83xx/sbc834x_defconfig
+++ b/arch/powerpc/configs/83xx/sbc834x_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.31-rc4
-# Wed Jul 29 23:32:13 2009
+# Linux kernel version: 2.6.31-rc5
+# Tue Aug 11 19:57:51 2009
#
# CONFIG_PPC64 is not set
@@ -420,7 +420,90 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+CONFIG_MTD_CONCAT=y
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_TESTS is not set
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_OF_PARTS=y
+# CONFIG_MTD_AR7_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# 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 is not set
+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 is not set
+# 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
+
+#
+# LPDDR flash memory drivers
+#
+# CONFIG_MTD_LPDDR is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_MDIO=y
@@ -436,6 +519,7 @@ CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
+# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32768
@@ -468,9 +552,38 @@ CONFIG_HAVE_IDE=y
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
-# CONFIG_SCSI is not set
-# CONFIG_SCSI_DMA is not set
+CONFIG_SCSI=y
+CONFIG_SCSI_DMA=y
+# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
+# CONFIG_SCSI_PROC_FS is not set
+
+#
+# SCSI support type (disk, tape, CD-ROM)
+#
+CONFIG_BLK_DEV_SD=y
+# CONFIG_CHR_DEV_ST is not set
+# CONFIG_CHR_DEV_OSST is not set
+# CONFIG_BLK_DEV_SR is not set
+# CONFIG_CHR_DEV_SG is not set
+# CONFIG_CHR_DEV_SCH is not set
+# CONFIG_SCSI_MULTI_LUN is not set
+# CONFIG_SCSI_CONSTANTS is not set
+# CONFIG_SCSI_LOGGING is not set
+# CONFIG_SCSI_SCAN_ASYNC is not set
+CONFIG_SCSI_WAIT_SCAN=m
+
+#
+# SCSI Transports
+#
+# CONFIG_SCSI_SPI_ATTRS is not set
+# CONFIG_SCSI_FC_ATTRS is not set
+# CONFIG_SCSI_ISCSI_ATTRS is not set
+# CONFIG_SCSI_SAS_LIBSAS is not set
+# CONFIG_SCSI_SRP_ATTRS is not set
+# CONFIG_SCSI_LOWLEVEL is not set
+# CONFIG_SCSI_DH is not set
+# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
@@ -578,11 +691,21 @@ CONFIG_GIANFAR=y
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
+
+#
+# USB Network Adapters
+#
+# CONFIG_USB_CATC is not set
+# CONFIG_USB_KAWETH is not set
+# CONFIG_USB_PEGASUS is not set
+# CONFIG_USB_RTL8150 is not set
+# CONFIG_USB_USBNET 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_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
@@ -633,9 +756,9 @@ CONFIG_DEVKMEM=y
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_PCI=y
-CONFIG_SERIAL_8250_NR_UARTS=4
-CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+# CONFIG_SERIAL_8250_PCI is not set
+CONFIG_SERIAL_8250_NR_UARTS=2
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
# CONFIG_SERIAL_8250_EXTENDED is not set
#
@@ -700,6 +823,7 @@ CONFIG_I2C_MPC=y
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
+# CONFIG_I2C_TINY_USB is not set
#
# Graphics adapter I2C/DDC channel drivers
@@ -814,6 +938,11 @@ CONFIG_WATCHDOG=y
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
+
+#
+# USB-based Watchdog Cards
+#
+# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
@@ -856,12 +985,134 @@ CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
+
+#
+# USB Input Devices
+#
+# CONFIG_USB_HID is not set
# CONFIG_HID_PID is not set
#
+# USB HID Boot Protocol drivers
+#
+# CONFIG_USB_KBD is not set
+# CONFIG_USB_MOUSE is not set
+
+#
# Special HID drivers
#
-# CONFIG_USB_SUPPORT 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=y
+# CONFIG_USB_DEBUG is not set
+# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
+
+#
+# Miscellaneous USB options
+#
+CONFIG_USB_DEVICEFS=y
+CONFIG_USB_DEVICE_CLASS=y
+# CONFIG_USB_DYNAMIC_MINORS is not set
+# CONFIG_USB_OTG is not set
+# CONFIG_USB_OTG_WHITELIST is not set
+# CONFIG_USB_OTG_BLACKLIST_HUB is not set
+CONFIG_USB_MON=y
+# CONFIG_USB_WUSB is not set
+# CONFIG_USB_WUSB_CBAF is not set
+
+#
+# USB Host Controller Drivers
+#
+# CONFIG_USB_C67X00_HCD is not set
+# CONFIG_USB_XHCI_HCD is not set
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+# CONFIG_USB_EHCI_TT_NEWSCHED is not set
+CONFIG_USB_EHCI_FSL=y
+CONFIG_USB_EHCI_HCD_PPC_OF=y
+# CONFIG_USB_OXU210HP_HCD is not set
+# CONFIG_USB_ISP116X_HCD is not set
+# CONFIG_USB_ISP1760_HCD is not set
+# CONFIG_USB_OHCI_HCD is not set
+# CONFIG_USB_UHCI_HCD is not set
+# CONFIG_USB_SL811_HCD is not set
+# CONFIG_USB_R8A66597_HCD is not set
+# CONFIG_USB_WHCI_HCD is not set
+# CONFIG_USB_HWA_HCD is not set
+
+#
+# USB Device Class drivers
+#
+# CONFIG_USB_ACM is not set
+# CONFIG_USB_PRINTER is not set
+# CONFIG_USB_WDM is not set
+# CONFIG_USB_TMC is not set
+
+#
+# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
+#
+
+#
+# also be needed; see USB_STORAGE Help for more info
+#
+CONFIG_USB_STORAGE=y
+# CONFIG_USB_STORAGE_DEBUG is not set
+# CONFIG_USB_STORAGE_DATAFAB is not set
+# CONFIG_USB_STORAGE_FREECOM is not set
+# CONFIG_USB_STORAGE_ISD200 is not set
+# CONFIG_USB_STORAGE_USBAT is not set
+# CONFIG_USB_STORAGE_SDDR09 is not set
+# CONFIG_USB_STORAGE_SDDR55 is not set
+# CONFIG_USB_STORAGE_JUMPSHOT is not set
+# CONFIG_USB_STORAGE_ALAUDA is not set
+# CONFIG_USB_STORAGE_ONETOUCH is not set
+# CONFIG_USB_STORAGE_KARMA is not set
+# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
+# CONFIG_USB_LIBUSUAL is not set
+
+#
+# USB Imaging devices
+#
+# CONFIG_USB_MDC800 is not set
+# CONFIG_USB_MICROTEK is not set
+
+#
+# USB port drivers
+#
+# CONFIG_USB_SERIAL is not set
+
+#
+# USB Miscellaneous drivers
+#
+# CONFIG_USB_EMI62 is not set
+# CONFIG_USB_EMI26 is not set
+# CONFIG_USB_ADUTUX is not set
+# CONFIG_USB_SEVSEG is not set
+# CONFIG_USB_RIO500 is not set
+# CONFIG_USB_LEGOTOWER is not set
+# CONFIG_USB_LCD is not set
+# CONFIG_USB_BERRY_CHARGE is not set
+# CONFIG_USB_LED is not set
+# CONFIG_USB_CYPRESS_CY7C63 is not set
+# CONFIG_USB_CYTHERM is not set
+# CONFIG_USB_IDMOUSE is not set
+# CONFIG_USB_FTDI_ELAN is not set
+# CONFIG_USB_APPLEDISPLAY is not set
+# CONFIG_USB_SISUSBVGA is not set
+# CONFIG_USB_LD is not set
+# CONFIG_USB_TRANCEVIBRATOR is not set
+# CONFIG_USB_IOWARRIOR is not set
+# CONFIG_USB_TEST is not set
+# CONFIG_USB_ISIGHTFW is not set
+# CONFIG_USB_VST is not set
+# CONFIG_USB_GADGET is not set
+
+#
+# OTG and related infrastructure
+#
+# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
@@ -882,9 +1133,14 @@ CONFIG_HID=y
#
# File systems
#
-# CONFIG_EXT2_FS is not set
-# CONFIG_EXT3_FS is not set
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
+CONFIG_JBD=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
@@ -940,6 +1196,7 @@ CONFIG_MISC_FILESYSTEMS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
@@ -977,7 +1234,46 @@ CONFIG_RPCSEC_GSS_KRB5=y
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
-# CONFIG_NLS is not set
+CONFIG_NLS=y
+CONFIG_NLS_DEFAULT="iso8859-1"
+# CONFIG_NLS_CODEPAGE_437 is not set
+# CONFIG_NLS_CODEPAGE_737 is not set
+# CONFIG_NLS_CODEPAGE_775 is not set
+# CONFIG_NLS_CODEPAGE_850 is not set
+# CONFIG_NLS_CODEPAGE_852 is not set
+# CONFIG_NLS_CODEPAGE_855 is not set
+# CONFIG_NLS_CODEPAGE_857 is not set
+# CONFIG_NLS_CODEPAGE_860 is not set
+# CONFIG_NLS_CODEPAGE_861 is not set
+# CONFIG_NLS_CODEPAGE_862 is not set
+# CONFIG_NLS_CODEPAGE_863 is not set
+# CONFIG_NLS_CODEPAGE_864 is not set
+# CONFIG_NLS_CODEPAGE_865 is not set
+# CONFIG_NLS_CODEPAGE_866 is not set
+# CONFIG_NLS_CODEPAGE_869 is not set
+# CONFIG_NLS_CODEPAGE_936 is not set
+# CONFIG_NLS_CODEPAGE_950 is not set
+# CONFIG_NLS_CODEPAGE_932 is not set
+# CONFIG_NLS_CODEPAGE_949 is not set
+# CONFIG_NLS_CODEPAGE_874 is not set
+# CONFIG_NLS_ISO8859_8 is not set
+# CONFIG_NLS_CODEPAGE_1250 is not set
+# CONFIG_NLS_CODEPAGE_1251 is not set
+# CONFIG_NLS_ASCII is not set
+# CONFIG_NLS_ISO8859_1 is not set
+# CONFIG_NLS_ISO8859_2 is not set
+# CONFIG_NLS_ISO8859_3 is not set
+# CONFIG_NLS_ISO8859_4 is not set
+# CONFIG_NLS_ISO8859_5 is not set
+# CONFIG_NLS_ISO8859_6 is not set
+# CONFIG_NLS_ISO8859_7 is not set
+# CONFIG_NLS_ISO8859_9 is not set
+# CONFIG_NLS_ISO8859_13 is not set
+# CONFIG_NLS_ISO8859_14 is not set
+# CONFIG_NLS_ISO8859_15 is not set
+# CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
+# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set
# CONFIG_BINARY_PRINTF is not set
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/4] Add localbus node and MTD partitions for SBC834x
From: Paul Gortmaker @ 2009-08-12 13:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <87b9869d069308d2ed12324ea924e284c85a6765.1250036189.git.paul.gortmaker@windriver.com>
From: Liang Li <liang.li@windriver.com>
There is 8MB flash, 8kB EEPROM and 128MB SDRAM on the sbc834x
local bus, so add a localbus node in DTS with MTD partitions.
The recent U-boot commit fe613cdd4eb moves u-boot to the beginning
of flash, hence the legacy label on the partition at the end of flash.
Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Yang Shi <yang.shi@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/sbc8349.dts | 40 +++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8349.dts b/arch/powerpc/boot/dts/sbc8349.dts
index d93e5be..b83036a 100644
--- a/arch/powerpc/boot/dts/sbc8349.dts
+++ b/arch/powerpc/boot/dts/sbc8349.dts
@@ -265,6 +265,46 @@
};
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349-localbus", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+ ranges = <0x0 0x0 0xff800000 0x00800000 /* 8MB Flash */
+ 0x1 0x0 0xf8000000 0x00002000 /* 8KB EEPROM */
+ 0x2 0x0 0x10000000 0x04000000 /* 64MB SDRAM */
+ 0x3 0x0 0x10000000 0x04000000>; /* 64MB SDRAM */
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "intel,28F640J3A", "cfi-flash";
+ reg = <0x0 0x0 0x800000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00000000 0x00040000>;
+ read-only;
+ };
+
+ partition@40000 {
+ label = "user";
+ reg = <0x00040000 0x006c0000>;
+ };
+
+ partition@700000 {
+ label = "legacy u-boot";
+ reg = <0x00700000 0x00100000>;
+ read-only;
+ };
+
+ };
+ };
+
pci0: pci@e0008500 {
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/4] Fix incorrect PCI interrupt map in SBC834x DTS
From: Paul Gortmaker @ 2009-08-12 13:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <87b9869d069308d2ed12324ea924e284c85a6765.1250036189.git.paul.gortmaker@windriver.com>
From: Liang Li <liang.li@windriver.com>
Allows interrupts to occur on the sbc834x. Currently PCI devices
get assigned an incorrect IRQ and so the interrupt count never
increases. This was tested with the 82546GB based dual port E1000
PCI-X NIC which uses two distinct IRQ lines on the one card.
root@localhost:/root> cat /proc/interrupts | grep eth
17: 78 IPIC Level eth1
48: 27121 IPIC Level eth0
Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Yang Shi <yang.shi@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/sbc8349.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8349.dts b/arch/powerpc/boot/dts/sbc8349.dts
index b83036a..0dc90f9 100644
--- a/arch/powerpc/boot/dts/sbc8349.dts
+++ b/arch/powerpc/boot/dts/sbc8349.dts
@@ -310,10 +310,10 @@
interrupt-map = <
/* IDSEL 0x11 */
- 0x8800 0x0 0x0 0x1 &ipic 20 0x8
- 0x8800 0x0 0x0 0x2 &ipic 21 0x8
- 0x8800 0x0 0x0 0x3 &ipic 22 0x8
- 0x8800 0x0 0x0 0x4 &ipic 23 0x8>;
+ 0x8800 0x0 0x0 0x1 &ipic 48 0x8
+ 0x8800 0x0 0x0 0x2 &ipic 17 0x8
+ 0x8800 0x0 0x0 0x3 &ipic 18 0x8
+ 0x8800 0x0 0x0 0x4 &ipic 19 0x8>;
interrupt-parent = <&ipic>;
interrupts = <0x42 0x8>;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/4] Remove second USB node from SBC834x DTS
From: Paul Gortmaker @ 2009-08-12 13:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1250084071-26418-1-git-send-email-paul.gortmaker@windriver.com>
From: Liang Li <liang.li@windriver.com>
Since only one of the SoC USB devices is brought out to a physical
connector on the board, remove the 2nd (USB-DR) node from the DTS.
Having it present and USB enabled will cause a hang at boot.
Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Yang Shi <yang.shi@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/sbc8349.dts | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8349.dts b/arch/powerpc/boot/dts/sbc8349.dts
index 2d9fa68..d93e5be 100644
--- a/arch/powerpc/boot/dts/sbc8349.dts
+++ b/arch/powerpc/boot/dts/sbc8349.dts
@@ -146,18 +146,6 @@
phy_type = "ulpi";
port0;
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
- usb@23000 {
- device_type = "usb";
- compatible = "fsl-usb2-dr";
- reg = <0x23000 0x1000>;
- #address-cells = <1>;
- #size-cells = <0>;
- interrupt-parent = <&ipic>;
- interrupts = <38 0x8>;
- dr_mode = "otg";
- phy_type = "ulpi";
- };
enet0: ethernet@24000 {
#address-cells = <1>;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/4] sbc834x update; PCI IRQ fix, enable MTD, USB
From: Paul Gortmaker @ 2009-08-12 13:34 UTC (permalink / raw)
To: linuxppc-dev
This is a handful of small sbc834x patches, entirely limited in
scope to this board's DTS/defconfig. Aside from the PCI IRQ
mis-assignment fix, the other changes are aimed at improving the
general functionality of the board out of the box, by enabling
MTD and USB storage.
Paul.
^ permalink raw reply
* change to of MTD partition parsing
From: Kumar Gala @ 2009-08-12 14:46 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev list
Ben,
The following commit breaks the previous definition of flash
partitions according to Documentation/powerpc/dts-bindings/mtd-
physmap.txt. Using the 'name' field is bad practice. What was going
on w/the SLOF case?
- k
commit 4b08e149c0e02e97ec49c2a31d14a0d3a02f8074
Author: Benjamin Krill <ben@codiert.org>
Date: Fri Jan 23 17:18:05 2009 +0100
[MTD] ofpart: Check name property to determine partition nodes.
SLOF has a further node which could not be evaluated
by the current routine. The current routine returns
because the node hasn't the required reg property. As
fix this patch adds a check to determine the partition
child nodes. If the node is not a partition the number
of total partitions will be decreased and loop continues
with the next nodes.
Signed-off-by: Benjamin Krill <ben@codiert.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
^ permalink raw reply
* Regarding initial PCI configuration
From: Thirumalai @ 2009-08-12 13:57 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I need some clarification on powerpc linux-2.6.30 kernels PCI
enumeration. Please correct me if i am wrong on this. I am having mpc7448
based custom board on which i am trying to port linux 2.6.30(Note : Earlier
i have ported linux2.6.23 kernel for this board and its successfully
booted). So i have choosen mpc7448hpc2 as my model BSP. . On this the first
call to pci related thing was called. (i.e from
linux/arch/powerpc/platform/mpc7448hpc2.c/setup_arch() ) which will again
call my sysdev/tsi108_pci.c/setup_pci() function. At the end of this
function we use to call the pci_OF_process() function for assigning MEM/IO
addresses to my kernel. again this function was defined on
kernel/pci-common.c function. So here the mess starts. On this function the
code is getting pci_addr and pci_size from ranges property that i used to
pass on my device tree. But the cpu_addr whatever used will get the
translated address from prom_parse.c file. This one is always returning
0xFFFFFFFF. When we just dig into the internals i came to know that the
implementation is totally different from the previos kernel means from
linux-2.6.23 this change has come. Now the latest kernel is exhibiting the
64 bit PCI implementation. But the prom_parse.c code is designed in that
manner i think. because whenever the of_translate_addr() function is called
the function will get the parent node for getting the system bus address
information which we used to have 0xc0000000 and size 0x10000 on the device
tree. This will do for all the devices but when try to use these function
PCI mapping. This will create mess. I don't know how to go further.
Kindly let me know any changes is required on device tree or kernel
itself to get out this problem.
Regards,
T.
**************** CAUTION - Disclaimer *****************This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
*********** End of Disclaimer ***********DataPatterns ITS Group**********
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Kumar Gala @ 2009-08-12 13:40 UTC (permalink / raw)
To: Josh Boyer
Cc: devicetree-discuss, John Jacques, linuxppc-dev list, Torez Smith,
Russell King
In-Reply-To: <20090812111954.GB31596@zod.rchland.ibm.com>
On Aug 12, 2009, at 6:19 AM, Josh Boyer wrote:
> On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt
> wrote:
>> Hi folks !
>>
>> (Russell, let us know if you want to dropped from the CC list, but I
>> felt you may have some useful input to provide here).
>>
>> So I think it would be valuable to provide the ARM clock API
>> exposed by
>> include/linux/clk.h on various PowerPC embedded hardware.
>
> I'm probably being particularly dense, and I haven't had my coffee
> yet this
> morning, but you never actually said _why_ you think this is valuable?
>
> I'm a bit confused as to what problem you are trying to solve with
> the API.
I'm in the same boat as you Josh. I think there is value and utility
here but not sure what problem Ben's trying to solve.
- k
^ permalink raw reply
* Re: ARM clock API to PowerPC
From: Mark Brown @ 2009-08-12 12:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: John Jacques, linuxppc-dev list, devicetree-discuss, Torez Smith,
Russell King
In-Reply-To: <1250063825.15143.43.camel@pasglop>
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
> - From the above, question: Do we want to keep that parent pointer ?
> Does it make sense ? Will we have objects that are clock providers and
> themselves source from multiple parent ? Or we don't care and it becomes
That happens and at times one or more of the sources is off-chip.
> entirely the responsibility of a given struct clk instance to deal with
> its own parenthood ? Parenthood in the core has the advantage of making
> it potentially easier to represent clock nets in the device-tree.
> The core would thus be able to do a search in that list based on the
> clock-id passed in, or if clk_get(dev, NULL), then, use the first one.
What happens if another clock gets added or the list gets reordered for
some reason?
> Also, it would be nice to have a way to have "generic" clock provider
> drivers. For example, have a driver for the FooBar Clock chip, which is
> known to provide 4 fully programmable clocks. So there could be a
> generic driver for that, attached to the clock provider by the probe
> code or via the device-tree, the devices clock-map's just provide the
> clock ID within the chip (which output of the chip they are connected
> to), and so the remaining questions is what to program in each clocks.
Note that the present ARM implementations don't handle anything except
the core SoC normally.
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Peter Zijlstra @ 2009-08-12 12:05 UTC (permalink / raw)
To: Pavel Machek
Cc: Brown, Len, Gautham R Shenoy, linux-kernel@vger.kernel.org,
Rafael J. Wysocki, Pallipadi, Venkatesh, Li, Shaohua, Ingo Molnar,
linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <20090812115806.GK24339@elf.ucw.cz>
On Wed, 2009-08-12 at 13:58 +0200, Pavel Machek wrote:
> Hi!
>
> > May be having (to pick a number) 3 possible offline states for all
> > platforms with one for halt equivalent and one for deepest possible that
> > CPU can handle and one for deepest possible that platform likes for
> > C-states may make sense. Will keeps things simpler in terms of usage
> > expectations and possibly reduce the misuse oppurtubity?
>
> Maybe just going to the deepest offline state automatically is the
> easiest option?
>
> cpu hotplug/unplug should be rare-enough operation that the latencies
> do not really matter, right?
Ha, it uses kstopmachine, anybody caring about hotplug latencies is
insane.
And yeah, I'm not quite sure what this user-interface is good for
either. Having an in-kernel management layer where you can register
various idle routines makes sense. But exposing it to userspace,.. not
so much.
The idle thread can select an idle routine under constraints of the QoS
latency constraints, the unplug loop however should indeed select the
one that is available to dead cpus (not all idle routines are available
from what people tell me), and yields the best power savings.
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Pavel Machek @ 2009-08-12 11:58 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Li, Shaohua,
Ingo Molnar, linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <1249950137.11545.38184.camel@localhost.localdomain>
Hi!
> May be having (to pick a number) 3 possible offline states for all
> platforms with one for halt equivalent and one for deepest possible that
> CPU can handle and one for deepest possible that platform likes for
> C-states may make sense. Will keeps things simpler in terms of usage
> expectations and possibly reduce the misuse oppurtubity?
Maybe just going to the deepest offline state automatically is the
easiest option?
cpu hotplug/unplug should be rare-enough operation that the latencies
do not really matter, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Fw: Regarding Device tree PCI binding on Linux-2.6.30 kernels
From: Thirumalai @ 2009-08-12 11:45 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
> Hi,
> Is there any changes on PCI Device tree binding has happened? Because i
> am trying to port linux 2.6.30 to my MPC7448 based custom board. The
> target is getting hanged at ethernet initialization. Also i have seen on
> the debug message of kernel that the PCI MEM/IO resources are not getting
> assigned. So when searched the reason for not assigning the PCI MEM/IO
> spaces. I have seen the implemetation of
> /linux/arch/powerpc/kernel/pci-common.c/ pci_process_bridge_OF_ranges() is
> some what different from the old kernels. The CPU address is taken using
> of_translate_address() function which is in prom_parse.c. This step is not
> included on the previous implementations. This particular implementation
> causing me problem of not finding PCI MEM/IO spaces. I have taken the dts
> file of arch/powerpc/boot/dts/MPC7448hpc2.dts as my base dts file and
> started to port for my hardware.
> Kindly let me know any changes that i need to know.
> My dts file,
>
> / {
> model = "dpvme0447";
> compatible = "mpc74xx";
> #address-cells = <1>;
> #size-cells = <1>;
>
> aliases {
> ethernet0 = &enet0;
> ethernet1 = &enet1;
>
> serial0 = &serial0;
> serial1 = &serial1;
>
> };
>
> cpus {
> #address-cells = <1>;
> #size-cells =<0>;
>
> PowerPC,7448@0 {
> device_type = "cpu";
> reg = <0>;
> d-cache-line-size = <0x20>; // 32 bytes
> i-cache-line-size = <0x20>; // 32 bytes
> d-cache-size = <0x8000>; // L1, 32K
> bytes
> i-cache-size = <0x8000>; // L1, 32K
> bytes
> timebase-frequency = <0>; // 33 MHz, from
> uboot
> clock-frequency = <0>; // From U-Boot
> bus-frequency = <0>; // From U-Boot
> 32-bit;
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x00000000 0x20000000 // DDR2 512M at 0
> >;
> };
>
> tsi108@50000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> device_type = "tsi-bridge";
> ranges = <0x00000000 0x50000000 0x00010000>;
> reg = <0x50000000 0x00010000>;
> assigned-addresses = <0>;
> bus-frequency = <0>;
>
> i2c@7000 {
> interrupt-parent = <&mpic>;
> interrupts = <0xE 0>;
> reg = <0x7000 0x400>;
> device_type = "i2c";
> compatible = "tsi108-i2c";
> };
>
> MDIO: mdio@6000 {
> device_type = "mdio";
> compatible = "tsi108-mdio";
> reg = <0x6000 0x50>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy8: ethernet-phy@6000 {
> interrupt-parent = <&mpic>;
> interrupts = <2 1>;
> reg = <8>;
> device_type = "ethernet-phy";
> };
>
> phy9: ethernet-phy@6400 {
> interrupt-parent = <&mpic>;
> interrupts = <2 1>;
> reg = <9>;
> device_type = "ethernet-phy"; enet0:
> ethernet@6200 {
> linux,network-index = <0>;
> #size-cells = <0>;
> device_type = "network";
> compatible = "tsi108-ethernet";
> reg = <0x6000 0x200>;
> address = [ 00 06 D2 00 00 01 ];
> interrupts = <0x10 2>;
> interrupt-parent = <&mpic>;
> mdio-handle = <&MDIO>;
> phy-handle = <&phy8>;
> };
>
> enet1: ethernet@6600 {
> linux,network-index = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
> compatible = "tsi108-ethernet";
> reg = <0x6400 0x200>;
> address = [ 00 06 D2 00 00 02 ];
> interrupts = <0x11 2>;
> interrupt-parent = <&mpic>;
> mdio-handle = <&MDIO>;
> phy-handle = <&phy9>;
> };
>
> serial0: serial@7808 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x7808 0x200>;
> clock-frequency = <0x3f6b5a00>;
> interrupts = <0xc 0>;
> interrupt-parent = <&mpic>;
> };
>
> serial1: serial@7c08 {
> device_type = "serial";
> compatible = "ns16550";
> reg = <0x7c08 0x200>;
> clock-frequency = <0x3f6b5a00>;
> interrupts = <0xd 0>;
> interrupt-parent = <&mpic>;
> };
> mpic: pic@7400 {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <0x7400 0x400>;
> built-in;
> compatible = "chrp,open-pic";
> device_type = "open-pic";
> big-endian;
> };
> pci@1000 {
> device_type = "pci";
> compatible = "tsi108-pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <0x1000 0x1000>;
> big-endian;
> bus-range = <0x0 0xff>;
> /* RANGE_TYPE UNKNOWN PCI_ADD PROC_ADDR UNKNOWN
> SIZE
> 02000000 - PCIMEM
> 42000000 - PCI-MEM-PREFETCH
> 01000000 - PCIIO
> */
> ranges = <0x02000000 0x0 0xe0000000 0xe0000000 0x0
> 0x10000000
> 0x42000000 0x0 0x80000000 0x80000000 0x0
> 0x40000000
> 0x01000000 0x0 0x00000000 0xf0000000 0x0
> 0x00010000>;
> clock-frequency = <0x7f28154>;
> interrupt-parent = <&mpic>;
> interrupts = <0x17 2>;
> interrupt-map-mask = <0xf800 0 0 7>;
> interrupt-map = <
>
> /* IDSEL 0x11 */
> 0x0800 0x0 0x0 0x1 &RT0 0x24 0x0
> 0x0800 0x0 0x0 0x2 &RT0 0x25 0x0
> 0x0800 0x0 0x0 0x3 &RT0 0x26 0x0
> 0x0800 0x0 0x0 0x4 &RT0 0x27 0x0
>
> /* IDSEL 0x12 */
> 0x1000 0x0 0x0 0x1 &RT0 0x25 0x0
> 0x1000 0x0 0x0 0x2 &RT0 0x26 0x0
> 0x1000 0x0 0x0 0x3 &RT0 0x27 0x0
> 0x1000 0x0 0x0 0x4 &RT0 0x24 0x0
>
> /* IDSEL 0x13 */
> 0x1800 0x0 0x0 0x1 &RT0 0x26 0x0
> 0x1800 0x0 0x0 0x2 &RT0 0x27 0x0
> 0x1800 0x0 0x0 0x3 &RT0 0x26 0x0
> 0x1800 0x0 0x0 0x4 &RT0 0x26 0x0
>
> /* IDSEL 0x14 */
> 0x2000 0x0 0x0 0x1 &RT0 0x27 0x0
> 0x2000 0x0 0x0 0x2 &RT0 0x24 0x0
> 0x2000 0x0 0x0 0x3 &RT0 0x25 0x0
> 0x2000 0x0 0x0 0x4 &RT0 0x26 0x0
> >;
>
> RT0: router@1180 {
> clock-frequency = <0>;
> interrupt-controller;
> device_type = "pic-router";
> #address-cells = <0>;
> #interrupt-cells = <2>;
> built-in;
> big-endian;
> interrupts = <0x17 2>;
> interrupt-parent = <&mpic>;
> };
> };
> };
> };
>
> Regards,
> T.
> };
>
> };
>
Panic Message that i got
------------[ cut here ]------------
Kernel BUG at c0190764 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
DPVME0447
NIP: c0190764 LR: c0190764 CTR: c014ea54
REGS: df82bd80 TRAP: 0700 Not tainted (2.6.30)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24000022 XER: 20000000
TASK = df82c000[1] 'swapper' THREAD: df82a000
GPR00: c0190764 df82be30 df82c000 0000001a 00001509 ffffffff c014e9a4
00000034
GPR08: c02f4af0 c02e9bb8 00001509 c02cf8f4 24000022 00000000 00000002
00000000
GPR16: c02c0000 00000000 00000000 00000000 00000000 0ffaa41c c0300000
00000004
GPR24: 00000000 00000000 c02f0000 c02f0000 df821030 00000000 df821000
df821300
NIP [c0190764] tsi108_open+0x68/0x9c
LR [c0190764] tsi108_open+0x68/0x9c
Call Trace:
[df82be30] [c0190764] tsi108_open+0x68/0x9c (unreliable)
[df82be50] [c01b157c] dev_open+0xac/0x11c
[df82be70] [c01b147c] dev_change_flags+0x160/0x1b4
[df82be90] [c02bd8f4] ip_auto_config+0x18c/0xe5c
[df82bf50] [c0003c8c] do_one_initcall+0x34/0x1a8
[df82bfd0] [c02a2848] kernel_init+0x9c/0x100
[df82bff0] [c0012024] kernel_thread+0x4c/0x68
Instruction dump:
7c7d1b79 40820034 80bf003c 3c60c029 7fc6f378 38632ad8 90be0028 809f0040
4be90669 3c60c029 38632b08 4be9065d <0fe00000> 48000000 80bf003c 3c60c029
---[ end trace a900fd7f842065b9 ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Regards,
T.
**************** CAUTION - Disclaimer *****************This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
*********** End of Disclaimer ***********DataPatterns ITS Group**********
^ 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