Previously, the 36-bit code was using these bits, but they had
never been named in the pte format definition. This patch just
gives those fields their proper names and adds a comment that
they are only present on some processors.
There is no functional code change.
Signed-off-by: Becky Bruce
Previously, this was specified as a void *, but that's not
large enough on 32-bit systems with 36-bit physical
addressing support. Change the type to dma_addr_t so it
will scale based on the size of a dma address.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include
On Aug 26, 2009, at 9:08 AM, Michael Ellerman wrote:
On Wed, 2009-08-26 at 22:29 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2009-08-24 at 21:48 +0200, Christoph Hellwig wrote:
On Mon, Aug 24, 2009 at 11:17:14AM -0500, Becky Bruce wrote:
Previously, this was specified as a void
The former is no longer really accurate with the swiotlb case now
a possibility. I also move it into dma-mapping.h - it no longer
needs to be in dma.c, and there are about to be some more accessors
that should all end up in the same place.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
Sometimes this is used to hold a simple offset, and sometimes
it is used to hold a pointer. This patch changes it to a union containing
void * and dma_addr_t. get/set accessors are also provided, because it was
getting a bit ugly to get to the actual data.
Signed-off-by: Becky Bruce bec
is not used in configs where there is no
simple dma offset, such as the iommu case.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/dma-mapping.h | 21 ++---
arch/powerpc/kernel/dma.c | 15 ---
2 files changed, 22 insertions
Sometimes this is used to hold a simple offset, and sometimes
it is used to hold a pointer. This patch changes it to a union containing
void * and dma_addr_t. get/set accessors are also provided, because it was
getting a bit ugly to get to the actual data.
Signed-off-by: Becky Bruce bec
so hopefully we will remember to remove this.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/kmap_types.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kmap_types.h
b/arch/powerpc/include/asm
On Jan 30, 2009, at 8:42 AM, Kumar Gala wrote:
On Jan 30, 2009, at 6:31 AM, Martyn Welch wrote:
Hi Guys,
It seems that 2.6.29-rc3 is not booting on the MPC8641 HPCN. I have
just updated u-boot to the latest git to see if that improved
matters, however I get stuck at the following. Any
8641 dual-core and run LTP to completion with an expected
number of fails. So
Acked-by: Becky Bruce bec...@kernel.crashing.org
-B
---
arch/powerpc/mm/hash_low_32.S |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/hash_low_32.S b/arch/powerpc/mm
forward.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Benjamin Krill b...@codiert.org
Tested on ppc 86xx, looks good.
Acked-by: Becky Bruce bec...@kernel.crashing.org
-B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https
...@codiert.org
Tested on ppc 86xx, looks good.
Acked-by: Becky Bruce bec...@kernel.crashing.org
-B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
if this
condition
shows up and the driver should be fixed.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Benjamin Krill b...@codiert.org
Tested on ppc 86xx, looks good.
Acked-by: Becky Bruce bec...@kernel.crashing.org
-B
to be setup correctly.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Boots on 8641D stock config and gets rid of the panic I was seeing.
Acked-by: Becky Bruce bec...@kernel.crashing.org
Cheers,
Becky
---
Dave,
This is for net-next. We are working on having per device dma ops
On Mar 30, 2009, at 1:53 PM, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
The driver triggers a BUG_ON() when allocating DMA buffers if the
arch/powerpc dma_ops from the of_platform device are not copied
into net_device structure.
Signed-off-by: Grant Likely
...@secretlab.ca
---
Becky, does this look better to you?
Reviewed-by: Becky Bruce bec...@kernel.crashing.org
I think this is OK now, and Kumar agrees
Thanks!
B
g.
drivers/net/fec_mpc52xx.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers
On Mar 31, 2009, at 10:06 AM, Eduard Fuchs wrote:
Hi,
Am Dienstag 31 März 2009 15:20:21 schrieb Kumar Gala:
On Mar 31, 2009, at 5:15 AM, Eduard Fuchs wrote:
Hi,
I'm testing the evaluation board from freescale (MPC8641DHPCN) with
the latest
linux kernel (2.6.29) and the second core seems
GIT: Please enter your email below.
GIT: Lines beginning in GIT: will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
GIT: Please enter your email below.
GIT: Lines beginning in GIT: will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
. For
now, initialize them to a standard value; in the near future, the
value will be calculated based on how the inbound windows are
programmed.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/pci-bridge.h |6 --
arch/powerpc/sysdev/fsl_pci.c
, and is needed by the swiotlb code which
actually distinguishes between dma_length and length.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/scatterlist.h |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm
This patch series allows the use of swiotlb on mpc86xx, with 85xx
support soon to follow. The most notable change here is the addition
of addr_needs_map to dma_ops. This is used to tell if a device
can reach an address without bounce buffering. I believe that patches
will be coming out soon to
Minor code to allow enabling swiotlb on mpc86xx, including
Kconfig addition for SWIOTLB.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/Kconfig | 10 ++
arch/powerpc/kernel/dma-swiotlb.c |2 ++
arch/powerpc/platforms/86xx
The new dts places most of the devices in physical address space
above 32-bits, which allows us to have more than 4GB of RAM present.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597
1 files changed, 597
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/include/asm/dma-mapping.h | 11
FAIL.
Here's the text that should have been there :)
-B
This patch series allows the use of swiotlb on mpc86xx, with 85xx
upport soon to follow. The most notable change here is the addition
of addr_needs_map to dma_ops. This is used to tell if a device
can reach an address without bounce
On Apr 20, 2009, at 12:00 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Minor code to allow enabling swiotlb on mpc86xx, including
Kconfig addition for SWIOTLB.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/Kconfig
On Apr 20, 2009, at 11:57 AM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
On Apr 20, 2009, at 1:31 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
+static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *dev = data;
+
+ /* We are only
On Apr 20, 2009, at 3:06 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Currently, the 32-bit code uses sg-length instead of sg-dma_lentgh
to report sg_dma_len. However, since the default dma code for 32-bit
(the dma_direct case) sets dma_length and length
On Apr 20, 2009, at 8:10 PM, David Gibson wrote:
On Mon, Apr 20, 2009 at 11:26:47AM -0500, Becky Bruce wrote:
The new dts places most of the devices in physical address space
above 32-bits, which allows us to have more than 4GB of RAM present.
Signed-off-by: Becky Bruce bec
Guys,
I've been looking at converting 32-bit powerpc's DMA code over to the
64-bit method, where there is a dma_ops structure inside archdata
that tells us which operations a device should use for DMA. I'll be
needing this shortly because I need to implement swiotlb to deal with
PCI and large
On Feb 6, 2008, at 7:26 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-02-06 at 18:32 -0600, Becky Bruce wrote:
I've been looking at converting 32-bit powerpc's DMA code over to the
64-bit method, where there is a dma_ops structure inside archdata
that tells us which operations a device
Convert the lmb code to use phys_addr_t instead of unsigned long for
physical addresses and sizes. This is needed to support large amounts
of RAM on 32-bit systems that support 36-bit physical addressing.
Built/booted on mpc8641; build tested on pasemi and 44x.
Signed-off-by: Becky Bruce
Convert the lmb code to use phys_addr_t instead of unsigned long for
physical addresses and sizes. This is needed to support large amounts
of RAM on 32-bit systems that support 36-bit physical addressing.
Built/booted on mpc8641; build tested on pasemi and 44x.
Signed-off-by: Becky Bruce [EMAIL
On Feb 13, 2008, at 7:09 PM, David Miller wrote:
I've taken into consideration the various feedback, and
ported the bug fix and other LMB patches posted recently
in an effort to keep the patch churn by others down wrt.
my moving of these files.
1) Use HAVE_LMB as suggested by Sam.
2)
dt_mem_next_cell() currently does of_read_ulong(). This does
not allow for the case where #size-cells and/or #address-cells = 2 on
a 32-bit system, as it will end up reading 32 bits instead of the
expected 64. Change it to use of_read_number instead and always return
a u64.
Signed-off-by: Becky
Reserved MCSR bits on FSL BookE parts may have spurious values
when mcheck occurs. Mask these off when printing the MCSR to
avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
for e500 - this bit doesn't actually have any meaning.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch
Hi Paul,
Is there a reason this hasn't been picked up:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035906.html
It fixes a build warning in the tree and removes some dead code. It
appears to still apply cleanly to the top of your tree if there
are issues please let me know so I can
This file was protected by _PPC64_LMB_H, which is confusing, as the 32-bit code
also uses the lmb these days. Changed to _ASM_POWERPC_LMB_H.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
include/asm-powerpc/lmb.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
Signed-off-by:
stwcx. needs to be paired with a dummy lwarx to the same address.
This patch adds the dummy lwarx, and creates a cpu feature bit to indicate
which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc;
build tested in arch/ppc.
Signed-off-by Becky Bruce [EMAIL PROTECTED]
---
arch
stwcx. needs to be paired with a dummy lwarx to the same address.
This patch adds the dummy lwarx, and creates a cpu feature bit to indicate
which cpus are affected. Tested on mpc8641_hpcn_defconfig in arch/powerpc;
build tested in arch/ppc.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
Resend
On Nov 9, 2007, at 5:19 PM, Olof Johansson wrote:
On Fri, Nov 09, 2007 at 04:08:06PM -0600, Becky Bruce wrote:
The context switch code in the kernel issues a dummy stwcx. to
clear the
reservation, as recommended by the architecture. However, some
processors
can have issues
On Mar 16, 2010, at 5:08 AM, FUJITA Tomonori wrote:
On Tue, 16 Mar 2010 06:58:41 +0100
Albert Herranz albert_herr...@yahoo.es wrote:
FUJITA Tomonori wrote:
On Fri, 12 Mar 2010 20:12:40 +0100
Albert Herranz albert_herr...@yahoo.es wrote:
The current SWIOTLB code uses a default of 64MB for
The code was looking for this in cpu_features, not mmu_features. Fix this.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/mm/fsl_booke_mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm
The code was looking for this in cpu_features, not mmu_features. Fix this.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
Switched to mmu_has_feature.
arch/powerpc/mm/fsl_booke_mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm
doesn't use the stack pointer the easiest
solution is to just have it in asm code.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Looks good on 8572 SMP - both cpus come up properly now with ftrace
enabled, and I am able to run the tracers.
Tested-by: Becky Bruce bec
possible, it might be a good idea even as it would allow to have
different implementations for different busses, which is in fact
needed
for some things like 4xx if we start changing the mapping between
different PCI bridges vs. SoCs. In fact, I think there's been some
patches from Becky Bruce
I just noticed that the fec_8xx driver is not currently reachable via
menuconfig because it depends on 8XX instead of 8xx. It looks like
this change occurred in commit
d1c0a65fb597697d1fbce4eadf42b84f70483edc, almost a year ago:
diff --git a/drivers/net/fec_8xx/Kconfig
On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:
On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
I just noticed that the fec_8xx driver is not currently reachable via
menuconfig because it depends on 8XX instead of 8xx.
[snip]
Since nobody has noticed this problem, I'm wondering
When resource_size_t is larger than an int, the current code
generates a build warning. Kill it.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch
This driver has been superseded by fs_enet and is no longer in use.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
drivers/net/Kconfig |1 -
drivers/net/Makefile|1 -
drivers/net/fec_8xx/Kconfig | 20 -
drivers/net/fec_8xx/Makefile
On May 8, 2008, at 12:25 PM, Vitaly Bordug wrote:
On Tue, May 06, 2008 at 12:30:08PM -0400, Jeff Garzik wrote:
Becky Bruce wrote:
This driver has been superseded by fs_enet and is no longer in use.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
I cannot make an informed judgement
On May 23, 2008, at 4:51 AM, Christoph Hellwig wrote:
On Wed, Apr 30, 2008 at 06:36:43PM -0500, Becky Bruce wrote:
In addition, the dma_map/unmap_page functions are added to dma_ops on
HIGHMEM-enabled configs because we can't just fall back on map/
unmap_single
when HIGHMEM is enabled
On May 28, 2008, at 8:53 PM, Mark Nelson wrote:
On Fri, 23 May 2008 06:06:50 pm Mark Nelson wrote:
On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote:
I essentially adopt the 64-bit dma code, with some changes to
support
32-bit systems, including HIGHMEM. dma functions on 32-bit are now
Boyer [EMAIL PROTECTED]
Acked-by: Stephen Neuendorffer [EMAIL PROTECTED]
Acked-by: Arnd Bergmann [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Acked-by: Scott Wood [EMAIL PROTECTED]
Acked-by: Becky Bruce [EMAIL PROTECTED]
___
Linuxppc
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
include/asm-powerpc/pgtable-ppc32.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/pgtable-ppc32.h
b/include/asm-powerpc/pgtable-ppc32.h
index c08e714..dde466b 100644
--- a/include/asm-powerpc
Currently, the physical address is an unsigned long, but it should
be phys_addr_t in set_bat, [v/p]_mapped_by_bat. Also, create a
macro that can convert a large physical address into the correct
format for programming the BAT registers.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch
representation of the batu/l values.
This seems like a nicer solution than adding in a bunch of
new bitfields to support extended bat addressing that would never
get used, and just leaving the struct as-is would have been
incomplete in the face of large physical addressing.
Signed-off-by: Becky
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
The new e500mc core from Freescale is based on the e500v2 but with the
following changes:
* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
---
In my
On Jul 9, 2008, at 7:44 PM, Josh Boyer wrote:
On Thu, 10 Jul 2008 06:39:39 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-07-09 at 16:22 -0400, Josh Boyer wrote:
On Thu, 10 Jul 2008 06:02:38 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-07-09 at
to this thread and maybe we'll have
an inform PPC BoF @ a pub.
I'll be there.
Acked-by-with-a-woohoo Becky Bruce
-B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Jul 18, 2008, at 11:33 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
If anybody wants to email me their cell phone # privately then I'll
collect a list and send it out to all the repliers to this thread.
That way you don't need to post your cell # to the mailing list
So,
There doesn't seem to be an official plan, so I'm making one
Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this
evening. Anybody that wants to join us welcome.
Cheers,
Becky
On Jul 21, 2008, at 4:24 PM, Sean MacLennan wrote:
On Mon, 21 Jul 2008 14:15:53 -0600
On Aug 11, 2008, at 4:37 PM, Morrison, Tom wrote:
I am sorry, but I've butted my head against a tree for over a
week and some things just aren't making sense...especially how
the prom parse code is working to exact / resolve physical
addresses to then ioremap...
a) Setup, I have a working
On Aug 12, 2008, at 10:14 AM, Morrison, Tom wrote:
Thank you Becky (and Kumar) for all the informationand help!
To answer your questions, yes, we are using 4GB++ of memory
(and plan more in the near future). But, for the initial bring
up, I reduced the memory to 2Gig. Further, I have
On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:
In message [EMAIL PROTECTED]
you wrote:
The mmu is still disabled at this point.
What is marked as readonly is the text section of the vmlinux file
generated when compiling the kernel. And since the code tries to
write
to the text
Also change consumers of various lmb funcs/arrays that are now
phys_addr_t to also be phys_addr_t.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/mm/mem.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch
to accomodate
large physical addresses on 32-bit systems and enables the
PHYS_64BIT config option for 6xx. It does *not*
allow you to boot a board with more than about 3.5GB of
RAM - for that, SWIOTLB support is also required (and
coming soon).
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc
Gah, I just noticed that part of this patch is missing - I will
resubmit as soon as I figure out what the heck happened.
-Becky
On Aug 21, 2008, at 3:10 PM, Becky Bruce wrote:
Also change consumers of various lmb funcs/arrays that are now
phys_addr_t to also be phys_addr_t.
Signed-off
Use phys_addr_t for sizes and addresses where appropriate.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/mm/mem.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1c93c25..89dc32b
It turns out that the commit message was out of date, and the patch
itself was correct. I have resubmitted with a different title/log, so
this patch can be ignored.
Cheers,
B
On Aug 22, 2008, at 10:26 AM, Becky Bruce wrote:
Gah, I just noticed that part of this patch is missing - I
On Aug 21, 2008, at 4:40 PM, Kumar Gala wrote:
#define _PMD_PRESENT0
#define _PMD_PRESENT_MASK (PAGE_MASK)
@@ -517,7 +522,13 @@ extern unsigned long
bad_call_to_PMD_PAGE_SIZE(void);
#define pte_none(pte) ((pte_val(pte) ~_PTE_NONE_MASK) == 0)
#define pte_present(pte)
On Aug 27, 2008, at 6:43 PM, Scott Wood wrote:
Becky Bruce wrote:
#if _PAGE_HASHPTE != 0
+#ifndef CONFIG_PTE_64BIT
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) ~_PAGE_HASHPTE);
#else
+ /*
+* We have to do the write of the 64b pte as 2 stores. This
+* code
Great, so *you* got my email, and I did not. I love our mailserver!
On Aug 28, 2008, at 3:28 PM, Scott Wood wrote:
Becky Bruce wrote:
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did
On Aug 28, 2008, at 11:07 AM, Scott Wood wrote:
Becky Bruce wrote:
I'm pretty sure I went through this in great detail at one point
and concluded that I did in fact need the lwarx/stwcx. IIRC, it
has to do with other non-set_pte_at writers not necessarily holding
the page table lock
On Aug 29, 2008, at 8:56 AM, Kumar Gala wrote:
There are some minor issues with support 64-bit PTEs on a 32-bit
processor
when dealing with SMP.
* We need to order the stores in set_pte_at to make sure the flag word
is set second.
* Change pte_clear to use pte_update so only the flag word
On Aug 29, 2008, at 8:56 AM, Kumar Gala wrote:
Introduced a new set of low level tlb invalidate functions that do not
broadcast invalidates on the bus:
_tlbil_all - invalidate all
_tlbil_pid - invalidate based on process id (or mm context)
_tlbil_va - invalidate based on virtual address (ea
to accomodate
large physical addresses on 32-bit systems and enables the
PHYS_64BIT config option for 6xx. It does *not*
allow you to boot a board with more than about 3.5GB of
RAM - for that, SWIOTLB support is also required (and
coming soon).
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
Incorporated
to accomodate
large physical addresses on 32-bit systems and enables the
PHYS_64BIT config option for 86xx. It does *not*
allow you to boot a board with more than about 3.5GB of
RAM - for that, SWIOTLB support is also required (and
coming soon).
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
Updated
On Sep 1, 2008, at 12:19 AM, Benjamin Herrenschmidt wrote:
Thanks for taking the time to dig through this :)
+#ifdef CONFIG_PTE_64BIT
+#define PTE_FLAGS_OFFSET 4 /* offset of PTE flags, in bytes */
+#define LNX_PTE_SIZE 8 /* size of a linux PTE, in bytes */
On Sep 2, 2008, at 4:21 PM, Benjamin Herrenschmidt wrote:
The reason I did that was to distinguish between the size of a
software PTE entry, and the actual size of the hardware entry. In
the
case of 36b physical, the hardware PTE size is the same as it always
is; but we've grown the
It's the size of the hardware PTE; make that clear in the name.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/mm/hash_low_32.S | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/mm/hash_low_32.S b/arch
On Aug 29, 2008, at 8:56 AM, Kumar Gala wrote:
There are some minor issues with support 64-bit PTEs on a 32-bit
processor
when dealing with SMP.
* We need to order the stores in set_pte_at to make sure the flag word
is set second.
* Change pte_clear to use pte_update so only the flag word
This patch series merges the 32 and 64-bit dma code and does some
other cleanup. This has changed a bit since the RFC was submitted
a few months ago - I incorporated most of the comments from Christoph,
including moving the iommu-specific code into its own file and dropping
numa_node from
32-bit platforms are about to start using dma.c; move the iommu
dma ops into their own file to make this a bit cleaner.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/kernel/Makefile|2 +-
arch/powerpc/kernel/dma-iommu.c | 103 +++
arch
Use the struct device's numa_node instead; use accessor functions
to get/set numa_node.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
64-bit folks: Please test when you get a moment. I've build-tested this,
but I do not have the ability to actually boot it on anything. Yes, I know
This is in preparation for the merge of the 32 and 64-bit
dma code in arch/powerpc.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/dma.c| 200 ++
arch/powerpc/kernel/dma_64.c | 200
/unmap_single in the dma_ops definition,
though, because they are needed by the iommu code, which does not
implement map/unmap_page.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/include/asm/dma-mapping.h | 178 +--
arch/powerpc/include/asm/machdep.h |5
On Sep 8, 2008, at 2:56 PM, Scott Wood wrote:
Becky Bruce wrote:
We're currently passing NULL, and really shouldn't be.
This patch doesn't change that for cpm2, since port.dev is never
initialized. :-P
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
drivers/serial/cpm_uart
, 2008 at 06:36:43PM -0500, Becky Bruce wrote:
In addition, the dma_map/unmap_page functions are added to dma_ops on
HIGHMEM-enabled configs because we can't just fall back on map/
unmap_single
when HIGHMEM is enabled. Adding these to dma_ops makes it cleaner to
substitute different functionality
On Sep 9, 2008, at 5:13 PM, Christoph Hellwig wrote:
On Wed, Sep 10, 2008 at 08:10:31AM +1000, Benjamin Herrenschmidt
wrote:
Yeah, the statement this time should be why do you keep _single :)
It don't really mind which one we keep, but having both and both
optional seems rather odd.
It
On Sep 8, 2008, at 4:57 PM, Christoph Hellwig wrote:
On Mon, Sep 08, 2008 at 02:09:53PM -0500, Becky Bruce wrote:
+/* We support DMA to/from any memory page via the iommu */
+static int dma_iommu_dma_supported(struct device *dev, u64 mask)
+{
+ struct iommu_table *tbl = dev
We're currently passing NULL, and really shouldn't be.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
drivers/serial/cpm_uart/cpm_uart_core.c |3 +++
drivers/serial/cpm_uart/cpm_uart_cpm1.c |6 +++---
drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 +++---
drivers/serial/ucc_uart.c
/unmap_single in the dma_ops definition,
though, because they are needed by the iommu code, which does not
implement map/unmap_page. Ideally, going forward, we will completely
eliminate map/unmap_single and just have map/unmap_page, if it's
workable for 64-bit.
Signed-off-by: Becky Bruce [EMAIL PROTECTED
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/include/asm/types.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index d3374bc..a9a9262 100644
--- a/arch/powerpc/include/asm/types.h
On Sep 22, 2008, at 11:53 PM, Wolfram Sang wrote:
On Mon, Sep 22, 2008 at 06:34:37PM -0500, Kumar Gala wrote:
Can we eliminate the linuxppc-embedded mailing list and merge it
with
linuxppc-dev?
That's not really up to me - more of a community question I think. I
imagine Paul would have
and LTP-ing like a champ. So
Acked-by: Becky Bruce becky.bruce!freescale.com
Cheers,
B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
This seems to have gotten dropped. Are there issues with this, or
did I get lost in the patchwork shuffle?
Cheers,
Becky
On Aug 22, 2008, at 11:49 AM, Becky Bruce wrote:
Use phys_addr_t for sizes and addresses where appropriate.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch
1 - 100 of 174 matches
Mail list logo
