* Re: [PATCH] Miscellaneous for Taco
From: Benjamin Herrenschmidt @ 2008-01-05 7:24 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <477F13C0.7040006@pikatech.com>
On Sat, 2008-01-05 at 00:21 -0500, Sean MacLennan wrote:
> Last ones for now.
>
> This patch allows you to turn off scsi_wait_scan.
You'll have to run that one via the SCSI maintainers.
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index a6676be..960dc78 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -248,7 +248,7 @@ config SCSI_SCAN_ASYNC
> or async on the kernel's command line.
>
> config SCSI_WAIT_SCAN
> - tristate
> + tristate "SCSI wait scan"
> default m
> depends on SCSI
> depends on MODULES
>
> This patch allows you to use the USB with the taco. The taco does not
> have PCI so we must specifically add it.
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 7580aa5..480580c 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
> # PPC:
> default y if STB03xxx
> default y if PPC_MPC52xx
> + default y if TACO
> # MIPS:
> default y if SOC_AU1X00
> # more:
I think we should instead reference use the 440EP here, or select it
from your board code. I -hate- those long lists of board specific bits
hidden in driver Kconfig...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Stefan Roese @ 2008-01-05 9:26 UTC (permalink / raw)
To: linuxppc-dev, benh; +Cc: Sean MacLennan
In-Reply-To: <1199517865.7291.50.camel@pasglop>
On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> > index 7580aa5..480580c 100644
> > --- a/drivers/usb/Kconfig
> > +++ b/drivers/usb/Kconfig
> > @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
> > # PPC:
> > default y if STB03xxx
> > default y if PPC_MPC52xx
> > + default y if TACO
> > # MIPS:
> > default y if SOC_AU1X00
> > # more:
>
> I think we should instead reference use the 440EP here,
I vote for adding 440EP here.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Stefan Roese @ 2008-01-05 9:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <477F12D1.2070109@pikatech.com>
On Saturday 05 January 2008, Sean MacLennan wrote:
> This patch adds the maps for the taco. It also gets the ndfc.c NAND
> driver in a compilable state. The map is guaranteed to change since the
> exact NOR/NAND flash configuration is in flux right now when we found
> the 256M NAND flash won't boot properly.
>
> Currently it configures the NOR in a reasonable fashion and leaves the
> NAND as one honkin' parition.
<snip>
> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
> index 1c0e89f..f5e93cf 100644
> --- a/drivers/mtd/nand/ndfc.c
> +++ b/drivers/mtd/nand/ndfc.c
> @@ -24,11 +24,6 @@
> =A0#include <linux/platform_device.h>
> =A0
> =A0#include <asm/io.h>
> -#ifdef CONFIG_40x
> -#include <asm/ibm405.h>
> -#else
> -#include <asm/ibm44x.h>
> -#endif
You do break arch/ppc support with this patch. We have to still support
arch/ppc a few month, so please don't break this support for now.
=A0
> =A0struct ndfc_nand_mtd {
> =A0=A0=A0=A0=A0=A0=A0=A0struct mtd_info=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0mtd;
> @@ -110,6 +105,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
> =A0=A0=A0=A0=A0=A0=A0=A0return 0;
> =A0}
> =A0
> +#ifdef CONFIG_TACO
> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
> + * the taco!
> + */
We definitely don't want to see such board specific stuff in the common
NDFC driver. And I really doubt that you need this change for your board.
We are using this ndfc driver on multiple boards, and all have no
problems accessing the controller with 32bit read/writes. So you most
likely have a problem with your board port. Perhaps something with
with the EBC setup. Please re-check and compare with boards that are know
to work, like Sequoia.
> +static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
> +{
> +=A0=A0=A0=A0=A0=A0=A0struct ndfc_controller *ndfc =3D &ndfc_ctrl;
> +=A0=A0=A0=A0=A0=A0=A0uint8_t *p =3D (uint8_t *) buf;
> +
> +=A0=A0=A0=A0=A0=A0=A0for(;len > 0; len -=3D 1)
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0*p++ =3D __raw_readb(ndfc->=
ndfcbase + NDFC_DATA);
> +}
> +
> +static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
> len) +{
> +=A0=A0=A0=A0=A0=A0=A0struct ndfc_controller *ndfc =3D &ndfc_ctrl;
> +=A0=A0=A0=A0=A0=A0=A0uint8_t *p =3D (uint8_t *) buf;
> +
> +=A0=A0=A0=A0=A0=A0=A0for(;len > 0; len -=3D 1)
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0__raw_writeb(*p++, ndfc->nd=
fcbase + NDFC_DATA);
> +}
> +
> +static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
> len) +{
> +=A0=A0=A0=A0=A0=A0=A0struct ndfc_controller *ndfc =3D &ndfc_ctrl;
> +=A0=A0=A0=A0=A0=A0=A0uint8_t *p =3D (uint8_t *) buf;
> +
> +=A0=A0=A0=A0=A0=A0=A0for(;len > 0; len -=3D 1)
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (*p++ !=3D __raw_readb(n=
dfc->ndfcbase + NDFC_DATA))
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret=
urn -EFAULT;
> +
> +=A0=A0=A0=A0=A0=A0=A0return 0;
> +}
> +#else
<snip>
> +++ drivers/mtd/maps/taco.c=A0=A0=A0=A0=A02008-01-02 13:07:43.000000000 -=
0500
> @@ -0,0 +1,140 @@
> +/*
> + * $Id: $
> + *
> + * drivers/mtd/maps/taco.c
> + *
> + * Mapping for PIKA Taco flash
I'm pretty sure that you don't need a board specific mapping driver
for NOR flash. physmap_of should be exactly what you need. You just need
to fill the device tree properties correctly.
BTW: I noticed you are using the boot wrapper approach. This is not
necessary anymore, since the latest U-Boot version has flattened
device tree support included for 4xx too. Let me know if you have any
questions about this.
Best regards,
Stefan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply
* [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Stefan Roese @ 2008-01-05 9:50 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
Performance tests done by AMCC have shown that 256 buffer increase the
performance of the Linux EMAC driver. So let's update the default
values to match this setup.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ibm_newemac/Kconfig b/drivers/net/ibm_newemac/Kconfig
index 0d3e738..5a06727 100644
--- a/drivers/net/ibm_newemac/Kconfig
+++ b/drivers/net/ibm_newemac/Kconfig
@@ -9,12 +9,12 @@ config IBM_NEW_EMAC
config IBM_NEW_EMAC_RXB
int "Number of receive buffers"
depends on IBM_NEW_EMAC
- default "128"
+ default "256"
config IBM_NEW_EMAC_TXB
int "Number of transmit buffers"
depends on IBM_NEW_EMAC
- default "64"
+ default "256"
config IBM_NEW_EMAC_POLL_WEIGHT
int "MAL NAPI polling weight"
--
1.5.4.rc2
^ permalink raw reply related
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Benjamin Herrenschmidt @ 2008-01-05 10:19 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <1199526609-12290-1-git-send-email-sr@denx.de>
On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> Performance tests done by AMCC have shown that 256 buffer increase the
> performance of the Linux EMAC driver. So let's update the default
> values to match this setup.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
Do we have the numbers ? Did they also measure latency ?
Ben.
> drivers/net/ibm_newemac/Kconfig | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/Kconfig b/drivers/net/ibm_newemac/Kconfig
> index 0d3e738..5a06727 100644
> --- a/drivers/net/ibm_newemac/Kconfig
> +++ b/drivers/net/ibm_newemac/Kconfig
> @@ -9,12 +9,12 @@ config IBM_NEW_EMAC
> config IBM_NEW_EMAC_RXB
> int "Number of receive buffers"
> depends on IBM_NEW_EMAC
> - default "128"
> + default "256"
>
> config IBM_NEW_EMAC_TXB
> int "Number of transmit buffers"
> depends on IBM_NEW_EMAC
> - default "64"
> + default "256"
>
> config IBM_NEW_EMAC_POLL_WEIGHT
> int "MAL NAPI polling weight"
^ permalink raw reply
* [PATCH v2] [POWERPC] Provide a way to protect 4k subpages when using 64k pages
From: Paul Mackerras @ 2008-01-05 11:02 UTC (permalink / raw)
To: linuxppc-dev
Using 64k pages on 64-bit PowerPC systems makes life difficult for
emulators that are trying to emulate an ISA, such as x86, which use a
smaller page size, since the emulator can no longer use the MMU and
the normal system calls for controlling page protections. Of course,
the emulator can emulate the MMU by checking and possibly remapping
the address for each memory access in software, but that is pretty
slow.
This provides a facility for such programs to control the access
permissions on individual 4k sub-pages of 64k pages. The idea is
that the emulator supplies an array of protection masks to apply to a
specified range of virtual addresses. These masks are applied at the
level where hardware PTEs are inserted into the hardware page table
based on the Linux PTEs, so the Linux PTEs are not affected. Note
that this new mechanism does not allow any access that would otherwise
be prohibited; it can only prohibit accesses that would otherwise be
allowed. This new facility is only available on 64-bit PowerPC and
only when the kernel is configured for 64k pages.
The masks are supplied using a new subpage_prot system call, which
takes a starting virtual address and length, and a pointer to an array
of protection masks in memory. The array has a 32-bit word per 64k
page to be protected; each 32-bit word consists of 16 2-bit fields,
for which 0 allows any access (that is otherwise allowed), 1 prevents
write accesses, and 2 or 3 prevent any access.
Implicit in this is that the regions of the address space that are
protected are switched to use 4k hardware pages rather than 64k
hardware pages (on machines with hardware 64k page support). In fact
the whole process is switched to use 4k hardware pages when the
subpage_prot system call is used, but this could be improved in future
to switch only the affected segments.
The subpage protection bits are stored in a 3 level tree akin to the
page table tree. The top level of this tree is stored in a structure
that is appended to the top level of the page table tree, i.e., the
pgd array. Since it will often only be 32-bit addresses (below 4GB)
that are protected, the pointers to the first four bottom level pages
are also stored in this structure (each bottom level page contains the
protection bits for 1GB of address space), so the protection bits for
addresses below 4GB can be accessed with one fewer loads than those
for higher addresses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
This version allocates a new system call number for the subpage_prot
syscall.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..53d0955 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -342,6 +342,14 @@ config PPC_64K_PAGES
while on hardware with such support, it will be used to map
normal application pages.
+config PPC_SUBPAGE_PROT
+ bool "Support setting protections for 4k subpages"
+ depends on PPC_64K_PAGES
+ help
+ This option adds support for a system call to allow user programs
+ to set access permissions (read/write, readonly, or no access)
+ on the 4k subpages of each 64k page.
+
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on PPC64 && SMP
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index c349868..11b4f6d 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -903,6 +903,7 @@ handle_page_fault:
* the PTE insertion
*/
12: bl .save_nvgprs
+ mr r5,r3
addi r3,r1,STACK_FRAME_OVERHEAD
ld r4,_DAR(r1)
bl .low_hash_fault
diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index 3b1d5dd..18be22e 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c
@@ -328,3 +328,7 @@ void do_show_syscall_exit(unsigned long r3)
{
printk(" -> %lx, current=%p cpu=%d\n", r3, current, smp_processor_id());
}
+
+#ifndef CONFIG_PPC_SUBPAGE_PROT
+cond_syscall(subpage_prot);
+#endif
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 20629ae..41649a5 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_FSL_BOOKE) += fsl_booke_mmu.o
obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
+obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S
index e935edd..21d2484 100644
--- a/arch/powerpc/mm/hash_low_64.S
+++ b/arch/powerpc/mm/hash_low_64.S
@@ -331,7 +331,8 @@ htab_pte_insert_failure:
*****************************************************************************/
/* _hash_page_4K(unsigned long ea, unsigned long access, unsigned long vsid,
- * pte_t *ptep, unsigned long trap, int local, int ssize)
+ * pte_t *ptep, unsigned long trap, int local, int ssize,
+ * int subpg_prot)
*/
/*
@@ -429,12 +430,19 @@ END_FTR_SECTION_IFSET(CPU_FTR_1T_SEGMENT)
xor r28,r28,r0 /* hash */
/* Convert linux PTE bits into HW equivalents */
-4: andi. r3,r30,0x1fe /* Get basic set of flags */
- xori r3,r3,HPTE_R_N /* _PAGE_EXEC -> NOEXEC */
+4:
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+ andc r10,r30,r10
+ andi. r3,r10,0x1fe /* Get basic set of flags */
+ rlwinm r0,r10,32-9+1,30,30 /* _PAGE_RW -> _PAGE_USER (r0) */
+#else
+ andi. r3,r30,0x1fe /* Get basic set of flags */
rlwinm r0,r30,32-9+1,30,30 /* _PAGE_RW -> _PAGE_USER (r0) */
+#endif
+ xori r3,r3,HPTE_R_N /* _PAGE_EXEC -> NOEXEC */
rlwinm r4,r30,32-7+1,30,30 /* _PAGE_DIRTY -> _PAGE_USER (r4) */
and r0,r0,r4 /* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/
- andc r0,r30,r0 /* r0 = pte & ~r0 */
+ andc r0,r3,r0 /* r0 = pte & ~r0 */
rlwimi r3,r0,32-1,31,31 /* Insert result into PP lsb */
ori r3,r3,HPTE_R_C /* Always add "C" bit for perf. */
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index cbbd8b0..9567b17 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -644,7 +644,7 @@ unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap)
* For now this makes the whole process use 4k pages.
*/
#ifdef CONFIG_PPC_64K_PAGES
-static void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
+void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
{
if (mm->context.user_psize == MMU_PAGE_4K)
return;
@@ -652,13 +652,62 @@ static void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
#ifdef CONFIG_SPU_BASE
spu_flush_all_slbs(mm);
#endif
+ if (get_paca()->context.user_psize != MMU_PAGE_4K) {
+ get_paca()->context = mm->context;
+ slb_flush_and_rebolt();
+ }
}
#endif /* CONFIG_PPC_64K_PAGES */
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+/*
+ * This looks up a 2-bit protection code for a 4k subpage of a 64k page.
+ * Userspace sets the subpage permissions using the subpage_prot system call.
+ *
+ * Result is 0: full permissions, _PAGE_RW: read-only,
+ * _PAGE_USER or _PAGE_USER|_PAGE_RW: no access.
+ */
+static int subpage_protection(pgd_t *pgdir, unsigned long ea)
+{
+ struct subpage_prot_table *spt = pgd_subpage_prot(pgdir);
+ u32 spp = 0;
+ u32 **sbpm, *sbpp;
+
+ if (ea >= spt->maxaddr)
+ return 0;
+ if (ea < 0x100000000) {
+ /* addresses below 4GB use spt->low_prot */
+ sbpm = spt->low_prot;
+ } else {
+ sbpm = spt->protptrs[ea >> SBP_L3_SHIFT];
+ if (!sbpm)
+ return 0;
+ }
+ sbpp = sbpm[(ea >> SBP_L2_SHIFT) & (SBP_L2_COUNT - 1)];
+ if (!sbpp)
+ return 0;
+ spp = sbpp[(ea >> PAGE_SHIFT) & (SBP_L1_COUNT - 1)];
+
+ /* extract 2-bit bitfield for this 4k subpage */
+ spp >>= 30 - 2 * ((ea >> 12) & 0xf);
+
+ /* turn 0,1,2,3 into combination of _PAGE_USER and _PAGE_RW */
+ spp = ((spp & 2) ? _PAGE_USER : 0) | ((spp & 1) ? _PAGE_RW : 0);
+ return spp;
+}
+
+#else /* CONFIG_PPC_SUBPAGE_PROT */
+static inline int subpage_protection(pgd_t *pgdir, unsigned long ea)
+{
+ return 0;
+}
+#endif
+
/* Result code is:
* 0 - handled
* 1 - normal page fault
* -1 - critical hash insertion error
+ * -2 - access not permitted by subpage protection mechanism
*/
int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
{
@@ -809,7 +858,14 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
rc = __hash_page_64K(ea, access, vsid, ptep, trap, local, ssize);
else
#endif /* CONFIG_PPC_HAS_HASH_64K */
- rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize);
+ {
+ int spp = subpage_protection(pgdir, ea);
+ if (access & spp)
+ rc = -2;
+ else
+ rc = __hash_page_4K(ea, access, vsid, ptep, trap,
+ local, ssize, spp);
+ }
#ifndef CONFIG_PPC_64K_PAGES
DBG_LOW(" o-pte: %016lx\n", pte_val(*ptep));
@@ -881,7 +937,8 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
__hash_page_64K(ea, access, vsid, ptep, trap, local, ssize);
else
#endif /* CONFIG_PPC_HAS_HASH_64K */
- __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize);
+ __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize,
+ subpage_protection(pgdir, ea));
local_irq_restore(flags);
}
@@ -926,19 +983,17 @@ void flush_hash_range(unsigned long number, int local)
* low_hash_fault is called when we the low level hash code failed
* to instert a PTE due to an hypervisor error
*/
-void low_hash_fault(struct pt_regs *regs, unsigned long address)
+void low_hash_fault(struct pt_regs *regs, unsigned long address, int rc)
{
if (user_mode(regs)) {
- siginfo_t info;
-
- info.si_signo = SIGBUS;
- info.si_errno = 0;
- info.si_code = BUS_ADRERR;
- info.si_addr = (void __user *)address;
- force_sig_info(SIGBUS, &info, current);
- return;
- }
- bad_page_fault(regs, address, SIGBUS);
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+ if (rc == -2)
+ _exception(SIGSEGV, regs, SEGV_ACCERR, address);
+ else
+#endif
+ _exception(SIGBUS, regs, BUS_ADRERR, address);
+ } else
+ bad_page_fault(regs, address, SIGBUS);
}
#ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
new file mode 100644
index 0000000..4cafc0c
--- /dev/null
+++ b/arch/powerpc/mm/subpage-prot.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright 2007-2008 Paul Mackerras, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/gfp.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/hugetlb.h>
+
+#include <asm/pgtable.h>
+#include <asm/uaccess.h>
+#include <asm/tlbflush.h>
+
+/*
+ * Free all pages allocated for subpage protection maps and pointers.
+ * Also makes sure that the subpage_prot_table structure is
+ * reinitialized for the next user.
+ */
+void subpage_prot_free(pgd_t *pgd)
+{
+ struct subpage_prot_table *spt = pgd_subpage_prot(pgd);
+ unsigned long i, j, addr;
+ u32 **p;
+
+ for (i = 0; i < 4; ++i) {
+ if (spt->low_prot[i]) {
+ free_page((unsigned long)spt->low_prot[i]);
+ spt->low_prot[i] = NULL;
+ }
+ }
+ addr = 0;
+ for (i = 0; i < 2; ++i) {
+ p = spt->protptrs[i];
+ if (!p)
+ continue;
+ spt->protptrs[i] = NULL;
+ for (j = 0; j < SBP_L2_COUNT && addr < spt->maxaddr;
+ ++j, addr += PAGE_SIZE)
+ if (p[j])
+ free_page((unsigned long)p[j]);
+ free_page((unsigned long)p);
+ }
+ spt->maxaddr = 0;
+}
+
+static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
+ int npages)
+{
+ pgd_t *pgd;
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+ spinlock_t *ptl;
+
+ pgd = pgd_offset(mm, addr);
+ if (pgd_none(*pgd))
+ return;
+ pud = pud_offset(pgd, addr);
+ if (pud_none(*pud))
+ return;
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+ return;
+ pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
+ arch_enter_lazy_mmu_mode();
+ for (; npages > 0; --npages) {
+ pte_update(mm, addr, pte, 0, 0);
+ addr += PAGE_SIZE;
+ ++pte;
+ }
+ arch_leave_lazy_mmu_mode();
+ pte_unmap_unlock(pte - 1, ptl);
+}
+
+/*
+ * Clear the subpage protection map for an address range, allowing
+ * all accesses that are allowed by the pte permissions.
+ */
+static void subpage_prot_clear(unsigned long addr, unsigned long len)
+{
+ struct mm_struct *mm = current->mm;
+ struct subpage_prot_table *spt = pgd_subpage_prot(mm->pgd);
+ u32 **spm, *spp;
+ int i, nw;
+ unsigned long next, limit;
+
+ down_write(&mm->mmap_sem);
+ limit = addr + len;
+ if (limit > spt->maxaddr)
+ limit = spt->maxaddr;
+ for (; addr < limit; addr = next) {
+ next = pmd_addr_end(addr, limit);
+ if (addr < 0x100000000) {
+ spm = spt->low_prot;
+ } else {
+ spm = spt->protptrs[addr >> SBP_L3_SHIFT];
+ if (!spm)
+ continue;
+ }
+ spp = spm[(addr >> SBP_L2_SHIFT) & (SBP_L2_COUNT - 1)];
+ if (!spp)
+ continue;
+ spp += (addr >> PAGE_SHIFT) & (SBP_L1_COUNT - 1);
+
+ i = (addr >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
+ nw = PTRS_PER_PTE - i;
+ if (addr + (nw << PAGE_SHIFT) > next)
+ nw = (next - addr) >> PAGE_SHIFT;
+
+ memset(spp, 0, nw * sizeof(u32));
+
+ /* now flush any existing HPTEs for the range */
+ hpte_flush_range(mm, addr, nw);
+ }
+ up_write(&mm->mmap_sem);
+}
+
+/*
+ * Copy in a subpage protection map for an address range.
+ * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
+ * Each 2-bit field is 0 to allow any access, 1 to prevent writes,
+ * 2 or 3 to prevent all accesses.
+ * Note that the normal page protections also apply; the subpage
+ * protection mechanism is an additional constraint, so putting 0
+ * in a 2-bit field won't allow writes to a page that is otherwise
+ * write-protected.
+ */
+long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
+{
+ struct mm_struct *mm = current->mm;
+ struct subpage_prot_table *spt = pgd_subpage_prot(mm->pgd);
+ u32 **spm, *spp;
+ int i, nw;
+ unsigned long next, limit;
+ int err;
+
+ /* Check parameters */
+ if ((addr & ~PAGE_MASK) || (len & ~PAGE_MASK) ||
+ addr >= TASK_SIZE || len >= TASK_SIZE || addr + len > TASK_SIZE)
+ return -EINVAL;
+
+ if (is_hugepage_only_range(mm, addr, len))
+ return -EINVAL;
+
+ if (!map) {
+ /* Clear out the protection map for the address range */
+ subpage_prot_clear(addr, len);
+ return 0;
+ }
+
+ if (!access_ok(VERIFY_READ, map, (len >> PAGE_SHIFT) * sizeof(u32)))
+ return -EFAULT;
+
+ down_write(&mm->mmap_sem);
+ for (limit = addr + len; addr < limit; addr = next) {
+ next = pmd_addr_end(addr, limit);
+ err = -ENOMEM;
+ if (addr < 0x100000000) {
+ spm = spt->low_prot;
+ } else {
+ spm = spt->protptrs[addr >> SBP_L3_SHIFT];
+ if (!spm) {
+ spm = (u32 **)get_zeroed_page(GFP_KERNEL);
+ if (!spm)
+ goto out;
+ spt->protptrs[addr >> SBP_L3_SHIFT] = spm;
+ }
+ }
+ spm += (addr >> SBP_L2_SHIFT) & (SBP_L2_COUNT - 1);
+ spp = *spm;
+ if (!spp) {
+ spp = (u32 *)get_zeroed_page(GFP_KERNEL);
+ if (!spp)
+ goto out;
+ *spm = spp;
+ }
+ spp += (addr >> PAGE_SHIFT) & (SBP_L1_COUNT - 1);
+
+ local_irq_disable();
+ demote_segment_4k(mm, addr);
+ local_irq_enable();
+
+ i = (addr >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
+ nw = PTRS_PER_PTE - i;
+ if (addr + (nw << PAGE_SHIFT) > next)
+ nw = (next - addr) >> PAGE_SHIFT;
+
+ up_write(&mm->mmap_sem);
+ err = -EFAULT;
+ if (__copy_from_user(spp, map, nw * sizeof(u32)))
+ goto out2;
+ map += nw;
+ down_write(&mm->mmap_sem);
+
+ /* now flush any existing HPTEs for the range */
+ hpte_flush_range(mm, addr, nw);
+ }
+ if (limit > spt->maxaddr)
+ spt->maxaddr = limit;
+ err = 0;
+ out:
+ up_write(&mm->mmap_sem);
+ out2:
+ return err;
+}
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 12e5e77..8f40d63 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -265,7 +265,7 @@ static inline unsigned long hpt_hash(unsigned long va, unsigned int shift,
extern int __hash_page_4K(unsigned long ea, unsigned long access,
unsigned long vsid, pte_t *ptep, unsigned long trap,
- unsigned int local, int ssize);
+ unsigned int local, int ssize, int subpage_prot);
extern int __hash_page_64K(unsigned long ea, unsigned long access,
unsigned long vsid, pte_t *ptep, unsigned long trap,
unsigned int local, int ssize);
@@ -278,6 +278,7 @@ extern int hash_huge_page(struct mm_struct *mm, unsigned long access,
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
+extern void demote_segment_4k(struct mm_struct *mm, unsigned long addr);
extern void htab_initialize(void);
extern void htab_initialize_secondary(void);
diff --git a/include/asm-powerpc/pgalloc-64.h b/include/asm-powerpc/pgalloc-64.h
index 94d0294..43214c8 100644
--- a/include/asm-powerpc/pgalloc-64.h
+++ b/include/asm-powerpc/pgalloc-64.h
@@ -12,6 +12,10 @@
#include <linux/cpumask.h>
#include <linux/percpu.h>
+#ifndef CONFIG_PPC_SUBPAGE_PROT
+static inline void subpage_prot_free(pgd_t *pgd) {}
+#endif
+
extern struct kmem_cache *pgtable_cache[];
#define PGD_CACHE_NUM 0
@@ -27,6 +31,7 @@ static inline pgd_t *pgd_alloc(struct mm_struct *mm)
static inline void pgd_free(pgd_t *pgd)
{
+ subpage_prot_free(pgd);
kmem_cache_free(pgtable_cache[PGD_CACHE_NUM], pgd);
}
diff --git a/include/asm-powerpc/pgtable-64k.h b/include/asm-powerpc/pgtable-64k.h
index bd54b77..1cbd6b3 100644
--- a/include/asm-powerpc/pgtable-64k.h
+++ b/include/asm-powerpc/pgtable-64k.h
@@ -13,12 +13,49 @@
#define PTE_TABLE_SIZE (sizeof(real_pte_t) << PTE_INDEX_SIZE)
#define PMD_TABLE_SIZE (sizeof(pmd_t) << PMD_INDEX_SIZE)
#define PGD_TABLE_SIZE (sizeof(pgd_t) << PGD_INDEX_SIZE)
-#endif /* __ASSEMBLY__ */
#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+/*
+ * For the sub-page protection option, we extend the PGD with one of
+ * these. Basically we have a 3-level tree, with the top level being
+ * the protptrs array. To optimize speed and memory consumption when
+ * only addresses < 4GB are being protected, pointers to the first
+ * four pages of sub-page protection words are stored in the low_prot
+ * array.
+ * Each page of sub-page protection words protects 1GB (4 bytes
+ * protects 64k). For the 3-level tree, each page of pointers then
+ * protects 8TB.
+ */
+struct subpage_prot_table {
+ unsigned long maxaddr; /* only addresses < this are protected */
+ unsigned int **protptrs[2];
+ unsigned int *low_prot[4];
+};
+
+#undef PGD_TABLE_SIZE
+#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
+ sizeof(struct subpage_prot_table))
+
+#define SBP_L1_BITS (PAGE_SHIFT - 2)
+#define SBP_L2_BITS (PAGE_SHIFT - 3)
+#define SBP_L1_COUNT (1 << SBP_L1_BITS)
+#define SBP_L2_COUNT (1 << SBP_L2_BITS)
+#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
+#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
+
+extern void subpage_prot_free(pgd_t *pgd);
+
+static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd)
+{
+ return (struct subpage_prot_table *)(pgd + PTRS_PER_PGD);
+}
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
+#endif /* __ASSEMBLY__ */
+
/* With 4k base page size, hugepage PTEs go at the PMD level */
#define MIN_HUGEPTE_SHIFT PAGE_SHIFT
diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
index 11d5383..0c8b0d6 100644
--- a/include/asm-powerpc/systbl.h
+++ b/include/asm-powerpc/systbl.h
@@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd)
SYSCALL_SPU(eventfd)
COMPAT_SYS_SPU(sync_file_range2)
COMPAT_SYS(fallocate)
+SYSCALL(subpage_prot)
diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
index 97d82b6..fedc4b8 100644
--- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -332,10 +332,11 @@
#define __NR_eventfd 307
#define __NR_sync_file_range2 308
#define __NR_fallocate 309
+#define __NR_subpage_prot 310
#ifdef __KERNEL__
-#define __NR_syscalls 310
+#define __NR_syscalls 311
#define __NR__exit __NR_exit
#define NR_syscalls __NR_syscalls
^ permalink raw reply related
* Re: [PATCH] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-01-05 11:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <477EF225.4070505@pikatech.com>
On Saturday 05 January 2008, Sean MacLennan wrote:
> I converted the i2c-ibm_iic driver from an ocp driver to an of_platform=20
> driver. Since this driver is in the kernel.org kernel, should I rename=20
> it and keep the old one around? I notice this was done with the emac=20
> network driver.
The interesting question is whether there are any functional users in
arch/ppc left for the original driver. If all platforms that used
to use i2c-ibm_iic are broken already, you can can go ahead with
the conversion. Otherwise, there are two options:
1. duplicate the driver like you suggested
2. make the same driver both a ocp and of_platform, depending on
the configuration options.
Since most of the driver is untouched by your patch, I'd lean to
the second option, but of course, that is more work for you.
Your patch otherwise looks good, but I have a few comments on
details:
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -241,7 +241,6 @@ config I2C_PIIX4
> =A0
> =A0config I2C_IBM_IIC
> =A0=A0=A0=A0=A0=A0=A0=A0tristate "IBM PPC 4xx on-chip I2C interface"
> -=A0=A0=A0=A0=A0=A0=A0depends on IBM_OCP
> =A0=A0=A0=A0=A0=A0=A0=A0help
> =A0=A0=A0=A0=A0=A0=A0=A0 =A0Say Y here if you want to use IIC peripheral =
found on=20
> =A0=A0=A0=A0=A0=A0=A0=A0 =A0embedded IBM PPC 4xx based systems.=20
In any way, this one now needs to depend on PPC_MERGE now, you
could even make it depend on PPC_4xx, but it's often better to
allow building the driver when you can, even if it doesn't make
sense on your hardware. This gives a better compile coverage.
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ib=
m_iic.c
> index 9b43ff7..838006f 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -3,6 +3,10 @@
> =A0 *
> =A0 * Support for the IIC peripheral on IBM PPC 4xx
> =A0 *
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <smaclennan@pikatech.com>
> + * =A0Converted to an of_platform_driver.
> + *
Changelogs in the file itself are discouraged. In this case, it's just
one line, so it's not really harmful.
I think the convention is for copyrights to be in chronological order,
so you should put the copyright below Eugene's.
> =A0 * Copyright (c) 2003, 2004 Zultys Technologies.
> =A0 * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
> =A0 *
> +=A0=A0=A0=A0=A0=A0=A0dev->idx =3D index++;
> +
> +=A0=A0=A0=A0=A0=A0=A0dev_set_drvdata(&ofdev->dev, dev);
> +
> +=A0=A0=A0=A0=A0=A0=A0if((addrp =3D of_get_address(np, 0, NULL, NULL)) =
=3D=3D NULL ||
> +=A0=A0=A0=A0=A0=A0=A0 =A0 (addr =3D of_translate_address(np, addrp)) =3D=
=3D OF_BAD_ADDR) {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_CRIT "ibm-iic%d=
: Unable to get iic address\n",
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0 dev->idx);
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D -EBUSY;
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail1;
> =A0=A0=A0=A0=A0=A0=A0=A0}
> =A0
> -=A0=A0=A0=A0=A0=A0=A0if (!(dev->vaddr =3D ioremap(ocp->def->paddr, sizeo=
f(struct iic_regs)))){
> +=A0=A0=A0=A0=A0=A0=A0if (!(dev->vaddr =3D ioremap(addr, sizeof(struct ii=
c_regs)))){
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_CRIT "ibm-iic=
%d: failed to ioremap device registers\n",
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0d=
ev->idx);
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D -ENXIO;
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail2;
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail1;
> =A0=A0=A0=A0=A0=A0=A0=A0}
Use of_iomap here to save a few lines.
> =A0=A0=A0=A0=A0=A0=A0=A0init_waitqueue_head(&dev->wq);
> =A0
> -=A0=A0=A0=A0=A0=A0=A0dev->irq =3D iic_force_poll ? -1 : ocp->def->irq;
> -=A0=A0=A0=A0=A0=A0=A0if (dev->irq >=3D 0){
> +=A0=A0=A0=A0=A0=A0=A0if(iic_force_poll)
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev->irq =3D -1;
> +=A0=A0=A0=A0=A0=A0=A0else if((dev->irq =3D irq_of_parse_and_map(np, 0)) =
=3D=3D NO_IRQ) {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_ERR __FILE__ ":=
irq_of_parse_and_map failed\n");
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev->irq =3D -1;
> +=A0=A0=A0=A0=A0=A0=A0}
> +
> +=A0=A0=A0=A0=A0=A0=A0if (dev->irq >=3D 0) {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/* Disable interrupts unt=
il we finish initialization,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 assumes level-sensit=
ive IRQ setup...
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 */
This was in the original driver, but I think it's wrong anyway:
irq =3D=3D 0 could be valid, so you shouldn't compare against that
in general. Use NO_IRQ as a symbolic way to express an invalid
IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
> @@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device *o=
cp){
> =A0=A0=A0=A0=A0=A0=A0=A0
> =A0=A0=A0=A0=A0=A0=A0=A0if (dev->irq < 0)
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_WARNING "ibm-=
iic%d: using polling mode\n",=20
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev=
=2D>idx);
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0 dev->idx);
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> =A0=A0=A0=A0=A0=A0=A0=A0/* Board specific settings */
> -=A0=A0=A0=A0=A0=A0=A0dev->fast_mode =3D iic_force_fast ? 1 : (iic_data ?=
iic_data->fast_mode : 0);
> +=A0=A0=A0=A0=A0=A0=A0dev->fast_mode =3D iic_force_fast ? 1 : 0;
If there is a good reason to specify fast or slow mode per board, you may w=
ant
to make that a property in the device node.
> +
> +static struct of_device_id ibm_iic_match[] =3D
> =A0{
> -=A0=A0=A0=A0=A0=A0=A0{ .vendor =3D OCP_VENDOR_IBM, .function =3D OCP_FUN=
C_IIC },
> -=A0=A0=A0=A0=A0=A0=A0{ .vendor =3D OCP_VENDOR_INVALID }
> +=A0=A0=A0=A0=A0=A0=A0{ .type =3D "i2c", .compatible =3D "ibm,iic", },
> +=A0=A0=A0=A0=A0=A0=A0{}
> =A0};
This is probably not specific enough. I'm rather sure that someone at IBM
has implemented an i2c chip that this driver doesn't support. Maybe
.compatible =3D "ibm,405-iic"
or similar would be a better thing to check for.
Arnd <><
^ permalink raw reply
* Re: [patch 2/3] PS3: Add logical performance monitor device support
From: Arnd Bergmann @ 2008-01-05 11:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <477EF5AC.7090105@am.sony.com>
T24gU2F0dXJkYXkgMDUgSmFudWFyeSAyMDA4LCBHZW9mZiBMZXZhbmQgd3JvdGU6Cj4gKyAgICAg
ICBzdHJ1Y3QgbGF5b3V0IHsKPiArICAgICAgICAgICAgICAgc3RydWN0IHBzM19zeXN0ZW1fYnVz
X2RldmljZSBkZXY7Cj4gKyAgICAgICB9ICpwOwoKV2hhdCdzIHRoZSBwb2ludCBvZiB0aGlzIGRh
dGEgc3RydWN0dXJlPyBZb3UgZG9uJ3QgdXNlIHRoZQpzdHJ1Y3QgYW55d2hlcmUsIGFuZCBpdCBv
bmx5IGhhcyBvbmUgbWVtYmVyLCBzbyB5b3UgY291bGQKanVzdCBkZWNsYXJlIHRoYXQgZGlyZWN0
bHkuCgo+ICugoKCgoKCgaWYgKHRtcDEgIT0gdG1wMikgewo+ICugoKCgoKCgoKCgoKCgoKBwcl9k
ZWJ1ZygiJXM6JWQ6IHdyb25nIGxwYXJcbiIsCj4gK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgX19m
dW5jX18sIF9fTElORV9fKTsKPiAroKCgoKCgoKCgoKCgoKCgcmVzdWx0ID0gLTE7Cj4gK6CgoKCg
oKCgoKCgoKCgoGdvdG8gZmFpbF9yaWdodHM7Cj4gK6CgoKCgoKB9Cj4gKwo+ICugoKCgoKCgaWYg
KCEocC0+ZGV2LmxwbS5yaWdodHMgJiBQUzNfTFBNX1JJR0hUU19VU0VfTFBNKSkgewo+ICugoKCg
oKCgoKCgoKCgoKBwcl9kZWJ1ZygiJXM6JWQ6IGRvbid0IGhhdmUgcmlnaHRzIHRvIHVzZSBscG1c
biIsCj4gK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgX19mdW5jX18sIF9fTElORV9fKTsKPiAroKCg
oKCgoKCgoKCgoKCgcmVzdWx0ID0gLTE7Cj4gK6CgoKCgoKCgoKCgoKCgoGdvdG8gZmFpbF9yaWdo
dHM7Cj4gK6CgoKCgoKB9Cj4gKwoKSSB0aGluayBfX2luaXQgZnVuY3Rpb25zIHNob3VsZCByZXR1
cm4gZXJyb3IgY29kZXMgbGlrZSAtRVBFUk0gb3IKLUVJTlZBTCwgbm90IG51bWVyaWMgLTEuCgpB
cGFydCBmcm9tIHRoYXQsIHRoZSBwYXRjaCBsb29rcyBnb29kLgoKCUFybmQgPD48Cg==
^ permalink raw reply
* Re: Enable RTC for Ebony and Walnut
From: David Gibson @ 2008-01-02 11:42 UTC (permalink / raw)
To: Olof Johansson; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20071221212922.GC11910@lixom.net>
On Fri, Dec 21, 2007 at 03:29:22PM -0600, Olof Johansson wrote:
> Hi,
>
> On Fri, Dec 21, 2007 at 01:21:30PM +1100, David Gibson wrote:
> > Index: working-2.6/arch/powerpc/platforms/Kconfig
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/platforms/Kconfig 2007-12-10 10:52:44.000000000 +1100
> > +++ working-2.6/arch/powerpc/platforms/Kconfig 2007-12-21 13:11:34.000000000 +1100
> > @@ -315,6 +315,9 @@ config FSL_ULI1575
> > config CPM
> > bool
> >
> > +config OF_RTC
> > + bool
> > +
>
> New config options should have descriptions, even if they're silent
> ones.
Uh.. but if there's a description, won't kconfig prompt for the
option? This one should only ever be selected by the platform
options.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 3/3] PS3: Add logical performance monitor driver support
From: Arnd Bergmann @ 2008-01-05 11:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, Takashi Yamamoto
In-Reply-To: <477EF9BD.2020202@am.sony.com>
On Saturday 05 January 2008, Geoff Levand wrote:
> From: Takashi Yamamoto <Takashi02_Yamamoto@hq.scei.sony.co.jp>
>
> Add PS3 logical performance monitor (lpm) device driver.
>
> The PS3's LV1 hypervisor provides a Logical Performance Monitor that
> abstarcts the Cell processor's performance monitor features for use
> by guest operating systems.
>
> Signed-off-by: Takashi Yamamoto <Takashi02_Yamamoto@hq.scei.sony.co.jp>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Wow, great stuff!
One bit of information I'm missing in the description is what the users
of this code are. Your Kconfig text mentions that can be used for both
perfmon and oprofile. Are these, or one of them, currently under
work as well?
> --- a/arch/powerpc/platforms/ps3/Kconfig
> +++ b/arch/powerpc/platforms/ps3/Kconfig
> @@ -138,4 +138,18 @@ config PS3_FLASH
> be disabled on the kernel command line using "ps3flash=off", to
> not allocate this fixed buffer.
>
> +config PS3_LPM
> + tristate "PS3 Logical Performance Monitor support"
> + depends on PPC_PS3
> + default n
'default n' is redundant.
> + help
> + Include support for the PS3 Logical Performance Monitor.
> +
> + This support is required to use the logical performance monitor
> + of the PS3's LV1 hypervisor.
> +
> + If you intend to use the advanced performance monitoring and
> + profiling support of the Cell processor with programs like
> + oprofile and perfmon, then say Y or M, otherwise say N.
> +
Should that be perfmon2 instead of perfmon?
I think once they high-level drivers are merged, it would make sense
to autoselected by these, so the user doesn't have to read through
the help text.
> +/**
> + * struct ps3_lpm_priv - private lpm device data.
> + *
> + * @mutex: Open/close mutex.
> + * @rights: The lpm rigths granted by the system policy module.
> + * @pu_id: The lv1 id of the BE prosessor for this lpm instance.
> + * @lpm_id: The lv1 id of this lpm instance.
> + * @outlet_id: The outlet created by lv1 for this lpm instance.
> + * @constructed: A flag indicating the lpm driver has been opened -- can we just use (lpm_id == ???)
> + * @tb_size: The lv1 trace buffer size
> + * @tb_cache: Trace buffer cache
> + * @tb_cache_internal: A flag indicating the trace buffer cache was allocated
> + * by the driver.
> + * @tb_cache: Trace buffer cache
> + * @sizeof_traced_data: Traced data size
> + * @sbd: the struct ps3_system_bus_device attached to this driver
> + */
> +
> +struct ps3_lpm_priv {
> + struct mutex mutex;
> + u64 rights;
> + u64 pu_id;
> + u64 lpm_id;
> + u64 outlet_id;
> + int constructed;
> + u64 tb_size;
> + void *tb_cache;
> + u64 tb_cache_size;
> + int tb_cache_internal;
> + u64 sizeof_traced_data;
> + u64 sizeof_total_copied_data;
> + u64 shadow_pm_control;
> + u64 shadow_pm_start_stop;
> + u64 shadow_pm_interval;
> + u64 shadow_group_control;
> + u64 shadow_debug_bus_control;
> + struct ps3_system_bus_device *sbd;
> +};
Some of the members in this struct are not present in the comment,
which is somewhat confusing.
> +
> +/**
> + * lpm_priv - Static instance of the lpm data.
> + *
> + * Since the exported routines don't support the notion of a device
> + * instance we need to hold the instance in this static variable
> + * and only allow at most one instance to be created.
> + */
> +
> +static struct ps3_lpm_priv *lpm_priv;
Hmmm, my gut feeling about this is that it would be better to actually
pass this around through the exported functions. That would also
provide some arbitration between the possible users, e.g. oprofile
would get -EBUSY when asking for the ps3_lpm while perfmon2 is
already active.
> +/* bookmark spr address */
> +#define BOOKMARK_SPR_ADDR 1020
This one belongs to asm/reg.h and should be named SRPN_BKMK.
> +inline u32 ps3_get_hw_thread_id(int cpu)
> +{
> + return cpu;
> +}
> +EXPORT_SYMBOL_GPL(ps3_get_hw_thread_id);
The 'inline' is bogus, as that doesn't work across exported functions
and you are not using the function in this file.
Should you perhaps return hard_smp_processor_id(cpu) instead of cpu
here?
> +/**
> + * _ps3_copy_trace_buffer - Copy the trace buffer.
> + */
> +
> +static u64 _ps3_copy_trace_buffer(u64 offset, u64 size, u64 *to, int to_user)
> +{
> + int result;
> + u64 sizeof_copied_data;
> +
> + if (offset >= lpm_priv->sizeof_traced_data)
> + return 0;
> +
> + result = lv1_copy_lpm_trace_buffer(lpm_priv->lpm_id, offset, size,
> + &sizeof_copied_data);
> + if (result) {
> + dev_err(sbd_core(), "%s:%u: lv1_copy_lpm_trace_buffer failed: "
> + "offset 0x%lx, size 0x%lx: %s\n", __func__, __LINE__,
> + offset, size, ps3_result(result));
> + return 0;
> + }
> +
> + if (to_user) {
> + result = copy_to_user((void __user *)to, lpm_priv->tb_cache,
> + sizeof_copied_data);
> + if (result) {
> + dev_err(sbd_core(), "%s:%u: copy_to_user() error. "
> + "offset:0x%lx size:0x%lx dest:0x%p src:0x%p\n",
> + __func__, __LINE__, offset, sizeof_copied_data,
> + to, lpm_priv->tb_cache);
> + return 0;
> + }
> + } else
> + memcpy(to, lpm_priv->tb_cache, sizeof_copied_data);
> +
> + return sizeof_copied_data;
> +}
I don't like how this functions uses the same argument for kernel and user
pointers, this will cause sparse warnings in the code using it. How about
making this two separate functions?
> +int ps3_lpm_open(void *tb_cache, u64 tb_cache_size, u64 tb_type)
> +{
> + int result;
> + u64 cbe_node_id;
> + u64 tb_size;
> + u64 ctrl_opt;
> + u64 tb_cache_lpar_addr;
> + u64 lpm_id;
> + u64 outlet_id;
> + u64 used_tb_size;
> +
> + if (!lpm_priv) {
> + BUG();
> + return -ENODEV;
> + }
> +
> + mutex_lock(&lpm_priv->mutex);
This mutex is documented as the 'open/close' mutex and you use it
to prevent concurrent execution of the open and close functions.
However, it's unclear what data structures are actually protected
by it.
I think this is the result of unusual lifetime rules for the lpm_priv
object, which I already mentioned above.
Arnd <><
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] Provide a way to protect 4k subpages when using 64k pages
From: Arnd Bergmann @ 2008-01-05 12:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <18303.25551.433692.29677@cargo.ozlabs.ibm.com>
On Saturday 05 January 2008, Paul Mackerras wrote:
> This version allocates a new system call number for the subpage_prot
> syscall.
Ah, good. Thanks!
> --- a/arch/powerpc/kernel/syscalls.c
> +++ b/arch/powerpc/kernel/syscalls.c
> @@ -328,3 +328,7 @@ void do_show_syscall_exit(unsigned long r3)
> =A0{
> =A0=A0=A0=A0=A0=A0=A0=A0printk(" -> %lx, current=3D%p cpu=3D%d\n", r3, cu=
rrent, smp_processor_id());
> =A0}
> +
> +#ifndef CONFIG_PPC_SUBPAGE_PROT
> +cond_syscall(subpage_prot);
> +#endif
cond_syscall is defined in a way that you don't need the #ifdef here,
and the other users always have it unconditionally.
> +/*
> + * Copy in a subpage protection map for an address range.
> + * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
> + * Each 2-bit field is 0 to allow any access, 1 to prevent writes,
> + * 2 or 3 to prevent all accesses.
> + * Note that the normal page protections also apply; the subpage
> + * protection mechanism is an additional constraint, so putting 0
> + * in a 2-bit field won't allow writes to a page that is otherwise
> + * write-protected.
> + */
> +long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user =
*map)
syscalls are normally marked asmlinkage, right? I know that it doesn't
have an effect on powerpc, but so far, we have been using the convention
anyway, AFAIK.
Also, I think there should be a declaration in asm/syscalls.h so we don't
get a warning about an undeclared global function from sparse.
> diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
> index 11d5383..0c8b0d6 100644
> --- a/include/asm-powerpc/systbl.h
> +++ b/include/asm-powerpc/systbl.h
> @@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd)
> =A0SYSCALL_SPU(eventfd)
> =A0COMPAT_SYS_SPU(sync_file_range2)
> =A0COMPAT_SYS(fallocate)
> +SYSCALL(subpage_prot)
The convention I've used for SPU syscalls is to allow them unless there is
a specific reason why it's harmful or not possible for the SPU to do it.
I think it should be SYSCALL_SPU because of that.
I already missed the addition of fallocate, which I think should have been
COMPAT_SYS_SPU. I can send you a patch for that one if you like.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/3] Add support for binary includes.
From: David Gibson @ 2008-01-05 12:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080104211043.GA28991@ld0162-tx32.am.freescale.net>
On Fri, Jan 04, 2008 at 03:10:43PM -0600, Scott Wood wrote:
> A property's data can be populated with a file's contents
> as follows:
>
> node {
> prop = /incbin/("path/to/data");
> };
>
> A subset of a file can be included by passing start and size parameters.
> For example, to include bytes 8 through 23:
>
> node {
> prop = /incbin/("path/to/data", 8, 16);
> };
Hrm. Can we leave this one until after 1.1? Since it adds new
syntax, I think it would be worth cogitating a bit longer.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: David Gibson @ 2008-01-05 12:25 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801051041.18173.sr@denx.de>
On Sat, Jan 05, 2008 at 10:41:17AM +0100, Stefan Roese wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
> > +++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.000000000 -0500
> > @@ -0,0 +1,140 @@
> > +/*
> > + * $Id: $
> > + *
> > + * drivers/mtd/maps/taco.c
> > + *
> > + * Mapping for PIKA Taco flash
>
> I'm pretty sure that you don't need a board specific mapping driver
> for NOR flash. physmap_of should be exactly what you need. You just need
> to fill the device tree properties correctly.
Absolutely. We should not be using C-coded maps in arch/powerpc
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Stefan Roese @ 2008-01-05 12:38 UTC (permalink / raw)
To: benh; +Cc: netdev, linuxppc-dev
In-Reply-To: <1199528388.7291.55.camel@pasglop>
On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > Performance tests done by AMCC have shown that 256 buffer increase the
> > performance of the Linux EMAC driver. So let's update the default
> > values to match this setup.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
>
> Do we have the numbers ? Did they also measure latency ?
I hoped this question would not come. ;) No, unfortunately I don't have any
numbers. Just the recommendation from AMCC to always use 256 buffers.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Stefan Roese @ 2008-01-05 12:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, Sean MacLennan
In-Reply-To: <200801051224.52693.arnd@arndb.de>
On Saturday 05 January 2008, Arnd Bergmann wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
> > I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
> > driver. Since this driver is in the kernel.org kernel, should I rename
> > it and keep the old one around? I notice this was done with the emac
> > network driver.
>
> The interesting question is whether there are any functional users in
> arch/ppc left for the original driver. If all platforms that used
> to use i2c-ibm_iic are broken already, you can can go ahead with
> the conversion.
No, they are not all broken. We still have to support arch/ppc till mid of=
=20
this year.
> Otherwise, there are two options:=20
>
> 1. duplicate the driver like you suggested
> 2. make the same driver both a ocp and of_platform, depending on
> the configuration options.
>
> Since most of the driver is untouched by your patch, I'd lean to
> the second option, but of course, that is more work for you.
I did send a patch for such a combined driver a few months ago:
http://patchwork.ozlabs.org/linuxppc/patch?person=3D305&id=3D14181
There were still same open issues and I didn't find the time till now to=20
address them. It would be great if you could take care of these issues and=
=20
submit a reworked version.
> Your patch otherwise looks good, but I have a few comments on
>
> details:
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -241,7 +241,6 @@ config I2C_PIIX4
> > =A0
> > =A0config I2C_IBM_IIC
> > =A0=A0=A0=A0=A0=A0=A0=A0tristate "IBM PPC 4xx on-chip I2C interface"
> > -=A0=A0=A0=A0=A0=A0=A0depends on IBM_OCP
> > =A0=A0=A0=A0=A0=A0=A0=A0help
> > =A0=A0=A0=A0=A0=A0=A0=A0 =A0Say Y here if you want to use IIC periphera=
l found on
> > =A0=A0=A0=A0=A0=A0=A0=A0 =A0embedded IBM PPC 4xx based systems.
>
> In any way, this one now needs to depend on PPC_MERGE now, you
> could even make it depend on PPC_4xx, but it's often better to
> allow building the driver when you can, even if it doesn't make
> sense on your hardware. This gives a better compile coverage.
>
> > diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
> > b/drivers/i2c/busses/i2c-ibm_iic.c index 9b43ff7..838006f 100644
> > --- a/drivers/i2c/busses/i2c-ibm_iic.c
> > +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> > @@ -3,6 +3,10 @@
> > =A0 *
> > =A0 * Support for the IIC peripheral on IBM PPC 4xx
> > =A0 *
> > + * Copyright (c) 2008 PIKA Technologies
> > + * Sean MacLennan <smaclennan@pikatech.com>
> > + * =A0Converted to an of_platform_driver.
> > + *
>
> Changelogs in the file itself are discouraged. In this case, it's just
> one line, so it's not really harmful.
>
> I think the convention is for copyrights to be in chronological order,
> so you should put the copyright below Eugene's.
>
> > =A0 * Copyright (c) 2003, 2004 Zultys Technologies.
> > =A0 * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.ne=
t>
> > =A0 *
> >
> >
> > +=A0=A0=A0=A0=A0=A0=A0dev->idx =3D index++;
> > +
> > +=A0=A0=A0=A0=A0=A0=A0dev_set_drvdata(&ofdev->dev, dev);
> > +
> > +=A0=A0=A0=A0=A0=A0=A0if((addrp =3D of_get_address(np, 0, NULL, NULL)) =
=3D=3D NULL ||
> > +=A0=A0=A0=A0=A0=A0=A0 =A0 (addr =3D of_translate_address(np, addrp)) =
=3D=3D OF_BAD_ADDR) {
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_CRIT "ibm-iic=
%d: Unable to get iic
> > address\n", +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 =A0 dev->idx);
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D -EBUSY;
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail1;
> > =A0=A0=A0=A0=A0=A0=A0=A0}
> > =A0
> > -=A0=A0=A0=A0=A0=A0=A0if (!(dev->vaddr =3D ioremap(ocp->def->paddr, siz=
eof(struct
> > iic_regs)))){ +=A0=A0=A0=A0=A0=A0=A0if (!(dev->vaddr =3D ioremap(addr, =
sizeof(struct
> > iic_regs)))){ printk(KERN_CRIT "ibm-iic%d: failed to ioremap device
> > registers\n", dev->idx);
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D -ENXIO;
> > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail2;
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0goto fail1;
> > =A0=A0=A0=A0=A0=A0=A0=A0}
>
> Use of_iomap here to save a few lines.
>
> > =A0=A0=A0=A0=A0=A0=A0=A0init_waitqueue_head(&dev->wq);
> > =A0
> > -=A0=A0=A0=A0=A0=A0=A0dev->irq =3D iic_force_poll ? -1 : ocp->def->irq;
> > -=A0=A0=A0=A0=A0=A0=A0if (dev->irq >=3D 0){
> > +=A0=A0=A0=A0=A0=A0=A0if(iic_force_poll)
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev->irq =3D -1;
> > +=A0=A0=A0=A0=A0=A0=A0else if((dev->irq =3D irq_of_parse_and_map(np, 0)=
) =3D=3D NO_IRQ) {
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_ERR __FILE__ =
": irq_of_parse_and_map
> > failed\n"); +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev->irq =3D =
=2D1;
> > +=A0=A0=A0=A0=A0=A0=A0}
> > +
> > +=A0=A0=A0=A0=A0=A0=A0if (dev->irq >=3D 0) {
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0/* Disable interrupts u=
ntil we finish initialization,
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 assumes level-sens=
itive IRQ setup...
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 */
>
> This was in the original driver, but I think it's wrong anyway:
> irq =3D=3D 0 could be valid, so you shouldn't compare against that
> in general. Use NO_IRQ as a symbolic way to express an invalid
> IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
>
> > @@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device
> > *ocp){=20
> > =A0=A0=A0=A0=A0=A0=A0=A0if (dev->irq < 0)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(KERN_WARNING "ib=
m-iic%d: using polling mode\n",
> > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0d=
ev->idx);
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0 dev->idx);
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> > =A0=A0=A0=A0=A0=A0=A0=A0/* Board specific settings */
> > -=A0=A0=A0=A0=A0=A0=A0dev->fast_mode =3D iic_force_fast ? 1 : (iic_data=
?
> > iic_data->fast_mode : 0); +=A0=A0=A0=A0=A0=A0=A0dev->fast_mode =3D iic_=
force_fast ? 1 :
> > 0;
>
> If there is a good reason to specify fast or slow mode per board, you may
> want to make that a property in the device node.
>
> > +
> > +static struct of_device_id ibm_iic_match[] =3D
> > =A0{
> > -=A0=A0=A0=A0=A0=A0=A0{ .vendor =3D OCP_VENDOR_IBM, .function =3D OCP_F=
UNC_IIC },
> > -=A0=A0=A0=A0=A0=A0=A0{ .vendor =3D OCP_VENDOR_INVALID }
> > +=A0=A0=A0=A0=A0=A0=A0{ .type =3D "i2c", .compatible =3D "ibm,iic", },
> > +=A0=A0=A0=A0=A0=A0=A0{}
> > =A0};
>
> This is probably not specific enough. I'm rather sure that someone at IBM
> has implemented an i2c chip that this driver doesn't support. Maybe
>
> .compatible =3D "ibm,405-iic"
>
> or similar would be a better thing to check for.
.compatible =3D "ibm,4xx-iic"
please, since 405 and 440 have the same I2C controller.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-01-05 12:54 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801051349.34488.sr@denx.de>
On Saturday 05 January 2008, Stefan Roese wrote:
> >
> > This is probably not specific enough. I'm rather sure that someone at I=
BM
> > has implemented an i2c chip that this driver doesn't support. Maybe
> >
> > =A0=A0=A0=A0=A0=A0.compatible =3D "ibm,405-iic"
> >
> > or similar would be a better thing to check for.
>=20
> =A0=A0=A0=A0=A0=A0=A0=A0.compatible =3D "ibm,4xx-iic"
>=20
> please, since 405 and 440 have the same I2C controller.
>=20
But that's not how compatible properties work -- they should not
contain wildcards. If you have different devices that are
backwards compatible, you should list the older one in all
newer devices, e.g. the 440 can list that it is compatible
with both ibm,405-iic and ibm,440-iic. If there was an earlier
401 that had iic as well, you may even want to include that
in the device tree.
Arnd <><
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Stefan Roese @ 2008-01-05 12:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801051354.11202.arnd@arndb.de>
On Saturday 05 January 2008, Arnd Bergmann wrote:
> > > This is probably not specific enough. I'm rather sure that someone at
> > > IBM has implemented an i2c chip that this driver doesn't support. May=
be
> > >
> > > =A0=A0=A0=A0=A0=A0.compatible =3D "ibm,405-iic"
> > >
> > > or similar would be a better thing to check for.
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0.compatible =3D "ibm,4xx-iic"
> >
> > please, since 405 and 440 have the same I2C controller.
>
> But that's not how compatible properties work -- they should not
> contain wildcards. If you have different devices that are
> backwards compatible, you should list the older one in all
> newer devices, e.g. the 440 can list that it is compatible
> with both ibm,405-iic and ibm,440-iic. If there was an earlier
> 401 that had iic as well, you may even want to include that
> in the device tree.
OK. Thanks for clarifying.
Best regards,
Stefan
^ permalink raw reply
* Re: Control not branching to the instruction present at resetvec i.e 0xfffffffc
From: Misbah khan @ 2008-01-05 14:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OFD408300E.ACB35FD3-ON852573C6.0072065E-852573C6.007337FA@RFLELECT.COM>
Hi Mr Ravi ...
I suggest you to post a new concern in a new thread ....
----Misbah
ravi.rao wrote:
>
> Hi All,
> We have a custom target board based on PPC-EP405. We just got the
> board from the hardware team .I connected the board to BDI200 and powered
> it on.
> The control came to the resetvec address which is 0xfffffffc. I was able
> to read and write to flash. So I erased the flash and burnt the bootloader
> into flash from 0xfffc0000.
> I verified that the instruction at 0xfffffffc is 4bfc2104 whicis actually
> a branch to 0xfffc2100. Also a memory dump of 0xfffc2100 shows the correct
> code. This proved that
> the uboot bootloader was burnt properly.
> Now when I reset the board the control never reaches 0xfffc2100 i.e for
> some reason the code at the resetvec is not getting executed. Any help or
> pointers to resolve this is greatly appreciated.
> Thanks,
> Ravishankar Govindarao
> RFL Electronics Inc.
> E-mail : Ravi.Rao@rflelect.com
> Voice: 973.334.3100 Ext. 233
> Fax: 973.334.3863
>
> CONFIDENTIALITY NOTE
> This e-mail, including any attachments, may contain confidential and/or
> legally privileged information. The Information is intended only for the
> use of the individual or entity named on this e-mail . If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or the taking of any action in reliance on the contents of
> this transmitted Information is strictly prohibited. Further, if you are
> not the intended recipient, please notify us by return e-mail and delete
> the Information promptly.
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/Reading-a-config-file-in-a-driver-....-tp14591717p14633599.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Base Taco Platform support
From: Sean MacLennan @ 2008-01-05 18:10 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1199517639.7291.45.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-04 at 23:49 -0500, Sean MacLennan wrote:
>
>> Here is a patch for the base taco platform. It is against for-2.6.25. It
>> adds basically everything in the arch/powerpc.
>>
>
> Care to tell us a bit more about what Taco is ? Even better is to also
> do that in your Kconfig entry, maybe along with a URL to your web site.
>
> Cheers,
> Ben.
>
>
>
Can do, if I can figure out what it is ;) Basically it is a telephony
appliance geared mainly to low-density asterisk users.
I will update the Kconfig.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-05 18:20 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051041.18173.sr@denx.de>
Stefan Roese wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
>
>> This patch adds the maps for the taco. It also gets the ndfc.c NAND
>> driver in a compilable state. The map is guaranteed to change since the
>> exact NOR/NAND flash configuration is in flux right now when we found
>> the 256M NAND flash won't boot properly.
>>
>> Currently it configures the NOR in a reasonable fashion and leaves the
>> NAND as one honkin' parition.
>>
>
> <snip>
>
>
>> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
>> index 1c0e89f..f5e93cf 100644
>> --- a/drivers/mtd/nand/ndfc.c
>> +++ b/drivers/mtd/nand/ndfc.c
>> @@ -24,11 +24,6 @@
>> #include <linux/platform_device.h>
>>
>> #include <asm/io.h>
>> -#ifdef CONFIG_40x
>> -#include <asm/ibm405.h>
>> -#else
>> -#include <asm/ibm44x.h>
>> -#endif
>>
>
> You do break arch/ppc support with this patch. We have to still support
> arch/ppc a few month, so please don't break this support for now.
>
Gotcha. Is CONFIG_PPC_MERGED the right flag for things like this?
>
>
>> struct ndfc_nand_mtd {
>> struct mtd_info mtd;
>> @@ -110,6 +105,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_TACO
>> +/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
>> + * the taco!
>> + */
>>
>
> We definitely don't want to see such board specific stuff in the common
> NDFC driver. And I really doubt that you need this change for your board.
> We are using this ndfc driver on multiple boards, and all have no
> problems accessing the controller with 32bit read/writes. So you most
> likely have a problem with your board port. Perhaps something with
> with the EBC setup. Please re-check and compare with boards that are know
> to work, like Sequoia.
>
>
Does the Sequoia use a Rev C chip? We had to modify u-boot the same way.
As soon as we do an 8-bit access we get a machine check exception.
To be honest, I don't know what more to check.
>> +static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
>> +{
>> + struct ndfc_controller *ndfc = &ndfc_ctrl;
>> + uint8_t *p = (uint8_t *) buf;
>> +
>> + for(;len > 0; len -= 1)
>> + *p++ = __raw_readb(ndfc->ndfcbase + NDFC_DATA);
>> +}
>> +
>> +static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
>> len) +{
>> + struct ndfc_controller *ndfc = &ndfc_ctrl;
>> + uint8_t *p = (uint8_t *) buf;
>> +
>> + for(;len > 0; len -= 1)
>> + __raw_writeb(*p++, ndfc->ndfcbase + NDFC_DATA);
>> +}
>> +
>> +static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
>> len) +{
>> + struct ndfc_controller *ndfc = &ndfc_ctrl;
>> + uint8_t *p = (uint8_t *) buf;
>> +
>> + for(;len > 0; len -= 1)
>> + if (*p++ != __raw_readb(ndfc->ndfcbase + NDFC_DATA))
>> + return -EFAULT;
>> +
>> + return 0;
>> +}
>> +#else
>>
>
> <snip>
>
>
>> +++ drivers/mtd/maps/taco.c 2008-01-02 13:07:43.000000000 -0500
>> @@ -0,0 +1,140 @@
>> +/*
>> + * $Id: $
>> + *
>> + * drivers/mtd/maps/taco.c
>> + *
>> + * Mapping for PIKA Taco flash
>>
>
> I'm pretty sure that you don't need a board specific mapping driver
> for NOR flash. physmap_of should be exactly what you need. You just need
> to fill the device tree properties correctly.
>
Yes, this was copied straight from the PPC port. The whole NOR/NAND
flash is in flux. Marketing really really wants to drop NOR for price
reasons. So I will probably leave this until a final decision is made.
> BTW: I noticed you are using the boot wrapper approach. This is not
> necessary anymore, since the latest U-Boot version has flattened
> device tree support included for 4xx too. Let me know if you have any
> questions about this.
>
I did this port over Christmas and had no access to the hardware guys so
I stayed away from u-boot since I had no way to recover from mistakes. I
hope to make towards the tree image approach but for now the in-kernel
version is much easier for me to work with.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Sean MacLennan @ 2008-01-05 18:22 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051026.26870.sr@denx.de>
Stefan Roese wrote:
> On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
>
>>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>>> index 7580aa5..480580c 100644
>>> --- a/drivers/usb/Kconfig
>>> +++ b/drivers/usb/Kconfig
>>> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
>>> # PPC:
>>> default y if STB03xxx
>>> default y if PPC_MPC52xx
>>> + default y if TACO
>>> # MIPS:
>>> default y if SOC_AU1X00
>>> # more:
>>>
>> I think we should instead reference use the 440EP here,
>>
>
> I vote for adding 440EP here.
>
> Best regards,
> Stefan
>
Ok. I thought of that, but most 440EP boards have PCI set and don't need
the special option. I was worried if I put 440EP someone down the road
might remove it as "extraneous". We are probably the only 440EP board
with no PCI ;)
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 18:30 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200801051224.52693.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
>
>> I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
>> driver. Since this driver is in the kernel.org kernel, should I rename
>> it and keep the old one around? I notice this was done with the emac
>> network driver.
>>
>
> The interesting question is whether there are any functional users in
> arch/ppc left for the original driver. If all platforms that used
> to use i2c-ibm_iic are broken already, you can can go ahead with
> the conversion. Otherwise, there are two options:
>
> 1. duplicate the driver like you suggested
> 2. make the same driver both a ocp and of_platform, depending on
> the configuration options.
>
> Since most of the driver is untouched by your patch, I'd lean to
> the second option, but of course, that is more work for you.
>
Given Stefan subsequent post, I'll go with the second option.
> Your patch otherwise looks good, but I have a few comments on
> details:
>
>
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -241,7 +241,6 @@ config I2C_PIIX4
>>
>> config I2C_IBM_IIC
>> tristate "IBM PPC 4xx on-chip I2C interface"
>> - depends on IBM_OCP
>> help
>> Say Y here if you want to use IIC peripheral found on
>> embedded IBM PPC 4xx based systems.
>>
>
> In any way, this one now needs to depend on PPC_MERGE now, you
> could even make it depend on PPC_4xx, but it's often better to
> allow building the driver when you can, even if it doesn't make
> sense on your hardware. This gives a better compile coverage.
>
>
>> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
>> index 9b43ff7..838006f 100644
>> --- a/drivers/i2c/busses/i2c-ibm_iic.c
>> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
>> @@ -3,6 +3,10 @@
>> *
>> * Support for the IIC peripheral on IBM PPC 4xx
>> *
>> + * Copyright (c) 2008 PIKA Technologies
>> + * Sean MacLennan <smaclennan@pikatech.com>
>> + * Converted to an of_platform_driver.
>> + *
>>
>
> Changelogs in the file itself are discouraged. In this case, it's just
> one line, so it's not really harmful.
>
> I think the convention is for copyrights to be in chronological order,
> so you should put the copyright below Eugene's.
>
Ok, I will change it. To be honest, I didn't think it was enough of a
change to actually be worth a copyright, but PIKA is a little touchy
about copyrights right now and I wanted to point out I *only* did the
port. I will remove the changelog and move the copyright notice.
>
>> * Copyright (c) 2003, 2004 Zultys Technologies.
>> * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
>> *
>>
>
>
>
>> + dev->idx = index++;
>> +
>> + dev_set_drvdata(&ofdev->dev, dev);
>> +
>> + if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
>> + (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
>> + printk(KERN_CRIT "ibm-iic%d: Unable to get iic address\n",
>> + dev->idx);
>> ret = -EBUSY;
>> goto fail1;
>> }
>>
>> - if (!(dev->vaddr = ioremap(ocp->def->paddr, sizeof(struct iic_regs)))){
>> + if (!(dev->vaddr = ioremap(addr, sizeof(struct iic_regs)))){
>> printk(KERN_CRIT "ibm-iic%d: failed to ioremap device registers\n",
>> dev->idx);
>> ret = -ENXIO;
>> - goto fail2;
>> + goto fail1;
>> }
>>
>
> Use of_iomap here to save a few lines.
>
>
Cool, I didn't notice that function.
>> init_waitqueue_head(&dev->wq);
>>
>> - dev->irq = iic_force_poll ? -1 : ocp->def->irq;
>> - if (dev->irq >= 0){
>> + if(iic_force_poll)
>> + dev->irq = -1;
>> + else if((dev->irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
>> + printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
>> + dev->irq = -1;
>> + }
>> +
>> + if (dev->irq >= 0) {
>> /* Disable interrupts until we finish initialization,
>> assumes level-sensitive IRQ setup...
>> */
>>
>
> This was in the original driver, but I think it's wrong anyway:
> irq == 0 could be valid, so you shouldn't compare against that
> in general. Use NO_IRQ as a symbolic way to express an invalid
> IRQ (yes, I'm aware that NO_IRQ is currently defined to 0).
>
Ok.
>
>> @@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device *ocp){
>>
>> if (dev->irq < 0)
>> printk(KERN_WARNING "ibm-iic%d: using polling mode\n",
>> - dev->idx);
>> + dev->idx);
>>
>> /* Board specific settings */
>> - dev->fast_mode = iic_force_fast ? 1 : (iic_data ? iic_data->fast_mode : 0);
>> + dev->fast_mode = iic_force_fast ? 1 : 0;
>>
>
> If there is a good reason to specify fast or slow mode per board, you may want
> to make that a property in the device node.
>
>
Ok. I really don't know, none of the board ports I looked at used fast mode.
>> +
>> +static struct of_device_id ibm_iic_match[] =
>> {
>> - { .vendor = OCP_VENDOR_IBM, .function = OCP_FUNC_IIC },
>> - { .vendor = OCP_VENDOR_INVALID }
>> + { .type = "i2c", .compatible = "ibm,iic", },
>> + {}
>> };
>>
>
> This is probably not specific enough. I'm rather sure that someone at IBM
> has implemented an i2c chip that this driver doesn't support. Maybe
>
> .compatible = "ibm,405-iic"
>
> or similar would be a better thing to check for.
>
> Arnd <><
>
Ok, I will look into this.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 18:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <200801051349.34488.sr@denx.de>
Stefan Roese wrote:
>
>> Otherwise, there are two options:
>>
>> 1. duplicate the driver like you suggested
>> 2. make the same driver both a ocp and of_platform, depending on
>> the configuration options.
>>
>> Since most of the driver is untouched by your patch, I'd lean to
>> the second option, but of course, that is more work for you.
>>
>
> I did send a patch for such a combined driver a few months ago:
>
> http://patchwork.ozlabs.org/linuxppc/patch?person=305&id=14181
>
> There were still same open issues and I didn't find the time till now to
> address them. It would be great if you could take care of these issues and
> submit a reworked version.
>
>
I can look into this. Thanks!
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 18:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <200801051354.11202.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 05 January 2008, Stefan Roese wrote:
>
>>> This is probably not specific enough. I'm rather sure that someone at IBM
>>> has implemented an i2c chip that this driver doesn't support. Maybe
>>>
>>> .compatible = "ibm,405-iic"
>>>
>>> or similar would be a better thing to check for.
>>>
>> .compatible = "ibm,4xx-iic"
>>
>> please, since 405 and 440 have the same I2C controller.
>>
>>
>
> But that's not how compatible properties work -- they should not
> contain wildcards. If you have different devices that are
> backwards compatible, you should list the older one in all
> newer devices, e.g. the 440 can list that it is compatible
> with both ibm,405-iic and ibm,440-iic. If there was an earlier
> 401 that had iic as well, you may even want to include that
> in the device tree.
>
> Arnd <><
>
Ok. The 44x based .dts files do not list 405-iic, so would I think I
will add two compatibility matches, one for 405 and one for 440EP. That
way I do not break all the current .dts files. Everybody ok with that?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Hwmon for Taco
From: Sean MacLennan @ 2008-01-05 18:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1199517763.7291.47.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> +module_exit(ad7414_exit);
>> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
>> +++ drivers/hwmon/taco-dtm.c 2008-01-05 00:06:21.000000000 -0500
>> @@ -0,0 +1,78 @@
>> +/*
>> + * drivers/hwmon/taco-dtm.c
>> + *
>> + * Overview: On the Taco, the fpga controls the fan. This provides
>> + * the temperature to the fpga.
>> + *
>> + * Copyright (c) 2008 PIKA Technologies
>> + * Sean MacLennan <smaclennan@pikatech.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + *
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/kthread.h>
>> +#include <linux/io.h>
>> +
>> +
>> +#define TACO_FPGA_BASE 0x80000000
>>
>
> That should be in the device-tree...
>
> Cheers,
> Ben.
>
>
>
It is in the device tree, I just forgot to update the driver to use it.
Thanks.
Cheers,
Sean
^ permalink raw reply
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