LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 10/16] mm/powerpc: use vm_flags_t for vma flags
From: Konstantin Khlebnikov @ 2012-03-21  6:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <20120321065140.13852.52315.stgit@zurg>

Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/include/asm/mman.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index d4a7f64..451de1c 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -44,7 +44,7 @@ static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot)
 }
 #define arch_calc_vm_prot_bits(prot) arch_calc_vm_prot_bits(prot)
 
-static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
+static inline pgprot_t arch_vm_get_page_prot(vm_flags_t vm_flags)
 {
 	return (vm_flags & VM_SAO) ? __pgprot(_PAGE_SAO) : __pgprot(0);
 }

^ permalink raw reply related

* Re: [PATCH] Disable /dev/port interface on powerpc systems
From: Benjamin Herrenschmidt @ 2012-03-21  7:23 UTC (permalink / raw)
  To: Haren Myneni; +Cc: linuxppc-dev, anton
In-Reply-To: <1332308237.23222.49.camel@hbabu-laptop>

On Tue, 2012-03-20 at 22:37 -0700, Haren Myneni wrote:
> Some power systems do not have legacy ISA devices. So, /dev/port is not
> a valid interface on these systems. User level tools such as kbdrate is
> trying to access the device using this interface which is causing the
> system crash. 
> 
> This patch will fix this issue by not creating this interface on these
> powerpc systems. 

Doesn't fix 32-bit... not a big deal for now I suppose... But I'd rather
you change the patch a tiny bit to change legacy_isa_device_found() to
arch_has_dev_port() instead. There may be other reason than legacy ISA
to enable dev/port or not so let's make the arch hook more generic.

Another approach which might be even better is to filter per-access,
ie for each read/write to /dev/port, have a hook to check if that
specific port is valid, but that may be overkill for what is
essentially a legacy interface that should have died a long time ago :)

Cheers,
Ben.

> Signed-off-by: Haren Myneni <haren@us.ibm.com>
> 
> 
> diff -Naurp linux.orig/arch/powerpc/kernel/isa-bridge.c
> linux/arch/powerpc/kernel/isa-bridge.c
> --- linux.orig/arch/powerpc/kernel/isa-bridge.c	2012-02-11
> 02:08:08.780005293 -0800
> +++ linux/arch/powerpc/kernel/isa-bridge.c	2012-02-11 02:16:25.080003386
> -0800
> @@ -255,6 +255,14 @@ static struct notifier_block isa_bridge_
>  	.notifier_call = isa_bridge_notify
>  };
>  
> +int __init legacy_isa_device_found(void)
> +{
> +	if (isa_bridge_pcidev)
> +		return 1;
> +	
> +	return 0;
> +}
> +
>  /**
>   * isa_bridge_init - register to be notified of ISA bridge
> addition/removal
>   *
> diff -Naurp linux.orig/drivers/char/mem.c linux/drivers/char/mem.c
> --- linux.orig/drivers/char/mem.c	2012-02-11 02:08:42.710002440 -0800
> +++ linux/drivers/char/mem.c	2012-03-20 20:40:43.650000003 -0700
> @@ -35,6 +35,8 @@
>  # include <linux/efi.h>
>  #endif
>  
> +#define DEVPORT_MINOR	4
> +
>  static inline unsigned long size_inside_page(unsigned long start,
>  					     unsigned long size)
>  {
> @@ -910,6 +912,11 @@ static char *mem_devnode(struct device *
>  
>  static struct class *mem_class;
>  
> +int __init __weak legacy_isa_device_found(void)
> +{
> +	return 1;
> +}
> +
>  static int __init chr_dev_init(void)
>  {
>  	int minor;
> @@ -930,6 +937,13 @@ static int __init chr_dev_init(void)
>  	for (minor = 1; minor < ARRAY_SIZE(devlist); minor++) {
>  		if (!devlist[minor].name)
>  			continue;
> +
> +		/*
> +		 * Create /dev/port? 
> +		 */
> +		if ((minor == DEVPORT_MINOR) && !legacy_isa_device_found())
> +			continue;
> +
>  		device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
>  			      NULL, devlist[minor].name);
>  	}
> diff -Naurp linux.orig/include/linux/isa.h linux/include/linux/isa.h
> --- linux.orig/include/linux/isa.h	2012-02-11 02:07:52.030019810 -0800
> +++ linux/include/linux/isa.h	2012-02-11 02:16:49.810002296 -0800
> @@ -36,4 +36,5 @@ static inline void isa_unregister_driver
>  }
>  #endif
>  
> +extern int __init legacy_isa_device_found(void);
>  #endif /* __LINUX_ISA_H */
> 

^ permalink raw reply

* kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Robert Berger @ 2012-03-21 12:10 UTC (permalink / raw)
  To: linuxppc-dev

Hi,

Up to 3.2.x I was able to compile a mainline kernel for the kilauea
board, but...

http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81

shows, that mfdcrx was introduced in the v3.3 kernel.

The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
ELDK 4.2) this assembly instruction is not known and the build breaks.

There are some obvious workarounds, like using a more recent toolchain
(e.g ELDK 5.x) or use make -k to keep on compiling even when there is an
error as much as possible;)

What puzzles me is that also stuff for boards is being compiled which is
not really needed like treeboot-currituck.c even when I configure the
kernel for a kilauea board.

Is this on purpose and if so why?

Please advise.

Regards,

Robert
..."But I have a slowly coagulating theory that the size of a project is
directly proportional to the possibility that significant bugs will crop
up. Exponentiate for each additional programmer involved." - Steven K.
Halliburton

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

^ permalink raw reply

* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Josh Boyer @ 2012-03-21 13:29 UTC (permalink / raw)
  To: robert.karl.berger; +Cc: linuxppc-dev
In-Reply-To: <4F69C553.6070409@gmail.com>

On Wed, Mar 21, 2012 at 8:10 AM, Robert Berger
<robert.karl.berger@gmail.com> wrote:
> Hi,
>
> Up to 3.2.x I was able to compile a mainline kernel for the kilauea
> board, but...
>
> http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
>
> shows, that mfdcrx was introduced in the v3.3 kernel.
>
> The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
> ELDK 4.2) this assembly instruction is not known and the build breaks.

Sigh.  GCC 4.2 is pretty old at this point.

> There are some obvious workarounds, like using a more recent toolchain
> (e.g ELDK 5.x) or use make -k to keep on compiling even when there is an
> error as much as possible;)

That would be the most expedient option, yes.

> What puzzles me is that also stuff for boards is being compiled which is
> not really needed like treeboot-currituck.c even when I configure the
> kernel for a kilauea board.
>
> Is this on purpose and if so why?

All of the stuff in arch/powerpc/boot/ is built regardless of the
configured board and stuffed into a wrapper.a archive.  Then the
individual board targets are built and the necessary pieces are pulled
from the wrapper.a file.

> Please advise.

If upgrading ELDK is an option for you, it will get you the quickest
solution.  Otherwise we'll need to figure out how to stub out the
instruction in boot/dcr.h and use the asm long trick.  Ew.  I can look
at that next week.

josh

^ permalink raw reply

* RE: [GIT PULL] DMA-mapping framework updates for 3.4
From: Marek Szyprowski @ 2012-03-21 13:43 UTC (permalink / raw)
  To: Marek Szyprowski, 'Linus Torvalds'
  Cc: linux-mips, linux-ia64, linux-sh, linux-mm, sparclinux,
	linux-arch, 'Jonathan Corbet', x86,
	'Arnd Bergmann', microblaze-uclinux, linaro-mm-sig,
	Andrzej Pietrasiewicz, 'Thomas Gleixner',
	linux-arm-kernel, discuss, linux-kernel,
	'FUJITA Tomonori', 'Kyungmin Park', linux-alpha,
	'Andrew Morton', linuxppc-dev
In-Reply-To: <1332228283-29077-1-git-send-email-m.szyprowski@samsung.com>

Hello,

On Tuesday, March 20, 2012 8:25 AM Marek Szyprowski wrote:

> Hi Linus,
> 
> Please pull the dma-mapping framework updates for v3.4 since commit
> c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
> 
>   Linux 3.3
> 
> with the top-most commit e749a9f707f1102735e02338fa564be86be3bb69
> 
>   common: DMA-mapping: add NON-CONSISTENT attribute
> 
> from the git repository at:
> 
>   git://git.infradead.org/users/kmpark/linux-samsung dma-mapping-next
> 
> Those patches introduce a new alloc method (with support for memory
> attributes) in dma_map_ops structure, which will later replace
> dma_alloc_coherent and dma_alloc_writecombine functions.
 
I've been pointed out that this summary is quite short and misses the main
rationale for the proposed changes.

A few limitations have been identified in the current dma-mapping design and 
its implementations for various architectures. There exist more than one function
for allocating and freeing the buffers: currently these 3 are used dma_{alloc,
free}_coherent, dma_{alloc,free}_writecombine, dma_{alloc,free}_noncoherent.

For most of the systems these calls are almost equivalent and can be interchanged.
For others, especially the truly non-coherent ones (like ARM), the difference can
be easily noticed in overall driver performance. Sadly not all architectures 
provide implementations for all of them, so the drivers might need to be adapted 
and cannot be easily shared between different architectures. The provided patches
unify all these functions and hide the differences under the already existing
dma attributes concept. The thread with more references is available here: 
http://www.spinics.net/lists/linux-sh/msg09777.html

These patches are also a prerequisite for unifying DMA-mapping implementation
on ARM architecture with the common one provided by dma_map_ops structure and 
extending it with IOMMU support. More information is available in the following 
thread: http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819

More works on dma-mapping framework are planned, especially in the area of buffer
sharing and managing the shared mappings (together with the recently introduced 
dma_buf interface: commit d15bd7ee445d0702ad801fdaece348fdb79e6581 "dma-buf: 
Introduce dma buffer sharing mechanism" ).

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

^ permalink raw reply

* Re: Please pull 'next' branch of 5xxx tree
From: Stephen Rothwell @ 2012-03-21 14:08 UTC (permalink / raw)
  To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20120321011830.20e20ca0@wker>

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

Hi Anatolij,

On Wed, 21 Mar 2012 01:18:30 +0100 Anatolij Gustschin <agust@denx.de> wrote:
>
> Yes. Stephen, could you please change linux-next to pull from my
> mpc5xxx tree
> 
>  git://git.denx.de/linux-2.6-agust.git next

I have replaced the 52xx-and-virtex tree with this (and called it simply
mpc5xxx).  I have also removed the 52xx-and-virtex-current tree.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Kumar Gala @ 2012-03-21 15:08 UTC (permalink / raw)
  To: Grant Likely
  Cc: Scott Wood, Dmitry Eremin-Solenikov, Timur Tabi,
	linuxppc-dev list
In-Reply-To: <20120319160452.B57D13E05A5@localhost>


On Mar 19, 2012, at 11:04 AM, Grant Likely wrote:

> On Fri, 16 Mar 2012 15:50:44 -0500, Timur Tabi <timur@freescale.com> =
wrote:
>> Kumar Gala wrote:
>>=20
>>> This seems like paper taping over the real issue.  We should be able =
to call of_platform_bus_probe() multiple times.
>>=20
>> I tried debugging it, but I couldn't figure it out.  My guess is that =
the
>> nodes probed by of_platform_bus_probe() are somehow "reserved", so =
that
>> the second time it's called, they're skipped.  I figured that this =
was
>> just a side-effect of the way the OF layer works.
>=20
> The problem is that you want to create devices for grandchildren
> nodes when the bus ids passed in don't match any of the child nodes so
> the of_platform_bus_probe() doesn't iterate down to that level.  This
> is correct and expected behaviour.
>=20
> g.

Does of_platform_populate() handle this?

- k=

^ permalink raw reply

* Re: [PATCH] powerpc/85xx: don't call of_platform_bus_probe() twice
From: Timur Tabi @ 2012-03-21 15:15 UTC (permalink / raw)
  To: Grant Likely; +Cc: Scott Wood, Dmitry Eremin-Solenikov, linuxppc-dev list
In-Reply-To: <4F68BD6F.2090008@freescale.com>

Timur Tabi wrote:
> They only problem I see with this is that I am thinking about modifying
> the drivers/dma driver to probe on "fsl,eloplus-dma-channel" channels
> directly.  If I do that, then who should call of_platform_populate()?

Grant, could you tell me if there's anything actually work with my patch?
 All I'm doing is adding a couple more commonly used entries to
mpc85xx_common_ids[].  After all, they're common IDs, so don't they belong
into an array called common_ids?

I've been waiting for months for this problem to be fixed, and 3.3 is
broken without it.  We've already established that you cannot actually
call of_platform_bus_probe() twice on the same level, so it's not like my
patch description is wrong or anything.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: [PATCH] p1010rdb: gianfar config does not have queues.
From: Kumar Gala @ 2012-03-21 15:26 UTC (permalink / raw)
  To: Aggrwal Poonam-B10812
  Cc: Chauhan Pankaj-B32944, Eric Dumazet, Srivastava Rajan-B34330,
	U Bhaskar-B22300, Robin Holt, PPC list
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D09D429@039-SN2MPN1-013.039d.mgd.msft.net>


On Mar 17, 2012, at 12:37 AM, Aggrwal Poonam-B10812 wrote:

> Hello Pankaj, Rajan
>=20
> DO you have any comments on the below patch of gianfar?
>>> -			fsl,num_rx_queues =3D <0x8>;
>>> -			fsl,num_tx_queues =3D <0x8>;
> Have been removed from P1010RDB device tree to avoid a kernel panic.
>=20

Ah, right.

> Kumar, as such I see this is the old dts format. Also in the latest =
sdk tree these properties are defined, not sure it is working on =
P1010RDB.
> I can check on this and get back.

Mostly, can you check that p1010rdb boots and works w/my next branch.

- k

>=20
>=20
> Regards
> Poonam
>=20
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, March 16, 2012 8:50 PM
>> To: Aggrwal Poonam-B10812
>> Cc: Robin Holt; U Bhaskar-B22300; PPC list; Eric Dumazet
>> Subject: Re: [PATCH] p1010rdb: gianfar config does not have queues.
>>=20
>>=20
>> On Aug 11, 2011, at 9:25 AM, Robin Holt wrote:
>>=20
>>> If I have the the fsl,num_rx_queues and fsl,num_tx_queues properties
>>> defined in the p1010's device tree file, I get a kernel panic very
>>> shortly after boot.  The failure indicates we are configuring the
>>> gianfar.c driver for a queue depth greater than actual.  Removing =
the
>>> properties got the problem resolved.
>>>=20
>>> Signed-off-by: Robin Holt <holt@sgi.com>
>>> To: U Bhaskar-B22300 <B22300@freescale.com>
>>> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
>>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>>=20
>> Poonam,
>>=20
>> Can you comment on this patch, does it look correct?
>>=20
>> - k
>>=20
>>>=20
>>> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi
>>> b/arch/powerpc/boot/dts/p1010si.dtsi
>>> index 7f51104..91566aa 100644
>>> --- a/arch/powerpc/boot/dts/p1010si.dtsi
>>> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
>>> @@ -258,8 +258,6 @@
>>> 			device_type =3D "network";
>>> 			model =3D "eTSEC";
>>> 			compatible =3D "fsl,etsec2";
>>> -			fsl,num_rx_queues =3D <0x8>;
>>> -			fsl,num_tx_queues =3D <0x8>;
>>> 			local-mac-address =3D [ 00 00 00 00 00 00 ];
>>> 			interrupt-parent =3D <&mpic>;
>>>=20
>>> @@ -280,8 +278,6 @@
>>> 			device_type =3D "network";
>>> 			model =3D "eTSEC";
>>> 			compatible =3D "fsl,etsec2";
>>> -			fsl,num_rx_queues =3D <0x8>;
>>> -			fsl,num_tx_queues =3D <0x8>;
>>> 			local-mac-address =3D [ 00 00 00 00 00 00 ];
>>> 			interrupt-parent =3D <&mpic>;
>>>=20
>>> @@ -302,8 +298,6 @@
>>> 			device_type =3D "network";
>>> 			model =3D "eTSEC";
>>> 			compatible =3D "fsl,etsec2";
>>> -			fsl,num_rx_queues =3D <0x8>;
>>> -			fsl,num_tx_queues =3D <0x8>;
>>> 			local-mac-address =3D [ 00 00 00 00 00 00 ];
>>> 			interrupt-parent =3D <&mpic>;
>>>=20
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>=20
>=20

^ permalink raw reply

* Re: [PATCH] powerpc/dts: Removed fsl,msi property from dts.
From: Diana CRACIUN @ 2012-03-21 15:33 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <36B1F034-98A1-4571-8B94-A01D345935DF@kernel.crashing.org>

On 03/16/2012 09:33 PM, Kumar Gala wrote:
> On Feb 9, 2012, at 7:41 AM, Diana Craciun wrote:
>
>> From: Diana CRACIUN<Diana.Craciun@freescale.com>
>>
>> The association in the decice tree between PCI and MSI
>> using fsl,msi property was an artificial one and it does
>> not reflect the actual hardware.
>>
>> Signed-off-by: Diana CRACIUN<Diana.Craciun@freescale.com>
>> ---
>> arch/powerpc/boot/dts/p2041rdb.dts |    3 ---
>> arch/powerpc/boot/dts/p3041ds.dts  |    4 ----
>> arch/powerpc/boot/dts/p3060qds.dts |    2 --
>> arch/powerpc/boot/dts/p4080ds.dts  |    3 ---
>> arch/powerpc/boot/dts/p5020ds.dts  |    4 ----
>> 5 files changed, 0 insertions(+), 16 deletions(-)
> Should we not also remove the code associated with this property?
>
> - k

No. The property may be present in the device tree when running under 
Freescale hypervisor and it is used to skip the MSI nodes which are not 
mapped in PAMU.

The code in kernel handles both situations: when the property is present 
and in this case it searches only the corresponding MSI device for 
available interrupts and when the property is not present and in this 
case it loops over all the MSI devices.

Diana

^ permalink raw reply

* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Wolfgang Denk @ 2012-03-21 16:25 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, robert.karl.berger
In-Reply-To: <CA+5PVA7+vPZmLBzkXOFwTM+kLMYHPDgVW4Jcm91XSxW=Ng-Y6g@mail.gmail.com>

Dear Josh,

In message <CA+5PVA7+vPZmLBzkXOFwTM+kLMYHPDgVW4Jcm91XSxW=Ng-Y6g@mail.gmail.com> you wrote:
>
> > The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
> > ELDK 4.2) this assembly instruction is not known and the build breaks.
> 
> Sigh.  GCC 4.2 is pretty old at this point.

But still rock-solid ...  We use it a lot, especially as reference for
more recent (and sometimes more broken) versions of GCC.

> All of the stuff in arch/powerpc/boot/ is built regardless of the
> configured board and stuffed into a wrapper.a archive.  Then the
> individual board targets are built and the necessary pieces are pulled
> from the wrapper.a file.

This appears to be a pretty inefficient approach.  Why don't we build
only the files we actually need?  That would save a bit of build time.

> > Please advise.
> 
> If upgrading ELDK is an option for you, it will get you the quickest
> solution.  Otherwise we'll need to figure out how to stub out the
> instruction in boot/dcr.h and use the asm long trick.  Ew.  I can look
> at that next week.

Thanks a lot in advance!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is wrong always, everywhere and for everyone to  believe  anything
upon  insufficient  evidence.  - W. K. Clifford, British philosopher,
circa 1876

^ permalink raw reply

* Re: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
From: Kumar Gala @ 2012-03-21 17:20 UTC (permalink / raw)
  To: Prabhakar Kushwaha
  Cc: Priyanka Jain, devicetree-discuss, Ramneek Mehresh,
	Rajan Srivastava, linuxppc-dev, Akhil Goyal
In-Reply-To: <1331973588-29896-1-git-send-email-prabhakar@freescale.com>


On Mar 17, 2012, at 3:39 AM, Prabhakar Kushwaha wrote:

> BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The =
BSC9131 is
> integrated SoC that targets Femto base station market. It combines =
Power
> Architecture e500v2 and DSP StarCore SC3850 core technologies with =
MAPLE-B2F
> baseband acceleration processing elements.
>=20
> The BSC9131 SoC includes the following function and features:
>    . Power Architecture subsystem including a e500 processor with =
256-Kbyte shared
>      L2 cache
>    . StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache
>    . The Multi Accelerator Platform Engine for Femto BaseStation =
Baseband
>      Processing (MAPLE-B2F)
>    . A multi-standard baseband algorithm accelerator for Channel =
Decoding/Encoding,
>      Fourier Transforms, UMTS chip rate processing, LTE UP/DL Channel =
processing,
>      and CRC algorithms
>    . Consists of accelerators for Convolution, Filtering, Turbo =
Encoding,
>      Turbo Decoding, Viterbi decoding, Chiprate processing, and Matrix =
Inversion
>      operations
>    . DDR3/3L memory interface with 32-bit data width without ECC and =
16-bit with
>      ECC, up to 400-MHz clock/800 MHz data rate
>    . Dedicated security engine featuring trusted boot
>    . DMA controller
>    . OCNDMA with four bidirectional channels
>    . Interfaces
>    . Two triple-speed Gigabit Ethernet controllers featuring network =
acceleration
>      including IEEE 1588. v2 hardware support and virtualization =
(eTSEC)
>    . eTSEC 1 supports RGMII/RMII
>    . eTSEC 2 supports RGMII
>    . High-speed USB 2.0 host and device controller with ULPI interface
>    . Enhanced secure digital (SD/MMC) host controller (eSDHC)
>    . Antenna interface controller (AIC), supporting three industry =
standard
>      JESD207/three custom ADI RF interfaces (two dual port and one =
single port)
>      and three MAXIM's MaxPHY serial interfaces
>    . ADI lanes support both full duplex FDD support and half duplex =
TDD support
>    . Universal Subscriber Identity Module (USIM) interface that =
facilitates
>      communication to SIM cards or Eurochip pre-paid phone cards
>    . TDM with one TDM port
>    . Two DUART, four eSPI, and two I2C controllers
>    . Integrated Flash memory controller (IFC)
>    . TDM with 256 channels
>    . GPIO
>    . Sixteen 32-bit timers
>=20
> The DSP portion of the SoC consists of DSP core (SC3850) and various
> accelerators pertaining to DSP operations.
>=20
> BSC9131RDB Overview
> ----------------------
>     BSC9131 SoC
>     1Gbyte DDR3 (on board DDR)
>     128Mbyte 2K page size NAND Flash
>     256 Kbit M24256 I2C EEPROM
>     128 Mbit SPI Flash memory
>     USB-ULPI
>     eTSEC1: Connected to RGMII PHY
>     eTSEC2: Connected to RGMII PHY
>     DUART interface: supports one UARTs up to 115200 bps for console =
display
>=20
> Linux runs on e500v2 core and access some DSP peripherals like AIC
>=20
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> Signed-off-by: Akhil Goyal <Akhil.Goyal@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Rajan Srivastava <rajan.srivastava@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Note:   Name of PSC9131 has been changed to BSC9131 because of new =
nomenclature
> 	Please reject earlier patch"powerpc/85xx:Add PSC9131 RDB =
Support"
> 	  http://patchwork.ozlabs.org/patch/146349/
>=20
> Beased on =
http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> 	    branch master
>=20
> Changes for v2:=20
> 	- Change board file name as bsc913x_rdb.c
> 	- Removed all I2C's board device. A separate patch will be send.
> 	- Combined SPI's 2 RFS partition into single RFS parition
> 	- Added SEC/crypto node in dts
>=20
> arch/powerpc/boot/dts/bsc9131rdb.dts          |   34 +++++
> arch/powerpc/boot/dts/bsc9131rdb.dtsi         |  142 =
++++++++++++++++++
> arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi |  193 =
+++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi  |   59 ++++++++
> arch/powerpc/platforms/85xx/Kconfig           |    9 ++
> arch/powerpc/platforms/85xx/Makefile          |    1 +
> arch/powerpc/platforms/85xx/bsc913x_rdb.c     |   95 ++++++++++++
> 7 files changed, 533 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dts
> create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi
> create mode 100644 arch/powerpc/platforms/85xx/bsc913x_rdb.c

[ Fix commit message so it wraps at 76 char columns=20


> diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi =
b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> new file mode 100644
> index 0000000..8906562
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> @@ -0,0 +1,142 @@
> +/*
> + * BSC9131 RDB Device Tree Source stub (no addresses or top-level =
ranges)
> + *
> + * Copyright 2011-2012 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions =
are met:
> + *     * Redistributions of source code must retain the above =
copyright
> + *       notice, this list of conditions and the following =
disclaimer.
> + *     * Redistributions in binary form must reproduce the above =
copyright
> + *       notice, this list of conditions and the following disclaimer =
in the
> + *       documentation and/or other materials provided with the =
distribution.
> + *     * Neither the name of Freescale Semiconductor nor the
> + *       names of its contributors may be used to endorse or promote =
products
> + *       derived from this software without specific prior written =
permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of =
the
> + * GNU General Public License ("GPL") as published by the Free =
Software
> + * Foundation, either version 2 of that License or (at your option) =
any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND =
ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE =
IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE =
ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE =
FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL =
DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR =
SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER =
CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, =
OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE =
USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +&board_ifc {
> +
> +	nand@0,0 {
> +		#address-cells =3D <1>;
> +		#size-cells =3D <1>;
> +		compatible =3D "fsl,ifc-nand";
> +		reg =3D <0x0 0x0 0x4000>;
> +
> +		partition@0 {
> +			/* This location must not be altered  */
> +			/* 3MB for u-boot Bootloader Image */
> +			reg =3D <0x0 0x00300000>;
> +			label =3D "NAND U-Boot Image";
> +			read-only;
> +		};
> +
> +		partition@300000 {
> +			/* 1MB for DTB Image */
> +			reg =3D <0x00300000 0x00100000>;
> +			label =3D "NAND DTB Image";
> +		};
> +
> +		partition@400000 {
> +			/* 8MB for Linux Kernel Image */
> +			reg =3D <0x00400000 0x00800000>;
> +			label =3D "NAND Linux Kernel Image";
> +		};
> +
> +		partition@c00000 {
> +			/* Rest space for Root file System Image */
> +			reg =3D <0x00c00000 0x07400000>;
> +			label =3D " NAND RFS Image";

extra white space on label string

> +		};
> +	};
> +};
> +
> +&board_soc {
> +	/* BSC9131RDB does not have any device on i2c@3100 */
> +	i2c@3100 {
> +		status =3D "disabled";
> +	};
> +
> +	spi@7000 {
> +		flash@0 {
> +			#address-cells =3D <1>;
> +			#size-cells =3D <1>;
> +			compatible =3D "spansion,s25sl12801";
> +			reg =3D <0>;
> +			spi-max-frequency =3D <50000000>;
> +
> +			/* 512KB for u-boot Bootloader Image */
> +			partition@0 {
> +				reg =3D <0x0 0x00080000>;
> +				label =3D "SPI Flash U-Boot Image";
> +				read-only;
> +			};
> +
> +			/* 512KB for DTB Image */
> +			partition@80000 {
> +				reg =3D <0x00080000 0x00080000>;
> +				label =3D "SPI Flash DTB Image";
> +			};
> +
> +			/* 4MB for Linux Kernel Image */
> +			partition@100000 {
> +				reg =3D <0x00100000 0x00400000>;
> +				label =3D "SPI Flash Kernel Image";
> +			};
> +
> +			/*11MB for RFS Image */
> +			partition@500000 {
> +				reg =3D <0x00500000 0x00B00000>;
> +				label =3D "SPI Flash RFS Image";
> +			};
> +
> +		};
> +	};
> +
> +	usb@22000 {
> +		phy_type =3D "ulpi";
> +	};
> +
> +	mdio@24000 {
> +		phy0: ethernet-phy@0 {
> +			interrupts =3D <3 1 0 0>;
> +			reg =3D <0x0>;
> +		};
> +
> +		phy1: ethernet-phy@1 {
> +			interrupts =3D <2 1 0 0>;
> +			reg =3D <0x3>;
> +		};
> +	};
> +
> +	sdhci@2e000 {
> +		status =3D "disabled";
> +	};
> +
> +	enet0: ethernet@b0000 {
> +		phy-handle =3D <&phy0>;
> +		phy-connection-type =3D "rgmii-id";
> +	};
> +
> +	enet1: ethernet@b1000 {
> +		phy-handle =3D <&phy1>;
> +		phy-connection-type =3D "rgmii-id";
> +	};
> +};

[snip]

> diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c =
b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> new file mode 100644
> index 0000000..611c289
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> @@ -0,0 +1,95 @@
> +/*
> + * BSC913xRDB Board Setup
> + *
> + * Author: Priyanka Jain <Priyanka.Jain@freescale.com>
> + *
> + * Copyright 2011-2012 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.
> + */
> +
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <asm/mpic.h>
> +#include <sysdev/fsl_soc.h>
> +#include <asm/udbg.h>
> +
> +void __init bsc913x_rdb_pic_init(void)
> +{
> +	struct mpic *mpic;
> +	struct resource r;
> +	struct device_node *np;
> +
> +	np =3D of_find_node_by_type(NULL, "open-pic");
> +	if (!np) {
> +		pr_err("bsc913x: Could not find open-pic node\n");
> +		return;
> +	}
> +
> +	if (of_address_to_resource(np, 0, &r)) {
> +		pr_err("bsc913x: Failed to map mpic register space\n");
> +		of_node_put(np);
> +		return;
> +	}
> +
> +	mpic =3D mpic_alloc(np, r.start, MPIC_WANTS_RESET |
> +	  MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS | =
MPIC_SINGLE_DEST_CPU,
> +	  0, 256, " OpenPIC  ");
> +
> +	of_node_put(np);
> +
> +	if (!mpic)
> +		pr_err("bsc913x: Failed to allocate MPIC structure\n");
> +	else
> +		mpic_init(mpic);
> +}
> +

This code is still out of date w/other board ports.  Have you tried =
building this against upstream??

> +/*
> + * Setup the architecture
> + */
> +static void __init bsc913x_rdb_setup_arch(void)
> +{
> +	if (ppc_md.progress)
> +		ppc_md.progress("bsc913x_rdb_setup_arch()", 0);
> +
> +	pr_info("bsc913x board from Freescale Semiconductor\n");
> +}
> +
> +static struct of_device_id __initdata bsc913x_rdb_ids[] =3D {
> +	{ .type =3D "soc", },
> +	{ .compatible =3D "soc", },
> +	{ .compatible =3D "simple-bus", },
> +	{ .compatible =3D "gianfar", },
> +	{},
> +};
> +
> +static int __init bsc913x_rdb_publish_devices(void)
> +{
> +	return of_platform_bus_probe(NULL, bsc913x_rdb_ids, NULL);
> +}
> +machine_device_initcall(bsc9131_rdb, bsc913x_rdb_publish_devices);
> +
> +/*
> + * Called very early, device-tree isn't unflattened
> + */
> +
> +static int __init bsc9131_rdb_probe(void)
> +{
> +	unsigned long root =3D of_get_flat_dt_root();
> +
> +	return of_flat_dt_is_compatible(root, "fsl,bsc9131rdb");
> +}
> +
> +define_machine(bsc9131_rdb) {
> +	.name			=3D "BSC9131 RDB",
> +	.probe			=3D bsc9131_rdb_probe,
> +	.setup_arch		=3D bsc913x_rdb_setup_arch,
> +	.init_IRQ		=3D bsc913x_rdb_pic_init,
> +	.get_irq		=3D mpic_get_irq,
> +	.restart		=3D fsl_rstcr_restart,
> +	.calibrate_decr		=3D generic_calibrate_decr,
> +	.progress		=3D udbg_progress,
> +};
> --=20
> 1.7.5.4
>=20
>=20
>=20
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

^ permalink raw reply

* Re: [PATCH] corenet64_smp_defconfig:Added I2C_CHARDEV and I2C_MPC options in defconfig to have compiled I2C device interface
From: Kumar Gala @ 2012-03-21 17:21 UTC (permalink / raw)
  To: Shaveta Leekha; +Cc: linuxppc-dev
In-Reply-To: <1331974736-14450-1-git-send-email-shaveta@freescale.com>


On Mar 17, 2012, at 3:58 AM, Shaveta Leekha wrote:

> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
> arch/powerpc/configs/corenet64_smp_defconfig |    2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)

applied, squashed to a single commit for all 4 and updated commit message

- k

^ permalink raw reply

* Re: [PATCH] powerpc/epapr: add "memory" as a clobber to all hypercalls
From: Kumar Gala @ 2012-03-21 17:21 UTC (permalink / raw)
  To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1331851262-1806-1-git-send-email-timur@freescale.com>


On Mar 15, 2012, at 5:41 PM, Timur Tabi wrote:

> The "memory" clobber tells the compiler to ensure that all writes to =
memory
> are committed before the hypercall is made.
>=20
> "memory" is only necessary for hcalls where the Hypervisor will read =
or
> write guest memory. However, we add it to all hcalls because the =
impact is
> minimal, and we want to ensure that it's present for the hcalls that =
need it.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/include/asm/epapr_hcalls.h |    7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)

applied

- k=

^ permalink raw reply

* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Kumar Gala @ 2012-03-21 17:21 UTC (permalink / raw)
  To: Jia Hongtao; +Cc: meador_inge, linuxppc-dev
In-Reply-To: <1329446943-9732-2-git-send-email-B38951@freescale.com>


On Feb 16, 2012, at 8:49 PM, Jia Hongtao wrote:

> Some MPIC implementations contain one or more blocks of message =
registers
> that are used to send messages between cores via IPIs.  A simple API =
has
> been added to access (get/put, read, write, etc ...) these message =
registers.
> The available message registers are initially discovered via nodes in =
the
> device tree.  A separate commit contains a binding for the message =
register
> nodes.
>=20
> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> This patch is an update for : http://patchwork.ozlabs.org/patch/98075/
>=20
> Meador Inge addressed the following points from Ben's feedback:
> * Drop the 'mpic_msgr.msr' field.
> * Drop the 'mpic_msgr.mer' field in favor of address arithmetic off of =
 'mpic_msgr.addr'.
> * Document the API.
> * Disable MPIC register in 'mpic_msgr_put'.
> * Put locking in 'mpic_msgr_disable'.
> * s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/g.
> * Make 'mpic_msgr_write' and 'mpic_msgr_read' 'static inline'.
>=20
> I just fixed the checkpatch errors and addressed the following item:
> * In 'mpic_msgr_set_destination' have a wrapper that goes from Linux
>  CPU number to HW CPU number.
>=20
> arch/powerpc/include/asm/mpic_msgr.h |  132 ++++++++++++++++
> arch/powerpc/platforms/Kconfig       |    8 +
> arch/powerpc/sysdev/Makefile         |    2 +
> arch/powerpc/sysdev/mpic_msgr.c      |  282 =
++++++++++++++++++++++++++++++++++
> 4 files changed, 424 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/include/asm/mpic_msgr.h
> create mode 100644 arch/powerpc/sysdev/mpic_msgr.c

applied

- k=

^ permalink raw reply

* Re: [PATCH] powerpc/dts: Removed fsl,msi property from dts.
From: Kumar Gala @ 2012-03-21 17:21 UTC (permalink / raw)
  To: Diana Craciun; +Cc: linuxppc-dev
In-Reply-To: <1328794860-12592-1-git-send-email-diana.craciun@freescale.com>


On Feb 9, 2012, at 7:41 AM, Diana Craciun wrote:

> From: Diana CRACIUN <Diana.Craciun@freescale.com>
> 
> The association in the decice tree between PCI and MSI
> using fsl,msi property was an artificial one and it does
> not reflect the actual hardware.
> 
> Signed-off-by: Diana CRACIUN <Diana.Craciun@freescale.com>
> ---
> arch/powerpc/boot/dts/p2041rdb.dts |    3 ---
> arch/powerpc/boot/dts/p3041ds.dts  |    4 ----
> arch/powerpc/boot/dts/p3060qds.dts |    2 --
> arch/powerpc/boot/dts/p4080ds.dts  |    3 ---
> arch/powerpc/boot/dts/p5020ds.dts  |    4 ----
> 5 files changed, 0 insertions(+), 16 deletions(-)

applied

- k

^ permalink raw reply

* Re: [PATCH 4/4 v2] powerpc/85xx: add the P1020UTM-PC DTS support
From: Kumar Gala @ 2012-03-21 17:22 UTC (permalink / raw)
  To: <Chang-Ming.Huang@freescale.com>; +Cc: linuxppc-dev
In-Reply-To: <1332224685-1012-2-git-send-email-Chang-Ming.Huang@freescale.com>


On Mar 20, 2012, at 1:24 AM, <Chang-Ming.Huang@freescale.com> =
<Chang-Ming.Huang@freescale.com> wrote:

> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>=20
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
> changes for v2:
> 	- remove the lable "read-only" for DTB and kernel partition
> 	- remove the word "RO" or "RW" from the "lable" option
>=20
> arch/powerpc/boot/dts/p1020utm-pc.dtsi    |  140 =
+++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/p1020utm-pc_32b.dts |   89 ++++++++++++++++++
> arch/powerpc/boot/dts/p1020utm-pc_36b.dts |   89 ++++++++++++++++++
> 3 files changed, 318 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1020utm-pc.dtsi
> create mode 100644 arch/powerpc/boot/dts/p1020utm-pc_32b.dts
> create mode 100644 arch/powerpc/boot/dts/p1020utm-pc_36b.dts

applied

- k=

^ permalink raw reply

* Re: [PATCH] [v3] powerpc/8xxx: remove 85xx/86xx restrictions from fsl_guts.h
From: Kumar Gala @ 2012-03-21 17:22 UTC (permalink / raw)
  To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <1332173199-25877-1-git-send-email-timur@freescale.com>


On Mar 19, 2012, at 11:06 AM, Timur Tabi wrote:

> Remove the check for CONFIG_PPC_85xx and CONFIG_PPC_86xx from =
fsl_guts.h.
> The check was originally intended to allow the same header file to
> be used on 85xx and 86xx systems, even though the Global Utilities
> register could be different.  It turns out that they're not actually
> different, and so the check is not necessary.  In addition, neither
> macro is defined for 64-bit e5500 kernels, so that causes a build
> break.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> The ASoC part of this patch applies cleanly to the ASoC for-3.4 =
branch,
> so this patch should not cause any merge conflicts if carried on the
> PowerPC branch, so I suggest that Kumar pick this up for 3.4 (it fixes =
a
> potential 64-bit book-e build break), with an ACK from Mark.=20
>=20
> arch/powerpc/include/asm/fsl_guts.h        |   26 =
+++++---------------------
> arch/powerpc/platforms/85xx/mpc85xx_mds.c  |    2 +-
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |    2 +-
> arch/powerpc/platforms/85xx/p1022_ds.c     |    4 ++--
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c |    2 +-
> sound/soc/fsl/mpc8610_hpcd.c               |    8 ++++----
> sound/soc/fsl/p1022_ds.c                   |   10 +++++-----
> 7 files changed, 19 insertions(+), 35 deletions(-)

applied

- k=

^ permalink raw reply

* Re: [PATCH 3/4 v2] powerpc/85xx: add the P1020MBG-PC DTS support
From: Kumar Gala @ 2012-03-21 17:22 UTC (permalink / raw)
  To: <Chang-Ming.Huang@freescale.com>; +Cc: linuxppc-dev
In-Reply-To: <1332224685-1012-1-git-send-email-Chang-Ming.Huang@freescale.com>


On Mar 20, 2012, at 1:24 AM, <Chang-Ming.Huang@freescale.com> =
<Chang-Ming.Huang@freescale.com> wrote:

> From: Jerry Huang <Chang-Ming.Huang@freescale.com>
>=20
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> ---
> changes for v2:
> 	- remove the lable "read-only" for DTB and kernel partition
> 	- remove the word "RO" or "RW" from the "lable" option
>=20
> arch/powerpc/boot/dts/p1020mbg-pc.dtsi    |  151 =
+++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/p1020mbg-pc_32b.dts |   89 +++++++++++++++++
> arch/powerpc/boot/dts/p1020mbg-pc_36b.dts |   89 +++++++++++++++++
> 3 files changed, 329 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc.dtsi
> create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
> create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc_36b.dts

applied

- k=

^ permalink raw reply

* Re: [PATCH v2] powerpc: document the FSL MPIC message register binding
From: Kumar Gala @ 2012-03-21 17:22 UTC (permalink / raw)
  To: Jia Hongtao; +Cc: linuxppc-dev
In-Reply-To: <1330594354-31095-1-git-send-email-B38951@freescale.com>


On Mar 1, 2012, at 3:32 AM, Jia Hongtao wrote:

> This binding documents how the message register blocks found in some FSL
> MPIC implementations shall be represented in a device tree.
> 
> Signed-off-by: Meador Inge <meador_inge@mentor.com>
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> ---
> Changes for v2:
> * Update compatible type from <string> to <string-list>.
> * Update interrupts description.
> * Update mpic-msgr-receive-mask description.

applied

- k

^ permalink raw reply

* RE: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
From: Kushwaha Prabhakar-B32579 @ 2012-03-21 17:29 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Srivastava Rajan-B34330, Mehresh Ramneek-B31383,
	Goyal Akhil-B35197, linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, Jain Priyanka-B32167
In-Reply-To: <6E492C67-B422-46B2-9A8E-C1E9B6C534E7@kernel.crashing.org>

Hi Kumar,

Thanks for reviewing it.
Please find my response in-lined.

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 10:51 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.org;
> Jain Priyanka-B32167; Mehresh Ramneek-B31383; Srivastava Rajan-B34330;
> Goyal Akhil-B35197
> Subject: Re: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
>=20
>=20
> On Mar 17, 2012, at 3:39 AM, Prabhakar Kushwaha wrote:
>=20
> > BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The
> > BSC9131 is integrated SoC that targets Femto base station market. It
> > combines Power Architecture e500v2 and DSP StarCore SC3850 core
> > technologies with MAPLE-B2F baseband acceleration processing elements.
> >
> > The BSC9131 SoC includes the following function and features:
> >    . Power Architecture subsystem including a e500 processor with 256-
> Kbyte shared
> >      L2 cache
> >    . StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache
> >    . The Multi Accelerator Platform Engine for Femto BaseStation
> Baseband
> >      Processing (MAPLE-B2F)
> >    . A multi-standard baseband algorithm accelerator for Channel
> Decoding/Encoding,
> >      Fourier Transforms, UMTS chip rate processing, LTE UP/DL Channel
> processing,
> >      and CRC algorithms
> >    . Consists of accelerators for Convolution, Filtering, Turbo
> Encoding,
> >      Turbo Decoding, Viterbi decoding, Chiprate processing, and Matrix
> Inversion
> >      operations
> >    . DDR3/3L memory interface with 32-bit data width without ECC and
> 16-bit with
> >      ECC, up to 400-MHz clock/800 MHz data rate
> >    . Dedicated security engine featuring trusted boot
> >    . DMA controller
> >    . OCNDMA with four bidirectional channels
> >    . Interfaces
> >    . Two triple-speed Gigabit Ethernet controllers featuring network
> acceleration
> >      including IEEE 1588. v2 hardware support and virtualization
> (eTSEC)
> >    . eTSEC 1 supports RGMII/RMII
> >    . eTSEC 2 supports RGMII
> >    . High-speed USB 2.0 host and device controller with ULPI interface
> >    . Enhanced secure digital (SD/MMC) host controller (eSDHC)
> >    . Antenna interface controller (AIC), supporting three industry
> standard
> >      JESD207/three custom ADI RF interfaces (two dual port and one
> single port)
> >      and three MAXIM's MaxPHY serial interfaces
> >    . ADI lanes support both full duplex FDD support and half duplex TDD
> support
> >    . Universal Subscriber Identity Module (USIM) interface that
> facilitates
> >      communication to SIM cards or Eurochip pre-paid phone cards
> >    . TDM with one TDM port
> >    . Two DUART, four eSPI, and two I2C controllers
> >    . Integrated Flash memory controller (IFC)
> >    . TDM with 256 channels
> >    . GPIO
> >    . Sixteen 32-bit timers
> >
> > The DSP portion of the SoC consists of DSP core (SC3850) and various
> > accelerators pertaining to DSP operations.
> >
> > BSC9131RDB Overview
> > ----------------------
> >     BSC9131 SoC
> >     1Gbyte DDR3 (on board DDR)
> >     128Mbyte 2K page size NAND Flash
> >     256 Kbit M24256 I2C EEPROM
> >     128 Mbit SPI Flash memory
> >     USB-ULPI
> >     eTSEC1: Connected to RGMII PHY
> >     eTSEC2: Connected to RGMII PHY
> >     DUART interface: supports one UARTs up to 115200 bps for console
> > display
> >
> > Linux runs on e500v2 core and access some DSP peripherals like AIC
> >
> > Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> > Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> > Signed-off-by: Akhil Goyal <Akhil.Goyal@freescale.com>
> > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> > Signed-off-by: Rajan Srivastava <rajan.srivastava@freescale.com>
> > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > ---
> > Note:   Name of PSC9131 has been changed to BSC9131 because of new
> nomenclature
> > 	Please reject earlier patch"powerpc/85xx:Add PSC9131 RDB Support"
> > 	  http://patchwork.ozlabs.org/patch/146349/
> >
> > Beased on
> http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> > 	    branch master
> >
> > Changes for v2:
> > 	- Change board file name as bsc913x_rdb.c
> > 	- Removed all I2C's board device. A separate patch will be send.
> > 	- Combined SPI's 2 RFS partition into single RFS parition
> > 	- Added SEC/crypto node in dts
> >
> > arch/powerpc/boot/dts/bsc9131rdb.dts          |   34 +++++
> > arch/powerpc/boot/dts/bsc9131rdb.dtsi         |  142 ++++++++++++++++++
> > arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi |  193
> +++++++++++++++++++++++++
> > arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi  |   59 ++++++++
> > arch/powerpc/platforms/85xx/Kconfig           |    9 ++
> > arch/powerpc/platforms/85xx/Makefile          |    1 +
> > arch/powerpc/platforms/85xx/bsc913x_rdb.c     |   95 ++++++++++++
> > 7 files changed, 533 insertions(+), 0 deletions(-) create mode 100644
> > arch/powerpc/boot/dts/bsc9131rdb.dts
> > create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
> > create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi
> > create mode 100644 arch/powerpc/platforms/85xx/bsc913x_rdb.c
>=20
> [ Fix commit message so it wraps at 76 char columns
>=20

I am not getting. Can you please tell more

>=20
> > diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > new file mode 100644
> > index 0000000..8906562
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > @@ -0,0 +1,142 @@
> > +/*
> > + * BSC9131 RDB Device Tree Source stub (no addresses or top-level
> > +ranges)
> > + *
> > + * Copyright 2011-2012 Freescale Semiconductor Inc.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> are met:
> > + *     * Redistributions of source code must retain the above
> copyright
> > + *       notice, this list of conditions and the following disclaimer.
> > + *     * Redistributions in binary form must reproduce the above
> copyright
> > + *       notice, this list of conditions and the following disclaimer
> in the
> > + *       documentation and/or other materials provided with the
> distribution.
> > + *     * Neither the name of Freescale Semiconductor nor the
> > + *       names of its contributors may be used to endorse or promote
> products
> > + *       derived from this software without specific prior written
> permission.
> > + *
> > + *
> > + * ALTERNATIVELY, this software may be distributed under the terms of
> > +the
> > + * GNU General Public License ("GPL") as published by the Free
> > +Software
> > + * Foundation, either version 2 of that License or (at your option)
> > +any
> > + * later version.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND
> > +ANY
> > + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > +IMPLIED
> > + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> > +ARE
> > + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE
> > +FOR ANY
> > + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> > +DAMAGES
> > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> > +SERVICES;
> > + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> > +CAUSED AND
> > + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> > +OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > +USE OF THIS
> > + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +&board_ifc {
> > +
> > +	nand@0,0 {
> > +		#address-cells =3D <1>;
> > +		#size-cells =3D <1>;
> > +		compatible =3D "fsl,ifc-nand";
> > +		reg =3D <0x0 0x0 0x4000>;
> > +
> > +		partition@0 {
> > +			/* This location must not be altered  */
> > +			/* 3MB for u-boot Bootloader Image */
> > +			reg =3D <0x0 0x00300000>;
> > +			label =3D "NAND U-Boot Image";
> > +			read-only;
> > +		};
> > +
> > +		partition@300000 {
> > +			/* 1MB for DTB Image */
> > +			reg =3D <0x00300000 0x00100000>;
> > +			label =3D "NAND DTB Image";
> > +		};
> > +
> > +		partition@400000 {
> > +			/* 8MB for Linux Kernel Image */
> > +			reg =3D <0x00400000 0x00800000>;
> > +			label =3D "NAND Linux Kernel Image";
> > +		};
> > +
> > +		partition@c00000 {
> > +			/* Rest space for Root file System Image */
> > +			reg =3D <0x00c00000 0x07400000>;
> > +			label =3D " NAND RFS Image";
>=20
> extra white space on label string
>=20

Sure. I will change

> > +		};
> > +	};
> > +};
> > +
> > +&board_soc {
> > +	/* BSC9131RDB does not have any device on i2c@3100 */
> > +	i2c@3100 {
> > +		status =3D "disabled";
> > +	};
> > +
> > +	spi@7000 {
> > +		flash@0 {
> > +			#address-cells =3D <1>;
> > +			#size-cells =3D <1>;
> > +			compatible =3D "spansion,s25sl12801";
> > +			reg =3D <0>;
> > +			spi-max-frequency =3D <50000000>;
> > +
> > +			/* 512KB for u-boot Bootloader Image */
> > +			partition@0 {
> > +				reg =3D <0x0 0x00080000>;
> > +				label =3D "SPI Flash U-Boot Image";
> > +				read-only;
> > +			};
> > +
> > +			/* 512KB for DTB Image */
> > +			partition@80000 {
> > +				reg =3D <0x00080000 0x00080000>;
> > +				label =3D "SPI Flash DTB Image";
> > +			};
> > +
> > +			/* 4MB for Linux Kernel Image */
> > +			partition@100000 {
> > +				reg =3D <0x00100000 0x00400000>;
> > +				label =3D "SPI Flash Kernel Image";
> > +			};
> > +
> > +			/*11MB for RFS Image */
> > +			partition@500000 {
> > +				reg =3D <0x00500000 0x00B00000>;
> > +				label =3D "SPI Flash RFS Image";
> > +			};
> > +
> > +		};
> > +	};
> > +
> > +	usb@22000 {
> > +		phy_type =3D "ulpi";
> > +	};
> > +
> > +	mdio@24000 {
> > +		phy0: ethernet-phy@0 {
> > +			interrupts =3D <3 1 0 0>;
> > +			reg =3D <0x0>;
> > +		};
> > +
> > +		phy1: ethernet-phy@1 {
> > +			interrupts =3D <2 1 0 0>;
> > +			reg =3D <0x3>;
> > +		};
> > +	};
> > +
> > +	sdhci@2e000 {
> > +		status =3D "disabled";
> > +	};
> > +
> > +	enet0: ethernet@b0000 {
> > +		phy-handle =3D <&phy0>;
> > +		phy-connection-type =3D "rgmii-id";
> > +	};
> > +
> > +	enet1: ethernet@b1000 {
> > +		phy-handle =3D <&phy1>;
> > +		phy-connection-type =3D "rgmii-id";
> > +	};
> > +};
>=20
> [snip]
>=20

??
Not getting you..

> > diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> > b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> > new file mode 100644
> > index 0000000..611c289
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> > @@ -0,0 +1,95 @@
> > +/*
> > + * BSC913xRDB Board Setup
> > + *
> > + * Author: Priyanka Jain <Priyanka.Jain@freescale.com>
> > + *
> > + * Copyright 2011-2012 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.
> > + */
> > +
> > +#include <linux/of_platform.h>
> > +#include <linux/pci.h>
> > +#include <asm/mpic.h>
> > +#include <sysdev/fsl_soc.h>
> > +#include <asm/udbg.h>
> > +
> > +void __init bsc913x_rdb_pic_init(void) {
> > +	struct mpic *mpic;
> > +	struct resource r;
> > +	struct device_node *np;
> > +
> > +	np =3D of_find_node_by_type(NULL, "open-pic");
> > +	if (!np) {
> > +		pr_err("bsc913x: Could not find open-pic node\n");
> > +		return;
> > +	}
> > +
> > +	if (of_address_to_resource(np, 0, &r)) {
> > +		pr_err("bsc913x: Failed to map mpic register space\n");
> > +		of_node_put(np);
> > +		return;
> > +	}
> > +
> > +	mpic =3D mpic_alloc(np, r.start, MPIC_WANTS_RESET |
> > +	  MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS | MPIC_SINGLE_DEST_CPU,
> > +	  0, 256, " OpenPIC  ");
> > +
> > +	of_node_put(np);
> > +
> > +	if (!mpic)
> > +		pr_err("bsc913x: Failed to allocate MPIC structure\n");
> > +	else
> > +		mpic_init(mpic);
> > +}
> > +
>=20
> This code is still out of date w/other board ports.  Have you tried
> building this against upstream??
>=20

I build with powerpc.git.=20
do you mean build with upstream code base ??
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git


--Prabhakar

^ permalink raw reply

* Re: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
From: Kumar Gala @ 2012-03-21 17:38 UTC (permalink / raw)
  To: Kushwaha Prabhakar-B32579
  Cc: Srivastava Rajan-B34330, Mehresh Ramneek-B31383,
	Goyal Akhil-B35197, linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, Jain Priyanka-B32167
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F8745B28E5@039-SN1MPN1-004.039d.mgd.msft.net>


On Mar 21, 2012, at 12:29 PM, Kushwaha Prabhakar-B32579 wrote:

>>=20
>>=20
>> [snip]
>>=20
>=20
> ??
> Not getting you..

Just meant, I was removing parts of the patch in the email to reduce =
things.

>=20
>>> diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c
>>> b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
>>> new file mode 100644
>>> index 0000000..611c289
>>> --- /dev/null
>>> +++ b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
>>> @@ -0,0 +1,95 @@
>>> +/*
>>> + * BSC913xRDB Board Setup
>>> + *
>>> + * Author: Priyanka Jain <Priyanka.Jain@freescale.com>
>>> + *
>>> + * Copyright 2011-2012 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.
>>> + */
>>> +
>>> +#include <linux/of_platform.h>
>>> +#include <linux/pci.h>
>>> +#include <asm/mpic.h>
>>> +#include <sysdev/fsl_soc.h>
>>> +#include <asm/udbg.h>
>>> +
>>> +void __init bsc913x_rdb_pic_init(void) {
>>> +	struct mpic *mpic;
>>> +	struct resource r;
>>> +	struct device_node *np;
>>> +
>>> +	np =3D of_find_node_by_type(NULL, "open-pic");
>>> +	if (!np) {
>>> +		pr_err("bsc913x: Could not find open-pic node\n");
>>> +		return;
>>> +	}
>>> +
>>> +	if (of_address_to_resource(np, 0, &r)) {
>>> +		pr_err("bsc913x: Failed to map mpic register space\n");
>>> +		of_node_put(np);
>>> +		return;
>>> +	}
>>> +
>>> +	mpic =3D mpic_alloc(np, r.start, MPIC_WANTS_RESET |
>>> +	  MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS | =
MPIC_SINGLE_DEST_CPU,
>>> +	  0, 256, " OpenPIC  ");
>>> +
>>> +	of_node_put(np);
>>> +
>>> +	if (!mpic)
>>> +		pr_err("bsc913x: Failed to allocate MPIC structure\n");
>>> +	else
>>> +		mpic_init(mpic);
>>> +}
>>> +
>>=20
>> This code is still out of date w/other board ports.  Have you tried
>> building this against upstream??
>>=20
>=20
> I build with powerpc.git.=20
> do you mean build with upstream code base ??
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>=20

I mean if you use my 'next' branch of galak/powerpc.git and apply this =
patch, and enable it.  For example MPIC_BROKEN_FRR_NIRQS doesn't exist =
anymore

- k

^ permalink raw reply

* RE: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
From: Kushwaha Prabhakar-B32579 @ 2012-03-21 17:45 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Srivastava Rajan-B34330, Mehresh Ramneek-B31383,
	Goyal Akhil-B35197, linuxppc-dev@lists.ozlabs.org,
	devicetree-discuss@lists.ozlabs.org, Jain Priyanka-B32167
In-Reply-To: <F67F01CF-E431-42B7-BA59-EBC6A792FC69@kernel.crashing.org>

Thanks Kumar for clarifying my doubts.

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 11:08 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.org;
> Jain Priyanka-B32167; Mehresh Ramneek-B31383; Srivastava Rajan-B34330;
> Goyal Akhil-B35197
> Subject: Re: [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
>=20
>=20
> On Mar 21, 2012, at 12:29 PM, Kushwaha Prabhakar-B32579 wrote:
>=20
> >>
> >>
> >> [snip]
> >>
> >
> > ??
> > Not getting you..
>=20
> Just meant, I was removing parts of the patch in the email to reduce
> things.
>=20

Oh :)


> >
> >>> diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> >>> b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> >>> new file mode 100644
> >>> index 0000000..611c289
> >>> --- /dev/null
> >>> +++ b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
> >>> @@ -0,0 +1,95 @@
> >>> +/*
> >>> + * BSC913xRDB Board Setup
> >>> + *
> >>> + * Author: Priyanka Jain <Priyanka.Jain@freescale.com>
> >>> + *
> >>> + * Copyright 2011-2012 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.
> >>> + */
> >>> +
> >>> +#include <linux/of_platform.h>
> >>> +#include <linux/pci.h>
> >>> +#include <asm/mpic.h>
> >>> +#include <sysdev/fsl_soc.h>
> >>> +#include <asm/udbg.h>
> >>> +
> >>> +void __init bsc913x_rdb_pic_init(void) {
> >>> +	struct mpic *mpic;
> >>> +	struct resource r;
> >>> +	struct device_node *np;
> >>> +
> >>> +	np =3D of_find_node_by_type(NULL, "open-pic");
> >>> +	if (!np) {
> >>> +		pr_err("bsc913x: Could not find open-pic node\n");
> >>> +		return;
> >>> +	}
> >>> +
> >>> +	if (of_address_to_resource(np, 0, &r)) {
> >>> +		pr_err("bsc913x: Failed to map mpic register space\n");
> >>> +		of_node_put(np);
> >>> +		return;
> >>> +	}
> >>> +
> >>> +	mpic =3D mpic_alloc(np, r.start, MPIC_WANTS_RESET |
> >>> +	  MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS | MPIC_SINGLE_DEST_CPU,
> >>> +	  0, 256, " OpenPIC  ");
> >>> +
> >>> +	of_node_put(np);
> >>> +
> >>> +	if (!mpic)
> >>> +		pr_err("bsc913x: Failed to allocate MPIC structure\n");
> >>> +	else
> >>> +		mpic_init(mpic);
> >>> +}
> >>> +
> >>
> >> This code is still out of date w/other board ports.  Have you tried
> >> building this against upstream??
> >>
> >
> > I build with powerpc.git.
> > do you mean build with upstream code base ??
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
>=20
> I mean if you use my 'next' branch of galak/powerpc.git and apply this
> patch, and enable it.  For example MPIC_BROKEN_FRR_NIRQS doesn't exist
> anymore
>=20


I did on master branch. I will check on "next" branch and if required send =
new patch version.

--Prabhakar

^ permalink raw reply

* Re: [PATCH 12/38] powerpc/booke: Provide exception macros with interrupt name
From: Kumar Gala @ 2012-03-21 18:04 UTC (permalink / raw)
  To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330474206-14794-13-git-send-email-agraf@suse.de>


On Feb 28, 2012, at 6:09 PM, Alexander Graf wrote:

> From: Scott Wood <scottwood@freescale.com>
>=20
> DO_KVM will need to identify the particular exception type.
>=20
> There is an existing set of arbitrary numbers that Linux passes,
> but it's an undocumented mess that sort of corresponds to =
server/classic
> exception vectors but not really.

So what do the new names correspond to?  What header is defining =
MACHINE_CHECK, BOOKE_INTERRUPT_EXTERNAL, etc (asm/kvm_asm.h)?  If so we =
really should move these out of asm/kvm_asm.h and into something a bit =
more appropriate.

> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> arch/powerpc/kernel/head_44x.S       |   23 +++++++++------
> arch/powerpc/kernel/head_booke.h     |   41 ++++++++++++++------------
> arch/powerpc/kernel/head_fsl_booke.S |   52 =
+++++++++++++++++++++-------------
> 3 files changed, 68 insertions(+), 48 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/head_44x.S =
b/arch/powerpc/kernel/head_44x.S
> index 7dd2981..d1192c5 100644
> --- a/arch/powerpc/kernel/head_44x.S
> +++ b/arch/powerpc/kernel/head_44x.S
> @@ -248,10 +248,11 @@ _ENTRY(_start);
>=20
> interrupt_base:
> 	/* Critical Input Interrupt */
> -	CRITICAL_EXCEPTION(0x0100, CriticalInput, unknown_exception)
> +	CRITICAL_EXCEPTION(0x0100, CRITICAL, CriticalInput, =
unknown_exception)
>=20
> 	/* Machine Check Interrupt */
> -	CRITICAL_EXCEPTION(0x0200, MachineCheck, =
machine_check_exception)
> +	CRITICAL_EXCEPTION(0x0200, MACHINE_CHECK, MachineCheck, \
> +			   machine_check_exception)
> 	MCHECK_EXCEPTION(0x0210, MachineCheckA, machine_check_exception)
>=20
> 	/* Data Storage Interrupt */
> @@ -261,7 +262,8 @@ interrupt_base:
> 	INSTRUCTION_STORAGE_EXCEPTION
>=20
> 	/* External Input Interrupt */
> -	EXCEPTION(0x0500, ExternalInput, do_IRQ, EXC_XFER_LITE)
> +	EXCEPTION(0x0500, BOOKE_INTERRUPT_EXTERNAL, ExternalInput, \
> +		  do_IRQ, EXC_XFER_LITE)
>=20
> 	/* Alignment Interrupt */
> 	ALIGNMENT_EXCEPTION
> @@ -273,29 +275,32 @@ interrupt_base:
> #ifdef CONFIG_PPC_FPU
> 	FP_UNAVAILABLE_EXCEPTION
> #else
> -	EXCEPTION(0x2010, FloatingPointUnavailable, unknown_exception, =
EXC_XFER_EE)
> +	EXCEPTION(0x2010, BOOKE_INTERRUPT_FP_UNAVAIL, \
> +		  FloatingPointUnavailable, unknown_exception, =
EXC_XFER_EE)
> #endif
> 	/* System Call Interrupt */
> 	START_EXCEPTION(SystemCall)
> -	NORMAL_EXCEPTION_PROLOG
> +	NORMAL_EXCEPTION_PROLOG(BOOKE_INTERRUPT_SYSCALL)
> 	EXC_XFER_EE_LITE(0x0c00, DoSyscall)
>=20
> 	/* Auxiliary Processor Unavailable Interrupt */
> -	EXCEPTION(0x2020, AuxillaryProcessorUnavailable, =
unknown_exception, EXC_XFER_EE)
> +	EXCEPTION(0x2020, BOOKE_INTERRUPT_AP_UNAVAIL, \
> +		  AuxillaryProcessorUnavailable, unknown_exception, =
EXC_XFER_EE)
>=20
> 	/* Decrementer Interrupt */
> 	DECREMENTER_EXCEPTION
>=20
> 	/* Fixed Internal Timer Interrupt */
> 	/* TODO: Add FIT support */
> -	EXCEPTION(0x1010, FixedIntervalTimer, unknown_exception, =
EXC_XFER_EE)
> +	EXCEPTION(0x1010, BOOKE_INTERRUPT_FIT, FixedIntervalTimer, \
> +		  unknown_exception, EXC_XFER_EE)
>=20
> 	/* Watchdog Timer Interrupt */
> 	/* TODO: Add watchdog support */
> #ifdef CONFIG_BOOKE_WDT
> -	CRITICAL_EXCEPTION(0x1020, WatchdogTimer, WatchdogException)
> +	CRITICAL_EXCEPTION(0x1020, WATCHDOG, WatchdogTimer, =
WatchdogException)
> #else
> -	CRITICAL_EXCEPTION(0x1020, WatchdogTimer, unknown_exception)
> +	CRITICAL_EXCEPTION(0x1020, WATCHDOG, WatchdogTimer, =
unknown_exception)
> #endif
>=20
> 	/* Data TLB Error Interrupt */
> diff --git a/arch/powerpc/kernel/head_booke.h =
b/arch/powerpc/kernel/head_booke.h
> index fc921bf..06ab353 100644
> --- a/arch/powerpc/kernel/head_booke.h
> +++ b/arch/powerpc/kernel/head_booke.h
> @@ -2,6 +2,8 @@
> #define __HEAD_BOOKE_H__
>=20
> #include <asm/ptrace.h>	/* for STACK_FRAME_REGS_MARKER */
> +#include <asm/kvm_asm.h>
> +
> /*
>  * Macros used for common Book-e exception handling
>  */
> @@ -28,7 +30,7 @@
>  */
> #define THREAD_NORMSAVE(offset)	(THREAD_NORMSAVES + (offset * =
4))
>=20
> -#define NORMAL_EXCEPTION_PROLOG						=
     \
> +#define NORMAL_EXCEPTION_PROLOG(intno)					=
	     \
> 	mtspr	SPRN_SPRG_WSCRATCH0, r10;	/* save one register */	 =
    \
> 	mfspr	r10, SPRN_SPRG_THREAD;					 =
    \
> 	stw	r11, THREAD_NORMSAVE(0)(r10);				 =
    \
> @@ -113,7 +115,7 @@
>  * registers as the normal prolog above. Instead we use a portion of =
the
>  * critical/machine check exception stack at low physical addresses.
>  */
> -#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, =
exc_level_srr1) \
> +#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, intno, exc_level_srr0, =
exc_level_srr1) \
> 	mtspr	SPRN_SPRG_WSCRATCH_##exc_level,r8;			 =
    \
> 	BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the =
exc_level stack*/ \
> 	stw	r9,GPR9(r8);		/* save various registers	 =
  */\
> @@ -162,12 +164,13 @@
> 	SAVE_4GPRS(3, r11);						 =
    \
> 	SAVE_2GPRS(7, r11)
>=20
> -#define CRITICAL_EXCEPTION_PROLOG \
> -		EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1)
> +#define CRITICAL_EXCEPTION_PROLOG(intno) \
> +		EXC_LEVEL_EXCEPTION_PROLOG(CRIT, intno, SPRN_CSRR0, =
SPRN_CSRR1)
> #define DEBUG_EXCEPTION_PROLOG \
> -		EXC_LEVEL_EXCEPTION_PROLOG(DBG, SPRN_DSRR0, SPRN_DSRR1)
> +		EXC_LEVEL_EXCEPTION_PROLOG(DBG, DEBUG, SPRN_DSRR0, =
SPRN_DSRR1)
> #define MCHECK_EXCEPTION_PROLOG \
> -		EXC_LEVEL_EXCEPTION_PROLOG(MC, SPRN_MCSRR0, SPRN_MCSRR1)
> +		EXC_LEVEL_EXCEPTION_PROLOG(MC, MACHINE_CHECK, \
> +			SPRN_MCSRR0, SPRN_MCSRR1)
>=20
> /*
>  * Exception vectors.
> @@ -181,16 +184,16 @@ label:
> 	.long	func;						\
> 	.long	ret_from_except_full
>=20
> -#define EXCEPTION(n, label, hdlr, xfer)				=
\
> +#define EXCEPTION(n, intno, label, hdlr, xfer)			=
\
> 	START_EXCEPTION(label);					\
> -	NORMAL_EXCEPTION_PROLOG;				\
> +	NORMAL_EXCEPTION_PROLOG(intno);				\
> 	addi	r3,r1,STACK_FRAME_OVERHEAD;			\
> 	xfer(n, hdlr)
>=20
> -#define CRITICAL_EXCEPTION(n, label, hdlr)			\
> -	START_EXCEPTION(label);					\
> -	CRITICAL_EXCEPTION_PROLOG;				\
> -	addi	r3,r1,STACK_FRAME_OVERHEAD;			\
> +#define CRITICAL_EXCEPTION(n, intno, label, hdlr)			=
\
> +	START_EXCEPTION(label);						=
\
> +	CRITICAL_EXCEPTION_PROLOG(intno);				=
\
> +	addi	r3,r1,STACK_FRAME_OVERHEAD;				=
\
> 	EXC_XFER_TEMPLATE(hdlr, n+2, (MSR_KERNEL & =
~(MSR_ME|MSR_DE|MSR_CE)), \
> 			  NOCOPY, crit_transfer_to_handler, \
> 			  ret_from_crit_exc)
> @@ -302,7 +305,7 @@ label:
>=20
> #define DEBUG_CRIT_EXCEPTION						 =
     \
> 	START_EXCEPTION(DebugCrit);					 =
     \
> -	CRITICAL_EXCEPTION_PROLOG;					 =
     \
> +	CRITICAL_EXCEPTION_PROLOG(DEBUG);				 =
     \
> 									 =
     \
> 	/*								 =
     \
> 	 * If there is a single step or branch-taken exception in an	 =
     \
> @@ -355,7 +358,7 @@ label:
>=20
> #define DATA_STORAGE_EXCEPTION						=
      \
> 	START_EXCEPTION(DataStorage)					 =
     \
> -	NORMAL_EXCEPTION_PROLOG;					 =
     \
> +	NORMAL_EXCEPTION_PROLOG(DATA_STORAGE);		      \
> 	mfspr	r5,SPRN_ESR;		/* Grab the ESR and save it */	 =
     \
> 	stw	r5,_ESR(r11);						 =
     \
> 	mfspr	r4,SPRN_DEAR;		/* Grab the DEAR */		 =
     \
> @@ -363,7 +366,7 @@ label:
>=20
> #define INSTRUCTION_STORAGE_EXCEPTION					 =
     \
> 	START_EXCEPTION(InstructionStorage)				 =
     \
> -	NORMAL_EXCEPTION_PROLOG;					 =
     \
> +	NORMAL_EXCEPTION_PROLOG(INST_STORAGE);		      \
> 	mfspr	r5,SPRN_ESR;		/* Grab the ESR and save it */	 =
     \
> 	stw	r5,_ESR(r11);						 =
     \
> 	mr      r4,r12;                 /* Pass SRR0 as arg2 */		 =
     \
> @@ -372,7 +375,7 @@ label:
>=20
> #define ALIGNMENT_EXCEPTION						 =
     \
> 	START_EXCEPTION(Alignment)					 =
     \
> -	NORMAL_EXCEPTION_PROLOG;					 =
     \
> +	NORMAL_EXCEPTION_PROLOG(ALIGNMENT);		      \
> 	mfspr   r4,SPRN_DEAR;           /* Grab the DEAR and save it */	 =
     \
> 	stw     r4,_DEAR(r11);						 =
     \
> 	addi    r3,r1,STACK_FRAME_OVERHEAD;				 =
     \
> @@ -380,7 +383,7 @@ label:
>=20
> #define PROGRAM_EXCEPTION						 =
     \
> 	START_EXCEPTION(Program)					 =
     \
> -	NORMAL_EXCEPTION_PROLOG;					 =
     \
> +	NORMAL_EXCEPTION_PROLOG(PROGRAM);		      \
> 	mfspr	r4,SPRN_ESR;		/* Grab the ESR and save it */	 =
     \
> 	stw	r4,_ESR(r11);						 =
     \
> 	addi	r3,r1,STACK_FRAME_OVERHEAD;				 =
     \
> @@ -388,7 +391,7 @@ label:
>=20
> #define DECREMENTER_EXCEPTION						 =
     \
> 	START_EXCEPTION(Decrementer)					 =
     \
> -	NORMAL_EXCEPTION_PROLOG;					 =
     \
> +	NORMAL_EXCEPTION_PROLOG(DECREMENTER);		      \
> 	lis     r0,TSR_DIS@h;           /* Setup the DEC interrupt mask =
*/    \
> 	mtspr   SPRN_TSR,r0;		/* Clear the DEC interrupt */	 =
     \
> 	addi    r3,r1,STACK_FRAME_OVERHEAD;				 =
     \
> @@ -396,7 +399,7 @@ label:
>=20
> #define FP_UNAVAILABLE_EXCEPTION					 =
     \
> 	START_EXCEPTION(FloatingPointUnavailable)			 =
     \
> -	NORMAL_EXCEPTION_PROLOG;					 =
     \
> +	NORMAL_EXCEPTION_PROLOG(FP_UNAVAIL);		      \
> 	beq	1f;							 =
     \
> 	bl	load_up_fpu;		/* if from user, just load it up =
*/   \
> 	b	fast_exception_return;					 =
     \
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S =
b/arch/powerpc/kernel/head_fsl_booke.S
> index d5d78c4..418931f 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -301,19 +301,20 @@ _ENTRY(__early_start)
>=20
> interrupt_base:
> 	/* Critical Input Interrupt */
> -	CRITICAL_EXCEPTION(0x0100, CriticalInput, unknown_exception)
> +	CRITICAL_EXCEPTION(0x0100, CRITICAL, CriticalInput, =
unknown_exception)
>=20
> 	/* Machine Check Interrupt */
> #ifdef CONFIG_E200
> 	/* no RFMCI, MCSRRs on E200 */
> -	CRITICAL_EXCEPTION(0x0200, MachineCheck, =
machine_check_exception)
> +	CRITICAL_EXCEPTION(0x0200, MACHINE_CHECK, MachineCheck, \
> +			   machine_check_exception)
> #else
> 	MCHECK_EXCEPTION(0x0200, MachineCheck, machine_check_exception)
> #endif
>=20
> 	/* Data Storage Interrupt */
> 	START_EXCEPTION(DataStorage)
> -	NORMAL_EXCEPTION_PROLOG
> +	NORMAL_EXCEPTION_PROLOG(DATA_STORAGE)
> 	mfspr	r5,SPRN_ESR		/* Grab the ESR, save it, pass =
arg3 */
> 	stw	r5,_ESR(r11)
> 	mfspr	r4,SPRN_DEAR		/* Grab the DEAR, save it, pass =
arg2 */
> @@ -328,7 +329,7 @@ interrupt_base:
> 	INSTRUCTION_STORAGE_EXCEPTION
>=20
> 	/* External Input Interrupt */
> -	EXCEPTION(0x0500, ExternalInput, do_IRQ, EXC_XFER_LITE)
> +	EXCEPTION(0x0500, EXTERNAL, ExternalInput, do_IRQ, =
EXC_XFER_LITE)
>=20
> 	/* Alignment Interrupt */
> 	ALIGNMENT_EXCEPTION
> @@ -342,32 +343,36 @@ interrupt_base:
> #else
> #ifdef CONFIG_E200
> 	/* E200 treats 'normal' floating point instructions as FP =
Unavail exception */
> -	EXCEPTION(0x0800, FloatingPointUnavailable, =
program_check_exception, EXC_XFER_EE)
> +	EXCEPTION(0x0800, FP_UNAVAIL, FloatingPointUnavailable, \
> +		  program_check_exception, EXC_XFER_EE)
> #else
> -	EXCEPTION(0x0800, FloatingPointUnavailable, unknown_exception, =
EXC_XFER_EE)
> +	EXCEPTION(0x0800, FP_UNAVAIL, FloatingPointUnavailable, \
> +		  unknown_exception, EXC_XFER_EE)
> #endif
> #endif
>=20
> 	/* System Call Interrupt */
> 	START_EXCEPTION(SystemCall)
> -	NORMAL_EXCEPTION_PROLOG
> +	NORMAL_EXCEPTION_PROLOG(SYSCALL)
> 	EXC_XFER_EE_LITE(0x0c00, DoSyscall)
>=20
> 	/* Auxiliary Processor Unavailable Interrupt */
> -	EXCEPTION(0x2900, AuxillaryProcessorUnavailable, =
unknown_exception, EXC_XFER_EE)
> +	EXCEPTION(0x2900, AP_UNAVAIL, AuxillaryProcessorUnavailable, \
> +		  unknown_exception, EXC_XFER_EE)
>=20
> 	/* Decrementer Interrupt */
> 	DECREMENTER_EXCEPTION
>=20
> 	/* Fixed Internal Timer Interrupt */
> 	/* TODO: Add FIT support */
> -	EXCEPTION(0x3100, FixedIntervalTimer, unknown_exception, =
EXC_XFER_EE)
> +	EXCEPTION(0x3100, FIT, FixedIntervalTimer, \
> +		  unknown_exception, EXC_XFER_EE)
>=20
> 	/* Watchdog Timer Interrupt */
> #ifdef CONFIG_BOOKE_WDT
> -	CRITICAL_EXCEPTION(0x3200, WatchdogTimer, WatchdogException)
> +	CRITICAL_EXCEPTION(0x3200, WATCHDOG, WatchdogTimer, =
WatchdogException)
> #else
> -	CRITICAL_EXCEPTION(0x3200, WatchdogTimer, unknown_exception)
> +	CRITICAL_EXCEPTION(0x3200, WATCHDOG, WatchdogTimer, =
unknown_exception)
> #endif
>=20
> 	/* Data TLB Error Interrupt */
> @@ -538,31 +543,38 @@ interrupt_base:
> #ifdef CONFIG_SPE
> 	/* SPE Unavailable */
> 	START_EXCEPTION(SPEUnavailable)
> -	NORMAL_EXCEPTION_PROLOG
> +	NORMAL_EXCEPTION_PROLOG(SPE_UNAVAIL)
> 	bne	load_up_spe
> 	addi	r3,r1,STACK_FRAME_OVERHEAD
> 	EXC_XFER_EE_LITE(0x2010, KernelSPE)
> #else
> -	EXCEPTION(0x2020, SPEUnavailable, unknown_exception, =
EXC_XFER_EE)
> +	EXCEPTION(0x2020, SPE_UNAVAIL, SPEUnavailable, \
> +		  unknown_exception, EXC_XFER_EE)
> #endif /* CONFIG_SPE */
>=20
> 	/* SPE Floating Point Data */
> #ifdef CONFIG_SPE
> -	EXCEPTION(0x2030, SPEFloatingPointData, =
SPEFloatingPointException, EXC_XFER_EE);
> +	EXCEPTION(0x2030, SPE_FP_DATA, SPEFloatingPointData, \
> +		  SPEFloatingPointException, EXC_XFER_EE);
>=20
> 	/* SPE Floating Point Round */
> -	EXCEPTION(0x2050, SPEFloatingPointRound, =
SPEFloatingPointRoundException, EXC_XFER_EE)
> +	EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
> +		  SPEFloatingPointRoundException, EXC_XFER_EE)
> #else
> -	EXCEPTION(0x2040, SPEFloatingPointData, unknown_exception, =
EXC_XFER_EE)
> -	EXCEPTION(0x2050, SPEFloatingPointRound, unknown_exception, =
EXC_XFER_EE)
> +	EXCEPTION(0x2040, SPE_FP_DATA, SPEFloatingPointData, \
> +		  unknown_exception, EXC_XFER_EE)
> +	EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
> +		  unknown_exception, EXC_XFER_EE)
> #endif /* CONFIG_SPE */
>=20
> 	/* Performance Monitor */
> -	EXCEPTION(0x2060, PerformanceMonitor, =
performance_monitor_exception, EXC_XFER_STD)
> +	EXCEPTION(0x2060, PERFORMANCE_MONITOR, PerformanceMonitor, \
> +		  performance_monitor_exception, EXC_XFER_STD)
>=20
> -	EXCEPTION(0x2070, Doorbell, doorbell_exception, EXC_XFER_STD)
> +	EXCEPTION(0x2070, DOORBELL, Doorbell, doorbell_exception, =
EXC_XFER_STD)
>=20
> -	CRITICAL_EXCEPTION(0x2080, CriticalDoorbell, unknown_exception)
> +	CRITICAL_EXCEPTION(0x2080, DOORBELL_CRITICAL, \
> +			   CriticalDoorbell, unknown_exception)
>=20
> 	/* Debug Interrupt */
> 	DEBUG_DEBUG_EXCEPTION
> --=20
> 1.6.0.2
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH][v2] Device Tree Bindings for Freescale TDM controller
From: Kumar Gala @ 2012-03-21 18:06 UTC (permalink / raw)
  To: Poonam Aggrwal; +Cc: Sandeep Singh, devicetree-discuss, linuxppc-dev
In-Reply-To: <1332205369-26260-1-git-send-email-poonam.aggrwal@freescale.com>


On Mar 19, 2012, at 8:02 PM, Poonam Aggrwal wrote:

> This TDM controller is available in various Freescale SOCs like =
MPC8315, P1020,
> P1022, P1010.
>=20
> Signed-off-by: Sandeep Singh <Sandeep@freescale.com>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> ---
> Changes in v2:
> 	- Incorporated Scott's Review comments
> Documentation/devicetree/bindings/tdm/fsl-tdm.txt |   67 =
+++++++++++++++++++++
> 1 files changed, 67 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/tdm/fsl-tdm.txt
>=20
> diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt =
b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> new file mode 100644
> index 0000000..6553dbe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> @@ -0,0 +1,67 @@
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +TDM Device Tree Binding
> +Copyright (C) 2012 Freescale Semiconductor Inc.
> +
> +NOTE: The bindings described in this document are preliminary
> +and subject to change.
> +
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +TDM (Time Division Multiplexing)
> +
> +DESCRIPTION
> +
> +The TDM is full duplex serial port designed to allow various devices =
including
> +digital signal processors (DSPs) to communicate with a variety of =
serial devices
> +including industry standard framers, codecs, other DSPs and =
microprocessors.
> +
> +The below properties describe the device tree bindings for Freescale =
TDM
> +controller.
> +This TDM controller is available on various Freescale Processors like
> +MPC8315, P1020, P1022 and P1010.
> +
> +PROPERTIES
> +
> +  - compatible
> +      Usage: required
> +      Value type: <string>
> +      Definition: Should contain "fsl,mpc8315-tdm".
> +	  So mpc8315 will have compatible =3D "fsl,mpc8315-tdm";
> +	  p1010 will have compatible "fsl,p1010-tdm", "fsl,mpc8315-tdm";
> +
> +  - reg
> +      Usage: required
> +      Definition: There are two reg resources. First is for  TDM =
registers and
> +	  the second for TDM DMAC registers.
> +
> +  - clock-frequency
> +      Usage: optional
> +      Value type: <u32>
> +      Definition: The frequency at which the TDM block is operating.
> +
> +  - interrupts
> +      Usage: required
> +      Definition: This field defines the interrupt specifiers for the =
two
> +      interrupts. First is for TDM error and second for TDM DMAC.
> +
> +  - phy-handle
> +      Usage: optional
> +      Value type: <phandle>
> +      Definition: Phandle of the line controller node or framer node =
eg. SLIC,
> +	  E1/T1 etc.

Which way are we going with the name of such handle properties?  Ie =
should this be 'tdm-phy-handle' or keeping it generic is ok?

> +
> +  - fsl,max-time-slots
> +      Usage: required
> +      Value type: <u32>
> +      Definition: Maximum number of 8-bit time slots in one TDM =
frame.
> +	  This is the maximum number which TDM hardware supports.
> +
> +EXAMPLE
> +
> +	tdm@16000 {
> +		compatible =3D "fsl,p1010-tdm", "fsl,mpc8315-tdm";
> +		reg =3D <0x16000 0x200 0x2c000 0x2000>;
> +		clock-frequency =3D <399999999>; /* typically filled by =
u-boot */
> +		interrupts =3D <16 8 62 8>;
> +		phy-handle =3D <&zarlink1>;
> +		fsl-max-time-slots =3D <128>;
> +	};
> --=20
> 1.6.5.6
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

^ permalink raw reply


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