Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
On Fri, Jan 11, 2013 at 03:23:59AM +, Chen Peter-B29397 wrote: > > > > > > > > > Some recent patch has caused fsl_mxc_udc.c driver to fail compilation > > > > because it can't find anymore. > > > > > > > > I would like this to be fixed still during this -rc cycle. > > > > > > Me too, who's sending a patch? :) > > > > Hi Peter, > > > > Who is currently working on the i.mx USB? > > > > I am working on it, but there are two versions, this one and chipidea's. > > Anyway, I will send a patch to fix this problem. if you're already using chipidea, then send me a patch removing this driver and focus your effort on chipidea. -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
> > > > > > > I am working on it, but there are two versions, this one and chipidea's. > > > > Anyway, I will send a patch to fix this problem. > > if you're already using chipidea, then send me a patch removing this > driver and focus your effort on chipidea. > Added Sascha Now, not all of FSL i.mx USB can move to use chipidea due to some platform and USB PHY problem. > -- > balbi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
Hi, On Fri, Jan 11, 2013 at 08:35:29AM +, Chen Peter-B29397 wrote: > > > I am working on it, but there are two versions, this one and chipidea's. > > > > > > Anyway, I will send a patch to fix this problem. > > > > if you're already using chipidea, then send me a patch removing this > > driver and focus your effort on chipidea. > > > Added Sascha > > Now, not all of FSL i.mx USB can move to use chipidea due to some platform > and USB > PHY problem. then we need to target fixing those problems and moving to chipidea completely at some point. There's no reason to duplicate efforts if we already have a re-usable driver in tree, right ? Let's fix this build break and focus on making sure all i.MX platforms can use chipidea so we can drop fsl udc on next merge window. That would be a great patchset to see. -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Friday, January 11, 2013 4:41 PM > To: Chen Peter-B29397 > Cc: ba...@ti.com; ker...@pengutronix.de; Li Yang-R58472; Greg KH; linux- > u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on > current v3.8-rc3 > > Hi, > > On Fri, Jan 11, 2013 at 08:35:29AM +, Chen Peter-B29397 wrote: > > > > I am working on it, but there are two versions, this one and > chipidea's. > > > > > > > > Anyway, I will send a patch to fix this problem. > > > > > > if you're already using chipidea, then send me a patch removing this > > > driver and focus your effort on chipidea. > > > > > Added Sascha > > > > Now, not all of FSL i.mx USB can move to use chipidea due to some > > platform and USB PHY problem. > > then we need to target fixing those problems and moving to chipidea > completely at some point. There's no reason to duplicate efforts if we > already have a re-usable driver in tree, right ? > > Let's fix this build break and focus on making sure all i.MX platforms > can use chipidea so we can drop fsl udc on next merge window. That would > be a great patchset to see. I do agree that we need move to use the chipidea driver and eventually remove the fsl udc driver, but there were many users of the current driver such as PowerPC and Coldfire platforms besides the i.MX platforms. The support for them with chipidea driver could also be broken for now. I would suggest to have a transitional period that both drivers are kept while new development be based on the new driver. Added Ramneek. What do you think of the current status for chipidea driver on PowerPC platforms? Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
Hi, On Fri, Jan 11, 2013 at 09:24:16AM +, Li Yang-R58472 wrote: > > > > -Original Message- > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Friday, January 11, 2013 4:41 PM > > To: Chen Peter-B29397 > > Cc: ba...@ti.com; ker...@pengutronix.de; Li Yang-R58472; Greg KH; linux- > > u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on > > current v3.8-rc3 > > > > Hi, > > > > On Fri, Jan 11, 2013 at 08:35:29AM +, Chen Peter-B29397 wrote: > > > > > I am working on it, but there are two versions, this one and > > chipidea's. > > > > > > > > > > Anyway, I will send a patch to fix this problem. > > > > > > > > if you're already using chipidea, then send me a patch removing this > > > > driver and focus your effort on chipidea. > > > > > > > Added Sascha > > > > > > Now, not all of FSL i.mx USB can move to use chipidea due to some > > > platform and USB PHY problem. > > > > then we need to target fixing those problems and moving to chipidea > > completely at some point. There's no reason to duplicate efforts if we > > already have a re-usable driver in tree, right ? > > > > Let's fix this build break and focus on making sure all i.MX platforms > > can use chipidea so we can drop fsl udc on next merge window. That would > > be a great patchset to see. > > I do agree that we need move to use the chipidea driver and eventually > remove the fsl udc driver, but there were many users of the current > driver such as PowerPC and Coldfire platforms besides the i.MX > platforms. The support for them with chipidea driver could also be > broken for now. I would suggest to have a transitional period that > both drivers are kept while new development be based on the new > driver. right, right. That can be done as long as 'transitional period' isn't 20 years. At least make a plan to remove fsl udc, if it doesn't happen in the next 4 merge windows, I will remove it myself to force people to reuse other drivers. There is no reason to keep both drivers around. > Added Ramneek. What do you think of the current status for chipidea > driver on PowerPC platforms? that would be great to know, indeed. -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
It changes the driver to use platform_device_id rather than cpu_is_xxx to determine the SoC type, and updates the platform code accordingly. Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable. Tested at mx51 bbg board, it works ok after enable phy clock (Need another patch to fix this problem) Signed-off-by: Peter Chen --- arch/arm/mach-imx/clk-imx25.c |6 +- arch/arm/mach-imx/clk-imx27.c |6 +- arch/arm/mach-imx/clk-imx31.c |6 +- arch/arm/mach-imx/clk-imx35.c |6 +- arch/arm/mach-imx/clk-imx51-imx53.c |6 +- arch/arm/mach-imx/devices/devices-common.h|1 + arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++--- drivers/usb/gadget/fsl_mxc_udc.c | 17 +++ drivers/usb/gadget/fsl_udc_core.c | 52 +--- drivers/usb/gadget/fsl_usb2_udc.h | 13 -- include/linux/fsl_devices.h |8 +++ 11 files changed, 82 insertions(+), 54 deletions(-) diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c index b197aa7..67e353d 100644 --- a/arch/arm/mach-imx/clk-imx25.c +++ b/arch/arm/mach-imx/clk-imx25.c @@ -254,9 +254,9 @@ int __init mx25_clocks_init(void) clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2"); clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); - clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx25"); + clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx25"); + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx25"); clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0"); /* i.mx25 has the i.mx35 type cspi */ clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0"); diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 4c1d1e4..1ffe3b5 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0"); clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0"); clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0"); - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc"); + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27"); + clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27"); + clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27"); clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0"); clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0"); clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0"); diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c index 8be64e0..ef66eaf 100644 --- a/arch/arm/mach-imx/clk-imx31.c +++ b/arch/arm/mach-imx/clk-imx31.c @@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref) clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2"); clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2"); clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); - clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc"); - clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc"); - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); + clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx31"); + clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx31"); + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx31"); clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0"); /* i.mx31 has the i.mx21 type uart */ clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0"); diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c index 66f3d65..69fe9c8 100644 --- a/arch/arm/mach-imx/clk-imx35.c +++ b/arch/arm/mach-imx/clk-imx35.c @@ -251,9 +251,9 @@ int __init mx35_clocks_init() clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2"); - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); - clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc"); + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx35"); + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx35"); + clk_register_clkdev(clk[usbotg_gate], "ahb", "imx-udc
RE: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Friday, January 11, 2013 3:18 PM > To: Li Yang-R58472 > Cc: ba...@ti.com; Chen Peter-B29397; Mehresh Ramneek-B31383; > ker...@pengutronix.de; Greg KH; linux-...@vger.kernel.org; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on > current v3.8-rc3 > > Hi, > > On Fri, Jan 11, 2013 at 09:24:16AM +, Li Yang-R58472 wrote: > > > > > > > -Original Message- > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Friday, January 11, 2013 4:41 PM > > > To: Chen Peter-B29397 > > > Cc: ba...@ti.com; ker...@pengutronix.de; Li Yang-R58472; Greg KH; > > > linux- u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > > Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on > > > current v3.8-rc3 > > > > > > Hi, > > > > > > On Fri, Jan 11, 2013 at 08:35:29AM +, Chen Peter-B29397 wrote: > > > > > > I am working on it, but there are two versions, this one and > > > chipidea's. > > > > > > > > > > > > Anyway, I will send a patch to fix this problem. > > > > > > > > > > if you're already using chipidea, then send me a patch removing > > > > > this driver and focus your effort on chipidea. > > > > > > > > > Added Sascha > > > > > > > > Now, not all of FSL i.mx USB can move to use chipidea due to some > > > > platform and USB PHY problem. > > > > > > then we need to target fixing those problems and moving to chipidea > > > completely at some point. There's no reason to duplicate efforts if > > > we already have a re-usable driver in tree, right ? > > > > > > Let's fix this build break and focus on making sure all i.MX > > > platforms can use chipidea so we can drop fsl udc on next merge > > > window. That would be a great patchset to see. > > > > I do agree that we need move to use the chipidea driver and eventually > > remove the fsl udc driver, but there were many users of the current > > driver such as PowerPC and Coldfire platforms besides the i.MX > > platforms. The support for them with chipidea driver could also be > > broken for now. I would suggest to have a transitional period that > > both drivers are kept while new development be based on the new > > driver. > > right, right. That can be done as long as 'transitional period' isn't 20 > years. At least make a plan to remove fsl udc, if it doesn't happen in > the next 4 merge windows, I will remove it myself to force people to > reuse other drivers. There is no reason to keep both drivers around. > > > Added Ramneek. What do you think of the current status for chipidea > > driver on PowerPC platforms? > > that would be great to know, indeed. > > -- > balbi As per my info, chipidea drv has never been tested for any ppc platforms we have... Also not sure how long chipidea will be used for ppc platforms... Let me get back to you on this -Ramneek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
Hi, On Fri, Jan 11, 2013 at 05:56:28PM +0800, Peter Chen wrote: > It changes the driver to use platform_device_id rather than cpu_is_xxx > to determine the SoC type, and updates the platform code accordingly. > > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable. > Tested at mx51 bbg board, it works ok after enable phy clock > (Need another patch to fix this problem) > > Signed-off-by: Peter Chen this is too big for -rc, can you break it down into smaller pieces ? -- balbi signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
On Fri, Jan 11, 2013 at 12:56:51PM +0200, Felipe Balbi wrote: > Hi, > > On Fri, Jan 11, 2013 at 05:56:28PM +0800, Peter Chen wrote: > > It changes the driver to use platform_device_id rather than cpu_is_xxx > > to determine the SoC type, and updates the platform code accordingly. > > > > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable. > > Tested at mx51 bbg board, it works ok after enable phy clock > > (Need another patch to fix this problem) > > > > Signed-off-by: Peter Chen > > this is too big for -rc, can you break it down into smaller pieces ? > This is a patch missed from my series that enables multiplatform support for IMX (because the driver is not enabled in defconfig, sorry). To me, it's logically one patch to convert the driver over to use platform_device_id. It does not make much sense to split it. Shawn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] usb: fsl-mxc-udc: fix build error due to mach/hardware.h
Hi, On Fri, Jan 11, 2013 at 05:56:28PM +0800, Peter Chen wrote: > It changes the driver to use platform_device_id rather than cpu_is_xxx > to determine the SoC type, and updates the platform code accordingly. > > Compile ok at imx_v6_v7_defconfig with CONFIG_USB_FSL_USB2 enable. > Tested at mx51 bbg board, it works ok after enable phy clock > (Need another patch to fix this problem) > > Signed-off-by: Peter Chen > --- > arch/arm/mach-imx/clk-imx25.c |6 +- > arch/arm/mach-imx/clk-imx27.c |6 +- > arch/arm/mach-imx/clk-imx31.c |6 +- > arch/arm/mach-imx/clk-imx35.c |6 +- > arch/arm/mach-imx/clk-imx51-imx53.c |6 +- > arch/arm/mach-imx/devices/devices-common.h|1 + > arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 15 +++--- > drivers/usb/gadget/fsl_mxc_udc.c | 17 +++ > drivers/usb/gadget/fsl_udc_core.c | 52 +--- > drivers/usb/gadget/fsl_usb2_udc.h | 13 -- > include/linux/fsl_devices.h |8 +++ > 11 files changed, 82 insertions(+), 54 deletions(-) > > diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c > index b197aa7..67e353d 100644 > --- a/arch/arm/mach-imx/clk-imx25.c > +++ b/arch/arm/mach-imx/clk-imx25.c > @@ -254,9 +254,9 @@ int __init mx25_clocks_init(void) > clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); > clk_register_clkdev(clk[usbotg_ahb], "ahb", "mxc-ehci.2"); > clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); > - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); > - clk_register_clkdev(clk[usbotg_ahb], "ahb", "fsl-usb2-udc"); > - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); > + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx25"); > + clk_register_clkdev(clk[usbotg_ahb], "ahb", "imx-udc-mx25"); > + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx25"); > clk_register_clkdev(clk[nfc_ipg_per], NULL, "imx25-nand.0"); > /* i.mx25 has the i.mx35 type cspi */ > clk_register_clkdev(clk[cspi1_ipg], NULL, "imx35-cspi.0"); > diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c > index 4c1d1e4..1ffe3b5 100644 > --- a/arch/arm/mach-imx/clk-imx27.c > +++ b/arch/arm/mach-imx/clk-imx27.c > @@ -236,9 +236,9 @@ int __init mx27_clocks_init(unsigned long fref) > clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0"); > clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0"); > clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0"); > - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); > - clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc"); > - clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc"); > + clk_register_clkdev(clk[usb_div], "per", "imx-udc-mx27"); > + clk_register_clkdev(clk[usb_ipg_gate], "ipg", "imx-udc-mx27"); > + clk_register_clkdev(clk[usb_ahb_gate], "ahb", "imx-udc-mx27"); > clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0"); > clk_register_clkdev(clk[usb_ipg_gate], "ipg", "mxc-ehci.0"); > clk_register_clkdev(clk[usb_ahb_gate], "ahb", "mxc-ehci.0"); > diff --git a/arch/arm/mach-imx/clk-imx31.c b/arch/arm/mach-imx/clk-imx31.c > index 8be64e0..ef66eaf 100644 > --- a/arch/arm/mach-imx/clk-imx31.c > +++ b/arch/arm/mach-imx/clk-imx31.c > @@ -139,9 +139,9 @@ int __init mx31_clocks_init(unsigned long fref) > clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.2"); > clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.2"); > clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); > - clk_register_clkdev(clk[usb_div_post], "per", "fsl-usb2-udc"); > - clk_register_clkdev(clk[usb_gate], "ahb", "fsl-usb2-udc"); > - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); > + clk_register_clkdev(clk[usb_div_post], "per", "imx-udc-mx31"); > + clk_register_clkdev(clk[usb_gate], "ahb", "imx-udc-mx31"); > + clk_register_clkdev(clk[ipg], "ipg", "imx-udc-mx31"); > clk_register_clkdev(clk[csi_gate], NULL, "mx3-camera.0"); > /* i.mx31 has the i.mx21 type uart */ > clk_register_clkdev(clk[uart1_gate], "per", "imx21-uart.0"); > diff --git a/arch/arm/mach-imx/clk-imx35.c b/arch/arm/mach-imx/clk-imx35.c > index 66f3d65..69fe9c8 100644 > --- a/arch/arm/mach-imx/clk-imx35.c > +++ b/arch/arm/mach-imx/clk-imx35.c > @@ -251,9 +251,9 @@ int __init mx35_clocks_init() > clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.2"); > clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.2"); > clk_register_clkdev(clk[usbotg_gate], "ahb", "mxc-ehci.2"); > - clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc"); > - clk_register_clkdev(clk[ipg], "ipg", "fsl-usb2-udc"); > - clk_register_clkdev(clk[usbotg_gate], "ahb", "fsl-usb2-udc"); > + clk_register_clkdev(clk[usb_div]
Re: Build regressions/improvements in v3.8-rc3
On Fri, 11 Jan 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.8-rc3 to v3.8-rc2[3], the summaries are:
> - build errors: +2/-414
+ arch/powerpc/sysdev/mpic.c: error: case label does not reduce to an integer
constant: => 890:9, 898:9, 886:9, 894:9
+ error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: => N/A
powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/5780/ (all 117 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/5767/ (all 117 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Interrupt handler not executed
On 01/11/2013 01:36:29 AM, r.pa...@mei-india.com wrote: Hello, We are working on board based on Freescale MPC8313ERDB. We have ported linux 3.0.46 kernel on it. In one of device driver written by us, we need to take some action upon asserting IRQ0 interrupt. For this we have written interrupt handler which takes care of this. We are able register interrupt handler successfully with the help of 'request_irq'. We confirmed this by checking respective entry in '/proc/interrupts'. We have also confirmed assertion of interrupt line (IRQ0) on oscilloscope. The problem is, interrupt handler does not execute upon asserting the interrupt line. What IRQ number did you pass to request_irq()? request_irq() takes virtual interrupt numbers, not anything out of the chip manual. If that's not the issue, is the interrupt configured properly for level and sense? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] perf/Power: PERF_EVENT_IOC_ENABLE does not reenable event
If we disable a perf event because we exceeded the specified ->event_limit, power_pmu_stop() sets the PERF_HES_STOPPED flag on the event. If the application then re-enables the event using PERF_EVENT_IOC_ENABLE ioctl, we don't seem to ever clear this STOPPED flag. Consequently, the user space is never notified of the event. Following message has more background and test case. http://lists.eecs.utk.edu/pipermail/ptools-perfapi/2012-October/002528.html The problem reported there does not seem to occur on x86. My unverified theory: Both x86 and Power clear the event->hw.state flag to 0 in their ->pmu_start() operations. On X86 x86_pmu_start() is called from x86_pmu_enable(). But on Power, power_pmu_start() is not called from power_pmu_enable(). Used the following test cases to verify that this patch works on latest PAPI. $ papi.git/src/ctests/nonthread PAPI_TOT_CYC@500 $ papi.git/src/ctests/overflow_single_event Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/perf/core-book3s.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c index aa2465e..a6faada 100644 --- a/arch/powerpc/perf/core-book3s.c +++ b/arch/powerpc/perf/core-book3s.c @@ -880,8 +880,16 @@ static int power_pmu_add(struct perf_event *event, int ef_flags) cpuhw->events[n0] = event->hw.config; cpuhw->flags[n0] = event->hw.event_base; + /* +* If this event was disabled in record_and_restart() because we +* exceeded the ->event_limit, this is probably a good time to +* re-enable the event ? If we don't reenable the event, we will +* never notify the user again about this event. +*/ if (!(ef_flags & PERF_EF_START)) event->hw.state = PERF_HES_STOPPED | PERF_HES_UPTODATE; + else + event->hw.state &= ~PERF_HES_STOPPED; /* * If group events scheduling transaction was started, -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 02/12] ACPI: Add sys_hotplug.h for system device hotplug framework
On Thursday, January 10, 2013 04:40:20 PM Toshi Kani wrote: > Added include/acpi/sys_hotplug.h, which is ACPI-specific system > device hotplug header and defines the order values of ACPI-specific > handlers. > > Signed-off-by: Toshi Kani > --- > include/acpi/sys_hotplug.h | 48 > > 1 file changed, 48 insertions(+) > create mode 100644 include/acpi/sys_hotplug.h > > diff --git a/include/acpi/sys_hotplug.h b/include/acpi/sys_hotplug.h > new file mode 100644 > index 000..ad80f61 > --- /dev/null > +++ b/include/acpi/sys_hotplug.h > @@ -0,0 +1,48 @@ > +/* > + * sys_hotplug.h - ACPI System device hot-plug framework > + * > + * Copyright (C) 2012 Hewlett-Packard Development Company, L.P. > + * Toshi Kani > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#ifndef _ACPI_SYS_HOTPLUG_H > +#define _ACPI_SYS_HOTPLUG_H > + > +#include > +#include > +#include > + > +/* > + * System device hot-plug operation proceeds in the following order. > + * Validate phase -> Execute phase -> Commit phase > + * > + * The order values below define the calling sequence of ACPI-specific > + * handlers for each phase in ascending order. The order value of > + * platform-neutral handlers are defined in . > + */ > + > +/* Add Validate order values */ > +#define SHP_ACPI_BUS_ADD_VALIDATE_ORDER 0 /* must be > first */ > + > +/* Add Execute order values */ > +#define SHP_ACPI_BUS_ADD_EXECUTE_ORDER 10 > +#define SHP_ACPI_RES_ADD_EXECUTE_ORDER 20 > + > +/* Add Commit order values */ > +#define SHP_ACPI_BUS_ADD_COMMIT_ORDER10 > + > +/* Delete Validate order values */ > +#define SHP_ACPI_BUS_DEL_VALIDATE_ORDER 0 /* must be > first */ > +#define SHP_ACPI_RES_DEL_VALIDATE_ORDER 10 > + > +/* Delete Execute order values */ > +#define SHP_ACPI_BUS_DEL_EXECUTE_ORDER 100 > + > +/* Delete Commit order values */ > +#define SHP_ACPI_BUS_DEL_COMMIT_ORDER100 > + > +#endif /* _ACPI_SYS_HOTPLUG_H */ > -- Why did you use the particular values above? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Thursday, January 10, 2013 04:40:19 PM Toshi Kani wrote:
> Added include/linux/sys_hotplug.h, which defines the system device
> hotplug framework interfaces used by the framework itself and
> handlers.
>
> The order values define the calling sequence of handlers. For add
> execute, the ordering is ACPI->MEM->CPU. Memory is onlined before
> CPU so that threads on new CPUs can start using their local memory.
> The ordering of the delete execute is symmetric to the add execute.
>
> struct shp_request defines a hot-plug request information. The
> device resource information is managed with a list so that a single
> request may target to multiple devices.
>
> Signed-off-by: Toshi Kani
> ---
> include/linux/sys_hotplug.h | 181
> +++
> 1 file changed, 181 insertions(+)
> create mode 100644 include/linux/sys_hotplug.h
>
> diff --git a/include/linux/sys_hotplug.h b/include/linux/sys_hotplug.h
> new file mode 100644
> index 000..86674dd
> --- /dev/null
> +++ b/include/linux/sys_hotplug.h
> @@ -0,0 +1,181 @@
> +/*
> + * sys_hotplug.h - System device hot-plug framework
> + *
> + * Copyright (C) 2012 Hewlett-Packard Development Company, L.P.
> + * Toshi Kani
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _LINUX_SYS_HOTPLUG_H
> +#define _LINUX_SYS_HOTPLUG_H
> +
> +#include
> +#include
> +
> +/*
> + * System device hot-plug operation proceeds in the following order.
> + * Validate phase -> Execute phase -> Commit phase
> + *
> + * The order values below define the calling sequence of platform
> + * neutral handlers for each phase in ascending order. The order
> + * values of firmware-specific handlers are defined in sys_hotplug.h
> + * under firmware specific directories.
> + */
> +
> +/* All order values must be smaller than this value */
> +#define SHP_ORDER_MAX0xff
> +
> +/* Add Validate order values */
> +
> +/* Add Execute order values */
> +#define SHP_MEM_ADD_EXECUTE_ORDER100
> +#define SHP_CPU_ADD_EXECUTE_ORDER110
> +
> +/* Add Commit order values */
> +
> +/* Delete Validate order values */
> +#define SHP_CPU_DEL_VALIDATE_ORDER 100
> +#define SHP_MEM_DEL_VALIDATE_ORDER 110
> +
> +/* Delete Execute order values */
> +#define SHP_CPU_DEL_EXECUTE_ORDER10
> +#define SHP_MEM_DEL_EXECUTE_ORDER20
> +
> +/* Delete Commit order values */
> +
> +/*
> + * Hot-plug request types
> + */
> +#define SHP_REQ_ADD 0x00
> +#define SHP_REQ_DELETE 0x01
> +#define SHP_REQ_MASK 0xff
> +
> +/*
> + * Hot-plug phase types
> + */
> +#define SHP_PH_VALIDATE 0x00
> +#define SHP_PH_EXECUTE 0x000100
> +#define SHP_PH_COMMIT0x000200
> +#define SHP_PH_MASK 0x00ff00
> +
> +/*
> + * Hot-plug operation types
> + */
> +#define SHP_OP_HOTPLUG 0x00
> +#define SHP_OP_ONLINE0x01
> +#define SHP_OP_MASK 0xff
> +
> +/*
> + * Hot-plug phases
> + */
> +enum shp_phase {
> + SHP_ADD_VALIDATE= (SHP_REQ_ADD|SHP_PH_VALIDATE),
> + SHP_ADD_EXECUTE = (SHP_REQ_ADD|SHP_PH_EXECUTE),
> + SHP_ADD_COMMIT = (SHP_REQ_ADD|SHP_PH_COMMIT),
> + SHP_DEL_VALIDATE= (SHP_REQ_DELETE|SHP_PH_VALIDATE),
> + SHP_DEL_EXECUTE = (SHP_REQ_DELETE|SHP_PH_EXECUTE),
> + SHP_DEL_COMMIT = (SHP_REQ_DELETE|SHP_PH_COMMIT)
> +};
> +
> +/*
> + * Hot-plug operations
> + */
> +enum shp_operation {
> + SHP_HOTPLUG_ADD = (SHP_OP_HOTPLUG|SHP_REQ_ADD),
> + SHP_HOTPLUG_DEL = (SHP_OP_HOTPLUG|SHP_REQ_DELETE),
> + SHP_ONLINE_ADD = (SHP_OP_ONLINE|SHP_REQ_ADD),
> + SHP_ONLINE_DEL = (SHP_OP_ONLINE|SHP_REQ_DELETE)
> +};
> +
> +/*
> + * Hot-plug device classes
> + */
> +enum shp_class {
> + SHP_CLS_INVALID = 0,
> + SHP_CLS_CPU = 1,
> + SHP_CLS_MEMORY = 2,
> + SHP_CLS_HOSTBRIDGE = 3,
> + SHP_CLS_CONTAINER = 4,
> +};
> +
> +/*
> + * Hot-plug device information
> + */
> +union shp_dev_info {
> + struct shp_cpu {
> + u32 cpu_id;
> + } cpu;
> +
> + struct shp_memory {
> + int node;
> + u64 start_addr;
> + u64 length;
> + } mem;
> +
> + struct shp_hostbridge {
> + } hb;
> +
> + struct shp_node {
> + } node;
> +};
> +
> +struct shp_device {
> + struct list_headlist;
> + struct device *device;
> + enum shp_class class;
> + union shp_dev_info info;
> +};
> +
> +/*
> + * Hot-plug request
> + */
> +struct shp_request {
> + /* common info */
> + enum shp_operation operati
[PATCH 2/2] powerpc/fsl: remove CONFIG_IRQ_ALL_CPUS from mpc85xx/mpc86xx defconfig
While this should be harmless now that distribute_irqs obeys MPIC_SINGLE_DEST_CPU, there's no reason to enable this on mpc85xx/mpc86xx since MPIC_SINGLE_DEST_CPU will always be set. Signed-off-by: Scott Wood --- arch/powerpc/configs/85xx/ge_imp3a_defconfig |1 - arch/powerpc/configs/86xx/gef_ppc9a_defconfig |1 - arch/powerpc/configs/86xx/gef_sbc310_defconfig |1 - arch/powerpc/configs/86xx/gef_sbc610_defconfig |1 - arch/powerpc/configs/86xx/sbc8641d_defconfig |1 - arch/powerpc/configs/corenet32_smp_defconfig |1 - arch/powerpc/configs/corenet64_smp_defconfig |1 - arch/powerpc/configs/mpc85xx_smp_defconfig |1 - 8 files changed, 8 deletions(-) diff --git a/arch/powerpc/configs/85xx/ge_imp3a_defconfig b/arch/powerpc/configs/85xx/ge_imp3a_defconfig index f8c51a4..c9765b5 100644 --- a/arch/powerpc/configs/85xx/ge_imp3a_defconfig +++ b/arch/powerpc/configs/85xx/ge_imp3a_defconfig @@ -34,7 +34,6 @@ CONFIG_PREEMPT=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m CONFIG_MATH_EMULATION=y -CONFIG_IRQ_ALL_CPUS=y CONFIG_FORCE_MAX_ZONEORDER=17 CONFIG_PCI=y CONFIG_PCIEPORTBUS=y diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig index da731c2..f2f6734 100644 --- a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig +++ b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig @@ -25,7 +25,6 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_HZ_1000=y CONFIG_PREEMPT=y CONFIG_BINFMT_MISC=m -CONFIG_IRQ_ALL_CPUS=y CONFIG_SPARSE_IRQ=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y diff --git a/arch/powerpc/configs/86xx/gef_sbc310_defconfig b/arch/powerpc/configs/86xx/gef_sbc310_defconfig index 2149360..be73219 100644 --- a/arch/powerpc/configs/86xx/gef_sbc310_defconfig +++ b/arch/powerpc/configs/86xx/gef_sbc310_defconfig @@ -25,7 +25,6 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_HZ_1000=y CONFIG_PREEMPT=y CONFIG_BINFMT_MISC=y -CONFIG_IRQ_ALL_CPUS=y CONFIG_SPARSE_IRQ=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig b/arch/powerpc/configs/86xx/gef_sbc610_defconfig index af2e8e1..b3e2b10 100644 --- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig +++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig @@ -25,7 +25,6 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_HZ_1000=y CONFIG_PREEMPT=y CONFIG_BINFMT_MISC=m -CONFIG_IRQ_ALL_CPUS=y CONFIG_SPARSE_IRQ=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y diff --git a/arch/powerpc/configs/86xx/sbc8641d_defconfig b/arch/powerpc/configs/86xx/sbc8641d_defconfig index 0a92ca0..1a62baf 100644 --- a/arch/powerpc/configs/86xx/sbc8641d_defconfig +++ b/arch/powerpc/configs/86xx/sbc8641d_defconfig @@ -23,7 +23,6 @@ CONFIG_SBC8641D=y CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT=y CONFIG_BINFMT_MISC=m -CONFIG_IRQ_ALL_CPUS=y CONFIG_SPARSE_IRQ=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig index 1c0f243..60027c2 100644 --- a/arch/powerpc/configs/corenet32_smp_defconfig +++ b/arch/powerpc/configs/corenet32_smp_defconfig @@ -32,7 +32,6 @@ CONFIG_HIGHMEM=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m CONFIG_KEXEC=y -CONFIG_IRQ_ALL_CPUS=y CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_PCI=y CONFIG_PCIEPORTBUS=y diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 88fa5c4..7375961 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -26,7 +26,6 @@ CONFIG_P5020_DS=y CONFIG_P5040_DS=y # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set CONFIG_BINFMT_MISC=m -CONFIG_IRQ_ALL_CPUS=y CONFIG_PCIEPORTBUS=y CONFIG_PCI_MSI=y CONFIG_RAPIDIO=y diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig index 502cd9e..8d00ea5b 100644 --- a/arch/powerpc/configs/mpc85xx_smp_defconfig +++ b/arch/powerpc/configs/mpc85xx_smp_defconfig @@ -49,7 +49,6 @@ CONFIG_QE_GPIO=y CONFIG_HIGHMEM=y CONFIG_BINFMT_MISC=m CONFIG_MATH_EMULATION=y -CONFIG_IRQ_ALL_CPUS=y CONFIG_FORCE_MAX_ZONEORDER=12 CONFIG_PCI=y CONFIG_PCI_MSI=y -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/mpic: make distribute_irqs obey MPIC_SINGLE_DEST_CPU
Previously we were setting an illegal configuration on mpc85xx MPICs if CONFIG_IRQ_ALL_CPUS is enabled (which for some reason it is in mpc85xx_smp_defconfig). Signed-off-by: Scott Wood --- arch/powerpc/sysdev/mpic.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c index 3b2efd4..6694425 100644 --- a/arch/powerpc/sysdev/mpic.c +++ b/arch/powerpc/sysdev/mpic.c @@ -54,7 +54,7 @@ static DEFINE_RAW_SPINLOCK(mpic_lock); #ifdef CONFIG_PPC32/* XXX for now */ #ifdef CONFIG_IRQ_ALL_CPUS -#define distribute_irqs(1) +#define distribute_irqs(!(mpic->flags & MPIC_SINGLE_DEST_CPU)) #else #define distribute_irqs(0) #endif -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.8-rc3
Spark mantainer ?
"To make this mail fit in the lkml limit, I deleted
- 3996 lines about __mcount_loc on sparc64"
On Fri, Jan 11, 2013 at 6:07 PM, Geert Uytterhoeven
wrote:
> On Fri, 11 Jan 2013, Geert Uytterhoeven wrote:
>> JFYI, when comparing v3.8-rc3 to v3.8-rc2[3], the summaries are:
>> - build errors: +2/-414
>
> + arch/powerpc/sysdev/mpic.c: error: case label does not reduce to an
> integer constant: => 890:9, 898:9, 886:9, 894:9
> + error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: =>
> N/A
>
> powerpc-randconfig
>
>> [1] http://kisskb.ellerman.id.au/kisskb/head/5780/ (all 117 configs)
>> [3] http://kisskb.ellerman.id.au/kisskb/head/5767/ (all 117 configs)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PS3 platform is broken on Linux 3.7.0
Hi, On Thu, 2012-12-20 at 08:53 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2012-12-14 at 16:35 +0400, Phileas Fogg wrote: > > Hi, > > > > I wanted to bring to your attention the fact that the PS3 platform is > > broken on Linux 3.7.0. > > > > i'm not able to boot Linux 3.7.0 on my PS3 slim. Linux 3.6.10 boots just > > fine but not 3.7.0 > > When i try to boot Linux 3.7.0 then my PS3 shuts down. > > > > So i cloned the Linux powerpc GIT repository and tried to find out which > > commits broke the PS3 platform. > > After some time I tracked it down to 2 commits: > > Aneesh, do you have any idea what might be going on there ? Can you look > at the PS3 hash code ? It's a bit different from the rest, you might > have missed an update or two... > Michael, same deal with PACA... I checked these, and Michael's 407821a34fce89b4f0b031dbab5cec7d059f46bc does indeed cause the LV1 hypervisor to panic early, and if that is reverted, Aneesh's 048ee0993ec8360abb0b51bdf8f8721e9ed62ec4 hits a BUG. I'll look at it some more next week. -Geoff > > - > > > > commit 407821a34fce89b4f0b031dbab5cec7d059f46bc > > Author: Michael Ellerman > > Date: Fri Sep 7 15:31:44 2012 + > > > > powerpc: Initialise paca.data_offset with poison > > > > It's possible for the cpu_possible_mask to change between the time we > > initialise the pacas and the time we setup per_cpu areas. > > > > Obviously impossible cpus shouldn't ever be running, but stranger things > > have happened. So be paranoid and initialise data_offset with a poison > > value in case we don't set it up later. > > > > Based on a patch from Anton Blanchard. > > > > Signed-off-by: Michael Ellerman > > Signed-off-by: Benjamin Herrenschmidt > > > > > > > > > > commit 048ee0993ec8360abb0b51bdf8f8721e9ed62ec4 > > Author: Aneesh Kumar K.V > > Date: Mon Sep 10 02:52:55 2012 + > > > > powerpc/mm: Add 64TB support > > > > Increase max addressable range to 64TB. This is not tested on > > real hardware yet. > > > > Reviewed-by: Paul Mackerras > > Signed-off-by: Aneesh Kumar K.V > > Signed-off-by: Benjamin Herrenschmidt > > > > -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
