Re: [PATCH] ppc440spe-adma: adds updated ppc440spe adma driver

[Anatolij Gustschin]

On Fri, 20 Nov 2009 08:00:26 -0500
Josh Boyer  wrote:

> On Tue, Nov 17, 2009 at 03:17:05PM +0100, Anatolij Gustschin wrote:
> >This patch adds new version of the PPC440SPe ADMA driver.
> >
> >Signed-off-by: Anatolij Gustschin 
> 
> The driver author is listed as Yuri Tikhonov .  Shouldn't
> this include a sign-off from Yuri, or perhaps even a From?

Yuri is the author of the previous driver version but he didn't
have time to rework the driver and prepare it for submission.
I will CC him and ask for his sign-off when submitting next
patch version.

> >Before applying this patch the following patch to katmai.dts
> >should be applied first: http://patchwork.ozlabs.org/patch/36768/
> 
> For the linux-raid people's benefit, I have that patch queued up in my next
> branch.

Thanks!

> > arch/powerpc/include/asm/async_tx.h|   47 +
> > arch/powerpc/include/asm/ppc440spe_adma.h  |  195 +
> > arch/powerpc/include/asm/ppc440spe_dma.h   |  224 +
> > arch/powerpc/include/asm/ppc440spe_xor.h   |  110 +
> 
> Why are these header files in the asm directory?  They seem to be only used
> by your new driver, so why not have them under the drivers/dma or if you want
> to be neat, drivers/dma/ppc440spe/ dirs?  I really don't think they should
> be in asm at all.

async_tx layer expects async_tx.h to be in the asm directory if
the architecture provides async_tx_find_channel(). I will move
other header files and the driver file to drivers/dma/ppc440spe/
directory.

> >diff --git a/arch/powerpc/include/asm/dcr-regs.h 
> >b/arch/powerpc/include/asm/dcr-regs.h
> >index 828e3aa..67d4069 100644
> >--- a/arch/powerpc/include/asm/dcr-regs.h
> >+++ b/arch/powerpc/include/asm/dcr-regs.h
> >@@ -157,4 +157,30 @@
> > #define  L2C_SNP_SSR_32G0xf000
> > #define  L2C_SNP_ESR0x0800
> >
> >+#define DCRN_SDR_CONFIG_ADDR0xe
> >+#define DCRN_SDR_CONFIG_DATA0xf
> 
> These #defines already exist as DCRN_SDR0_CONFIG_{ADDR,DATA}.  We don't need
> them defined again.

OK, I'll remove them.


> >+ * Common initialisation for RAID engines; allocate memory for
> >+ * DMAx FIFOs, perform configuration common for all DMA engines.
> >+ * Further DMA engine specific configuration is done at probe time.
> >+ */
> >+static int ppc440spe_configure_raid_devices(void)
> >+{
> >+struct device_node *np;
> >+struct resource i2o_res;
> >+i2o_regs_t __iomem *i2o_reg;
> >+const u32 *dcrreg;
> >+u32 dcrbase_i2o;
> >+int i, len, ret;
> >+
> >+np = of_find_compatible_node(NULL, NULL, "ibm,i2o-440spe");
> >+if (!np) {
> >+pr_err("%s: can't find I2O device tree node\n",
> >+__func__);
> >+return -ENODEV;
> >+}
> >+
> >+if (of_address_to_resource(np, 0, &i2o_res)) {
> >+of_node_put(np);
> >+return -EINVAL;
> >+}
> >+
> >+i2o_reg = of_iomap(np, 0);
> >+if (!i2o_reg) {
> >+pr_err("%s: failed to map I2O registers\n", __func__);
> >+of_node_put(np);
> >+return -EINVAL;
> >+}
> >+
> >+/* Get I2O DCRs base */
> >+dcrreg = of_get_property(np, "dcr-reg", &len);
> >+if (!dcrreg || (len != 2 * sizeof(u32))) {
> >+pr_err("%s: can't get DCR register base!\n",
> >+np->full_name);
> >+of_node_put(np);
> >+iounmap(i2o_reg);
> >+return -ENODEV;
> >+}
> >+of_node_put(np);
> >+dcrbase_i2o = dcrreg[0];
> >+
> >+/* Provide memory regions for DMA's FIFOs: I2O, DMA0 and DMA1 share
> >+ * the base address of FIFO memory space.
> >+ * Actually we need twice more physical memory than programmed in the
> >+ *  register (because there are two FIFOs for each DMA: CP and CS)
> >+ */
> >+ppc440spe_dma_fifo_buf = kmalloc((DMA0_FIFO_SIZE + DMA1_FIFO_SIZE) << 1,
> >+ GFP_KERNEL);
> >+if (!ppc440spe_dma_fifo_buf) {
> >+pr_err("%s: DMA FIFO buffer allocation failed.\n", __func__);
> >+iounmap(i2o_reg);
> >+return -ENOMEM;
> >+}
> >+v
> >+/*
> >+ * Configure h/w
> >+ */
> >+/* Reset I2O/DMA */
> >+mtdcri(SDR, DCRN_SDR0_SRST, DCRN_SDR0_SRST_I2ODMA);
> >+mtdcri(SDR, DCRN_SDR0_SRST, 0);
> >+
> >+/* Setup the base address of mmaped registers */
> >+mtdcr(dcrbase_i2o + DCRN_I2O0_IBAH, (u32)(i2o_res.start >> 32));
> >+mtdcr(dcrbase_i2o + DCRN_I2O0_IBAL, (u32)(i2o_res.start) |
> >+I2O_REG_ENABLE);
> 
> It would be cleaner if you used the dcr_read/dcr_write functions instead
> of the open coded mtdcr/mfdcr.  I don't think it's required though.
> 
> >+
> >+/* Setup FIFO memory space base address */
> >+out_le32(&i2o_reg->ifbah, 0);
> >+out_le32(&i2o_reg->ifbal, ((u32)__pa(ppc440spe_dma_fifo_buf)));
> 
> Similarly ioread32/iowrite32 instead of {out,in}_.

OK, I'll fix this.

Thanks!

Anatolij
__

[RESEND] [PATCH] Fix wrong error code from ppc32 select syscall

[Josh Boyer]

From: Arnd Bergmann , Paul Mackerras 

This patch was submitted, discussed, and eventually Acked by everyone, yet
still isn't in the tree.  See:

http://patchwork.ozlabs.org/patch/1240/

Signed-off-by: Josh Boyer 
Cc: Arnd Bergmann 
Cc: Paul Mackerras 

---

diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl
index c7d671a..07d2d19 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -145,7 +145,7 @@ SYSCALL_SPU(setfsuid)
 SYSCALL_SPU(setfsgid)
 SYSCALL_SPU(llseek)
 COMPAT_SYS_SPU(getdents)
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
 SYSCALL_SPU(flock)
 SYSCALL_SPU(msync)
 COMPAT_SYS_SPU(readv)

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [microblaze-uclinux] Re: [PATCH 0/4 v2] Merge OF dynamic patches

[Michal Simek]

Grant Likely wrote:

On Fri, Nov 20, 2009 at 8:01 AM, Nathan Fontenot  wrote:

This set of patches merges the common dynamic device tree
updating routines of_attach_node() and of_detach_node() to
drivers/of/of_dynamic.c.

Built and tested on powerpc, I have no access to build/test
this on microblaze.


Heh.  Actually, I've got a patch in my tree that does the same thing
(except to a different location).  I could pick up your version and
drop mine, but you need to rework it to be bi-sectable.  As the series
exists right now, the build will fail if only part of the series is
applied.  This change is simple enough that you can do the whole thing
in a single patch.  Or, fix the Kconfig and include stuff in the first
patch with the merge of of_attach_node, and then move of_detach_node
in the second.

But I'm really close to posting my 3rd series, so it may be better to
wait until that is published and build a patch on top of that to move
them into of_dynamic.c


ACK.
Michal



Cheers,
g.


---

1/4 - Merge of_attach_node
2/4 - Merge of_detach_node
3/4 - Makefile/Kconfig updates
4/4 - Update powerpc/pseries to include of_dynamic.h

arch/microblaze/Kconfig   |1
arch/microblaze/include/asm/prom.h|4 -
arch/microblaze/kernel/prom.c |   59 ---
arch/powerpc/Kconfig  |1
arch/powerpc/include/asm/prom.h   |4 -
arch/powerpc/kernel/prom.c|   59 ---
arch/powerpc/platforms/pseries/reconfig.c |1 drivers/of/Kconfig
   |4 +
drivers/of/Makefile   |1 drivers/of/of_dynamic.c
  |   75 ++
include/linux/of_dynamic.h|   27 ++
11 files changed, 110 insertions(+), 126 deletions(-)








--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/3] eLBC NAND: increase bus timeout to maximum

[Artem Bityutskiy]

On Fri, 2009-11-13 at 14:12 -0600, Scott Wood wrote:
> When a NAND operation is in progress, all other localbus operations
> (including NOR flash) will have to wait for access to the bus.  However, the
> NAND operation may take longer to complete than the default timeout.  Thus,
> if NOR is accessed while a NAND operation is in progress, the NAND operation
> will fail.
> 
> Signed-off-by: Scott Wood 

Taken the patches to my l2-mtd-2.6 tree.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/4 v2] Merge OF dynamic patches

[Nathan Fontenot]

Grant Likely wrote:


But I'm really close to posting my 3rd series, so it may be better to
wait until that is published and build a patch on top of that to move
them into of_dynamic.c



Works for me.

-Nathan Fontenot
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: DMA to User-Space

[Sergey Temerkhanov]

On Wednesday 04 November 2009 02:37:38 Jonathan Haws wrote:
> All,
> 
> I have what may be an unconventional question:
> 
> Our application consists of data being captured by an FPGA, processed, and
>  transferred to SDRAM.  I simply give the FPGA an address of where I want
>  it stored in SDRAM and it simply DMAs the data over and interrupts me when
>  finished.  I then take that data and store it to disk.
> 
> I have code in user space that handles all of the writing to disk nicely
>  and fast enough for my application (I am capturing data at about 35-40
>  Mbytes/sec).
> 
> My question is this:  is it possible to give a user-space pointer to the
>  FPGA to DMA to?  It seems like I would have problems with alignment,
>  address manipulation, and a whole slew of other issues.

Well, it's possible: you'll have to use zero-copy I/O. Here's an article on 
this subject: http://lwn.net/Articles/28548/.
Have a look at drivers/scsi/st.c at sgl_get_user_pages() or 
drivers/infiniband/hw/ipath/ipath_user_pages.c for example of how to use that.

Regards, Sergey Temerkhanov.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Fwd: Re: DTS for PowerPC 440 based board

[Grant Likely]

On Mon, Nov 23, 2009 at 12:29 AM,   wrote:
> Hi,
>
> David, Grant thank you for providing the info.
> From your reply and the other sources what I gather is as below. Please
> confirm whether I am on the right track.
>
> 1) Bootloader passing BDInfo:
> Here, I have to create a .dts file inside /arch/powerpc/boot/dts directory.
> dtc compiles the .dts file and creates a dtb. The kernel, dtb and
> boot-wrapper are then embedded in a cuImage.* file after make. We need to
> write the platform-specific fix-ups in the cuboot-*.c file. The bootloader
> will pass BDInfo struct to kernel.

The bootloader will pass bdinfo to the bootwrapper (the cuImage)

> The kernel will also receive the dtb.

The bootwrapper will pass the dtb to the kernel proper.  bootloader
knows nothing about the dtb, and the kernel knows nothing about
bdinfo.

> The only kernel changes we need to do here are fixups in cuboot-*.c and
> creation of .dts file.

Correct.  But if you're doing a new board and have control over your
bootloader, then don't choose this option.  bdinfo structures

> 2) Bootloader passing DT:
> Here, the booloader will directly pass the DT instead of BDInfo. The
> platform-specific code in simpleboot.c will get excuted. We don't have to do
> any fixups inside kernel here.

simpleboot.c doesn't get run at all.  In fact, the bootwrapper doesn't
get used at all in this case.  The uImage is just the raw compressed
kernel image (vmlinux) with a uImage header on it.

> I have queries with this approach -
> a) In this case, who creates DT? Do we need to use any tools to create a DT?

The .dts file still lives in the kernel tree, and the kernel build
process still compiles it into a .dtb

> or it can be created the same way by compiling the .dts file using dtc?

yes

> b) From previous implementaions of other boards, I didn't see any platform
> specific fix-ups inside kernel being done? Why is so that in case of BDInfo
> we need fix-ups and here we don't?

because bdinfo is a horribly method of passing data to the kernel.  So
the bdinfo data needs to be translated into a form the kernel can use
(the device tree).  Fixups aren't needed with this approach because
the device tree passed by the bootloader already has all the correct
data in it.  U-Boot has the ability to modify the .dtb blob at boot
time to update things like the kernel parameters line and the memory
size if it needs to.

> Please confirm my understanding of above to approaches. Also please suggest
> which way is better.

Pass the device tree from the bootloader.  the bootwrapper method is
only to support firmware that cannot pass a device tree image, and
passing bdinfo is non-portable and can cause problems.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ppc440spe-adma: adds updated ppc440spe adma driver

[Dan Williams]

Anatolij Gustschin wrote:

This patch adds new version of the PPC440SPe ADMA driver.

Signed-off-by: Anatolij Gustschin 


As Josh said please don't drop attribution tags.  If you borrowed from 
Yuri's implementation you can forward his signed-off-by.



---
Before applying this patch the following patch to katmai.dts
should be applied first: http://patchwork.ozlabs.org/patch/36768/

The driver was updated to work with extended async_tx API.
Comments to previous PPC440SPe ADMA driver versions submitted to
the linuxppc-dev list were addressed. Please review and consider
for inclusion. Thanks.

 .../powerpc/dts-bindings/4xx/ppc440spe-adma.txt|   93 +
 arch/powerpc/boot/dts/katmai.dts   |   52 +-
 arch/powerpc/include/asm/async_tx.h|   47 +
 arch/powerpc/include/asm/dcr-regs.h|   26 +
 arch/powerpc/include/asm/ppc440spe_adma.h  |  195 +
 arch/powerpc/include/asm/ppc440spe_dma.h   |  224 +
 arch/powerpc/include/asm/ppc440spe_xor.h   |  110 +
 drivers/dma/Kconfig|   13 +
 drivers/dma/Makefile   |1 +
 drivers/dma/ppc440spe-adma.c   | 4944 
 10 files changed, 5704 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt
 create mode 100644 arch/powerpc/include/asm/async_tx.h
 create mode 100644 arch/powerpc/include/asm/ppc440spe_adma.h
 create mode 100644 arch/powerpc/include/asm/ppc440spe_dma.h
 create mode 100644 arch/powerpc/include/asm/ppc440spe_xor.h
 create mode 100644 drivers/dma/ppc440spe-adma.c

[..]

diff --git a/arch/powerpc/include/asm/ppc440spe_dma.h 
b/arch/powerpc/include/asm/ppc440spe_dma.h
new file mode 100644
index 000..7cce63e
--- /dev/null
+++ b/arch/powerpc/include/asm/ppc440spe_dma.h

[..]

+/*
+ * DMAx hardware registers (p.515 in 440SPe UM 1.22)
+ */
+typedef struct {
+   u32 cpfpl;
+   u32 cpfph;
+   u32 csfpl;
+   u32 csfph;
+   u32 dsts;
+   u32 cfg;
+   u8  pad0[0x8];
+   u16 cpfhp;
+   u16 cpftp;
+   u16 csfhp;
+   u16 csftp;
+   u8  pad1[0x8];
+   u32 acpl;
+   u32 acph;
+   u32 s1bpl;
+   u32 s1bph;
+   u32 s2bpl;
+   u32 s2bph;
+   u32 s3bpl;
+   u32 s3bph;
+   u8  pad2[0x10];
+   u32 earl;
+   u32 earh;
+   u8  pad3[0x8];
+   u32 seat;
+   u32 sead;
+   u32 op;
+   u32 fsiz;
+} dma_regs_t;
+
+/*
+ * I2O hardware registers (p.528 in 440SPe UM 1.22)
+ */
+typedef struct {
+   u32 ists;
+   u32 iseat;
+   u32 isead;
+   u8  pad0[0x14];
+   u32 idbel;
+   u8  pad1[0xc];
+   u32 ihis;
+   u32 ihim;
+   u8  pad2[0x8];
+   u32 ihiq;
+   u32 ihoq;
+   u8  pad3[0x8];
+   u32 iopis;
+   u32 iopim;
+   u32 iopiq;
+   u8  iopoq;
+   u8  pad4[3];
+   u16 iiflh;
+   u16 iiflt;
+   u16 iiplh;
+   u16 iiplt;
+   u16 ioflh;
+   u16 ioflt;
+   u16 ioplh;
+   u16 ioplt;
+   u32 iidc;
+   u32 ictl;
+   u32 ifcpp;
+   u8  pad5[0x4];
+   u16 mfac0;
+   u16 mfac1;
+   u16 mfac2;
+   u16 mfac3;
+   u16 mfac4;
+   u16 mfac5;
+   u16 mfac6;
+   u16 mfac7;
+   u16 ifcfh;
+   u16 ifcht;
+   u8  pad6[0x4];
+   u32 iifmc;
+   u32 iodb;
+   u32 iodbc;
+   u32 ifbal;
+   u32 ifbah;
+   u32 ifsiz;
+   u32 ispd0;
+   u32 ispd1;
+   u32 ispd2;
+   u32 ispd3;
+   u32 ihipl;
+   u32 ihiph;
+   u32 ihopl;
+   u32 ihoph;
+   u32 iiipl;
+   u32 iiiph;
+   u32 iiopl;
+   u32 iioph;
+   u32 ifcpl;
+   u32 ifcph;
+   u8  pad7[0x8];
+   u32 iopt;
+} i2o_regs_t;


I saw the use of "volatile" in the driver code which lead me back here. 
 I think it is a reasonable expectation that all drivers use the 
accessors in asm/io.h to read/write mmio registers rather than volatile 
structure pointers.  PPC folks feel free to correct me if this is common 
practice for PPC drivers.


A side note, checkpatch rightly says "do not add new typedefs".

[..]

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 5903a88..854d594 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -109,6 +109,19 @@ config SH_DMAE
help
  Enable support for the Renesas SuperH DMA controllers.

+config AMCC_PPC440SPE_ADMA
+   tristate "AMCC PPC440SPe ADMA support"
+   depends on 440SPe || 440SP
+   select DMA_ENGINE
+   select ASYNC_TX_DMA


The user should have the option to t

Re: RFC: Put printk buffer in video ram

[Arnd Bergmann]

On Monday 23 November 2009, Chris Friesen wrote:
> We've had a mechanism sort of like this for quite a while.  Hasn't been
> pushed to mainline because it used board-specific hardware and we're
> usually multiple kernel versions behind mainline.
> 
> Anyways, a couple things that we've found to be useful are:
> 1) The ability to allocate a chunk of this persistent memory area for a
> special purpose.  This allows things like memory-mapped circular buffers
> for per-cpu binary data.
> 2) An API to log just to this persistent area and bypass the normal
> console completely.  This can be useful when debugging issues where the
> normal logging paths result in a hang.

Some powerpc machines have a memory-mapped nvram, in which the kernel
can install persistant 'partitions'. Not all of them are memory mapped,
but for those that are (e.g. IBM QS22), your approach sounds perfect.

Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 07/19] powerpc: gamecube/wii: declare as non-coherent platforms

[Albert Herranz]

Arnd Bergmann wrote:
> On Sunday 22 November 2009, Albert Herranz wrote:
>>  config NOT_COHERENT_CACHE
>> bool
>> -   depends on 4xx || 8xx || E200 || PPC_MPC512x
>> +   depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
>> default y
>>  
>>  config CHECK_CACHE_COHERENCY
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig 
>> b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index 97a2dbc..31487e4 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -93,4 +93,5 @@ config MPC10X_STORE_GATHERING
>>  
>>  config GAMECUBE_COMMON
>> bool
>> +   select NOT_COHERENT_CACHE
> 
> One of the two (depends and select) is enough. I'd just drop the 'select'
> line here.
> 
>   Arnd <><
> 

Thanks, I'll fix that.

Cheers,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko

[Albert Herranz]

Arnd Bergmann wrote:
> On Sunday 22 November 2009, Albert Herranz wrote:
>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>> +setup_usbgecko_bat:
>> +/* prepare a BAT for early io */
>> +lis r8, 0x0c00
>> +ori r8, r8, 0x002a  /* uncached, guarded ,rw */
>> +lis r11, 0xcc00
>> +ori r11, r11, 0x3   /* 128K */
>> +#ifdef CONFIG_WII
>> +orisr8, r8, 0x0100
>> +orisr11, r11, 0x0100
>> +#endif
>> +mtspr   SPRN_DBAT1L, r8
>> +mtspr   SPRN_DBAT1U, r11
>> +sync
>> +isync
>> +blr
>> +#endif
> 
> This will probably break other platforms if CONFIG_PPC_EARLY_DEBUG_USBGECKO
> is set. In general, we try hard to make it possible to build generic
> kernels for multiple systems, so it would be better to also add a runtime
> check here.
> 

Ok, I see the point.
But, what makes CONFIG_PPC_EARLY_DEBUG_USBGECKO case different from 
CONFIG_PPC_EARLY_DEBUG_CPM case here?

>> --- a/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
>> +++ b/arch/powerpc/platforms/embedded6xx/usbgecko_udbg.h
>> @@ -27,4 +27,10 @@ static inline void __init ug_udbg_init(void)
>>  
>>  #endif /* CONFIG_USBGECKO_UDBG */
>>  
>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>> +
>> +void __init udbg_init_usbgecko(void);
>> +
>> +#endif /* CONFIG_PPC_EARLY_DEBUG_USBGECKO */
>> +
> 
> No need to enclose a declaration in #ifdef, better leave it there
> unconditionally, unless you have an alternative version, like
> 
> #ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
> void __init udbg_init_usbgecko(void);
> #else /* !CONFIG_PPC_EARLY_DEBUG_USBGECKO */
> static inline void udbg_init_usbgecko(void)
> {
> }
> #endif /* CONFIG_PPC_EARLY_DEBUG_USBGECKO */
> 
> That style is now more common than having additional #ifdefs
> in the code using the function.

I'll fix that too. Thanks.

Cheers,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 17/19] powerpc: wii: bootmii starlet 'mini' firmware support

[Albert Herranz]

Arnd Bergmann wrote:
> On Sunday 22 November 2009, Albert Herranz wrote:
>> + *
>> + */
>> +struct mipc_device {
>> +void __iomem *io_base;
>> +int irq;
>> +
>> +struct device *dev;
>> +
>> +spinlock_t call_lock;   /* serialize firmware calls */
>> +spinlock_t io_lock; /* serialize access to io registers */
>> +
>> +struct mipc_infohdr *hdr;
>> +
>> +struct mipc_req *in_ring;
>> +size_t in_ring_size;
>> +volatile u16 intail_idx;
>> +
>> +struct mipc_req *out_ring;
>> +size_t out_ring_size;
>> +volatile u16 outhead_idx;
>> +
>> +u32 tag;
>> +};
> 
> The 'volatile' here seems out of place. What are you trying to protect
> against?

Nothing. I'll get rid of it.
It slipped through from ancient versions of the patch.

> The rest of the patch seems to be made up of layers of wrappers. They
> are all well coded, but I got a feeling that the same could be achieved
> with less of it.

The code provides a complete emulation layer of hardware accessors via ipc 
calls to the firmware.
This was a requirement to access part of the hardware until a "magic" register 
was found allowing direct hardware access from the PowerPC side.

I can get rid of the currently unused infrastructure and leave the strictly 
needed code (i.e. code to make sure that the firmware SDHC driver is shutdown 
and that the ahbprot register is properly setup).

I'll look into that. Thanks.

Cheers,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 00/19] powerpc: nintendo gamecube and wii support

[Albert Herranz]

Arnd Bergmann wrote:
> 
> Very nice series, well done!
> 
> Time for me to invest in some new hardware ;-)
> 
>   Arnd <><
> 

Thanks for review :)

Cheers,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add a device tree source file for the Nintendo GameCube video game console.
>>
>> Signed-off-by: Albert Herranz 
> 
> Mostly looks good.  A few comments below.  Biggest comment is you need
> to add a brief blurb for every new "compatible" property value that
> you've added to Documentation/powerpc/dts-bindings.  General agreement
> is that we don't merge drivers with new OF tree bindings unless the
> binding is also documented.  It doesn't need to be long, it just needs
> to state what the device is, and what properties are expected.  If you
> define new properties, then you need to state what they are used for.
> 
> Once the comments below are addressed...
> 
> Acked-by: Grant Likely 
> 

Thanks. I'll add the documentation for the new compatible properties.

>> ---
>>  arch/powerpc/boot/dts/gamecube.dts |  135 
>> 
>>  1 files changed, 135 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/powerpc/boot/dts/gamecube.dts
>>
>> diff --git a/arch/powerpc/boot/dts/gamecube.dts 
>> b/arch/powerpc/boot/dts/gamecube.dts
>> new file mode 100644
>> index 000..941a2c4
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/gamecube.dts
>> @@ -0,0 +1,135 @@
>> +/*
>> + * arch/powerpc/boot/dts/gamecube.dts
>> + *
>> + * Nintendo GameCube platform device tree source
>> + * Copyright (C) 2007-2009 The GameCube Linux Team
>> + * Copyright (C) 2007,2008,2009 Albert Herranz
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/ {
>> +   model = "NintendoGameCube";
>> +   compatible = "nintendo,gamecube";
> 
> To date, we've been using the same form for both the model and
> compatible properties.  Specifically the , form to
> maintain the namespace.
> 

Ok, I'll change model to "nintendo,gamecube".

>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +
>> +   chosen {
>> +   bootargs = "root=/dev/gcnsda2 rootwait udbg-immortal";
>> +   linux,stdout-path = &USBGECKO0;
>> +   };
>> +
>> +   aliases {
>> +   ugecon = &USBGECKO0;
>> +   };
>> +
>> +   memory {
>> +   device_type = "memory";
>> +   /* 24M minus framebuffer memory area (640*576*2*2) */
>> +   reg = <0x 0x01698000>;
>> +   };
>> +
>> +   cpus {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   PowerPC,ge...@0 {
>> +   device_type = "cpu";
>> +   reg = <0>;
>> +   clock-frequency = <48600>; /* 486MHz */
>> +   bus-frequency = <16200>; /* 162MHz core-to-bus 
>> 3x */
>> +   timebase-frequency = <4050>; /* 162MHz / 4 */
>> +   i-cache-line-size = <32>;
>> +   d-cache-line-size = <32>;
>> +   i-cache-size = <32768>;
>> +   d-cache-size = <32768>;
>> +   };
>> +   };
>> +
>> +   /* devices contained int the flipper chipset */
>> +   soc {
> 
> It would be better to rename this as IMMR or the bus type.  This node
> doesn't actually describe the entire chip, but describes the internal
> memory mapped registers.
> 

Can you please elaborate more on this or point me to documentation?
The soc node here tries to represent the big multi-function chip that 
integrates most of the devices of the video game consoles ("Flipper" on the 
Nintendo GameCube and "Hollywood" on the Wii).

>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   #interrupt-cells = <1>;
>> +   model = "flipper";
> 
> Drop the model property
> 

Ok, I'll fix that.

>> +   compatible = "nintendo,flipper";
>> +   clock-frequency = <16200>; /* 162MHz */
>> +   ranges = <0x0c00 0x0c00 0x0001>;
> 
> Since you're only doing 1:1 mappings; you could replace this with an
> empty "ranges;" property instead.
> 

Nice, didn't know about this. I'll do that.

>> +
>> +   vi...@0c002000 {
>> +   compatible = "nintendo,flipper-video";
>> +   reg = <0x0c002000 0x100>;
>> +   interrupts = <8>;
>> +   interrupt-parent = <&pic>;
> 
> Hint:  If you move the interrupt-parent property up to the root node,
> then you don't need to specify it in every single device node; it will
> just inherit from the parent.
> 

Got it. This makes a lot of sense here with a single interrupt controller.

>> +   /* XFB is the eXternal FrameBuffer */
>> +

Re: [RFC PATCH 04/19] powerpc: wii: device tree

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add a device tree source file for the Nintendo Wii video game console.
>>
>> Signed-off-by: Albert Herranz 
> 
> Same comments apply here as for the gamecube.dts file, plus a few more below.
> 

Ok, I'll try to address them too here.

>> ---
>>  arch/powerpc/boot/dts/wii.dts |  244 
>> +
>>  1 files changed, 244 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/powerpc/boot/dts/wii.dts
>>
>> diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
>> new file mode 100644
>> index 000..a30a804
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/wii.dts
>> @@ -0,0 +1,244 @@
>> +/*
>> + * arch/powerpc/boot/dts/wii.dts
>> + *
>> + * Nintendo Wii platform device tree source
>> + * Copyright (C) 2008-2009 The GameCube Linux Team
>> + * Copyright (C) 2008,2009 Albert Herranz
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
> 
> This bothers me... see below.
> 
>> +
>> +/ {
>> +   model = "NintendoWii";
>> +   compatible = "nintendo,wii";
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +
>> +   chosen {
>> +   /* root filesystem on 2nd partition of SD card */
>> +   bootargs = "nobats root=/dev/mmcblk0p2 rootwait 
>> udbg-immortal";
>> +   linux,stdout-path = &USBGECKO0;
>> +   };
>> +
>> +   aliases {
>> +   ugecon = &USBGECKO0;
>> +   hw_gpio = &gpio1;
>> +   };
>> +
>> +   /*
>> +* The Nintendo Wii has two discontiguous RAM memory areas called
>> +* MEM1 and MEM2.
>> +* MEM1 starts at 0x and contains 24MB of 1T-SRAM.
>> +* MEM2 starts at 0x1000 and contains 64MB of DDR2 RAM.
>> +* Between both memory address ranges there is an address space
>> +* where memory-mapped I/O registers are found.
>> +*
>> +* Currently, Linux 32-bit PowerPC does not support RAM in
>> +* discontiguous memory address spaces. Thus, in order to use
>> +* both RAM areas, we declare as RAM the range from the start of
>> +* MEM1 to the end of useable MEM2 and exclude the needed parts
>> +* with /memreserve/ statements, at the expense of wasting a bit
>> +* of memory.
> 
> Hmmm.  It's not great practice to lie about hardware in the device
> tree.  Better to describe the memory correctly here, and if you have
> to work around Linux deficiencies, then do so in the platform support
> code (arch/platforms/*).  I won't NAK the patch over it (feel free to
> add my Acked-by line) because it doesn't impact other platforms, but
> it should be fixed.
> 

I'll try to workaround the limitation via a fixups function in the bootwrapper 
instead.

>> +   i2c-video {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   compatible = "virtual,i2c-gpio";
> 
> There isn't a documented binding for this.  Is there a driver for it?
> 

I have a driver for it. But it isn't yet published.

This is the documentation I wrote so far for the bindings.
Is there a standard for this?

Documentation/powerpc/dts-bindings/gpio/i2c.txt

GPIO-based I2C

Required properties:
- compatible : should be "virtual,i2c-gpio".
- gpios : should specify GPIOs used for SDA and SCL lines, in that order.
- sda-is-open-drain : should be non-zero if SDA gpio is open-drain.
- sda-enforce-dir : should be non-zero if SDA gpio must be configured for
input before reading and for output before writing.
- scl-is-open-drain : should be non-zero if SCL gpio is open-drain.
- scl-is-output-only : should be non-zero if SCL is an output gpio only.
- udelay : signal toggle delay. SCL frequency is (500 / udelay) kHz
- timeout : clock stretching timeout in milliseconds.

Example:

gpio0: hollywood-g...@0d8000c0 {
compatible = "nintendo,hollywood-gpio";
reg = <0x0d8000c0 0x20>;
gpio-controller;
#gpio-cells = <2>;
 };

i2c-video {
#address-cells = <1>;
#size-cells = <0>;
compatible = "virtual,i2c-gpio";

gpios = <&gpio0 16 0/* SDA line */
 &gpio0 17 0/* SCL line */
>;
sda-is-open-drain = <1>;
sda-enforce-dir = <1>;
scl-is-open-drain = <1>;
scl-is-output-only = <1>;
udelay = <2>;

audio-video-encoder {
compatible = "nintendo,wii-ave-rvl";
reg = <0x70>;
};
};

>> +
>

Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add a config option GAMECUBE_COMMON to be used as a dependency for all
>> options common to the Nintendo GameCube and Wii video game consoles.
>>
>> Signed-off-by: Albert Herranz 
> 
> This could just be rolled into the first patch that uses it.  But
> otherwise; ACK.
> 
> g.
> 

Thanks. This one I prefer in a separate patch as a logical step, if that's not 
a problem.

>> ---
>>  arch/powerpc/platforms/embedded6xx/Kconfig |4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig 
>> b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index 291ac9d..97a2dbc 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -90,3 +90,7 @@ config MPC10X_OPENPIC
>>  config MPC10X_STORE_GATHERING
>>bool "Enable MPC10x store gathering"
>>depends on MPC10X_BRIDGE
>> +
>> +config GAMECUBE_COMMON
>> +   bool
>> +

Cheers,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add support for the interrupt controller included in the "Flipper"
>> chipset of the Nintendo GameCube video game console.
>> The same interrupt controller is also present in the "Hollywood" chipset
>> of the Nintendo Wii.
>>
>> Signed-off-by: Albert Herranz 
>> ---
>>  arch/powerpc/platforms/embedded6xx/Kconfig   |6 +
>>  arch/powerpc/platforms/embedded6xx/Makefile  |1 +
>>  arch/powerpc/platforms/embedded6xx/flipper-pic.c |  247 
>> ++
>>  arch/powerpc/platforms/embedded6xx/flipper-pic.h |   25 +++
>>  4 files changed, 279 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/powerpc/platforms/embedded6xx/flipper-pic.c
>>  create mode 100644 arch/powerpc/platforms/embedded6xx/flipper-pic.h
>>
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig 
>> b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index bfd88be..29a98c6 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -94,6 +94,7 @@ config MPC10X_STORE_GATHERING
>>  config GAMECUBE_COMMON
>>bool
>>select NOT_COHERENT_CACHE
>> +   select FLIPPER_PIC
>>
>>  config USBGECKO_UDBG
>>bool "USB Gecko udbg console for the Nintendo GameCube/Wii"
>> @@ -108,3 +109,8 @@ config USBGECKO_UDBG
>>
>>  If in doubt, say N here.
>>
>> +config FLIPPER_PIC
>> +   bool
>> +   depends on GAMECUBE_COMMON
>> +   default y
> 
> You'll always want this driver when GAMECUBE common is set.  Don't add
> another Kconfig entry.
> 

Ok.

>> +
>> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile 
>> b/arch/powerpc/platforms/embedded6xx/Makefile
>> index 0ab7492..35258fd 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Makefile
>> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_PPC_HOLLY) += holly.o
>>  obj-$(CONFIG_PPC_PRPMC2800)+= prpmc2800.o
>>  obj-$(CONFIG_PPC_C2K)  += c2k.o
>>  obj-$(CONFIG_USBGECKO_UDBG)+= usbgecko_udbg.o
>> +obj-$(CONFIG_FLIPPER_PIC)  += flipper-pic.o
> 
>> +unsigned int flipper_pic_get_irq(void)
>> +{
>> +   void __iomem *io_base = flipper_irq_host->host_data;
>> +   int irq;
>> +   u32 irq_status;
>> +
>> +   irq_status = in_be32(io_base + FLIPPER_ICR) &
>> +in_be32(io_base + FLIPPER_IMR);
>> +   if (irq_status == 0)
>> +   return -1;  /* no more IRQs pending */
> 
> NO_IRQ_IGNORE
> 

I'll fix that. Thanks.
I did it in the other interrupt controller but forgot about this.

>> +
>> +   __asm__ __volatile__("cntlzw %0,%1" : "=r"(irq) : "r"(irq_status));
>> +   return irq_linear_revmap(flipper_irq_host, 31 - irq);
>> +}
>> +
> 

Thanks.

Cheers,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 12/19] powerpc: gamecube: platform support

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add platform support for the Nintendo GameCube video game console.
>>
>> Signed-off-by: Albert Herranz 
>> ---
>> +static void gamecube_show_cpuinfo(struct seq_file *m)
>> +{
>> +   seq_printf(m, "vendor\t\t: IBM\n");
>> +   seq_printf(m, "machine\t\t: Nintendo GameCube\n");
>> +}
> 
> show_cpuinfo hooks have been dropped on most platforms now.
> 

I'll drop'em all. Thanks.

>> +static void gamecube_shutdown(void)
>> +{
>> +   /* currently not used */
>> +}
> 
> Then don't add the hook.  Just drop it.  Same for other empty
> functions in this file.  If it is safe to drop them, then please do.
> 
> Otherwise: Acked-by: Grant Likely 
> 

I actually forgot to add a flipper_quiesce() call there.
That one will be used.

But I'll review the other cases. Thanks.

>> +define_machine(gamecube) {
>> +   .name   = "gamecube",
>> +   .probe  = gamecube_probe,
>> +   .setup_arch = gamecube_setup_arch,
>> +   .init_early = gamecube_init_early,
>> +   .show_cpuinfo   = gamecube_show_cpuinfo,
>> +   .restart= gamecube_restart,
>> +   .power_off  = gamecube_power_off,
>> +   .halt   = gamecube_halt,
>> +   .init_IRQ   = flipper_pic_probe,
>> +   .get_irq= flipper_pic_get_irq,
>> +   .calibrate_decr = generic_calibrate_decr,
>> +   .progress   = udbg_progress,
>> +   .machine_shutdown   = gamecube_shutdown,
>> +#ifdef CONFIG_KEXEC
>> +   .machine_kexec_prepare  = gamecube_kexec_prepare,
>> +   .machine_kexec  = default_machine_kexec,
>> +#endif
>> +};
>> +
>> diff --git a/arch/powerpc/platforms/embedded6xx/gamecube_dev.c 
>> b/arch/powerpc/platforms/embedded6xx/gamecube_dev.c
>> new file mode 100644
>> index 000..13e1f73
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/embedded6xx/gamecube_dev.c
>> @@ -0,0 +1,34 @@
>> +/*
>> + * arch/powerpc/platforms/embedded6xx/gamecube_dev.c
>> + *
>> + * Nintendo GameCube platform device setup.
>> + * Copyright (C) 2008-2009 The GameCube Linux Team
>> + * Copyright (C) 2008,2009 Albert Herranz
>> + *
>> + * 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 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +static struct of_device_id gamecube_of_bus[] = {
>> +   { .compatible = "nintendo,flipper", },
>> +   { },
>> +};
>> +
>> +static int __init gamecube_device_probe(void)
>> +{
>> +   if (!machine_is(gamecube))
>> +   return 0;
>> +
>> +   of_platform_bus_probe(NULL, gamecube_of_bus, NULL);
>> +   return 0;
>> +}
>> +device_initcall(gamecube_device_probe);

Cheers,
Albert


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> The Nintendo Wii has two discontiguous RAM memory areas called
>> MEM1 and MEM2.
>> MEM1 starts at 0x and contains 24MB of 1T-SRAM.
>> MEM2 starts at 0x1000 and contains 64MB of DDR2 RAM.
>> Between both memory address ranges there is an address space
>> where memory-mapped I/O registers are found.
>>
>> Currently, Linux 32-bit PowerPC does not support RAM in
>> discontiguous memory address spaces. Thus, in order to use
>> both RAM areas, we declare as RAM the range from the start of
>> MEM1 to the end of useable MEM2 and exclude the needed parts
>> with /memreserve/ statements, at the expense of wasting a bit
>> of memory.
>>
>> As a side effect, we need to allow ioremapping RAM areas
>> because the I/O address space sits within the memreserve'd part
>> of the declared RAM region.
>> Note that this is not safe if the region ioremapped is covered
>> by an existing BAT mapping used to map RAM, so this is
>> specifically banned here.
>>
>> Signed-off-by: Albert Herranz 
>> ---
>>  arch/powerpc/mm/pgtable_32.c |   19 ---
>>  1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>> index cb96cb2..ba00cb1 100644
>> --- a/arch/powerpc/mm/pgtable_32.c
>> +++ b/arch/powerpc/mm/pgtable_32.c
>> @@ -191,9 +191,22 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
>> unsigned long flags,
>> * Don't allow anybody to remap normal RAM that we're using.
>> * mem_init() sets high_memory so only do the check after that.
>> */
>> -   if (mem_init_done && (p < virt_to_phys(high_memory))) {
>> -   printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
>> -  (unsigned long long)p, __builtin_return_address(0));
>> +   if (mem_init_done && (p < virt_to_phys(high_memory))
>> +#ifdef CONFIG_WII
>> +   /*
>> +* On some systems, though, we may want to remap an area
>> +* declared as normal RAM that we have memreserve'd at the
>> +* device tree. See wii.dts.
>> +* But we can't do that safely if we are using BATs to map
>> +* part of that area.
>> +*/
>> +   && !__map_without_bats
>> +#endif
>> +   ) {
>> +   printk(KERN_WARNING
>> +  "__ioremap(): phys addr 0x%llx is RAM lr %p\n",
>> +  (unsigned long long)p,
>> +__builtin_return_address(0));
> 
> This could adversely affect multiplatform kernels.  I'd rather get the
> RAM problem fixed and not hack up common code to work around the hack.
> 
> g.
> 

Would it be acceptable to create a global var __allow_ioremap_normal_ram that 
by default would have a value of 0 and would be set _only_ for those platforms 
needing it?

The other solutions I see is:
- add support for discontiguous memory to powerpc 32-bits (which is not 
something that I can look into now)
- don't use the precious second 64MB area (which is a waste)

Do you have any other suggestions?

Thanks,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 15/19] powerpc: broadway processor support

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> This patch extends the cputable entry of the 750CL to also match
>> the 750CL-based "Broadway" cpu found on the Nintendo Wii.
>>
>> As of this patch, the following "Broadway" design revision levels have
>> been seen in the wild:
>> - DD1.2 (87102)
>> - DD2.0 (87200)
> 
> Please respin without the reordering of CPU table entries.  If you
> want to reorder, then do it in a separate patch.
> 
> g.
> 

Ok. I'll look into that too. Thanks.

Cheers,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 16/19] powerpc: wii: hollywood interrupt controller support

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add support for the dual interrupt controller included in the "Hollywood"
>> chipset of the Nintendo Wii video game console.
>> This interrupt controller serves both the Broadway processor (as a cascade)
>> and the Starlet processor, and is used to manage interrupts for the
>> non-classic hardware.
>>
>> Signed-off-by: Albert Herranz 
> 
> On brief glance...
> 
> Acked-by: Grant Likely 
> 

Uhmmm... I think I should use .name instead of .typename in struct irq_chip, no?

>> ---
>>  arch/powerpc/platforms/embedded6xx/Kconfig|5 +
>>  arch/powerpc/platforms/embedded6xx/Makefile   |1 +
>>  arch/powerpc/platforms/embedded6xx/hlwd-pic.c |  238 
>> +
>>  arch/powerpc/platforms/embedded6xx/hlwd-pic.h |   22 +++
>>  4 files changed, 266 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/powerpc/platforms/embedded6xx/hlwd-pic.c
>>  create mode 100644 arch/powerpc/platforms/embedded6xx/hlwd-pic.h
>>
>> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig 
>> b/arch/powerpc/platforms/embedded6xx/Kconfig
>> index efb2ea1..490f89e 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
>> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
>> @@ -122,3 +122,8 @@ config GAMECUBE
>>  Select GAMECUBE if configuring for the Nintendo GameCube.
>>  More information at: 
>>
>> +config HLWD_PIC
>> +   bool
>> +   depends on STARLET_MINI
>> +   default y
>> +
>> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile 
>> b/arch/powerpc/platforms/embedded6xx/Makefile
>> index b0324ed..c1dcc54 100644
>> --- a/arch/powerpc/platforms/embedded6xx/Makefile
>> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
>> @@ -10,3 +10,4 @@ obj-$(CONFIG_PPC_C2K) += c2k.o
>>  obj-$(CONFIG_USBGECKO_UDBG)+= usbgecko_udbg.o
>>  obj-$(CONFIG_FLIPPER_PIC)  += flipper-pic.o
>>  obj-$(CONFIG_GAMECUBE) += gamecube.o gamecube_dev.o
>> +obj-$(CONFIG_HLWD_PIC) += hlwd-pic.o
>> diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c 
>> b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
>> new file mode 100644
>> index 000..b024800
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
>> @@ -0,0 +1,238 @@
>> +/*
>> + * arch/powerpc/platforms/embedded6xx/hlwd-pic.c
>> + *
>> + * Nintendo Wii "Hollywood" interrupt controller support.
>> + * Copyright (C) 2009 The GameCube Linux Team
>> + * Copyright (C) 2009 Albert Herranz
>> + *
>> + * 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.
>> + *
>> + */
>> +#define DRV_MODULE_NAME "hlwd-pic"
>> +#define pr_fmt(fmt) DRV_MODULE_NAME ": " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "hlwd-pic.h"
>> +
>> +#define HLWD_NR_IRQS   32
>> +
>> +/*
>> + * Each interrupt has a corresponding bit in both
>> + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
>> + *
>> + * Enabling/disabling an interrupt line involves asserting/clearing
>> + * the corresponding bit in IMR. ACK'ing a request simply involves
>> + * asserting the corresponding bit in ICR.
>> + */
>> +#define HW_BROADWAY_ICR0x00
>> +#define HW_BROADWAY_IMR0x04
>> +
>> +
>> +/*
>> + * IRQ chip hooks.
>> + *
>> + */
>> +
>> +static void hlwd_pic_mask_and_ack(unsigned int virq)
>> +{
>> +   int irq = virq_to_hw(virq);
>> +   void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +   clear_bit(irq, io_base + HW_BROADWAY_IMR);
>> +   set_bit(irq, io_base + HW_BROADWAY_ICR);
>> +}
>> +
>> +static void hlwd_pic_ack(unsigned int virq)
>> +{
>> +   int irq = virq_to_hw(virq);
>> +   void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +   set_bit(irq, io_base + HW_BROADWAY_ICR);
>> +}
>> +
>> +static void hlwd_pic_mask(unsigned int virq)
>> +{
>> +   int irq = virq_to_hw(virq);
>> +   void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +   clear_bit(irq, io_base + HW_BROADWAY_IMR);
>> +}
>> +
>> +static void hlwd_pic_unmask(unsigned int virq)
>> +{
>> +   int irq = virq_to_hw(virq);
>> +   void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +   set_bit(irq, io_base + HW_BROADWAY_IMR);
>> +}
>> +
>> +
>> +static struct irq_chip hlwd_pic = {
>> +   .typename   = "hlwd-pic",
>> +   .ack= hlwd_pic_ack,
>> +   .mask_ack   = hlwd_pic_mask_and_ack,
>> +   .mask   = hlwd_pic_mask,
>> +   .unmask = hlwd_pic_unmask,
>> +};
>> +
>> +/*
>> + * IRQ host hooks.
>> + *
>> + */
>> +
>> +static struct irq_host *hlwd_irq_host;
>> +
>> +static int hlwd_pic_map(struct irq_host *h, unsigned int virq,
>> +   

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree

[Grant Likely]

On Mon, Nov 23, 2009 at 12:44 PM, Albert Herranz
 wrote:
> Grant Likely wrote:
>> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
>> wrote:
>>> +       /* devices contained int the flipper chipset */
>>> +       soc {
>>
>> It would be better to rename this as IMMR or the bus type.  This node
>> doesn't actually describe the entire chip, but describes the internal
>> memory mapped registers.
>>
>
> Can you please elaborate more on this or point me to documentation?
> The soc node here tries to represent the big multi-function chip that 
> integrates most of the devices of the video game consoles ("Flipper" on the 
> Nintendo GameCube and "Hollywood" on the Wii).

Right.  Much like many other SoCs.  However, the SoC has all these
devices + the cpu core + the memory controller, and probably some
other stuff.  Whereas this particular node only encapsulates the
integrated peripherals on an internal bus, so the node really is
describing the internal bus, not the entire SoC.  On some chips it is
documented as the "internally memory mapped registers", or IMMR.  So,
it is better to name this node in a way that reflects what it is (an
internal bus) instead of as the whole chip.

Similarly, it is better to use a compatible value of something like:
compatible = "nintendo,flipper-immr"; (instead of "nintendo,flipper")
because your describing just the internal bus, not the entire chip.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 18/19] powerpc: wii: platform support

[Albert Herranz]

Grant Likely wrote:
> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
> wrote:
>> Add platform support for the Nintendo Wii video game console.
>>
>> Signed-off-by: Albert Herranz 
>> ---
>> +static int wii_setup_hw_resets(void)
>> +{
>> +   struct device_node *np;
>> +   struct resource res;
>> +   int error = -ENODEV;
>> +
>> +   np = of_find_compatible_node(NULL, NULL, HW_RESETS_OF_COMPATIBLE);
>> +   if (!np) {
>> +   pr_err("no compatible node found for %s\n",
>> +  HW_RESETS_OF_COMPATIBLE);
>> +   goto out;
>> +   }
>> +   error = of_address_to_resource(np, 0, &res);
>> +   if (error) {
>> +   pr_err("no valid reg found for %s\n", np->name);
>> +   goto out_put;
>> +   }
>> +
>> +   hw_resets = ioremap(res.start, res.end - res.start + 1);
> 
> Or you could use of_iomap() to cut out some code.
> 

Thanks. I'll have a look at it.

>> +   if (hw_resets) {
>> +   pr_info("hw_resets at 0x%08x mapped to 0x%p\n",
>> +   res.start, hw_resets);
>> +   }
>> +
>> +out_put:
>> +   of_node_put(np);
>> +out:
>> +   return error;
>> +}
>> +
>> +static int wii_setup_hw_gpio(void)
>> +{
>> +   struct device_node *np;
>> +   struct resource res;
>> +   const char *path;
>> +   int error = -ENODEV;
>> +
>> +   np = of_find_node_by_name(NULL, "aliases");
>> +   if (!np) {
>> +   pr_err("unable to find node %s\n", "aliases");
>> +   goto out;
>> +   }
>> +
>> +   path = of_get_property(np, HW_GPIO_ALIAS, NULL);
>> +   of_node_put(np);
>> +   if (!path) {
>> +   pr_err("alias %s unknown\n", HW_GPIO_ALIAS);
>> +   goto out;
>> +   }
>> +
>> +   np = of_find_node_by_path(path);
>> +   if (!np) {
>> +   pr_err("node for alias %s unknown\n", HW_GPIO_ALIAS);
>> +   goto out;
>> +   }
>> +   error = of_address_to_resource(np, 0, &res);
>> +   if (error) {
>> +   pr_err("no valid reg found for %s\n", np->name);
>> +   goto out_put;
>> +   }
>> +
>> +   hw_gpio = ioremap(res.start, res.end - res.start + 1);
>> +   if (hw_gpio) {
>> +   pr_info("hw_gpio at 0x%08x mapped to 0x%p\n",
>> +   res.start, hw_gpio);
>> +   }
>> +
>> +out_put:
>> +   of_node_put(np);
>> +out:
>> +   return error;
>> +}
>> +
>> +static void wii_setup(void)
>> +{
>> +   wii_setup_hw_resets();
>> +   wii_setup_hw_gpio();
>> +}
>> +
>> +static void wii_restart(char *cmd)
>> +{
>> +   local_irq_disable();
>> +
>> +   if (hw_resets) {
>> +   /* clear the system reset pin to cause a reset */
>> +   clear_bit(0, hw_resets);
>> +   }
>> +   wii_spin();
>> +}
>> +
>> +static void wii_power_off(void)
>> +{
>> +   local_irq_disable();
>> +
>> +   if (hw_gpio) {
>> +   /* make sure that the poweroff GPIO is configured as output 
>> */
>> +   out_be32(hw_gpio + HW_GPIO_DIR,
>> +in_be32(hw_gpio + HW_GPIO_DIR) | HW_GPIO_SHUTDOWN);
>> +
>> +   /* drive the poweroff GPIO high */
>> +   out_be32(hw_gpio + HW_GPIO_OUT,
>> +in_be32(hw_gpio + HW_GPIO_OUT) | HW_GPIO_SHUTDOWN);
>> +   }
>> +   wii_spin();
>> +}
>> +
>> +#else
>> +
>> +static void wii_setup(void)
>> +{
>> +}
>> +
>> +static void wii_restart(char *cmd)
>> +{
>> +   wii_spin();
>> +}
>> +
>> +static void wii_power_off(void)
>> +{
>> +   wii_spin();
>> +}
>> +
>> +#endif /* CONFIG_STARLET_MINI */
>> +
>> +static void wii_halt(void)
>> +{
>> +   if (ppc_md.restart)
>> +   ppc_md.restart(NULL);
>> +   wii_spin();
>> +}
>> +
>> +static void wii_show_cpuinfo(struct seq_file *m)
>> +{
>> +   seq_printf(m, "vendor\t\t: IBM\n");
>> +   seq_printf(m, "machine\t\t: Nintendo Wii\n");
>> +}
> 
> Drop show_cpuinfo() hook.
> 

Yup.

>> +static int wii_discover_ipc_flavour(void)
>> +{
>> +   struct mipc_infohdr *hdrp;
>> +   int error;
>> +
>> +   error = mipc_infohdr_get(&hdrp);
>> +   if (!error) {
>> +   mipc_infohdr_put(hdrp);
>> +   starlet_ipc_flavour = STARLET_IPC_MINI;
>> +   wii_setup();
>> +   ppc_md.restart = wii_restart;
>> +   ppc_md.power_off = wii_power_off;
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +static void __init wii_setup_arch(void)
>> +{
>> +   ug_udbg_init();
>> +   wii_discover_ipc_flavour();
>> +}
>> +
>> +static void __init wii_init_early(void)
>> +{
>> +}
>> +
>> +static int __init wii_probe(void)
>> +{
>> +   unsigned long dt_root;
>> +
>> +   dt_root = of_get_flat_dt_root();
>> +   if (!of_flat_dt_is_compatible(dt_root, "nintendo,wii"))
>> +   return 0;
>> +
>> +   return 1;
>> +}
>> +
>> +static void wii_shutdown(void)

Re: [RFC PATCH 02/19] powerpc: gamecube: device tree

[Albert Herranz]

Grant Likely wrote:
> On Mon, Nov 23, 2009 at 12:44 PM, Albert Herranz
>> Can you please elaborate more on this or point me to documentation?
>> The soc node here tries to represent the big multi-function chip that 
>> integrates most of the devices of the video game consoles ("Flipper" on the 
>> Nintendo GameCube and "Hollywood" on the Wii).
> 
> Right.  Much like many other SoCs.  However, the SoC has all these
> devices + the cpu core + the memory controller, and probably some
> other stuff.  Whereas this particular node only encapsulates the
> integrated peripherals on an internal bus, so the node really is
> describing the internal bus, not the entire SoC.  On some chips it is
> documented as the "internally memory mapped registers", or IMMR.  So,
> it is better to name this node in a way that reflects what it is (an
> internal bus) instead of as the whole chip.
> 
> Similarly, it is better to use a compatible value of something like:
> compatible = "nintendo,flipper-immr"; (instead of "nintendo,flipper")
> because your describing just the internal bus, not the entire chip.
> 
> g.
> 

Thanks for the clarification.
I'll see what I can do :)

Cheers,
Albert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

[Grant Likely]

On Mon, Nov 23, 2009 at 12:54 PM, Albert Herranz
 wrote:
> Grant Likely wrote:
>> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
>> wrote:
>>> +               i2c-video {
>>> +                       #address-cells = <1>;
>>> +                       #size-cells = <0>;
>>> +                       compatible = "virtual,i2c-gpio";
>>
>> There isn't a documented binding for this.  Is there a driver for it?
>>
>
> I have a driver for it. But it isn't yet published.
>
> This is the documentation I wrote so far for the bindings.
> Is there a standard for this?

This looks pretty good to me.  The documentation format isn't strict,
just follow the pattern seen in other bindings.  Make sure you post
new bindings to devicetree-disc...@lists.ozlabs.org for review.  A
couple of comments below.

> Documentation/powerpc/dts-bindings/gpio/i2c.txt
>
> GPIO-based I2C
>
> Required properties:
> - compatible : should be "virtual,i2c-gpio".
> - gpios : should specify GPIOs used for SDA and SCL lines, in that order.
> - sda-is-open-drain : should be non-zero if SDA gpio is open-drain.
> - sda-enforce-dir : should be non-zero if SDA gpio must be configured for
>                    input before reading and for output before writing.
> - scl-is-open-drain : should be non-zero if SCL gpio is open-drain.
> - scl-is-output-only : should be non-zero if SCL is an output gpio only.

Instead of looking for a value in these properties, just make them
empty properties and change behaviour based on whether or not the
property is present.

Why is the scl-is-output-only property needed?

> - udelay : signal toggle delay. SCL frequency is (500 / udelay) kHz

You should follow the lead of
Documentation/powerpc/dts-bindings/fsl/i2c.txt here and specify a
clock-frequency property.

> - timeout : clock stretching timeout in milliseconds.

I don't understand what this property means.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions

[Grant Likely]

On Mon, Nov 23, 2009 at 1:16 PM, Albert Herranz  wrote:
> Grant Likely wrote:
>> On Sun, Nov 22, 2009 at 3:01 PM, Albert Herranz  
>> wrote:
>>> The Nintendo Wii has two discontiguous RAM memory areas called
>>> MEM1 and MEM2.
>>> MEM1 starts at 0x and contains 24MB of 1T-SRAM.
>>> MEM2 starts at 0x1000 and contains 64MB of DDR2 RAM.
>>> Between both memory address ranges there is an address space
>>> where memory-mapped I/O registers are found.
>>>
>>> Currently, Linux 32-bit PowerPC does not support RAM in
>>> discontiguous memory address spaces. Thus, in order to use
>>> both RAM areas, we declare as RAM the range from the start of
>>> MEM1 to the end of useable MEM2 and exclude the needed parts
>>> with /memreserve/ statements, at the expense of wasting a bit
>>> of memory.
>>>
>>> As a side effect, we need to allow ioremapping RAM areas
>>> because the I/O address space sits within the memreserve'd part
>>> of the declared RAM region.
>>> Note that this is not safe if the region ioremapped is covered
>>> by an existing BAT mapping used to map RAM, so this is
>>> specifically banned here.
>>>
>>> Signed-off-by: Albert Herranz 
>>> ---
>>>  arch/powerpc/mm/pgtable_32.c |   19 ---
>>>  1 files changed, 16 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
>>> index cb96cb2..ba00cb1 100644
>>> --- a/arch/powerpc/mm/pgtable_32.c
>>> +++ b/arch/powerpc/mm/pgtable_32.c
>>> @@ -191,9 +191,22 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
>>> unsigned long flags,
>>>         * Don't allow anybody to remap normal RAM that we're using.
>>>         * mem_init() sets high_memory so only do the check after that.
>>>         */
>>> -       if (mem_init_done && (p < virt_to_phys(high_memory))) {
>>> -               printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
>>> -                      (unsigned long long)p, __builtin_return_address(0));
>>> +       if (mem_init_done && (p < virt_to_phys(high_memory))
>>> +#ifdef CONFIG_WII
>>> +               /*
>>> +                * On some systems, though, we may want to remap an area
>>> +                * declared as normal RAM that we have memreserve'd at the
>>> +                * device tree. See wii.dts.
>>> +                * But we can't do that safely if we are using BATs to map
>>> +                * part of that area.
>>> +                */
>>> +           && !__map_without_bats
>>> +#endif
>>> +           ) {
>>> +               printk(KERN_WARNING
>>> +                      "__ioremap(): phys addr 0x%llx is RAM lr %p\n",
>>> +                      (unsigned long long)p,
>>> +                        __builtin_return_address(0));
>>
>> This could adversely affect multiplatform kernels.  I'd rather get the
>> RAM problem fixed and not hack up common code to work around the hack.
>>
>> g.
>>
>
> Would it be acceptable to create a global var __allow_ioremap_normal_ram that 
> by default would have a value of 0 and would be set _only_ for those 
> platforms needing it?

I'm not the best one to answer this since I don't dig into the mm code
very often.  Ben?  Kumar?  Becky?  Thoughts?

> The other solutions I see is:
> - add support for discontiguous memory to powerpc 32-bits (which is not 
> something that I can look into now)

I of course like this option.  :-)

> - don't use the precious second 64MB area (which is a waste)

Not exactly nice, but it might be wise to do this now so that
discussion about how to fix it best won't block getting the bulk of
support into mainline.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

[Albert Herranz]

Grant Likely wrote:
> This looks pretty good to me.  The documentation format isn't strict,
> just follow the pattern seen in other bindings.  Make sure you post
> new bindings to devicetree-disc...@lists.ozlabs.org for review.  A
> couple of comments below.
> 

Ok. I know it now for the next time :)

>> Documentation/powerpc/dts-bindings/gpio/i2c.txt
>>
>> GPIO-based I2C
>>
>> Required properties:
>> - compatible : should be "virtual,i2c-gpio".
>> - gpios : should specify GPIOs used for SDA and SCL lines, in that order.
>> - sda-is-open-drain : should be non-zero if SDA gpio is open-drain.
>> - sda-enforce-dir : should be non-zero if SDA gpio must be configured for
>>input before reading and for output before writing.
>> - scl-is-open-drain : should be non-zero if SCL gpio is open-drain.
>> - scl-is-output-only : should be non-zero if SCL is an output gpio only.
> 
> Instead of looking for a value in these properties, just make them
> empty properties and change behaviour based on whether or not the
> property is present.
> 

It seems reasonable. Thanks.

> Why is the scl-is-output-only property needed?
> 

It is needed to specify that the I2C master can't honour clock stretching done 
by I2C slave devices, as it cannot read back SCL.

>> - udelay : signal toggle delay. SCL frequency is (500 / udelay) kHz
> 
> You should follow the lead of
> Documentation/powerpc/dts-bindings/fsl/i2c.txt here and specify a
> clock-frequency property.
> 

Ok.

>> - timeout : clock stretching timeout in milliseconds.
> 
> I don't understand what this property means.
> 

It is the maximum time that the I2C master should wait for SCL to go high when 
a I2C slave is "clock-stretching".

Cheers,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko

[Arnd Bergmann]

On Monday 23 November 2009 19:10:55 Albert Herranz wrote:
> 
> Arnd Bergmann wrote:
> > On Sunday 22 November 2009, Albert Herranz wrote:
> >> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
> >> +setup_usbgecko_bat:
> >> +/* prepare a BAT for early io */
> >> +lis r8, 0x0c00
> >> +ori r8, r8, 0x002a  /* uncached, guarded ,rw */
> >> +lis r11, 0xcc00
> >> +ori r11, r11, 0x3   /* 128K */
> >> +#ifdef CONFIG_WII
> >> +orisr8, r8, 0x0100
> >> +orisr11, r11, 0x0100
> >> +#endif
> >> +mtspr   SPRN_DBAT1L, r8
> >> +mtspr   SPRN_DBAT1U, r11
> >> +sync
> >> +isync
> >> +blr
> >> +#endif
> > 
> > This will probably break other platforms if CONFIG_PPC_EARLY_DEBUG_USBGECKO
> > is set. In general, we try hard to make it possible to build generic
> > kernels for multiple systems, so it would be better to also add a runtime
> > check here.
> > 
> 
> Ok, I see the point.
> But, what makes CONFIG_PPC_EARLY_DEBUG_USBGECKO case different from 
> CONFIG_PPC_EARLY_DEBUG_CPM case here?
> 

I looked again, and the help text for PPC_EARLY_DEBUG makes it very clear that
are never usable on a production kernel. Just leave your code the way it is 
here,
but if there are other places that prevent portable kernels, those should be 
fixed.
I'm not aware of any of those right now.

Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Fix DEBUG_HIGHMEM build break from d4515646699

[Becky Bruce]

Code was added to mm/higmem.c that depends on several
kmap types that powerpc does not support.  We add dummy
invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.

According to list discussion, this fix should not be needed
anymore starting with 2.6.33.  The code is commented to this
effect so hopefully we will remember to remove this.

Signed-off-by: Becky Bruce 
---
 arch/powerpc/include/asm/kmap_types.h |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kmap_types.h 
b/arch/powerpc/include/asm/kmap_types.h
index b6bac6f..9163695 100644
--- a/arch/powerpc/include/asm/kmap_types.h
+++ b/arch/powerpc/include/asm/kmap_types.h
@@ -29,5 +29,16 @@ enum km_type {
KM_TYPE_NR
 };
 
+/*
+ * This is a temporary build fix that (so they say on lkml) should no 
longer
+ * be required after 2.6.33, because of changes planned to the kmap code.
+ * Let's try to remove this cruft then.
+ */
+#ifdef CONFIG_DEBUG_HIGHMEM
+#define KM_NMI (-1)
+#define KM_NMI_PTE (-1)
+#define KM_IRQ_PTE (-1)
+#endif
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_KMAP_TYPES_H */
-- 
1.6.0.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] [PPC4xx] Fix device tree dts file for katmai board.

[Pravin Bathija]

 Description: Set PCI-E node inbound DMA ranges size to 4GB for correct
 boot up of katmai. Including only changes for PCI-E DMA ranges as
 suggested by Stefan.

Signed-off-by: Pravin Bathija 
Acked-by: Feng Kan 
Acked-by: Prodyut Hazarika 
Acked-by: Loc Ho 
Acked-by: Tirumala Reddy Marri 
Acked-by: Victor Gallardo 
---
 arch/powerpc/boot/dts/katmai.dts |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 077819b..d2595b2 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -245,8 +245,8 @@
ranges = <0x0200 0x 0x8000 0x000d 
0x8000 0x 0x8000
  0x0100 0x 0x 0x000c 
0x0800 0x 0x0001>;
 
-   /* Inbound 2GB range starting at 0 */
-   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000>;
+   /* Inbound 4GB range starting at 0 */
+   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x1 
0x>;
 
/* This drives busses 0 to 0xf */
bus-range = <0x0 0xf>;
@@ -289,10 +289,10 @@
ranges = <0x0200 0x 0x8000 0x000e 
0x 0x 0x8000
  0x0100 0x 0x 0x000f 
0x8000 0x 0x0001>;
 
-   /* Inbound 2GB range starting at 0 */
-   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000>;
+   /* Inbound 4GB range starting at 0 */
+   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x1 
0x>;
 
-   /* This drives busses 10 to 0x1f */
+   /* This drives busses 0x10 to 0x1f */
bus-range = <0x10 0x1f>;
 
/* Legacy interrupts (note the weird polarity, the 
bridge seems
@@ -330,10 +330,10 @@
ranges = <0x0200 0x 0x8000 0x000e 
0x8000 0x 0x8000
  0x0100 0x 0x 0x000f 
0x8001 0x 0x0001>;
 
-   /* Inbound 2GB range starting at 0 */
-   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000>;
+   /* Inbound 4GB range starting at 0 */
+   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x1 
0x>;
 
-   /* This drives busses 10 to 0x1f */
+   /* This drives busses 0x20 to 0x2f */
bus-range = <0x20 0x2f>;
 
/* Legacy interrupts (note the weird polarity, the 
bridge seems
@@ -371,10 +371,10 @@
ranges = <0x0200 0x 0x8000 0x000f 
0x 0x 0x8000
  0x0100 0x 0x 0x000f 
0x8002 0x 0x0001>;
 
-   /* Inbound 2GB range starting at 0 */
-   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000>;
+   /* Inbound 4GB range starting at 0 */
+   dma-ranges = <0x4200 0x0 0x0 0x0 0x0 0x1 
0x>;
 
-   /* This drives busses 10 to 0x1f */
+   /* This drives busses 0x30 to 0x3f */
bus-range = <0x30 0x3f>;
 
/* Legacy interrupts (note the weird polarity, the 
bridge seems
-- 
1.5.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 14/19] powerpc: allow ioremap within reserved fake ram regions

[Michael Ellerman]

On Mon, 2009-11-23 at 21:16 +0100, Albert Herranz wrote:
> >>  arch/powerpc/mm/pgtable_32.c |   19 ---
> >>  1 files changed, 16 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> >> index cb96cb2..ba00cb1 100644
> >> --- a/arch/powerpc/mm/pgtable_32.c
> >> +++ b/arch/powerpc/mm/pgtable_32.c
> >> @@ -191,9 +191,22 @@ __ioremap_caller(phys_addr_t addr, unsigned long 
> >> size, unsigned long flags,
> >> * Don't allow anybody to remap normal RAM that we're using.
> >> * mem_init() sets high_memory so only do the check after that.
> >> */
> >> -   if (mem_init_done && (p < virt_to_phys(high_memory))) {
> >> -   printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
> >> -  (unsigned long long)p, __builtin_return_address(0));
> >> +   if (mem_init_done && (p < virt_to_phys(high_memory))
> >> +#ifdef CONFIG_WII
> >> +   /*
> >> +* On some systems, though, we may want to remap an area
> >> +* declared as normal RAM that we have memreserve'd at the
> >> +* device tree. See wii.dts.
> >> +* But we can't do that safely if we are using BATs to map
> >> +* part of that area.
> >> +*/
> >> +   && !__map_without_bats
> >> +#endif
> >> +   ) {
> >> +   printk(KERN_WARNING
> >> +  "__ioremap(): phys addr 0x%llx is RAM lr %p\n",
> >> +  (unsigned long long)p,
> >> +__builtin_return_address(0));
> > 
> > This could adversely affect multiplatform kernels.  I'd rather get the
> > RAM problem fixed and not hack up common code to work around the hack.
> > 
> > g.
> > 
> 
> Would it be acceptable to create a global var __allow_ioremap_normal_ram that 
> by default would have a value of 0 and would be set _only_ for those 
> platforms needing it?
> 
> The other solutions I see is:
> - add support for discontiguous memory to powerpc 32-bits (which is not 
> something that I can look into now)
> - don't use the precious second 64MB area (which is a waste)

- Implement your own ppc_md.ioremap(), see iseries & cell for example.

Currently that's only called on 64-bit, but you could change that.

If I'm reading your patch right, you should be able to do that check in
your platform's ioremap() and then call the generic implementation to do
the actual work.

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits

[Segher Boessenkool]

Hi Albert,


+asm ("\n\



A file scope asm?!  Please don't.

+ * We enter with the cache enabled, the MMU enabled and some known  
legacy

+ * memory mappings active. xBAT3 is unused


It would be good if you could depend as little as possible on these  
things;

that makes writing another bootloader a lot easier.


+   /* IBAT3,DBAT3 for first 16Mbytes */\n\
+   li  8, 0x01ff   /* 16MB */\n\
+   li  9, 0x0002   /* rw */\n\
+   mtspr   0x216, 8/* IBAT3U */\n\
+   mtspr   0x217, 9/* IBAT3L */\n\
+   mtspr   0x21e, 8/* DBAT3U */\n\
+   mtspr   0x21f, 9/* DBAT3L */\n\


WIMG=, are you sure?  Not M=1?


+   bcl-20,4*cr7+so,1f\n\


Just write  bcl 20,31,1f .


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [Cbe-oss-dev] [PATCH] spufs: Fix test in spufs_switch_log_read()

[Jeremy Kerr]

Roel,

> size_t len cannot be less than 0.
> 
> Signed-off-by: Roel Kluin 

Acked-by: Jeremy Kerr 

Thanks!

Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 05/19] powerpc: wii: bootwrapper bits

[Segher Boessenkool]

+ * We enter with an unknown cache, high BATs and MMU status.


What does this mean?  You know the low four BATs on entry and
nothing else?


+asm ("\n\


Global asm() is evil.


+   mfmsr   9\n\
+   andi.   0, 9, (1<<4)|(1<<5) /* MSR_DR|MSR_IR */\n\



+   andc9, 9, 0\n\


mfmsr 9 ; rlwinm 9,9,0,~0x30 ?


+   mtspr   0x01a, 8/* SRR0 */\n\
+   mtspr   0x01b, 9/* SRR1 */\n\


mtsrr0 and mtsrr1


+   sync\n\
+   rfi\n\


No need for sync before rfi


+   mtspr   0x210, 8/* IBAT0U */\n\
+   mtspr   0x211, 8/* IBAT0L */\n\


You only need to set the upper BAT to zero, saves some code.


+   isync\n\


isync here is cargo cult


+   li  8, 0x01ff   /* first 16MiB */\n\
+   li  9, 0x0002   /* rw */\n\
+   mtspr   0x210, 8/* IBAT0U */\n\
+   mtspr   0x211, 9/* IBAT0L */\n\
+   mtspr   0x218, 8/* DBAT0U */\n\
+   mtspr   0x219, 9/* DBAT0L */\n\


M=0 for RAM?





Also, you should normally write the lower BAT first.  Doesn't matter
here because IR=DR=0 of course.


+   lis 8, 0xcc00   /* I/O mem */\n\
+   ori 8, 8, 0x3ff /* 32MiB */\n\
+   lis 9, 0x0c00\n\
+   ori 9, 9, 0x002a/* uncached, guarded, rw */\n\
+   mtspr   0x21a, 8/* DBAT1U */\n\
+   mtspr   0x21b, 9/* DBAT1L */\n\


Is there any real reason you don't identity map this?


+   sync\n\
+   isync\n\
+\n\


Don't need these


+   /* enable high BATs */\n\
+   lis 8, 0x8200\n\
+   mtspr   0x3f3, 8/* HID4 */\n\


You need to use read-modify-write here.  Also, shouldn't you
enable the extra BATs before setting them?

And you _do_ need isync here as far as I can see.


+   /* enable caches */\n\
+   mfspr   8, 0x3f0\n\
+   ori 8, 8, 0xc000\n\
+   mtspr   0x3f0, 8/* HID0 */\n\
+   isync\n\


You need to invalidate the L1 caches at the same time as you enable
them.

+void platform_init(unsigned long r3, unsigned long r4, unsigned  
long r5)

+{
+   u32 heapsize = 24*1024*1024 - (u32)_end;
+
+   simple_alloc_init(_end, heapsize, 32, 64);
+   fdt_init(_dtb_start);
+
+   if (!ug_grab_io_base() && ug_is_adapter_present())


The "!" reads weird.  Can you not make ug_is_adapter_present()
call ug_grab_io_base(), anyway?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 06/19] powerpc: gamecube/wii: introduce GAMECUBE_COMMON

[Segher Boessenkool]

Add a config option GAMECUBE_COMMON to be used as a dependency for all
options common to the Nintendo GameCube and Wii video game consoles.


Maybe something like GAMECUBE_OR_WII instead?  "COMMON" is so
common it's meaningless.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko

[Segher Boessenkool]

+ If you say yes to this option, support will be included for the
+ USB Gecko adapter as an udbg console.
+ The USB Gecko is a EXI to USB Serial converter that can be plugged
+ into a memcard slot in the Nintendo GameCube/Wii.


Not "a" memcard slot, only the first one, you have it hardcoded.


+#if 0
+/*
+ * Trasmits a null terminated character string.
+ */
+static void ug_puts(char *s)
+{
+   while (*s)
+   ug_putc(*s++);
+}
+#endif


Remove?


+   stdout = of_find_node_by_path(path);
+   if (!stdout) {
+   udbg_printf("%s: missing path %s", __func__, path);
+   goto done;
+   }
+
+   for (np = NULL;
+   (np = of_find_compatible_node(np, NULL, "usbgecko,usbgecko"));)
+   if (np == stdout)
+   break;
+
+   of_node_put(stdout);
+   if (!np) {
+   udbg_printf("%s: stdout is not an usbgecko", __func__);
+   goto done;
+   }


Surely there is something called something like of_node_is_compatible()
you can use here?  You already have the node pointer, there is no need
to look at all other nodes.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko

[Segher Boessenkool]

You set up DBAT1 here...


+setup_usbgecko_bat:
+   /* prepare a BAT for early io */
+   lis r8, 0x0c00
+   ori r8, r8, 0x002a  /* uncached, guarded ,rw */
+   lis r11, 0xcc00
+   ori r11, r11, 0x3   /* 128K */
+#ifdef CONFIG_WII
+   orisr8, r8, 0x0100
+   orisr11, r11, 0x0100
+#endif
+   mtspr   SPRN_DBAT1L, r8
+   mtspr   SPRN_DBAT1U, r11
+   sync
+   isync
+   blr


... and again here:


+void __init udbg_init_usbgecko(void)
+{
+   unsigned long vaddr, paddr;
+
+#if defined(CONFIG_GAMECUBE)
+   paddr = 0x0c00;
+#elif defined(CONFIG_WII)
+   paddr = 0x0d00;
+#else
+#error Invalid platform for USB Gecko based early debugging.
+#endif
+
+   vaddr = 0xc000 | paddr;
+   setbat(1, vaddr, paddr, 128*1024, PAGE_KERNEL_NCG);


Do you need to do it twice?


+   ug_io_base = (void __iomem *)(vaddr | 0x6814);


Oh, hardcoded slot2, now i'm confused which one should be it :-)


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] zlib: Optimize inffast when copying direct from output

[Benjamin Herrenschmidt]

On Tue, 2009-11-10 at 10:00 +0100, Joakim Tjernlund wrote:
> JFFS2 uses lesser compression ratio and inflate always
> ends up in "copy direct from output" case.
> This patch tries to optimize the direct copy procedure.
> Uses get_unaligned() but only in one place.
> The copy loop just above this one can also use this
> optimization, but I havn't done so as I have not tested if it
> is a win there too.
> On my MPC8321 this is about 17% faster on my JFFS2 root FS
> than the original.
> ---
> 
>  Would like some testing of the PowerPC boot wrapper and
>  a LE target before sending it upstream.

Well, you should probably submit that patch to lkml then :-)

I'm not sure its going to work to use get_unaligned() like that on all
archs .. it might be definitely something to discuss on some more
appropriate mailing list.

Cheers,
Ben.

>  arch/powerpc/boot/Makefile |4 ++-
>  lib/zlib_inflate/inffast.c |   48 +--
>  2 files changed, 40 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 9ae7b7e..98e4c4f 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -20,7 +20,7 @@
>  all: $(obj)/zImage
>  
>  BOOTCFLAGS:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> -  -fno-strict-aliasing -Os -msoft-float -pipe \
> +  -fno-strict-aliasing -Os -msoft-float -pipe -D__KERNEL__\
>-fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
>-isystem $(shell $(CROSS32CC) -print-file-name=include)
>  BOOTAFLAGS   := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
> @@ -34,6 +34,8 @@ BOOTCFLAGS  += -fno-stack-protector
>  endif
>  
>  BOOTCFLAGS   += -I$(obj) -I$(srctree)/$(obj)
> +BOOTCFLAGS   += -include include/linux/autoconf.h -Iarch/powerpc/include
> +BOOTCFLAGS   += -Iinclude
>  
>  DTS_FLAGS?= -p 1024
>  
> diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
> index 8550b0c..0c7fa3d 100644
> --- a/lib/zlib_inflate/inffast.c
> +++ b/lib/zlib_inflate/inffast.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include "inftrees.h"
>  #include "inflate.h"
>  #include "inffast.h"
> @@ -24,9 +25,11 @@
>  #ifdef POSTINC
>  #  define OFF 0
>  #  define PUP(a) *(a)++
> +#  define UP_UNALIGNED(a) get_unaligned((a)++)
>  #else
>  #  define OFF 1
>  #  define PUP(a) *++(a)
> +#  define UP_UNALIGNED(a) get_unaligned(++(a))
>  #endif
>  
>  /*
> @@ -239,18 +242,41 @@ void inflate_fast(z_streamp strm, unsigned start)
>  }
>  }
>  else {
> + unsigned short *sout;
> + unsigned long loops;
> +
>  from = out - dist;  /* copy direct from output */
> -do {/* minimum length is three */
> -PUP(out) = PUP(from);
> -PUP(out) = PUP(from);
> -PUP(out) = PUP(from);
> -len -= 3;
> -} while (len > 2);
> -if (len) {
> -PUP(out) = PUP(from);
> -if (len > 1)
> -PUP(out) = PUP(from);
> -}
> +/* minimum length is three */
> + /* Align out addr */
> + if (!((long)(out - 1 + OFF)) & 1) {
> + PUP(out) = PUP(from);
> + len--;
> + }
> + sout = (unsigned short *)(out - OFF);
> + if (dist > 2 ) {
> + unsigned short *sfrom;
> +
> + sfrom = (unsigned short *)(from - OFF);
> + loops = len >> 1;
> + do
> + PUP(sout) = UP_UNALIGNED(sfrom);
> + while (--loops);
> + out = (unsigned char *)sout + OFF;
> + from = (unsigned char *)sfrom + OFF;
> + } else { /* dist == 1 or dist == 2 */
> + unsigned short pat16;
> +
> + pat16 = *(sout-2+2*OFF);
> + if (dist == 1)
> + pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8);
> + loops = len >> 1;
> + do
> + PUP(sout) = pat16;
> + while (--loops);
> + out = (unsigned char *)sout + OFF;
> + }
> + if (len & 1)
> + PUP(out) = PUP(from);
>  }
>  }
>  else if ((op & 64) == 0) {  /* 2nd level distance code */


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v5 0/4] pseries: Add cede support for cpu-offline

[Benjamin Herrenschmidt]

On Fri, 2009-10-30 at 10:52 +0530, Gautham R Shenoy wrote:
> Hi,
> 
> This is version 5 of patch series that provides a framework to choose the
> state a pseries CPU must be put to when it is offlined.
> 
> Previous versions can be found here:
> Version 4: http://lkml.org/lkml/2009/10/9/59
> Version 3: http://lkml.org/lkml/2009/9/15/164
> Version 2: http://lkml.org/lkml/2009/8/28/102
> Version 1: http://lkml.org/lkml/2009/8/6/236
> 
> Changes from the previous version include:
> - Rebased against Nathan Fontenot's latest "pseries kernel handling of dynamic
>   logical paritioning v4" patches found here:
>   http://lkml.org/lkml/2009/10/21/98

I can't merge them right now because afaik, Nathan patches are still not
quite ready. So we need to either get a final version of Nathan patches
something like tomorrow or you need to rebase your series on current
-next by the end of the week, or I'm afraid it's going to miss the next
merge window.

Cheers,
Ben.

> - Added boot-time option to disable putting the offlined vcpus into an
>   extended H_CEDE state.
> 
> - Addressed Ben's comments regarding the if-else sequencing in
>   pseries_mach_cpu_die().
> 
> - Addition of comments for pseries_cpu_die() to distinguish it from
>   pseries_mach_cpu_die()
> 
> Also,
> 
> - This approach addresses Peter Z's objections regarding layering
>   violations. The user simply offlines the cpu and doesn't worry about what
>   state the CPU should be put into. That part is automatically handled by the
>   kernel.
> 
> - It does not add any additional sysfs interface instead uses the existing
>   sysfs interface to offline CPUs.
> 
> - On platforms which do not have support for ceding the vcpu with a
>   latency specifier value, the offlining mechanism defaults to the current
>   method of calling rtas_stop_self().
> 
> The patchset has been tested on the available pseries platforms and it works
> as per the expectations. I believe that the patch set is ready for inclusion.
> ---
> 
> Gautham R Shenoy (4):
>   pseries: Serialize cpu hotplug operations during deactivate Vs 
> deallocate
>   pseries: Add code to online/offline CPUs of a DLPAR node.
>   pSeries: Add hooks to put the CPU into an appropriate offline state
>   pSeries: extended_cede_processor() helper function.
> 
> 
>  Documentation/cpu-hotplug.txt   |6 +
>  arch/powerpc/include/asm/lppaca.h   |9 +
>  arch/powerpc/platforms/pseries/dlpar.c  |  129 
>  arch/powerpc/platforms/pseries/hotplug-cpu.c|  182 
> ++-
>  arch/powerpc/platforms/pseries/offline_states.h |   18 ++
>  arch/powerpc/platforms/pseries/plpar_wrappers.h |   22 +++
>  arch/powerpc/platforms/pseries/smp.c|   19 ++
>  arch/powerpc/xmon/xmon.c|3 
>  drivers/base/cpu.c  |2 
>  include/linux/cpu.h |   13 ++
>  10 files changed, 387 insertions(+), 16 deletions(-)
>  create mode 100644 arch/powerpc/platforms/pseries/offline_states.h
> 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on

[Paul Mackerras]

Neil Horman writes:

>   Before anyone flames me for what a oddball solution this is, let me just
> say I'm trying to get the ball rolling here.  I think there may be better
> solutions that can be impemented in reloc_64.S, but I've yet to make any of 
> the
> ones I've tried work successfully.  I'm open to suggestions, but this solution
> is the only one so far that I've been able to get to work. thanks :)

I had thought that the CRCs would be the only things with reloc
addends less than 4G, but it turns out that the toolchain folds
expressions like __pa(&sym) into just a load from a doubleword (in the
TOC) containing the physical address of sym.  That needs to be
relocated and its reloc addend will be less than 4GB.  Hence the
crashes early in boot that you were seeing with my proposed patch to
reloc_64.S.

Given that, your solution seems as reasonable as any.  Should this go
via the modules maintainer, Rusty Russell, perhaps?

In any case,

Acked-by: Paul Mackerras 

> Adjust crcs in __kcrctab_* sections if relocs are used with CONFIG_RELOCATABLE
> 
> When CONFIG_MODVERSIONS and CONFIG_RELOCATABLE are enabled on powerpc 
> platforms,
> kdump has been failing in a rather odd way.  specifically modules will not
> install.  This is because when validating the crcs of symbols that the module
> needs, the crc of the module never matches the crc that is stored in the 
> kernel.
> 
> The underlying cause of this is how CONFIG_MODVERSIONS is implemented, and how
> CONFIG_RELOCATABLE are implemented.  with CONFIG_MODVERSIONS enabled, for 
> every
> exported symbol in the kernel we emit 2 symbols, __crc_#sym which is declared
> extern and __kcrctab_##sym, which is placed in the __kcrctab section of the
> binary.  The latter has its value set equal to the address of the former
> (recalling it is declared extern).  After the object file is built, genksyms 
> is
> run on the processed source, and crcs are computed for each exported symbol.
> genksyms then emits a linker script which defines each of the needed 
> __crc_##sym
> symbols, and sets their addresses euqal to their respective crcs.  This script
> is then used in a secondary link to the previously build object file, so that
> the crcs of the missing symbol can be validated on module insert.
> 
> The problem here is that because __kcrctab_sym is set equal to &__crc_##sym, a
> relocation entry is emitted by the compiler for the __kcrctab__##sym.  
> Normally
> this is not a problem, since relocation on other arches is done without the 
> aid
> of .rel.dyn sections.  PPC however uses these relocations when
> CONFIG_RELOCATABLE is enabled.  nominally, since addressing starts at 0 for 
> ppc,
> its irrelevant, but if we start at a non-zero address (like we do when booting
> via kexec from reserved crashkernel memory), the ppc boot code iterates over 
> the
> relocation entries, and winds up adding that relocation offset to all symbols,
> including the symbols that are actually the aforementioned crc values in the
> __kcrctab_* sections.  This effectively corrupts the crcs and prevents any
> module loads from happening during a kdump.
> 
> My solution is to 'undo' these relocations prior to boot up.  If
> ARCH_USES_RELOC_ENTRIES is defined, we add a symbol at address zero to the
> linker script for that arch (I call it reloc_start, so that &reloc_start = 0).
> This symbol will then indicate the relocation offset for any given boot.  We
> also add an initcall to the module code that, during boot, scans the 
> __kcrctab_*
> sections and subtracts &reloc_start from every entry in those sections,
> restoring the appropriate crc value.
> 
> I've verified that this allows kexec to work properly on ppc64 systems myself.
> 
> Signed-off-by: Neil Horman 
> 
> 
>  arch/powerpc/include/asm/local.h  |6 ++
>  arch/powerpc/kernel/vmlinux.lds.S |4 
>  kernel/module.c   |   30 ++
>  3 files changed, 40 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/local.h 
> b/arch/powerpc/include/asm/local.h
> index 84b457a..9cc49e5 100644
> --- a/arch/powerpc/include/asm/local.h
> +++ b/arch/powerpc/include/asm/local.h
> @@ -4,6 +4,12 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_MODVERSIONS
> +#define ARCH_USES_RELOC_ENTRIES
> +
> +extern unsigned long reloc_start;
> +#endif
> +
>  typedef struct
>  {
>   atomic_long_t a;
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
> b/arch/powerpc/kernel/vmlinux.lds.S
> index 27735a7..2b9fb2e 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -38,6 +38,10 @@ jiffies = jiffies_64 + 4;
>  #endif
>  SECTIONS
>  {
> + . = 0;
> + reloc_start = .;
> + . = 0;
> +
>   . = KERNELBASE;
>  
>  /*
> diff --git a/kernel/module.c b/kernel/module.c
> index 8b7d880..87a4928 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -181,8 +181,11 @@ extern const struct kernel_symbol 
> __stop___ksymtab_gpl_future[];
>  extern 

Re: [PATCH v5 0/4] pseries: Add cede support for cpu-offline

[Vaidyanathan Srinivasan]

* Benjamin Herrenschmidt  [2009-11-24 14:35:09]:

> On Fri, 2009-10-30 at 10:52 +0530, Gautham R Shenoy wrote:
> > Hi,
> > 
> > This is version 5 of patch series that provides a framework to choose the
> > state a pseries CPU must be put to when it is offlined.
> > 
> > Previous versions can be found here:
> > Version 4: http://lkml.org/lkml/2009/10/9/59
> > Version 3: http://lkml.org/lkml/2009/9/15/164
> > Version 2: http://lkml.org/lkml/2009/8/28/102
> > Version 1: http://lkml.org/lkml/2009/8/6/236
> > 
> > Changes from the previous version include:
> > - Rebased against Nathan Fontenot's latest "pseries kernel handling of 
> > dynamic
> >   logical paritioning v4" patches found here:
> >   http://lkml.org/lkml/2009/10/21/98
> 
> I can't merge them right now because afaik, Nathan patches are still not
> quite ready. So we need to either get a final version of Nathan patches
> something like tomorrow or you need to rebase your series on current
> -next by the end of the week, or I'm afraid it's going to miss the next
> merge window.

Hi Ben,

I had checked with Nathan earlier and he mentioned that he is working
on an update.  We can post a rebase to -next tomorrow, but this series
depends on Nathan's patch, hence will work with him. This feature is
important for the next merge window.

Thanks,
Vaidy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 7/8] spi_mpc8xxx: Turn qe_mode into flags

[Benjamin Herrenschmidt]

On Thu, 2009-11-05 at 07:47 -0600, Kumar Gala wrote:
> On Oct 12, 2009, at 11:49 AM, Anton Vorontsov wrote:
> 
> > Soon there will be more flags introduced in subsequent patches, so
> > let's turn qe_mode into flags.
> >
> > Also introduce mpc8xxx_spi_strmode() and print current SPI mode.
> >
> > Signed-off-by: Anton Vorontsov 
> > Acked-by: David Brownell 
> > ---
> > drivers/spi/spi_mpc8xxx.c   |   30 +++---
> > include/linux/fsl_devices.h |2 +-
> > 2 files changed, 20 insertions(+), 12 deletions(-)
> 
> applied to next

This patch breaks my 6xx config:

/home/benh/linux-powerpc-test/arch/powerpc/platforms/83xx/mpc832x_rdb.c: In 
function ‘of_fsl_spi_probe’:
/home/benh/linux-powerpc-test/arch/powerpc/platforms/83xx/mpc832x_rdb.c:77: 
error: ‘struct fsl_spi_platform_data’ has no member named ‘qe_

The reason is that the mpc832x_rdb.c code still uses the legacy probing
method. The fix is not totally trivial as the new flags are defined inside
spi_mpc8xxx.c so either the flags need to be moved to fsl_devices.h or
mpc832x_rdb.c needs to be converted to new style stuff.

I'll commit (will be up later today in my next branch) a fix moving the
flags over for now so the tree doesn't break building.

If you are going to keep the flags in the .c file you probably also want
to remove the platform device definition from fsl_devices.h anyways as
there's no point exposing to the world a structure with a "flags" member
if the definition of those flags isn't also exposed.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT

[David Gibson]

Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
the latter's cleverly hidden technique of adding some extra allocation
space to the top level page directory to store the extra information
it needs.

Since that extra allocation really doesn't fit into the cleaned up
page directory allocating scheme, this patch alters
CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
subpage_prot_table as part of the mm_context_t.

Signed-off-by: David Gibson 

Index: working-2.6/arch/powerpc/include/asm/mmu-hash64.h
===
--- working-2.6.orig/arch/powerpc/include/asm/mmu-hash64.h  2009-11-24 
13:00:07.076303532 +1100
+++ working-2.6/arch/powerpc/include/asm/mmu-hash64.h   2009-11-24 
13:37:49.216303709 +1100
@@ -373,6 +373,38 @@ extern void slb_set_size(u16 size);
 
 #ifndef __ASSEMBLY__
 
+#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];
+};
+
+#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(struct mm_struct *mm);
+extern void subpage_prot_init_new_context(struct mm_struct *mm);
+#else
+static inline void subpage_prot_free(pgd_t *pgd) {}
+static inline void subpage_prot_init_new_context(struct mm_struct *mm) { }
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
+
 typedef unsigned long mm_context_id_t;
 
 typedef struct {
@@ -386,6 +418,9 @@ typedef struct {
u16 sllp;   /* SLB page size encoding */
 #endif
unsigned long vdso_base;
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+   struct subpage_prot_table spt;
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
 } mm_context_t;
 
 
Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
===
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h  2009-11-24 
12:58:25.616303379 +1100
+++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h   2009-11-24 
14:04:25.752332450 +1100
@@ -28,10 +28,6 @@
  */
 #define MAX_PGTABLE_INDEX_SIZE 0xf
 
-#ifndef CONFIG_PPC_SUBPAGE_PROT
-static inline void subpage_prot_free(pgd_t *pgd) {}
-#endif
-
 extern struct kmem_cache *pgtable_cache[];
 #define PGT_CACHE(shift) (pgtable_cache[(shift)-1])
 
@@ -42,7 +38,6 @@ static inline pgd_t *pgd_alloc(struct mm
 
 static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
 {
-   subpage_prot_free(pgd);
kmem_cache_free(PGT_CACHE(PGD_INDEX_SIZE), pgd);
 }
 
Index: working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h
===
--- working-2.6.orig/arch/powerpc/include/asm/pte-hash64-64k.h  2009-11-24 
12:58:54.332307997 +1100
+++ working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h   2009-11-24 
13:04:10.261303844 +1100
@@ -76,41 +76,4 @@
remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE,\
__pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
 
-
-#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_CO

Fix bug in gup_hugepd()

[David Gibson]

Commit a4fe3ce7699bfe1bd88f816b55d42d8fe1dac655 introduced a new
get_user_pages() path for hugepages on powerpc.  Unfortunately, there
is a bug in it's loop logic, which can cause it to overrun the end of
the intended region.  This came about by copying the logic from the
normal page path, which assumes the address and end parameters have
been pagesize aligned at the top-level.  Since they're not *hugepage*
size aligned, the simplistic logic could step over the end of the gup
region without triggering the loop end condition.

This patch fixes the bug by using the technique that the normal page
path uses in levels above the lowest to truncate the ending address to
something we know we'll match with.

Signed-off-by: David Gibson 

Index: working-2.6/arch/powerpc/mm/hugetlbpage.c
===
--- working-2.6.orig/arch/powerpc/mm/hugetlbpage.c  2009-11-24 
14:25:36.488330625 +1100
+++ working-2.6/arch/powerpc/mm/hugetlbpage.c   2009-11-24 15:55:27.296455938 
+1100
@@ -436,18 +436,27 @@ static noinline int gup_hugepte(pte_t *p
return 1;
 }
 
+static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
+ unsigned long sz)
+{
+   unsigned long __boundary = (addr + sz) & ~(sz-1);
+   return (__boundary - 1 < end - 1) ? __boundary : end;
+}
+
 int gup_hugepd(hugepd_t *hugepd, unsigned pdshift,
   unsigned long addr, unsigned long end,
   int write, struct page **pages, int *nr)
 {
pte_t *ptep;
unsigned long sz = 1UL << hugepd_shift(*hugepd);
+   unsigned long next;
 
ptep = hugepte_offset(hugepd, addr, pdshift);
do {
+   next = hugepte_addr_end(addr, end, sz);
if (!gup_hugepte(ptep, sz, addr, end, write, pages, nr))
return 0;
-   } while (ptep++, addr += sz, addr != end);
+   } while (ptep++, addr = next, addr != end);
 
return 1;
 }


-- 
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Fix bug in gup_hugepd()

[Stephen Rothwell]

Hi David,

On Tue, 24 Nov 2009 17:03:40 +1100 David Gibson  
wrote:
>
> Commit a4fe3ce7699bfe1bd88f816b55d42d8fe1dac655 introduced a new

When you quote a SHA1, please also quote the summary line for the commit
so those without git access may find it.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpq4zYEKL3gr.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT

[Sachin Sant]

David Gibson wrote:

Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
the latter's cleverly hidden technique of adding some extra allocation
space to the top level page directory to store the extra information
it needs.

Since that extra allocation really doesn't fit into the cleaned up
page directory allocating scheme, this patch alters
CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
subpage_prot_table as part of the mm_context_t.

Signed-off-by: David Gibson 

Thanks David for the patch. With this patch on top of next-20091123
my test machine boots fine. 


Regards
-Sachin

--

-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] PPC: Sync guest visible MMU state

[Alexander Graf]

Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.

This patch exports enough of the MMU segment state to userspace to make
debugging work and thus also includes the groundwork for migration.

Signed-off-by: Alexander Graf 
---
 arch/powerpc/include/asm/kvm.h|   20 -
 arch/powerpc/include/asm/kvm_asm.h|1 +
 arch/powerpc/include/asm/kvm_book3s.h |3 ++
 arch/powerpc/kvm/book3s.c |   47 +
 arch/powerpc/kvm/book3s_64_emulate.c  |   38 --
 arch/powerpc/kvm/book3s_64_mmu.c  |2 +
 arch/powerpc/kvm/powerpc.c|3 ++
 include/linux/kvm.h   |1 +
 8 files changed, 98 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index c9ca97f..bc0aeba 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,8 +46,24 @@ struct kvm_regs {
 };
 
 struct kvm_sregs {
-   __u32 pvr;
-   char pad[1020];
+   union {
+   struct {
+   __u32 pvr;
+   __u64 sdr1;
+   struct {
+   struct {
+   __u64 slbe;
+   __u64 slbv;
+   } slb[64];
+   } ppc64;
+   struct {
+   __u32 sr[16];
+   __u64 ibat[8]; 
+   __u64 dbat[8]; 
+   } ppc32;
+   };
+   __u8 pad[1024];
+   };
 };
 
 struct kvm_fpu {
diff --git a/arch/powerpc/include/asm/kvm_asm.h 
b/arch/powerpc/include/asm/kvm_asm.h
index 19ddb35..af2abe7 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -87,6 +87,7 @@
 #define BOOK3S_IRQPRIO_MAX 16
 
 #define BOOK3S_HFLAG_DCBZ320x1
+#define BOOK3S_HFLAG_SLB   0x2
 
 #define RESUME_FLAG_NV  (1<<0)  /* Reload guest nonvolatile state? */
 #define RESUME_FLAG_HOST(1<<1)  /* Resume host? */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index c601133..74b7369 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -46,6 +46,7 @@ struct kvmppc_sr {
 };
 
 struct kvmppc_bat {
+   u64 raw;
u32 bepi;
u32 bepi_mask;
bool vs;
@@ -113,6 +114,8 @@ extern struct kvmppc_pte *kvmppc_mmu_find_pte(struct 
kvm_vcpu *vcpu, u64 ea, boo
 extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr, 
bool data);
 extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong eaddr, int size, void *ptr);
 extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int 
vec);
+extern void kvmppc_set_bat(struct kvm_vcpu *vcpu, struct kvmppc_bat *bat,
+  bool upper, u32 val);
 
 extern u32 kvmppc_trampoline_lowmem;
 extern u32 kvmppc_trampoline_enter;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 42037d4..650ebf8 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -281,6 +281,7 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
 
 void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
 {
+   vcpu->arch.hflags &= ~BOOK3S_HFLAG_SLB;
vcpu->arch.pvr = pvr;
if ((pvr >= 0x33) && (pvr < 0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
@@ -762,14 +763,60 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
 int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
   struct kvm_sregs *sregs)
 {
+   int i;
+
sregs->pvr = vcpu->arch.pvr;
+
+   sregs->sdr1 = to_book3s(vcpu)->sdr1;
+   if (vcpu->arch.hflags & BOOK3S_HFLAG_SLB) {
+   for (i = 0; i < 64; i++) {
+   sregs->ppc64.slb[i].slbe = 
to_book3s(vcpu)->slb[i].orige | i;
+   sregs->ppc64.slb[i].slbv = 
to_book3s(vcpu)->slb[i].origv;
+   }
+   } else {
+   for (i = 0; i < 16; i++) {
+   sregs->ppc32.sr[i] = to_book3s(vcpu)->sr[i].raw;
+   sregs->ppc32.sr[i] = to_book3s(vcpu)->sr[i].raw;
+   }
+   for (i = 0; i < 8; i++) {
+   sregs->ppc32.ibat[i] = to_book3s(vcpu)->ibat[i].raw;
+   sregs->ppc32.dbat[i] = to_book3s(vcpu)->dbat[i].raw;
+   }
+   }
return 0;
 }
 
 int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
   struct kvm_sregs *sregs)
 {
+   int i;
+