* 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
* Re: new IRQ work status
From: Bob Brose @ 2006-06-30 4:57 UTC (permalink / raw)
To: linuxppc-dev
Ben Said:
>
> Here's a progress report on my new irq management work.
.
.
> validate as much as the core as possible. I still need to port over chrp
> and maple which are easy, and powermac which will be a bit more
> difficult as it relies a lot more on intrs/n_intrs in the device-nodes
> which I've now removed.
>
> Hopefully, it should be finished this week. The current serie of patch
> applies on top of 2.6.17-mm1. I will do a version on top of the powerpc
> tree as soon as the genirq port is upstream (which hopefully should
> happen soon, possibly tomorrow).
.
.
> Comments welcome.
Any chance you can fix the 6 slot S900 irq problem when you do the powermac
changes??
Bob
^ permalink raw reply
* Re: [PATCH] Add QE device tree definition
From: Kumar Gala @ 2006-06-30 5:09 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FEA@zch01exm40.ap.freescale.net>
On Jun 29, 2006, at 11:52 PM, Li Yang-r58472 wrote:
>> -----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.
So what exactly does the QE do in this 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";
>>>>> + };
>>>>> +
>>
>> [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?
Let me think on this now that I understand what's going on.
- k
^ permalink raw reply
* RE: [PATCH] Add QE device tree definition
From: Li Yang-r58472 @ 2006-06-30 5:28 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, June 30, 2006 1:10 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
>
> On Jun 29, 2006, at 11:52 PM, Li Yang-r58472 wrote:
>
> >> -----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.
>
> So what exactly does the QE do in this mode?
Just like CPM. Driver only deal with buffer and buffer descriptor. And QE will take care of the other things.
While in CPU mode, it is up to the CPU to pack and unpack the receive/transmit frames. And tx/rx through data registers.
>
> >>>>> + - 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?
>
> Let me think on this now that I understand what's going on.
>
> - k
^ permalink raw reply
* Re: [PATCH] Add QE device tree definition
From: Kumar Gala @ 2006-06-30 5:37 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FEB@zch01exm40.ap.freescale.net>
>>>>
>>>>>>> + 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.
>>
>> So what exactly does the QE do in this mode?
>
> Just like CPM. Driver only deal with buffer and buffer
> descriptor. And QE will take care of the other things.
> While in CPU mode, it is up to the CPU to pack and unpack the
> receive/transmit frames. And tx/rx through data registers.
Ohh, so CPU mode matches the 834x then, and QE mode matches 82xx/CPM.
Has anyone looked at extending the 834x driver that is in the tree
now for using descriptors for QE/82xx?
- k
^ permalink raw reply
* Re: [PATCH] [powerpc] cleanup of_device_(un)register
From: Jeremy Kerr @ 2006-06-30 6:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1151636581.762717.409507295266.qpush@pokey>
> of_device_register() and of_device_unregister() modify the contents
> of property values, so use of_find_property rather than get_property.
OK, looks like nothing else in the kernel uses the linux,device
property, and seeing as it's a kernel pointer, it's kinda useless to
userspace.
Anyone mind if I remove the linux,device property completely?
Jeremy
^ permalink raw reply
* RE: SMC1 serial port blocks
From: Martin Krause @ 2006-06-30 6:34 UTC (permalink / raw)
To: tauanna; +Cc: linuxppc-embedded
In-Reply-To: <29672631.1151616571867.JavaMail.root@ps18>
Hi,
linuxppc-embedded-bounces+martin.krause=3Dtqs.de@ozlabs.org wrote on
Thursday, June 29, 2006 11:30 PM:=20
> 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.
Are you really sure, you don't use handshaking? You could try to connect
your boxes via three signal lines only: RxD, TxD and GND. This should
ensure that no (hardware) handshaking is involved.
Martin
^ permalink raw reply
* "boot: mem=1024M" causes only one CPU is brought up in 2.6.17-mm4
From: Raid Cheng @ 2006-06-30 7:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
I installed latest mm kernel 2.6.17-mm4 on ppc64 with RHEL4-U3.
When i tried to limit the memory to 1024M by modifying yaboot.conf or
typing on the boot line, I found some error messages in dmesg log
and only one CPU is brought up by checking /proc/cpuinfo.
But if i boot the kernel without such "mem=1024M" limitation, all 8 CPUs
will be show in /proc/cpuinfo
I have seen this issue both with mm1,mm2,mm3 and mm4.
The error message printed by xmon is like (will repeat for cpu1 - cpu7):
-------------------------------------------------------------------------------------------------------
cpu 0x1: Vector: 300 (Data Access) at [c00000000ffbed10]
pc: 00000000000104dc
lr: 000000000000830c
sp: c00000000ffbef90
msr: 8000000000001000
dar: c00000000ffbef88
dsisr: a000000
current = 0xc000000002683820
paca = 0xc00000000055f080
pid = 0, comm = swapper
WARNING: exception is not recoverable, can't continue
Unable to handle kernel paging request for data at address 0xc00000000ffbef88
Faulting instruction address: 0x000104dc
[-- Attachment #2: dmesg.2.6.17-mm4.log --]
[-- Type: application/octet-stream, Size: 12603 bytes --]
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found initrd at 0xc000000002500000:0xc0000000025dc000
Partition configured for 8 cpus.
Starting Linux PPC64 #1 SMP Tue Jun 27 01:56:47 EDT 2006
-----------------------------------------------------
ppc64_pft_size = 0x1b
ppc64_interrupt_controller = 0x2
physicalMemorySize = 0x40000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0x0000000000000000
htab_hash_mask = 0xfffff
-----------------------------------------------------
Linux version 2.6.17-mm4 (root@wakashi) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)) #1 SMP Tue Jun 27 01:56:47 EDT 2006
[boot]0012 Setup Arch
Node 0 Memory: 0x0-0x40000000
Node 1 Memory:
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Using dedicated idle loop
On node 0 totalpages: 262144
DMA zone: 262144 pages, LIFO batch:31
On node 1 totalpages: 0
[boot]0015 Setup Done
Built 2 zonelists. Total pages: 262144
Kernel command line: ro console=hvc0 rhgb quiet root=LABEL=/ mem=1024M
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 188.047000 MHz
time_init: processor frequency = 1504.376000 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
freeing bootmem node 0
Memory: 1014324k/1048576k available (5360k kernel code, 34252k reserved, 2032k data, 569k bss, 264k init)
Calibrating delay loop... 375.80 BogoMIPS (lpj=751616)
Mount-cache hash table entries: 256
Unable to handle kernel paging request for data at address 0xc00000000ffbef88
Faulting instruction address: 0x000104dc
Processor 1 is stuck.
Unable to handle kernel paging request for data at address 0xc00000000ffbdf88
Faulting instruction address: 0x000104dc
Processor 2 is stuck.
Unable to handle kernel paging request for data at address 0xc00000000ffbcf88
Faulting instruction address: 0x000104dc
Processor 3 is stuck.
Unable to handle kernel paging request for data at address 0xc00000000ffbbf88
Faulting instruction address: 0x000104dc
Processor 4 is stuck.
Unable to handle kernel paging request for data at address 0xc00000000ffbaf88
Faulting instruction address: 0x000104dc
Processor 5 is stuck.
Unable to handle kernel paging request for data at address 0xc00000000ffb9f88
Faulting instruction address: 0x000104dc
Processor 6 is stuck.
Unable to handle kernel paging request for data at address 0xc00000000ffb8f88
Faulting instruction address: 0x000104dc
Processor 7 is stuck.
Brought up 1 CPUs
Node 0 CPUs: 0
Node 1 CPUs:
migration_cost=0
checking if image is initramfs... it is
Freeing initrd memory: 880k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging enabled
mapping IO 3fe00200000 -> d000080000000000, size: 100000
mapping IO 3fe00700000 -> d000080000100000, size: 100000
PCI: Probing PCI hardware done
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
vio_bus_init: processing c00000003fffa138
vio_bus_init: processing c00000003fffa300
vio_bus_init: processing c00000003fffa448
vio_bus_init: processing c00000003fffa5b0
RTAS daemon started
RTAS: event: 23, Type: Platform Error, Severity: 2
audit: initializing netlink socket (disabled)
audit(1151383045.640:1): initialized
Total HugeTLB memory allocated, 0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.0.38-k4
Copyright (c) 1999-2006 Intel Corporation.
PCI: Enabling device: (0001:c8:01.0), cmd 143
e1000: 0001:c8:01.0: e1000_probe: (PCI-X:133MHz:64-bit) 00:02:55:2f:ee:ba
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
PCI: Enabling device: (0001:c8:01.1), cmd 143
e1000: 0001:c8:01.1: e1000_probe: (PCI-X:133MHz:64-bit) 00:02:55:2f:ee:bb
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
pcnet32.c:v1.32 18.Mar.2006 tsbogend@alpha.franken.de
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03
vio_register_driver: driver ibmveth registering
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
st: Version 20050830, fixed bufsize 32768, s/g segs 256
PCI: Enabling device: (0000:c8:01.2), cmd 142
ehci_hcd 0000:c8:01.2: EHCI Host Controller
ehci_hcd 0000:c8:01.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:c8:01.2: irq 133, io mem 0x400b8002000
ehci_hcd 0000:c8:01.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.17-mm4 ehci_hcd
usb usb1: SerialNumber: 0000:c8:01.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd 0000:c8:01.0: OHCI Host Controller
ohci_hcd 0000:c8:01.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:c8:01.0: irq 133, io mem 0x400b8001000
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.17-mm4 ohci_hcd
usb usb2: SerialNumber: 0000:c8:01.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:c8:01.1: OHCI Host Controller
ohci_hcd 0000:c8:01.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:c8:01.1: irq 133, io mem 0x400b8000000
usb usb3: new device found, idVendor=0000, idProduct=0000
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.17-mm4 ohci_hcd
usb usb3: SerialNumber: 0000:c8:01.1
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
device-mapper: ioctl: 4.8.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
oprofile: using ppc64/power5 performance monitoring.
Netfilter messages via NETLINK v0.30.
IPv4 over IPv4 tunneling driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 264k freed
ipr: IBM Power RAID SCSI Device Driver version: 2.1.3 (March 29, 2006)
ipr 0001:d0:01.0: Found IOA with IRQ: 167
ipr 0001:d0:01.0: Starting IOA initialization sequence.
ipr 0001:d0:01.0: Adapter firmware version: 020A005C
ipr 0001:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
Vendor: IBM H0 Model: HUS103036FL3800 Rev: RPQF
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
sda: Mode Sense: d3 00 10 08
SCSI device sda: drive cache: write through w/ FUA
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
sda: Mode Sense: d3 00 10 08
SCSI device sda: drive cache: write through w/ FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:3:0: Attached scsi disk sda
sd 0:0:3:0: Attached scsi generic sg0 type 0
Vendor: IBM H0 Model: HUS103036FL3800 Rev: RPQF
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
sdb: Mode Sense: d3 00 10 08
SCSI device sdb: drive cache: write through w/ FUA
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
sdb: Mode Sense: d3 00 10 08
SCSI device sdb: drive cache: write through w/ FUA
sdb: unknown partition table
sd 0:0:4:0: Attached scsi disk sdb
sd 0:0:4:0: Attached scsi generic sg1 type 0
Vendor: IBM H0 Model: HUS103036FL3800 Rev: RPQF
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sdc: 71096640 512-byte hdwr sectors (36401 MB)
sdc: Write Protect is off
sdc: Mode Sense: d3 00 10 08
SCSI device sdc: drive cache: write through w/ FUA
SCSI device sdc: 71096640 512-byte hdwr sectors (36401 MB)
sdc: Write Protect is off
sdc: Mode Sense: d3 00 10 08
SCSI device sdc: drive cache: write through w/ FUA
sdc: sdc1 sdc2 sdc3 sdc4
sd 0:0:5:0: Attached scsi disk sdc
sd 0:0:5:0: Attached scsi generic sg2 type 0
Vendor: IBM H0 Model: HUS103036FL3800 Rev: RPQF
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sdd: 71096640 512-byte hdwr sectors (36401 MB)
sdd: Write Protect is off
sdd: Mode Sense: d3 00 10 08
SCSI device sdd: drive cache: write through w/ FUA
SCSI device sdd: 71096640 512-byte hdwr sectors (36401 MB)
sdd: Write Protect is off
sdd: Mode Sense: d3 00 10 08
SCSI device sdd: drive cache: write through w/ FUA
sdd: sdd1 sdd2 sdd3 sdd4
sd 0:0:8:0: Attached scsi disk sdd
sd 0:0:8:0: Attached scsi generic sg3 type 0
Vendor: IBM Model: VSBPD4E1 U4SCSI Rev: 4770
Type: Enclosure ANSI SCSI revision: 02
scsi 0:0:15:0: Attached scsi generic sg4 type 13
Vendor: IBM H0 Model: ST336753LC Rev: C51C
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sde: 71096640 512-byte hdwr sectors (36401 MB)
sde: Write Protect is off
sde: Mode Sense: cb 00 10 08
SCSI device sde: drive cache: write through w/ FUA
SCSI device sde: 71096640 512-byte hdwr sectors (36401 MB)
sde: Write Protect is off
sde: Mode Sense: cb 00 10 08
SCSI device sde: drive cache: write through w/ FUA
sde:
sd 0:1:5:0: Attached scsi disk sde
sd 0:1:5:0: Attached scsi generic sg5 type 0
Vendor: IBM H0 Model: HUS103014FL3800 Rev: RPQF
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sdf: 286748000 512-byte hdwr sectors (146815 MB)
sdf: Write Protect is off
sdf: Mode Sense: d3 00 10 08
SCSI device sdf: drive cache: write through w/ FUA
SCSI device sdf: 286748000 512-byte hdwr sectors (146815 MB)
sdf: Write Protect is off
sdf: Mode Sense: d3 00 10 08
SCSI device sdf: drive cache: write through w/ FUA
sdf:
sd 0:1:8:0: Attached scsi disk sdf
sd 0:1:8:0: Attached scsi generic sg6 type 0
Vendor: IBM Model: VSBPD4E1 U4SCSI Rev: 4770
Type: Enclosure ANSI SCSI revision: 02
scsi 0:1:15:0: Attached scsi generic sg7 type 13
scsi: unknown device type 31
Vendor: IBM Model: 570B001 Rev: 0150
Type: Unknown ANSI SCSI revision: 00
scsi 0:255:255:255: Attached scsi generic sg8 type 31
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Floppy drive(s): fd0 is 2.88M
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on sda4, internal journal
device-mapper: multipath: version 1.0.5 loaded
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
^ permalink raw reply
* Re: new IRQ work status
From: Benjamin Herrenschmidt @ 2006-06-30 7:45 UTC (permalink / raw)
To: Bob Brose; +Cc: linuxppc-dev
In-Reply-To: <20060630045711.21347.qmail@kunk.qbjnet.com>
On Fri, 2006-06-30 at 04:57 +0000, Bob Brose wrote:
> Ben Said:
> >
> > Here's a progress report on my new irq management work.
> .
> .
> > validate as much as the core as possible. I still need to port over chrp
> > and maple which are easy, and powermac which will be a bit more
> > difficult as it relies a lot more on intrs/n_intrs in the device-nodes
> > which I've now removed.
> >
> > Hopefully, it should be finished this week. The current serie of patch
> > applies on top of 2.6.17-mm1. I will do a version on top of the powerpc
> > tree as soon as the genirq port is upstream (which hopefully should
> > happen soon, possibly tomorrow).
> .
> .
> > Comments welcome.
>
> Any chance you can fix the 6 slot S900 irq problem when you do the powermac
> changes??
I'll look at it after I have done the initial set of patches... it's a
bug fix so there is a bit less hurry for 2.6.18 merge window
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox