* Re: [PATCH 1/3] Add support for the Freescale MPC8349E-mITX eval board
From: Kim Phillips @ 2006-06-29 19:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B0F8A9DE-8841-4404-BF8D-D712322FB20E@kernel.crashing.org>
On Thu, 29 Jun 2006 11:38:04 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> > It removes rtc chip-specific code from the platform code. It
> > accomplishes this by using the new "RTC-framework" glue.
>
> I'm aware of the new RTC framework.
>
> This code seems pretty generic for any RTC using the new framework.
> If so, we should put it somewhere more generic like setup.c
>
yeah, I'd like to clean up some more of the existing rtc specific code and do that in one fell swoop..
> > <snip>
> >>> diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h
> >>> index 02ed2c3..80076be 100644
> >>> --- a/include/asm-ppc/mpc83xx.h
> >>> +++ b/include/asm-ppc/mpc83xx.h
> >>> @@ -25,6 +25,10 @@
> >>> #include <platforms/83xx/mpc834x_sys.h>
> >>> #endif
> >>>
> >>> +#ifdef CONFIG_MPC834x_ITX
> >>> +#include <platforms/83xx/mpc834x_itx.h>
> >>> +#endif
> >>> +
> >>
> >> This shouldn't be needed, its a hold over from arch/ppc
> >>
> > Unfortunately it won't build without it.
>
> What's the build error?
>
..
CC arch/powerpc/platforms/83xx/mpc834x_itx.o
arch/powerpc/platforms/83xx/mpc834x_itx.c: In function `mpc83xx_map_irq':
arch/powerpc/platforms/83xx/mpc834x_itx.c:57: error: `PIRQB' undeclared (first use in this function)
..
which reminds me of wanting to adopt Benh's new irq stuff..
Kim
^ permalink raw reply
* Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Andy Fleming @ 2006-06-29 19:18 UTC (permalink / raw)
To: Vitaly Bordug
Cc: Phillips Kim-R1AAHA, Yin Olivia-r63875,
'linux-kernel@vger.kernel.org', linuxppc-dev,
'Paul Mackerras', Chu hanjin-r52514
In-Reply-To: <20060629225131.43b9ed59@localhost.localdomain>
On Jun 29, 2006, at 13:51, Vitaly Bordug wrote:
> On Thu, 29 Jun 2006 13:03:23 -0500
> Andy Fleming wrote:
>
> [snip]
>>>>> + iounmap(bcsr_regs);
>>>>> +
>>>> And if we have a design, which do not contain real ethernet UCC
>>>> usage? Or UCC
>>>> geth is disabled somehow explicitly? Stuff like that normally
>>>> goes to the
>>>> callback that is going to be triggered upon Etherbet init.
>>> I will move it.
>>
>>
>> Wait...no. I don't understand Vitaly's objection. If someone
>> creates a board with an 8360 that doesn't use the UCC ethernet, they
>> can create a separate board file. This is the board-specific code,
>> and it is perfectly acceptable for it to reset the PHY like this.
>> What ethernet callback could be used?
>>
>
> I am sort of against the unconditional trigger of the ethernet-
> specific stuff,
> dependless if UCC eth is really wanted in specific configuration.
>
> For stuff like that I'd make a function (to setup low-level stuff),
> and pass it
> via platform_info to the eth driver, so that really driver-specific
> things happen in driver context only.
>
> Yes this is board specific file, and virtually everything needed
> for the board can take place here.
> But usually BCSR acts as a toggle for a several things, and IOW, I
> see it more correct to trigger those stuff from the respective
> drivers (using a callback passed through platform_info)
Callbacks are fairly evil. And the driver most certainly cannot know
about the BCSR, since there may or may not even *be* a BCSR on any
given board with a QE. The PHY only needs to be reset once, during
initialization. On some boards, there is no need to trigger some
sort of reset, or enable any PHYs. I'm still not sure why this
should be the domain of the device driver, since it's a board option.
Andy
^ permalink raw reply
* Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Vitaly Bordug @ 2006-06-29 19:56 UTC (permalink / raw)
To: Andy Fleming
Cc: Phillips Kim-R1AAHA, Yin Olivia-r63875,
'linux-kernel@vger.kernel.org', linuxppc-dev,
'Paul Mackerras', Chu hanjin-r52514
In-Reply-To: <C45A575E-1283-4299-A403-BE46B13AEF9C@freescale.com>
On Thu, 29 Jun 2006 14:18:51 -0500
Andy Fleming wrote:
>
> On Jun 29, 2006, at 13:51, Vitaly Bordug wrote:
>
> > On Thu, 29 Jun 2006 13:03:23 -0500
> > Andy Fleming wrote:
> >
> > [snip]
> >>>>> + iounmap(bcsr_regs);
> >>>>> +
> >>>> And if we have a design, which do not contain real ethernet UCC
> >>>> usage? Or UCC
> >>>> geth is disabled somehow explicitly? Stuff like that normally
> >>>> goes to the
> >>>> callback that is going to be triggered upon Etherbet init.
> >>> I will move it.
> >>
> >>
> >> Wait...no. I don't understand Vitaly's objection. If someone
> >> creates a board with an 8360 that doesn't use the UCC ethernet,
> >> they can create a separate board file. This is the board-specific
> >> code, and it is perfectly acceptable for it to reset the PHY like
> >> this. What ethernet callback could be used?
> >>
> >
> > I am sort of against the unconditional trigger of the ethernet-
> > specific stuff,
> > dependless if UCC eth is really wanted in specific configuration.
> >
> > For stuff like that I'd make a function (to setup low-level
> > stuff), and pass it
> > via platform_info to the eth driver, so that really
> > driver-specific things happen in driver context only.
> >
> > Yes this is board specific file, and virtually everything needed
> > for the board can take place here.
> > But usually BCSR acts as a toggle for a several things, and IOW, I
> > see it more correct to trigger those stuff from the respective
> > drivers (using a callback passed through platform_info)
>
>
> Callbacks are fairly evil. And the driver most certainly cannot
> know about the BCSR, since there may or may not even *be* a BCSR on
> any given board with a QE. The PHY only needs to be reset once,
> during initialization. On some boards, there is no need to trigger
> some sort of reset, or enable any PHYs. I'm still not sure why this
> should be the domain of the device driver, since it's a board option.
>
Well. The driver does not need to know anything about bcsr. All it needs to do is to execute the function pointer filled in bsp code, if one exists (If nothing needs to be tweaked in bsp level for a driver, just no need to fill that function pointer). For instance, in PQ2 uart, usb and fcc need to be enabled by bcsr before could be actually utilized, so say fs_enet does all needed upon startup, without messing with board setup code.
The same does cpm uart...
In case of this particular board, it is not that bad. But I dislike the concept to execute the code in common (for this board) path, not depending if UCC eth disabled in config explicitly.
-Vitaly
^ permalink raw reply
* Re: [Alsa-devel] [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Andreas Schwab @ 2006-06-29 21:03 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Johannes Berg, alsa-devel, netstar
In-Reply-To: <jehd26aa25.fsf@sykes.suse.de>
Andreas Schwab <schwab@suse.de> writes:
> Takashi Iwai <tiwai@suse.de> writes:
>
>> At Mon, 26 Jun 2006 22:49:04 +0200,
>> Andreas Schwab wrote:
>>>
>>> Johannes Berg <johannes@sipsolutions.net> writes:
>>>
>>> > This patch removes from snd-powermac the code that check for the layout-id
>>> > and instead adds code that makes it refuse loading when a layout-id property
>>> > is present, nothing that snd-aoa should be used.
>>>
>>> Can we get snd-powermac back as long as snd-aoa is lacking all those
>>> features from snd-powermac?
>>
>> What functions are missing?
>
> Sound on PowerMac7,2, DRC on TAS, probably more.
Another problem is that the sound device can only be opened once.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Andy Fleming @ 2006-06-29 21:04 UTC (permalink / raw)
To: Vitaly Bordug
Cc: jeff, Yin Olivia-r63875,
linux-kernel@vger.kernel.org Mailing List, linuxppc-dev list,
Paul Mackerras, Chu hanjin-r52514
In-Reply-To: <20060629235625.5a8880a0@localhost.localdomain>
On Jun 29, 2006, at 14:56, Vitaly Bordug wrote:
> On Thu, 29 Jun 2006 14:18:51 -0500
> Andy Fleming wrote:
>
>>
>> On Jun 29, 2006, at 13:51, Vitaly Bordug wrote:
>>
>>> On Thu, 29 Jun 2006 13:03:23 -0500
>>> Andy Fleming wrote:
>>>
>>> [snip]
>>>>>>> + iounmap(bcsr_regs);
>>>>>>> +
>>>>>> And if we have a design, which do not contain real ethernet UCC
>>>>>> usage? Or UCC
>>>>>> geth is disabled somehow explicitly? Stuff like that normally
>>>>>> goes to the
>>>>>> callback that is going to be triggered upon Etherbet init.
>>>>> I will move it.
>>>>
>>>>
>>>> Wait...no. I don't understand Vitaly's objection. If someone
>>>> creates a board with an 8360 that doesn't use the UCC ethernet,
>>>> they can create a separate board file. This is the board-specific
>>>> code, and it is perfectly acceptable for it to reset the PHY like
>>>> this. What ethernet callback could be used?
>>>>
>>>
>>> I am sort of against the unconditional trigger of the ethernet-
>>> specific stuff,
>>> dependless if UCC eth is really wanted in specific configuration.
>>>
>>> For stuff like that I'd make a function (to setup low-level
>>> stuff), and pass it
>>> via platform_info to the eth driver, so that really
>>> driver-specific things happen in driver context only.
>>>
>>> Yes this is board specific file, and virtually everything needed
>>> for the board can take place here.
>>> But usually BCSR acts as a toggle for a several things, and IOW, I
>>> see it more correct to trigger those stuff from the respective
>>> drivers (using a callback passed through platform_info)
>>
>>
>> Callbacks are fairly evil. And the driver most certainly cannot
>> know about the BCSR, since there may or may not even *be* a BCSR on
>> any given board with a QE. The PHY only needs to be reset once,
>> during initialization. On some boards, there is no need to trigger
>> some sort of reset, or enable any PHYs. I'm still not sure why this
>> should be the domain of the device driver, since it's a board option.
>>
>
> Well. The driver does not need to know anything about bcsr. All it
> needs to do is to execute the function pointer filled in bsp code,
> if one exists (If nothing needs to be tweaked in bsp level for a
> driver, just no need to fill that function pointer). For instance,
> in PQ2 uart, usb and fcc need to be enabled by bcsr before could be
> actually utilized, so say fs_enet does all needed upon startup,
> without messing with board setup code.
> The same does cpm uart...
>
> In case of this particular board, it is not that bad. But I dislike
> the concept to execute the code in common (for this board) path,
> not depending if UCC eth disabled in config explicitly.
Well, let me try to see if I understand the two approaches being
pondered:
1) Use a callback.
Inside the platform info device-specific structure, we create a
callback. Something like enet_info->board_init(). The board boots,
and in the initialization function for that board, the callback is
assigned to be a function which does the appropriate board-specific
initialization. Actually, it makes sure to do this for every device
which requires such initialization. Then, later, the devices are
registered, and matched up with appropriate drivers. Those drivers
make sure to invoke enet_info->board_init() before they do anything
hw related.
2) Let board init code do it
The board boots, and in the initialization function for that board,
it checks to see if the device exists (by searching the device tree),
and if so, does any board-specific initialization (in this case,
configuring the board register to enable the PHY for that device).
The devices are registered, and matched with appropriate drivers.
Those drivers operate, blissfully unaware that there was ever any
danger the board wasn't set up.
Andy
^ permalink raw reply
* Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
From: Gerhard Pircher @ 2006-06-29 21:15 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, rlrevell, alsa-devel, linux-kernel
In-Reply-To: <s5hfyhopb0s.wl%tiwai@suse.de>
-------- Original-Nachricht --------
Datum: Thu, 29 Jun 2006 11:27:15 +0200
Von: Takashi Iwai <tiwai@suse.de>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
Betreff: Re: [Alsa-devel] RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
> At Wed, 28 Jun 2006 22:27:53 +0200,
> Gerhard Pircher wrote:
> >
> > Hi,
> >
> > It took a little bit longer to integrate the patch, as I didn't figure
> out first how to implement the __dma_mmap_coherent() function for PPC
> systems with CONFIG_NOT_COHERENT_CACHE defined. :)
> >
> > Unfortunately my system still crashes within snd_pcm_mmap_data_nopage()
> > (sound/core/pcm_native.c), as you can see below. I guess it tries to
> remap
> > a DMA buffer allocated by the not cache coherent DMA memory allocation
> > function in arch/ppc/kernel/dma-mapping.c.
>
> Strange, nopage will be never called if you apply my patch and modify
> to use dma_mmap_coherent().
>
>
> Takashi
>
That's indeed strange! I'm sure that the new code is called by the sound drivers. Should snd_pcm_mmap_data_nopage() not be used at all anymore, or are there any cases that could still trigger a call of snd_pcm_mmap_data_nopage()?
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH] powerpc: support ibm,extended-*-frequency properties
From: Olof Johansson @ 2006-06-29 21:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, Anton Blanchard
In-Reply-To: <0107ED1F-B674-48C3-AA07-BDF9FD2F7678@kernel.crashing.org>
On Tue, Jun 27, 2006 at 11:48:57PM -0500, Kumar Gala wrote:
> On Jun 20, 2006, at 3:47 AM, Anton Blanchard wrote:
> > + while (cells--)
> > + *val = (*val << 32) | *fp++;
>
> Is it reasonable for cells to be greater than 1 on a 32-bit system?
> If not, ok to protect this with a CONFIG_PPC64
Well, large values will be broken on 32-bit no matter what right now:
CC arch/powerpc/kernel/time.o
arch/powerpc/kernel/time.c: In function ‘get_freq’:
arch/powerpc/kernel/time.c:875: warning: left shift count >= width of type
-Olof
^ permalink raw reply
* [PATCH] Xmon stops CPUs for kdump
From: David Wilder @ 2006-06-29 22:17 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras, haren
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
In the case of a system hang, the user will invoke soft-reset to
initiate the kdump boot. If xmon is enabled, the CPU(s) enter into the
xmon debugger. Unfortunately, the secondary CPU(s) will return to the
hung state when they exit from the debugger (returned from die() ->
system_reset_exception()). This causes a problem in kdump since the
hung CPU(s) will not respond to the IPI sent from kdump. This patch
fixes the issue by calling crash_kexec_secondary() directly from
system_reset_exception() without returning to the previous state. These
secondary CPUs wait 5ms until the kdump boot is started by the primary
CPU. In the case we exited from the debugger to "recover" (command 'x'
in xmon) the primary and the secondary CPUs will all return from die()
-> system_reset_exception() ->crash_kexec_secondary() wait 5ms, then
return to the previous state. A kdump boot is not started in this case.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: David Wilder <dwilder@us.ibm.com>
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: ppc64-x-mon-stop-cpu.patch --]
[-- Type: text/x-patch, Size: 1059 bytes --]
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index fa6bd97..49679c3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -216,6 +216,19 @@ void system_reset_exception(struct pt_re
die("System Reset", regs, SIGABRT);
+ /*
+ * Some CPUs when released from the debugger will execute this path.
+ * These CPUs entered the debugger via a soft-reset. If the CPU was
+ * hung before entering the debugger it will return to the hung
+ * state when exiting this function. This causes a problem in
+ * kdump since the hung CPU(s) will not respond to the IPI sent
+ * from kdump. To prevent the problem we call crash_kexec_secondary()
+ * here. If a kdump had not been initiated or we exit the debugger
+ * with the "exit and recover" command (x) crash_kexec_secondary()
+ * will return after 5ms and the CPU returns to its previous state.
+ */
+ crash_kexec_secondary(regs);
+
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
panic("Unrecoverable System Reset");
^ permalink raw reply related
* SMC1 Serial port blocks
From: tauanna @ 2006-06-29 21:38 UTC (permalink / raw)
To: linuxppc-embedded
I have two identical linux boxes connected via a serial link (9600
bit/s without any handshaking). In both boxes the serial port is
realized by SMC1. One box is receiving and the other transmits a long
stream of bytes. If I start the receiver after the transmitter, it
seems that the transmitter cannot send anymore, even when I start the
receiver. The transmitter has to be restarted to solve the problem.
Any help is appreciated,
Anna
Hai voglia di fare un viaggio, ma non sai dove andare?
Scegli una delle nostre offerte HOTEL IN ITALIA E IN EUROPA da 50 euro.
Prenota subito su Expedia.it e... buona vacanza!
http://expedia.viaggi.tiscali.it/default.aspx?eapid=330-8
^ permalink raw reply
* SMC1 serial port blocks
From: tauanna @ 2006-06-29 21:29 UTC (permalink / raw)
To: linuxppc-embedded
I have two identical linux boxes connected via a serial link (9600
bit/s without any handshaking). In both boxes the serial port is
realized by SMC1. One box is receiving and the other transmits a long
stream of bytes. If I start the receiver after the transmitter, it
seems that the transmitter cannot send anymore, even when I start the
receiver. The transmitter has to be restarted to solve the problem.
Any help is appreciated,
Anna
Hai voglia di fare un viaggio, ma non sai dove andare?
Scegli una delle nostre offerte HOTEL IN ITALIA E IN EUROPA da 50 euro.
Prenota subito su Expedia.it e... buona vacanza!
http://expedia.viaggi.tiscali.it/default.aspx?eapid=330-8
^ permalink raw reply
* Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Vitaly Bordug @ 2006-06-29 22:10 UTC (permalink / raw)
To: Andy Fleming
Cc: linuxppc-dev list, linux-kernel@vger.kernel.org Mailing List,
Yin Olivia-r63875, Chu hanjin-r52514
In-Reply-To: <E5D17B54-D345-4859-A9B0-62F038A694EF@freescale.com>
On Thu, 29 Jun 2006 16:04:21 -0500
Andy Fleming wrote:
>
> On Jun 29, 2006, at 14:56, Vitaly Bordug wrote:
>
> > On Thu, 29 Jun 2006 14:18:51 -0500
> > Andy Fleming wrote:
> >
> >>
> >> On Jun 29, 2006, at 13:51, Vitaly Bordug wrote:
> >>
> >>> On Thu, 29 Jun 2006 13:03:23 -0500
> >>> Andy Fleming wrote:
> >>>
> >>> [snip]
> >>>>>>> + iounmap(bcsr_regs);
> >>>>>>> +
> >>>>>> And if we have a design, which do not contain real ethernet UCC
> >>>>>> usage? Or UCC
> >>>>>> geth is disabled somehow explicitly? Stuff like that normally
> >>>>>> goes to the
> >>>>>> callback that is going to be triggered upon Etherbet init.
> >>>>> I will move it.
> >>>>
> >>>>
> >>>> Wait...no. I don't understand Vitaly's objection. If someone
> >>>> creates a board with an 8360 that doesn't use the UCC ethernet,
> >>>> they can create a separate board file. This is the
> >>>> board-specific code, and it is perfectly acceptable for it to
> >>>> reset the PHY like this. What ethernet callback could be used?
> >>>>
> >>>
> >>> I am sort of against the unconditional trigger of the ethernet-
> >>> specific stuff,
> >>> dependless if UCC eth is really wanted in specific configuration.
> >>>
> >>> For stuff like that I'd make a function (to setup low-level
> >>> stuff), and pass it
> >>> via platform_info to the eth driver, so that really
> >>> driver-specific things happen in driver context only.
> >>>
> >>> Yes this is board specific file, and virtually everything needed
> >>> for the board can take place here.
> >>> But usually BCSR acts as a toggle for a several things, and IOW, I
> >>> see it more correct to trigger those stuff from the respective
> >>> drivers (using a callback passed through platform_info)
> >>
> >>
> >> Callbacks are fairly evil. And the driver most certainly cannot
> >> know about the BCSR, since there may or may not even *be* a BCSR on
> >> any given board with a QE. The PHY only needs to be reset once,
> >> during initialization. On some boards, there is no need to trigger
> >> some sort of reset, or enable any PHYs. I'm still not sure why
> >> this should be the domain of the device driver, since it's a board
> >> option.
> >>
> >
> > Well. The driver does not need to know anything about bcsr. All it
> > needs to do is to execute the function pointer filled in bsp code,
> > if one exists (If nothing needs to be tweaked in bsp level for a
> > driver, just no need to fill that function pointer). For instance,
> > in PQ2 uart, usb and fcc need to be enabled by bcsr before could
> > be actually utilized, so say fs_enet does all needed upon startup,
> > without messing with board setup code.
> > The same does cpm uart...
> >
> > In case of this particular board, it is not that bad. But I
> > dislike the concept to execute the code in common (for this board)
> > path, not depending if UCC eth disabled in config explicitly.
>
> Well, let me try to see if I understand the two approaches being
> pondered:
>
Yes, just right.
> 1) Use a callback.
>
> Inside the platform info device-specific structure, we create a
> callback. Something like enet_info->board_init(). The board boots,
> and in the initialization function for that board, the callback is
> assigned to be a function which does the appropriate board-specific
> initialization. Actually, it makes sure to do this for every device
> which requires such initialization. Then, later, the devices are
> registered, and matched up with appropriate drivers. Those drivers
> make sure to invoke enet_info->board_init() before they do anything
> hw related.
>
> 2) Let board init code do it
>
> The board boots, and in the initialization function for that board,
> it checks to see if the device exists (by searching the device
> tree), and if so, does any board-specific initialization (in this
> case, configuring the board register to enable the PHY for that
> device). The devices are registered, and matched with appropriate
> drivers. Those drivers operate, blissfully unaware that there was
> ever any danger the board wasn't set up.
>
Sounds fine, but there are some corner cases.
In case, really familiar to 8xx people, the board actually has devices, but
they simply do not operate simultaneously (because of hw, or there are conflicting pin options)
So the only way to work in such a case is to craft proper kconfig for say, secondary Eth off, 2-nd uart on and vice versa. BSP code could be aware of that, and make/do not make hw tweaks up to #ifdefs. The way for BSP code to put needed stuff into the function, hereby telling the driver to execute it upon setup before accessing hw seems more consistent way for me.
Again, I agree it may be extra for this particular board. But we are speaking about the concept... That sort of things is used within fs_enet and cpm_uart drivers already in the stock tree.
-Vitaly
^ permalink raw reply
* Re: [Alsa-devel] [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Lee Revell @ 2006-06-29 22:26 UTC (permalink / raw)
To: Andreas Schwab
Cc: Takashi Iwai, linuxppc-dev, Johannes Berg, alsa-devel, netstar
In-Reply-To: <jeu0631xpr.fsf@sykes.suse.de>
On Thu, 2006-06-29 at 23:03 +0200, Andreas Schwab wrote:
> Andreas Schwab <schwab@suse.de> writes:
>
> > Takashi Iwai <tiwai@suse.de> writes:
> >
> >> At Mon, 26 Jun 2006 22:49:04 +0200,
> >> Andreas Schwab wrote:
> >>>
> >>> Johannes Berg <johannes@sipsolutions.net> writes:
> >>>
> >>> > This patch removes from snd-powermac the code that check for the layout-id
> >>> > and instead adds code that makes it refuse loading when a layout-id property
> >>> > is present, nothing that snd-aoa should be used.
> >>>
> >>> Can we get snd-powermac back as long as snd-aoa is lacking all those
> >>> features from snd-powermac?
> >>
> >> What functions are missing?
> >
> > Sound on PowerMac7,2, DRC on TAS, probably more.
>
> Another problem is that the sound device can only be opened once.
>
What is the content of /proc/asound/cards? The patches must have
changed the card name and failed to create a matching config file
in /usr/share/alsa/cards.
Lee
^ permalink raw reply
* Re: new IRQ work status
From: Benjamin Herrenschmidt @ 2006-06-29 22:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200606291525.53254.arnd.bergmann@de.ibm.com>
> > /* Get an IRQ number from the pending state register of the IIC */
> > -int iic_get_irq(struct pt_regs *regs)
> > +unsigned int iic_get_irq(struct pt_regs *regs)
>
> Is unsigned the right thing here? NO_IRQ is defined as (-1).
One of the patches changes NO_IRQ to 0 and generally virtual irq numbers
to unsigned int
> I'd prefer to throw out the hardcoded part from the official tree
> completely. It's only needed on the very first FW versions that
> were shipped and those need some other patches that we never merged
> upstream anyway. So better move it to an extra patch that we keep
> external for some time and eventually drop.
Ok, will move it to a separate patch then.
> > static irqreturn_t iic_ipi_action(int irq, void *dev_id, struct pt_regs
> > *regs) {
> > - smp_message_recv(iic_irq_to_ipi(irq), regs);
> > + int ipi = (int)(long)dev_id;
> > + smp_message_recv(ipi, regs);
> > return IRQ_HANDLED;
> > }
>
> Nice one. this looks a lot cleaner than looking at the irq number here.
Yeah, I had the calculation wrong at first :) the irq number you get
here is the virtual one. So you 'd need to convert it through the
reverse map. With the above trick, I avoid that.
> Considering that name is know to be rather short and we have a fixed
> number of these, can't we just put the strings into struct iic
> instead of doing the kzalloc?
Good point, I'll look into it.
> > enum {
> > - IIC_EXT_OFFSET = 0x00, /* Start of south bridge IRQs */
> > - IIC_EXT_CASCADE = 0x20, /* There is no interrupt 32 on spider */
> > - IIC_NUM_EXT = 0x40, /* Number of south bridge IRQs */
> > - IIC_SPE_OFFSET = 0x40, /* Start of SPE interrupts */
> > - IIC_CLASS_STRIDE = 0x10, /* SPE IRQs per class */
> > - IIC_IPI_OFFSET = 0x70, /* Start of IPI IRQs */
> > - IIC_NUM_IPIS = 0x10, /* IRQs reserved for IPI */
> > - IIC_NODE_STRIDE = 0x80, /* Total IRQs per node */
> > + IIC_IRQ_INVALID = 0xff,
>
> Where is IIC_IRQ_INVALID used?
Just to give an invalid number to the remapping core. It uses that to
fill up allocated but not-yet mapped slots
> See above about the hardcoded stuff.
Yup.
>
> > @@ -664,11 +688,18 @@ static int __init create_spu(struct devi
> > if (ret)
> > goto out_free;
> >
> > + /* XXX FIXME: Those node vs. nid things are crap, we need
> > + * only one information, but fixing that goes along with fixing
> > + * all of the node vs chip vs thread code all over the cell
> > + * platform. To do soon hopefully...
> > + */
> > spu->node = find_spu_node_id(spe);
> > spu->nid = of_node_to_nid(spe);
> > if (spu->nid == -1)
> > spu->nid = 0;
>
> The idea at some point was to keep the notion of nid (as in address
> on the inter-chip protocol) separate from the NUMA node ID, which
> may in theory be less fine-grained. Defining them to be the same
> at least requires the device tree to be very careful with the numbers
> in ibm,associativity properties to match the bus numbers.
Yeah, I've discussed that with Paul and Anton, I want to do a generic
layer to take care of all these conversions with a 4 level
representation:
- thread -> match linux CPU numbers
- core
- chip
- node
Anyway, that's the sort of cleanup I'll do later.
> > Index: linux-work-mm/include/asm-powerpc/spu.h
> > ===================================================================
> > --- linux-work-mm.orig/include/asm-powerpc/spu.h 2006-06-23
> > 13:38:19.000000000 +1000 +++
> > linux-work-mm/include/asm-powerpc/spu.h 2006-06-29 16:32:35.000000000 +1000
> > @@ -117,7 +117,7 @@ struct spu {
> > struct list_head sched_list;
> > int number;
> > int nid;
> > - u32 isrc;
> > + unsigned int irqs[3];
> > u32 node;
> > u64 flags;
> > u64 dar;
>
> We've started exporting the isrc property in sysfs recently, so I think
> we need to keep that in here.
Why would we do that ? It makes no sense on HV platforms. Is there
anything that makes use of it ?
Ben.
^ permalink raw reply
* Re: [Alsa-devel] [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Andreas Schwab @ 2006-06-29 23:16 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, linuxppc-dev, Johannes Berg, alsa-devel, netstar
In-Reply-To: <1151619973.22380.50.camel@mindpipe>
Lee Revell <rlrevell@joe-job.com> writes:
> What is the content of /proc/asound/cards? The patches must have
> changed the card name and failed to create a matching config file
> in /usr/share/alsa/cards.
Thanks for the hint. I have added 'AppleOnbdAudio cards.PMac' to
/usr/share/alsa/cards/aliases.conf, and it works again.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] PCI-less kernel for PPC405-based boards
From: Wojtek Kaniewski @ 2006-06-29 23:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
This patch fixes compilation errors of PCI-less kernel for Bubinga and
EP405 boards. Other PPC405-based boards with bios_fixup() (Walnut and
Sycamore) already contain required #ifdefs.
Signed-Off-By: Wojtek Kaniewski <wojtekka@toxygen.net>
[-- Attachment #2: linux-2.6.17-ppc4xx-pciless.patch --]
[-- Type: text/x-patch, Size: 1176 bytes --]
diff -uNr linux-2.6.17.orig/arch/ppc/platforms/4xx/bubinga.c linux-2.6.17/arch/ppc/platforms/4xx/bubinga.c
--- linux-2.6.17.orig/arch/ppc/platforms/4xx/bubinga.c 2006-03-21 13:58:58.000000000 +0100
+++ linux-2.6.17/arch/ppc/platforms/4xx/bubinga.c 2006-06-30 00:53:44.000000000 +0200
@@ -117,7 +117,7 @@
void __init
bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
{
-
+#ifdef CONFIG_PCI
unsigned int bar_response, bar;
/*
* Expected PCI mapping:
@@ -213,6 +213,7 @@
printk(" ptm2la\t0x%x\n", in_le32(&(pcip->ptm2la)));
#endif
+#endif
}
void __init
diff -uNr linux-2.6.17.orig/arch/ppc/platforms/4xx/ep405.c linux-2.6.17/arch/ppc/platforms/4xx/ep405.c
--- linux-2.6.17.orig/arch/ppc/platforms/4xx/ep405.c 2006-06-18 12:10:45.000000000 +0200
+++ linux-2.6.17/arch/ppc/platforms/4xx/ep405.c 2006-06-30 00:54:01.000000000 +0200
@@ -69,6 +69,7 @@
void __init
bios_fixup(struct pci_controller *hose, struct pcil0_regs *pcip)
{
+#ifdef CONFIG_PCI
unsigned int bar_response, bar;
/*
* Expected PCI mapping:
@@ -131,6 +132,7 @@
PCI_FUNC(hose->first_busno), bar, bar_response);
}
/* end work arround */
+#endif
}
void __init
^ permalink raw reply
* Re: [PATCH] Add QE device tree definition
From: Kumar Gala @ 2006-06-29 23:55 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FE5@zch01exm40.ap.freescale.net>
On Jun 29, 2006, at 7:53 AM, Li Yang-r58472 wrote:
> This is the device tree definition for QE SOC for Freescale CPUs.
>
> I have discussed with Vitaly. We agreed on having CPM and QE
> definition ultimately merged. He will add in CPM specified
> definition later.
>
> Signed-off-by: Jiang Bo <Tanya.jiang@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>
> ---
> Documentation/powerpc/booting-without-of.txt | 222 ++++++++++++++++
> ++++++++++
> 1 files changed, 222 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index 217e517..096063f 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1442,6 +1442,227 @@ platforms are moved over to use the flat
> };
>
>
> + h) Freescale QUICC Engine module (QE)
> + This represents qe module that is installed on PowerQUICC II Pro.
> + Hopefully it will merge backward compatibility with CPM/CPM2.
> + Basically, it is a bus of devices, that could act more or less
> + as a complete entity (UCC, USB etc ). All of them should be
> siblings on
> + the "root" qe node, using the common properties from there.
> + The description below applies to the the qe of MPC8360 and
> + more nodes and properties would be extended in the future.
> +
> + 1) Root QE device
> +
> + Required properties:
> + - device_type : should be "qe";
> + - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
> + - reg : Offset and length of the register set for the device.
> + - bus-frequency : the clock frequency for QUICC Engine.
> +
> + Recommended properties
> + - brg-frequency : the internal clock source frequency for baud-
> rate
> + generators in Hz.
> +
> + Example:
> + qe@e0100000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "qe";
> + model = "QE";
> + ranges = <0 e0100000 00100000>;
> + reg = <e0100000 480>;
> + brg-frequency = <0>;
> + bus-frequency = <179A7B00>;
> + }
> +
> +
> + 2) SPI (Serial Peripheral Interface)
> +
> + Required properties:
> + - device_type : should be "spi".
> + - compatible : should be "fsl_spi".
> + - mode : the spi operation mode, it can be "cpu" or "qe".
What does it mean for the spi to be in "qe" mode?
> + - reg : offset to the register set and its length.
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> +
> + Example:
> + spi@4c0 {
> + device_type = "spi";
> + compatible = "fsl_spi";
> + reg = <4c0 40>;
> + interrupts = <82 0>;
> + interrupt-parent = <700>;
> + mode = "cpu";
> + };
> +
How do we tell the difference between the various spi controllers. I
think we have four of them, three of which are probably pretty
similar. We have the 834x spi, and QE, CPM1, CPM2 SPI.
> +
> + 3) USB (Universal Serial Bus Controller)
> +
> + Required properties:
> + - device_type : should be "usb".
> + - compatible : could be "qe_udc" or "fhci-hcd".
> + - model : the could be "host" or "slave".
got a 'l' on mode, if we are slave should we provide more info about
what kinda slave we are (ie, what gadget driver should apply).
> + - reg : there will be two tuples of "address size". The first
> tuple is
> + offset and length of the device registers respectively; the
> second is
> + offset and length of the device parameter RAM respectively.
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> +
> + Example(slave):
> + usb@6c0 {
> + device_type = "usb";
> + compatible = "qe_udc";
> + reg = <6c0 40 8B00 100>;
> + interrupts = <8b 0>;
> + interrupt-parent = <700>;
> + mode = "slave";
> + };
> +
> +
> + 4) UCC (Unified Communications Controllers)
Why dont you create a sub section for network, and in the future
additional subsections can be added for the different device_types.
> +
> + Required properties:
> + - device_type : should be "network", "hldc", "uart", "transparent"
> + "bisync" or "atm".
> + - compatible : could be "ucc_geth" or "fsl_atm" and so on.
> + - model : should be "UCC".
> + - device-id : the ucc number(1-8), corresponding to UCCx in UM.
> + - reg : there will be two tuples of "address size". The first
> tuple is
> + offset and length of the device registers respectively; the
> second is
> + offset and length of the device parameter RAM respectively.
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> + - pio-handle : The phandle for the Parallel I/O port
> configuration.
> +
> + Required properties for network device_type:
> + - mac-address : list of bytes representing the ethernet address.
> + - rx-clock : a string represents the UCC receive clock source.
> + "brgx" : clock source is BRG1~BRG16 respectively;
> + "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> + others : clock source is disabled;
> + - tx-clock: a string represents the UCC transmit clock source;
> + "brgx" : clock source is BRG1~BRG16 respectively;
> + "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> + others : clock source is disabled;
> + - phy-handle : The phandle for the PHY connected to this
> controller.
> +
> + Example:
> + ucc@2000 {
> + device_type = "network";
> + compatible = "ucc_geth";
> + model = "UCC";
> + device-id = <1>;
> + reg = <2000 200 8400 100>;
> + interrupts = <a0 0>;
> + interrupt-parent = <700>;
> + mac-address = [ 00 04 9f 00 23 23 ];
> + rx-clock = "none";
> + tx-clock = "clk9";
> + phy-handle = <212000>;
> + pio-handle = <140001>;
> + };
> +
> +
> + 5) Parallel I/O Ports
> +
> + This node configures Parallel I/O ports for CPUs with QE support.
> + The node should reside in the "soc" node of the tree. For each
> + device that using parallel I/O ports, a child node should be
> created.
> + See the definition of the Pin configuration nodes below for more
> + information.
> +
> + Required properties:
> + - device_type : should be "par_io".
> + - reg : offset to the register set and its length.
> +
> + Example:
> + par_io@1400 {
> + reg = <1400 100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "par_io";
> + ucc_pin@01 {
> + ......
> + };
> +
Can you explain this further, I'm not getting the relationship
between a par_io & ucc_pin. An example maybe helpful.
> +
> + 6) Pin configuration nodes
> +
> + Required properties:
> + - linux,phandle : phandle of this node; likely referenced by a QE
> + device.
> + - pio-map : array of pin configurations. Each pin is defined by 6
> + integers. The six numbers are respectively: port, pin, dir,
> + open_drain, assignment, has_irq.
> + - port : port number of the pin; 0-6 represent port A-G in UM.
> + - pin : pin number in the port.
> + - dir : direction of the pin, should encode as follows:
> +
> + 0 = The pin is disabled
> + 1 = The pin is an output
> + 2 = The pin is an input
> + 3 = The pin is I/O
> +
> + - open_drain : indicates the pin is normal or wired-OR:
> +
> + 0 = The pin is actively driven as an output
> + 1 = The pin is an open-drain driver. As an output, the pin is
> + driven active-low, otherwise it is three-stated.
> +
> + - assignment : function number of the pin according to the
> Pin Assignment
> + tables in User Manual. Each pin can have up to 4 possible
> functions in
> + QE and two options for CPM.
> + - has_irq : indicates if the pin is used as source of exteral
> + interrupts.
> +
> + Example:
> + ucc_pin@01 {
> + linux,phandle = <140001>;
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 3 1 0 1 0 /* TxD0 */
> + 0 4 1 0 1 0 /* TxD1 */
> + 0 5 1 0 1 0 /* TxD2 */
> + 0 6 1 0 1 0 /* TxD3 */
> + 1 6 1 0 3 0 /* TxD4 */
> + 1 7 1 0 1 0 /* TxD5 */
> + 1 9 1 0 2 0 /* TxD6 */
> + 1 a 1 0 2 0 /* TxD7 */
> + 0 9 2 0 1 0 /* RxD0 */
> + 0 a 2 0 1 0 /* RxD1 */
> + 0 b 2 0 1 0 /* RxD2 */
> + 0 c 2 0 1 0 /* RxD3 */
> + 0 d 2 0 1 0 /* RxD4 */
> + 1 1 2 0 2 0 /* RxD5 */
> + 1 0 2 0 2 0 /* RxD6 */
> + 1 4 2 0 2 0 /* RxD7 */
> + 0 7 1 0 1 0 /* TX_EN */
> + 0 8 1 0 1 0 /* TX_ER */
> + 0 f 2 0 1 0 /* RX_DV */
> + 0 10 2 0 1 0 /* RX_ER */
> + 0 0 2 0 1 0 /* RX_CLK */
> + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
> + 2 8 2 0 1 0>; /* GTX125 - CLK9 */
> + };
> +
> +
> More devices will be defined as this spec matures.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] [powerpc] cleanup of_device_(un)register
From: Jeremy Kerr @ 2006-06-30 3:03 UTC (permalink / raw)
To: linuxppc-dev
of_device_register() and of_device_unregister() modify the contents of
property values, so use of_find_property rather than get_property.
Also, clean up the sizeof(sizeof()) fruitiness.
Booted on pmac32.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/kernel/of_device.c | 33 ++++++++++++++-------------------
1 file changed, 14 insertions(+), 19 deletions(-)
Index: linux-2.6/arch/powerpc/kernel/of_device.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/of_device.c
+++ linux-2.6/arch/powerpc/kernel/of_device.c
@@ -190,26 +190,21 @@ void of_release_dev(struct device *dev)
int of_device_register(struct of_device *ofdev)
{
int rc;
- struct of_device **odprop;
+ struct property *prop;
BUG_ON(ofdev->node == NULL);
- odprop = (struct of_device **)get_property(ofdev->node, "linux,device", NULL);
- if (!odprop) {
- struct property *new_prop;
-
- new_prop = kmalloc(sizeof(struct property) + sizeof(struct of_device *),
- GFP_KERNEL);
- if (new_prop == NULL)
+ prop = of_find_property(ofdev->node, "linux,device", NULL);
+ if (!prop) {
+ prop = kmalloc(sizeof(*prop) + sizeof(ofdev), GFP_KERNEL);
+ if (prop == NULL)
return -ENOMEM;
- new_prop->name = "linux,device";
- new_prop->length = sizeof(sizeof(struct of_device *));
- new_prop->value = (unsigned char *)&new_prop[1];
- odprop = (struct of_device **)new_prop->value;
- *odprop = NULL;
- prom_add_property(ofdev->node, new_prop);
+ prop->name = "linux,device";
+ prop->length = sizeof(ofdev);
+ prop->value = (unsigned char *)&prop[1];
+ prom_add_property(ofdev->node, prop);
}
- *odprop = ofdev;
+ *(struct of_device **)prop->value = ofdev;
rc = device_register(&ofdev->dev);
if (rc)
@@ -222,13 +217,13 @@ int of_device_register(struct of_device
void of_device_unregister(struct of_device *ofdev)
{
- struct of_device **odprop;
+ struct property *prop;
device_remove_file(&ofdev->dev, &dev_attr_devspec);
- odprop = (struct of_device **)get_property(ofdev->node, "linux,device", NULL);
- if (odprop)
- *odprop = NULL;
+ prop = of_find_property(ofdev->node, "linux,device", NULL);
+ if (prop)
+ prop->value = NULL;
device_unregister(&ofdev->dev);
}
^ permalink raw reply
* RE: [PATCH] Add QE device tree definition
From: Li Yang-r58472 @ 2006-06-30 3:36 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 7:55 AM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
>
> On Jun 29, 2006, at 7:53 AM, Li Yang-r58472 wrote:
>
> > This is the device tree definition for QE SOC for Freescale CPUs.
> >
> > I have discussed with Vitaly. We agreed on having CPM and QE
> > definition ultimately merged. He will add in CPM specified
> > definition later.
> >
> > Signed-off-by: Jiang Bo <Tanya.jiang@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> >
> > ---
> > Documentation/powerpc/booting-without-of.txt | 222 ++++++++++++++++
> > ++++++++++
> > 1 files changed, 222 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/powerpc/booting-without-of.txt b/
> > Documentation/powerpc/booting-without-of.txt
> > index 217e517..096063f 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -1442,6 +1442,227 @@ platforms are moved over to use the flat
> > };
> >
> >
> > + h) Freescale QUICC Engine module (QE)
> > + This represents qe module that is installed on PowerQUICC II Pro.
> > + Hopefully it will merge backward compatibility with CPM/CPM2.
> > + Basically, it is a bus of devices, that could act more or less
> > + as a complete entity (UCC, USB etc ). All of them should be
> > siblings on
> > + the "root" qe node, using the common properties from there.
> > + The description below applies to the the qe of MPC8360 and
> > + more nodes and properties would be extended in the future.
> > +
> > + 1) Root QE device
> > +
> > + Required properties:
> > + - device_type : should be "qe";
> > + - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
> > + - reg : Offset and length of the register set for the device.
> > + - bus-frequency : the clock frequency for QUICC Engine.
> > +
> > + Recommended properties
> > + - brg-frequency : the internal clock source frequency for baud-
> > rate
> > + generators in Hz.
> > +
> > + Example:
> > + qe@e0100000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + device_type = "qe";
> > + model = "QE";
> > + ranges = <0 e0100000 00100000>;
> > + reg = <e0100000 480>;
> > + brg-frequency = <0>;
> > + bus-frequency = <179A7B00>;
> > + }
> > +
> > +
> > + 2) SPI (Serial Peripheral Interface)
> > +
> > + Required properties:
> > + - device_type : should be "spi".
> > + - compatible : should be "fsl_spi".
> > + - mode : the spi operation mode, it can be "cpu" or "qe".
>
> What does it mean for the spi to be in "qe" mode?
That means:
The SPI can operate in QE mode or in CPU mode. In QE mode SPI is compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU mode, the SPI is controlled wholly by the CPU without any QE RISC intervention.
>
> > + - reg : offset to the register set and its length.
> > + - interrupts : <a b> where a is the interrupt number and b is a
> > + field that represents an encoding of the sense and level
> > + information for the interrupt. This should be encoded based on
> > + the information in section 2) depending on the type of interrupt
> > + controller you have.
> > + - interrupt-parent : the phandle for the interrupt controller that
> > + services interrupts for this device.
> > +
> > + Example:
> > + spi@4c0 {
> > + device_type = "spi";
> > + compatible = "fsl_spi";
> > + reg = <4c0 40>;
> > + interrupts = <82 0>;
> > + interrupt-parent = <700>;
> > + mode = "cpu";
> > + };
> > +
>
> How do we tell the difference between the various spi controllers. I
> think we have four of them, three of which are probably pretty
> similar. We have the 834x spi, and QE, CPM1, CPM2 SPI.
>
> > +
> > + 3) USB (Universal Serial Bus Controller)
> > +
> > + Required properties:
> > + - device_type : should be "usb".
> > + - compatible : could be "qe_udc" or "fhci-hcd".
> > + - model : the could be "host" or "slave".
>
> got a 'l' on mode, if we are slave should we provide more info about
> what kinda slave we are (ie, what gadget driver should apply).
>
> > + - reg : there will be two tuples of "address size". The first
> > tuple is
> > + offset and length of the device registers respectively; the
> > second is
> > + offset and length of the device parameter RAM respectively.
> > + - interrupts : <a b> where a is the interrupt number and b is a
> > + field that represents an encoding of the sense and level
> > + information for the interrupt. This should be encoded based on
> > + the information in section 2) depending on the type of interrupt
> > + controller you have.
> > + - interrupt-parent : the phandle for the interrupt controller that
> > + services interrupts for this device.
> > +
> > + Example(slave):
> > + usb@6c0 {
> > + device_type = "usb";
> > + compatible = "qe_udc";
> > + reg = <6c0 40 8B00 100>;
> > + interrupts = <8b 0>;
> > + interrupt-parent = <700>;
> > + mode = "slave";
> > + };
> > +
> > +
> > + 4) UCC (Unified Communications Controllers)
>
> Why dont you create a sub section for network, and in the future
> additional subsections can be added for the different device_types.
>
> > +
> > + Required properties:
> > + - device_type : should be "network", "hldc", "uart", "transparent"
> > + "bisync" or "atm".
> > + - compatible : could be "ucc_geth" or "fsl_atm" and so on.
> > + - model : should be "UCC".
> > + - device-id : the ucc number(1-8), corresponding to UCCx in UM.
> > + - reg : there will be two tuples of "address size". The first
> > tuple is
> > + offset and length of the device registers respectively; the
> > second is
> > + offset and length of the device parameter RAM respectively.
> > + - interrupts : <a b> where a is the interrupt number and b is a
> > + field that represents an encoding of the sense and level
> > + information for the interrupt. This should be encoded based on
> > + the information in section 2) depending on the type of interrupt
> > + controller you have.
> > + - interrupt-parent : the phandle for the interrupt controller that
> > + services interrupts for this device.
> > + - pio-handle : The phandle for the Parallel I/O port
> > configuration.
> > +
> > + Required properties for network device_type:
> > + - mac-address : list of bytes representing the ethernet address.
> > + - rx-clock : a string represents the UCC receive clock source.
> > + "brgx" : clock source is BRG1~BRG16 respectively;
> > + "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> > + others : clock source is disabled;
> > + - tx-clock: a string represents the UCC transmit clock source;
> > + "brgx" : clock source is BRG1~BRG16 respectively;
> > + "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> > + others : clock source is disabled;
> > + - phy-handle : The phandle for the PHY connected to this
> > controller.
> > +
> > + Example:
> > + ucc@2000 {
> > + device_type = "network";
> > + compatible = "ucc_geth";
> > + model = "UCC";
> > + device-id = <1>;
> > + reg = <2000 200 8400 100>;
> > + interrupts = <a0 0>;
> > + interrupt-parent = <700>;
> > + mac-address = [ 00 04 9f 00 23 23 ];
> > + rx-clock = "none";
> > + tx-clock = "clk9";
> > + phy-handle = <212000>;
> > + pio-handle = <140001>;
> > + };
> > +
> > +
> > + 5) Parallel I/O Ports
> > +
> > + This node configures Parallel I/O ports for CPUs with QE support.
> > + The node should reside in the "soc" node of the tree. For each
> > + device that using parallel I/O ports, a child node should be
> > created.
> > + See the definition of the Pin configuration nodes below for more
> > + information.
> > +
> > + Required properties:
> > + - device_type : should be "par_io".
> > + - reg : offset to the register set and its length.
> > +
> > + Example:
> > + par_io@1400 {
> > + reg = <1400 100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "par_io";
> > + ucc_pin@01 {
> > + ......
> > + };
> > +
>
> Can you explain this further, I'm not getting the relationship
> between a par_io & ucc_pin. An example maybe helpful.
Each QE device needs to configure Parallel I/O Ports pin configuration in order to work, for example the configuration for ucc1 is ucc_pin@01. par_io is a container for all these configurations and gives the base for parallel io port register. I will paste dts file for 8360 to give an example.
>
> > +
> > + 6) Pin configuration nodes
> > +
> > + Required properties:
> > + - linux,phandle : phandle of this node; likely referenced by a QE
> > + device.
> > + - pio-map : array of pin configurations. Each pin is defined by 6
> > + integers. The six numbers are respectively: port, pin, dir,
> > + open_drain, assignment, has_irq.
> > + - port : port number of the pin; 0-6 represent port A-G in UM.
> > + - pin : pin number in the port.
> > + - dir : direction of the pin, should encode as follows:
> > +
> > + 0 = The pin is disabled
> > + 1 = The pin is an output
> > + 2 = The pin is an input
> > + 3 = The pin is I/O
> > +
> > + - open_drain : indicates the pin is normal or wired-OR:
> > +
> > + 0 = The pin is actively driven as an output
> > + 1 = The pin is an open-drain driver. As an output, the pin is
> > + driven active-low, otherwise it is three-stated.
> > +
> > + - assignment : function number of the pin according to the
> > Pin Assignment
> > + tables in User Manual. Each pin can have up to 4 possible
> > functions in
> > + QE and two options for CPM.
> > + - has_irq : indicates if the pin is used as source of exteral
> > + interrupts.
> > +
> > + Example:
> > + ucc_pin@01 {
> > + linux,phandle = <140001>;
> > + pio-map = <
> > + /* port pin dir open_drain assignment has_irq */
> > + 0 3 1 0 1 0 /* TxD0 */
> > + 0 4 1 0 1 0 /* TxD1 */
> > + 0 5 1 0 1 0 /* TxD2 */
> > + 0 6 1 0 1 0 /* TxD3 */
> > + 1 6 1 0 3 0 /* TxD4 */
> > + 1 7 1 0 1 0 /* TxD5 */
> > + 1 9 1 0 2 0 /* TxD6 */
> > + 1 a 1 0 2 0 /* TxD7 */
> > + 0 9 2 0 1 0 /* RxD0 */
> > + 0 a 2 0 1 0 /* RxD1 */
> > + 0 b 2 0 1 0 /* RxD2 */
> > + 0 c 2 0 1 0 /* RxD3 */
> > + 0 d 2 0 1 0 /* RxD4 */
> > + 1 1 2 0 2 0 /* RxD5 */
> > + 1 0 2 0 2 0 /* RxD6 */
> > + 1 4 2 0 2 0 /* RxD7 */
> > + 0 7 1 0 1 0 /* TX_EN */
> > + 0 8 1 0 1 0 /* TX_ER */
> > + 0 f 2 0 1 0 /* RX_DV */
> > + 0 10 2 0 1 0 /* RX_ER */
> > + 0 0 2 0 1 0 /* RX_CLK */
> > + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
> > + 2 8 2 0 1 0>; /* GTX125 - CLK9 */
> > + };
> > +
> > +
> > More devices will be defined as this spec matures.
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [FYI] dts file for MPC8360EPB support
From: Li Yang-r58472 @ 2006-06-30 3:40 UTC (permalink / raw)
To: linuxppc-dev
Here is the dts file to work with the platform support patch I just posted.
---
/*
* MPC8360E PB Device Tree Source
*
* Copyright 2006 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.
*/
/*
/memreserve/ 00000000 1000000;
*/
/ {
model = "MPC8360EPB";
compatible = "MPC83xx";
#address-cells = <1>;
#size-cells = <1>;
linux,phandle = <100>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
linux,phandle = <200>;
PowerPC,8360@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 = <3EF1480>;
bus-frequency = <FBC5200>;
clock-frequency = <1F78A400>;
32-bit;
linux,phandle = <201>;
linux,boot-cpu;
};
};
memory {
device_type = "memory";
linux,phandle = <300>;
reg = <00000000 10000000>;
};
soc8360@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;
bus-frequency = <FBC5200>;
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
reg = <200 100>;
};
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 0>;
interrupt-parent = <700>;
dfsrr;
};
i2c@3100 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3100 100>;
interrupts = <f 0>;
interrupt-parent = <700>;
dfsrr;
};
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
clock-frequency = <FBC5200>;
interrupts = <9 0>;
interrupt-parent = <700>;
};
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>;
clock-frequency = <FBC5200>;
interrupts = <a 0>;
interrupt-parent = <700>;
};
crypto@30000 {
device_type = "crypto";
model = "SEC2";
compatible = "talitos";
reg = <30000 10000>;
interrupts = <b 0>;
interrupt-parent = <700>;
num-channels = <4>;
channel-fifo-len = <18>;
exec-units-mask = <0000007e>;
/* desc mask is for rev1.x, we need runtime fixup for >=2.x */
descriptor-types-mask = <01010ebf>;
};
pci@8500 {
linux,phandle = <8500>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 AD17 */
8800 0 0 1 700 14 0
8800 0 0 2 700 15 0
8800 0 0 3 700 16 0
8800 0 0 4 700 17 0
/* IDSEL 0x12 AD18 */
9000 0 0 1 700 16 0
9000 0 0 2 700 17 0
9000 0 0 3 700 14 0
9000 0 0 4 700 15 0
/* IDSEL 0x13 AD19 */
9800 0 0 1 700 17 0
9800 0 0 2 700 14 0
9800 0 0 3 700 15 0
9800 0 0 4 700 16 0
/* IDSEL 0x15 AD21*/
a800 0 0 1 700 14 0
a800 0 0 2 700 15 0
a800 0 0 3 700 16 0
a800 0 0 4 700 17 0
/* IDSEL 0x16 AD22*/
b000 0 0 1 700 17 0
b000 0 0 2 700 14 0
b000 0 0 3 700 15 0
b000 0 0 4 700 16 0
/* IDSEL 0x17 AD23*/
b800 0 0 1 700 16 0
b800 0 0 2 700 17 0
b800 0 0 3 700 14 0
b800 0 0 4 700 15 0
/* IDSEL 0x18 AD24*/
c000 0 0 1 700 15 0
c000 0 0 2 700 16 0
c000 0 0 3 700 17 0
c000 0 0 4 700 14 0>;
interrupt-parent = <700>;
interrupts = <42 0>;
bus-range = <0 0>;
ranges = <02000000 0 a0000000 a0000000 0 10000000
42000000 0 80000000 80000000 0 10000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
compatible = "83xx";
device_type = "pci";
};
// IPIC
pic@700 {
linux,phandle = <700>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <700 100>;
built-in;
device_type = "ipic";
};
par_io@1400 {
reg = <1400 100>;
device_type = "par_io";
ucc_pin@01 {
linux,phandle = <140001>;
pio-map = <
/* port pin dir open_drain assignment has_irq */
0 3 1 0 1 0 /* TxD0 */
0 4 1 0 1 0 /* TxD1 */
0 5 1 0 1 0 /* TxD2 */
0 6 1 0 1 0 /* TxD3 */
1 6 1 0 3 0 /* TxD4 */
1 7 1 0 1 0 /* TxD5 */
1 9 1 0 2 0 /* TxD6 */
1 a 1 0 2 0 /* TxD7 */
0 9 2 0 1 0 /* RxD0 */
0 a 2 0 1 0 /* RxD1 */
0 b 2 0 1 0 /* RxD2 */
0 c 2 0 1 0 /* RxD3 */
0 d 2 0 1 0 /* RxD4 */
1 1 2 0 2 0 /* RxD5 */
1 0 2 0 2 0 /* RxD6 */
1 4 2 0 2 0 /* RxD7 */
0 7 1 0 1 0 /* TX_EN */
0 8 1 0 1 0 /* TX_ER */
0 f 2 0 1 0 /* RX_DV */
0 10 2 0 1 0 /* RX_ER */
0 0 2 0 1 0 /* RX_CLK */
2 9 1 0 3 0 /* GTX_CLK - CLK10 */
2 8 2 0 1 0>; /* GTX125 - CLK9 */
};
ucc_pin@02 {
linux,phandle = <140002>;
pio-map = <
/* port pin dir open_drain assignment has_irq */
0 11 1 0 1 0 /* TxD0 */
0 12 1 0 1 0 /* TxD1 */
0 13 1 0 1 0 /* TxD2 */
0 14 1 0 1 0 /* TxD3 */
1 2 1 0 1 0 /* TxD4 */
1 3 1 0 2 0 /* TxD5 */
1 5 1 0 3 0 /* TxD6 */
1 8 1 0 3 0 /* TxD7 */
0 17 2 0 1 0 /* RxD0 */
0 18 2 0 1 0 /* RxD1 */
0 19 2 0 1 0 /* RxD2 */
0 1a 2 0 1 0 /* RxD3 */
0 1b 2 0 1 0 /* RxD4 */
1 c 2 0 2 0 /* RxD5 */
1 d 2 0 3 0 /* RxD6 */
1 b 2 0 2 0 /* RxD7 */
0 15 1 0 1 0 /* TX_EN */
0 16 1 0 1 0 /* TX_ER */
0 1d 2 0 1 0 /* RX_DV */
0 1e 2 0 1 0 /* RX_ER */
0 1f 2 0 1 0 /* RX_CLK */
2 2 1 0 2 0 /* GTX_CLK - CLK10 */
2 3 2 0 1 0 /* GTX125 - CLK4 */
0 1 3 0 2 0 /* MDIO */
0 2 1 0 1 0>; /* MDC */
};
};
};
// QE
qe@e0100000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "qe";
model = "QE";
ranges = <0 e0100000 00100000>;
reg = <e0100000 480>;
brg-frequency = <0>;
bus-frequency = <179A7B00>;
spi@4c0 {
device_type = "spi";
compatible = "fsl_spi";
reg = <4c0 40>;
interrupts = <82 0>;
interrupt-parent = <700>;
mode = "cpu";
};
spi@500 {
device_type = "spi";
compatible = "fsl_spi";
reg = <500 40>;
interrupts = <81 0>;
interrupt-parent = <700>;
mode = "cpu";
};
brg@640 {
device_type = "brg";
reg = <668 4>;
};
usb@6c0 {
device_type = "usb";
compatible = "qe_udc";
reg = <6c0 40>;
reg_pram = <8B00 100>;
interrupts = <8b 0>;
interrupt-parent = <700>;
mode = "slave";
};
ucc@2000 {
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <1>;
reg = <2000 200 8400 100>;
interrupts = <a0 0>;
interrupt-parent = <700>;
mac-address = [ 00 04 9f 00 23 23 ];
rx-clock = <0>;
tx-clock = <19>;
phy-handle = <212000>;
pio-handle = <140001>;
};
ucc@3000 {
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <2>;
reg = <3000 200 8500 100>;
interrupts = <a1 0>;
interrupt-parent = <700>;
mac-address = [ 00 11 22 33 44 55 ];
rx-clock = <0>;
tx-clock = <14>;
phy-handle = <212001>;
pio-handle = <140002>;
};
mdio@2120 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2120 18>;
device_type = "mdio";
compatible = "ucc_geth_phy";
ethernet-phy@00 {
linux,phandle = <212000>;
interrupt-parent = <700>;
interrupts = <11 1>;
reg = <0>;
device_type = "ethernet-phy";
interface = <6>; //ENET_1000_GMII
};
ethernet-phy@01 {
linux,phandle = <212001>;
interrupt-parent = <700>;
interrupts = <12 1>;
reg = <1>;
device_type = "ethernet-phy";
interface = <6>;
};
};
};
};
--
Leo Li
Freescale Semiconductor
LeoLi@freescale.com
^ permalink raw reply
* Re: [PATCH] Add QE device tree definition
From: Kumar Gala @ 2006-06-30 4:10 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FE7@zch01exm40.ap.freescale.net>
[snip]
>>> + 2) SPI (Serial Peripheral Interface)
>>> +
>>> + Required properties:
>>> + - device_type : should be "spi".
>>> + - compatible : should be "fsl_spi".
>>> + - mode : the spi operation mode, it can be "cpu" or "qe".
>>
>> What does it mean for the spi to be in "qe" mode?
> That means:
> The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> mode, the SPI is controlled wholly by the CPU without any QE RISC
> intervention.
In QE mode does software get involved at all?
>>> + - reg : offset to the register set and its length.
>>> + - interrupts : <a b> where a is the interrupt number and b is a
>>> + field that represents an encoding of the sense and level
>>> + information for the interrupt. This should be encoded
>>> based on
>>> + the information in section 2) depending on the type of
>>> interrupt
>>> + controller you have.
>>> + - interrupt-parent : the phandle for the interrupt controller
>>> that
>>> + services interrupts for this device.
>>> +
>>> + Example:
>>> + spi@4c0 {
>>> + device_type = "spi";
>>> + compatible = "fsl_spi";
>>> + reg = <4c0 40>;
>>> + interrupts = <82 0>;
>>> + interrupt-parent = <700>;
>>> + mode = "cpu";
>>> + };
>>> +
[snip]
>>> + 5) Parallel I/O Ports
>>> +
>>> + This node configures Parallel I/O ports for CPUs with QE
>>> support.
>>> + The node should reside in the "soc" node of the tree. For each
>>> + device that using parallel I/O ports, a child node should be
>>> created.
>>> + See the definition of the Pin configuration nodes below for more
>>> + information.
>>> +
>>> + Required properties:
>>> + - device_type : should be "par_io".
>>> + - reg : offset to the register set and its length.
>>> +
>>> + Example:
>>> + par_io@1400 {
>>> + reg = <1400 100>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + device_type = "par_io";
>>> + ucc_pin@01 {
>>> + ......
>>> + };
>>> +
>>
>> Can you explain this further, I'm not getting the relationship
>> between a par_io & ucc_pin. An example maybe helpful.
>
> Each QE device needs to configure Parallel I/O Ports pin
> configuration in order to work, for example the configuration for
> ucc1 is ucc_pin@01. par_io is a container for all these
> configurations and gives the base for parallel io port register. I
> will paste dts file for 8360 to give an example.
Maybe its the name that's confusing me, ucc_pin@01 describes what
exactly? A single pin? or all the pin configs for ucc 1?
>>> +
>>> + 6) Pin configuration nodes
>>> +
>>> + Required properties:
>>> + - linux,phandle : phandle of this node; likely referenced by
>>> a QE
>>> + device.
>>> + - pio-map : array of pin configurations. Each pin is defined
>>> by 6
>>> + integers. The six numbers are respectively: port, pin, dir,
>>> + open_drain, assignment, has_irq.
>>> + - port : port number of the pin; 0-6 represent port A-G in UM.
>>> + - pin : pin number in the port.
>>> + - dir : direction of the pin, should encode as follows:
>>> +
>>> + 0 = The pin is disabled
>>> + 1 = The pin is an output
>>> + 2 = The pin is an input
>>> + 3 = The pin is I/O
>>> +
>>> + - open_drain : indicates the pin is normal or wired-OR:
>>> +
>>> + 0 = The pin is actively driven as an output
>>> + 1 = The pin is an open-drain driver. As an output, the pin is
>>> + driven active-low, otherwise it is three-stated.
>>> +
>>> + - assignment : function number of the pin according to the
>>> Pin Assignment
>>> + tables in User Manual. Each pin can have up to 4 possible
>>> functions in
>>> + QE and two options for CPM.
>>> + - has_irq : indicates if the pin is used as source of exteral
>>> + interrupts.
>>> +
>>> + Example:
>>> + ucc_pin@01 {
>>> + linux,phandle = <140001>;
>>> + pio-map = <
>>> + /* port pin dir open_drain assignment has_irq */
>>> + 0 3 1 0 1 0 /* TxD0 */
>>> + 0 4 1 0 1 0 /* TxD1 */
>>> + 0 5 1 0 1 0 /* TxD2 */
>>> + 0 6 1 0 1 0 /* TxD3 */
>>> + 1 6 1 0 3 0 /* TxD4 */
>>> + 1 7 1 0 1 0 /* TxD5 */
>>> + 1 9 1 0 2 0 /* TxD6 */
>>> + 1 a 1 0 2 0 /* TxD7 */
>>> + 0 9 2 0 1 0 /* RxD0 */
>>> + 0 a 2 0 1 0 /* RxD1 */
>>> + 0 b 2 0 1 0 /* RxD2 */
>>> + 0 c 2 0 1 0 /* RxD3 */
>>> + 0 d 2 0 1 0 /* RxD4 */
>>> + 1 1 2 0 2 0 /* RxD5 */
>>> + 1 0 2 0 2 0 /* RxD6 */
>>> + 1 4 2 0 2 0 /* RxD7 */
>>> + 0 7 1 0 1 0 /* TX_EN */
>>> + 0 8 1 0 1 0 /* TX_ER */
>>> + 0 f 2 0 1 0 /* RX_DV */
>>> + 0 10 2 0 1 0 /* RX_ER */
>>> + 0 0 2 0 1 0 /* RX_CLK */
>>> + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
>>> + 2 8 2 0 1 0>; /* GTX125 - CLK9 */
>>> + };
>>> +
>>> +
>>> More devices will be defined as this spec matures.
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [FYI] dts file for MPC8360EPB support
From: Kumar Gala @ 2006-06-30 4:11 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FE8@zch01exm40.ap.freescale.net>
> // QE
> qe@e0100000 {
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <2>;
> device_type = "qe";
> model = "QE";
> ranges = <0 e0100000 00100000>;
> reg = <e0100000 480>;
> brg-frequency = <0>;
> bus-frequency = <179A7B00>;
>
> spi@4c0 {
> device_type = "spi";
> compatible = "fsl_spi";
> reg = <4c0 40>;
> interrupts = <82 0>;
> interrupt-parent = <700>;
> mode = "cpu";
> };
>
> spi@500 {
> device_type = "spi";
> compatible = "fsl_spi";
> reg = <500 40>;
> interrupts = <81 0>;
> interrupt-parent = <700>;
> mode = "cpu";
> };
>
> brg@640 {
> device_type = "brg";
> reg = <668 4>;
> };
brg isn't described in your patch to the flat dev tree spec.
>
> usb@6c0 {
> device_type = "usb";
> compatible = "qe_udc";
> reg = <6c0 40>;
> reg_pram = <8B00 100>;
> interrupts = <8b 0>;
> interrupt-parent = <700>;
> mode = "slave";
> };
>
> ucc@2000 {
> device_type = "network";
> compatible = "ucc_geth";
> model = "UCC";
> device-id = <1>;
> reg = <2000 200 8400 100>;
> interrupts = <a0 0>;
> interrupt-parent = <700>;
> mac-address = [ 00 04 9f 00 23 23 ];
> rx-clock = <0>;
> tx-clock = <19>;
> phy-handle = <212000>;
> pio-handle = <140001>;
> };
>
> ucc@3000 {
> device_type = "network";
> compatible = "ucc_geth";
> model = "UCC";
> device-id = <2>;
> reg = <3000 200 8500 100>;
> interrupts = <a1 0>;
> interrupt-parent = <700>;
> mac-address = [ 00 11 22 33 44 55 ];
> rx-clock = <0>;
> tx-clock = <14>;
> phy-handle = <212001>;
> pio-handle = <140002>;
> };
>
> mdio@2120 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <2120 18>;
> device_type = "mdio";
> compatible = "ucc_geth_phy";
>
> ethernet-phy@00 {
> linux,phandle = <212000>;
> interrupt-parent = <700>;
> interrupts = <11 1>;
> reg = <0>;
> device_type = "ethernet-phy";
> interface = <6>; //ENET_1000_GMII
> };
> ethernet-phy@01 {
> linux,phandle = <212001>;
> interrupt-parent = <700>;
> interrupts = <12 1>;
> reg = <1>;
> device_type = "ethernet-phy";
> interface = <6>;
> };
> };
>
> };
> };
>
>
> --
> Leo Li
> Freescale Semiconductor
>
> LeoLi@freescale.com
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/3] Add support for the Freescale MPC8349E-mITX eval board
From: Kumar Gala @ 2006-06-30 4:32 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060629140217.4a07f05a.kim.phillips@freescale.com>
On Jun 29, 2006, at 2:02 PM, Kim Phillips wrote:
> On Thu, 29 Jun 2006 11:38:04 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>>
>>> It removes rtc chip-specific code from the platform code. It
>>> accomplishes this by using the new "RTC-framework" glue.
>>
>> I'm aware of the new RTC framework.
>>
>> This code seems pretty generic for any RTC using the new framework.
>> If so, we should put it somewhere more generic like setup.c
>>
> yeah, I'd like to clean up some more of the existing rtc specific
> code and do that in one fell swoop..
well we can drop the rtc code for now and get the ITX base into the
tree.
>>> <snip>
>>>>> diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h
>>>>> index 02ed2c3..80076be 100644
>>>>> --- a/include/asm-ppc/mpc83xx.h
>>>>> +++ b/include/asm-ppc/mpc83xx.h
>>>>> @@ -25,6 +25,10 @@
>>>>> #include <platforms/83xx/mpc834x_sys.h>
>>>>> #endif
>>>>>
>>>>> +#ifdef CONFIG_MPC834x_ITX
>>>>> +#include <platforms/83xx/mpc834x_itx.h>
>>>>> +#endif
>>>>> +
>>>>
>>>> This shouldn't be needed, its a hold over from arch/ppc
>>>>
>>> Unfortunately it won't build without it.
>>
>> What's the build error?
>>
> ..
> CC arch/powerpc/platforms/83xx/mpc834x_itx.o
> arch/powerpc/platforms/83xx/mpc834x_itx.c: In function
> `mpc83xx_map_irq':
> arch/powerpc/platforms/83xx/mpc834x_itx.c:57: error: `PIRQB'
> undeclared (first use in this function)
> ..
Include the header in mpc834x_itc.c since its what's using it.
- k
^ permalink raw reply
* Re: [PATCH] todc: add support for Time-Of-Day-Clock
From: Kumar Gala @ 2006-06-30 4:34 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list, Kim Phillips, Paul Mackerras
In-Reply-To: <20060628211320.GA13257@mag.az.mvista.com>
On Jun 28, 2006, at 4:13 PM, Mark A. Greer wrote:
> This is a resubmit with a proper subject and with all comments
> addressed.
> Applies cleanly to powerpc.git
> 649e85797259162f7fdc696420e7492f20226f2d
>
> Mark
> --
>
> The todc code from arch/ppc supports many todc/rtc chips and is needed
> in arch/powerpc. This patch adds the todc code to arch/powerpc.
>
> Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Just noticed this and was wondering if you have looked at the new RTC
subsystem and if we can move any of this over to use that?
Kim has a patch for the MPC834x ITC board that appear to provide a
generic implementations of ppc_md.set_rtc_time, ppc.get_rtc_time
using the RTC class code.
- k
^ permalink raw reply
* RE: [FYI] dts file for MPC8360EPB support
From: Li Yang-r58472 @ 2006-06-30 4:46 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
Best Regards,
Leo
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 12:12 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [FYI] dts file for MPC8360EPB support
>
>
> > // QE
> > qe@e0100000 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <2>;
> > device_type = "qe";
> > model = "QE";
> > ranges = <0 e0100000 00100000>;
> > reg = <e0100000 480>;
> > brg-frequency = <0>;
> > bus-frequency = <179A7B00>;
> >
> > spi@4c0 {
> > device_type = "spi";
> > compatible = "fsl_spi";
> > reg = <4c0 40>;
> > interrupts = <82 0>;
> > interrupt-parent = <700>;
> > mode = "cpu";
> > };
> >
> > spi@500 {
> > device_type = "spi";
> > compatible = "fsl_spi";
> > reg = <500 40>;
> > interrupts = <81 0>;
> > interrupt-parent = <700>;
> > mode = "cpu";
> > };
> >
> > brg@640 {
> > device_type = "brg";
> > reg = <668 4>;
> > };
>
> brg isn't described in your patch to the flat dev tree spec.
After discussion with Vitaly, I removed it from the spec as it is not used currently. We will add it in, when it is necessary. I forgot to update my dts file though :)
>
> >
> > usb@6c0 {
> > device_type = "usb";
> > compatible = "qe_udc";
> > reg = <6c0 40>;
> > reg_pram = <8B00 100>;
> > interrupts = <8b 0>;
> > interrupt-parent = <700>;
> > mode = "slave";
> > };
> >
> > ucc@2000 {
> > device_type = "network";
> > compatible = "ucc_geth";
> > model = "UCC";
> > device-id = <1>;
> > reg = <2000 200 8400 100>;
> > interrupts = <a0 0>;
> > interrupt-parent = <700>;
> > mac-address = [ 00 04 9f 00 23 23 ];
> > rx-clock = <0>;
> > tx-clock = <19>;
> > phy-handle = <212000>;
> > pio-handle = <140001>;
> > };
> >
> > ucc@3000 {
> > device_type = "network";
> > compatible = "ucc_geth";
> > model = "UCC";
> > device-id = <2>;
> > reg = <3000 200 8500 100>;
> > interrupts = <a1 0>;
> > interrupt-parent = <700>;
> > mac-address = [ 00 11 22 33 44 55 ];
> > rx-clock = <0>;
> > tx-clock = <14>;
> > phy-handle = <212001>;
> > pio-handle = <140002>;
> > };
> >
> > mdio@2120 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <2120 18>;
> > device_type = "mdio";
> > compatible = "ucc_geth_phy";
> >
> > ethernet-phy@00 {
> > linux,phandle = <212000>;
> > interrupt-parent = <700>;
> > interrupts = <11 1>;
> > reg = <0>;
> > device_type = "ethernet-phy";
> > interface = <6>; //ENET_1000_GMII
> > };
> > ethernet-phy@01 {
> > linux,phandle = <212001>;
> > interrupt-parent = <700>;
> > interrupts = <12 1>;
> > reg = <1>;
> > device_type = "ethernet-phy";
> > interface = <6>;
> > };
> > };
> >
> > };
> > };
> >
> >
> > --
> > Leo Li
> > Freescale Semiconductor
> >
> > LeoLi@freescale.com
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH] Add QE device tree definition
From: Li Yang-r58472 @ 2006-06-30 4:52 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 12:11 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
> [snip]
>
> >>> + 2) SPI (Serial Peripheral Interface)
> >>> +
> >>> + Required properties:
> >>> + - device_type : should be "spi".
> >>> + - compatible : should be "fsl_spi".
> >>> + - mode : the spi operation mode, it can be "cpu" or "qe".
> >>
> >> What does it mean for the spi to be in "qe" mode?
> > That means:
> > The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> > compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> > mode, the SPI is controlled wholly by the CPU without any QE RISC
> > intervention.
>
> In QE mode does software get involved at all?
Yes, of course. The driver needs to do initialization, and deal with the BDs.
>
> >>> + - reg : offset to the register set and its length.
> >>> + - interrupts : <a b> where a is the interrupt number and b is a
> >>> + field that represents an encoding of the sense and level
> >>> + information for the interrupt. This should be encoded
> >>> based on
> >>> + the information in section 2) depending on the type of
> >>> interrupt
> >>> + controller you have.
> >>> + - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> + services interrupts for this device.
> >>> +
> >>> + Example:
> >>> + spi@4c0 {
> >>> + device_type = "spi";
> >>> + compatible = "fsl_spi";
> >>> + reg = <4c0 40>;
> >>> + interrupts = <82 0>;
> >>> + interrupt-parent = <700>;
> >>> + mode = "cpu";
> >>> + };
> >>> +
>
> [snip]
>
> >>> + 5) Parallel I/O Ports
> >>> +
> >>> + This node configures Parallel I/O ports for CPUs with QE
> >>> support.
> >>> + The node should reside in the "soc" node of the tree. For each
> >>> + device that using parallel I/O ports, a child node should be
> >>> created.
> >>> + See the definition of the Pin configuration nodes below for more
> >>> + information.
> >>> +
> >>> + Required properties:
> >>> + - device_type : should be "par_io".
> >>> + - reg : offset to the register set and its length.
> >>> +
> >>> + Example:
> >>> + par_io@1400 {
> >>> + reg = <1400 100>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + device_type = "par_io";
> >>> + ucc_pin@01 {
> >>> + ......
> >>> + };
> >>> +
> >>
> >> Can you explain this further, I'm not getting the relationship
> >> between a par_io & ucc_pin. An example maybe helpful.
> >
> > Each QE device needs to configure Parallel I/O Ports pin
> > configuration in order to work, for example the configuration for
> > ucc1 is ucc_pin@01. par_io is a container for all these
> > configurations and gives the base for parallel io port register. I
> > will paste dts file for 8360 to give an example.
>
> Maybe its the name that's confusing me, ucc_pin@01 describes what
> exactly? A single pin? or all the pin configs for ucc 1?
All pin configs to ucc1.
Could you suggest a more proper name?
>
> >>> +
> >>> + 6) Pin configuration nodes
> >>> +
> >>> + Required properties:
> >>> + - linux,phandle : phandle of this node; likely referenced by
> >>> a QE
> >>> + device.
> >>> + - pio-map : array of pin configurations. Each pin is defined
> >>> by 6
> >>> + integers. The six numbers are respectively: port, pin, dir,
> >>> + open_drain, assignment, has_irq.
> >>> + - port : port number of the pin; 0-6 represent port A-G in UM.
> >>> + - pin : pin number in the port.
> >>> + - dir : direction of the pin, should encode as follows:
> >>> +
> >>> + 0 = The pin is disabled
> >>> + 1 = The pin is an output
> >>> + 2 = The pin is an input
> >>> + 3 = The pin is I/O
> >>> +
> >>> + - open_drain : indicates the pin is normal or wired-OR:
> >>> +
> >>> + 0 = The pin is actively driven as an output
> >>> + 1 = The pin is an open-drain driver. As an output, the pin is
> >>> + driven active-low, otherwise it is three-stated.
> >>> +
> >>> + - assignment : function number of the pin according to the
> >>> Pin Assignment
> >>> + tables in User Manual. Each pin can have up to 4 possible
> >>> functions in
> >>> + QE and two options for CPM.
> >>> + - has_irq : indicates if the pin is used as source of exteral
> >>> + interrupts.
> >>> +
> >>> + Example:
> >>> + ucc_pin@01 {
> >>> + linux,phandle = <140001>;
> >>> + pio-map = <
> >>> + /* port pin dir open_drain assignment has_irq */
> >>> + 0 3 1 0 1 0 /* TxD0 */
> >>> + 0 4 1 0 1 0 /* TxD1 */
> >>> + 0 5 1 0 1 0 /* TxD2 */
> >>> + 0 6 1 0 1 0 /* TxD3 */
> >>> + 1 6 1 0 3 0 /* TxD4 */
> >>> + 1 7 1 0 1 0 /* TxD5 */
> >>> + 1 9 1 0 2 0 /* TxD6 */
> >>> + 1 a 1 0 2 0 /* TxD7 */
> >>> + 0 9 2 0 1 0 /* RxD0 */
> >>> + 0 a 2 0 1 0 /* RxD1 */
> >>> + 0 b 2 0 1 0 /* RxD2 */
> >>> + 0 c 2 0 1 0 /* RxD3 */
> >>> + 0 d 2 0 1 0 /* RxD4 */
> >>> + 1 1 2 0 2 0 /* RxD5 */
> >>> + 1 0 2 0 2 0 /* RxD6 */
> >>> + 1 4 2 0 2 0 /* RxD7 */
> >>> + 0 7 1 0 1 0 /* TX_EN */
> >>> + 0 8 1 0 1 0 /* TX_ER */
> >>> + 0 f 2 0 1 0 /* RX_DV */
> >>> + 0 10 2 0 1 0 /* RX_ER */
> >>> + 0 0 2 0 1 0 /* RX_CLK */
> >>> + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
> >>> + 2 8 2 0 1 0>; /* GTX125 - CLK9 */
> >>> + };
> >>> +
> >>> +
> >>> More devices will be defined as this spec matures.
> >>>
> >>>
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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