* [PATCH V6 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: tmarri @ 2010-12-09 0:32 UTC (permalink / raw)
To: linux-usb; +Cc: tmarri, Mark Miesfeld, linuxppc-dev, Fushen Chen
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>
---
drivers/usb/gadget/Kconfig | 22 ++++++++++++++++++++++
drivers/usb/gadget/gadget_chips.h | 8 ++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
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
This OTG-capable silicon IP is used in dual designs including
the TI DaVinci, OMAP 243x, OMAP 343x, TUSB 6010, and ADI Blackfin
+# dwc_otg builds in ../dwc_otg along with host support
+config USB_GADGET_DWC_HDRC
+ boolean "DesignWare USB Peripheral"
+ depends on DWC_OTG_MODE || DWC_DEVICE_ONLY
+ select USB_GADGET_DUALSPEED
+ select USB_GADGET_SELECTED
+ select USB_OTG
+ help
+ This OTG-capable Designware USB IP
+
+config USB_OTG
+ boolean "OTG Support"
+ depends on USB_GADGET_DWC_HDRC
+ help
+ The most notable feature of USB OTG is support for a
+ "Dual-Role" device, which can act as either a device
+ or a host. The initial role choice can be changed
+ later, when two dual-role devices talk to each other.
+ Select this only if your board has a Mini-AB connector.
+
+
+
config USB_GADGET_M66592
boolean "Renesas M66592 USB Peripheral Controller"
select USB_GADGET_DUALSPEED
diff --git a/drivers/usb/gadget/gadget_chips.h b/drivers/usb/gadget/gadget_chips.h
index d7b3bbe..e008e07 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -142,6 +142,12 @@
#define gadget_is_s3c_hsotg(g) 0
#endif
+#if defined(CONFIG_DWC_OTG_MODE) || defined(CONFIG_DWC_DEVICE_ONLY)
+#define gadget_is_dwc_otg_pcd(g) (!strcmp("dwc_otg_pcd", (g)->name))
+#else
+#define gadget_is_dwc_otg_pcd(g) 0
+#endif
+
#ifdef CONFIG_USB_GADGET_EG20T
#define gadget_is_pch(g) (!strcmp("pch_udc", (g)->name))
#else
@@ -207,6 +213,8 @@ static inline int usb_gadget_controller_number(struct usb_gadget *gadget)
return 0x26;
else if (gadget_is_pch(gadget))
return 0x27;
+ else if (gadget_is_dwc_otg_pcd(gadget))
+ return 0x28;
return -ENOENT;
}
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH V6 10/10] USB ppc4xx: Add Synopsys DWC OTG driver kernel configuration and Makefile
From: tmarri @ 2010-12-09 0:32 UTC (permalink / raw)
To: linux-usb; +Cc: tmarri, Mark Miesfeld, linuxppc-dev, Fushen Chen
From: Tirumala Marri <tmarri@apm.com>
Add Synopsys DesignWare HS USB OTG driver kernel configuration.
Synopsys OTG driver may operate in host only, device only, or OTG mode.
The driver also allows user configure the core to use its internal DMA
or Slave (PIO) mode.
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>
---
drivers/Makefile | 2 +
drivers/usb/Kconfig | 3 +-
drivers/usb/dwc_otg/Kconfig | 96 ++++++++++++++++++++++++++++++++++++++++++
drivers/usb/dwc_otg/Makefile | 19 ++++++++
4 files changed, 119 insertions(+), 1 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index 14152fc..0ecbf42 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_UWB) += uwb/
obj-$(CONFIG_USB_OTG_UTILS) += usb/otg/
obj-$(CONFIG_USB) += usb/
obj-$(CONFIG_USB_MUSB_HDRC) += usb/musb/
+obj-$(CONFIG_USB_DWC_OTG) += usb/dwc_otg/
obj-$(CONFIG_PCI) += usb/
obj-$(CONFIG_USB_GADGET) += usb/gadget/
obj-$(CONFIG_SERIO) += input/serio/
@@ -105,6 +106,7 @@ obj-$(CONFIG_ARCH_SHMOBILE) += sh/
ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
obj-y += clocksource/
endif
+obj-$(CONFIG_DMA_ENGINE) += dma/
obj-$(CONFIG_DCA) += dca/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 6585f0b..8b3623d 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -55,7 +55,6 @@ config USB_ARCH_HAS_OHCI
config USB_ARCH_HAS_EHCI
boolean
default y if PPC_83xx
- default y if PPC_MPC512x
default y if SOC_AU1200
default y if ARCH_IXP4XX
default y if ARCH_W90X900
@@ -113,6 +112,8 @@ source "drivers/usb/host/Kconfig"
source "drivers/usb/musb/Kconfig"
+source "drivers/usb/dwc_otg/Kconfig"
+
source "drivers/usb/class/Kconfig"
source "drivers/usb/storage/Kconfig"
diff --git a/drivers/usb/dwc_otg/Kconfig b/drivers/usb/dwc_otg/Kconfig
new file mode 100644
index 0000000..4d33d72
--- /dev/null
+++ b/drivers/usb/dwc_otg/Kconfig
@@ -0,0 +1,96 @@
+#
+# USB Dual Role (OTG-ready) Controller Drivers
+# for silicon based on Synopsys DesignWare IP
+#
+
+comment "Enable Host or Gadget support for DesignWare OTG controller"
+ depends on !USB && USB_GADGET=n
+
+config USB_DWC_OTG
+ depends on (USB || USB_GADGET)
+ select NOP_USB_XCEIV
+ select USB_OTG_UTILS
+ tristate "Synopsys DWC OTG Controller"
+ default USB_GADGET
+ help
+ This driver provides USB Device Controller support for the
+ Synopsys DesignWare USB OTG Core used on the AppliedMicro PowerPC SoC.
+
+config DWC_DEBUG
+ bool "Enable DWC Debugging"
+ depends on USB_DWC_OTG
+ default n
+ help
+ Enable DWC driver debugging
+
+choice
+ prompt "DWC Mode Selection"
+ depends on USB_DWC_OTG
+ default DWC_HOST_ONLY
+ help
+ Select the DWC Core in OTG, Host only, or Device only mode.
+
+config DWC_HOST_ONLY
+ bool "DWC Host Only Mode"
+
+config DWC_OTG_MODE
+ bool "DWC OTG Mode"
+ select USB_GADGET_SELECTED
+
+config DWC_DEVICE_ONLY
+ bool "DWC Device Only Mode"
+ select USB_GADGET_SELECTED
+
+endchoice
+
+# enable peripheral support (including with OTG)
+config USB_GADGET_DWC_HDRC
+ bool
+ depends on USB_DWC_OTG && (DWC_DEVICE_ONLY || USB_DWC_OTG)
+
+choice
+ prompt "DWC DMA/SlaveMode Selection"
+ depends on USB_DWC_OTG
+ default DWC_DMA_MODE
+ help
+ Select the DWC DMA or Slave Mode.
+ DMA mode uses the DWC core internal DMA engines.
+ Slave mode uses the processor PIO to tranfer data.
+ In Slave mode, processor's DMA channels can be used if available.
+
+config DWC_SLAVE
+ bool "DWC Slave Mode"
+
+config DWC_DMA_MODE
+ bool "DWC DMA Mode"
+
+endchoice
+
+config USB_OTG_WHITELIST
+ bool "Rely on OTG Targeted Peripherals List"
+ depends on !USB_SUSPEND && USB_DWC_OTG
+ default n
+ help
+ This is the same flag as in ../core/Kconfig.
+ It is here for easy deselect.
+
+config DWC_OTG_REG_LE
+ depends on USB_DWC_OTG
+ bool "DWC Little Endian Register"
+ default y
+ help
+ OTG core register access is Little-Endian.
+
+config DWC_OTG_FIFO_LE
+ depends on USB_DWC_OTG
+ bool "DWC FIFO Little Endian"
+ default n
+ help
+ OTG core FIFO access is Little-Endian.
+
+config DWC_LIMITED_XFER_SIZE
+ depends on USB_GADGET_DWC_HDRC
+ bool "DWC Endpoint Limited Xfer Size"
+ default n
+ help
+ Bit fields in the Device EP Transfer Size Register is 11 bits.
diff --git a/drivers/usb/dwc_otg/Makefile b/drivers/usb/dwc_otg/Makefile
new file mode 100644
index 0000000..31dd5e8
--- /dev/null
+++ b/drivers/usb/dwc_otg/Makefile
@@ -0,0 +1,19 @@
+#
+# OTG infrastructure and transceiver drivers
+#
+obj-$(CONFIG_USB_DWC_OTG) += dwc_otg.o
+
+dwc_otg-objs := dwc_otg_cil.o dwc_otg_cil_intr.o dwc_otg_param.o
+
+ifeq ($(CONFIG_4xx_SOC),y)
+dwc_otg-objs += dwc_otg_apmppc.o
+endif
+
+ifneq ($(CONFIG_DWC_DEVICE_ONLY),y)
+dwc_otg-objs += dwc_otg_hcd.o dwc_otg_hcd_intr.o \
+ dwc_otg_hcd_queue.o
+endif
+
+ifneq ($(CONFIG_DWC_HOST_ONLY),y)
+dwc_otg-objs += dwc_otg_pcd.o dwc_otg_pcd_intr.o
+endif
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH] ppc4xx: Add USB DWC DTS entry to Canyonlands board
From: tmarri @ 2010-12-09 0:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmarri
From: Tirumala Marri <tmarri@apm.com>
Add Synopsys Designware DTS entry for 460EX based Canyonlands board.
Signed-off-by: Tirumala R Marri<tmarri@apm.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 5b27a4b..54caec6 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -172,6 +172,19 @@
interrupts = <0x1e 4>;
};
+ USBOTG0: usbotg@bff80000 {
+ compatible = "amcc,dwc-otg";
+ reg = <0x4 0xbff80000 0x10000>;
+ interrupt-parent = <&USBOTG0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupts = <0x0 0x1 0x2>;
+ interrupt-map = </* USB-OTG */ 0x0 &UIC2 0x1c 0x4
+ /* HIGH-POWER */ 0x1 &UIC1 0x1a 0x8
+ /* DMA */ 0x2 &UIC0 0xc 0x4>;
+ };
+
SATA0: sata@bffd1000 {
compatible = "amcc,sata-460ex";
reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
--
1.6.1.rc3
^ permalink raw reply related
* [PATCH] ppc4xx: Add USB DWC DTS entry to Canyonlands board
From: tmarri @ 2010-12-09 0:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tmarri
From: Tirumala Marri <tmarri@apm.com>
Add Synopsys Designware DTS entry for 460EX based Canyonlands board.
Signed-off-by: Tirumala R Marri<tmarri@apm.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 5b27a4b..54caec6 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -172,6 +172,19 @@
interrupts = <0x1e 4>;
};
+ USBOTG0: usbotg@bff80000 {
+ compatible = "amcc,dwc-otg";
+ reg = <0x4 0xbff80000 0x10000>;
+ interrupt-parent = <&USBOTG0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupts = <0x0 0x1 0x2>;
+ interrupt-map = </* USB-OTG */ 0x0 &UIC2 0x1c 0x4
+ /* HIGH-POWER */ 0x1 &UIC1 0x1a 0x8
+ /* DMA */ 0x2 &UIC0 0xc 0x4>;
+ };
+
SATA0: sata@bffd1000 {
compatible = "amcc,sata-460ex";
reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
--
1.6.1.rc3
^ permalink raw reply related
* Re: [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: Michael Ellerman @ 2010-12-09 1:33 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, linuxppc-dev, Deepak Saxena
In-Reply-To: <20101208150102.69b8062b@udp111988uds.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]
On Wed, 2010-12-08 at 15:01 -0600, Scott Wood wrote:
> On Wed, 8 Dec 2010 11:29:44 -0800
> Deepak Saxena <deepak_saxena@mentor.com> wrote:
>
> > We only return the next child if the device is available.
> >
> > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
> > Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
> > ---
> > drivers/of/base.c | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index 5d269a4..81b2601 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct device_node *node)
> > *
> > * Returns a node pointer with refcount incremented, use
> > * of_node_put() on it when done.
> > + *
> > + * Does not return nodes marked unavailable by a status property.
> > */
> > struct device_node *of_get_next_child(const struct device_node *node,
> > struct device_node *prev)
> > @@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const struct device_node *node,
> > read_lock(&devtree_lock);
> > next = prev ? prev->sibling : node->child;
> > for (; next; next = next->sibling)
> > - if (of_node_get(next))
> > + if (of_device_is_available(next) && of_node_get(next))
> > break;
> > of_node_put(prev);
> > read_unlock(&devtree_lock);
>
> This seems like too low-level a place to put this. Some code may know
> how to un-disable a device in certain situations, or it may be part of
> debug code trying to dump the whole device tree, etc. Looking
> further[1], I see a raw version of this function, but not other things
> like of_find_compatible_node.
Yeah I agree. I think we'll eventually end up with __ versions of all or
lots of them. Not to mention there might be cases you've missed where
code expects to see unavailable nodes. The right approach is to add
_new_ routines that don't return unavailable nodes, and convert code
that you know wants to use them.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: David Gibson @ 2010-12-09 3:09 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Scott Wood, devicetree-discuss, linuxppc-dev
In-Reply-To: <1291858402.2962.2.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
On Thu, Dec 09, 2010 at 12:33:22PM +1100, Michael Ellerman wrote:
> On Wed, 2010-12-08 at 15:01 -0600, Scott Wood wrote:
> > On Wed, 8 Dec 2010 11:29:44 -0800
> > Deepak Saxena <deepak_saxena@mentor.com> wrote:
> >
> > > We only return the next child if the device is available.
> > >
> > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
> > > Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
> > > ---
> > > drivers/of/base.c | 4 +++-
> > > 1 files changed, 3 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > > index 5d269a4..81b2601 100644
> > > --- a/drivers/of/base.c
> > > +++ b/drivers/of/base.c
> > > @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct device_node *node)
> > > *
> > > * Returns a node pointer with refcount incremented, use
> > > * of_node_put() on it when done.
> > > + *
> > > + * Does not return nodes marked unavailable by a status property.
> > > */
> > > struct device_node *of_get_next_child(const struct device_node *node,
> > > struct device_node *prev)
> > > @@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const struct device_node *node,
> > > read_lock(&devtree_lock);
> > > next = prev ? prev->sibling : node->child;
> > > for (; next; next = next->sibling)
> > > - if (of_node_get(next))
> > > + if (of_device_is_available(next) && of_node_get(next))
> > > break;
> > > of_node_put(prev);
> > > read_unlock(&devtree_lock);
> >
> > This seems like too low-level a place to put this. Some code may know
> > how to un-disable a device in certain situations, or it may be part of
> > debug code trying to dump the whole device tree, etc. Looking
> > further[1], I see a raw version of this function, but not other things
> > like of_find_compatible_node.
>
> Yeah I agree. I think we'll eventually end up with __ versions of all or
> lots of them. Not to mention there might be cases you've missed where
> code expects to see unavailable nodes. The right approach is to add
> _new_ routines that don't return unavailable nodes, and convert code
> that you know wants to use them.
Actually, I don't think we really want these status-skipping
iterators at all. The device tree iterators should give us the device
tree, as it is. Those old-style drivers which seach for a node rather
than using the bus probing logic can keep individual checks of the
status property until they're converted to the new scheme.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Run 'usermode-agent' cause kernel panic on Powerpc
From: Benjamin Herrenschmidt @ 2010-12-09 3:26 UTC (permalink / raw)
To: xufeng zhang; +Cc: Linuxppc-dev, Dave Kleikamp
In-Reply-To: <4CFEDD4D.5020205@windriver.com>
On Wed, 2010-12-08 at 09:20 +0800, xufeng zhang wrote:
> > I believe it would have such an impact. I don't see that user-mode
> > debugging would be enabled at all.
> >
> > Maybe something like this untested patch:
> >
> > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> > index 84906d3..0e7d1cf 100644
> > --- a/arch/powerpc/kernel/process.c
> > +++ b/arch/powerpc/kernel/process.c
> > @@ -323,6 +323,13 @@ static void set_debug_reg_defaults(struct thread_struct *thread)
> >
> > static void prime_debug_regs(struct thread_struct *thread)
> > {
> > + /*
> > + * If we're setting up debug events for user space, make sure they
> > + * don't fire in kernel space before we get to user space
> > + */
> > + if (thread->dbcr0& DBCR0_IDM)
> > + mtmsr(mfmsr()& ~MSR_DE);
> > +
> > mtspr(SPRN_IAC1, thread->iac1);
> > mtspr(SPRN_IAC2, thread->iac2);
> > #if CONFIG_PPC_ADV_DEBUG_IACS> 2
> >
> >
> Thanks for your reply, Dave, I know where the problem is.
So is there a kernel bug we need to fix ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 7/7 v2] ppc: add dynamic dma window support
From: Benjamin Herrenschmidt @ 2010-12-09 4:17 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: sonnyrao, miltonm, Paul Mackerras, Anton Blanchard, linuxppc-dev
In-Reply-To: <1288150518-4026-8-git-send-email-nacc@us.ibm.com>
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 ?
Cheers,
Ben.
^ permalink raw reply
* [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
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