Re: [PATCH v14 10/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
Hello. On 12-10-2011 2:43, Tirumala Marri wrote: <> +# dwc_otg builds in ../dwc along with host support <> +config USB_GADGET_DWC_HDRC <> + boolean "DesignWare USB Peripheral" <> + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY <> + select USB_GADGET_DUALSPEED <> + select USB_GADGET_SELECTED <> + select USB_GADGET_DWC_OTG < I don't see where this one is defined... [Tirumala Marri] You mean USB_GADGET_SELECTED ? Ok I will add it. No, I mean USB_GADGET_DWC_OTG. USB_GADGET_SELECTED is already defined. --marri WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ll_temac: Add support for ethtool
This patch enables the ethtool interface. The implementation is done
using the libphy helper functions.
Signed-off-by: Ricardo Ribalda Delgado
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kai Jiang
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
Signed-off-by: Minghuan Lian
Signed-off-by: Kumar Gala
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
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
---
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..88f 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
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
>>
>> 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?
- k
> 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
>> Signed-off-by: Minghuan Lian
>> Signed-off-by: Kumar Gala
>> ---
>> 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
>>
>>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
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.
- k
>
>> 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
>> ---
>> 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..88f 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
>>
>>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
On Wed, Oct 12, 2011 at 18:07, 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
>>>
>>> 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:
#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,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
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
> > Signed-off-by: K.Prasad
> >
> > 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 PTRA
[PATCH] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Becky Bruce 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 --- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-booke: Fix settlbcam for 64-bit
On Oct 12, 2011, at 1:22 PM, Becky Bruce wrote: > From: Becky Bruce > > 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 > --- > 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; If you do this you don't need 'lz' or the asm() statement. > > #ifdef CONFIG_SMP > if ((flags & _PAGE_NO_CACHE) == 0) > -- > 1.5.6.5 > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ps3: Fix PS3 repository build warnings
Fix uninitialized variable warnings in build of repository.c
Signed-off-by: Geoff Levand
---
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),
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
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 >>> >>> 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? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ps3: Fix lv1_gpu_attribute hcall
The lv1_gpu_attribute hcall takes three, not five input
arguments. Adjust the lv1 hcall table and all calls.
Signed-off-by: Geoff Levand
CC: Takashi Iwai
---
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);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Kai Jiang
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
Signed-off-by: Minghuan Lian
Signed-off-by: Kumar Gala
---
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
kmalloc()). There's also
-unsigned long addr: Required if the mapping is used.
+phys_addr_t addr: Required if the mapping is used.
Fill in the address of your memory block. This address is the one that
appears in sysfs.
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 88f..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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
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: >> >> 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 > > 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 New version sent, let me know if there are any other aspects to the DocBook that need updating. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/fsl-booke: Fix settlbcam for 64-bit
From: Becky Bruce
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4
Joakim Tjernlund/Transmode wrote on 2011/10/11 09:42:58: > > Dan Malek 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
How to handle cache when I allocate phys memory?
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
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 > >> > >> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
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
> ---
> 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..88f 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
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
> From: Kai Jiang
>
> 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
> Signed-off-by: Minghuan Lian
> Signed-off-by: Kumar Gala
> ---
> 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
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
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 > > > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] UIO: Allow a UIO driver to override the default pgprot when we mmap
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
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 > >>> > >>> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ll_temac: Add support for ethtool
On Wed, Oct 12, 2011 at 01:47:29PM +0200, Ricardo Ribalda Delgado wrote:
> This patch enables the ethtool interface. The implementation is done
> using the libphy helper functions.
>
> Signed-off-by: Ricardo Ribalda Delgado
Looks good to me.
Reviewed-by: Grant Likely
> ---
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: e500mc: Fix: use CONFIG_PPC_E500MC in idle_e500.S
It is wrongly using undefined CONFIG_E500MC. Tested on custom p4080DS board. Signed-off-by: Bharat Bhushan --- arch/powerpc/kernel/idle_e500.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S index 3e2b95c..4f0ab85 100644 --- a/arch/powerpc/kernel/idle_e500.S +++ b/arch/powerpc/kernel/idle_e500.S @@ -26,7 +26,7 @@ _GLOBAL(e500_idle) ori r4,r4,_TLF_NAPPING /* so when we take an exception */ stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our caller */ -#ifdef CONFIG_E500MC +#ifdef CONFIG_PPC_E500MC wrteei 1 1: wait -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fsl-booke: Fix settlbcam for 64-bit
On Oct 12, 2011, at 4:17 PM, Becky Bruce wrote: > From: Becky Bruce > > 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 > --- > 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(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/ps3: Fix lv1_gpu_attribute hcall
At Wed, 12 Oct 2011 11:42:13 -0700,
Geoff Levand wrote:
>
> The lv1_gpu_attribute hcall takes three, not five input
> arguments. Adjust the lv1 hcall table and all calls.
>
> Signed-off-by: Geoff Levand
> CC: Takashi Iwai
Acked-by: Takashi Iwai
> ---
> 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);
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
