* Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4
From: Dan Malek @ 2011-10-13 1:08 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev, Willy Tarreau
In-Reply-To: <OF76F1F5B7.8750C8C4-ONC1257927.00767D9A-C1257927.0076B5BE@transmode.se>
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 :-) I did have the wired page version that I've
been using now and then.
I had the bad thought yesterday that we need to check the
implementation for coherent memory. It appears we set the
pages non-cached, which could cause some trouble. We
have to ensure we never access the same physical page
with different attributes from the 8M mapping and the single
page "coherent" mapping.
I'll try to get some testing done.
Thanks.
-- Dan
^ permalink raw reply
* How to handle cache when I allocate phys memory?
From: Ayman El-Khashab @ 2011-10-12 21:08 UTC (permalink / raw)
To: linuxppc-dev
I'm using the 460sx (440 core) so no snooping here. What
I've done is reserved the top of memory for my driver. My
driver can read/write the memory and I can mmap it just
fine. The problem is I want to enable caching on the mmap
for performance but I don't know / can't figure out how to
tell the kernel to sync the cache after it gets dma data
from the device or after i put data into it from user space.
I know how to do it from regular devices, but not when I've
allocated the physical memory myself. I suppose what I am
looking for is something akin to dma_sync_single cpu/device.
In my device driver, I am allocating the memory like this,
in this case the buffer is about 512MB.
vma->vm_flags |= VM_LOCKED | VM_RESERVED;
/* map the physical area into one buffer */
rc = remap_pfn_range(vma, vma->vm_start,
(PHYS_MEM_ADDR)>>PAGE_SHIFT,
len, vma->vm_page_prot);
Is this going to give me the best performance, or is there
something more I can do?
Failing that, what is the best way to do this (i need a very
large contiguous buffer). it runs in batch mode, so it
DMAs, stops, cpu reads, cpu writes, repeat ...
thanks
ayman
^ permalink raw reply
* Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4
From: Joakim Tjernlund @ 2011-10-12 21:36 UTC (permalink / raw)
Cc: Scott Wood, linuxppc-dev, Dan Malek, Willy Tarreau
In-Reply-To: <OF5A487DD5.BE515A85-ONC1257926.0029F008-C1257926.002A6323@LocalDomain>
Joakim Tjernlund/Transmode wrote on 2011/10/11 09:42:58:
>
> Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/10/10 20:03:53:
> >
> >
> > On Oct 10, 2011, at 9:45 AM, Joakim Tjernlund wrote:
> >
> > > That is an easy port but I will have to do that blind. Would you
> > > mind take this for a spin on 2.4 first?
> >
> > My current system is running 2.6, so I don't have much
> > interested in testing 2.4
>
> Too bad as I won't be able to run 2.6 at all.
> However, I just sent you a dry port to 3.0 of the large page stuff to
> you. Happy testing.
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 :)
Jocke
^ permalink raw reply
* [PATCH v2] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Becky Bruce @ 2011-10-12 21:17 UTC (permalink / raw)
To: linuxppc-dev
From: Becky Bruce <beckyb@kernel.crashing.org>
Currently, it does a cntlzd on the size and then subtracts it from
21.... this doesn't take into account the varying size of a "long".
Just use __ilog instead (and subtract the 10 we have to subtract
to get to the tsize encoding).
Also correct the comment about page sizes supported.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
Sent the wrong version last time; also noticed that the comment is
incorrect now that we have 64-bit and added that to the patch.
arch/powerpc/mm/fsl_booke_mmu.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index f7802c8..5b8fd3b 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -101,17 +101,17 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
/*
* Set up a variable-size TLB entry (tlbcam). The parameters are not checked;
- * in particular size must be a power of 4 between 4k and 256M (or 1G, for cpus
- * that support extended page sizes). Note that while some cpus support a
- * page size of 4G, we don't allow its use here.
+ * in particular size must be a power of 4 between 4k and the max supported by
+ * an implementation; max may further be limited by what can be represented in
+ * an unsigned long (for example, 32-bit implementations cannot support a 4GB
+ * size).
*/
static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned long size, unsigned long flags, unsigned int pid)
{
- unsigned int tsize, lz;
+ unsigned int tsize;
- asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (size));
- tsize = 21 - lz;
+ tsize = __ilog2(size) - 10;
#ifdef CONFIG_SMP
if ((flags & _PAGE_NO_CACHE) == 0)
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 20:58 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
In-Reply-To: <20111012202332.GG21852@local>
On Oct 12, 2011, at 3:23 PM, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 01:40:22PM -0500, Kumar Gala wrote:
>>=20
>> On Oct 12, 2011, at 11:19 AM, Hans J. Koch wrote:
>>=20
>>> On Wed, Oct 12, 2011 at 05:32:29PM +0200, Hans J. Koch wrote:
>>>> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>>>>> From: Kai Jiang <Kai.Jiang@freescale.com>
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Since 'addr' may contain a physical, logical, or virtual address =
the
>>>>> easiest solution is to just change the type to 'unsigned long =
long'
>>>>> regardless of which type is utilized.
>>>>=20
>>>> No. There's phys_addr_t for that purpose, defined in =
include/linux/types.h.
>>>> Please use that.
>>>=20
>>> I forgot: If you resend this, please update the documentation as =
well.
>>> (Documentation/DocBook/uio-howto.tmpl)
>>=20
>> What would you look added or modified here?
>=20
> struct uio_mem ?
>=20
> Hans
New version sent, let me know if there are any other aspects to the =
DocBook that need updating.
- k=
^ permalink raw reply
* [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 20:57 UTC (permalink / raw)
To: hjk; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
From: Kai Jiang <Kai.Jiang@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 contain a physical, logical, or virtual address the
easiest solution is to just change the type to 'unsigned long long'
regardless of which type is utilized.
For physical address we can support up to a 44-bit physical address on a
typical 32-bit system as we utilize remap_pfn_range() for the mapping of
the memory region and pfn's are represnted by shifting the address by
the page size (typically 4k).
Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v2:
* Use phys_addr_t instead of 'unsigned long long'
* Updated DocBook detail in uio-howto.tmpl
Documentation/DocBook/uio-howto.tmpl | 2 +-
drivers/uio/uio.c | 8 ++++----
include/linux/uio_driver.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index 7c4b514d..54883de 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,7 +529,7 @@ memory (e.g. allocated with <function>kmalloc()</function>). There's also
</para></listitem>
<listitem><para>
-<varname>unsigned long addr</varname>: Required if the mapping is used.
+<varname>phys_addr_t addr</varname>: Required if the mapping is used.
Fill in the address of your memory block. This address is the one that
appears in sysfs.
</para></listitem>
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 88f4444..43b7096 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr);
+ return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr);
}
static ssize_t map_size_show(struct uio_mem *mem, char *buf)
@@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
+ return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr & ~PAGE_MASK);
}
struct map_sysfs_entry {
@@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
page = virt_to_page(idev->info->mem[mi].addr + offset);
else
- page = vmalloc_to_page((void *)idev->info->mem[mi].addr
- + offset);
+ page = vmalloc_to_page((void *)(unsigned long)
+ idev->info->mem[mi].addr + offset);
get_page(page);
vmf->page = page;
return 0;
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 4c618cd..d9ce796 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -32,7 +32,7 @@ struct uio_map;
*/
struct uio_mem {
const char *name;
- unsigned long addr;
+ phys_addr_t addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 20:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <38B65690-DA92-4923-B2A4-6523DDDA579A@kernel.crashing.org>
On Wed, Oct 12, 2011 at 01:40:22PM -0500, Kumar Gala wrote:
>
> On Oct 12, 2011, at 11:19 AM, Hans J. Koch wrote:
>
> > On Wed, Oct 12, 2011 at 05:32:29PM +0200, Hans J. Koch wrote:
> >> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> >>> From: Kai Jiang <Kai.Jiang@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 contain a physical, logical, or virtual address the
> >>> easiest solution is to just change the type to 'unsigned long long'
> >>> regardless of which type is utilized.
> >>
> >> No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
> >> Please use that.
> >
> > I forgot: If you resend this, please update the documentation as well.
> > (Documentation/DocBook/uio-howto.tmpl)
>
> What would you look added or modified here?
struct uio_mem ?
Hans
>
> - k
^ permalink raw reply
* [PATCH] powerpc/ps3: Fix lv1_gpu_attribute hcall
From: Geoff Levand @ 2011-10-12 18:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Takashi Iwai, linuxppc-dev, cbe-oss-dev
The lv1_gpu_attribute hcall takes three, not five input
arguments. Adjust the lv1 hcall table and all calls.
Signed-off-by: Geoff Levand <geoff@infradead.org>
CC: Takashi Iwai <tiwai@suse.de>
---
arch/powerpc/include/asm/lv1call.h | 2 +-
sound/ppc/snd_ps3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/lv1call.h
+++ b/arch/powerpc/include/asm/lv1call.h
@@ -315,7 +315,7 @@ LV1_CALL(gpu_context_free,
LV1_CALL(gpu_context_iomap, 5, 0, 221 )
LV1_CALL(gpu_context_attribute, 6, 0, 225 )
LV1_CALL(gpu_context_intr, 1, 1, 227 )
-LV1_CALL(gpu_attribute, 5, 0, 228 )
+LV1_CALL(gpu_attribute, 3, 0, 228 )
LV1_CALL(get_rtc, 0, 2, 232 )
LV1_CALL(set_ppe_periodic_tracer_frequency, 1, 0, 240 )
LV1_CALL(start_ppe_periodic_tracer, 5, 0, 241 )
--- a/sound/ppc/snd_ps3.c
+++ b/sound/ppc/snd_ps3.c
@@ -875,7 +875,7 @@ static void __devinit snd_ps3_audio_set_
(0x0fUL << 12) |
(PS3_AUDIO_IOID);
- ret = lv1_gpu_attribute(0x100, 0x007, val, 0, 0);
+ ret = lv1_gpu_attribute(0x100, 0x007, val);
if (ret)
pr_info("%s: gpu_attribute failed %d\n", __func__,
ret);
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 18:40 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
In-Reply-To: <20111012161931.GE21852@local>
On Oct 12, 2011, at 11:19 AM, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 05:32:29PM +0200, Hans J. Koch wrote:
>> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>>> From: Kai Jiang <Kai.Jiang@freescale.com>
>>>=20
>>> 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.
>>>=20
>>> Since 'addr' may contain a physical, logical, or virtual address the
>>> easiest solution is to just change the type to 'unsigned long long'
>>> regardless of which type is utilized.
>>=20
>> No. There's phys_addr_t for that purpose, defined in =
include/linux/types.h.
>> Please use that.
>=20
> I forgot: If you resend this, please update the documentation as well.
> (Documentation/DocBook/uio-howto.tmpl)
What would you look added or modified here?
- k=
^ permalink raw reply
* [PATCH] powerpc/ps3: Fix PS3 repository build warnings
From: Geoff Levand @ 2011-10-12 18:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: cbe-oss-dev, linuxppc-dev
Fix uninitialized variable warnings in build of repository.c
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/repository.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -184,7 +184,7 @@ int ps3_repository_read_bus_type(unsigne
enum ps3_bus_type *bus_type)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -199,7 +199,7 @@ int ps3_repository_read_bus_num_dev(unsi
unsigned int *num_dev)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -239,7 +239,7 @@ int ps3_repository_read_dev_type(unsigne
unsigned int dev_index, enum ps3_dev_type *dev_type)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -256,8 +256,8 @@ int ps3_repository_read_dev_intr(unsigne
enum ps3_interrupt_type *intr_type, unsigned int *interrupt_id)
{
int result;
- u64 v1;
- u64 v2;
+ u64 v1 = 0;
+ u64 v2 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -275,7 +275,7 @@ int ps3_repository_read_dev_reg_type(uns
enum ps3_reg_type *reg_type)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -615,7 +615,7 @@ int ps3_repository_read_stor_dev_num_reg
unsigned int dev_index, unsigned int *num_regions)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -631,7 +631,7 @@ int ps3_repository_read_stor_dev_region_
unsigned int *region_id)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("bus", bus_index),
@@ -786,7 +786,7 @@ int ps3_repository_read_mm_info(u64 *rm_
int ps3_repository_read_num_spu_reserved(unsigned int *num_spu_reserved)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -805,7 +805,7 @@ int ps3_repository_read_num_spu_reserved
int ps3_repository_read_num_spu_resource_id(unsigned int *num_resource_id)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -827,8 +827,8 @@ int ps3_repository_read_spu_resource_id(
enum ps3_spu_resource_type *resource_type, unsigned int *resource_id)
{
int result;
- u64 v1;
- u64 v2;
+ u64 v1 = 0;
+ u64 v2 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -854,7 +854,7 @@ static int ps3_repository_read_boot_dat_
int ps3_repository_read_boot_dat_size(unsigned int *size)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -869,7 +869,7 @@ int ps3_repository_read_boot_dat_size(un
int ps3_repository_read_vuart_av_port(unsigned int *port)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -884,7 +884,7 @@ int ps3_repository_read_vuart_av_port(un
int ps3_repository_read_vuart_sysmgr_port(unsigned int *port)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
@@ -919,7 +919,7 @@ int ps3_repository_read_boot_dat_info(u6
int ps3_repository_read_num_be(unsigned int *num_be)
{
int result;
- u64 v1;
+ u64 v1 = 0;
result = read_node(PS3_LPAR_ID_PME,
make_first_field("ben", 0),
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Kumar Gala @ 2011-10-12 18:32 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <13184437244040-git-send-email-beckyb@kernel.crashing.org>
On Oct 12, 2011, at 1:22 PM, Becky Bruce wrote:
> From: Becky Bruce <beckyb@kernel.crashing.org>
>=20
> Currently, it does a cntlzd on the size and then subtracts it from
> 21.... this doesn't take into account the varying size of a "long".
> Just use __ilog instead (and subtract the 10 we have to subtract
> to get to the tsize encoding).
>=20
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/mm/fsl_booke_mmu.c =
b/arch/powerpc/mm/fsl_booke_mmu.c
> index f7802c8..54897c0 100644
> --- a/arch/powerpc/mm/fsl_booke_mmu.c
> +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> @@ -111,7 +111,7 @@ static void settlbcam(int index, unsigned long =
virt, phys_addr_t phys,
> unsigned int tsize, lz;
>=20
> asm (PPC_CNTLZL "%0,%1" : "=3Dr" (lz) : "r" (size));
> - tsize =3D 21 - lz;
> + tsize =3D __ilog2(size) - 10;
If you do this you don't need 'lz' or the asm() statement.
>=20
> #ifdef CONFIG_SMP
> if ((flags & _PAGE_NO_CACHE) =3D=3D 0)
> --=20
> 1.5.6.5
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Becky Bruce @ 2011-10-12 18:22 UTC (permalink / raw)
To: linuxppc-dev
From: Becky Bruce <beckyb@kernel.crashing.org>
Currently, it does a cntlzd on the size and then subtracts it from
21.... this doesn't take into account the varying size of a "long".
Just use __ilog instead (and subtract the 10 we have to subtract
to get to the tsize encoding).
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index f7802c8..54897c0 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -111,7 +111,7 @@ static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned int tsize, lz;
asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (size));
- tsize = 21 - lz;
+ tsize = __ilog2(size) - 10;
#ifdef CONFIG_SMP
if ((flags & _PAGE_NO_CACHE) == 0)
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: K.Prasad @ 2011-10-12 17:39 UTC (permalink / raw)
To: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20111012033359.GR4849@truffala.fritz.box>
On Wed, Oct 12, 2011 at 02:33:59PM +1100, David Gibson wrote:
> On Fri, Sep 16, 2011 at 12:57:10PM +0530, K.Prasad wrote:
> > On Fri, Aug 26, 2011 at 03:05:52PM +0530, K.Prasad wrote:
> > > On Wed, Aug 24, 2011 at 01:59:39PM +1000, David Gibson wrote:
> > > > On Tue, Aug 23, 2011 at 02:55:13PM +0530, K.Prasad wrote:
> > > > > On Tue, Aug 23, 2011 at 03:08:50PM +1000, David Gibson wrote:
> > > > > > On Fri, Aug 19, 2011 at 01:21:36PM +0530, K.Prasad wrote:
[snipped]
> > [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
> >
> > PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> > PowerPC specific ptrace flags that use the watchpoint register. While they are
> > targeted primarily towards BookE users, user-space applications such as GDB
> > have started using them for BookS too.
> >
> > This patch enables the use of generic hardware breakpoint interfaces for these
> > new flags. The version number of the associated data structures
> > "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
>
> Above pargraph needs revision.
>
>
Sure, done.
> > Apart from the usual benefits of using generic hw-breakpoint interfaces, these
> > changes allow debuggers (such as GDB) to use a common set of ptrace flags for
> > their watchpoint needs and allow more precise breakpoint specification (length
> > of the variable can be specified).
> >
> > [Edjunior: Identified an issue in the patch with the sanity check for version
> > numbers]
> >
> > Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
> > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
> >
> > diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
> > index f4a5499..04656ec 100644
> > --- a/Documentation/powerpc/ptrace.txt
> > +++ b/Documentation/powerpc/ptrace.txt
> > @@ -127,6 +127,22 @@ Some examples of using the structure to:
> > p.addr2 = (uint64_t) end_range;
> > p.condition_value = 0;
> >
> > +- set a watchpoint in server processors (BookS)
> > +
> > + p.version = 1;
> > + p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
> > + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
> > + or
> > + p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
>
> MODE_RANGE_EXACT? Shouldn't that just be MODE_EXACT?
>
That was silly. Thanks for pointing it out.
> > +
> > + p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
> > + p.addr = (uint64_t) begin_range;
> > + /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
> > + * addr2 - addr <= 8 Bytes.
> > + */
> > + p.addr2 = (uint64_t) end_range;
> > + p.condition_value = 0;
> > +
> > 3. PTRACE_DELHWDEBUG
> >
> > Takes an integer which identifies an existing breakpoint or watchpoint
> > diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> > index 05b7dd2..2449495 100644
> > --- a/arch/powerpc/kernel/ptrace.c
> > +++ b/arch/powerpc/kernel/ptrace.c
> > @@ -1339,6 +1339,12 @@ static int set_dac_range(struct task_struct *child,
> > static long ppc_set_hwdebug(struct task_struct *child,
> > struct ppc_hw_breakpoint *bp_info)
> > {
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + int ret, len = 0;
> > + struct thread_struct *thread = &(child->thread);
> > + struct perf_event *bp;
> > + struct perf_event_attr attr;
> > +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> > #ifndef CONFIG_PPC_ADV_DEBUG_REGS
> > unsigned long dabr;
> > #endif
> > @@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > */
> > if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
> > (bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
> > - bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
> > bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
> > return -EINVAL;
> >
> > - if (child->thread.dabr)
> > - return -ENOSPC;
> > -
> > if ((unsigned long)bp_info->addr >= TASK_SIZE)
> > return -EIO;
> >
> > @@ -1398,15 +1400,83 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > dabr |= DABR_DATA_READ;
> > if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
> > dabr |= DABR_DATA_WRITE;
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + if (ptrace_get_breakpoints(child) < 0)
> > + return -ESRCH;
> >
> > - child->thread.dabr = dabr;
> > + bp = thread->ptrace_bps[0];
> > + if (!bp_info->addr) {
>
> I think this is treating a hardware breakpoint at address 0 as if it
> didn't exist. That seems wrong.
>
Yes, I think the above the condition need not exist after we've agreed
that 0 is a valid address to set breakpoint upon. One needs to use
PPC_PTRACE_DELHWDEBUG to delete a breakpoint and not by writing 0 (as
done with PTRACE_SET_DEBUGREG).
I'll remove that.
> > + if (bp) {
> > + unregister_hw_breakpoint(bp);
> > + thread->ptrace_bps[0] = NULL;
> > + }
> > + ptrace_put_breakpoints(child);
> > + return 0;
> > + }
> > + /*
> > + * Check if the request is for 'range' breakpoints. We can
> > + * support it if range < 8 bytes.
> > + */
> > + if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
> > + len = bp_info->addr2 - bp_info->addr;
> > + else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
> > + ptrace_put_breakpoints(child);
> > + return -EINVAL;
> > + }
>
> Misindent here. This statement would be clearer if you had {} on all
> of the if branches.
>
Okay, done.
> > + if (bp) {
> > + attr = bp->attr;
> > + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> > + arch_bp_generic_fields(dabr &
> > + (DABR_DATA_WRITE | DABR_DATA_READ),
> > + &attr.bp_type);
> > + attr.bp_len = len;
>
> If gdb is using the new breakpoint interface, surely it should just
> use it, rather than doing this bit frobbing as in the old SET_DABR
> call.
>
I understand that you wanted to avoid this duplication of effort in terms
of encoding and decoding the breakpoint type from
PPC_BREAKPOINT_TRIGGER_READ to DABR_DATA_READ to HW_BREAKPOINT_R.
However HW_BREAKPOINT_R is a generic definition used across
architectures, DABR_DATA_READ is used in the !CONFIG_HAVE_HW_BREAKPOINT
case while PPC_BREAKPOINT_TRIGGER_READ is used in
CONFIG_PPC_ADV_DEBUG_REGS case.
While we could define PPC_BREAKPOINT_TRIGGER_READ and DABR_DATA_READ to
the same value it may not result in any code savings (since the bit
translation is done for !CONFIG_HAVE_HW_BREAKPOINT case anyway). So, I
think it is best left the way it is.
I'm attaching the revised patch (after incorporating your comments).
Kindly let me know your comments.
Thanks,
K.Prasad
---------
[hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
PowerPC specific ptrace flags that use the watchpoint register. While they are
targeted primarily towards BookE users, user-space applications such as GDB
have started using them for BookS too. This patch enables the use of generic
hardware breakpoint interfaces for these new flags.
Apart from the usual benefits of using generic hw-breakpoint interfaces, these
changes allow debuggers (such as GDB) to use a common set of ptrace flags for
their watchpoint needs and allow more precise breakpoint specification (length
of the variable can be specified).
Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
Documentation/powerpc/ptrace.txt | 16 +++++++
arch/powerpc/kernel/ptrace.c | 88 +++++++++++++++++++++++++++++++++++---
2 files changed, 98 insertions(+), 6 deletions(-)
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f4a5499..f2a7a39 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
+- set a watchpoint in server processors (BookS)
+
+ p.version = 1;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+ * addr2 - addr <= 8 Bytes.
+ */
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
3. PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 05b7dd2..be5dc57 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1339,6 +1339,12 @@ static int set_dac_range(struct task_struct *child,
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int ret, len = 0;
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long dabr;
#endif
@@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
*/
if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
(bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
- bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
return -EINVAL;
- if (child->thread.dabr)
- return -ENOSPC;
-
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
@@ -1398,15 +1400,75 @@ static long ppc_set_hwdebug(struct task_struct *child,
dabr |= DABR_DATA_READ;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
dabr |= DABR_DATA_WRITE;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
- child->thread.dabr = dabr;
+ /*
+ * Check if the request is for 'range' breakpoints. We can
+ * support it if range < 8 bytes.
+ */
+ if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE) {
+ len = bp_info->addr2 - bp_info->addr;
+ } else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
+ ptrace_put_breakpoints(child);
+ return -EINVAL;
+ }
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(dabr &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+ attr.bp_len = len;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret) {
+ ptrace_put_breakpoints(child);
+ return ret;
+ }
+ thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(child);
+ thread->dabr = dabr;
+ return 0;
+ }
+
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ attr.bp_len = len;
+ arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, NULL, child);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(child);
+ return PTR_ERR(bp);
+ }
+ ptrace_put_breakpoints(child);
+ return 1;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
+ if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
+ return -EINVAL;
+
+ if (child->thread.dabr)
+ return -ENOSPC;
+
+ child->thread.dabr = dabr;
return 1;
#endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
}
static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
int rc;
@@ -1426,10 +1488,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
#else
if (data != 1)
return -EINVAL;
+
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
+
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
if (child->thread.dabr == 0)
return -ENOENT;
child->thread.dabr = 0;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
return 0;
#endif
@@ -1560,7 +1636,7 @@ long arch_ptrace(struct task_struct *child, long request,
dbginfo.data_bp_alignment = 4;
#endif
dbginfo.sizeof_condition = 0;
- dbginfo.features = 0;
+ dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
if (!access_ok(VERIFY_WRITE, datavp,
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Hans J. Koch @ 2011-10-12 16:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, gregkh, linux-kernel
In-Reply-To: <AEAF26D0-640A-4DD2-82FE-B3BD02662EEC@kernel.crashing.org>
On Wed, Oct 12, 2011 at 11:08:20AM -0500, Kumar Gala wrote:
>
> On Oct 12, 2011, at 10:35 AM, Hans J. Koch wrote:
>
> > On Wed, Oct 12, 2011 at 09:43:36AM -0500, Kumar Gala wrote:
> >> For some devices the default behavior of pgprot_noncached is not
> >> the correct flags for the address space.
> >
> > For what devices? Can you give a real world usecase where this is needed?
> >
> > Thanks,
> > Hans
>
> In the Freescale Networking devices we have a coherent memory interface to our HW queuing system. In that case we want to change the pgprot() to be cache-able instead of non-cached.
Could you please post the kernel part of that driver?
Thanks,
Hans
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 16:19 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
In-Reply-To: <20111012153229.GB21852@local>
On Wed, Oct 12, 2011 at 05:32:29PM +0200, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> > From: Kai Jiang <Kai.Jiang@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 contain a physical, logical, or virtual address the
> > easiest solution is to just change the type to 'unsigned long long'
> > regardless of which type is utilized.
>
> No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
> Please use that.
I forgot: If you resend this, please update the documentation as well.
(Documentation/DocBook/uio-howto.tmpl)
Thanks,
Hans
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 15:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, hjk, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <1318430145-19898-1-git-send-email-galak@kernel.crashing.org>
On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> From: Kai Jiang <Kai.Jiang@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 contain a physical, logical, or virtual address the
> easiest solution is to just change the type to 'unsigned long long'
> regardless of which type is utilized.
No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
Please use that.
Thanks,
Hans
>
> For physical address we can support up to a 44-bit physical address on a
> typical 32-bit system as we utilize remap_pfn_range() for the mapping of
> the memory region and pfn's are represnted by shifting the address by
> the page size (typically 4k).
>
> Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/uio/uio.c | 8 ++++----
> include/linux/uio_driver.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index d2efe82..a927c51 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
>
> static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
> {
> - return sprintf(buf, "0x%lx\n", mem->addr);
> + return sprintf(buf, "0x%llx\n", mem->addr);
> }
>
> static ssize_t map_size_show(struct uio_mem *mem, char *buf)
> @@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
>
> static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
> {
> - return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
> + return sprintf(buf, "0x%llx\n", mem->addr & ~PAGE_MASK);
> }
>
> struct map_sysfs_entry {
> @@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
> page = virt_to_page(idev->info->mem[mi].addr + offset);
> else
> - page = vmalloc_to_page((void *)idev->info->mem[mi].addr
> - + offset);
> + page = vmalloc_to_page((void *)(unsigned long)
> + idev->info->mem[mi].addr + offset);
> get_page(page);
> vmf->page = page;
> return 0;
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 665517c..c1fdb19 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -31,7 +31,7 @@ struct uio_map;
> */
> struct uio_mem {
> const char *name;
> - unsigned long addr;
> + unsigned long long addr;
> unsigned long size;
> int memtype;
> void __iomem *internal_addr;
> --
> 1.7.3.4
>
>
^ permalink raw reply
* Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Hans J. Koch @ 2011-10-12 15:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, hjk, gregkh, linux-kernel
In-Reply-To: <1318430616-20351-1-git-send-email-galak@kernel.crashing.org>
On Wed, Oct 12, 2011 at 09:43:36AM -0500, Kumar Gala wrote:
> For some devices the default behavior of pgprot_noncached is not
> the correct flags for the address space.
For what devices? Can you give a real world usecase where this is needed?
Thanks,
Hans
> Provide a means for the
> kernel side UIO driver to override the flags without having to
> implement its own full mmap callback.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/uio/uio.c | 6 +++++-
> include/linux/uio_driver.h | 2 ++
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index d2efe82..88f4444 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -656,7 +656,11 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
>
> vma->vm_flags |= VM_IO | VM_RESERVED;
>
> - vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + if (idev->info->mem[mi].set_pgprot)
> + vma->vm_page_prot =
> + idev->info->mem[mi].set_pgprot(vma->vm_page_prot);
> + else
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>
> return remap_pfn_range(vma,
> vma->vm_start,
> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
> index 665517c..4c618cd 100644
> --- a/include/linux/uio_driver.h
> +++ b/include/linux/uio_driver.h
> @@ -28,6 +28,7 @@ struct uio_map;
> * @memtype: type of memory addr points to
> * @internal_addr: ioremap-ped version of addr, for driver internal use
> * @map: for use by the UIO core only.
> + * @set_pgprot: allow driver to override default(noncached) pgprot
> */
> struct uio_mem {
> const char *name;
> @@ -36,6 +37,7 @@ struct uio_mem {
> int memtype;
> void __iomem *internal_addr;
> struct uio_map *map;
> + pgprot_t (*set_pgprot)(pgprot_t prot);
> };
>
> #define MAX_UIO_MAPS 5
> --
> 1.7.3.4
>
>
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Hans J. Koch @ 2011-10-12 16:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <AD39F4F8-E9C0-4090-9AEA-644F82DD328B@kernel.crashing.org>
On Wed, Oct 12, 2011 at 11:07:09AM -0500, Kumar Gala wrote:
>
> On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
>
> > On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> >> From: Kai Jiang <Kai.Jiang@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 contain a physical, logical, or virtual address the
> >> easiest solution is to just change the type to 'unsigned long long'
> >> regardless of which type is utilized.
> >
> > No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
> > Please use that.
>
> Do we believe phys_addr_t is always greater than or equal to size need for logical & virtual addresses?
Yes.
Hans
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Geert Uytterhoeven @ 2011-10-12 16:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Hans J. Koch, Kai Jiang, gregkh, linux-kernel
In-Reply-To: <AD39F4F8-E9C0-4090-9AEA-644F82DD328B@kernel.crashing.org>
On Wed, Oct 12, 2011 at 18:07, Kumar Gala <galak@kernel.crashing.org> wrote=
:
> On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
>> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>>> From: Kai Jiang <Kai.Jiang@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. =C2=A0Numerous platforms =
like
>>> embedded PPC, ARM, and X86 have support for systems with larger physica=
l
>>> address than logical.
>>>
>>> Since 'addr' may contain a physical, logical, or virtual address the
>>> easiest solution is to just change the type to 'unsigned long long'
>>> regardless of which type is utilized.
>>
>> No. There's phys_addr_t for that purpose, defined in include/linux/types=
.h.
>> Please use that.
>
> Do we believe phys_addr_t is always greater than or equal to size need fo=
r logical & virtual addresses?
Yes:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Kumar Gala @ 2011-10-12 16:08 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, linux-kernel
In-Reply-To: <20111012153536.GC21852@local>
On Oct 12, 2011, at 10:35 AM, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 09:43:36AM -0500, Kumar Gala wrote:
>> For some devices the default behavior of pgprot_noncached is not
>> the correct flags for the address space.
>=20
> For what devices? Can you give a real world usecase where this is =
needed?
>=20
> Thanks,
> Hans
In the Freescale Networking devices we have a coherent memory interface =
to our HW queuing system. In that case we want to change the pgprot() =
to be cache-able instead of non-cached.
- k
>=20
>> Provide a means for the
>> kernel side UIO driver to override the flags without having to
>> implement its own full mmap callback.
>>=20
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> drivers/uio/uio.c | 6 +++++-
>> include/linux/uio_driver.h | 2 ++
>> 2 files changed, 7 insertions(+), 1 deletions(-)
>>=20
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index d2efe82..88f4444 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -656,7 +656,11 @@ static int uio_mmap_physical(struct =
vm_area_struct *vma)
>>=20
>> vma->vm_flags |=3D VM_IO | VM_RESERVED;
>>=20
>> - vma->vm_page_prot =3D pgprot_noncached(vma->vm_page_prot);
>> + if (idev->info->mem[mi].set_pgprot)
>> + vma->vm_page_prot =3D
>> + =
idev->info->mem[mi].set_pgprot(vma->vm_page_prot);
>> + else
>> + vma->vm_page_prot =3D =
pgprot_noncached(vma->vm_page_prot);
>>=20
>> return remap_pfn_range(vma,
>> vma->vm_start,
>> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
>> index 665517c..4c618cd 100644
>> --- a/include/linux/uio_driver.h
>> +++ b/include/linux/uio_driver.h
>> @@ -28,6 +28,7 @@ struct uio_map;
>> * @memtype: type of memory addr points to
>> * @internal_addr: ioremap-ped version of addr, for driver internal =
use
>> * @map: for use by the UIO core only.
>> + * @set_pgprot: allow driver to override =
default(noncached) pgprot
>> */
>> struct uio_mem {
>> const char *name;
>> @@ -36,6 +37,7 @@ struct uio_mem {
>> int memtype;
>> void __iomem *internal_addr;
>> struct uio_map *map;
>> + pgprot_t (*set_pgprot)(pgprot_t prot);
>> };
>>=20
>> #define MAX_UIO_MAPS 5
>> --=20
>> 1.7.3.4
>>=20
>>=20
^ permalink raw reply
* Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 16:07 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
In-Reply-To: <20111012153229.GB21852@local>
On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>> From: Kai Jiang <Kai.Jiang@freescale.com>
>>=20
>> 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.
>>=20
>> Since 'addr' may contain a physical, logical, or virtual address the
>> easiest solution is to just change the type to 'unsigned long long'
>> regardless of which type is utilized.
>=20
> No. There's phys_addr_t for that purpose, defined in =
include/linux/types.h.
> Please use that.
Do we believe phys_addr_t is always greater than or equal to size need =
for logical & virtual addresses?
- k
> Thanks,
> Hans
>=20
>>=20
>> For physical address we can support up to a 44-bit physical address =
on a
>> typical 32-bit system as we utilize remap_pfn_range() for the mapping =
of
>> the memory region and pfn's are represnted by shifting the address by
>> the page size (typically 4k).
>>=20
>> Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
>> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> drivers/uio/uio.c | 8 ++++----
>> include/linux/uio_driver.h | 2 +-
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>=20
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index d2efe82..a927c51 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, =
char *buf)
>>=20
>> static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
>> {
>> - return sprintf(buf, "0x%lx\n", mem->addr);
>> + return sprintf(buf, "0x%llx\n", mem->addr);
>> }
>>=20
>> static ssize_t map_size_show(struct uio_mem *mem, char *buf)
>> @@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, =
char *buf)
>>=20
>> static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
>> {
>> - return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
>> + return sprintf(buf, "0x%llx\n", mem->addr & ~PAGE_MASK);
>> }
>>=20
>> struct map_sysfs_entry {
>> @@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct =
*vma, struct vm_fault *vmf)
>> if (idev->info->mem[mi].memtype =3D=3D UIO_MEM_LOGICAL)
>> page =3D virt_to_page(idev->info->mem[mi].addr + =
offset);
>> else
>> - page =3D vmalloc_to_page((void =
*)idev->info->mem[mi].addr
>> - + offset);
>> + page =3D vmalloc_to_page((void *)(unsigned long)
>> + idev->info->mem[mi].addr + offset);
>> get_page(page);
>> vmf->page =3D page;
>> return 0;
>> diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
>> index 665517c..c1fdb19 100644
>> --- a/include/linux/uio_driver.h
>> +++ b/include/linux/uio_driver.h
>> @@ -31,7 +31,7 @@ struct uio_map;
>> */
>> struct uio_mem {
>> const char *name;
>> - unsigned long addr;
>> + unsigned long long addr;
>> unsigned long size;
>> int memtype;
>> void __iomem *internal_addr;
>> --=20
>> 1.7.3.4
>>=20
>>=20
^ permalink raw reply
* [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
From: Kumar Gala @ 2011-10-12 14:43 UTC (permalink / raw)
To: hjk; +Cc: linuxppc-dev, gregkh, linux-kernel
For some devices the default behavior of pgprot_noncached is not
the correct flags for the address space. Provide a means for the
kernel side UIO driver to override the flags without having to
implement its own full mmap callback.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/uio/uio.c | 6 +++++-
include/linux/uio_driver.h | 2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index d2efe82..88f4444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -656,7 +656,11 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
vma->vm_flags |= VM_IO | VM_RESERVED;
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ if (idev->info->mem[mi].set_pgprot)
+ vma->vm_page_prot =
+ idev->info->mem[mi].set_pgprot(vma->vm_page_prot);
+ else
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
return remap_pfn_range(vma,
vma->vm_start,
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 665517c..4c618cd 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -28,6 +28,7 @@ struct uio_map;
* @memtype: type of memory addr points to
* @internal_addr: ioremap-ped version of addr, for driver internal use
* @map: for use by the UIO core only.
+ * @set_pgprot: allow driver to override default(noncached) pgprot
*/
struct uio_mem {
const char *name;
@@ -36,6 +37,7 @@ struct uio_mem {
int memtype;
void __iomem *internal_addr;
struct uio_map *map;
+ pgprot_t (*set_pgprot)(pgprot_t prot);
};
#define MAX_UIO_MAPS 5
--
1.7.3.4
^ permalink raw reply related
* [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-12 14:35 UTC (permalink / raw)
To: hjk; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
From: Kai Jiang <Kai.Jiang@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 contain a physical, logical, or virtual address the
easiest solution is to just change the type to 'unsigned long long'
regardless of which type is utilized.
For physical address we can support up to a 44-bit physical address on a
typical 32-bit system as we utilize remap_pfn_range() for the mapping of
the memory region and pfn's are represnted by shifting the address by
the page size (typically 4k).
Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/uio/uio.c | 8 ++++----
include/linux/uio_driver.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index d2efe82..a927c51 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr);
+ return sprintf(buf, "0x%llx\n", mem->addr);
}
static ssize_t map_size_show(struct uio_mem *mem, char *buf)
@@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
+ return sprintf(buf, "0x%llx\n", mem->addr & ~PAGE_MASK);
}
struct map_sysfs_entry {
@@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
page = virt_to_page(idev->info->mem[mi].addr + offset);
else
- page = vmalloc_to_page((void *)idev->info->mem[mi].addr
- + offset);
+ page = vmalloc_to_page((void *)(unsigned long)
+ idev->info->mem[mi].addr + offset);
get_page(page);
vmf->page = page;
return 0;
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 665517c..c1fdb19 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -31,7 +31,7 @@ struct uio_map;
*/
struct uio_mem {
const char *name;
- unsigned long addr;
+ unsigned long long addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
From: Dave Hansen @ 2011-10-12 14:15 UTC (permalink / raw)
To: Suzuki Poulose
Cc: Michal Simek, tmarri, Mahesh Jagannath Salgaonkar, David Laight,
Paul Mackerras, Scott Wood, linux ppc dev, Vivek Goyal
In-Reply-To: <4E943C70.4030106@in.ibm.com>
On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
> On 10/10/11 23:30, Scott Wood wrote:
> > On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
> >> #if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
> >> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START + (KERNELBASE + RELOC_OFFSET)))
> >> #define __pa(x) ((unsigned long)(x) + PHYSICAL_START - (KERNELBASE + RELOC_OFFSET))
> >> #endif
> >
> > Why is this 44x-specific?
>
> As of now, we compile with relocations only for the 44x. We could make this
> generic once the approach is accepted by everyone and implemented on the other
> platforms.
This is not the place to enforce that kind of thing. If
CONFIG_RELOCATABLE is only supported on one platform, then do:
config RELOCATABLE
depends on 44x
and take the 44x reference out of the #ifdef.
-- Dave
^ permalink raw reply
* [PATCH] ll_temac: Add support for ethtool
From: Ricardo Ribalda Delgado @ 2011-10-12 11:47 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-netdev, dhlii, ville.sundell,
grant.likely
Cc: Ricardo Ribalda Delgado
This patch enables the ethtool interface. The implementation is done
using the libphy helper functions.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
drivers/net/ll_temac_main.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 728fe41..91a9804 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -957,6 +957,32 @@ static const struct attribute_group temac_attr_group = {
.attrs = temac_device_attrs,
};
+/* ethtool support */
+static int temac_get_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_gset(lp->phy_dev, cmd);
+}
+
+static int temac_set_settings(struct net_device *ndev, struct ethtool_cmd *cmd)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_ethtool_sset(lp->phy_dev, cmd);
+}
+
+static int temac_nway_reset(struct net_device *ndev)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ return phy_start_aneg(lp->phy_dev);
+}
+
+static const struct ethtool_ops temac_ethtool_ops = {
+ .get_settings = temac_get_settings,
+ .set_settings = temac_set_settings,
+ .nway_reset = temac_nway_reset,
+ .get_link = ethtool_op_get_link,
+};
+
static int __devinit temac_of_probe(struct platform_device *op)
{
struct device_node *np;
@@ -978,6 +1004,7 @@ static int __devinit temac_of_probe(struct platform_device *op)
ndev->flags &= ~IFF_MULTICAST; /* clear multicast */
ndev->features = NETIF_F_SG | NETIF_F_FRAGLIST;
ndev->netdev_ops = &temac_netdev_ops;
+ ndev->ethtool_ops= &temac_ethtool_ops;
#if 0
ndev->features |= NETIF_F_IP_CSUM; /* Can checksum TCP/UDP over IPv4. */
ndev->features |= NETIF_F_HW_CSUM; /* Can checksum all the packets. */
--
1.7.6.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox