Dan Malek ppc6...@digitaldans.com wrote on 2011/10/13 03:08:12:
Hi Joakim.
On Oct 12, 2011, at 2:36 PM, Joakim Tjernlund wrote:
Dan, where did you go? I figured you would throw yourself at this as
this is
something you been meaning to do yourself for years :)
Too many things to do
Update all dts files that support SRIO controllers to match the new
fsl,srio device tree binding.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8568mds.dts | 66 ++---
arch/powerpc/boot/dts/mpc8569mds.dts | 72
From: Liu Gang gang@freescale.com
This document is created for powerpc rapidio and rmu nodes in dts file.
These nodes can support two rapidio ports and message units. In addition,
It explicates the properties and gives examples about rapidio and rmu nodes.
Signed-off-by: Li Yang
From: Kai Jiang kai.ji...@freescale.com
Update of_platform_bus_probe() RapidIO node to be compitable with
new RapidIO dts compatible property.
Signed-off-by: Kai Jiang kai.ji...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/platforms/85xx/corenet_ds.c |
From: Liu Gang gang@freescale.com
Usually, freescale rapidio endpoint can support one 1X or two 4X LP-Serial
link interfaces, and rapidio message transactions can be implemented by two
message units. This patch adds the support of two rapidio ports and
initializes message unit 0 and message
On Wed, Oct 12, 2011 at 11:15 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Do we believe phys_addr_t is always greater than or equal to size need for
logical virtual addresses?
Yes:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
On Tue, Oct 11, 2011 at 11:53 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:
Remove wrong CONFIG_ prefix in Kconfig file.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
arch/powerpc/platforms/85xx/Kconfig | 2 +-
1 files
On Thu, Oct 13, 2011 at 16:10, Tabi Timur-B04825 b04...@freescale.com wrote:
On Wed, Oct 12, 2011 at 11:15 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Do we believe phys_addr_t is always greater than or equal to size need for
logical virtual addresses?
Yes:
#ifdef
Geert Uytterhoeven wrote:
You deleted this part:
config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
which enforces that PHYS_ADDR_T_64BIT is enabled if 64BIT is set.
Ok, I didn't catch that before, but it makes sense now. Thanks.
--
Timur Tabi
Linux kernel
On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala ga...@kernel.crashing.org wrote:
From: Kai Jiang kai.ji...@freescale.com
To support 32-bit physical addresses for UIO_MEM_PHYS type we need to
extend the width of 'addr' in struct uio_mem. Numerous platforms like
embedded PPC, ARM, and X86 have
Normally logical and hard cpu ID are the same, however in same cases like
on the P3060 they may differ. Where the logical is 0..5, the hard id
goes 0,1,4..7. This can causes issues for places we utilize PIR to index
into array like in debug exception handlers for finding the exception
stack.
On Oct 13, 2011, at 9:37 AM, Tabi Timur-B04825 wrote:
On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala ga...@kernel.crashing.org wrote:
From: Kai Jiang kai.ji...@freescale.com
To support 32-bit physical addresses for UIO_MEM_PHYS type we need to
extend the width of 'addr' in struct uio_mem.
David Laight wrote:
Since there is a discriminating field, could a union be used?
At a guess the type of the address is constrained between
produces and consumer??
I don't think we need to complicate the code by changing that variable into a
union. I just a want a short comment added to the
On Oct 13, 2011, at 10:35 AM, Timur Tabi wrote:
Kumar Gala wrote:
Why did you apply this patch? Both Scott and I rejected it.
Because its fixing a real issue. If we want to remove PHYS_64BIT support or
make it optional for the board feel free to send another patch.
Ok, so if someone
Kumar Gala wrote:
+ phys_addr_t addr;
Please add a comment here saying:
1) That 'addr' can be a virtual or physical address
The code and everything else makes that clear
I'm sorry, but I have to strongly disagree here. It is *NOT*
clear that a variable
Kumar Gala wrote:
I think this 25% number is bogus. There are cases where it also improves
performance.
I don't think we ever ship a P1022 system with more than 2GB of DDR, so I can't
see how performance is ever improved.
I will post a patch that removes the Kconfig option, but I don't
On Oct 13, 2011, at 7:00 AM, Joakim Tjernlund wrote:
ehhm, do the fun stuff first? :)
Need to pay the bills, first :-)
Thanks for the other information.
-- Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Oct 13, 2011, at 10:37 AM, David Laight wrote:
Kumar Gala wrote:
+ phys_addr_t addr;
Please add a comment here saying:
1) That 'addr' can be a virtual or physical address
The code and everything else makes that clear
I'm sorry, but I have to strongly disagree
On Thu, 13 Oct 2011 10:35:04 -0500
Timur Tabi ti...@freescale.com wrote:
Kumar Gala wrote:
Why did you apply this patch? Both Scott and I rejected it.
Because its fixing a real issue. If we want to remove PHYS_64BIT support
or make it optional for the board feel free to send another
From: Kai Jiang kai.ji...@freescale.com
To support 32-bit physical addresses for UIO_MEM_PHYS type we need to
extend the width of 'addr' in struct uio_mem. Numerous platforms like
embedded PPC, ARM, and X86 have support for systems with larger physical
address than logical.
Since 'addr' may
On Thu, 13 Oct 2011 10:45:04 -0500
Timur Tabi ti...@freescale.com wrote:
Kumar Gala wrote:
I think this 25% number is bogus. There are cases where it also improves
performance.
I don't think we ever ship a P1022 system with more than 2GB of DDR, so I
can't
see how performance is ever
Anatolij Gustschin wrote:
there is no 32bit address map DTS file for P1022DS in the mainline
tree. A proper patch should then also add appropriate 32bit address
map DTS file. I'm not in the position to do it currently since it would
require testing, I do not have this board to test patches for
-Original Message-
From: linuxppc-dev-bounces+bharat.bhushan=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of
smitha.va...@wipro.com
Sent: Friday, October 14, 2011 9:45 AM
To: Wood Scott-B07421
Cc:
23 matches
Mail list logo
