* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Geoff Levand @ 2011-10-27 3:52 UTC (permalink / raw)
To: Tirumala Marri; +Cc: Olof Johansson, greg, linux-usb, linuxppc-dev
In-Reply-To: <d4b201db8e7510eeeca77dc26dab02c1@mail.gmail.com>
Hi Marri,
On Wed, 2011-10-26 at 09:06 -0700, Tirumala Marri wrote:
> <
> <No, just start over from scratch. Just leave the crap driver behind,
> <use it for reference but write the new one.
> <
> <It's obvious given that you are already at iteration v15 and it's
> <still looking this bad that this is not realistic to get reviewed and
> <accepted as-is. I don't think staging is a good target either -- what
> <the driver really needs is _functional_ cut-down to only cover the use
> <cases that your product uses, and staging cleanups are mostly around
> <style and refactoring, not changing, fixing or removing functionality.
> <
> [Tirumala Marri] I like to hear What maintainer GregKH thinks. We already
> spent lot
> Of time on it and passed multiple hands.
I don't think the amount of time spent should be given much
consideration. What matters is whether or not the code is acceptable.
Maybe you can do some coding on a whiteboard to get it right -- hahaha.
-Geoff
^ permalink raw reply
* [PATCH] powerpc/iommu: remove default window before creating larger window
From: Nishanth Aravamudan @ 2011-10-26 22:43 UTC (permalink / raw)
To: benh; +Cc: miltonm, paulus, linuxppc-dev
The DDW feature relies on there being sufficient TCE space to allocate
for the requested DMA window size. The default window uses up some of
that space, though, and it is recommended to first remove the default
window and then allocate the larger window advertised by firmware. Do
this by abstracting out parts of remove_ddw into a function that does
not assume an existing larger window has been created.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pseries/iommu.c | 35 +++++++++++++++++++++++--------
1 files changed, 26 insertions(+), 9 deletions(-)
Is there a better way to get the default window's LIOBN than to call
of_parse_dma_window?
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 01faab9..afcc04c 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -655,6 +655,21 @@ static int __init disable_ddw_setup(char *str)
early_param("disable_ddw", disable_ddw_setup);
+static void __remove_ddw(struct device_node *np, const u32 *ddw_avail, u64 liobn)
+{
+ int ret;
+
+ ret = rtas_call(ddw_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, ddw_avail[2], liobn);
+ else
+ pr_debug("%s: successfully removed direct window: rtas returned "
+ "%d to ibm,remove-pe-dma-window(%x) %llx\n",
+ np->full_name, ret, ddw_avail[2], liobn);
+}
+
static void remove_ddw(struct device_node *np)
{
struct dynamic_dma_window_prop *dwp;
@@ -684,15 +699,7 @@ static void remove_ddw(struct device_node *np)
pr_debug("%s successfully cleared tces in window.\n",
np->full_name);
- ret = rtas_call(ddw_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, ddw_avail[2], liobn);
- else
- pr_debug("%s: successfully removed direct window: rtas returned "
- "%d to ibm,remove-pe-dma-window(%x) %llx\n",
- np->full_name, ret, ddw_avail[2], liobn);
+ __remove_ddw(np, ddw_avail, liobn);
delprop:
ret = prom_remove_property(np, win64);
@@ -843,6 +850,8 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
struct direct_window *window;
struct property *win64;
struct dynamic_dma_window_prop *ddwprop;
+ const void *dma_window = NULL;
+ unsigned long liobn, offset, size;
mutex_lock(&direct_window_init_mutex);
@@ -918,6 +927,14 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
goto out_free_prop;
}
+ /*
+ * To maximize the resources available to the create RTAS call,
+ * delete the existing DMA window
+ */
+ dma_window = of_get_property(pdn, "ibm,dma-window", NULL);
+ of_parse_dma_window(pdn, dma_window, &liobn, &offset, &size);
+ __remove_ddw(pdn, ddw_avail, liobn);
+
ret = create_ddw(dev, ddw_avail, &create, page_shift, len);
if (ret != 0)
goto out_free_prop;
--
1.7.5.4
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply related
* [PATCH] [v2] powerpc/fsl_msi: add support for the fsl, msi property in PCI nodes
From: Timur Tabi @ 2011-10-26 22:30 UTC (permalink / raw)
To: kumar.gala, scottwood, miltonm, tglx, benh, linuxppc-dev
On Freescale parts with multiple MSI controllers, the controllers are
combined into one "pool" of interrupts. Whenever a device requests an MSI
interrupt, the next available interrupt from the pool is selected,
regardless of which MSI controller the interrupt is from. This works
because each PCI bus has an ATMU to all of CCSR, so any PCI device can
access any MSI interrupt register.
The fsl,msi property is used to specify that a given PCI bus should only
use a specific MSI device. This is necessary, for example, with the
Freescale hypervisor, because the MSI devices are assigned to specific
partitions.
Ideally, we'd like to be able to assign MSI devices to PCI busses within
the MSI or PCI layers. However, there does not appear to be a mechanism
to do that. Whenever the MSI layer wants to allocate an MSI interrupt to
a PCI device, it just calls arch_setup_msi_irqs(). It would be nice if we
could register an MSI device with a specific PCI bus.
So instead we remember the phandles of each MSI device, and we use that to
limit our search for an available interrupt. Whenever we are asked to
allocate a new interrupt for a PCI device, we check the fsl,msi property
of the PCI bus for that device. If it exists, then as we are looping over
all MSI devices, we skip the ones that don't have a matching phandle.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/fsl_msi.c | 33 +++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_msi.h | 3 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index e5c344d..155ccb2 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -148,14 +148,41 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ struct device_node *np;
+ phandle phandle = 0;
int rc, hwirq = -ENOMEM;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
struct fsl_msi *msi_data;
+ /*
+ * If the PCI node has an fsl,msi property, then we need to use it
+ * to find the specific MSI.
+ */
+ np = of_parse_phandle(hose->dn, "fsl,msi", 0);
+ if (np)
+ phandle = np->phandle;
+
list_for_each_entry(entry, &pdev->msi_list, list) {
+ /*
+ * Loop over all the available MSI devices until we find one
+ * that has an available interrupt.
+ */
list_for_each_entry(msi_data, &msi_head, list) {
+ /*
+ * If the PCI node has an fsl,msi property, then we
+ * need to restrict our search to the corresponding
+ * MSI node. The simplest way is to skip over MSI
+ * nodes with the wrong phandle. Under the Freescale
+ * hypervisor, this has the additional benefit of
+ * skipping over MSI nodes that are not mapped in the
+ * PAMU.
+ */
+ if (phandle && (phandle != msi_data->phandle))
+ continue;
+
hwirq = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
if (hwirq >= 0)
break;
@@ -370,6 +397,12 @@ static int __devinit fsl_of_msi_probe(struct platform_device *dev)
msi->msiir_offset = features->msiir_offset + (res.start & 0xfffff);
+ /*
+ * Remember the phandle, so that we can match with any PCI nodes
+ * that have an "fsl,msi" property.
+ */
+ msi->phandle = dev->dev.of_node->phandle;
+
rc = fsl_msi_init_allocator(msi);
if (rc) {
dev_err(&dev->dev, "Error allocating MSI bitmap\n");
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index 1313abb..b5d25ba 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -13,6 +13,7 @@
#ifndef _POWERPC_SYSDEV_FSL_MSI_H
#define _POWERPC_SYSDEV_FSL_MSI_H
+#include <linux/of.h>
#include <asm/msi_bitmap.h>
#define NR_MSI_REG 8
@@ -36,6 +37,8 @@ struct fsl_msi {
struct msi_bitmap bitmap;
struct list_head list; /* support multiple MSI banks */
+
+ phandle phandle;
};
#endif /* _POWERPC_SYSDEV_FSL_MSI_H */
--
1.7.3.4
^ permalink raw reply related
* [PATCH] powerpc/fsl_msi: add support for the fsl, msi property in PCI nodes
From: Timur Tabi @ 2011-10-26 21:22 UTC (permalink / raw)
To: kumar.gala, scottwood, miltonm, tglx, benh, linuxppc-dev
On Freescale parts with multiple MSI controllers, the controllers are
combined into one "pool" of interrupts. Whenever a device requests an MSI
interrupt, the next available interrupt from the pool is selected,
regardless of which MSI controller the interrupt is from. This works
because each PCI bus has an ATMU to all of CCSR, so any PCI device can
access any MSI interrupt register.
The fsl,msi property is used to specify that a given PCI bus should only
use a specific MSI device. This is necessary, for example, with the
Freescale hypervisor, because the MSI devices are assigned to specific
partitions.
Ideally, we'd like to be able to assign MSI devices to PCI busses within
the MSI or PCI layers. However, there does not appear to be a mechanism
to do that. Whenever the MSI layer wants to allocate an MSI interrupt to
a PCI device, it just calls arch_setup_msi_irqs(). It would be nice if we
could register an MSI device with a specific PCI bus.
So instead we remember the phandles of each MSI device, and we use that to
limit our search for an available interrupt. Whenever we are asked to
allocate a new interrupt for a PCI device, we check the fsl,msi property
of the PCI bus for that device. If it exists, then as we are looping over
all MSI devices, we skip the ones that don't have a matching phandle.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/fsl_msi.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index e5c344d..ef08b1b 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -148,14 +148,41 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ struct device_node *np = hose->dn;
+ phandle phandle = 0;
int rc, hwirq = -ENOMEM;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
struct fsl_msi *msi_data;
+ /*
+ * If the PCI node has an fsl,msi property, then we need to use it
+ * to find the specific MSI.
+ */
+ np = of_parse_phandle(hose->dn, "fsl,msi", 0);
+ if (np)
+ phandle = np->phandle;
+
list_for_each_entry(entry, &pdev->msi_list, list) {
+ /*
+ * Loop over all the available MSI devices until we find one
+ * that has an available interrupt.
+ */
list_for_each_entry(msi_data, &msi_head, list) {
+ /*
+ * If the PCI node has an fsl,msi property, then we
+ * need to restrict our search to the corresponding
+ * MSI node. The simplest way is to skip over MSI
+ * nodes with the wrong phandle. Under the Freescale
+ * hypervisor, this has the additional benefit of
+ * skipping over MSI nodes that are not mapped in the
+ * PAMU.
+ */
+ if (phandle && (phandle != msi_data->phandle))
+ continue;
+
hwirq = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
if (hwirq >= 0)
break;
@@ -370,6 +397,12 @@ static int __devinit fsl_of_msi_probe(struct platform_device *dev)
msi->msiir_offset = features->msiir_offset + (res.start & 0xfffff);
+ /*
+ * Remember the phandle, so that we can match with any PCI nodes
+ * that have an "fsl,msi" property.
+ */
+ msi->phandle = dev->dev.of_node->phandle;
+
rc = fsl_msi_init_allocator(msi);
if (rc) {
dev_err(&dev->dev, "Error allocating MSI bitmap\n");
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
From: Scott Wood @ 2011-10-26 19:16 UTC (permalink / raw)
To: Suzuki Poulose
Cc: Michal Simek, tmarri, Mahesh Jagannath Salgaonkar, Dave Hansen,
David Laight, Paul Mackerras, linux ppc dev, Vivek Goyal
In-Reply-To: <4EA85B95.9030802@in.ibm.com>
On 10/26/2011 02:12 PM, Suzuki Poulose wrote:
> On 10/25/11 21:04, Scott Wood wrote:
>> On 10/12/2011 09:15 AM, Dave Hansen wrote:
>>> This is not the place to enforce that kind of thing. If
>>> CONFIG_RELOCATABLE is only supported on one platform, then do:
>>>
>>> config RELOCATABLE
>>> depends on 44x
>>>
>>> and take the 44x reference out of the #ifdef.
>>
>> ...but please first rename the existing, different CONFIG_RELOCATABLE
>> behavior that is currently supported on e500.
>
> Scott,
>
> I have renamed the new type of relocation to RELOCATABLE_PPC32_PIE. The
> patches
> were posted yesterday. Please let me know your thoughts.
I think it would make more sense to rename the existing behavior (maybe
something like DYNAMIC_MEMSTART -- if there's even enough overhead to
make it worth being configurable at all), since it's not fully
relocatable and since 64-bit already uses RELOCATABLE to mean PIE.
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] [44x] Enable CONFIG_RELOCATABLE for PPC44x
From: Suzuki Poulose @ 2011-10-26 19:12 UTC (permalink / raw)
To: Scott Wood
Cc: Michal Simek, tmarri, Mahesh Jagannath Salgaonkar, Dave Hansen,
David Laight, Paul Mackerras, linux ppc dev, Vivek Goyal
In-Reply-To: <4EA6D701.3030603@freescale.com>
On 10/25/11 21:04, Scott Wood wrote:
> On 10/12/2011 09:15 AM, Dave Hansen wrote:
>> On Tue, 2011-10-11 at 18:24 +0530, Suzuki Poulose wrote:
>>> On 10/10/11 23:30, Scott Wood wrote:
>>>> On 10/10/2011 04:56 AM, Suzuki K. Poulose wrote:
>>>>> #if defined(CONFIG_RELOCATABLE)&& defined(CONFIG_44x)
>>>>> #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) - PHYSICAL_START + (KERNELBASE + RELOC_OFFSET)))
>>>>> #define __pa(x) ((unsigned long)(x) + PHYSICAL_START - (KERNELBASE + RELOC_OFFSET))
>>>>> #endif
>>>>
>>>> Why is this 44x-specific?
>>>
>>> As of now, we compile with relocations only for the 44x. We could make this
>>> generic once the approach is accepted by everyone and implemented on the other
>>> platforms.
>>
>> This is not the place to enforce that kind of thing. If
>> CONFIG_RELOCATABLE is only supported on one platform, then do:
>>
>> config RELOCATABLE
>> depends on 44x
>>
>> and take the 44x reference out of the #ifdef.
>
> ...but please first rename the existing, different CONFIG_RELOCATABLE
> behavior that is currently supported on e500.
Scott,
I have renamed the new type of relocation to RELOCATABLE_PPC32_PIE. The patches
were posted yesterday. Please let me know your thoughts.
Thanks
Suzuki
^ permalink raw reply
* [PATCH v4 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Matthew McClintock @ 2011-10-26 18:46 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319654028-30478-1-git-send-email-msm@freescale.com>
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
v2: Updated commit message
v3: Added detail in code comment as well
v4: Check for MPIC_FSL in mpic->flags to determine if we need 15 EOIs
arch/powerpc/sysdev/mpic.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9678081..0842c6f 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
struct mpic *mpic = mpic_primary;
u32 pir;
int cpuid = get_hard_smp_processor_id(cpu);
+ int i;
/* Set target bit for core reset */
pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
@@ -1759,6 +1760,15 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts.
+ * This is required for FSL CoreNet based devices */
+ if (mpic->flags & MPIC_FSL) {
+ for (i = 0; i < 15; i++) {
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
+ MPIC_CPU_EOI, 0);
+ }
+ }
}
#endif /* CONFIG_SMP */
--
1.7.6.1
^ permalink raw reply related
* [PATCH v3 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Matthew McClintock @ 2011-10-26 18:33 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <08F58B37-0825-4C07-91B3-1040A7E70528@freescale.com>
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
v2: Updated commit message
v3: Added detail in code comment as well
arch/powerpc/sysdev/mpic.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9678081..d641481 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
struct mpic *mpic = mpic_primary;
u32 pir;
int cpuid = get_hard_smp_processor_id(cpu);
+ int i;
/* Set target bit for core reset */
pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
@@ -1759,6 +1760,13 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts.
+ * This is required for FSL CoreNet based devices */
+ for (i = 0; i < 15; i++) {
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
+ MPIC_CPU_EOI, 0);
+ }
}
#endif /* CONFIG_SMP */
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Segher Boessenkool @ 2011-10-26 18:30 UTC (permalink / raw)
To: Matthew McClintock; +Cc: kumar.gala, linuxppc-dev
In-Reply-To: <1319652797-28017-1-git-send-email-msm@freescale.com>
> @@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
> pir &= ~(1 << cpuid);
> mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
> mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
> +
> + /* Perform 15 EOI on each reset core to clear pending interrupts */
> + for (i = 0; i < 15; i++) {
> + _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
> + MPIC_CPU_EOI, 0);
> + }
This is generic code, right? Please add info to the comment about
which devices need this quirk, then.
Segher
^ permalink raw reply
* [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Matthew McClintock @ 2011-10-26 18:13 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <08F58B37-0825-4C07-91B3-1040A7E70528@freescale.com>
This is listed as a requirement for Freescale CoreNet based devices (e.g
p4080ds with MPIC v4.x) after issuing a core reset to properly clear pending
interrupts.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
v2: Updated commit message
arch/powerpc/sysdev/mpic.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9678081..f5b83f0 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
struct mpic *mpic = mpic_primary;
u32 pir;
int cpuid = get_hard_smp_processor_id(cpu);
+ int i;
/* Set target bit for core reset */
pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
@@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts */
+ for (i = 0; i < 15; i++) {
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
+ MPIC_CPU_EOI, 0);
+ }
}
#endif /* CONFIG_SMP */
--
1.7.6.1
^ permalink raw reply related
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-26 17:17 UTC (permalink / raw)
To: greg; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <CAOesGMhVuxbqq7cmm2XVUof9vEifAL=GpPirYb8148a24upJCw@mail.gmail.com>
Greg,
<
<No, just start over from scratch. Just leave the crap driver behind,
<use it for reference but write the new one.
<
<It's obvious given that you are already at iteration v15 and it's
<still looking this bad that this is not realistic to get reviewed and
<accepted as-is. I don't think staging is a good target either -- what
<the driver really needs is _functional_ cut-down to only cover the use
<cases that your product uses, and staging cleanups are mostly around
<style and refactoring, not changing, fixing or removing functionality.
<
<> <Compare this to the dwc3 driver, which is much much cleaner.
<> <
Could you please comment on this. This has been reviewed so many times
And we did the major changes. I think it is un-acceptable to say to
re-write
The driver now after 15 reviews? This should have happened in first 5
reviews.
Thx,
Marri
^ permalink raw reply
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-26 16:06 UTC (permalink / raw)
To: Olof Johansson; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <CAOesGMhVuxbqq7cmm2XVUof9vEifAL=GpPirYb8148a24upJCw@mail.gmail.com>
<
<No, just start over from scratch. Just leave the crap driver behind,
<use it for reference but write the new one.
<
<It's obvious given that you are already at iteration v15 and it's
<still looking this bad that this is not realistic to get reviewed and
<accepted as-is. I don't think staging is a good target either -- what
<the driver really needs is _functional_ cut-down to only cover the use
<cases that your product uses, and staging cleanups are mostly around
<style and refactoring, not changing, fixing or removing functionality.
<
[Tirumala Marri] I like to hear What maintainer GregKH thinks. We already
spent lot
Of time on it and passed multiple hands.
--marri
^ permalink raw reply
* Re: [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Scott Wood @ 2011-10-26 16:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6549A2B9-A9FD-42BC-A3B0-B920167739F5@kernel.crashing.org>
On 10/25/2011 10:35 PM, Kumar Gala wrote:
>
> On Oct 25, 2011, at 5:19 PM, Scott Wood wrote:
>
>> On 10/22/2011 04:20 PM, Kumar Gala wrote:
>>> All eTSEC2 controllers support waking on magic packet so fixup device
>>> tree to report that.
>>
>> If they *all* support it, we can make the driver rely on the compatible
>> instead.
>>
>> -Scott
>
> I think this might have originated on eTSEC v1, in which all controllers don't support it.
Sure, I was just talking about nodes with fsl,etsec2 -- especially if we
have device trees already out there that are missing the property.
Easier to change the driver.
-Scott
^ permalink raw reply
* Re: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Olof Johansson @ 2011-10-26 12:04 UTC (permalink / raw)
To: Tirumala Marri; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <c898f5030d342baa4df570317536bcf2@mail.gmail.com>
On Tue, Oct 25, 2011 at 2:54 PM, Tirumala Marri <tmarri@apm.com> wrote:
> <
> <Overall this driver seems to be based on the IP vendor driver? It
> <looks like a completely flexible driver that implements all possible
> <combinations of everything.
> <
> [Tirumala Marri] Some what true that it was based on skeletal driver
> Provided from IP vendor.
Please use a real mail program instead of this [name] comment style.
It's hard to read.
> <And as a result, it's huge, and it's got a lot of extra code in there
> <that I'm
> <willing to bet that you have never even executed on your platform.
> <
> <Please, pare it down to the portions that you have used, and know works
> <and can support. If others need the extra functionality in the future,
> <they can and will expand and bring in what is needed.
> <
> [Tirumala Marri] I can sure review and find if there are any dead
> functions.
> It may not be 100% free of dead code as some of the code paths may execut=
e
> Asynchronously.
No, just start over from scratch. Just leave the crap driver behind,
use it for reference but write the new one.
It's obvious given that you are already at iteration v15 and it's
still looking this bad that this is not realistic to get reviewed and
accepted as-is. I don't think staging is a good target either -- what
the driver really needs is _functional_ cut-down to only cover the use
cases that your product uses, and staging cleanups are mostly around
style and refactoring, not changing, fixing or removing functionality.
> <Compare this to the dwc3 driver, which is much much cleaner.
> <
> [Tirumala Marri] I will check.
> <Overall other comments:
> <
> <* Register definitions are crazy long. It means you have to do lots of
> <line
> < =A0wraps to keep the 80-character limit, which makes it hard to read th=
e
> <code.
> [Tirumala Marri] This was suggestion from the review to use bit shifting.
> I welcome any suggestions.
I'd be surprised if anyone asked to you that kind of crazy shifting.
> <* The header files seem to have been autogenerated and have unnneeded
> < =A0shift/mask operations.
> <
> <* It doesn't build on non-powerpc platforms since it uses out_{b,l}e
> <accessors.
> <
> [Tirumala Marri] You have to select Little Endian mode for LE platform
> From make menuconfig.
I don't think you understood what I meant. Try building an ARM config
with this driver enabled, for example, and you'll see that it breaks
the build.
-Olof
^ permalink raw reply
* Re: [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Kumar Gala @ 2011-10-26 3:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4EA735E8.5010206@freescale.com>
On Oct 25, 2011, at 5:19 PM, Scott Wood wrote:
> On 10/22/2011 04:20 PM, Kumar Gala wrote:
>> All eTSEC2 controllers support waking on magic packet so fixup device
>> tree to report that.
>=20
> If they *all* support it, we can make the driver rely on the =
compatible
> instead.
>=20
> -Scott
I think this might have originated on eTSEC v1, in which all controllers =
don't support it.
I'm not against removing it & just using compatible but don't know =
enough about these nodes to comment.
- k=
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset
From: Kumar Gala @ 2011-10-26 3:16 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
On Oct 25, 2011, at 5:54 PM, Matthew McClintock wrote:
> This is listed as a requirement after issuing a core reset to
> properly clear pending interrupts
>=20
Fix comment message to be more clear on 'what' this is required. [ its a =
requirement on FSL corenet series / MPIC v4.x ]
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/sysdev/mpic.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 9678081..f5b83f0 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
> struct mpic *mpic =3D mpic_primary;
> u32 pir;
> int cpuid =3D get_hard_smp_processor_id(cpu);
> + int i;
>=20
> /* Set target bit for core reset */
> pir =3D mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
> @@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
> pir &=3D ~(1 << cpuid);
> mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
> mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
> +
> + /* Perform 15 EOI on each reset core to clear pending interrupts =
*/
> + for (i =3D 0; i < 15; i++) {
> + _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
> + MPIC_CPU_EOI, 0);
> + }
> }
> #endif /* CONFIG_SMP */
>=20
> --=20
> 1.7.6.1
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Kdump/kexec for mpc83xx
From: McClintock Matthew-B29882 @ 2011-10-26 0:57 UTC (permalink / raw)
To: radha krishna; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAJ4m0g4TT3dNeRXqiU1oTa+tcjn+62jjrXJYTQjMoOaDAT48xg@mail.gmail.com>
On Mon, Oct 24, 2011 at 7:35 AM, radha krishna <ramamru@gmail.com> wrote:
> Hi Team,
>
> I am using Linux-3.0 on mpc8379 RDB. I have downloaded kexec-tools-2.0.2
> package from open source and cross compiled for ppc_6xx.
> But, the kexec is not booting with kernel loaded with "kexec -l".
I'm not sure who has tested on 83xx stuff, I've only done 85xx.
-M=
^ permalink raw reply
* [PATCH 5/5] powerpc/setup_{32, 64}.c: remove unneeded boot_cpuid{, _phys}
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
boot_cpuid and init_thread_info.cpu are redundant, just use the
var that stays around longer and add a define to make boot_cpuid
point at the correct value
boot_cpudid_phys is not needed and can completely go away from the
SMP case, we leave it there for the non-SMP case since the paca
struct is not around to store this info
This patch also has the effect of having the logical cpu number
of the boot cpu be updated correctly independently of the ordering
of the cpu nodes in the device tree.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Could also just change boot_cpuid every to init_thread_info.cpu instead
of using this define
This is only tested on 32-bit parts, only compiled on 64-bit
arch/powerpc/include/asm/smp.h | 2 +-
arch/powerpc/kernel/setup_32.c | 7 ++++---
arch/powerpc/kernel/setup_64.c | 1 -
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index adba970..f26c554 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -29,7 +29,7 @@
#endif
#include <asm/percpu.h>
-extern int boot_cpuid;
+#define boot_cpuid (init_thread_info.cpu)
extern int spinning_secondaries;
extern void cpu_die(void);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index c1ce863..f396847 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -46,10 +46,11 @@
extern void bootx_init(unsigned long r4, unsigned long phys);
-int boot_cpuid = -1;
-EXPORT_SYMBOL_GPL(boot_cpuid);
-int boot_cpuid_phys;
+/* we need a place to store phys cpu for non-SMP case */
+#ifndef CONFIG_SMP
+int boot_cpuid_phys = -1;
EXPORT_SYMBOL_GPL(boot_cpuid_phys);
+#endif
int smp_hw_index[NR_CPUS];
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index d4168c9..eacefba 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -73,7 +73,6 @@
#define DBG(fmt...)
#endif
-int boot_cpuid = 0;
int __initdata spinning_secondaries;
u64 ppc64_pft_size;
--
1.7.6.1
^ permalink raw reply related
* [PATCH 4/5] powerpc/85xx: use physical cpu from device tree
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
Currently, we assume the first CPU to come up is the boot cpu. Instead
we can use the boot_cpu_phys from the device tree.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/asm-offsets.c | 4 ++++
arch/powerpc/kernel/head_fsl_booke.S | 9 ++-------
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 536ffa8..264f8ad 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -28,6 +28,7 @@
#include <linux/hardirq.h>
#endif
#include <linux/kbuild.h>
+#include <linux/of_fdt.h>
#include <asm/io.h>
#include <asm/page.h>
@@ -619,5 +620,8 @@ int main(void)
DEFINE(PACA_OPAL_MC_EVT, offsetof(struct paca_struct, opal_mc_evt));
#endif
+ DEFINE(DT_BOOTCPU, offsetof(struct boot_param_header,
+ boot_cpuid_phys));
+
return 0;
}
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 9f5d210..eb28ade 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -87,6 +87,7 @@ _ENTRY(_start);
li r25,0 /* phys kernel start (low) */
li r24,0 /* CPU number */
li r23,0 /* phys kernel start (high) */
+ lwz r22,DT_BOOTCPU(r3) /* boot_cpuid_phys */
/* We try to not make any assumptions about how the boot loader
* setup or used the TLBs. We invalidate all mappings from the
@@ -166,11 +167,8 @@ _ENTRY(__early_start)
/* Check to see if we're the second processor, and jump
* to the secondary_start code if so
*/
- lis r24, boot_cpuid@h
- ori r24, r24, boot_cpuid@l
- lwz r24, 0(r24)
- cmpwi r24, -1
mfspr r24,SPRN_PIR
+ cmpw r22,r24
bne __secondary_start
#endif
@@ -192,9 +190,6 @@ _ENTRY(__early_start)
li r0,0
stwu r0,THREAD_SIZE-STACK_FRAME_OVERHEAD(r1)
- rlwinm r22,r1,0,0,31-THREAD_SHIFT /* current thread_info */
- stw r24, TI_CPU(r22)
-
bl early_init
#ifdef CONFIG_RELOCATABLE
--
1.7.6.1
^ permalink raw reply related
* [PATCH 3/5] powerpc/85xx: Make kexec to interate over online cpus
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
This is not strictly required, because this iterates over logical
cpus and they are not (currently) discontigous. But, it's cleaner
code and more obvious what is going on
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 5b9b901..b830f8a 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -206,7 +206,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage *image)
if ( !timeout )
printk(KERN_ERR "Unable to bring down secondary cpu(s)");
- for (i = 0; i < num_cpus; i++)
+ for_each_online_cpu(i)
{
if ( i == smp_processor_id() ) continue;
mpic_reset_core(i);
--
1.7.6.1
^ permalink raw reply related
* [PATCH 1/5] powerpc/85xx: issue 15 EOI after core reset
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
This is listed as a requirement after issuing a core reset to
properly clear pending interrupts
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/sysdev/mpic.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 9678081..f5b83f0 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1748,6 +1748,7 @@ void mpic_reset_core(int cpu)
struct mpic *mpic = mpic_primary;
u32 pir;
int cpuid = get_hard_smp_processor_id(cpu);
+ int i;
/* Set target bit for core reset */
pir = mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
@@ -1759,6 +1760,12 @@ void mpic_reset_core(int cpu)
pir &= ~(1 << cpuid);
mpic_write(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT), pir);
mpic_read(mpic->gregs, MPIC_INFO(GREG_PROCESSOR_INIT));
+
+ /* Perform 15 EOI on each reset core to clear pending interrupts */
+ for (i = 0; i < 15; i++) {
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpuid],
+ MPIC_CPU_EOI, 0);
+ }
}
#endif /* CONFIG_SMP */
--
1.7.6.1
^ permalink raw reply related
* [PATCH 2/5] powerpc/fsl_booke: Fix comment in head_fsl_booke.S
From: Matthew McClintock @ 2011-10-25 22:54 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
In-Reply-To: <1319583246-6120-1-git-send-email-msm@freescale.com>
Fix typo in comments introduced by:
commit 6dece0eb69b2a28e18d104bc5d707f1cb673f5e0
Author: Scott Wood <scottwood@freescale.com>
Date: Mon Jul 25 11:29:33 2011 +0000
powerpc/32: Pass device tree address as u64 to machine_init
Signed-off-by: Matthew McClintock <msm@freescale.com>
cc: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/head_fsl_booke.S | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index e1c699f..9f5d210 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -80,8 +80,8 @@ _ENTRY(_start);
slw r18,r18,r17 /* r18 = page size */
addi r18,r18,-1
and r19,r3,r18 /* r19 = page offset */
- andc r31,r20,r18 /* r3 = page base */
- or r31,r31,r19 /* r3 = devtree phys addr */
+ andc r31,r20,r18 /* r31 = page base */
+ or r31,r31,r19 /* r31 = devtree phys addr */
mfspr r30,SPRN_MAS7
li r25,0 /* phys kernel start (low) */
--
1.7.6.1
^ permalink raw reply related
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-25 22:45 UTC (permalink / raw)
To: Pratyush Anand; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <CAHM4w1k+-KgpkW4QzRkq5wDZK0+VdVhD_QLkJy24HB0s+pE8fg@mail.gmail.com>
Hi Pratyush,
<
<Hi Tirumala,
<
<I have reviwed all the patches.
<Thanks for taking my most of the diffs over your v13.
<There are few thing, which are really very important like,
<AHB disable check, EP Disable/Stall (have commented about them in
<respective patches). I am doubtful, that how does all of usbcv test
<cases passes
<without those modifications.
<So, please have a look on those comments.
<You may add my signed-off.
<
[Tirumala Marri] I don't do all the unit tests before submission.
I only do few device tests like Ethernet and file backed storage.
For host mode I do some basic IO test. I will try embed your suggestions.
Thx,
Marri
^ permalink raw reply
* Re: [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Scott Wood @ 2011-10-25 22:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1319318452-27036-6-git-send-email-galak@kernel.crashing.org>
On 10/22/2011 04:20 PM, Kumar Gala wrote:
> All eTSEC2 controllers support waking on magic packet so fixup device
> tree to report that.
If they *all* support it, we can make the driver rely on the compatible
instead.
-Scott
^ permalink raw reply
* RE: [PATCH v15 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2011-10-25 21:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: greg, linux-usb, linuxppc-dev
In-Reply-To: <20111021173302.GB27652@quad.lixom.net>
<
<Overall this driver seems to be based on the IP vendor driver? It
<looks like a completely flexible driver that implements all possible
<combinations of everything.
<
[Tirumala Marri] Some what true that it was based on skeletal driver
Provided from IP vendor.
<And as a result, it's huge, and it's got a lot of extra code in there
<that I'm
<willing to bet that you have never even executed on your platform.
<
<Please, pare it down to the portions that you have used, and know works
<and can support. If others need the extra functionality in the future,
<they can and will expand and bring in what is needed.
<
[Tirumala Marri] I can sure review and find if there are any dead
functions.
It may not be 100% free of dead code as some of the code paths may execute
Asynchronously.
<Compare this to the dwc3 driver, which is much much cleaner.
<
[Tirumala Marri] I will check.
<Overall other comments:
<
<* Register definitions are crazy long. It means you have to do lots of
<line
< wraps to keep the 80-character limit, which makes it hard to read the
<code.
[Tirumala Marri] This was suggestion from the review to use bit shifting.
I welcome any suggestions.
<* The header files seem to have been autogenerated and have unnneeded
< shift/mask operations.
<
<* It doesn't build on non-powerpc platforms since it uses out_{b,l}e
<accessors.
<
[Tirumala Marri] You have to select Little Endian mode for LE platform
>From make menuconfig.
Thx,
Marri
^ 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