LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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

* new irq works status (#2)
From: Benjamin Herrenschmidt @ 2006-06-30  7:50 UTC (permalink / raw)
  To: linuxppc-dev

I uploaded a new version at http://gate.crashing.org/~benh/irq-WIP/

This one applies on top of a linus git checkout from today and thus
should also apply on top of a recent powerpc.git tree. It contains
various fixes & cleanups over the previous ones, significant fixes in
the mpic code (mpic based pseries work now) and powermac 64 bits is
ported over.

Remaining bits are:

 - PowerMac 32 bits. There is a bit of work to replace the old
workarounds for broken device-trees
   here, those used to be done by changing device_node->intrs which is
now gone
 - Maple (should be trivial, +/- a small nit for some SLOF version)
 - CHRP (should be really trivial :) Just need to be careful of Pegasos
lack of a valid
   interrupt-tree and properly default to the PCI_INTERRUPT_LINE config
space register
   in that case, which shall match 8259 interrupts
 - embedded6xx/* platforms. I'll leave the pleasure of fixing these to
the maintainers for now 
   unless I decide to beat them to it, but since I'm not too familiar,
I'd rather have them do
   the job. It should be fairly trivial to just make them work. The next
step though is to make
   them _use_ the new stuff which will probably involve device-tree
updates.

I expect to have PowerMac32 and possibly CHRP fixed tomorrow and will
proceed to the merge asap, leaving Maple and embedded6xx as "to be fixed
before 2.6.18 is finished".

I'd appreciate review and comments.

Cheers,
Ben.

^ permalink raw reply

* Re: "boot: mem=1024M" causes only one CPU is brought up in 2.6.17-mm4
From: Michael Ellerman @ 2006-06-30  7:51 UTC (permalink / raw)
  To: Raid Cheng; +Cc: linuxppc-dev
In-Reply-To: <b7ddee480606300005p15367a6al4db562f8d0b885d9@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Fri, 2006-06-30 at 15:05 +0800, Raid Cheng wrote:
> 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

Oops, must be a bug in my "cleaned up" mem=x handling. Can you send me
your System.map, and a tar.gz of /proc/device-tree for a working kernel
and also the mem=1024M kernel?

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply

* Re: new irq works status (#2)
From: Benjamin Herrenschmidt @ 2006-06-30  7:57 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <1151653855.13194.9.camel@localhost.localdomain>

On Fri, 2006-06-30 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> I uploaded a new version at http://gate.crashing.org/~benh/irq-WIP/
> 
> This one applies on top of a linus git checkout from today and thus
> should also apply on top of a recent powerpc.git tree. It contains
> various fixes & cleanups over the previous ones, significant fixes in
> the mpic code (mpic based pseries work now) and powermac 64 bits is
> ported over.

Note: Right now, powerpc.git might not have been updated yet to linus
latest so my patch will not apply on top of it ... oops.. that will be
fixed as soon as paulus updates powerpc.git though.

Ben.

^ permalink raw reply

* RE: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Li Yang-r58472 @ 2006-06-30  7:58 UTC (permalink / raw)
  To: 'Vitaly Bordug', Fleming Andy-afleming
  Cc: linuxppc-dev list, linux-kernel@vger.kernel.org Mailing List,
	Yin Olivia-r63875, Chu hanjin-r52514

Both of you are reasonable.  But the simplest fix goes like this:

-       /* Reset the Ethernet PHY */
-       bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
-       bcsr_regs[9] &= ~0x20;
-       udelay(1000);
-       bcsr_regs[9] |= 0x20;
-       iounmap(bcsr_regs);
+       if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
+                       != NULL){
+               /* Reset the Ethernet PHY */
+               bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+               bcsr_regs[9] &= ~0x20;
+               udelay(1000);
+               bcsr_regs[9] |= 0x20;
+               iounmap(bcsr_regs);
+       }


> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Friday, June 30, 2006 6:10 AM
> To: Fleming Andy-afleming
> Cc: Li Yang-r58472; Yin Olivia-r63875; linux-kernel@vger.kernel.org Mailing
> List; linuxppc-dev list; Chu hanjin-r52514
> Subject: Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
> 
> 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: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
From: Takashi Iwai @ 2006-06-30  9:12 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, rlrevell, alsa-devel, linux-kernel
In-Reply-To: <20060629211513.64980@gmx.net>

At Thu, 29 Jun 2006 23:15:13 +0200,
Gerhard Pircher wrote:
> 
> 
> -------- 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()? 

What is the type of buffer are you using?  If it's a buffer
pre-allocated via snd_pcm_lib_preallocate*() with SNDRV_DMA_TYPE_DEV,
there should be no snd_pcm_mmap_data_nopage call.  For other types,
there can be.  For example, the patch still doesn't solve the problems
with drivers using sg-buffer.


Takashi

^ permalink raw reply

* Re: [Alsa-devel] [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Takashi Iwai @ 2006-06-30  9:35 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: linuxppc-dev, Johannes Berg, Lee Revell, alsa-devel, netstar
In-Reply-To: <jehd231rjx.fsf@sykes.suse.de>

At Fri, 30 Jun 2006 01:16:18 +0200,
Andreas Schwab wrote:
> 
> 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.

Good catch.  I fixed on ALSA HG repo.


Takashi

^ permalink raw reply

* RE: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Li Yang-r58472 @ 2006-06-30 10:27 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

> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Thursday, June 29, 2006 12:59 AM
> To: Li Yang-r58472
> Cc: 'Paul Mackerras'; linuxppc-dev@ozlabs.org; Phillips Kim-R1AAHA; Chu
> hanjin-r52514; Yin Olivia-r63875; 'linux-kernel@vger.kernel.org'
> Subject: Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
> 
> On Wed, 28 Jun 2006 22:23:03 +0800
> Li Yang-r58472 <LeoLi@freescale.com> wrote:
> 
[snip]
> 
> >
> >  config MPC834x
> > @@ -24,4 +31,10 @@ config MPC834x
> >  	select PPC_INDIRECT_PCI
> >  	default y if MPC834x_SYS
> >
> > +config MPC836x
> > +	bool
> > +	select PPC_UDBG_16550
> 
> debug option made default?

I'm afraid this is needed to boot.  83xx family platforms need it to initialize early console.  And it does appear in several defconfigs of other platforms.
> > +	select PPC_INDIRECT_PCI
> > +	default y if MPC8360E_PB
> > +
> >  endmenu

^ permalink raw reply

* [PATCH 1/7 v2] powerpc: Add mpc8360epb platform support
From: Li Yang-r58472 @ 2006-06-30 10:45 UTC (permalink / raw)
  To: 'Paul Mackerras'; +Cc: linuxppc-dev

Some minor changes from v1.  The real content starts below:


The patch adds mpc8360e MDS Processor Board support.  MPC8360E is a new processor in the PowerQUICC II pro family, and it's the first one to use the new generation of communication coprocessor called QUICC ENGINE (QE in abbreviation). 

The patch needs a flat device tree to work.  It means either u-boot provides a flat device tree blob or somehow a kernel shim passes the tree.  The final mechanism of providing FDT is far beyond this patch.

---
 arch/powerpc/platforms/83xx/Kconfig       |   13 ++
 arch/powerpc/platforms/83xx/Makefile      |    1 
 arch/powerpc/platforms/83xx/mpc8360e_pb.c |  209 +++++++++++++++++++++++++++++
 arch/powerpc/platforms/83xx/mpc8360e_pb.h |   31 ++++
 4 files changed, 254 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 7675e67..04c4508 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -16,6 +16,13 @@ config MPC834x_SYS
 	  3 PCI slots.  The PIBs PCI initialization is the bootloader's
 	  responsiblilty.
 
+config MPC8360E_PB
+	bool "Freescale MPC8360E PB"
+	select DEFAULT_UIMAGE
+	select QUICC_ENGINE
+	help
+	  This option enables support for the MPC836x EMDS Processor Board.
+
 endchoice
 
 config MPC834x
@@ -24,4 +31,10 @@ config MPC834x
 	select PPC_INDIRECT_PCI
 	default y if MPC834x_SYS
 
+config MPC836x
+	bool
+	select PPC_UDBG_16550
+	select PPC_INDIRECT_PCI
+	default y if MPC8360E_PB
+
 endmenu
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 5c72367..0c9ea5c 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -4,3 +4,4 @@ #
 obj-y				:= misc.o
 obj-$(CONFIG_PCI)		+= pci.o
 obj-$(CONFIG_MPC834x_SYS)	+= mpc834x_sys.o
+obj-$(CONFIG_MPC8360E_PB)	+= mpc8360e_pb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
new file mode 100644
index 0000000..971b3cf
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ *
+ * Author: Li Yang <LeoLi@freescale.com>
+ *	   Yin Olivia <Hong-hua.Yin@freescale.com>
+ *
+ * Description:
+ * MPC8360E MDS PB board specific routines. 
+ *
+ * Changelog: 
+ * Jun 21, 2006	Initial version
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/reboot.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/major.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/seq_file.h>
+#include <linux/root_dev.h>
+#include <linux/initrd.h>
+
+#include <asm/system.h>
+#include <asm/atomic.h>
+#include <asm/time.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/ipic.h>
+#include <asm/bootinfo.h>
+#include <asm/irq.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <sysdev/fsl_soc.h>
+#ifdef CONFIG_QUICC_ENGINE
+#include <asm/immap_qe.h>
+#include <asm/qe_ic.h>
+#endif				/* CONFIG_QUICC_ENGINE */
+#include "mpc83xx.h"
+#include "mpc8360e_pb.h"
+
+#undef DEBUG
+#ifdef DEBUG
+#define DBG(fmt...) udbg_printf(fmt)
+#else
+#define DBG(fmt...)
+#endif
+
+#ifndef CONFIG_PCI
+unsigned long isa_io_base = 0;
+unsigned long isa_mem_base = 0;
+#endif
+
+/* ************************************************************************
+ *
+ * Setup the architecture
+ *
+ */
+static void __init mpc8360_sys_setup_arch(void)
+{
+	struct device_node *np;
+	
+#ifdef CONFIG_QUICC_ENGINE
+	u8 *bcsr_regs;
+#endif
+
+	if (ppc_md.progress)
+		ppc_md.progress("mpc8360_sys_setup_arch()", 0);
+
+	np = of_find_node_by_type(NULL, "cpu");
+	if (np != 0) {
+		unsigned int *fp =
+		    (int *)get_property(np, "clock-frequency", NULL);
+		if (fp != 0)
+			loops_per_jiffy = *fp / HZ;
+		else
+			loops_per_jiffy = 50000000 / HZ;
+		of_node_put(np);
+	}
+#ifdef CONFIG_PCI
+	for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
+		add_bridge(np);
+
+	ppc_md.pci_swizzle = common_swizzle;
+	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
+#endif
+
+#ifdef CONFIG_QUICC_ENGINE
+	qe_reset();
+
+	for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
+		par_io_of_config(np);
+	
+	if ((np = of_find_compatible_node(NULL, "network", "ucc_geth")) 
+			!= NULL){
+		/* Reset the Ethernet PHY */
+		bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+		bcsr_regs[9] &= ~0x20;
+		udelay(1000);
+		bcsr_regs[9] |= 0x20;
+		iounmap(bcsr_regs);
+	}
+
+#endif				/* CONFIG_QUICC_ENGINE */
+
+#ifdef CONFIG_BLK_DEV_INITRD
+	if (initrd_start)
+		ROOT_DEV = Root_RAM0;
+	else
+#endif
+#ifdef  CONFIG_ROOT_NFS
+		ROOT_DEV = Root_NFS;
+#else
+		ROOT_DEV = Root_HDA1;
+#endif
+}
+
+void __init mpc8360_sys_init_IRQ(void)
+{
+	u8 senses[8] = {
+		0,		/* EXT 0 */
+		IRQ_SENSE_LEVEL,	/* EXT 1 */
+		IRQ_SENSE_LEVEL,	/* EXT 2 */
+		0,		/* EXT 3 */
+#ifdef CONFIG_PCI
+		IRQ_SENSE_LEVEL,	/* EXT 4 */
+		IRQ_SENSE_LEVEL,	/* EXT 5 */
+		IRQ_SENSE_LEVEL,	/* EXT 6 */
+		IRQ_SENSE_LEVEL,	/* EXT 7 */
+#else
+		0,		/* EXT 4 */
+		0,		/* EXT 5 */
+		0,		/* EXT 6 */
+		0,		/* EXT 7 */
+#endif
+	};
+
+	ipic_init(get_immrbase() + 0x00700, 0, 0, senses, 8);
+
+	/* Initialize the default interrupt mapping priorities,
+	 * in case the boot rom changed something on us.
+	 */
+	ipic_set_default_priority();
+
+#ifdef CONFIG_QUICC_ENGINE
+	qe_ic_init(get_qe_base() + 0x00000080,
+		   (QE_IC_LOW_SIGNAL | QE_IC_HIGH_SIGNAL), QE_IRQ_OFFSET);
+#endif				/* CONFIG_QUICC_ENGINE */
+}
+
+#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
+extern ulong ds1374_get_rtc_time(void);
+extern int ds1374_set_rtc_time(ulong);
+
+static int __init mpc8360_rtc_hookup(void)
+{
+	struct timespec tv;
+
+	ppc_md.get_rtc_time = ds1374_get_rtc_time;
+	ppc_md.set_rtc_time = ds1374_set_rtc_time;
+
+	tv.tv_nsec = 0;
+	tv.tv_sec = (ppc_md.get_rtc_time) ();
+	do_settimeofday(&tv);
+
+	return 0;
+}
+
+late_initcall(mpc8360_rtc_hookup);
+#endif
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc8360_sys_probe(void)
+{
+	char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
+					  "model", NULL);
+	if (model == NULL)
+		return 0;
+	if (strcmp(model, "MPC8360EPB"))
+		return 0;
+
+	DBG("MPC8360EMDS-PB found\n");
+
+	return 1;
+}
+
+define_machine(mpc8360_sys) {
+	.name 		= "MPC8360E PB",
+	.probe 		= mpc8360_sys_probe,
+	.setup_arch 	= mpc8360_sys_setup_arch,
+	.init_IRQ 	= mpc8360_sys_init_IRQ,
+	.get_irq 	= ipic_get_irq,
+	.restart 	= mpc83xx_restart,
+	.time_init 	= mpc83xx_time_init,
+	.calibrate_decr	= generic_calibrate_decr,
+	.progress 	= udbg_progress,
+};
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.h b/arch/powerpc/platforms/83xx/mpc8360e_pb.h
new file mode 100644
index 0000000..84282e5
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ *
+ * Author: Li Yang <LeoLi@freescale.com>
+ *	   Yin Olivia <Hong-hua.Yin@freescale.com>
+ *
+ * Description:
+ * MPC8360E MDS PB board specific header. 
+ *
+ * Changelog: 
+ * Jun 21, 2006	Initial version
+ *
+ * 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.
+ *
+ */
+
+#ifndef __MACH_MPC83XX_SYS_H__
+#define __MACH_MPC83XX_SYS_H__
+
+#define BCSR_PHYS_ADDR		((uint)0xf8000000)
+#define BCSR_SIZE		((uint)(32 * 1024))
+
+#ifdef CONFIG_QUICC_ENGINE
+extern void qe_reset(void);
+extern int par_io_of_config(struct device_node *np);
+#endif  /* CONFIG_QUICC_ENGINE */
+
+#endif				/* __MACH_MPC83XX_SYS_H__ */

^ permalink raw reply related

* RE: [PATCH 1/7 v2] powerpc: Add mpc8360epb platform support
From: Li Yang-r58472 @ 2006-06-30 10:47 UTC (permalink / raw)
  To: 'Paul Mackerras'; +Cc: linuxppc-dev

Sorry, forgot the signed-off part.

Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Yin Olivia <hong-hua.yin@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

Best Regards,
Leo

> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf Of Li
> Yang-r58472
> Sent: Friday, June 30, 2006 6:45 PM
> To: 'Paul Mackerras'
> Cc: linuxppc-dev@ozlabs.org
> Subject: [PATCH 1/7 v2] powerpc: Add mpc8360epb platform support
> 
> Some minor changes from v1.  The real content starts below:
> 
> 
> The patch adds mpc8360e MDS Processor Board support.  MPC8360E is a new
> processor in the PowerQUICC II pro family, and it's the first one to use the
> new generation of communication coprocessor called QUICC ENGINE (QE in
> abbreviation).
> 
> The patch needs a flat device tree to work.  It means either u-boot provides
> a flat device tree blob or somehow a kernel shim passes the tree.  The final
> mechanism of providing FDT is far beyond this patch.
> 
> ---
>  arch/powerpc/platforms/83xx/Kconfig       |   13 ++
>  arch/powerpc/platforms/83xx/Makefile      |    1
>  arch/powerpc/platforms/83xx/mpc8360e_pb.c |  209
> +++++++++++++++++++++++++++++
>  arch/powerpc/platforms/83xx/mpc8360e_pb.h |   31 ++++
>  4 files changed, 254 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/83xx/Kconfig
> b/arch/powerpc/platforms/83xx/Kconfig
> index 7675e67..04c4508 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -16,6 +16,13 @@ config MPC834x_SYS
>  	  3 PCI slots.  The PIBs PCI initialization is the bootloader's
>  	  responsiblilty.
> 
> +config MPC8360E_PB
> +	bool "Freescale MPC8360E PB"
> +	select DEFAULT_UIMAGE
> +	select QUICC_ENGINE
> +	help
> +	  This option enables support for the MPC836x EMDS Processor Board.
> +
>  endchoice
> 
>  config MPC834x
> @@ -24,4 +31,10 @@ config MPC834x
>  	select PPC_INDIRECT_PCI
>  	default y if MPC834x_SYS
> 
> +config MPC836x
> +	bool
> +	select PPC_UDBG_16550
> +	select PPC_INDIRECT_PCI
> +	default y if MPC8360E_PB
> +
>  endmenu
> diff --git a/arch/powerpc/platforms/83xx/Makefile
> b/arch/powerpc/platforms/83xx/Makefile
> index 5c72367..0c9ea5c 100644
> --- a/arch/powerpc/platforms/83xx/Makefile
> +++ b/arch/powerpc/platforms/83xx/Makefile
> @@ -4,3 +4,4 @@ #
>  obj-y				:= misc.o
>  obj-$(CONFIG_PCI)		+= pci.o
>  obj-$(CONFIG_MPC834x_SYS)	+= mpc834x_sys.o
> +obj-$(CONFIG_MPC8360E_PB)	+= mpc8360e_pb.o
> diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c
> b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
> new file mode 100644
> index 0000000..971b3cf
> --- /dev/null
> +++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
> + *
> + * Author: Li Yang <LeoLi@freescale.com>
> + *	   Yin Olivia <Hong-hua.Yin@freescale.com>
> + *
> + * Description:
> + * MPC8360E MDS PB board specific routines.
> + *
> + * Changelog:
> + * Jun 21, 2006	Initial version
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/config.h>
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/major.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/root_dev.h>
> +#include <linux/initrd.h>
> +
> +#include <asm/system.h>
> +#include <asm/atomic.h>
> +#include <asm/time.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/ipic.h>
> +#include <asm/bootinfo.h>
> +#include <asm/irq.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <sysdev/fsl_soc.h>
> +#ifdef CONFIG_QUICC_ENGINE
> +#include <asm/immap_qe.h>
> +#include <asm/qe_ic.h>
> +#endif				/* CONFIG_QUICC_ENGINE */
> +#include "mpc83xx.h"
> +#include "mpc8360e_pb.h"
> +
> +#undef DEBUG
> +#ifdef DEBUG
> +#define DBG(fmt...) udbg_printf(fmt)
> +#else
> +#define DBG(fmt...)
> +#endif
> +
> +#ifndef CONFIG_PCI
> +unsigned long isa_io_base = 0;
> +unsigned long isa_mem_base = 0;
> +#endif
> +
> +/*
> ************************************************************************
> + *
> + * Setup the architecture
> + *
> + */
> +static void __init mpc8360_sys_setup_arch(void)
> +{
> +	struct device_node *np;
> +
> +#ifdef CONFIG_QUICC_ENGINE
> +	u8 *bcsr_regs;
> +#endif
> +
> +	if (ppc_md.progress)
> +		ppc_md.progress("mpc8360_sys_setup_arch()", 0);
> +
> +	np = of_find_node_by_type(NULL, "cpu");
> +	if (np != 0) {
> +		unsigned int *fp =
> +		    (int *)get_property(np, "clock-frequency", NULL);
> +		if (fp != 0)
> +			loops_per_jiffy = *fp / HZ;
> +		else
> +			loops_per_jiffy = 50000000 / HZ;
> +		of_node_put(np);
> +	}
> +#ifdef CONFIG_PCI
> +	for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> +		add_bridge(np);
> +
> +	ppc_md.pci_swizzle = common_swizzle;
> +	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
> +#endif
> +
> +#ifdef CONFIG_QUICC_ENGINE
> +	qe_reset();
> +
> +	for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> +		par_io_of_config(np);
> +
> +	if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
> +			!= NULL){
> +		/* Reset the Ethernet PHY */
> +		bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
> +		bcsr_regs[9] &= ~0x20;
> +		udelay(1000);
> +		bcsr_regs[9] |= 0x20;
> +		iounmap(bcsr_regs);
> +	}
> +
> +#endif				/* CONFIG_QUICC_ENGINE */
> +
> +#ifdef CONFIG_BLK_DEV_INITRD
> +	if (initrd_start)
> +		ROOT_DEV = Root_RAM0;
> +	else
> +#endif
> +#ifdef  CONFIG_ROOT_NFS
> +		ROOT_DEV = Root_NFS;
> +#else
> +		ROOT_DEV = Root_HDA1;
> +#endif
> +}
> +
> +void __init mpc8360_sys_init_IRQ(void)
> +{
> +	u8 senses[8] = {
> +		0,		/* EXT 0 */
> +		IRQ_SENSE_LEVEL,	/* EXT 1 */
> +		IRQ_SENSE_LEVEL,	/* EXT 2 */
> +		0,		/* EXT 3 */
> +#ifdef CONFIG_PCI
> +		IRQ_SENSE_LEVEL,	/* EXT 4 */
> +		IRQ_SENSE_LEVEL,	/* EXT 5 */
> +		IRQ_SENSE_LEVEL,	/* EXT 6 */
> +		IRQ_SENSE_LEVEL,	/* EXT 7 */
> +#else
> +		0,		/* EXT 4 */
> +		0,		/* EXT 5 */
> +		0,		/* EXT 6 */
> +		0,		/* EXT 7 */
> +#endif
> +	};
> +
> +	ipic_init(get_immrbase() + 0x00700, 0, 0, senses, 8);
> +
> +	/* Initialize the default interrupt mapping priorities,
> +	 * in case the boot rom changed something on us.
> +	 */
> +	ipic_set_default_priority();
> +
> +#ifdef CONFIG_QUICC_ENGINE
> +	qe_ic_init(get_qe_base() + 0x00000080,
> +		   (QE_IC_LOW_SIGNAL | QE_IC_HIGH_SIGNAL), QE_IRQ_OFFSET);
> +#endif				/* CONFIG_QUICC_ENGINE */
> +}
> +
> +#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
> +extern ulong ds1374_get_rtc_time(void);
> +extern int ds1374_set_rtc_time(ulong);
> +
> +static int __init mpc8360_rtc_hookup(void)
> +{
> +	struct timespec tv;
> +
> +	ppc_md.get_rtc_time = ds1374_get_rtc_time;
> +	ppc_md.set_rtc_time = ds1374_set_rtc_time;
> +
> +	tv.tv_nsec = 0;
> +	tv.tv_sec = (ppc_md.get_rtc_time) ();
> +	do_settimeofday(&tv);
> +
> +	return 0;
> +}
> +
> +late_initcall(mpc8360_rtc_hookup);
> +#endif
> +
> +/*
> + * Called very early, MMU is off, device-tree isn't unflattened
> + */
> +static int __init mpc8360_sys_probe(void)
> +{
> +	char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
> +					  "model", NULL);
> +	if (model == NULL)
> +		return 0;
> +	if (strcmp(model, "MPC8360EPB"))
> +		return 0;
> +
> +	DBG("MPC8360EMDS-PB found\n");
> +
> +	return 1;
> +}
> +
> +define_machine(mpc8360_sys) {
> +	.name 		= "MPC8360E PB",
> +	.probe 		= mpc8360_sys_probe,
> +	.setup_arch 	= mpc8360_sys_setup_arch,
> +	.init_IRQ 	= mpc8360_sys_init_IRQ,
> +	.get_irq 	= ipic_get_irq,
> +	.restart 	= mpc83xx_restart,
> +	.time_init 	= mpc83xx_time_init,
> +	.calibrate_decr	= generic_calibrate_decr,
> +	.progress 	= udbg_progress,
> +};
> diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.h
> b/arch/powerpc/platforms/83xx/mpc8360e_pb.h
> new file mode 100644
> index 0000000..84282e5
> --- /dev/null
> +++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.h
> @@ -0,0 +1,31 @@
> +/*
> + * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
> + *
> + * Author: Li Yang <LeoLi@freescale.com>
> + *	   Yin Olivia <Hong-hua.Yin@freescale.com>
> + *
> + * Description:
> + * MPC8360E MDS PB board specific header.
> + *
> + * Changelog:
> + * Jun 21, 2006	Initial version
> + *
> + * 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.
> + *
> + */
> +
> +#ifndef __MACH_MPC83XX_SYS_H__
> +#define __MACH_MPC83XX_SYS_H__
> +
> +#define BCSR_PHYS_ADDR		((uint)0xf8000000)
> +#define BCSR_SIZE		((uint)(32 * 1024))
> +
> +#ifdef CONFIG_QUICC_ENGINE
> +extern void qe_reset(void);
> +extern int par_io_of_config(struct device_node *np);
> +#endif  /* CONFIG_QUICC_ENGINE */
> +
> +#endif				/* __MACH_MPC83XX_SYS_H__ */
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Problem in PCI with MPC5200B
From: Ram Prasad H L @ 2006-06-30 12:51 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20060607120252.qjekdh5yzyrs4s0g@webmail.bluenox.com>

hi all,
	we are using a customized board based on the reference design of lite5200B.
The PCI bus heirarchy in the board is as follows:
											     |---------> DM642(TMS320C642)
	OnChip-Host-Bridge(MPC5200B) ----> PCI-to-PCI Bridge (TI2250) ---|
											     |---------> Empty Slot
                                                                       |

|---------> Empty Slot

	The linux kernel used is 2.6.11.7. with u-boot-1.1.3. The problem we are
facing is that
I'm able to access the PCI Memory and I/O Region of DM642 from my Host
(MPC5200B) ie.upstream.
But when it comes to other way around ie. with Host Bridge being the PCI
slave and DM642 being the
master, the transaction is failing to complete. But not getting any
exceptions like master abort
and target abort. The BAR Configuration is as follows

Host (MPC5200B):

	BAR0 -- 0x41000000 (256MB) Non prefetchable
	BAR1 -- 0x00000000 (1GB)   prefetchable

PCI-PCI Bridge (TI2250):
	BAR0 -- 0x00000000  {Both are defaulted to 0's and are Read Only}
	BAR1 -- 0x00000000

DM642:
	BAR0 -- 0x40000000 (4MB) 	prefetchable
	BAR1 -- 0x40800000 (8MB) 	Non prefetchable
	BAR2 -- 0x00fff001 (16 bytes) I/O

	If anyone can provide pointers and suggestions to overcome this problem, it
will be of great help, as
we are stuck up with it since long time.

thanks and regards,
Ramprasad H L

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s)and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender or administrator@tataelxsi.co.in

^ permalink raw reply

* [PATCH] powerpc:Fix rheap alignment problem
From: Li Yang-r58472 @ 2006-06-30 13:02 UTC (permalink / raw)
  To: 'Paul Mackerras'
  Cc: linuxppc-dev, 'linux-kernel@vger.kernel.org'

Honour alignment parameter in the rheap allocator.
Remove compile warning.

Signed-off-by: Pantelis Antoniou <pantelis@embeddedalley.com>
Signed-off-by: Li Yang <leoli@freescale.com>

---
 arch/powerpc/lib/Makefile |    1 +
 arch/powerpc/lib/rheap.c  |   24 ++++++++++++++++++++----
 include/asm-ppc/rheap.h   |    4 ++++
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 34f5c2e..136a892 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -11,6 +11,7 @@ obj-y			+= bitops.o
 obj-$(CONFIG_PPC64)	+= checksum_64.o copypage_64.o copyuser_64.o \
 			   memcpy_64.o usercopy_64.o mem_64.o string.o \
 			   strcase.o
+obj-$(CONFIG_QUICC_ENGINE) += rheap.o
 obj-$(CONFIG_PPC_ISERIES) += e2a.o
 obj-$(CONFIG_XMON)	+= sstep.o
 
diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c
index 31e5118..57bf991 100644
--- a/arch/powerpc/lib/rheap.c
+++ b/arch/powerpc/lib/rheap.c
@@ -423,17 +423,21 @@ void *rh_detach_region(rh_info_t * info,
 	return (void *)s;
 }
 
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
 {
 	struct list_head *l;
 	rh_block_t *blk;
 	rh_block_t *newblk;
 	void *start;
 
-	/* Validate size */
-	if (size <= 0)
+	/* Validate size, (must be power of two) */
+	if (size <= 0 || (alignment & (alignment - 1)) != 0)
 		return ERR_PTR(-EINVAL);
 
+	/* given alignment larger that default rheap alignment */
+	if (alignment > info->alignment)
+		size += alignment - 1;
+
 	/* Align to configured alignment */
 	size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
 
@@ -476,15 +480,27 @@ void *rh_alloc(rh_info_t * info, int siz
 
 	attach_taken_block(info, newblk);
 
+	/* for larger alignment return fixed up pointer  */
+	/* this is no problem with the deallocator since */
+	/* we scan for pointers that lie in the blocks   */
+	if (alignment > info->alignment)
+		start = (void *)(((unsigned long)start + alignment - 1) &
+				~(alignment - 1));
+
 	return start;
 }
 
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+	return rh_alloc_align(info, size, info->alignment, owner);
+}
+
 /* allocate at precisely the given address */
 void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
 {
 	struct list_head *l;
 	rh_block_t *blk, *newblk1, *newblk2;
-	unsigned long s, e, m, bs, be;
+	unsigned long s, e, m, bs = 0, be = 0;
 
 	/* Validate size */
 	if (size <= 0)
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
index e6ca1f6..65b9322 100644
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t * 
 /* Detach a free region */
 extern void *rh_detach_region(rh_info_t * info, void *start, int size);
 
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+		const char *owner);
+
 /* Allocate the given size from the remote heap */
 extern void *rh_alloc(rh_info_t * info, int size, const char *owner);

--
Leo Li
Freescale Semiconductor

LeoLi@freescale.com 

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox