* [PATCH v5] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-12-09 4:24 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: rsarmah
This fix is a reset for USB PHY that requires some amount of time for power to be stable on Canyonlands.
Signed-off-by: Rupjyoti Sarmah <rsarmah@apm.com>
---
changes from previous version:
-- dts node correction, removed the address and size parameters
-- Kconfig file updated removing dependency on PPC44x_SIMPLE
-- 44x prefixes in the function names changed
-- Error paths updated in canyonlands.c
arch/powerpc/boot/dts/canyonlands.dts | 11 +++
arch/powerpc/platforms/44x/44x.h | 4 +
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/canyonlands.c | 125 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 -
6 files changed, 141 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..8ff1f3f 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -224,6 +224,11 @@
};
};
+ cpld@2,0 {
+ compatible = "amcc,ppc460ex-bcsr";
+ reg = <2 0x0 0x9>;
+ };
+
ndfc@3,0 {
compatible = "ibm,ndfc";
reg = <0x00000003 0x00000000 0x00002000>;
@@ -320,6 +325,12 @@
interrupts = <0x3 0x4>;
};
+ GPIO0: gpio@ef600b00 {
+ compatible = "ibm,ppc4xx-gpio";
+ reg = <0xef600b00 0x00000048>;
+ gpio-controller;
+ };
+
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <0xef600d00 0x0000000c>;
diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
index dbc4d2b..63f703e 100644
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -4,4 +4,8 @@
extern u8 as1_readb(volatile u8 __iomem *addr);
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
+#define GPIO0_OSRH 0xC
+#define GPIO0_TSRH 0x14
+#define GPIO0_ISR1H 0x34
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0f979c5..f485fc5 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -115,7 +115,6 @@ config CANYONLANDS
bool "Canyonlands"
depends on 44x
default n
- select PPC44x_SIMPLE
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..6854e73 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
+obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
new file mode 100644
index 0000000..9639709
--- /dev/null
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -0,0 +1,125 @@
+/*
+ * This contain platform specific code for APM PPC460EX based Canyonlands
+ * board.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Rupjyoti Sarmah <rsarmah@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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/init.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+#include <asm/udbg.h>
+#include <asm/uic.h>
+#include <linux/of_platform.h>
+#include <linux/delay.h>
+#include "44x.h"
+
+#define BCSR_USB_EN 0x11
+
+static __initdata struct of_device_id ppc460ex_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc460ex_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc460ex_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc460ex_device_probe);
+
+/* Using this code only for the Canyonlands board. */
+
+static int __init ppc460ex_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
+ return 1;
+ }
+ return 0;
+}
+
+/* USB PHY fixup code on Canyonlands kit. */
+
+static int __init ppc460ex_canyonlands_fixup(void)
+{
+ u8 __iomem *bcsr ;
+ void __iomem *vaddr;
+ struct device_node *np;
+ int ret = 0;
+
+ np = of_find_compatible_node(NULL, NULL, "amcc,ppc460ex-bcsr");
+ if (!np) {
+ printk(KERN_ERR "failed did not find amcc, ppc460ex bcsr node\n");
+ return -ENODEV;
+ }
+
+ bcsr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!bcsr) {
+ printk(KERN_CRIT "Could not remap bcsr\n");
+ ret = -ENODEV;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
+ vaddr = of_iomap(np, 0);
+ if (!vaddr) {
+ printk(KERN_CRIT "Could not get gpio node address\n");
+ ret = -ENODEV;
+ goto err_bcsr;
+ }
+ /* Disable USB, through the BCSR7 bits */
+ setbits8(&bcsr[7], BCSR_USB_EN);
+
+ /* Wait for a while after reset */
+ msleep(100);
+
+ /* Enable USB here */
+ clrbits8(&bcsr[7], BCSR_USB_EN);
+
+ /*
+ * Configure multiplexed gpio16 and gpio19 as alternate1 output
+ * source after USB reset. In this configuration gpio16 will be
+ * USB2HStop and gpio19 will be USB2DStop. For more details refer to
+ * table 34-7 of PPC460EX user manual.
+ */
+ setbits32((vaddr + GPIO0_OSRH), 0x42000000);
+ setbits32((vaddr + GPIO0_TSRH), 0x42000000);
+ of_node_put(np);
+err_bcsr:
+ iounmap(bcsr);
+ return ret;
+}
+machine_device_initcall(canyonlands, ppc460ex_canyonlands_fixup);
+define_machine(canyonlands) {
+ .name = "Canyonlands",
+ .probe = ppc460ex_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 7ddcba3..c81c19c 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -53,7 +53,6 @@ static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
"amcc,bluestone",
- "amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
"amcc,eiger",
--
1.5.6.3
^ permalink raw reply related
* Re: [RFC PATCH 6/7 v2] ppc/iommu: pass phb only to iommu_table_setparms_lpar
From: Benjamin Herrenschmidt @ 2010-12-09 4:24 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: sonnyrao, miltonm, Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <1288150518-4026-7-git-send-email-nacc@us.ibm.com>
On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
> iommu_table_setparms_lpar needs either the phb or the subbusnumber
> (not both), pass the phb to make it similar to iommu_table_setparms.
>
> Note: In cases where a caller was passing bus->number previously to
> iommu_table_setparms_lpar() rather than phb->bus->number, this can lead
> to a different value in tbl->it_busno. The only example of this was the
> removed pci_dma_dev_setup_pSeriesLP(), removed in "ppc/iommu: remove
> unneeded pci_dma_dev_setup_pSeriesLP".
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> ---
> arch/powerpc/platforms/pseries/iommu.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 9d564b9..45c6865 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -323,14 +323,13 @@ static void iommu_table_setparms(struct pci_controller *phb,
> static void iommu_table_setparms_lpar(struct pci_controller *phb,
> struct device_node *dn,
> struct iommu_table *tbl,
> - const void *dma_window,
> - int bussubno)
> + const void *dma_window)
> {
> unsigned long offset, size;
>
> - tbl->it_busno = bussubno;
> of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
>
> + tbl->it_busno = phb->bus->number;
> tbl->it_base = 0;
> tbl->it_blocksize = 16;
> tbl->it_type = TCE_PCI;
> @@ -534,8 +533,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> if (!pci->iommu_table) {
> tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
> pci->phb->node);
> - iommu_table_setparms_lpar(pci->phb, pdn, tbl, dma_window,
> - pci->phb->bus->number);
> + iommu_table_setparms_lpar(pci->phb, pdn, tbl, dma_window);
> pci->iommu_table = iommu_init_table(tbl, pci->phb->node);
> pr_debug(" created table: %p\n", pci->iommu_table);
> } else {
There's another caller :-) I've fixed that up locally and will push with
the fix.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc, 5200: add support for charon board
From: Heiko Schocher @ 2010-12-09 6:43 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101208154911.GE4641@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Tue, Dec 07, 2010 at 07:58:55AM +0100, Heiko Schocher wrote:
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>
> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Thanks!
One more defconfig question:
Is it possible to add to the mpc5200_defconfig, what is needed for
this board to compile a kernel which contains all features it needs?
I need:
CONFIG_HWMON
CONFIG_SENSORS_LM80
CONFIG_RTC_LIB
CONFIG_RTC_CLASS
CONFIG_RTC_HCTOSYS
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS
CONFIG_RTC_INTF_PROC
CONFIG_RTC_INTF_DEV
CONFIG_RTC_DRV_DS1374
I think, to have a DTS in kernel for a board, and no defconfig, which
builds a kernel with all features for it, is suboptimal, or?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Greg KH @ 2010-12-09 6:47 UTC (permalink / raw)
To: tmarri; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1291854539-23879-1-git-send-email-tmarri@apm.com>
On Wed, Dec 08, 2010 at 04:28:59PM -0800, tmarri@apm.com wrote:
> From: Tirumala Marri <tmarri@apm.com>
>
> v6:
> 1. Replaced register definitions and bit fields with macros.
> 2. Replace printks with dev_dbg or dev_err functions.
> 3. Cleanup some assignments.
> 4. Remove chip specific selections in Kconfig file.
Much nicer, thanks.
Do you wish for me to apply this to the tree if it passes review?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
From: Heiko Schocher @ 2010-12-09 6:49 UTC (permalink / raw)
To: Paul Mundt
Cc: linux-fbdev, devicetree-discuss, linuxppc-dev, Samuel Ortiz,
Ben Dooks
In-Reply-To: <20101208053635.GB31508@linux-sh.org>
Hello Paul,
Paul Mundt wrote:
> On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote:
>> - add binding to OF, compatible name "smi,sm501"
>>
[...]
>> Documentation/kernel-parameters.txt | 7 +
>> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
>> drivers/mfd/sm501.c | 141 ++++++++------
>> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
>> include/linux/sm501.h | 8 +
>> 5 files changed, 299 insertions(+), 151 deletions(-)
>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>>
> Given that this is all SM501 dependent, is there some particular reason
> why you neglected to Cc the author or the MFD folks?
Hups, sorry! No, there is no reason, thanks for detecting this.
Hmm.. couldn;t find a MFD maillinglist?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH] powerpc: iommu: Add device name to iommu error printks
From: Olof Johansson @ 2010-12-09 7:07 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20101208113605.38ac68a9@kryten>
On Wed, Dec 08, 2010 at 11:36:05AM +1100, Anton Blanchard wrote:
>
> Right now its difficult to see which device is running out of iommu space:
>
> iommu_alloc failed, tbl c00000076e096660 vaddr c000000768806600 npages 1
>
> Use dev_info() so we get the device name and location:
>
> ipr 0000:00:01.0: iommu_alloc failed, tbl c00000076e096660 vaddr c000000768806600 npages 1
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* [PATCH] fsldma: fix issue of slow dma
From: Li Yang @ 2010-12-09 8:14 UTC (permalink / raw)
To: dan.j.williams; +Cc: linuxppc-dev, linux-kernel
From: Forrest Shi <b29237@freescale.com>
Fixed fsl dma slow issue by initializing dma mode register with
bandwidth control. It boosts dma performance and should works
with 85xx board.
Signed-off-by: Forrest Shi <b29237@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/dma/fsldma.c | 6 ++++--
drivers/dma/fsldma.h | 9 ++++++++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 286c3ac..e5e172d 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -50,9 +50,11 @@ static void dma_init(struct fsldma_chan *chan)
* EIE - Error interrupt enable
* EOSIE - End of segments interrupt enable (basic mode)
* EOLNIE - End of links interrupt enable
+ * BWC - Bandwidth sharing among channels
*/
- DMA_OUT(chan, &chan->regs->mr, FSL_DMA_MR_EIE
- | FSL_DMA_MR_EOLNIE | FSL_DMA_MR_EOSIE, 32);
+ DMA_OUT(chan, &chan->regs->mr, FSL_DMA_MR_BWC
+ | FSL_DMA_MR_EIE | FSL_DMA_MR_EOLNIE
+ | FSL_DMA_MR_EOSIE, 32);
break;
case FSL_DMA_IP_83XX:
/* Set the channel to below modes:
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index cb4d6ff..ba9f403 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007-2010 Freescale Semiconductor, Inc. All rights reserved.
*
* Author:
* Zhang Wei <wei.zhang@freescale.com>, Jul 2007
@@ -36,6 +36,13 @@
#define FSL_DMA_MR_DAHE 0x00002000
#define FSL_DMA_MR_SAHE 0x00001000
+/*
+ * Bandwidth/pause control determines how many bytes a given
+ * channel is allowed to transfer before the DMA engine pauses
+ * the current channel and switches to the next channel
+ */
+#define FSL_DMA_MR_BWC 0x08000000
+
/* Special MR definition for MPC8349 */
#define FSL_DMA_MR_EOTIE 0x00000080
#define FSL_DMA_MR_PRC_RM 0x00000800
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [PATCH v2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-09 10:39 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <4D007AA8.9050101@denx.de>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
> Is it possible to add to the mpc5200_defconfig, what is needed for
> this board to compile a kernel which contains all features it needs?
Just add it as modules.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V6 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: Sergei Shtylyov @ 2010-12-09 13:24 UTC (permalink / raw)
To: tmarri; +Cc: Mark Miesfeld, linux-usb, linuxppc-dev, Fushen Chen
In-Reply-To: <1291854755-25103-1-git-send-email-tmarri@apm.com>
Hello.
On 09-12-2010 3:32, tmarri@apm.com wrote:
> From: Tirumala Marri<tmarri@apm.com>
> Enable gadget support
> Signed-off-by: Tirumala R Marri<tmarri@apm.com>
> Signed-off-by: Fushen Chen<fchen@apm.com>
> Signed-off-by: Mark Miesfeld<mmiesfeld@apm.com>
[...]
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index 747b0d3..b2bcc4e 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC
[...]
> +config USB_OTG
> + boolean "OTG Support"
This symbol is already defined in drivers/usb/core/Kconfig.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
From: Samuel Ortiz @ 2010-12-09 15:03 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, Paul Mundt, linuxppc-dev, Ben Dooks,
devicetree-discuss
In-Reply-To: <4D007C09.3040308@denx.de>
Hi Heiko,
On Thu, Dec 09, 2010 at 07:49:45AM +0100, Heiko Schocher wrote:
> Hello Paul,
>
> Paul Mundt wrote:
> > On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote:
> >> - add binding to OF, compatible name "smi,sm501"
> >>
> [...]
> >> Documentation/kernel-parameters.txt | 7 +
> >> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> >> drivers/mfd/sm501.c | 141 ++++++++------
> >> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> >> include/linux/sm501.h | 8 +
> >> 5 files changed, 299 insertions(+), 151 deletions(-)
> >> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
> >>
> > Given that this is all SM501 dependent, is there some particular reason
> > why you neglected to Cc the author or the MFD folks?
>
> Hups, sorry! No, there is no reason, thanks for detecting this.
>
> Hmm.. couldn;t find a MFD maillinglist?
We use lkml. Could you please re-send the patch to me ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [RFC PATCH 6/7 v2] ppc/iommu: pass phb only to iommu_table_setparms_lpar
From: Nishanth Aravamudan @ 2010-12-09 16:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, sonnyrao, Paul Mackerras, Anton Blanchard, miltonm
In-Reply-To: <1291868679.16694.221.camel@pasglop>
On 09.12.2010 [15:24:39 +1100], Benjamin Herrenschmidt wrote:
> On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
> > iommu_table_setparms_lpar needs either the phb or the subbusnumber
> > (not both), pass the phb to make it similar to iommu_table_setparms.
> >
> > Note: In cases where a caller was passing bus->number previously to
> > iommu_table_setparms_lpar() rather than phb->bus->number, this can lead
> > to a different value in tbl->it_busno. The only example of this was the
> > removed pci_dma_dev_setup_pSeriesLP(), removed in "ppc/iommu: remove
> > unneeded pci_dma_dev_setup_pSeriesLP".
> >
> > Signed-off-by: Milton Miller <miltonm@bga.com>
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/iommu.c | 8 +++-----
> > 1 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> > index 9d564b9..45c6865 100644
> > --- a/arch/powerpc/platforms/pseries/iommu.c
> > +++ b/arch/powerpc/platforms/pseries/iommu.c
> > @@ -323,14 +323,13 @@ static void iommu_table_setparms(struct pci_controller *phb,
> > static void iommu_table_setparms_lpar(struct pci_controller *phb,
> > struct device_node *dn,
> > struct iommu_table *tbl,
> > - const void *dma_window,
> > - int bussubno)
> > + const void *dma_window)
> > {
> > unsigned long offset, size;
> >
> > - tbl->it_busno = bussubno;
> > of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
> >
> > + tbl->it_busno = phb->bus->number;
> > tbl->it_base = 0;
> > tbl->it_blocksize = 16;
> > tbl->it_type = TCE_PCI;
> > @@ -534,8 +533,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> > if (!pci->iommu_table) {
> > tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
> > pci->phb->node);
> > - iommu_table_setparms_lpar(pci->phb, pdn, tbl, dma_window,
> > - pci->phb->bus->number);
> > + iommu_table_setparms_lpar(pci->phb, pdn, tbl, dma_window);
> > pci->iommu_table = iommu_init_table(tbl, pci->phb->node);
> > pr_debug(" created table: %p\n", pci->iommu_table);
> > } else {
>
> There's another caller :-) I've fixed that up locally and will push with
> the fix.
Shoot! Thanks for catching that.
-Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2010-12-09 16:45 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <20101209064737.GA10820@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
Yes please.
Regards,
Marri
On Wed, Dec 8, 2010 at 10:47 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Dec 08, 2010 at 04:28:59PM -0800, tmarri@apm.com wrote:
> > From: Tirumala Marri <tmarri@apm.com>
> >
> > v6:
> > 1. Replaced register definitions and bit fields with macros.
> > 2. Replace printks with dev_dbg or dev_err functions.
> > 3. Cleanup some assignments.
> > 4. Remove chip specific selections in Kconfig file.
>
> Much nicer, thanks.
>
> Do you wish for me to apply this to the tree if it passes review?
>
> thanks,
>
> greg k-h
>
[-- Attachment #2: Type: text/html, Size: 970 bytes --]
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2010-12-09 16:47 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <20101209064737.GA10820@kroah.com>
> Much nicer, thanks.
>
> Do you wish for me to apply this to the tree if it passes review?
>
> thanks,
>
> greg k-h
Yes, please.
Thanks,
marri
^ permalink raw reply
* Re: [PATCH V6 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: Tirumala Marri @ 2010-12-09 16:52 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Mark Miesfeld, linux-usb, linuxppc-dev, Fushen Chen
In-Reply-To: <4D00D89B.6020208@ru.mvista.com>
On Thu, Dec 9, 2010 at 5:24 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrot=
e:
> Hello.
>
> On 09-12-2010 3:32, tmarri@apm.com wrote:
>
>> From: Tirumala Marri<tmarri@apm.com>
>
>> Enable gadget support
>
>> Signed-off-by: Tirumala R Marri<tmarri@apm.com>
>> Signed-off-by: Fushen Chen<fchen@apm.com>
>> Signed-off-by: Mark Miesfeld<mmiesfeld@apm.com>
>
> [...]
>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index 747b0d3..b2bcc4e 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC
>
> [...]
>>
>> +config USB_OTG
>> + =A0 =A0 =A0 boolean "OTG Support"
>
> =A0 This symbol is already defined in drivers/usb/core/Kconfig.
>
> WBR, Sergei
>
Sure I will fix that.
Thx,
Marri
^ permalink raw reply
* Re: [RFC PATCH 7/7 v2] ppc: add dynamic dma window support
From: Nishanth Aravamudan @ 2010-12-09 19:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: sonnyrao, miltonm, Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <1291868226.16694.220.camel@pasglop>
On 09.12.2010 [15:17:06 +1100], Benjamin Herrenschmidt wrote:
> On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
>
> No much comments... I'm amazed how complex he firmware folks managed to
> make this ...
>
> > static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long action, void *node)
> > {
> > int err = NOTIFY_OK;
> > struct device_node *np = node;
> > struct pci_dn *pci = PCI_DN(np);
> > + struct direct_window *window;
> >
> > switch (action) {
> > case PSERIES_RECONFIG_REMOVE:
> > if (pci && pci->iommu_table)
> > iommu_free_table(pci->iommu_table, np->full_name);
> > +
> > + spin_lock(&direct_window_list_lock);
> > + list_for_each_entry(window, &direct_window_list, list) {
> > + if (window->device == np) {
> > + list_del(&window->list);
> > + break;
> > + }
> > + }
> > + spin_unlock(&direct_window_list_lock);
>
> Should you also kfree the window ?
Yeah, looks like I should. I have a few other questions due to testing,
but I'll reply to my original e-mail with those.
Thanks for the review!
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC PATCH 7/7 v2] ppc: add dynamic dma window support
From: Nishanth Aravamudan @ 2010-12-09 19:09 UTC (permalink / raw)
To: sonnyrao, miltonm, Benjamin Herrenschmidt, Paul Mackerras,
Grant Likely, Anton Blanchard, linuxppc-dev
In-Reply-To: <1288150518-4026-8-git-send-email-nacc@us.ibm.com>
On 26.10.2010 [20:35:17 -0700], Nishanth Aravamudan wrote:
> If firmware allows us to map all of a partition's memory for DMA on a
> particular bridge, create a 1:1 mapping of that memory. Add hooks for
> dealing with hotplug events. Dyanmic DMA windows can use larger than the
> default page size, and we use the largest one possible.
>
> Not-yet-signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> ---
>
> I've tested this briefly on a machine with suitable firmware/hardware.
> Things seem to work well, but I want to do more exhaustive I/O testing
> before asking for upstream merging. I would really appreciate any
> feedback on the updated approach.
>
> Specific questions:
>
> Ben, did I hook into the dma_set_mask() platform callback as you
> expected? Anything I can do better or which perhaps might lead to
> gotchas later?
>
> I've added a disable_ddw option, but perhaps it would be better to
> just disable the feature if iommu=force?
So for the final version, I probably should document this option in
kernel-parameters.txt w/ the patch, right?
<snip>
> +static int tce_clearrange_multi_pSeriesLP(unsigned long start_pfn,
> + unsigned long num_pfn, const void *arg)
> +{
> + const struct dynamic_dma_window_prop *maprange = arg;
> + int rc;
> + u64 tce_size, num_tce, dma_offset, next;
> + u32 tce_shift;
> + long limit;
> +
> + tce_shift = be32_to_cpu(maprange->tce_shift);
> + tce_size = 1ULL << tce_shift;
> + next = start_pfn << PAGE_SHIFT;
> + num_tce = num_pfn << PAGE_SHIFT;
> +
> + /* round back to the beginning of the tce page size */
> + num_tce += next & (tce_size - 1);
> + next &= ~(tce_size - 1);
> +
> + /* covert to number of tces */
> + num_tce |= tce_size - 1;
> + num_tce >>= tce_shift;
> +
> + do {
> + /*
> + * Set up the page with TCE data, looping through and setting
> + * the values.
> + */
> + limit = min_t(long, num_tce, 512);
> + dma_offset = next + be64_to_cpu(maprange->dma_base);
> +
> + rc = plpar_tce_stuff(be64_to_cpu(maprange->liobn),
> + (u64)dma_offset,
> + 0, limit);
> + num_tce -= limit;
> + } while (num_tce > 0 && !rc);
> +
> + return rc;
> +}
There is a bit of a typo here, the liobn is a 32-bit value. I've fixed
this is up locally and will update it when I send out the final version
of this patch.
I'm finding that on dlpar remove of adapters running in slots supporting
64-bit DMA, that the plpar_tce_stuff is failing. Can you think of a
reason why? It looks basically the same as the put_indirect below...
> +static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
> + unsigned long num_pfn, const void *arg)
> +{
> + const struct dynamic_dma_window_prop *maprange = arg;
> + u64 *tcep, tce_size, num_tce, dma_offset, next, proto_tce, liobn;
> + u32 tce_shift;
> + u64 rc = 0;
> + long l, limit;
> +
> + local_irq_disable(); /* to protect tcep and the page behind it */
> + tcep = __get_cpu_var(tce_page);
> +
> + if (!tcep) {
> + tcep = (u64 *)__get_free_page(GFP_ATOMIC);
> + if (!tcep) {
> + local_irq_enable();
> + return -ENOMEM;
> + }
> + __get_cpu_var(tce_page) = tcep;
> + }
> +
> + proto_tce = TCE_PCI_READ | TCE_PCI_WRITE;
> +
> + liobn = (u64)be32_to_cpu(maprange->liobn);
> + tce_shift = be32_to_cpu(maprange->tce_shift);
> + tce_size = 1ULL << tce_shift;
> + next = start_pfn << PAGE_SHIFT;
> + num_tce = num_pfn << PAGE_SHIFT;
> +
> + /* round back to the beginning of the tce page size */
> + num_tce += next & (tce_size - 1);
> + next &= ~(tce_size - 1);
> +
> + /* covert to number of tces */
> + num_tce |= tce_size - 1;
> + num_tce >>= tce_shift;
> +
> + /* We can map max one pageful of TCEs at a time */
> + do {
> + /*
> + * Set up the page with TCE data, looping through and setting
> + * the values.
> + */
> + limit = min_t(long, num_tce, 4096/TCE_ENTRY_SIZE);
> + dma_offset = next + be64_to_cpu(maprange->dma_base);
> +
> + for (l = 0; l < limit; l++) {
> + tcep[l] = proto_tce | next;
> + next += tce_size;
> + }
> +
> + rc = plpar_tce_put_indirect(liobn,
> + (u64)dma_offset,
> + (u64)virt_to_abs(tcep),
> + limit);
> +
> + num_tce -= limit;
> + } while (num_tce > 0 && !rc);
> + printk("plpar_tce_put_indirect for offset 0x%llx and tcep[0] 0x%llx returned %llu\n",
> + (u64)dma_offset, tcep[0], rc);
> +
I'll cleanup the debugging on the final version too.
<snip>
> +static void remove_ddw(struct device_node *np)
> +{
> + struct dynamic_dma_window_prop *dwp;
> + struct property *win64;
> + const u32 *ddr_avail;
> + u64 liobn;
> + int len, ret;
> +
> + ddr_avail = of_get_property(np, "ibm,ddw-applicable", &len);
> + win64 = of_find_property(np, DIRECT64_PROPNAME, NULL);
> + if (!win64 || !ddr_avail || len < 3 * sizeof(u32))
> + return;
> +
> + dwp = win64->value;
> + liobn = (u64)be32_to_cpu(dwp->liobn);
> +
> + /* clear the whole window, note the arg is in kernel pages */
> + ret = tce_clearrange_multi_pSeriesLP(0,
> + 1ULL << (be32_to_cpu(dwp->window_shift) - PAGE_SHIFT), dwp);
> + if (ret)
> + pr_warning("%s failed to clear tces in window.\n",
> + np->full_name);
> + else
> + pr_warning("%s successfully cleared tces in window.\n",
> + np->full_name);
> +
> + ret = rtas_call(ddr_avail[2], 1, 1, NULL, liobn);
> + if (ret)
> + pr_warning("%s: failed to remove direct window: rtas returned "
> + "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> + np->full_name, ret, ddr_avail[2], liobn);
> + else
> + pr_warning("%s: successfully removed direct window: rtas returned "
> + "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> + np->full_name, ret, ddr_avail[2], liobn);
> +
> + ret = prom_remove_property(np, win64);
> + if (ret)
> + pr_warning("%s: failed to remove direct window property (%i)\n",
> + np->full_name, ret);
> + else
> + pr_warning("%s: successfully removed direct window property (%i)\n",
> + np->full_name, ret);
> +}
When this function gets called on dlpar remove of an adapter, it throws
a proc warning because the property has already been removed from
/proc/device-tree (but not the kernel representation) before the
notifiers get called:
static int pSeries_reconfig_remove_node(struct device_node *np)
{
struct device_node *parent, *child;
parent = of_get_parent(np);
if (!parent)
return -EINVAL;
if ((child = of_get_next_child(np, NULL))) {
of_node_put(child);
of_node_put(parent);
return -EBUSY;
}
remove_node_proc_entries(np);
blocking_notifier_call_chain(&pSeries_reconfig_chain,
PSERIES_RECONFIG_REMOVE, np);
of_detach_node(np);
of_node_put(parent);
of_node_put(np); /* Must decrement the refcount */
return 0;
}
Am I reading that correctly? Should I add a paramter to remove_ddw that
specifies if it is being called from the reconfig notifier (or perhaps
just whether it needs to remove the property)?
Also, just so I understand, it doesn't seem like dlpar provides an
option for the notifier chain to indicate failure (e.g., the tce stuff
failing above) and prevent the dlpar operation. AFAICT after discussing
with the firmware folks, it's actually non-fatal for the TCEs not to be
cleared during the dlpar remove, but seems like it might indicate an
issue if it happens in the field?
Otherwise, I've hit no problems testing this series under load. Once I
get some feedback on these questions, I'll roll out a new version,
hopefully tomorrow, that can be accepted.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Mark Pearson @ 2010-12-09 20:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3872 bytes --]
I have a curious problem. This is on a MPC8636 based platform with
36-bit address space (that may or may not be important).
I have a very simple driver that registers for one of the external IRQs
with a trivial interrupt handler. It works great when built in as part
of the kernel.
However, if I make it a loadable module I get the crash shown below
(blade_irq is my IRQ handler).
-----Console capture ----------------------------------------
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0xf31200f8
Oops: Kernel access of bad area, sig: 11 [#1]
COMPASS
Modules linked in: blade_pnic blade_irq_drv blade_cpld_mmap_drv
NIP: f31200f8 LR: c006a26c CTR: f31200f8
REGS: c057bdd0 TRAP: 0400 Not tainted (2.6.32.12-131)
MSR: 00029000 <EE,ME,CE> CR: 24024048 XER: 00000000
TASK = c0544318[0] 'swapper' THREAD: c057a000
GPR00: 00000000 c057be80 c0544318 00000012 00000000 08f9cac0 c058177c
ef820000
GPR08: 00000200 c04a0000 f31200f8 c058a368 2dc6c000 1012b250 3ffbd200
00000000
GPR16: 3ff91140 3ffb22f8 00000000 00000000 00000000 00000000 00000000
00000000
GPR24: 00000000 00000000 00001600 c049fe4c 00000000 00000000 00000012
ea7975c0
NIP [f31200f8] blade_irq+0x0/0x110 [blade_irq_drv]
LR [c006a26c] handle_IRQ_event+0x64/0x13c
Call Trace:
[c057be80] [c0547b80] 0xc0547b80 (unreliable)
[c057bea0] [c006c41c] handle_fasteoi_irq+0x68/0xf4
[c057beb0] [c0004da0] do_IRQ+0x98/0xb4
[c057bed0] [c000fe0c] ret_from_except+0x0/0x18
[c057bf90] [c0008168] cpu_idle+0x50/0xd8
[c057bfb0] [c000237c] rest_init+0x5c/0x70
[c057bfc0] [c0516850] start_kernel+0x238/0x2c4
[c057bff0] [c000039c] skpinv+0x2b4/0x2f0
Instruction dump:
7d6903a6 4e800420 3d60c007 396bb59c 7d6903a6 4e800420 38000000 38600000
90040068 4e800020 38600000 4e800020 <9421fff0> 7c0802a6 3d20f312
bfc10008
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
----- End of Console capture --------------------------------
I've done a few things
- Verified the symbol address and the NIP match. They seem
correct
- Removed all code from the IRQ handler and just return
IRQ_HANDLED. Still crashes
- Put an infinite loop at the start of the IRQ handler - loop
isn't hit and still crashes so I assume the handler itself is never run.
- I'm able to call my IRQ handler from the module init code and
it runs successfully. The problem is only when running in an interrupt
context.
- I also as a somewhat stupid test passed the physical address
rather than the virtual address when registering the handler. Still
crashes (not sure if that's a valid thing to do to be honest, but I
figured it might be a virtual memory paging issue...grasping at
straws.....).
I do have a ticket in with Freescale support but they suggested I post
here for quicker and wider responses and if there are any ideas out
there I'd really appreciate them. Any chance anyone else has hit this
and knows a workaround or solution? Are there any examples of working
driver modules that use interrupts on the 8536 out there in case I've
done something really goofy in my code? Any suggestions of things to
try?
Thanks in advance
Mark
Confidentiality Notice: This message and any attachments may contain privileged and confidential information. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this information to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. Please contact the sender immediately by reply mail and destroy all copies of the original message.
[-- Attachment #2: Type: text/html, Size: 10961 bytes --]
^ permalink raw reply
* Re: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Michael Ellerman @ 2010-12-09 23:33 UTC (permalink / raw)
To: Mark Pearson; +Cc: linuxppc-dev
In-Reply-To: <11BA25866A2E3A45A797B469B2344B3901554D3D@blademail.bladenetwork.net>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
On Thu, 2010-12-09 at 12:45 -0800, Mark Pearson wrote:
> I have a curious problem. This is on a MPC8636 based platform with
> 36-bit address space (that may or may not be important).
>
>
>
> I have a very simple driver that registers for one of the external
> IRQs with a trivial interrupt handler. It works great when built in as
> part of the kernel.
>
>
>
> However, if I make it a loadable module I get the crash shown below
> (blade_irq is my IRQ handler).
>
>
>
> -----Console capture ----------------------------------------
>
> Unable to handle kernel paging request for instruction fetch
^^^^^^^^^^^^^^^^^
Your interrupt handler isn't mapped executable? Something wrong with
module loading?
Do you need 78e2e68a2b79f394b7cd61e07987a8a89af907f7 ?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Mark Pearson @ 2010-12-10 1:20 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1291937594.3523.20.camel@concordia>
TWFnaWNhbCAtIHRoYW5rIHlvdSB2ZXJ5IHZlcnkgbXVjaC4gVGhlIHBhdGNoIGZpeGVzIHRoZSBw
cm9ibGVtDQoNClJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayByZXNwb25zZSAtIGFuZCBJIHdv
dWxkIG5ldmVyIGhhdmUgZm91bmQgdGhhdCBpbiBhIG1pbGxpb24geWVhcnMuDQoNCk1hcmsNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgRWxsZXJtYW4gW21haWx0
bzptaWNoYWVsQGVsbGVybWFuLmlkLmF1XSANClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwOSwg
MjAxMCA2OjMzIFBNDQpUbzogTWFyayBQZWFyc29uDQpDYzogbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNClN1YmplY3Q6IFJlOiBQcm9ibGVtIHdpdGggTVBDODUzNiBhbmQgZXh0ZXJuYWwg
SVJRcyB3aGVuIHVzaW5nIGEgbG9hZGFibGUga2VybmVsIG1vZHVsZQ0KDQpPbiBUaHUsIDIwMTAt
MTItMDkgYXQgMTI6NDUgLTA4MDAsIE1hcmsgUGVhcnNvbiB3cm90ZToNCj4gSSBoYXZlIGEgY3Vy
aW91cyBwcm9ibGVtLiBUaGlzIGlzIG9uIGEgTVBDODYzNiBiYXNlZCBwbGF0Zm9ybSB3aXRoIA0K
PiAzNi1iaXQgYWRkcmVzcyBzcGFjZSAodGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBpbXBvcnRhbnQp
Lg0KPiANCj4gIA0KPiANCj4gSSBoYXZlIGEgdmVyeSBzaW1wbGUgZHJpdmVyIHRoYXQgcmVnaXN0
ZXJzIGZvciBvbmUgb2YgdGhlIGV4dGVybmFsIA0KPiBJUlFzIHdpdGggYSB0cml2aWFsIGludGVy
cnVwdCBoYW5kbGVyLiBJdCB3b3JrcyBncmVhdCB3aGVuIGJ1aWx0IGluIGFzIA0KPiBwYXJ0IG9m
IHRoZSBrZXJuZWwuDQo+IA0KPiAgDQo+IA0KPiBIb3dldmVyLCBpZiBJIG1ha2UgaXQgYSBsb2Fk
YWJsZSBtb2R1bGUgSSBnZXQgdGhlIGNyYXNoIHNob3duIGJlbG93IA0KPiAoYmxhZGVfaXJxIGlz
IG15IElSUSBoYW5kbGVyKS4NCj4gDQo+ICANCj4gDQo+IC0tLS0tQ29uc29sZSBjYXB0dXJlIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFVuYWJsZSB0byBo
YW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGZvciBpbnN0cnVjdGlvbiBmZXRjaA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXg0K
DQpZb3VyIGludGVycnVwdCBoYW5kbGVyIGlzbid0IG1hcHBlZCBleGVjdXRhYmxlPyBTb21ldGhp
bmcgd3Jvbmcgd2l0aCBtb2R1bGUgbG9hZGluZz8NCg0KRG8geW91IG5lZWQgNzhlMmU2OGEyYjc5
ZjM5NGI3Y2Q2MWUwNzk4N2E4YTg5YWY5MDdmNyA/DQoNCmNoZWVycw0KDQoNCgpDb25maWRlbnRp
YWxpdHkgTm90aWNlOiBUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFp
biAgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSBy
ZWFzb24gdG8gYmVsaWV2ZSB0aGF0IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg
b3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBpbmZvcm1hdGlvbiB0
byBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55
IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBjb3B5aW5nIG9mIHRoaXMg
bWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBQbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGJ5IHJlcGx5IG1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUg
b3JpZ2luYWwgbWVzc2FnZS4K
^ permalink raw reply
* RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Michael Ellerman @ 2010-12-10 3:07 UTC (permalink / raw)
To: Mark Pearson; +Cc: b24347, linuxppc-dev
In-Reply-To: <11BA25866A2E3A45A797B469B2344B3901554D94@blademail.bladenetwork.net>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Thu, 2010-12-09 at 17:20 -0800, Mark Pearson wrote:
> Magical - thank you very very much. The patch fixes the problem
>
> Really appreciate the quick response - and I would never have found that in a million years.
No worries.
Looks like someone should send 78e2e68a2b to the stable crew. FSL guys?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Alexander Gordeev @ 2010-12-10 4:52 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <1291854539-23879-1-git-send-email-tmarri@apm.com>
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Hi,
В Wed, 8 Dec 2010 16:28:59 -0800
tmarri at apm.com (tmarri at apm.com) пишет:
> From: Tirumala Marri <tmarri at apm.com>
>
> v6:
> 1. Replaced register definitions and bit fields with macros.
> 2. Replace printks with dev_dbg or dev_err functions.
> 3. Cleanup some assignments.
> 4. Remove chip specific selections in Kconfig file.
Thanks for the update!
I'm currently working on USB support for Ralink RT3050 (mipsel) boards
which have the same USB OTG controller. I've based my work on the
previous version of your patchset. The were several arch-specific issues
that I'd like to be fixed here before it hits mainline (BTW, is it going
to be mainlined?). I'll reply to the subsequent e-mails about the
specific issues. Is this ok?
Also I'd like to note that s3c-hsotg driver that is already in the
kernel seems to be quite similar from the register definitions at least.
It handles gadget mode only and the code looks different. I think it
should be replaced somehow by this new driver (which is based on the
"official" driver).
--
Alexander
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2010-12-10 6:21 UTC (permalink / raw)
To: Alexander Gordeev; +Cc: linuxppc-dev
In-Reply-To: <20101210075256.296752e2@apollo.gnet>
On Thu, Dec 9, 2010 at 8:52 PM, Alexander Gordeev <lasaine@lvk.cs.msu.su> w=
rote:
> Hi,
>
> =D0=92 Wed, =C2=A08 Dec 2010 16:28:59 -0800
> tmarri at apm.com (tmarri at apm.com) =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>
>> From: Tirumala Marri <tmarri at apm.com>
>>
>> v6:
>> =C2=A01. Replaced register definitions and bit fields with macros.
>> =C2=A02. Replace printks with dev_dbg or dev_err functions.
>> =C2=A03. Cleanup some assignments.
>> =C2=A04. Remove chip specific selections in Kconfig file.
>
> Thanks for the update!
>
> I'm currently working on USB support for Ralink RT3050 (mipsel) boards
> which have the same USB OTG controller. I've based my work on the
> previous version of your patchset. The were several arch-specific issues
> that I'd like to be fixed here before it hits mainline (BTW, is it going
> to be mainlined?). I'll reply to the subsequent e-mails about the
> specific issues. Is this ok?
Yes the idea is to push into main line. I am not sure if it is good idea
to push all the changes in one go. I would wait for this patch to be acce=
pted
first and add your changes on top of that.
>
> Also I'd like to note that s3c-hsotg driver that is already in the
> kernel seems to be quite similar from the register definitions at least.
> It handles gadget mode only and the code looks different. I think it
> should be replaced somehow by this new driver (which is based on the
> "official" driver).
It sound similar to gadget portion of this OTG driver. After this patch acc=
epted
I will take a look and see if we can completely eliminate s3c-hsotg .
Thanks,
Marri
^ permalink raw reply
* RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Li Yang-R58472 @ 2010-12-10 8:03 UTC (permalink / raw)
To: michael, Mark Pearson; +Cc: Jin Qing-B24347, linuxppc-dev
In-Reply-To: <1291950448.3574.5.camel@concordia>
Pk9uIFRodSwgMjAxMC0xMi0wOSBhdCAxNzoyMCAtMDgwMCwgTWFyayBQZWFyc29uIHdyb3RlOg0K
Pj4gTWFnaWNhbCAtIHRoYW5rIHlvdSB2ZXJ5IHZlcnkgbXVjaC4gVGhlIHBhdGNoIGZpeGVzIHRo
ZSBwcm9ibGVtDQo+Pg0KPj4gUmVhbGx5IGFwcHJlY2lhdGUgdGhlIHF1aWNrIHJlc3BvbnNlIC0g
YW5kIEkgd291bGQgbmV2ZXIgaGF2ZSBmb3VuZCB0aGF0DQo+aW4gYSBtaWxsaW9uIHllYXJzLg0K
Pg0KPk5vIHdvcnJpZXMuDQo+DQo+TG9va3MgbGlrZSBzb21lb25lIHNob3VsZCBzZW5kIDc4ZTJl
NjhhMmIgdG8gdGhlIHN0YWJsZSBjcmV3LiBGU0wgZ3V5cz8NCg0KSSB0aGluayBpdCBoYXMgYWxy
ZWFkeSBiZWVuIHNlbnQgdG8gdGhlIHN0YWJsZUBrZXJuZWwub3JnLiAgTm90IHN1cmUgaWYgaXQg
aGFzIGJlZW4gaW5jbHVkZWQgdGhvdWdoLg0KDQotIExlbw0KDQo=
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Andre Schwarz @ 2010-12-10 8:47 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208160531.393bedf1@udp111988uds.am.freescale.net>
Scott,
do you think this issue also applies to MPC8377 ?
I'm in the middle of a small redesign for series production and would
like not to miss a thing.
We have Nand, Nor and MRAM connected to LBC.
Since RFS is running from NAND and we use the MRAM as a non-volatile
SRAM I'd like to avoid being hit by this issue.
Any comments from your side ?
Regards,
André
> On Wed, 8 Dec 2010 22:26:59 +0100
> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
>
>> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 21:25:51:
>>> On Wed, 8 Dec 2010 21:11:08 +0100
>>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
>>>
>>>> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 20:59:28:
>>>>> On Wed, 8 Dec 2010 20:57:03 +0100
>>>>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
>>>>>
>>>>>> Can you think of any workaround such as not connecting the BUSY pin at all?
>>>>> Maybe connect the busy pin to a gpio?
>>>> Is BUSY required for sane operation or it an optimization?
>>> You could probably get away without it by inserting delays if you know
>>> the chip specs well enough.
>> Urgh, that does not feel like a good solution.
> No, but you asked if it could be done, and if it was just a
> performance issue. :-)
>
>>>> Is there any risk that the NAND device will drive the LB and corrupt
>>>> the bus for other devices?
>>> I think the only thing the NAND chip should be driving is the busy pin,
>> OK, good. What function is actually lost if one uses an GPIO instead of
>> BUSY?
> Not much, if you enable interrupts on the GPIO pin. The driver would
> have to be reworked a bit, of course.
>
>> You think Freescale could test and validate a GPIO solution? I don't
>> think we will be very happy to design our board around an unproven
>> workaround.
> Ask your sales/support contacts.
>
>> An even better workaround would be if one could add logic between the
>> NAND and the CPU which would compensate for this defect without needing
>> special SW fixes.
> The problem with that is when would you assert the chipselect again to
> check if it's done? Current SW depends on being able to tell the LBC
> to interrupt (or take other action) when busy goes away.
>
> I suppose you could poll with status reads, which could at least be
> preempted if you've got something higher priority to do with the LBC.
>
> -Scott
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-10 8:56 UTC (permalink / raw)
To: Andre Schwarz; +Cc: Mark Mason, Scott Wood, linuxppc-dev
In-Reply-To: <4D01E90E.8070404@matrix-vision.de>
Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/12/10 09:4=
7:10:
>
> Scott,
>
> do you think this issue also applies to MPC8377 ?
Probably, I think this is so for all eLBC controllers.
>
> I'm in the middle of a small redesign for series production and would=
> like not to miss a thing.
> We have Nand, Nor and MRAM connected to LBC.
>
> Since RFS is running from NAND and we use the MRAM as a non-volatile
> SRAM I'd like to avoid being hit by this issue.
Please report back, I really want to know if this works and if there
are any drawbacks.
>
> Any comments from your side ?
>
> Regards,
> Andr=E9
>
> > On Wed, 8 Dec 2010 22:26:59 +0100
> > Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >
> >> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 21:25:51:=
> >>> On Wed, 8 Dec 2010 21:11:08 +0100
> >>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >>>
> >>>> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 20:59:2=
8:
> >>>>> On Wed, 8 Dec 2010 20:57:03 +0100
> >>>>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >>>>>
> >>>>>> Can you think of any workaround such as not connecting the BUS=
Y pin at all?
> >>>>> Maybe connect the busy pin to a gpio?
> >>>> Is BUSY required for sane operation or it an optimization?
> >>> You could probably get away without it by inserting delays if you=
know
> >>> the chip specs well enough.
> >> Urgh, that does not feel like a good solution.
> > No, but you asked if it could be done, and if it was just a
> > performance issue. :-)
> >
> >>>> Is there any risk that the NAND device will drive the LB and cor=
rupt
> >>>> the bus for other devices?
> >>> I think the only thing the NAND chip should be driving is the bus=
y pin,
> >> OK, good. What function is actually lost if one uses an GPIO inste=
ad of
> >> BUSY?
> > Not much, if you enable interrupts on the GPIO pin. The driver wou=
ld
> > have to be reworked a bit, of course.
> >
> >> You think Freescale could test and validate a GPIO solution? I don=
't
> >> think we will be very happy to design our board around an unproven=
> >> workaround.
> > Ask your sales/support contacts.
> >
> >> An even better workaround would be if one could add logic between =
the
> >> NAND and the CPU which would compensate for this defect without ne=
eding
> >> special SW fixes.
> > The problem with that is when would you assert the chipselect again=
to
> > check if it's done? Current SW depends on being able to tell the L=
BC
> > to interrupt (or take other action) when busy goes away.
> >
> > I suppose you could poll with status reads, which could at least be=
> > preempted if you've got something higher priority to do with the LB=
C.
> >
> > -Scott
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner=
^ 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