* Re: [PATCH] [POWERPC] QE: simplify GUEMR register initialization
From: Kumar Gala @ 2007-09-11 17:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46E6CBB9.90008@freescale.com>
On Sep 11, 2007, at 12:09 PM, Timur Tabi wrote:
> Paul and Kumar,
>
> It turns out that I have a bunch more QE library code clean-up, so
> please ignore this patch. I'll submit a more comprehensive one
> later this week.
>
> Timur Tabi wrote:
>> The initialization of the QE's GUEMR register is overly
>> complicated, involving
>> multiple functions and a redundant ucc_common structure. This
>> patch removes
>> struct ucc_common, merges ucc_init_guemr() into ucc_set_type()
>> (every caller
>> of ucc_init_guemr() also calls ucc_set_type() immediately
>> afterward), and
>> removes the unused enum ucc_pram_initial_offset.
ok
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Scott Wood @ 2007-09-11 17:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070911173308.GA11951@lixom.net>
Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
>> Olof Johansson wrote:
>>> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>>> primary from the device tree today.
>>> How about something like "fsl,primary-phb" in the bus device node? I don't
>>> know, maybe it's already been discussed and turned down for some reason.
>> It's more of a Linux issue than anything to do with the hardware.
>
> That doesn't stop firmware from telling linux which bus is the primary
> one on the system to help out.
The entire notion of a "primary" PCI bus is due to a Linux flaw.
If we did put it in the device tree, it should be something like
"linux,primary-phb". But since Linux can tell from the node's children,
there doesn't seem to be much point.
-Scott
^ permalink raw reply
* Re: SOC registers/immr determination from device tree (was Re: [PATCH 1/3] fsl_soc.c cleanup)
From: Kumar Gala @ 2007-09-11 17:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list, Yoder Stuart-B08248
In-Reply-To: <46E6CA63.1040703@freescale.com>
On Sep 11, 2007, at 12:03 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 11, 2007, at 11:24 AM, Scott Wood wrote:
>>> I propose we do it by defining the first (and ideally only, but
>>> that's another argument) entry in ranges as the immr, and getting
>>> rid of /soc/reg.
>> I disagree.
>
> I'm shocked. :-)
:)
>> I don't think we want to start overloading the meaning of
>> something like 'ranges' in that way.
>
> As opposed to overloading the meaning of 'reg'?
>
> It's no different than how PCI ranges are treated -- we interpret,
> in a bus-specific way, that certain ranges mean certain things. In
> the case of fsl immr/cssr buses, the first range would mean the
> immr/cssr space.
In PCI its not order dependent. Its just a PCI address. If you want
to propose a SOC address that encodes other information like the PCI
address does feel free to. However, order shouldn't be special. Its
too fragile.
>
>>>>> And why is 82xx-pq2 special? Wouldn't you need this on 83xx,
>>>>> 85xx, and 86xx as well?
>>>> The range will cover the whole immr space on 83xx/85xx/86xx.
>>> And why can't it do that on 82xx?
>> we can cover the whole range, thats fine. We just need a different
>> mechanism to determine immr base.
>
> I'm unconvinced.
>
>>>> 82xx-pq2 is special in that its soc regs are in the middle of the
>>>> immr address map.
>>> The /soc node is misnamed; it should really be /immr. Why do we
>>> need these particular registers to be in /soc/reg rather than a
>>> subnode?
>> They could be in a sub node if there is a clear subnode for them
>> to be in.
>
> Does anything actually use /soc/reg as anything other than an input to
> get_immrbase()? If not, we can defer defining such nodes until
> there's
> actually a need.
I think that's the only user for it. Let's separate the issues.
> It'd probably be more efficient to discuss this in person; can you
> stop
> by my cube sometime when you're around and not in a meeting?
I suggest you propose a solution to determine IMMR base w/o having
using a specific entry in the range property and w/o introducing a
new property. I believe it can be done via either a new device type/
sub-node or regs in the soc node. However, I don't believe you'll be
able to come up with a solution that works for all the FSL platforms.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-11 17:59 UTC (permalink / raw)
To: Scott Wood; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <46E6D4D4.2050600@freescale.com>
On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
> Olof Johansson wrote:
>> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
>>> Olof Johansson wrote:
>>>> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>>>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>>>> primary from the device tree today.
>>>> How about something like "fsl,primary-phb" in the bus device
>>>> node? I don't
>>>> know, maybe it's already been discussed and turned down for some
>>>> reason.
>>> It's more of a Linux issue than anything to do with the hardware.
>>
>> That doesn't stop firmware from telling linux which bus is the
>> primary
>> one on the system to help out.
>
> The entire notion of a "primary" PCI bus is due to a Linux flaw.
>
> If we did put it in the device tree, it should be something like
> "linux,primary-phb". But since Linux can tell from the node's
> children,
> there doesn't seem to be much point.
Once someone rights code to do this I'm happy to change over. I took
this model of explicitly knowing the primary PHB from the pmac code.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Kumar Gala @ 2007-09-11 18:00 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070911172000.GC10743@lixom.net>
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
>> arch/powerpc/platforms/85xx/Kconfig | 1 +
>> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214 +
>> +----------------------
>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224 +
>> +-----------------------
>> arch/powerpc/platforms/Kconfig | 8 +
>> arch/powerpc/platforms/Makefile | 3 +
>> arch/powerpc/platforms/fsl_uli1575.c | 255 ++++++++++++++++
>> ++++++++++++
>> 9 files changed, 363 insertions(+), 545 deletions(-)
>> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>
>
> Since when do we add code directly under powerpc/platforms? Isn't that
> what we have sysdev for?
>
> I know this is already picked up, but I just noticed it when
> looking at
> Kumar's 8572 patch. :-(
I put it in platforms since it was related to the boards not the
chips. We can go around about what sysdev actual means, but I'm
using the assumption that its for processor & bridges (for discrete
processors 10x, mv640x0, etc). Things that are board specific like
the ULI I'm putting under platforms/
- k
^ permalink raw reply
* 2.6.23-rc3 is not booting
From: sivaji @ 2007-09-11 18:05 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am using the kernel 2.6.23-rc3, when i try to boot the kernel i got
following messages.
Booting image at 00200000 ...
Image Name: Linux-2.6.23-rc3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1487259 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x600000.
I have tested with and without pci express support in the kernel and
the device tree. But the result was same.
Processor information :
8641D processor and the silicon revision is 2.0.
Part : MPC8641D
Revision: 2.0
e600 Core Revision: 2.2
DeviceMarking: B
Processor Version Register Value: 0x8004_0202
System Version Register Value: 0x8090_0120
Please Advice me.
by
Sivaji
--
View this message in context: http://www.nabble.com/2.6.23-rc3-is-not-booting-tf4424317.html#a12620437
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-11 18:17 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <46E6D131.2030904@ovro.caltech.edu>
Hi Matthias,
>
>> we build a couple of PCI target designs using AMCC PowerPCs.
>> You are right that some things could be better. But ..
Since you build a couple of target designs, I assume you
(or someone working with you) must have written some host
to target communication device drivers.
The reason I refer to the AMCC interrupt solution as
'cheesy' is that there is only one way to generate
an interrupt; this is distinct from the fact that
there is one interrupt signal (in each direction).
The PCI-to-local bus bridges from PLX, and the messaging
units found in other processors still only have one
interrupt signal between the target and the host
(an INTA# PCI line), and a host-to-target interrupt
by way of some interrupt controller line internal to the
SoC. However, these devices have multiple bits to
assert the interrupt signals.
The nicest feature I've used for developing a host-to-target
communications mechanism is the mailbox registers.
A mailbox register can be written by the host using
write-1 to set, and then cleared by the target using
write-1 to clear. Its important that a write-1 interface
is used, if read-modify-write was used, then interrupts
could be missed.
I wrote up the method I used to create an interprocessor
handshake (used much like a mutex)
http://www.ovro.caltech.edu/~dwh/correlator/pdf/cobra_driver.pdf
The host processor and the target processor use this
protocol for protecting access to a common resource; the
read and write data buffers. The buffers are transferred
using DMA.
Page 8-10 of the document shows a simplified version analogous
to the serial ports of a UART.
A key part of the protocol described is that, analogous to
a serial port, two interrupt sources are required;
* transmitter empty
* receiver ready
The host CPU writes to a transmitter ready bit to generate
a receiver ready interrupt at the target, and once the
target has moved the transmitter data out of the transmit
buffer, it writes to the transmitter empty bit to generate
a transmitter empty interrupt to the host. And the
analogous operation happens for the target to host
transmissions. Hence there are two mailbox bits that
the devices write to to generate an interrupt to the other
processor, and two mailbox bits that generate interrupts,
so are cleared by each processor.
The two interprocessor data paths are independent and
asynchronous with respect to each other, and no polling
is required; upon receiving a mailbox interrupt the
ISR can schedule a receive task, or a transmit task,
or both, depending on the state of the mailbox bits.
How then with only one interrupt source do you implement
a robust interprocessor handshake with the AMCC
single-interrupt, without resorting to polling anywhere
in a driver?
Obviously the above driver was just my take on how to
create such an interface. After I wrote it, I had a look
around and found Micheal Barr had created something similar
(not in the context of a linux driver though).
BTW; I'm not trying to start a flame-war of AMCC verus
Freescale. This just happened to be a downside to this
processor for my specific application. I found plenty
of downsides with Coldfire's, and PowerQuiccIIs and IIIs
too.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Olof Johansson @ 2007-09-11 18:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <9C9F1918-1B55-4426-8138-842B9AAA5BD5@kernel.crashing.org>
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>
>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
>>> arch/powerpc/platforms/85xx/Kconfig | 1 +
>>> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214
>>> ++----------------------
>>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224
>>> ++-----------------------
>>> arch/powerpc/platforms/Kconfig | 8 +
>>> arch/powerpc/platforms/Makefile | 3 +
>>> arch/powerpc/platforms/fsl_uli1575.c | 255
>>> ++++++++++++++++++++++++++++
>>> 9 files changed, 363 insertions(+), 545 deletions(-)
>>> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>>
>>
>> Since when do we add code directly under powerpc/platforms? Isn't that
>> what we have sysdev for?
>>
>> I know this is already picked up, but I just noticed it when looking at
>> Kumar's 8572 patch. :-(
>
> I put it in platforms since it was related to the boards not the chips. We
> can go around about what sysdev actual means, but I'm using the assumption
> that its for processor & bridges (for discrete processors 10x, mv640x0,
> etc). Things that are board specific like the ULI I'm putting under
> platforms/
Hmm, I don't like the pollution of that directory myself, especially since
we've been able to keep it clean up until now.
Maybe it would make more sense for you guys to slice the platforms
differently, and have a common platform for the eval boards you have
with ULi on them instead of grouping it by core used by the processor
on the board.
(In other words, move 86xx over under 85xx, since there wouldn't be much
left over anyway).
-Olof
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-11 18:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40709110719j26a5bf30uc075253c6d1a6d97@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
Hello,
> >[...]
> > intr = mpc52xx_find_and_map("mpc52xx-pic");
> > if(!intr) {
> > panic(__FILE__ ": mpc52xx-pic - MAP failed");
> > }
> >
> > set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
>
> You probably don't want to do this (unless you are cascading IRQs to
> custom external hardware). All you should need is the call to
> request_irq() to register your irq handler, and code in your ISR
> handler to clear the interrupt condition.
>
> You do *NOT* want to program the interrupt controller directly. The
> mpc5200 interrupt controller already has a driver. Don't go twiddling
> the registers manually.
OK!
I have tried it before and i get a "-ENOSYS" returned.
My code was/is now:
--==>
request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
INTMOD_IRQ_BOARD);
<==--
I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
"setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
IRQ-2 on a mpc5200b?
best regards,
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: fricke@jabber.org
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Kumar Gala @ 2007-09-11 18:33 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070911182234.GA12802@lixom.net>
On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>
>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>
>>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>>
>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>> ---
>>>> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
>>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
>>>> arch/powerpc/platforms/85xx/Kconfig | 1 +
>>>> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214
>>>> ++----------------------
>>>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224
>>>> ++-----------------------
>>>> arch/powerpc/platforms/Kconfig | 8 +
>>>> arch/powerpc/platforms/Makefile | 3 +
>>>> arch/powerpc/platforms/fsl_uli1575.c | 255
>>>> ++++++++++++++++++++++++++++
>>>> 9 files changed, 363 insertions(+), 545 deletions(-)
>>>> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>>>
>>>
>>> Since when do we add code directly under powerpc/platforms? Isn't
>>> that
>>> what we have sysdev for?
>>>
>>> I know this is already picked up, but I just noticed it when
>>> looking at
>>> Kumar's 8572 patch. :-(
>>
>> I put it in platforms since it was related to the boards not the
>> chips. We
>> can go around about what sysdev actual means, but I'm using the
>> assumption
>> that its for processor & bridges (for discrete processors 10x,
>> mv640x0,
>> etc). Things that are board specific like the ULI I'm putting under
>> platforms/
>
> Hmm, I don't like the pollution of that directory myself,
> especially since
> we've been able to keep it clean up until now.
What's it matter if we have files under platforms/
Would you feel better if it was in platforms/common/ or platforms/fsl
> Maybe it would make more sense for you guys to slice the platforms
> differently, and have a common platform for the eval boards you have
> with ULi on them instead of grouping it by core used by the processor
> on the board.
>
> (In other words, move 86xx over under 85xx, since there wouldn't be
> much
> left over anyway).
Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
even less sense to me.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Becky Bruce @ 2007-09-11 18:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <424B650B-C272-45FC-BBC6-F090A9474082@kernel.crashing.org>
On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>
> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>
>> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>>
>>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>>
>>>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>>>
>>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>>> ---
>>>>> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
>>>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
>>>>> arch/powerpc/platforms/85xx/Kconfig | 1 +
>>>>> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214
>>>>> ++----------------------
>>>>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>>>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224
>>>>> ++-----------------------
>>>>> arch/powerpc/platforms/Kconfig | 8 +
>>>>> arch/powerpc/platforms/Makefile | 3 +
>>>>> arch/powerpc/platforms/fsl_uli1575.c | 255
>>>>> ++++++++++++++++++++++++++++
>>>>> 9 files changed, 363 insertions(+), 545 deletions(-)
>>>>> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>>>>
>>>>
>>>> Since when do we add code directly under powerpc/platforms? Isn't
>>>> that
>>>> what we have sysdev for?
>>>>
>>>> I know this is already picked up, but I just noticed it when
>>>> looking at
>>>> Kumar's 8572 patch. :-(
>>>
>>> I put it in platforms since it was related to the boards not the
>>> chips. We
>>> can go around about what sysdev actual means, but I'm using the
>>> assumption
>>> that its for processor & bridges (for discrete processors 10x,
>>> mv640x0,
>>> etc). Things that are board specific like the ULI I'm putting under
>>> platforms/
>>
>> Hmm, I don't like the pollution of that directory myself,
>> especially since
>> we've been able to keep it clean up until now.
>
> What's it matter if we have files under platforms/
>
The original intent of platforms as we (Kumar included) laid it out
was that it *only* contain platform subdirs. This makes it easy to
poke around in platforms, and it makes reading the "ls" of that
directory much more meaningful and informative. It also makes it
easy to figure out where a file might be without having to have too
much knowledge about the devices themselves. I really don't like the
idea of polluting this directory.
> Would you feel better if it was in platforms/common/ or platforms/fsl
>
>> Maybe it would make more sense for you guys to slice the platforms
>> differently, and have a common platform for the eval boards you have
>> with ULi on them instead of grouping it by core used by the processor
>> on the board.
>>
>> (In other words, move 86xx over under 85xx, since there wouldn't be
>> much
>> left over anyway).
>
> Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
> even less sense to me.
Yeah, that makes *no* sense to me either. It's an unfortunate
artifact of the naming of boards to include the core name. While the
devices and boards may be similar, once you have bookE vs non-bookE
cores, they become quite different.
I still don't see why this isn't in "sysdev". We intended that to be
the device "kitchen sink". If we really don't want to put it there,
then I would prefer creating a "fsl_common" or "common" directory
under platforms.
I'm also guilty of not noticing the original patch - my apologies.
-Becky
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Kumar Gala @ 2007-09-11 19:08 UTC (permalink / raw)
To: Becky Bruce; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <24F46474-1425-4C8B-A400-4D18D28932F2@freescale.com>
On Sep 11, 2007, at 1:43 PM, Becky Bruce wrote:
>
> On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>
>>
>> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>>
>>> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>>>
>>>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>>>
>>>>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>>>>
>>>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>>>> ---
>>>>>> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
>>>>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
>>>>>> arch/powerpc/platforms/85xx/Kconfig | 1 +
>>>>>> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214
>>>>>> ++----------------------
>>>>>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>>>>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224
>>>>>> ++-----------------------
>>>>>> arch/powerpc/platforms/Kconfig | 8 +
>>>>>> arch/powerpc/platforms/Makefile | 3 +
>>>>>> arch/powerpc/platforms/fsl_uli1575.c | 255
>>>>>> ++++++++++++++++++++++++++++
>>>>>> 9 files changed, 363 insertions(+), 545 deletions(-)
>>>>>> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>>>>>
>>>>>
>>>>> Since when do we add code directly under powerpc/platforms? Isn't
>>>>> that
>>>>> what we have sysdev for?
>>>>>
>>>>> I know this is already picked up, but I just noticed it when
>>>>> looking at
>>>>> Kumar's 8572 patch. :-(
>>>>
>>>> I put it in platforms since it was related to the boards not the
>>>> chips. We
>>>> can go around about what sysdev actual means, but I'm using the
>>>> assumption
>>>> that its for processor & bridges (for discrete processors 10x,
>>>> mv640x0,
>>>> etc). Things that are board specific like the ULI I'm putting
>>>> under
>>>> platforms/
>>>
>>> Hmm, I don't like the pollution of that directory myself,
>>> especially since
>>> we've been able to keep it clean up until now.
>>
>> What's it matter if we have files under platforms/
>>
>
> The original intent of platforms as we (Kumar included) laid it out
> was that it *only* contain platform subdirs. This makes it easy to
> poke around in platforms, and it makes reading the "ls" of that
> directory much more meaningful and informative. It also makes it
> easy to figure out where a file might be without having to have too
> much knowledge about the devices themselves. I really don't like
> the idea of polluting this directory.
That's bogus already. Parts of platform code exist in sysdev/ or
arch/powerpc/kernel/ so there isnt a single place to look. While
that might have been the intent its not true in practice.
>> Would you feel better if it was in platforms/common/ or platforms/fsl
>>
>>> Maybe it would make more sense for you guys to slice the platforms
>>> differently, and have a common platform for the eval boards you have
>>> with ULi on them instead of grouping it by core used by the
>>> processor
>>> on the board.
>>>
>>> (In other words, move 86xx over under 85xx, since there wouldn't be
>>> much
>>> left over anyway).
>>
>> Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
>> even less sense to me.
>
> Yeah, that makes *no* sense to me either. It's an unfortunate
> artifact of the naming of boards to include the core name. While
> the devices and boards may be similar, once you have bookE vs non-
> bookE cores, they become quite different.
>
> I still don't see why this isn't in "sysdev". We intended that to
> be the device "kitchen sink". If we really don't want to put it
> there, then I would prefer creating a "fsl_common" or "common"
> directory under platforms.
>
> I'm also guilty of not noticing the original patch - my apologies.
maybe we should just have a platforms/fsl for all boards from
freescale. Not having things broken up by which processor family
they are for.
- k
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Grant Likely @ 2007-09-11 19:05 UTC (permalink / raw)
To: S. Fricke; +Cc: linuxppc-dev
In-Reply-To: <20070911182811.GA3582@sfrouter>
On 9/11/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
> Hello,
>
> > >[...]
> > > intr = mpc52xx_find_and_map("mpc52xx-pic");
> > > if(!intr) {
> > > panic(__FILE__ ": mpc52xx-pic - MAP failed");
> > > }
> > >
> > > set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
> >
> > You probably don't want to do this (unless you are cascading IRQs to
> > custom external hardware). All you should need is the call to
> > request_irq() to register your irq handler, and code in your ISR
> > handler to clear the interrupt condition.
> >
> > You do *NOT* want to program the interrupt controller directly. The
> > mpc5200 interrupt controller already has a driver. Don't go twiddling
> > the registers manually.
>
> OK!
>
> I have tried it before and i get a "-ENOSYS" returned.
>
> My code was/is now:
> --==>
> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
> INTMOD_IRQ_BOARD);
> <==--
>
> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
>
> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> IRQ-2 on a mpc5200b?
The irq number you pass into request_irq is a system-wide irq number;
it doesn't necessarily map directly onto the MPC52xx irq number.
Typically, you'd have a node for your device in the device tree which
has a phandle back to the interrupt node and you would use
irq_of_parse_and_map() to map it back to a system-wide irq number.
Otherwise, you need to call of_irq_map_raw with the pointer to the
52xx interrupt controller node and the interrupt number in the form
expected by the device tree. (But adding a device tree node for your
device is far easier).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Becky Bruce @ 2007-09-11 19:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <6EF5E5F8-703B-4C49-B458-92CD0CDF89A0@kernel.crashing.org>
On Sep 11, 2007, at 2:08 PM, Kumar Gala wrote:
>
> On Sep 11, 2007, at 1:43 PM, Becky Bruce wrote:
>
>>
>> On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>>
>>>
>>> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>>>
>>>> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>>>>
>>>>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>>>>
>>>>>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>>>>>
>>>>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>>>>> ---
>>>>>>> arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
>>>>>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
>>>>>>> arch/powerpc/platforms/85xx/Kconfig | 1 +
>>>>>>> arch/powerpc/platforms/85xx/mpc8544_ds.c | 214
>>>>>>> ++----------------------
>>>>>>> arch/powerpc/platforms/86xx/Kconfig | 1 +
>>>>>>> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224
>>>>>>> ++-----------------------
>>>>>>> arch/powerpc/platforms/Kconfig | 8 +
>>>>>>> arch/powerpc/platforms/Makefile | 3 +
>>>>>>> arch/powerpc/platforms/fsl_uli1575.c | 255
>>>>>>> ++++++++++++++++++++++++++++
>>>>>>> 9 files changed, 363 insertions(+), 545 deletions(-)
>>>>>>> create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>>>>>>
>>>>>>
>>>>>> Since when do we add code directly under powerpc/platforms? Isn't
>>>>>> that
>>>>>> what we have sysdev for?
>>>>>>
>>>>>> I know this is already picked up, but I just noticed it when
>>>>>> looking at
>>>>>> Kumar's 8572 patch. :-(
>>>>>
>>>>> I put it in platforms since it was related to the boards not the
>>>>> chips. We
>>>>> can go around about what sysdev actual means, but I'm using the
>>>>> assumption
>>>>> that its for processor & bridges (for discrete processors 10x,
>>>>> mv640x0,
>>>>> etc). Things that are board specific like the ULI I'm putting
>>>>> under
>>>>> platforms/
>>>>
>>>> Hmm, I don't like the pollution of that directory myself,
>>>> especially since
>>>> we've been able to keep it clean up until now.
>>>
>>> What's it matter if we have files under platforms/
>>>
>>
>> The original intent of platforms as we (Kumar included) laid it
>> out was that it *only* contain platform subdirs. This makes it
>> easy to poke around in platforms, and it makes reading the "ls" of
>> that directory much more meaningful and informative. It also
>> makes it easy to figure out where a file might be without having
>> to have too much knowledge about the devices themselves. I really
>> don't like the idea of polluting this directory.
>
> That's bogus already. Parts of platform code exist in sysdev/ or
> arch/powerpc/kernel/ so there isnt a single place to look. While
> that might have been the intent its not true in practice.
No, it's not bogus. I said "x" should only contain "y" (where "x" is
"platforms" and "y is "all platform-related code". You extended that
to "all y is in x". That doesn't follow logically. Just because I
want "platforms" to contain only platform subdirs makes *no
statement* about where all platform code exists. What I like about
platforms is that when I go to that directory and look at what's
there, I see a list of platforms (or platform families), not a bunch
of random files. If I want random files, I go to sysdev. Maybe some
code is in kernel, fine. That has absolutely nothing to do with
putting stuff in top-level platforms.
>
>>> Would you feel better if it was in platforms/common/ or platforms/
>>> fsl
>>>
>>>> Maybe it would make more sense for you guys to slice the platforms
>>>> differently, and have a common platform for the eval boards you
>>>> have
>>>> with ULi on them instead of grouping it by core used by the
>>>> processor
>>>> on the board.
>>>>
>>>> (In other words, move 86xx over under 85xx, since there wouldn't be
>>>> much
>>>> left over anyway).
>>>
>>> Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
>>> even less sense to me.
>>
>> Yeah, that makes *no* sense to me either. It's an unfortunate
>> artifact of the naming of boards to include the core name. While
>> the devices and boards may be similar, once you have bookE vs non-
>> bookE cores, they become quite different.
>>
>> I still don't see why this isn't in "sysdev". We intended that to
>> be the device "kitchen sink". If we really don't want to put it
>> there, then I would prefer creating a "fsl_common" or "common"
>> directory under platforms.
You still haven't, in my opinion, answered my question about why it
can't go in sysdev, when I believe the original intent was for stuff
like this to go there.
>>
>> I'm also guilty of not noticing the original patch - my apologies.
>
> maybe we should just have a platforms/fsl for all boards from
> freescale. Not having things broken up by which processor family
> they are for.
What do you envision as being under there? Subdirs? How's it
organized? In some ways that might make sense, but I think we'd need
to sit down and think it through with all the twisted combinations
our hardware people come up with. The fact is that there's really no
clean way to deal with all the wackiness. So we just pick something
that fits OK and go with it.
Cheers,
B
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Olof Johansson @ 2007-09-11 19:36 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, paulus
In-Reply-To: <24F46474-1425-4C8B-A400-4D18D28932F2@freescale.com>
On Tue, Sep 11, 2007 at 01:43:59PM -0500, Becky Bruce wrote:
> >> Maybe it would make more sense for you guys to slice the platforms
> >> differently, and have a common platform for the eval boards you have
> >> with ULi on them instead of grouping it by core used by the processor
> >> on the board.
> >>
> >> (In other words, move 86xx over under 85xx, since there wouldn't be
> >> much
> >> left over anyway).
> >
> > Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
> > even less sense to me.
>
> Yeah, that makes *no* sense to me either. It's an unfortunate
> artifact of the naming of boards to include the core name. While the
> devices and boards may be similar, once you have bookE vs non-bookE
> cores, they become quite different.
It doesn't make sense if you move 86xx under 85xx right now, no.
What I meant (but didn't write) was more along the lines of forking off
a new platform (I don't know if you have a common code name for the SoC
side, but fsl-whatever) that contains the SoC and board support for the
parts and boards that share much (looks like the latest gen 85xx and
8641 would be candidates).
Looks like the CPM2-based stuff could be candidates for something similar
as well, but there's less activity there so there's less reason to rework
those, I suppose.
Of course, down the road I'm sure there'll be a part that contains 75%
of the current SoC, plus something new. And the next gen after that only
contains the 25% non-shared plus 75% brand new stuff and it all falls
apart. Not knowing your roadmap I have a hard time judging if that's
likely though. :-)
-Olof
^ permalink raw reply
* [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-11 19:37 UTC (permalink / raw)
To: linuxppc-dev
Added basic board port for MPC8572 DS reference platform that is
similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
---
Rev 3 -- updates to the device tree based on discussion on how we want
to handle memory busses going forward.
arch/powerpc/boot/dts/mpc8572ds.dts | 374 +++++++
arch/powerpc/configs/mpc8572_ds_defconfig | 1496 +++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 31 +
arch/powerpc/sysdev/fsl_pci.c | 2 +
include/linux/pci_ids.h | 2 +
5 files changed, 1905 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8572ds.dts
create mode 100644 arch/powerpc/configs/mpc8572_ds_defconfig
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
new file mode 100644
index 0000000..bc8feaf
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -0,0 +1,374 @@
+/*
+ * MPC8572 DS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/ {
+ model = "fsl,MPC8572DS";
+ compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8572@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 00000000>; // Filled by U-Boot
+ };
+
+ soc8572@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <00000000 ffe00000 00100000>;
+ reg = <ffe00000 00001000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
+ bus-frequency = <0>; // Filled out by uboot.
+
+ memory-controller@2000 {
+ compatible = "fsl,8572-memory-controller";
+ reg = <2000 1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <12 2>;
+ };
+
+ memory-controller@6000 {
+ compatible = "fsl,8572-memory-controller";
+ reg = <6000 1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <12 2>;
+ };
+
+ l2-cache-controller@20000 {
+ compatible = "fsl,8572-l2-cache-controller";
+ reg = <20000 1000>;
+ cache-line-size = <20>; // 32 bytes
+ cache-size = <80000>; // L2, 512K
+ interrupt-parent = <&mpic>;
+ interrupts = <10 2>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ phy3: ethernet-phy@3 {
+ interrupt-parent = <&mpic>;
+ interrupts = <a 1>;
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <1f 2 20 2 21 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy3>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
+ mpic: pic@40000 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ };
+ };
+
+ pcie@ffe08000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <ffe08000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 80000000 80000000 0 20000000
+ 01000000 0 00000000 ffc00000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ interrupt-map-mask = <fb00 0 0 0>;
+ interrupt-map = <
+ /* IDSEL 0x11 - PCI slot 1 */
+ 8800 0 0 1 &mpic 2 1
+ 8800 0 0 2 &mpic 3 1
+ 8800 0 0 3 &mpic 4 1
+ 8800 0 0 4 &mpic 1 1
+
+ /* IDSEL 0x12 - PCI slot 2 */
+ 9000 0 0 1 &mpic 3 1
+ 9000 0 0 2 &mpic 4 1
+ 9000 0 0 3 &mpic 1 1
+ 9000 0 0 4 &mpic 2 1
+
+ // IDSEL 0x1c USB
+ e000 0 0 0 &i8259 c 2
+ e100 0 0 0 &i8259 9 2
+ e200 0 0 0 &i8259 a 2
+ e300 0 0 0 &i8259 b 2
+
+ // IDSEL 0x1d Audio
+ e800 0 0 0 &i8259 6 2
+
+ // IDSEL 0x1e Legacy
+ f000 0 0 0 &i8259 7 2
+ f100 0 0 0 &i8259 7 2
+
+ // IDSEL 0x1f IDE/SATA
+ f800 0 0 0 &i8259 e 2
+ f900 0 0 0 &i8259 5 2
+
+ >;
+ uli1575@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+
+ pci_bridge@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+
+ isa@1e {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <f000 0 0 0 0>;
+ ranges = <1 0 01000000 0 0
+ 00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ reg = <1 20 2
+ 1 a0 2
+ 1 4d0 2>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ interrupts = <9 2>;
+ interrupt-parent =
+ <&mpic>;
+ };
+
+ i8042@60 {
+ #size-cells = <0>;
+ #address-cells = <1>;
+ reg = <1 60 1 1 64 1>;
+ interrupts = <1 3 c 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ reg = <0>;
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ reg = <1>;
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible = "pnpPNP,b00";
+ reg = <1 70 2>;
+ };
+
+ gpio@400 {
+ reg = <1 400 80>;
+ };
+ };
+ };
+ };
+
+ };
+
+ pcie@ffe09000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <ffe09000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 a0000000 a0000000 0 20000000
+ 01000000 0 00000000 ffc10000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1a 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 4 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ };
+
+ pcie@ffe0a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <ffe0a000 1000>;
+ bus-range = <0 ff>;
+ ranges = <02000000 0 c0000000 c0000000 0 20000000
+ 01000000 0 00000000 ffc20000 0 00010000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <1b 2>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 0 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 3a5c3c4..4d44902 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -181,6 +181,23 @@ static int __init mpc8544_ds_probe(void)
}
}
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mpc8572_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,MPC8572DS")) {
+#ifdef CONFIG_PCI
+ primary_phb_addr = 0x8000;
+#endif
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
define_machine(mpc8544_ds) {
.name = "MPC8544 DS",
.probe = mpc8544_ds_probe,
@@ -194,3 +211,17 @@ define_machine(mpc8544_ds) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(mpc8572_ds) {
+ .name = "MPC8572 DS",
+ .probe = mpc8572_ds_probe,
+ .setup_arch = mpc85xx_ds_setup_arch,
+ .init_IRQ = mpc85xx_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = mpc85xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 114c90f..34cad96 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -255,5 +255,7 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_transpare
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_transparent);
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_transparent)
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_transparent);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 06d23e1..daedb60 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2100,6 +2100,8 @@
#define PCI_DEVICE_ID_MPC8533 0x0031
#define PCI_DEVICE_ID_MPC8544E 0x0032
#define PCI_DEVICE_ID_MPC8544 0x0033
+#define PCI_DEVICE_ID_MPC8572E 0x0040
+#define PCI_DEVICE_ID_MPC8572 0x0041
#define PCI_DEVICE_ID_MPC8641 0x7010
#define PCI_DEVICE_ID_MPC8641D 0x7011
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Josh Boyer @ 2007-09-11 19:38 UTC (permalink / raw)
To: Becky Bruce; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <65BEA2C0-2494-490E-B0EE-B51C96B64075@freescale.com>
On Tue, 11 Sep 2007 14:22:21 -0500
Becky Bruce <becky.bruce@freescale.com> wrote:
> > maybe we should just have a platforms/fsl for all boards from
> > freescale. Not having things broken up by which processor family
> > they are for.
>
> What do you envision as being under there? Subdirs? How's it
> organized? In some ways that might make sense, but I think we'd need
> to sit down and think it through with all the twisted combinations
> our hardware people come up with. The fact is that there's really no
> clean way to deal with all the wackiness. So we just pick something
> that fits OK and go with it.
Just butting in here, but I'd rather not see a platforms/fsl. Just
stick the stuff in sysdev. Companies get renamed, people use cores
from one company in their own products for another company, blah blah
blah.
Not that my opinion counts for much :)
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Kumar Gala @ 2007-09-11 19:47 UTC (permalink / raw)
To: Becky Bruce; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <65BEA2C0-2494-490E-B0EE-B51C96B64075@freescale.com>
>>>> Would you feel better if it was in platforms/common/ or
>>>> platforms/fsl
>>>>
>>>>> Maybe it would make more sense for you guys to slice the platforms
>>>>> differently, and have a common platform for the eval boards you
>>>>> have
>>>>> with ULi on them instead of grouping it by core used by the
>>>>> processor
>>>>> on the board.
>>>>>
>>>>> (In other words, move 86xx over under 85xx, since there
>>>>> wouldn't be
>>>>> much
>>>>> left over anyway).
>>>>
>>>> Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
>>>> even less sense to me.
>>>
>>> Yeah, that makes *no* sense to me either. It's an unfortunate
>>> artifact of the naming of boards to include the core name. While
>>> the devices and boards may be similar, once you have bookE vs non-
>>> bookE cores, they become quite different.
>>>
>>> I still don't see why this isn't in "sysdev". We intended that
>>> to be the device "kitchen sink". If we really don't want to put
>>> it there, then I would prefer creating a "fsl_common" or "common"
>>> directory under platforms.
>
> You still haven't, in my opinion, answered my question about why it
> can't go in sysdev, when I believe the original intent was for
> stuff like this to go there.
I think sysdev should be related to chipsets and soc functionality.
It seems odd to me that the Kconfig for these things lives in arch/
powerpc/platforms
>>> I'm also guilty of not noticing the original patch - my apologies.
>>
>> maybe we should just have a platforms/fsl for all boards from
>> freescale. Not having things broken up by which processor family
>> they are for.
>
> What do you envision as being under there? Subdirs? How's it
> organized? In some ways that might make sense, but I think we'd
> need to sit down and think it through with all the twisted
> combinations our hardware people come up with. The fact is that
> there's really no clean way to deal with all the wackiness. So we
> just pick something that fits OK and go with it.
Just a flat directory.
I don't really care that much about all this. If someone wants to
clean it up feel free to, but not sure what the value of that is.
However, if you are going to fix the Kconfig issue I just mentioned
as well.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
From: Olof Johansson @ 2007-09-11 19:45 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, paulus
In-Reply-To: <65BEA2C0-2494-490E-B0EE-B51C96B64075@freescale.com>
On Tue, Sep 11, 2007 at 02:22:21PM -0500, Becky Bruce wrote:
> >>
> >> I'm also guilty of not noticing the original patch - my apologies.
> >
> > maybe we should just have a platforms/fsl for all boards from
> > freescale. Not having things broken up by which processor family
> > they are for.
>
> What do you envision as being under there? Subdirs? How's it
> organized? In some ways that might make sense, but I think we'd need
> to sit down and think it through with all the twisted combinations
> our hardware people come up with. The fact is that there's really no
> clean way to deal with all the wackiness. So we just pick something
> that fits OK and go with it.
Given the amount of stuff under ??xx, it would be pretty easy to contain
already. All the drivers are under sysdev/ and all core support is under
kernel/. There's really very little under each platform directory at
the moment, just a few shared device tree parsers and some device fixups.
-Olof
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Wolfgang Denk @ 2007-09-11 20:07 UTC (permalink / raw)
To: Babarovic Ivica; +Cc: linuxppc-embedded
In-Reply-To: <46E57A9D.2020506@asist.si>
In message <46E57A9D.2020506@asist.si> you wrote:
>
> What kernel should I get/pull for MPC5200 clone board.
> I've been away from coding on mpc5200 for quite some time now.
> I've read some archives from ML.
> Git repo on Sylvain Munauts url:
> http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.gitpage
> isn't working. Nothing on http://*git*.secretlab.ca/cgi-bin/*gitweb*.cgi
> <http://git.secretlab.ca/cgi-bin/gitweb.cgi> to.
We have working support for the MPC5200 (based on Sylvain's and
Grant's) code in our linux-2.6-denx repository, at least for the
lite5200b and TQM5200 boards; I recommend to stick with commit ID
85ab69c5 = tag DENX-2007-08-30-1748 at the moment, as the 2.6.23-rc5
coe is not completely tested yet. [Well, actually *all* this is work
in progress...]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3
^ permalink raw reply
* Re: SPI driver?
From: Wolfgang Denk @ 2007-09-11 20:19 UTC (permalink / raw)
To: Nicholas Hickman; +Cc: Hesam.Kohanteb, linuxppc-embedded
In-Reply-To: <8140AAF341CC904BA92C3D6A5A1909782F0D4F@ditech-1.ditechllc.com>
In message <8140AAF341CC904BA92C3D6A5A1909782F0D4F@ditech-1.ditechllc.com> you wrote:
> I am also in search of this, or some information about one. Please let
> me know if you find anything.
>
> I ran across an existing platform that used an mpc8270. During boot up
> it displayed:
> [ 17.828513] SPIDriver: module license 'Proprietary' taints kernel.
> [ 17.865052] CPM SPI Driver: $Revision: 1.0 $ wd@denx.de
>
> I have been all over denx and have not been able to find it. This
> particular system used the SPI for a DSP chip.
Probably somebody copied and modified a driver they found in our
trees. We release all such code under GPL...
You can find SPI driver code in our old linuxppc_2_4_devel tree, but
this does not include support for MPC82xx; and then there is an
ancient (5+ years) 82xx SPI driver in our linux-2.4 (2.4.4) kernel
tree.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Thought for the day: What if there were no hypothetical situations?
^ permalink raw reply
* Re: [PATCH 1/3] Implement arch disable/enable irq hooks.
From: Paul Mackerras @ 2007-09-11 21:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905220607.GA11330@ld0162-tx32.am.freescale.net>
Scott Wood writes:
> These hooks ensure that a decrementer interrupt is not pending when
> suspending; otherwise, problems may occur. For example, with deep sleep
> on the 831x, a pending decrementer will cause a system freeze because the
> SoC thinks the decrementer interrupt would have woken the system, but the
> core must have interrupts disabled due to the setup required for deep
> sleep.
> + set_dec(0x7fffffff);
> + local_irq_disable();
> + set_dec(0x7fffffff);
It might be better to use hard_irq_disable rather than
local_irq_disable here, since I think we will need that on 64-bit (and
on 32-bit if we ever do lazy irq disabling there).
> +/* Overrides the weak version in kernel/power/main.c */
> +void arch_suspend_disable_irqs(void)
> +{
> + if (ppc_md.suspend_disable_irqs)
> + ppc_md.suspend_disable_irqs();
> + else
> + generic_suspend_disable_irqs();
Any particular reason why we need a ppc_md hook here? Do we expect
some platform to need to do something different?
Paul.
^ permalink raw reply
* Re: [PATCH 2/3] pm: Handle HID0_SLEEP in the TLF_NAPPING hack.
From: Paul Mackerras @ 2007-09-11 21:31 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905220638.GA11353@ld0162-tx32.am.freescale.net>
Scott Wood writes:
> The e300 core (and probably most other 6xx chips) can only come out of
> sleep mode with an interrupt. However, interrupts are logically disabled
> by the power management layer.
>
> This hack extends the existing doze/nap hack to also suppress the running
> of the interrupt handler when in sleep mode.
Having thought about this for a bit, I have come to the conclusion
that it would be a lot cleaner to use a new TLF_SLEEPING bit rather
than having to read HID0 to know whether we were napping or sleeping.
There are plenty of bits left in thread_info.local_flags; we've only
used 1 so far. :)
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2007-09-11 21:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18151.1452.702936.394284@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> It might be better to use hard_irq_disable rather than
> local_irq_disable here, since I think we will need that on 64-bit (and
> on 32-bit if we ever do lazy irq disabling there).
OK.
>> +/* Overrides the weak version in kernel/power/main.c */
>> +void arch_suspend_disable_irqs(void)
>> +{
>> + if (ppc_md.suspend_disable_irqs)
>> + ppc_md.suspend_disable_irqs();
>> + else
>> + generic_suspend_disable_irqs();
>
> Any particular reason why we need a ppc_md hook here? Do we expect
> some platform to need to do something different?
Not that I know the details of, but others requested it.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] Add 6xx-style HID0_SLEEP support.
From: Paul Mackerras @ 2007-09-11 21:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905220640.GB11353@ld0162-tx32.am.freescale.net>
Scott Wood writes:
> +_GLOBAL(mpc6xx_enter_sleep)
The name is slightly unfortunate as powerbooks also use 6xx-family
processors but enter sleep in a quite different manner, because they
exit sleep with a reset. Can you think of a better name, that gives a
hint that this is the one to use if we are exiting sleep with an
interrupt rather than a reset?
Paul.
^ 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