* QUICC Engine USB Host controller
From: Guilherme Maciel Ferreira @ 2012-06-12 22:26 UTC (permalink / raw)
To: linuxppc-dev
Hi guys,
I'm struggling to make the QUICC engine USB host controller to work.
Thus, I came here in the hope to get some light =3D)
I am working on MPC8321 processor and kernel 2.6.32. Comparing against
the mainstream version, I applied some patches to fix some p=C5=95oblems in
the FHCI driver, then it got running.
Now, it seems that the driver detects a new device, but is not able to
get its description. I'm aware that the driver uses the timer to
synchronize its packets exchange, but I couldn't find the proper timer
clock frequency. I've already tried every value I could derive from
the documentation, once as long as I am concerned there is no way to
measure it.
Here follows a relevant dmesg USB driver output, where there is a timeout e=
rror:
[ 24.396373] usbcore: registered new interface driver usbfs
[ 24.405860] usbcore: registered new interface driver hub
[ 24.414642] usbcore: registered new device driver usb
[ 24.706132] fsl,usb-fhci e01006c0.usb: at 0xcbaf66c0, irq 23
[ 24.721953] fsl,usb-fhci e01006c0.usb: FHCI HOST Controller
[ 24.734528] fsl,usb-fhci e01006c0.usb: new USB bus registered,
assigned bus number 1
[ 24.745942] fsl,usb-fhci e01006c0.usb: irq 23, io mem 0x00000000
[ 24.853738] usb usb1: New USB device found, idVendor=3D1d6b, idProduct=
=3D0001
[ 24.860623] usb usb1: New USB device strings: Mfr=3D3, Product=3D2,
SerialNumber=3D1
[ 24.867902] usb usb1: Product: FHCI HOST Controller
[ 24.872836] usb usb1: Manufacturer: Linux 2.6.32 fsl,usb-fhci
[ 24.878633] usb usb1: SerialNumber: e01006c0.usb
[ 24.937686] usb usb1: configuration #1 chosen from 1 choice
[ 24.957830] hub 1-0:1.0: USB hub found
[ 24.968867] hub 1-0:1.0: 1 port detected
[ 25.367766] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 2
[ 25.531795] usb 1-1: device descriptor read/64, error -110
[ 25.787864] usb 1-1: device descriptor read/64, error -110
[ 26.024464] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 3
[ 26.199736] usb 1-1: device descriptor read/64, error -110
[ 26.455838] usb 1-1: device descriptor read/64, error -110
[ 26.688100] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 4
[ 27.123765] usb 1-1: device not accepting address 4, error -110
[ 27.271797] usb 1-1: new full speed USB device using fsl,usb-fhci
and address 5
[ 27.712333] usb 1-1: device not accepting address 5, error -110
[ 27.735892] hub 1-0:1.0: unable to enumerate USB device on port 1
And here follows a snippet from my device tree:
qe@e0100000 {
#address-cells =3D <1>;
#size-cells =3D <1>;
device_type =3D "qe";
compatible =3D "fsl,qe";
reg =3D <0xe0100000 0x480>;
ranges =3D <0x0 0xe0100000 0x100000>;
brg-frequency =3D <0>;
bus-frequency =3D <0>;
timer@440 {
compatible =3D "fsl,mpc8321-qe-gtm",
"fsl,mpc8360-qe-gtm",
"fsl,qe-gtm", "fsl,gtm";
reg =3D <0x440 0x40>; // 64 bytes @ offset 0x000440
interrupts =3D <12 13 14 15>;
interrupt-parent =3D <&qeic>;
clock-frequency =3D <100000000>; // 100 MHz???
};
usb@6C0 {
#address-cells =3D <1>;
#size-cells =3D <0>;
compatible =3D "fsl,mpc8321-qe-usb",
"fsl,mpc8323-qe-usb",
"fsl,mpc8360-qe-usb";
reg =3D <0x6c0 0x40 0x700 0x100>;
interrupts =3D <11>;
interrupt-parent =3D <&qeic>;
mode =3D "host";
fsl,fullspeed-clock =3D "clk3";
hub-power-budget =3D "100";
gpios =3D <
&qe_pio_a 8 0 // USBOE
&qe_pio_a 1 0 // USBTXP
&qe_pio_a 0 0 // USBTXN
&qe_pio_a 4 0 // USBRXP
&qe_pio_a 5 0 // USBRXN
&qe_pio_d 21 1 // SPEED
&qe_pio_d 25 0 // POWER/SUSPEND
>;
};
};
Thanks in advance for anyone willing to help me.
Best regards,
--=20
Guilherme Maciel Ferreira
Site: http://guilhermemacielferreira.com/
^ permalink raw reply
* [PATCH] powerpc/booke-64: fix tlbsrx. path in bolted tlb handler
From: Scott Wood @ 2012-06-12 22:02 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
It was branching to the cleanup part of the non-bolted handler,
which would have been bad if there were any chips with tlbsrx.
that use the bolted handler.
Signed-off-by: Scott Wood <scott@tyr.buserror.net>
---
arch/powerpc/mm/tlb_low_64e.S | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index ff672bd..efe0f33 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -128,7 +128,7 @@ BEGIN_MMU_FTR_SECTION
*/
PPC_TLBSRX_DOT(0,r16)
ldx r14,r14,r15 /* grab pgd entry */
- beq normal_tlb_miss_done /* tlb exists already, bail */
+ beq tlb_miss_done_bolted /* tlb exists already, bail */
MMU_FTR_SECTION_ELSE
ldx r14,r14,r15 /* grab pgd entry */
ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_USE_TLBRSRV)
@@ -184,6 +184,7 @@ ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_USE_TLBRSRV)
mtspr SPRN_MAS7_MAS3,r15
tlbwe
+tlb_miss_done_bolted:
TLB_MISS_STATS_X(MMSTAT_TLB_MISS_NORM_OK)
tlb_epilog_bolted
rfi
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2] usb: fsl_udc: errata - postpone freeing current dTD
From: Christoph Fritz @ 2012-06-12 19:40 UTC (permalink / raw)
To: Fabio Estevam
Cc: Ben Dooks, Chen Peter-B29397, Nicolas Ferre, Hans J. Koch,
Kukjin Kim, Russell King, Thomas Dahlmann, Sascha Hauer,
Christian Hemp, Haojian Zhuang, Daniel Mack, Neil Zhang,
linux-arm-kernel, Oliver Neukum, Eric Miao, Li Yang-R58472,
Greg Kroah-Hartman, linux-usb@vger.kernel.org, Felipe Balbi,
Ido Shayevitz, Estevam Fabio-R49496,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOMZO5B7+Qy06m7O=v1M3vt7to7ciKOhQOihVgAEf+utntvw4w@mail.gmail.com>
Hi Fabio
On Sun, 2012-06-10 at 15:41 -0300, Fabio Estevam wrote:
> Hi Christoph,
>
> On Mon, Jun 4, 2012 at 8:37 AM, Christoph Fritz
> <chf.fritz@googlemail.com> wrote:
>
> > After that, I stumbled upon this dmesg:
> >
> > Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)
> > fsl-usb2-udc fsl-usb2-udc: clk_get("usb") failed
> > fsl-usb2-udc: probe of fsl-usb2-udc failed with error -2
> >
> > Sascha, could you give me a hint?
>
> Does the patch below fix your problem?
Thanks for your patch. It does indeed load
"Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007)"
fine - but now when I want to use it:
modprobe g_ether
[ 17.099363] g_ether gadget: using random self ethernet address
[ 17.105316] g_ether gadget: using random host ethernet address
[ 17.111974] usb0: MAC 1a:c7:9e:76:cc:45
[ 17.115866] usb0: HOST MAC 66:a2:4a:0a:46:17
[ 17.120199] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[ 17.126861] g_ether gadget: g_ether ready
these are "the last words": System hangs completely. Same behavior with
g_serial (these two I've tested).
Currently I can't investigate this further, not because of a bug - but a
flu.
Thanks,
-- Christoph
^ permalink raw reply
* Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
From: Oleg Nesterov @ 2012-06-12 17:43 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: peterz, antonb, lkml, Jim Keniston, Paul Mackerras, Ingo Molnar,
linuxppc-dev
In-Reply-To: <20120612165404.GB30555@linux.vnet.ibm.com>
On 06/12, Srikar Dronamraju wrote:
> >
> > Note also that we should move this !UPROBE_COPY_INSN from
> > install_breakpoint() to somewhere near alloc_uprobe(). This code
> > is called only once, it looks a bit strange to use the "random" mm
> > (the first mm vma_prio_tree_foreach() finds) and its mapping to
> > verify the insn. In fact this is simply not correct and should be
> > fixed, note that on x86 arch_uprobe_analyze_insn() checks
>
> The reason we "delay" the copy_insn to the first insert is because
> we have to get access to mm. For archs like x86, we want to know if the
> executable is 32 bit or not
Yes. And this is wrong afaics.
Once again. This !UPROBE_COPY_INSN code is called only once, and it
uses the "random" mm. After that install_breakpoint() just calls
set_swbp(another_mm) while the insn can be invalid because
another_mm->ia32_compat != mm->ia32_compat.
> So in effect, if we get access to
> struct file corresponding to the inode and if the inode corresponds to
> 32 bit executable file or 64 bit executable file during register, then
> we can move it around alloc_uprobe().
I don't think this can work. I have another simple fix in mind, I'll
write another email later.
Oleg.
^ permalink raw reply
* RE: reserving memory using OF rsvmap feature?
From: Joakim Tjernlund @ 2012-06-12 17:20 UTC (permalink / raw)
To: Jenkins, Clive; +Cc: linuxppc-dev
In-Reply-To: <929D3CED81F34E43887A393170D66FB9065B79F5@GBRSUN01MS002.eu.xerox.net>
"Jenkins, Clive" <Clive.Jenkins@xerox.com> wrote on 2012/06/12 17:48:15:
>
> > Is it possible to reserve some memory using OF rsvmap such that Linux
> > will not touch this area at all? Think of is as warm start stash area
> > were one could store data which should survive a reboot.
>
> Yes, I guess it should be possible, but you need to take care where you
> place this block so it does not get overwritten during the boot process.
> This depends on how your bootloader is set up to place images in memory,
> decompress them etc.
>
> I don't know about OF, but in U-Boot use the function fdt_add_mem_rsv()
> in file
> http://git.denx.de/?p=u-boot.git;a=blob;f=lib/libfdt/fdt_rw.c
>
> // Reserve the memory location of the framebuffer + descriptor page.
> if (fdt_add_mem_rsv(working_fdt, fbinfo->smem_start,
> (fbinfo->smem_len + 0x1FFF) & 0xFFFFF000))
> printf("ERROR: could not reserve FB memory in device tree\n");
>
> In my powerpc_e500v2 systems this block is located at 64MiB
> (0x04000000).
Thanks, this was what I was looking at too. I plan to use u-boots PRAM feature
and reserve memory at the end of RAM.
Jocke
^ permalink raw reply
* Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
From: Srikar Dronamraju @ 2012-06-12 16:54 UTC (permalink / raw)
To: Oleg Nesterov
Cc: peterz, antonb, lkml, Jim Keniston, Paul Mackerras, Ingo Molnar,
linuxppc-dev
In-Reply-To: <20120611161215.GA12116@redhat.com>
>
> Well, IMHO, this is confusing.
>
> First of all, why do we have this "addr" or even "vaddr"? It should
> not exists. We pass it to copy_insn(), but for what?? copy_insn()
> should simply use uprobe->offset, the virtual address for this
> particular mapping does not matter at all. I am going to send
> the cleanup.
>
Yes, we can use uprobe->offset instead of vaddr/addr.
> Note also that we should move this !UPROBE_COPY_INSN from
> install_breakpoint() to somewhere near alloc_uprobe(). This code
> is called only once, it looks a bit strange to use the "random" mm
> (the first mm vma_prio_tree_foreach() finds) and its mapping to
> verify the insn. In fact this is simply not correct and should be
> fixed, note that on x86 arch_uprobe_analyze_insn() checks
The reason we "delay" the copy_insn to the first insert is because
we have to get access to mm. For archs like x86, we want to know if the
executable is 32 bit or not (since we have a different valid set of
instructions for 32 bit and 64 bit). So in effect, if we get access to
struct file corresponding to the inode and if the inode corresponds to
32 bit executable file or 64 bit executable file during register, then
we can move it around alloc_uprobe().
^ permalink raw reply
* RE: reserving memory using OF rsvmap feature?
From: Jenkins, Clive @ 2012-06-12 15:48 UTC (permalink / raw)
To: Joakim Tjernlund, linuxppc-dev
In-Reply-To: <OFDFDC3B6C.CE37E2BC-ONC1257A1A.00698754-C1257A1A.0069E657@transmode.se>
> Is it possible to reserve some memory using OF rsvmap such that Linux
> will not touch this area at all? Think of is as warm start stash area
> were one could store data which should survive a reboot.
Yes, I guess it should be possible, but you need to take care where you
place this block so it does not get overwritten during the boot process.
This depends on how your bootloader is set up to place images in memory,
decompress them etc.
I don't know about OF, but in U-Boot use the function fdt_add_mem_rsv()
in file
http://git.denx.de/?p=3Du-boot.git;a=3Dblob;f=3Dlib/libfdt/fdt_rw.c
// Reserve the memory location of the framebuffer + descriptor page.
if (fdt_add_mem_rsv(working_fdt, fbinfo->smem_start,
(fbinfo->smem_len + 0x1FFF) & 0xFFFFF000))
printf("ERROR: could not reserve FB memory in device tree\n");
In my powerpc_e500v2 systems this block is located at 64MiB
(0x04000000).
Clive
^ permalink raw reply
* RE: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx SoC and Bluestone board
From: Vinh Huu Tuong Nguyen @ 2012-06-12 10:26 UTC (permalink / raw)
To: Vinh Huu Tuong Nguyen, Benjamin Herrenschmidt, Paul Mackerras,
Josh Boyer, Matt Porter, Grant Likely, Rob Herring, Duc Dang,
David S. Miller, Kumar Gala, Li Yang, Ashish Kalra,
Anatolij Gustschin, Liu Gang, linuxppc-dev, linux-kernel,
devicetree-discuss
In-Reply-To: <1336362768-31326-1-git-send-email-vhtnguyen@apm.com>
> -----Original Message-----
> From: Vinh Nguyen Huu Tuong [mailto:vhtnguyen@apm.com]
> Sent: Monday, May 07, 2012 10:53 AM
> To: Benjamin Herrenschmidt; Paul Mackerras; Josh Boyer; Matt Porter;
> Grant Likely; Rob Herring; Duc Dang; David S. Miller; Kumar Gala; Li
> Yang; Ashish Kalra; Anatolij Gustschin; Liu Gang; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; devicetree-
> discuss@lists.ozlabs.org
> Cc: Vinh Nguyen Huu Tuong
> Subject: [PATCH] powerpc/44x: Support OCM(On Chip Memory) for APM821xx
> SoC and Bluestone board
>
> This patch consists of:
> - Add driver for OCM component
> - Export OCM Information at /sys/class/ocm/ocminfo
>
> Signed-off-by: Vinh Nguyen Huu Tuong <vhtnguyen@apm.com>
> ---
> arch/powerpc/boot/dts/bluestone.dts | 8 +
> arch/powerpc/include/asm/ppc4xx_ocm.h | 47 ++++
> arch/powerpc/platforms/44x/Kconfig | 8 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/ppc4xx_ocm.c | 420
> +++++++++++++++++++++++++++++++++
> 5 files changed, 484 insertions(+), 0 deletions(-) create mode 100644
> arch/powerpc/include/asm/ppc4xx_ocm.h
> create mode 100644 arch/powerpc/sysdev/ppc4xx_ocm.c
>
> diff --git a/arch/powerpc/boot/dts/bluestone.dts
> b/arch/powerpc/boot/dts/bluestone.dts
> index 7bda373..2687c11 100644
> --- a/arch/powerpc/boot/dts/bluestone.dts
> +++ b/arch/powerpc/boot/dts/bluestone.dts
> @@ -107,6 +107,14 @@
> interrupt-parent = <&UIC0>;
> };
>
> + OCM1: ocm@400040000 {
> + compatible = "ibm,ocm";
> + status = "ok";
> + cell-index = <1>;
> + /* configured in U-Boot */
> + reg = <4 0x00040000 0x8000>; /* 32K */
> + };
> +
> SDR0: sdr {
> compatible = "ibm,sdr-apm821xx";
> dcr-reg = <0x00e 0x002>;
> diff --git a/arch/powerpc/include/asm/ppc4xx_ocm.h
> b/arch/powerpc/include/asm/ppc4xx_ocm.h
> new file mode 100644
> index 0000000..ff7f386
> --- /dev/null
> +++ b/arch/powerpc/include/asm/ppc4xx_ocm.h
> @@ -0,0 +1,47 @@
> +/*
> + * PowerPC 4xx OCM memory allocation support
> + *
> + * (C) Copyright 2009, Applied Micro Circuits Corporation
> + * Victor Gallardo (vgallardo@amcc.com)
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __ASM_POWERPC_PPC4xx_OCM_H__
> +#define __ASM_POWERPC_PPC4xx_OCM_H__
> +
> +#include <linux/types.h>
> +
> +#define OCM_NON_CACHED 0
> +#define OCM_CACHED 1
> +
> +#if defined(CONFIG_PPC4xx_OCM)
> +
> +void *ocm_alloc(phys_addr_t *phys, int size, int align,
> + int flags, const char *owner);
> +void ocm_free(const void *virt);
> +
> +#else
> +
> +#define ocm_alloc(phys, size, align, flags, owner) NULL
> +#define ocm_free(addr) ((void)0)
> +
> +#endif /* CONFIG_PPC4xx_OCM */
> +
> +#endif /* __ASM_POWERPC_PPC4xx_OCM_H__ */
> diff --git a/arch/powerpc/platforms/44x/Kconfig
> b/arch/powerpc/platforms/44x/Kconfig
> index 2e4e64a..6b1a64e 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -250,6 +250,14 @@ config PPC4xx_GPIO
> help
> Enable gpiolib support for ppc440 based boards
>
> +config PPC4xx_OCM
> + bool "PPC4xx On Chip Memory (OCM) support"
> + depends on 4xx
> + select PPC_LIB_RHEAP
> + help
> + Enable OCM support for PowerPC 4xx platforms with on chip
> memory,
> + OCM provides the fast place for memory access to improve
> performance.
> +
> # 44x specific CPU modules, selected based on the board above.
> config 440EP
> bool
> diff --git a/arch/powerpc/sysdev/Makefile
> b/arch/powerpc/sysdev/Makefile index 1bd7ecb..6f768e2 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
> obj-$(CONFIG_PPC_I8259) += i8259.o
> obj-$(CONFIG_IPIC) += ipic.o
> obj-$(CONFIG_4xx) += uic.o
> +obj-$(CONFIG_PPC4xx_OCM) += ppc4xx_ocm.o
> obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
> obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
> obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c
> b/arch/powerpc/sysdev/ppc4xx_ocm.c
> new file mode 100644
> index 0000000..ba3e450
> --- /dev/null
> +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
> @@ -0,0 +1,420 @@
> +/*
> + * PowerPC 4xx OCM memory allocation support
> + *
> + * (C) Copyright 2009, Applied Micro Circuits Corporation
> + * Victor Gallardo (vgallardo@amcc.com)
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/proc_fs.h>
> +#include <linux/seq_file.h>
> +#include <linux/spinlock.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/list.h>
> +#include <asm/uaccess.h>
> +#include <asm/prom.h>
> +#include <asm/dcr.h>
> +#include <asm/rheap.h>
> +#include <asm/mmu.h>
> +#include <asm/ppc4xx_ocm.h>
> +#include <linux/export.h>
> +
> +#define OCM_DISABLED 0
> +#define OCM_ENABLED 1
> +
> +struct ocm_block {
> + struct list_head list;
> + void __iomem *addr;
> + int size;
> + const char *owner;
> +};
> +
> +/* non-cached or cached region */
> +struct ocm_region {
> + phys_addr_t phys;
> + void __iomem *virt;
> +
> + int memtotal;
> + int memfree;
> +
> + rh_info_t *rh;
> + struct list_head list;
> +};
> +
> +struct ocm_info {
> + int index;
> + int status;
> + int ready;
> +
> + phys_addr_t phys;
> +
> + int alignment;
> + int memtotal;
> + int cache_size;
> +
> + struct ocm_region nc; /* non-cached region */
> + struct ocm_region c; /* cached region */
> +};
> +
> +static struct ocm_info *ocm_nodes;
> +static int ocm_count;
> +
> +static struct ocm_info *ocm_get_node(unsigned int index) {
> + if (index >= ocm_count) {
> + printk(KERN_ERR "OCM: invalid index");
> + return NULL;
> + }
> +
> + return &ocm_nodes[index];
> +}
> +
> +void *ocm_alloc(phys_addr_t *phys, int size, int align,
> + int flags, const char *owner)
> +{
> + void __iomem *addr = NULL;
> + unsigned long offset;
> + struct ocm_info *ocm;
> + struct ocm_region *ocm_reg;
> + struct ocm_block *ocm_blk;
> + int i;
> +
> + for (i = 0; i < ocm_count; i++) {
> + ocm = ocm_get_node(i);
> +
> + if (!ocm || !ocm->ready)
> + continue;
> +
> + if (flags == OCM_NON_CACHED)
> + ocm_reg = &ocm->nc;
> + else
> + ocm_reg = &ocm->c;
> +
> + if (!ocm_reg->virt)
> + continue;
> +
> + if (align < ocm->alignment)
> + align = ocm->alignment;
> +
> + offset = rh_alloc_align(ocm_reg->rh, size, align, NULL);
> +
> + if (IS_ERR_VALUE(offset))
> + continue;
> +
> + ocm_blk = kzalloc(sizeof(struct ocm_block *), GFP_KERNEL);
> + if (!ocm_blk) {
> + printk(KERN_ERR "OCM: could not allocate ocm
block");
> + rh_free(ocm_reg->rh, offset);
> + break;
> + }
> +
> + *phys = ocm_reg->phys + offset;
> + addr = ocm_reg->virt + offset;
> + size = ALIGN(size, align);
> +
> + ocm_blk->addr = addr;
> + ocm_blk->size = size;
> + ocm_blk->owner = owner;
> + list_add_tail(&ocm_blk->list, &ocm_reg->list);
> +
> + ocm_reg->memfree -= size;
> +
> + break;
> + }
> +
> + return addr;
> +}
> +
> +static int ocm_free_region(struct ocm_region *ocm_reg, const void
> +*addr) {
> + struct ocm_block *blk, *tmp;
> + unsigned long offset;
> +
> + if (!ocm_reg->virt)
> + return 0;
> +
> + list_for_each_entry_safe(blk, tmp, &ocm_reg->list, list) {
> + if (blk->addr == addr) {
> + offset = addr - ocm_reg->virt;
> + ocm_reg->memfree += blk->size;
> + rh_free(ocm_reg->rh, offset);
> + list_del(&blk->list);
> + kfree(blk);
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +
> +void ocm_free(const void *addr)
> +{
> + int i;
> +
> + if (!addr)
> + return;
> +
> + for (i = 0; i < ocm_count; i++) {
> + struct ocm_info *ocm = ocm_get_node(i);
> +
> + if (!ocm || !ocm->ready)
> + continue;
> +
> + if (ocm_free_region(&ocm->nc, addr) ||
> + ocm_free_region(&ocm->c, addr))
> + return;
> + }
> +}
> +
> +static void __init ocm_init_node(int count, struct device_node *node)
> {
> + struct ocm_info *ocm;
> +
> + const unsigned int *cell_index;
> + const unsigned int *cache_size;
> + int len;
> +
> + struct resource rsrc;
> + int ioflags;
> +
> + ocm = ocm_get_node(count);
> +
> + cell_index = of_get_property(node, "cell-index", &len);
> + if (!cell_index) {
> + printk(KERN_ERR "OCM: missing cell-index property");
> + return;
> + }
> + ocm->index = *cell_index;
> +
> + if (of_device_is_available(node))
> + ocm->status = OCM_ENABLED;
> +
> + cache_size = of_get_property(node, "cached-region-size", &len);
> + if (cache_size)
> + ocm->cache_size = *cache_size;
> +
> + if (of_address_to_resource(node, 0, &rsrc)) {
> + printk(KERN_ERR "OCM%d: could not get resource address\n",
> + ocm->index);
> + return;
> + }
> +
> + ocm->phys = rsrc.start;
> + ocm->memtotal = (rsrc.end - rsrc.start + 1);
> +
> + printk(KERN_INFO "OCM%d: %d Bytes (%s)\n",
> + ocm->index, ocm->memtotal,
> + (ocm->status == OCM_DISABLED) ? "disabled" : "enabled");
> +
> + if (ocm->status == OCM_DISABLED)
> + return;
> +
> + /* request region */
> +
> + if (!request_mem_region(ocm->phys, ocm->memtotal, "ppc4xx_ocm"))
> {
> + printk(KERN_ERR "OCM%d: could not request region\n",
> + ocm->index);
> + return;
> + }
> +
> + /* Configure non-cached and cached regions */
> +
> + ocm->nc.phys = ocm->phys;
> + ocm->nc.memtotal = ocm->memtotal - ocm->cache_size;
> + ocm->nc.memfree = ocm->nc.memtotal;
> +
> + ocm->c.phys = ocm->phys + ocm->nc.memtotal;
> + ocm->c.memtotal = ocm->cache_size;
> + ocm->c.memfree = ocm->c.memtotal;
> +
> + if (ocm->nc.memtotal == 0)
> + ocm->nc.phys = 0;
> +
> + if (ocm->c.memtotal == 0)
> + ocm->c.phys = 0;
> +
> + printk(KERN_INFO "OCM%d: %d Bytes (non-cached)\n",
> + ocm->index, ocm->nc.memtotal);
> +
> + printk(KERN_INFO "OCM%d: %d Bytes (cached)\n",
> + ocm->index, ocm->c.memtotal);
> +
> + /* ioremap the non-cached region */
> + if (ocm->nc.memtotal) {
> + ioflags = _PAGE_NO_CACHE | _PAGE_GUARDED | _PAGE_EXEC;
> + ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
> + ioflags);
> +
> + if (!ocm->nc.virt) {
> + printk(KERN_ERR
> + "OCM%d: failed to ioremap non-cached
> memory\n",
> + ocm->index);
> + ocm->nc.memfree = 0;
> + return;
> + }
> + }
> +
> + /* ioremap the cached region */
> +
> + if (ocm->c.memtotal) {
> + ioflags = _PAGE_EXEC;
> + ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
> + ioflags);
> +
> + if (!ocm->c.virt) {
> + printk(KERN_ERR
> + "OCM%d: failed to ioremap cached memory\n",
> + ocm->index);
> + ocm->c.memfree = 0;
> + return;
> + }
> + }
> +
> + /* Create Remote Heaps */
> +
> + ocm->alignment = 4; /* default 4 byte alignment */
> +
> + if (ocm->nc.virt) {
> + ocm->nc.rh = rh_create(ocm->alignment);
> + rh_attach_region(ocm->nc.rh, 0, ocm->nc.memtotal);
> + }
> +
> + if (ocm->c.virt) {
> + ocm->c.rh = rh_create(ocm->alignment);
> + rh_attach_region(ocm->c.rh, 0, ocm->c.memtotal);
> + }
> +
> + INIT_LIST_HEAD(&ocm->nc.list);
> + INIT_LIST_HEAD(&ocm->c.list);
> +
> + ocm->ready = 1;
> +
> + return;
> +}
> +
> +static ssize_t ocm_sysfs_show(struct class *class,
> + struct class_attribute *attr, char *buf) {
> + struct ocm_block *blk, *tmp;
> + unsigned int count, i;
> +
> + count = 0;
> + for (i = 0; i < ocm_count; i++) {
> + struct ocm_info *ocm = ocm_get_node(i);
> +
> + if (!ocm || !ocm->ready)
> + continue;
> +
> + count += sprintf(buf + count, "OCM : %d\n",
> + ocm->index);
> + count += sprintf(buf + count, "PhysAddr : 0x%llx\n",
> + ocm->phys);
> + count += sprintf(buf + count, "MemTotal : %d Bytes\n",
> + ocm->memtotal);
> + count += sprintf(buf + count, "MemTotal(NC) : %d Bytes\n",
> + ocm->nc.memtotal);
> + count += sprintf(buf + count, "MemTotal(C) : %d Bytes\n",
> + ocm->c.memtotal);
> +
> + count += sprintf(buf + count, "\n");
> +
> + count += sprintf(buf + count, "NC.PhysAddr : 0x%llx\n",
> + ocm->nc.phys);
> + count += sprintf(buf + count, "NC.VirtAddr : 0x%p\n",
> + ocm->nc.virt);
> + count += sprintf(buf + count, "NC.MemTotal : %d Bytes\n",
> + ocm->nc.memtotal);
> + count += sprintf(buf + count, "NC.MemFree : %d Bytes\n",
> + ocm->nc.memfree);
> +
> + list_for_each_entry_safe(blk, tmp, &ocm->nc.list, list) {
> + count += sprintf(buf + count, "NC.MemUsed : %d
> Bytes (%s)\n",
> + blk->size,
blk->owner);
> + }
> +
> + count += sprintf(buf + count, "\n");
> +
> + count += sprintf(buf + count, "C.PhysAddr : 0x%llx\n",
> + ocm->c.phys);
> + count += sprintf(buf + count, "C.VirtAddr : 0x%p\n",
> + ocm->c.virt);
> + count += sprintf(buf + count, "C.MemTotal : %d Bytes\n",
> + ocm->c.memtotal);
> + count += sprintf(buf + count, "C.MemFree : %d Bytes\n",
> + ocm->c.memfree);
> +
> + list_for_each_entry_safe(blk, tmp, &ocm->c.list, list) {
> + count += sprintf(buf + count, "C.MemUsed : %d
> Bytes (%s)\n",
> + blk->size, blk->owner);
> + }
> +
> + count += sprintf(buf + count, "\n");
> + }
> +
> + return count;
> +}
> +
> +static struct class *mem_class;
> +
> +static CLASS_ATTR(ocminfo, S_IRUGO, ocm_sysfs_show, NULL);
> +
> +static int ocm_sysfs_init(void)
> +{
> + mem_class = class_create(THIS_MODULE, "ocm");
> + if (IS_ERR(mem_class))
> + return PTR_ERR(mem_class);
> +
> + return class_create_file(mem_class, &class_attr_ocminfo); }
> +
> +static int __init ocm_init(void)
> +{
> + struct device_node *np;
> + int count;
> +
> + count = 0;
> + for_each_compatible_node(np, NULL, "ibm,ocm")
> + count++;
> +
> + if (!count)
> + return 0;
> +
> + ocm_nodes = kzalloc((count * sizeof(struct ocm_info)),
> GFP_KERNEL);
> + if (!ocm_nodes) {
> + printk(KERN_ERR "OCM: failed to allocate OCM nodes!\n");
> + return -ENOMEM;
> + }
> +
> + ocm_count = count;
> + count = 0;
> +
> + for_each_compatible_node(np, NULL, "ibm,ocm") {
> + ocm_init_node(count, np);
> + count++;
> + }
> +
> + ocm_sysfs_init();
> +
> + return 0;
> +}
> +
> +arch_initcall(ocm_init);
> --
> 1.7.2.5
Hi all reviewers,
One month pass from the day I sent out this patch, but I didn't receive
any comments from you. Could you please do me a favor to take a look on it
and give me your advices?
Best regards,
Vinh Nguyen.
^ permalink raw reply
* [PATCH] arch/powerpc/: fix kernel-doc warning
From: Wanpeng Li @ 2012-06-12 5:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Wanpeng Li, Wanpeng Li, linuxppc-dev, linux-kernel, Gavin Shan
From: Wanpeng Li <liwp@linux.vnet.ibm.com>
Warning(arch/powerpc/kernel/pci_of_scan.c:210): Excess function parameter 'node' description in 'of_scan_pci_bridge'
Warning(arch/powerpc/kernel/vio.c:636): No description found for parameter 'desired'
Warning(arch/powerpc/kernel/vio.c:636): Excess function parameter 'new_desired' description in 'vio_cmo_set_dev_desired'
Warning(arch/powerpc/kernel/vio.c:1270): No description found for parameter 'viodrv'
Warning(arch/powerpc/kernel/vio.c:1270): Excess function parameter 'drv' description in '__vio_register_driver'
Warning(arch/powerpc/kernel/vio.c:1289): No description found for parameter 'viodrv'
Warning(arch/powerpc/kernel/vio.c:1289): Excess function parameter 'driver' description in 'vio_unregister_driver'
Signed-off-by: Wanpeng Li <liwp@linux.vnet.ibm.com>
---
arch/powerpc/kernel/pci_of_scan.c | 1 -
arch/powerpc/kernel/vio.c | 6 +++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 89dde17..d7dd42b 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -198,7 +198,6 @@ EXPORT_SYMBOL(of_create_pci_dev);
/**
* of_scan_pci_bridge - Set up a PCI bridge and scan for child nodes
- * @node: device tree node of bridge
* @dev: pci_dev structure for the bridge
*
* of_scan_bus() calls this routine for each PCI bridge that it finds, and
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index cb87301..06cbc30 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -625,7 +625,7 @@ struct dma_map_ops vio_dma_mapping_ops = {
* vio_cmo_set_dev_desired - Set desired entitlement for a device
*
* @viodev: struct vio_dev for device to alter
- * @new_desired: new desired entitlement level in bytes
+ * @desired: new desired entitlement level in bytes
*
* For use by devices to request a change to their entitlement at runtime or
* through sysfs. The desired entitlement level is changed and a balancing
@@ -1262,7 +1262,7 @@ static int vio_bus_remove(struct device *dev)
/**
* vio_register_driver: - Register a new vio driver
- * @drv: The vio_driver structure to be registered.
+ * @viodrv: The vio_driver structure to be registered.
*/
int __vio_register_driver(struct vio_driver *viodrv, struct module *owner,
const char *mod_name)
@@ -1282,7 +1282,7 @@ EXPORT_SYMBOL(__vio_register_driver);
/**
* vio_unregister_driver - Remove registration of vio driver.
- * @driver: The vio_driver struct to be removed form registration
+ * @viodrv: The vio_driver struct to be removed form registration
*/
void vio_unregister_driver(struct vio_driver *viodrv)
{
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/2] [POWERPC] uprobes: powerpc port
From: Ananth N Mavinakayanahalli @ 2012-06-12 4:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jim Keniston, Srikar Dronamraju, Peter Zijlstra, oleg, lkml,
Paul Mackerras, Anton Blanchard, Ingo Molnar, linuxppc-dev
In-Reply-To: <1339473706.14757.14.camel@concordia>
On Tue, Jun 12, 2012 at 02:01:46PM +1000, Michael Ellerman wrote:
> On Fri, 2012-06-08 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jun 08, 2012 at 04:38:17PM +1000, Michael Ellerman wrote:
> > > On Fri, 2012-06-08 at 11:49 +0530, Ananth N Mavinakayanahalli wrote:
> > > > On Fri, Jun 08, 2012 at 04:17:44PM +1000, Michael Ellerman wrote:
> > > > > On Fri, 2012-06-08 at 11:31 +0530, Ananth N Mavinakayanahalli wrote:
> > > > > > On Fri, Jun 08, 2012 at 03:51:54PM +1000, Michael Ellerman wrote:
> > > > > > > On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli wrote:
> > > > > >
> > > > > > But MSR_PR=1 and hence emulate_step() will return -1 and hence we will
> > > > > > end up single-stepping using user_enable_single_step(). Same with rfid.
> > > > >
> > > > > Right. But that was exactly Jim's point, you may be asked to emulate
> > > > > those instructions even though you wouldn't expect to see them in
> > > > > userspace code, so you need to handle it.
> > > > >
> > > > > Luckily it looks like emulate_step() will do the right thing for you.
> > > > > It'd be good to test it to make 100% sure.
> > > >
> > > > Sure. Will add that check and send v2.
> > >
> > > Sorry I didn't mean add a test in the code, I meant construct a test
> > > case to confirm that it works as expected.
> >
> > Michael,
> >
> > I just hand-coded the instr to emulate_step() and here are the results:
> >
> > MSR_PR is set
> > insn = 7c600124, ret = 0 /* mtmsr */
> > insn = 7c600164, ret = 0 /* mtmsrd */
> > insn = 4c000024, ret = -1 /* rfid */
> > insn = 4c000064, ret = 0 /* rfi */
> >
> > Also verified that standalone programs with those instructions in inline
> > asm will die with a SIGILL.
> >
> > So, for mtmsr, mtmsrd and rfi, we have to single-step them which will
> > result in a SIGILL in turn.
>
> What happens in the rfid case? You don't handle -1 from emulate_step()
> any differently AFAICS, so don't we try to single step that too?
-1 is just emulate_step() flagging cases where instructions must not be
single-stepped (rfi[d], mtmsr that clears MSR_RI). But as with the other
OEA instructions in user space, we fail with a SIGILL.
As the application is hozed in any case if we encounter an OEA
instruction, I'd think there is no point in handling a -1 from
emulate_step() any differently.
Ananth
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] uprobes: powerpc port
From: Michael Ellerman @ 2012-06-12 4:01 UTC (permalink / raw)
To: ananth
Cc: Jim Keniston, Srikar Dronamraju, Peter Zijlstra, oleg, lkml,
Paul Mackerras, Anton Blanchard, Ingo Molnar, linuxppc-dev
In-Reply-To: <20120608092104.GF13409@in.ibm.com>
On Fri, 2012-06-08 at 14:51 +0530, Ananth N Mavinakayanahalli wrote:
> On Fri, Jun 08, 2012 at 04:38:17PM +1000, Michael Ellerman wrote:
> > On Fri, 2012-06-08 at 11:49 +0530, Ananth N Mavinakayanahalli wrote:
> > > On Fri, Jun 08, 2012 at 04:17:44PM +1000, Michael Ellerman wrote:
> > > > On Fri, 2012-06-08 at 11:31 +0530, Ananth N Mavinakayanahalli wrote:
> > > > > On Fri, Jun 08, 2012 at 03:51:54PM +1000, Michael Ellerman wrote:
> > > > > > On Fri, 2012-06-08 at 10:06 +0530, Ananth N Mavinakayanahalli wrote:
> > > > >
> > > > > But MSR_PR=1 and hence emulate_step() will return -1 and hence we will
> > > > > end up single-stepping using user_enable_single_step(). Same with rfid.
> > > >
> > > > Right. But that was exactly Jim's point, you may be asked to emulate
> > > > those instructions even though you wouldn't expect to see them in
> > > > userspace code, so you need to handle it.
> > > >
> > > > Luckily it looks like emulate_step() will do the right thing for you.
> > > > It'd be good to test it to make 100% sure.
> > >
> > > Sure. Will add that check and send v2.
> >
> > Sorry I didn't mean add a test in the code, I meant construct a test
> > case to confirm that it works as expected.
>
> Michael,
>
> I just hand-coded the instr to emulate_step() and here are the results:
>
> MSR_PR is set
> insn = 7c600124, ret = 0 /* mtmsr */
> insn = 7c600164, ret = 0 /* mtmsrd */
> insn = 4c000024, ret = -1 /* rfid */
> insn = 4c000064, ret = 0 /* rfi */
>
> Also verified that standalone programs with those instructions in inline
> asm will die with a SIGILL.
>
> So, for mtmsr, mtmsrd and rfi, we have to single-step them which will
> result in a SIGILL in turn.
What happens in the rfid case? You don't handle -1 from emulate_step()
any differently AFAICS, so don't we try to single step that too?
cheers
^ permalink raw reply
* RE: [PATCH 0/6] Description for PCI patches using platform driver
From: Jia Hongtao-B38951 @ 2012-06-12 2:27 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Li Yang-R58472, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <4FD61215.8030608@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, June 11, 2012 11:43 PM
> To: Jia Hongtao-B38951
> Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> galak@kernel.crashing.org; Li Yang-R58472; benh@kernel.crashing.org; Wood
> Scott-B07421
> Subject: Re: [PATCH 0/6] Description for PCI patches using platform
> driver
>=20
> On 06/10/2012 09:33 PM, Jia Hongtao-B38951 wrote:
> >> -----Original Message-----
> >> From: Bhushan Bharat-R65777
> >> Sent: Friday, June 08, 2012 6:47 PM
> >> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> >> galak@kernel.crashing.org
> >> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> >> Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> >> driver
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jia Hongtao-B38951
> >>> Sent: Friday, June 08, 2012 3:12 PM
> >>> To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> >>> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421;
> >> Bhushan Bharat-
> >>> R65777; Jia Hongtao-B38951
> >>> Subject: [PATCH 0/6] Description for PCI patches using platform
> driver
> >>>
> >>> This series of patches are to unify pci initialization code and add
> PM
> >> support
> >>> for all 85xx/86xx powerpc boards. But two side effects are introduced
> >> by this
> >>> mechanism which listed below:
> >>>
> >>> 1. of_platform_bus_probe() will be called twice but in some cases
> >> duplication
> >>> warning occured. We fix this in [PATCH 5/6].
> >>>
> >>> 2. Edac driver failed to register pci nodes as platform devices. We
> fix
> >> this
> >>> in [PATCH 6/6].
> >>
> >> With these patches will not the SWIOTLB will not be initialized even
> if
> >> PCI/PCIe demanded?
> >>
> >> Thanks
> >> -Bharat
> >>
> >
> > These patches still have the swiotlb init problem if
> "ppc_swiotlb_enable" is
> > only demanded by PCI/PCIe. One of the purposes of sending out these
> patches
> > is to let us start a discussion for this problem in upstream.
>=20
> When sending out a patchset like that, label it as [RFC PATCH] (request
> for comments), and mention all known problems to be resolved.
>=20
> -Scott
I got it.
Thanks for your remind.
-Jia Hongtao.
^ permalink raw reply
* RE: [PATCH 0/6] Description for PCI patches using platform driver
From: Jia Hongtao-B38951 @ 2012-06-12 2:24 UTC (permalink / raw)
To: Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org,
galak@kernel.crashing.org
Cc: Li Yang-R58472, Wood Scott-B07421
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03D78FAE@039-SN2MPN1-022.039d.mgd.msft.net>
> -----Original Message-----
> From: Bhushan Bharat-R65777
> Sent: Monday, June 11, 2012 9:25 PM
> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> galak@kernel.crashing.org
> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> driver
>=20
>=20
>=20
> > -----Original Message-----
> > From: Jia Hongtao-B38951
> > Sent: Monday, June 11, 2012 8:03 AM
> > To: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> > galak@kernel.crashing.org
> > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> > Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> driver
> >
> > > -----Original Message-----
> > > From: Bhushan Bharat-R65777
> > > Sent: Friday, June 08, 2012 6:47 PM
> > > To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> > > galak@kernel.crashing.org
> > > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> > > Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> > > driver
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jia Hongtao-B38951
> > > > Sent: Friday, June 08, 2012 3:12 PM
> > > > To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> > > > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421;
> > > Bhushan Bharat-
> > > > R65777; Jia Hongtao-B38951
> > > > Subject: [PATCH 0/6] Description for PCI patches using platform
> > > > driver
> > > >
> > > > This series of patches are to unify pci initialization code and add
> > > > PM
> > > support
> > > > for all 85xx/86xx powerpc boards. But two side effects are
> > > > introduced
> > > by this
> > > > mechanism which listed below:
> > > >
> > > > 1. of_platform_bus_probe() will be called twice but in some cases
> > > duplication
> > > > warning occured. We fix this in [PATCH 5/6].
> > > >
> > > > 2. Edac driver failed to register pci nodes as platform devices. We
> > > > fix
> > > this
> > > > in [PATCH 6/6].
> > >
> > > With these patches will not the SWIOTLB will not be initialized even
> > > if PCI/PCIe demanded?
> > >
> > > Thanks
> > > -Bharat
> > >
> >
> > These patches still have the swiotlb init problem if
> "ppc_swiotlb_enable" is
> > only demanded by PCI/PCIe. One of the purposes of sending out these
> patches is
> > to let us start a discussion for this problem in upstream.
>=20
> Ok, I did not find any mention of that, so I thought that you have
> resolved the issue by some means in these patches which I did not catch.
>=20
> So, these patches introduces the issue, that SWIOTLB will not be
> initialized if requested by pci/pcie. The request is raised by setting
> the flag ppc_swiotlb_enable. The swiotlb_init() will be called in
> mem_init() if ppc_swiotlb_enable is set. Now with these patches, the
> request is raised after mem_init() is called. So request not handled :).
>=20
> Following are the solutions we have thought of during our internal
> discussions (if I did not missed any):
>=20
> 1. These patches move the code from platform init to device init
> (arch_initcall()). Rather than moving the whole code, let us divide the
> code into two. First, which is needed to raise the swiotlb init request
> and second the rest. Define this first as an function in
> arch/powerpc/sysdev/fsl_pci.c and call this from platform init code of
> the SOCs.
>=20
> 2. All known devices, the lowest PCIe outbound range starts at 0x80000000=
,
> but there's nothing above 0xc0000000. So the inbound of size 0x8000_0000
> is always availbe on all devices. Hardcode the check in platform code to
> check memblock_end_of_DRAM() to 0x80000000.
>=20
> Something like this:
>=20
> diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
> b/arch/powerpc/platforms/85xx/corenet_ds.c
> index 1f7028e..ef4e215 100644
> --- a/arch/powerpc/platforms/85xx/corenet_ds.c
> +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
> @@ -79,7 +79,7 @@ void __init corenet_ds_setup_arch(void) #endif
>=20
> #ifdef CONFIG_SWIOTLB
> - if (memblock_end_of_DRAM() > 0xffffffff)
> + if (memblock_end_of_DRAM() > 0xff000000)
> ppc_swiotlb_enable =3D 1; #endif
> pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
>=20
> -------------
>=20
> 3. Always do swiotlb_init() in mem_init() and later after PCI init, if
> the swiotlb is not needed then free it (swiotlb_free()).
>=20
> 4. etc, please provide some other better way.
>=20
> Thanks
> -Bharat
Thanks.
In my point of view the 2nd solution is better for it does not treat PCI/PC=
Ie as
the special kind of devices from others.
-Jia Hongtao.
^ permalink raw reply
* Re: [PATCH v2 0/2] Add pcibios_device_change_notifier
From: Benjamin Herrenschmidt @ 2012-06-11 23:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, Kenji Kaneshige, linuxppc-dev, jbarnes,
Hiroo Matsumoto
In-Reply-To: <CAErSpo79RDid=4m+Q8FZxnhThQ9BAJo4HhtZ8ZQ5rGc1nmvH-w@mail.gmail.com>
On Mon, 2012-06-11 at 16:51 -0600, Bjorn Helgaas wrote:
> > This makes me a bit nervous (that doesn't mean it's not right, but
> > we need some careful auditing & testing here, which I won't be
> > able to do until I'm back from leave). Mostly due to the change in when
> > we do the work.
> >
> > pcibios_fixup_bus() used to be called early on in the initial scan pass.
> >
> > Your code causes the code to be called -much- later when registering the
> > device with the device model. Are we 100% certain nothing will happen in
> > between that might rely on the stuff being setup already ? It might well
> > be ok, but I want us to triple check that.
>
> Here's my theory on this: we're setting up DMA and IRQ stuff. DMA and
> IRQ usage is device-specific, so the core can't do anything with them.
> Only drivers know how to use them. Drivers can't find the device
> until it's registered with the device model. So it seems like it
> should be safe to move it later. Subject to thinkos and testing in
> the real world, of course :)
I am aware of that and that's why I say "might well be ok" :-) But this
is old code and you know what can happen in there ... might be a quirk
here or a piece of platform code there trying to fixup the IRQ for
example ... before we set it up. That sort of thing.
I should be allright, but I want to test, which I won't be able to do
properly before I'm back at work next week.
> > Now, if we are ok to do the setup that late (basically right before the
> > driver probe() routine gets called), would it make sense to simplify
> > things even further ... and do it from pcibios_enable_device() ? Thus
> > avoiding the notifier business completely or is that pushing it too
> > far ?
>
> Kenji-san actually suggested using pcibios_enable_device() early on,
> and I'm the one who suggested the notifiers instead. I think I
> suggested that because I was copying the amd_iommu_init_notifier()
> style.
>
> But I now think that might have been a mistake. Notifiers are
> definitely more complicated, and a pcibios_*() hook seems
> straightforward. It could be in pcibios_enable_device(), though we
> only need it to be called once, and the enable_device() path may be
> called many times, e.g., every time a driver claims it. My new vote
> is a pcibios_device_add(), with an empty weak definition in
> drivers/pci, and a non-empty definition for microblaze and powerpc.
Would it be called before or after the notifiers ? I wonder... if others
already use the notifiers maybe we should stick to it. I only suggested
pcibios_enable_device() because it's already there.
> > Also you seem to add:
> >
> > + /* Setup OF node pointer in the device */
> > + dev->dev.of_node = pci_device_to_OF_node(dev);
> >
> > This shouldn't be needed anymore, the device node should be setup by the
> > core nowadays. Is this just a remnant of you rebasing an old patch or do
> > you have a good reason to add this statement ?
>
> It sounds like you want to remove this line in any case, so I'll wait
> for updated patches.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 0/2] Add pcibios_device_change_notifier
From: Bjorn Helgaas @ 2012-06-11 22:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-pci, Kenji Kaneshige, linuxppc-dev, jbarnes,
Hiroo Matsumoto
In-Reply-To: <1338960416.7150.160.camel@pasglop>
On Tue, Jun 5, 2012 at 11:26 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2012-05-23 at 11:33 +0900, Hiroo Matsumoto wrote:
>> This patchset is for PCI hotplug.
>>
>>
>> pcibios_setup_bus_devices which sets DMA and IRQs of PCI device is calle=
d
>> only when boot. DMA setting in probe for PCI driver, like dma_set_mask,
>> does not work on powerpc platform. So it is need to set DMA and IRQs of
>> PCI device when hotplug.
>>
>> 1. Moving pcibios_setup_bus_devices code to pcibios_device_change_notifi=
er
>> =A0 =A0which is registered to bus notifier in pcibios_init.
>> 2. Removing caller and callee of pcibios_setup_bus_devices bus notifier
>> =A0 =A0works instead of pcibios_setup_bus_devices.
>> 3. Using this bus notifier for microblaze because microblaze/PCI is simi=
ler
>> =A0 =A0with powerpc/PCI.
>
> This makes me a bit nervous (that doesn't mean it's not right, but
> we need some careful auditing & testing here, which I won't be
> able to do until I'm back from leave). Mostly due to the change in when
> we do the work.
>
> pcibios_fixup_bus() used to be called early on in the initial scan pass.
>
> Your code causes the code to be called -much- later when registering the
> device with the device model. Are we 100% certain nothing will happen in
> between that might rely on the stuff being setup already ? It might well
> be ok, but I want us to triple check that.
Here's my theory on this: we're setting up DMA and IRQ stuff. DMA and
IRQ usage is device-specific, so the core can't do anything with them.
Only drivers know how to use them. Drivers can't find the device
until it's registered with the device model. So it seems like it
should be safe to move it later. Subject to thinkos and testing in
the real world, of course :)
> Now, if we are ok to do the setup that late (basically right before the
> driver probe() routine gets called), would it make sense to simplify
> things even further ... and do it from pcibios_enable_device() ? Thus
> avoiding the notifier business completely or is that pushing it too
> far ?
Kenji-san actually suggested using pcibios_enable_device() early on,
and I'm the one who suggested the notifiers instead. I think I
suggested that because I was copying the amd_iommu_init_notifier()
style.
But I now think that might have been a mistake. Notifiers are
definitely more complicated, and a pcibios_*() hook seems
straightforward. It could be in pcibios_enable_device(), though we
only need it to be called once, and the enable_device() path may be
called many times, e.g., every time a driver claims it. My new vote
is a pcibios_device_add(), with an empty weak definition in
drivers/pci, and a non-empty definition for microblaze and powerpc.
> Also you seem to add:
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Setup OF node pointer in the device */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev->dev.of_node =3D pci_device_to_OF_node(=
dev);
>
> This shouldn't be needed anymore, the device node should be setup by the
> core nowadays. Is this just a remnant of you rebasing an old patch or do
> you have a good reason to add this statement ?
It sounds like you want to remove this line in any case, so I'll wait
for updated patches.
Bjorn
^ permalink raw reply
* Re: PowerMac PMU programming
From: Benjamin Herrenschmidt @ 2012-06-11 21:24 UTC (permalink / raw)
To: Justin Hibbits; +Cc: linuxppc-dev
In-Reply-To: <20120610233127.1284fec0@narn.knownspace>
On Sun, 2012-06-10 at 23:31 -0400, Justin Hibbits wrote:
> I'll settle on just getting the CPU speed change working, losing 333MHz
> on my TiBook is a few too many MHz for the poor thing to lose :) I do
> have a desktop, but that's my development platform, so needs to be
> at least somewhat stable, so my TiBook is my guinea pig.
>
> I've googled everything I can think of, but do you know of any
> definitive PMU documentation? Or can you give me any hints on what's
> needed just for that simple operation?
No doco no, Darwin and Linux source code are your best bet.
It works like sleep as in: you send the switch command and the PMU will
reboot the processor with the new frequency whenever the processor
enters NAP mode.
This is tricky because there's a loss of cache coherency vs. ongoing
DMAs, hence tricky bits of code in there to deal with the various
caches.
> I noticed that you wind down the ADB queue before killing the PMU. Is
> this necessary? I only disable the interrupt by writing 0x10 to the
> IER, but our interrupt model for the PMU is different from the Linux
> one.
Well that will not disable CB1 (or the external GPIO one). You need to
make sure no other communication with the PMU takes place once you've
sent the sleep command and until you're back.
> Is it also necessary to disable the interrupt input, even though
> the register write should be disabling the PMU's asserting of the
> line? There doesn't seem to be much more different than that, and
> setting the openpic priority, Linux sets it to 0x0f but I didn't see
> anything in OS X doing that (might that be a problem, too?)
>
> I would love to get my TiBook using the full 1GHz.
I don't remember what openpic does in Darwin, I think interrupts are all
masked there as a side effect of the code in KeyLargo.cpp but I'm not
sure that applies to frequency changes.
Cheers,
Ben.
^ permalink raw reply
* Re: [Doubt] PPC Linux Device Tree Update
From: Scott Wood @ 2012-06-11 20:14 UTC (permalink / raw)
To: Kay One; +Cc: linuxppc-dev
In-Reply-To: <CAL3nkH-HAwRngz2Ob7R_AB0YSDbSVGi6AWNEEaiwQXbcHvwGSw@mail.gmail.com>
On 06/11/2012 02:52 AM, Kay One wrote:
> Hi All,
>
> Currently I am working on p1020rdb soc for some kernel bringing up activity.
> I have come across one requirement to update the memory map (MMAP) of
> kernel from evaluation board to
> some other board who is having the same soc.
>
> for my eval board I have used the p1020rdb.dts file from 2.6.38 standard
> kernel source.
Why not start with the latest version?
> (PFA) which is working almost fine.
> But, I am really not able to find the following mapping as a part of the
> attached dts file what I am using.
> Can anyone please point me out that dts file is the only one to search
> out following base addresses selected in memory map or is there
> some specific file of kernel inside which I will be able to search
> through to find the following base addresses?
>
> FFFF_F000 4 KB .bootpg
This is not expressed in the device tree, though it is marked reserved
by U-Boot in the reserve map (part of the dtb, but not part of the
actual tree).
> FFE0_0000 1 MB CCSR
That's the "soc" node.
> EC00_0000 64 MB Flash + alias
/localbus@ffe05000/nor@0,0/
...but it's at 0xef00_0000 according to the tree you attached.
Read the ePAPR spec for a description of how the ranges property works.
> 8000_0000 1 GB PCI[1:2] mem
> FFC0_0000 256 KB PCI[1:2] I/O
These are encoded in the ranges property of the relevant PCIe node (see
version 1.0 of the ePAPR spec for how), but I don't see one with those
specific addresses. I don't know what the [1:2] is supposed to mean.
> FFB0_0000 1 MB VTSS
/localbus@ffe05000/L2switch@2,0/
> FFA0_0000 1 MB CPLD
Not represented in the device tree. The device tree shows NAND at this
address.
> FF80_0000 1 MB NAND
/localbus@ffe05000/nand@1,0/
...but with a different address, as noted above.
> 0000_0000 1 GB DDR
/memory
U-Boot fills in the reg property.
-Scott
^ permalink raw reply
* reserving memory using OF rsvmap feature?
From: Joakim Tjernlund @ 2012-06-11 19:16 UTC (permalink / raw)
To: linuxppc-dev
Is it possible to reserve some memory using OF rsvmap such that Linux
will not touch this area at all? Think of is as warm start stash area
were one could store data which should survive a reboot.
One could then create an uio driver which exports this memory to user space I hope.
Jocke
^ permalink raw reply
* Q: a_ops->readpage() && struct file
From: Oleg Nesterov @ 2012-06-11 19:09 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli, Linus Torvalds, Al Viro
Cc: Srikar Dronamraju, peterz, antonb, lkml, michael, Jim Keniston,
Paul Mackerras, Ingo Molnar, linuxppc-dev
In-Reply-To: <20120611161215.GA12116@redhat.com>
On 06/11, Oleg Nesterov wrote:
>
> Note also that we should move this !UPROBE_COPY_INSN from
> install_breakpoint() to somewhere near alloc_uprobe().
The main problem is, uprobe_register() doesn't have struct file
for read_mapping_page().
Stupid question. I'm afraid the answer is "no" but I'll ask anyway.
Is it safe to pass filp == NULL to mapping->readpage()? In fact
I do not understand why it needs "struct file*" and I do not see
any example of actual usage. Yes, I didn't try to grep very much
and I understand that the filesystem can do something special.
Say it can use file->private_data...
However. There is read_cache_page_gfp() which does use
a_ops->readpage(filp => NULL), and the comment says nothing about
the riskiness.
If not, is there any other way
uprobe_register(struct inode *inode, loff_t offset) can read the
page at this offset?
And btw, read_mapping_page() accepts "void *data". Why? it uses
filler == a_ops->readpage, it shouldn't accept anything but file
pointer?
Please help, I know nothing about vfs.
Oleg.
^ permalink raw reply
* Re: [PATCH v2 1/2] uprobes: Pass probed vaddr to arch_uprobe_analyze_insn()
From: Oleg Nesterov @ 2012-06-11 16:12 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli
Cc: Srikar Dronamraju, peterz, antonb, lkml, michael, Jim Keniston,
Paul Mackerras, Ingo Molnar, linuxppc-dev
In-Reply-To: <20120608093257.GG13409@in.ibm.com>
Ananth, Srikar,
I think the patch is correct and I am sorry for nit-picking,
this is really minor.
But,
On 06/08, Ananth N Mavinakayanahalli wrote:
>
> Changes in V2:
> Pass (unsigned long)addr
Well, IMHO, this is confusing.
First of all, why do we have this "addr" or even "vaddr"? It should
not exists. We pass it to copy_insn(), but for what?? copy_insn()
should simply use uprobe->offset, the virtual address for this
particular mapping does not matter at all. I am going to send
the cleanup.
Note also that we should move this !UPROBE_COPY_INSN from
install_breakpoint() to somewhere near alloc_uprobe(). This code
is called only once, it looks a bit strange to use the "random" mm
(the first mm vma_prio_tree_foreach() finds) and its mapping to
verify the insn. In fact this is simply not correct and should be
fixed, note that on x86 arch_uprobe_analyze_insn() checks
mm->context.ia32_compat.
IOW, Perhaps uprobe->offset makes more sense?
> --- linux-3.5-rc1.orig/kernel/events/uprobes.c
> +++ linux-3.5-rc1/kernel/events/uprobes.c
> @@ -697,7 +697,7 @@ install_breakpoint(struct uprobe *uprobe
> if (is_swbp_insn((uprobe_opcode_t *)uprobe->arch.insn))
> return -EEXIST;
>
> - ret = arch_uprobe_analyze_insn(&uprobe->arch, mm);
> + ret = arch_uprobe_analyze_insn(&uprobe->arch, mm, addr);
Just fyi, this conflicts with
"[PATCH 1/3] uprobes: install_breakpoint() should fail if is_swbp_insn() == T"
I sent, but the conflict is trivial.
Oleg.
^ permalink raw reply
* Re: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
From: Scott Wood @ 2012-06-11 15:54 UTC (permalink / raw)
To: Gopalakrishnan Raman; +Cc: rgkwstl@gmail.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <802E1C77E421D345A43385A6BFAC7AC4BE502C@ROYALGORGE.arubanetworks.com>
On 06/10/2012 03:37 PM, Gopalakrishnan Raman wrote:
> Hi
>=20
> The P1020 manual states (in the PIC chapter) that in the =93Internal
> Interrupt Destination=94 register, only 1 CPU (and not both) can be
> selected as the IRQ destination.
Right.
> How then can we achieve =93interrupt
> spraying=94 for the PCI interrupt (we want interrupts to be sent
> alternately to CPU0 and CPU1).
You'll have to implement it in software by changing the destination each
time (and be careful to follow the documented sequence for making such
changes).
Why do you want to do this? Won't it cause a bunch of cache misses as
the IRQ-relevant data structures bounce between CPUs? Distributing
different devices' interrupts among multiple CPUs is probably good for
load balancing, but distributing a single device's interrupts may not be
so good.
> Also, we changed the code to ignore the
> MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the
> PIC_IIDRn register. This does seem to work.
What specifically does it seem to do?
> But we=92re not sure if we can
> rely on this behavior and whether it will cause other problems.
You cannot rely on this. It is not a supported configuration.
-Scott
^ permalink raw reply
* Re: [PATCH 0/6] Description for PCI patches using platform driver
From: Scott Wood @ 2012-06-11 15:43 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: Wood Scott-B07421, Li Yang-R58472, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A0921B@039-SN1MPN1-002.039d.mgd.msft.net>
On 06/10/2012 09:33 PM, Jia Hongtao-B38951 wrote:
>> -----Original Message-----
>> From: Bhushan Bharat-R65777
>> Sent: Friday, June 08, 2012 6:47 PM
>> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
>> galak@kernel.crashing.org
>> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
>> Subject: RE: [PATCH 0/6] Description for PCI patches using platform
>> driver
>>
>>
>>> -----Original Message-----
>>> From: Jia Hongtao-B38951
>>> Sent: Friday, June 08, 2012 3:12 PM
>>> To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
>>> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421;
>> Bhushan Bharat-
>>> R65777; Jia Hongtao-B38951
>>> Subject: [PATCH 0/6] Description for PCI patches using platform driver
>>>
>>> This series of patches are to unify pci initialization code and add PM
>> support
>>> for all 85xx/86xx powerpc boards. But two side effects are introduced
>> by this
>>> mechanism which listed below:
>>>
>>> 1. of_platform_bus_probe() will be called twice but in some cases
>> duplication
>>> warning occured. We fix this in [PATCH 5/6].
>>>
>>> 2. Edac driver failed to register pci nodes as platform devices. We fix
>> this
>>> in [PATCH 6/6].
>>
>> With these patches will not the SWIOTLB will not be initialized even if
>> PCI/PCIe demanded?
>>
>> Thanks
>> -Bharat
>>
>
> These patches still have the swiotlb init problem if "ppc_swiotlb_enable" is
> only demanded by PCI/PCIe. One of the purposes of sending out these patches
> is to let us start a discussion for this problem in upstream.
When sending out a patchset like that, label it as [RFC PATCH] (request
for comments), and mention all known problems to be resolved.
-Scott
^ permalink raw reply
* Re: P2010 External HW IRQ number?
From: Scott Wood @ 2012-06-11 15:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OFA31422D6.CC72BDBF-ONC1257A18.0031549A-C1257A18.003183C0@transmode.se>
On 06/09/2012 04:00 AM, Joakim Tjernlund wrote:
>
>
> Scott Wood <scottwood@freescale.com> wrote on 2012/06/08 21:23:50:
>
>> From: Scott Wood <scottwood@freescale.com>
>> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>,
>> Cc: <linuxppc-dev@ozlabs.org>
>> Date: 2012/06/08 21:25
>> Subject: Re: P2010 External HW IRQ number?
>>
>> On 06/08/2012 06:06 AM, Joakim Tjernlund wrote:
>>>
>>> I have been trying to figure out what irq number to use for external IRQs for
>>> the P2010. There are no HW IRQ numbers in the ref manual and I cannot find
>>> any examples in the kernel either.
>>> How do specify irq numbers in my dts for external IRQs?
>>
>> See Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
>
> Ahh, now I see. however I must say that I didn't until I read this older version first:
> http://os1a.cs.columbia.edu/lxr/source/Documentation/powerpc/dts-bindings/fsl/mpic.txt?a=x86;v=2.6.34
Yeah, while the information is there in the new version, it's should be
more prominent and detailed for something that causes so much confusion.
-Scott
^ permalink raw reply
* RE: [PATCH 0/6] Description for PCI patches using platform driver
From: Bhushan Bharat-R65777 @ 2012-06-11 13:24 UTC (permalink / raw)
To: Jia Hongtao-B38951, linuxppc-dev@lists.ozlabs.org,
galak@kernel.crashing.org
Cc: Li Yang-R58472, Wood Scott-B07421
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A0921B@039-SN1MPN1-002.039d.mgd.msft.net>
> -----Original Message-----
> From: Jia Hongtao-B38951
> Sent: Monday, June 11, 2012 8:03 AM
> To: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> galak@kernel.crashing.org
> Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> Subject: RE: [PATCH 0/6] Description for PCI patches using platform drive=
r
>=20
> > -----Original Message-----
> > From: Bhushan Bharat-R65777
> > Sent: Friday, June 08, 2012 6:47 PM
> > To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> > galak@kernel.crashing.org
> > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421
> > Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> > driver
> >
> >
> > > -----Original Message-----
> > > From: Jia Hongtao-B38951
> > > Sent: Friday, June 08, 2012 3:12 PM
> > > To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> > > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421;
> > Bhushan Bharat-
> > > R65777; Jia Hongtao-B38951
> > > Subject: [PATCH 0/6] Description for PCI patches using platform
> > > driver
> > >
> > > This series of patches are to unify pci initialization code and add
> > > PM
> > support
> > > for all 85xx/86xx powerpc boards. But two side effects are
> > > introduced
> > by this
> > > mechanism which listed below:
> > >
> > > 1. of_platform_bus_probe() will be called twice but in some cases
> > duplication
> > > warning occured. We fix this in [PATCH 5/6].
> > >
> > > 2. Edac driver failed to register pci nodes as platform devices. We
> > > fix
> > this
> > > in [PATCH 6/6].
> >
> > With these patches will not the SWIOTLB will not be initialized even
> > if PCI/PCIe demanded?
> >
> > Thanks
> > -Bharat
> >
>=20
> These patches still have the swiotlb init problem if "ppc_swiotlb_enable"=
is
> only demanded by PCI/PCIe. One of the purposes of sending out these patch=
es is
> to let us start a discussion for this problem in upstream.
Ok, I did not find any mention of that, so I thought that you have resolved=
the issue by some means in these patches which I did not catch.
So, these patches introduces the issue, that SWIOTLB will not be initialize=
d if requested by pci/pcie. The request is raised by setting the flag ppc_s=
wiotlb_enable. The swiotlb_init() will be called in mem_init() if ppc_swiot=
lb_enable is set. Now with these patches, the request is raised after mem_i=
nit() is called. So request not handled :).
Following are the solutions we have thought of during our internal discussi=
ons (if I did not missed any):
1. These patches move the code from platform init to device init (arch_init=
call()). Rather than moving the whole code, let us divide the code into two=
. First, which is needed to raise the swiotlb init request and second the r=
est. Define this first as an function in arch/powerpc/sysdev/fsl_pci.c and =
call this from platform init code of the SOCs.
2. All known devices, the lowest PCIe outbound range starts at 0x80000000, =
but there's nothing above 0xc0000000. So the inbound of size 0x8000_0000 is=
always availbe on all devices. Hardcode the check in platform code to chec=
k memblock_end_of_DRAM() to 0x80000000.
Something like this:
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index 1f7028e..ef4e215 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -79,7 +79,7 @@ void __init corenet_ds_setup_arch(void) #endif
#ifdef CONFIG_SWIOTLB
- if (memblock_end_of_DRAM() > 0xffffffff)
+ if (memblock_end_of_DRAM() > 0xff000000)
ppc_swiotlb_enable =3D 1; #endif
pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
-------------
3. Always do swiotlb_init() in mem_init() and later after PCI init, if the =
swiotlb is not needed then free it (swiotlb_free()).=20
4. etc, please provide some other better way.
Thanks
-Bharat
^ permalink raw reply related
* RE: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
From: Li Yang-R58472 @ 2012-06-11 9:36 UTC (permalink / raw)
To: Gopalakrishnan Raman, linuxppc-dev@lists.ozlabs.org; +Cc: rgkwstl@gmail.com
In-Reply-To: <802E1C77E421D345A43385A6BFAC7AC4BE502C@ROYALGORGE.arubanetworks.com>
> Subject: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
>=20
> Hi
> The P1020 manual states (in the PIC chapter) that in the "Internal
> Interrupt Destination" register, only 1 CPU (and not both) can be
> selected as the IRQ destination. How then can we achieve "interrupt
> spraying" for the PCI interrupt (we want interrupts to be sent
> alternately to CPU0 and CPU1). Also, =A0we changed the code to ignore the
> MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the
> PIC_IIDRn register. This does seem to work. But we're not sure if we can
> rely on this behavior and whether it will cause other problems.
I suggest you to follow the UM. The note should be there for a reason alth=
ough personally I don't know what the specific problem will be.
Leo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox