* Re: [RFCv2 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Grant Likely @ 2012-01-25 0:26 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-discuss, linux-kernel, Milton Miller, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F1F2C3A.3060607@gmail.com>
On Tue, Jan 24, 2012 at 3:10 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 01/23/2012 03:07 PM, Grant Likely wrote:
>> This patch removes the simplistic implementation of irq_domains and enab=
les
>> the powerpc infrastructure for all irq_domain users. =A0The powerpc
>> infrastructure includes support for complex mappings between Linux and
>> hardware irq numbers, and can manage allocation of irq_descs.
>>
>> This patch also converts the few users of irq_domain_add()/irq_domain_de=
l()
>> to call irq_domain_add_legacy() instead.
>>
>> v2: Fix removal of irq_alloc_descs() call in gic driver
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>> =A0arch/arm/common/gic.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 85 ++++++++--=
---------
>> =A0arch/arm/common/vic.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 16 +---
>> =A0arch/arm/include/asm/hardware/gic.h | =A0 =A04 +-
>> =A0arch/arm/include/asm/hardware/vic.h | =A0 =A02 +
>> =A0arch/arm/mach-exynos/common.c =A0 =A0 =A0 | =A0 =A02 +-
>> =A0arch/arm/mach-versatile/core.c =A0 =A0 =A0| =A0 =A05 +-
>> =A0drivers/mfd/twl-core.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 12 +--
>> =A0include/linux/irqdomain.h =A0 =A0 =A0 =A0 =A0 | =A0 45 +---------
>> =A0kernel/irq/irqdomain.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0159 +++-------=
-------------------------
>> =A09 files changed, 69 insertions(+), 261 deletions(-)
>>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>
> snip
>
>> @@ -716,17 +708,17 @@ void __init gic_init_bases(unsigned int gic_nr, in=
t irq_start,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 gic_irqs =3D 1020;
>> =A0 =A0 =A0 gic->gic_irqs =3D gic_irqs;
>>
>> - =A0 =A0 domain->nr_irq =3D gic_irqs - domain->hwirq_base;
>> - =A0 =A0 domain->irq_base =3D irq_alloc_descs(irq_start, 16, domain->nr=
_irq,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0numa_node_id());
>> - =A0 =A0 if (IS_ERR_VALUE(domain->irq_base)) {
>> + =A0 =A0 irq_base =3D irq_alloc_descs(irq_start, 16, gic_irqs - hwirq_b=
ase,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0numa_no=
de_id());
>> + =A0 =A0 if (IS_ERR_VALUE(irq_base)) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 WARN(1, "Cannot allocate irq_descs @ IRQ%d, =
assuming pre-allocated\n",
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_start);
>> - =A0 =A0 =A0 =A0 =A0 =A0 domain->irq_base =3D irq_start;
>> + =A0 =A0 =A0 =A0 =A0 =A0 irq_base =3D irq_start;
>> =A0 =A0 =A0 }
>> - =A0 =A0 domain->host_data =3D gic;
>> - =A0 =A0 domain->ops =3D &gic_irq_domain_ops;
>> - =A0 =A0 irq_domain_add(domain);
>> + =A0 =A0 gic->domain =3D irq_domain_add_legacy(node, gic_irqs, irq_base=
,
>
> gic_irqs is wrong here. It needs 16 or 32 subtracted off. This patch
> will fix things:
Good catch, I've integrated this into my series.
g.
^ permalink raw reply
* FSL SPI driver question
From: Bruce_Leonard @ 2012-01-25 0:11 UTC (permalink / raw)
To: linuxppc-dev
Good afternoon,
I'm using the 3.0.3 kernel running on an MPC8308 and am trying to
interface to a Cypress CY14B256Q2A non-volatile RAM via SPI. I've got the
SPI infrastructure, the Freescale SPI driver (drivers/spi/spi_fsl_spi.c),
and spidev built into the kernel and everything on the user space/kernel
side appears to be working correctly (at least when I try to read the
NvRAM's config register all the right places in the kernel get hit and I
see the SPI signals active with an o-scope).
I think what I'm hitting is a lack of understanding/documentation on the
SPI controller in the 8308. To read data from the NvRAM, the Master (the
8308 in this case) needs to clock out a byte long "read" command, two
bytes of address, and then clock in the data from the NvRAM. However, I
never get any data back. I think the problem is that (direct quote from
the 8308 reference manual) "SPICLK is a gated clock, active only during
data transfers". So once the read command and address are sent, the 8308
considers the data transfer complete and gates off SPICLK. Without
SPICLK, the NvRAM has no way to clock out it's data. I think it's ready
to, it just can't.
So the question is, how do I use spidev (or any other means) to get the
8308 SPI controller to keep SPICLK active so that the output data from the
NvRAM gets clocked out to the 8308?
Thanks.
Bruce
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Rob Herring @ 2012-01-25 1:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <1327450719-25590-1-git-send-email-grant.likely@secretlab.ca>
On 01/24/2012 06:18 PM, Grant Likely wrote:
> Rather than having each interrupt controller driver creating its own barely
> unique .xlate function for irq_domain, create a library of translators which
> any driver can use directly.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This builds on top of my irq_domain series and will be included with it when
> I post v3. Rob, does this serve your needs for generic irq controller DT
> support?
>
Yes, but comments below.
> g.
>
> include/linux/irqdomain.h | 15 ++++++++++
> kernel/irq/irqdomain.c | 69 +++++++++++++++++++++++++++++++++++++++-----
> 2 files changed, 76 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index e7379a3..5e497a0 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -110,6 +110,9 @@ struct irq_domain {
> void *host_data;
> irq_hw_number_t inval_irq;
>
> + /* Data for common irq xlate functions */
> + unsigned int xlate_type;
> +
How does this get set? Do we want interrupt controllers messing with the
domain struct directly long term?
> /* Optional device node pointer */
> struct device_node *of_node;
> };
> @@ -163,6 +166,18 @@ extern unsigned int irq_linear_revmap(struct irq_domain *host,
> irq_hw_number_t hwirq);
>
> extern struct irq_domain_ops irq_domain_simple_ops;
> +
> +/* stock xlate functions */
> +int irq_domain_xlate_onecell(struct irq_domain *d, struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq, unsigned int *out_type);
> +int irq_domain_xlate_twocell(struct irq_domain *d, struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq, unsigned int *out_type);
> +int irq_domain_xlate_onetwocell(struct irq_domain *d, struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq, unsigned int *out_type);
> +
> #if defined(CONFIG_OF_IRQ)
> extern void irq_domain_generate_simple(const struct of_device_id *match,
> u64 phys_base, unsigned int irq_start);
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index def8e7b..df80205 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -53,6 +53,7 @@ static struct irq_domain *irq_domain_alloc(struct device_node *of_node,
> domain->ops = ops;
> domain->host_data = host_data;
> domain->of_node = of_node_get(of_node);
> + domain->xlate_type = IRQ_TYPE_NONE;
>
> if (domain->ops->match == NULL)
> domain->ops->match = default_irq_domain_match;
> @@ -690,25 +691,77 @@ int irq_domain_simple_map(struct irq_domain *d, unsigned int irq,
> return 0;
> }
>
> -int irq_domain_simple_xlate(struct irq_domain *d,
> - struct device_node *controller,
> - const u32 *intspec, unsigned int intsize,
> - unsigned long *out_hwirq, unsigned int *out_type)
> +/**
> + * irq_domain_xlate_onecell() - Generic xlate for direct one cell bindings
> + *
> + * Device Tree IRQ specifier translation function which works with one cell
> + * bindings where the cell value maps directly to the hwirq number.
> + */
> +int irq_domain_xlate_onecell(struct irq_domain *d, struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq, unsigned int *out_type)
> +{
> + if (WARN(intsize < 1, "Bad intspec for %s: intsize=%i < 1\n",
> + ctrlr->full_name, intsize))
> + return -EINVAL;
> + *out_hwirq = intspec[0];
> + *out_type = d->xlate_type;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
> +
> +/**
> + * irq_domain_xlate_twocell() - Generic xlate for direct two cell bindings
> + *
> + * Device Tree IRQ specifier translation function which works with two cell
> + * bindings where the cell values map directly to the hwirq number
> + * and linux irq flags.
> + */
> +int irq_domain_xlate_twocell(struct irq_domain *d, struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq, unsigned int *out_type)
> {
> - if (d->of_node != controller)
> + if (WARN(intsize < 2, "Bad intspec for %s: intsize=%i < 2\n",
> + ctrlr->full_name, intsize))
> + return -EINVAL;
> + if (intsize < 2)
You've already checked this...
> return -EINVAL;
> - if (intsize < 1)
> + *out_hwirq = intspec[0];
> + *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
> +
> +/**
> + * irq_domain_xlate_onetwocell() - Generic xlate for one or two cell bindings
> + *
> + * Device Tree IRQ specifier translation function which works with either one
> + * or two cell bindings where the cell values map directly to the hwirq number
> + * and linux irq flags.
> + *
> + * Note: don't use this function unless your interrupt controller explicitly
> + * supports both one and two cell bindings. For the majority of controllers
> + * the _onecell() or _twocell() variants above should be used.
This comment is confusing since you turn around and use it for simple
ops below.
> + */
> +int irq_domain_xlate_onetwocell(struct irq_domain *d,
> + struct device_node *ctrlr,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq, unsigned int *out_type)
> +{
> + if (WARN(intsize < 1, "Bad intspec for %s: intsize=%i < 1\n",
> + ctrlr->full_name, intsize))
> return -EINVAL;
Isn't this check redundant with the check in of_irq_map_raw:
if (ointsize != intsize)
return -EINVAL;
The only diff in these functions is really checking the size. So I
really don't think we need 3 versions if that can be factored out where
you know value of #interrupt-cells.
Rob
> *out_hwirq = intspec[0];
> - *out_type = IRQ_TYPE_NONE;
> + *out_type = d->xlate_type;
> if (intsize > 1)
> *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> return 0;
> }
> +EXPORT_SYMBOL_GPL(irq_domain_xlate_onetwocell);
>
> struct irq_domain_ops irq_domain_simple_ops = {
> .map = irq_domain_simple_map,
> - .xlate = irq_domain_simple_xlate,
> + .xlate = irq_domain_xlate_onetwocell,
> };
> EXPORT_SYMBOL_GPL(irq_domain_simple_ops);
>
^ permalink raw reply
* [PATCH] powerpc/powernv: Fix PCI resource handling
From: Benjamin Herrenschmidt @ 2012-01-25 2:36 UTC (permalink / raw)
To: linuxppc-dev
Recent changes to the handling of PCI resources for host bridges
are breaking the PowerNV code for assigning resources on IODA.
The root of the problem is that the pci_bus attached to a host
bridge no longer has its "legacy" resource pointers populated
but only uses the newer list instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 43 ++++++++++++++++++-----------
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index f31162c..5e155df 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -204,11 +204,10 @@ static void __devinit pnv_ioda_offset_bus(struct pci_bus *bus,
pr_devel(" -> OBR %s [%x] +%016llx\n",
bus->self ? pci_name(bus->self) : "root", flags, offset);
- for (i = 0; i < 2; i++) {
- r = bus->resource[i];
+ pci_bus_for_each_resource(bus, r, i) {
if (r && (r->flags & flags)) {
- bus->resource[i]->start += offset;
- bus->resource[i]->end += offset;
+ r->start += offset;
+ r->end += offset;
}
}
list_for_each_entry(dev, &bus->devices, bus_list)
@@ -288,12 +287,17 @@ static void __devinit pnv_ioda_calc_bus(struct pci_bus *bus, unsigned int flags,
* assignment algorithm is going to be uber-trivial for now, we
* can try to be smarter later at filling out holes.
*/
- start = bus->self ? 0 : bus->resource[bres]->start;
-
- /* Don't hand out IO 0 */
- if ((flags & IORESOURCE_IO) && !bus->self)
- start += 0x1000;
-
+ if (bus->self) {
+ /* No offset for downstream bridges */
+ start = 0;
+ } else {
+ /* Offset from the root */
+ if (flags & IORESOURCE_IO)
+ /* Don't hand out IO 0 */
+ start = hose->io_resource.start + 0x1000;
+ else
+ start = hose->mem_resources[0].start;
+ }
while(!list_empty(&head)) {
w = list_first_entry(&head, struct resource_wrap, link);
list_del(&w->link);
@@ -321,13 +325,20 @@ static void __devinit pnv_ioda_calc_bus(struct pci_bus *bus, unsigned int flags,
empty:
/* Only setup P2P's, not the PHB itself */
if (bus->self) {
- WARN_ON(bus->resource[bres] == NULL);
- bus->resource[bres]->start = 0;
- bus->resource[bres]->flags = (*size) ? flags : 0;
- bus->resource[bres]->end = (*size) ? (*size - 1) : 0;
+ struct resource *res = bus->resource[bres];
+
+ if (WARN_ON(res == NULL))
+ return;
- /* Clear prefetch bus resources for now */
- bus->resource[2]->flags = 0;
+ /*
+ * FIXME: We should probably export and call
+ * pci_bridge_check_ranges() to properly re-initialize
+ * the PCI portion of the flags here, and to detect
+ * what the bridge actually supports.
+ */
+ res->start = 0;
+ res->flags = (*size) ? flags : 0;
+ res->end = (*size) ? (*size - 1) : 0;
}
pr_devel("<- CBR %s [%x] *size=%016llx *align=%016llx\n",
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-01-25 3:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a few fixes on top of rc1, a couple of important compile
regressions and a couple of minor embedded additions.
Cheers,
Ben.
The following changes since commit 4a7cbb56fdbd92a47f57ca8b25bf5db35f0d6518:
regulator: Fix documentation for of_node parameter of regulator_register() (2012-01-24 10:40:06 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (3):
Merge remote-tracking branch 'kumar/merge' into merge
powerpc/powernv: Fix PCI resource handling
powerpc: Fix build on some non-freescale platforms
Christian Kujau (1):
powerpc/crash: Fix build error without SMP
Deepthi Dharwar (1):
powerpc/cpuidle: Make it a bool, not a tristate
Jerry Huang (1):
powerpc/85xx: Fix cmd12 bug and add the chip compatible for eSDHC
Julia Lawall (1):
arch/powerpc/sysdev/fsl_pci.c: add missing iounmap
Michael Neuling (1):
powerpc: fix compile error with 85xx/p1022_ds.c
Ramneek Mehresh (2):
powerpc/85xx: Enable USB2 controller node for P1020RDB
powerpc/85xx: Add dr_mode property in USB nodes
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 3 +-
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 4 ++
arch/powerpc/boot/dts/p1020rdb.dtsi | 13 +++----
arch/powerpc/boot/dts/p1021mds.dts | 3 +-
arch/powerpc/boot/dts/p2020ds.dtsi | 3 +-
arch/powerpc/boot/dts/p2020rdb.dts | 3 +-
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/legacy_serial.c | 2 +
arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
arch/powerpc/platforms/powernv/pci-ioda.c | 43 +++++++++++++++---------
arch/powerpc/platforms/pseries/Kconfig | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 5 ++-
15 files changed, 63 insertions(+), 32 deletions(-)
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Grant Likely @ 2012-01-25 5:35 UTC (permalink / raw)
To: Rob Herring; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <4F1F5FE0.9090901@gmail.com>
On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wrote:
>
>
> On 01/24/2012 06:18 PM, Grant Likely wrote:
>> Rather than having each interrupt controller driver creating its own bar=
ely
>> unique .xlate function for irq_domain, create a library of translators w=
hich
>> any driver can use directly.
>>
>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>> index e7379a3..5e497a0 100644
>> --- a/include/linux/irqdomain.h
>> +++ b/include/linux/irqdomain.h
>> @@ -110,6 +110,9 @@ struct irq_domain {
>> =A0 =A0 =A0 void *host_data;
>> =A0 =A0 =A0 irq_hw_number_t inval_irq;
>>
>> + =A0 =A0 /* Data for common irq xlate functions */
>> + =A0 =A0 unsigned int xlate_type;
>> +
>
> How does this get set? Do we want interrupt controllers messing with the
> domain struct directly long term?
It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
override it. Alternately it could be made part of the
irq_domain_add() arguments, but I'm not thrilled with adding a whole
bunch of arguments to the function prototype.
>
>> =A0 =A0 =A0 /* Optional device node pointer */
>> =A0 =A0 =A0 struct device_node *of_node;
>> =A0};
>> @@ -163,6 +166,18 @@ extern unsigned int irq_linear_revmap(struct irq_do=
main *host,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
irq_hw_number_t hwirq);
>>
>> =A0extern struct irq_domain_ops irq_domain_simple_ops;
>> +
>> +/* stock xlate functions */
>> +int irq_domain_xlate_onecell(struct irq_domain *d, struct device_node *=
ctrlr,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned i=
nt intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, un=
signed int *out_type);
>> +int irq_domain_xlate_twocell(struct irq_domain *d, struct device_node *=
ctrlr,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned i=
nt intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, un=
signed int *out_type);
>> +int irq_domain_xlate_onetwocell(struct irq_domain *d, struct device_nod=
e *ctrlr,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned i=
nt intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, un=
signed int *out_type);
>> +
>> =A0#if defined(CONFIG_OF_IRQ)
>> =A0extern void irq_domain_generate_simple(const struct of_device_id *mat=
ch,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 u64 phys_base, unsigned int irq_start);
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index def8e7b..df80205 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -53,6 +53,7 @@ static struct irq_domain *irq_domain_alloc(struct devi=
ce_node *of_node,
>> =A0 =A0 =A0 domain->ops =3D ops;
>> =A0 =A0 =A0 domain->host_data =3D host_data;
>> =A0 =A0 =A0 domain->of_node =3D of_node_get(of_node);
>> + =A0 =A0 domain->xlate_type =3D IRQ_TYPE_NONE;
>>
>> =A0 =A0 =A0 if (domain->ops->match =3D=3D NULL)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 domain->ops->match =3D default_irq_domain_ma=
tch;
>> @@ -690,25 +691,77 @@ int irq_domain_simple_map(struct irq_domain *d, un=
signed int irq,
>> =A0 =A0 =A0 return 0;
>> =A0}
>>
>> -int irq_domain_simple_xlate(struct irq_domain *d,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct device_node *co=
ntroller,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, un=
signed int intsize,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long *out_hwi=
rq, unsigned int *out_type)
>> +/**
>> + * irq_domain_xlate_onecell() - Generic xlate for direct one cell bindi=
ngs
>> + *
>> + * Device Tree IRQ specifier translation function which works with one =
cell
>> + * bindings where the cell value maps directly to the hwirq number.
>> + */
>> +int irq_domain_xlate_onecell(struct irq_domain *d, struct device_node *=
ctrlr,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const u32 *intspec,=
unsigned int intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *out_=
hwirq, unsigned int *out_type)
>> +{
>> + =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> + =A0 =A0 *out_hwirq =3D intspec[0];
>> + =A0 =A0 *out_type =3D d->xlate_type;
>> + =A0 =A0 return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
>> +
>> +/**
>> + * irq_domain_xlate_twocell() - Generic xlate for direct two cell bindi=
ngs
>> + *
>> + * Device Tree IRQ specifier translation function which works with two =
cell
>> + * bindings where the cell values map directly to the hwirq number
>> + * and linux irq flags.
>> + */
>> +int irq_domain_xlate_twocell(struct irq_domain *d, struct device_node *=
ctrlr,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned i=
nt intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, un=
signed int *out_type)
>> =A0{
>> - =A0 =A0 if (d->of_node !=3D controller)
>> + =A0 =A0 if (WARN(intsize < 2, "Bad intspec for %s: intsize=3D%i < 2\n"=
,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> + =A0 =A0 if (intsize < 2)
>
> You've already checked this...
cut-and-paste error. Fixed.
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 if (intsize < 1)
>> + =A0 =A0 *out_hwirq =3D intspec[0];
>> + =A0 =A0 *out_type =3D intspec[1] & IRQ_TYPE_SENSE_MASK;
>> + =A0 =A0 return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
>> +
>> +/**
>> + * irq_domain_xlate_onetwocell() - Generic xlate for one or two cell bi=
ndings
>> + *
>> + * Device Tree IRQ specifier translation function which works with eith=
er one
>> + * or two cell bindings where the cell values map directly to the hwirq=
number
>> + * and linux irq flags.
>> + *
>> + * Note: don't use this function unless your interrupt controller expli=
citly
>> + * supports both one and two cell bindings. =A0For the majority of cont=
rollers
>> + * the _onecell() or _twocell() variants above should be used.
>
> This comment is confusing since you turn around and use it for simple
> ops below.
I intend to faze out the generic simple ops so that most drivers will
explicitly use _onecell or _twocell.
>> + */
>> +int irq_domain_xlate_onetwocell(struct irq_domain *d,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct device_=
node *ctrlr,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *int=
spec, unsigned int intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long =
*out_hwirq, unsigned int *out_type)
>> +{
>> + =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>
> Isn't this check redundant with the check in of_irq_map_raw:
>
> =A0 =A0 =A0 =A0if (ointsize !=3D intsize)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EINVAL;
No. It's a different test. The core code does indeed ensure that
intsize matches the #interrupt-cells value defined in the device tree,
but it does nothing to check if the #interrupt-cells value is set to
something sane. This test ensures that the xlate function will not
dereference beyond the end of the intspec array.
Ideally the interrupt controller driver should already verify the
#interrupt-cells value at initialization, but I'm not going to rely on
it when this test is so cheap. The intent is to be really noisy about
bad data in the device tree.
> The only diff in these functions is really checking the size. So I
> really don't think we need 3 versions if that can be factored out where
> you know value of #interrupt-cells.
There are subtleties here and #interrupt-cells is not always the
correct thing to test. For example, some powerpc controllers has
#interrupt-cells =3D <2>, but the second cell must be ignored so the
_onecell version is the correct function. I originally investigated
parameterizing a single function, but I didn't like how it ended up
looking because it would require adding something like irq_cells_min
and irq_cells_max to the irq_domain structure. I think using
variations on the function ends up being cleaner. I may also add
something like a ..._twocell_lookup() version that uses a lookup table
for the type values to handle the other type of xlate common in the
powerpc tree.
Thanks for the quick review.
g.
^ permalink raw reply
* RE: Problem in getting shared memory access on P1022RDK
From: Arshad, Farrukh @ 2012-01-25 11:04 UTC (permalink / raw)
To: tiejun.chen; +Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F0E9539.7090205@windriver.com>
SSBoYXZlIGR1bXBlZCBUTEIgZW50cmllcyB3aGlsZSBtYXBwaW5nIHNoYXJlZCBtZW1vcnkuIE9u
IGJvdGggY29yZXMgTS1CaXQgKE1BUzJbNjFdKSBpcyBzZXQgaW4gVExCMCBlbnRyaWVzLiBPbiBi
b3RoIGNvcmVzIE0tQml0IGlzIHNldCBmb3IgYWxsIHZhbGlkIFRMQjEgZW50cmllcy4gVExCMSBk
b2VzIGNvbnRhaW5zIHNvbWUgaW52YWxpZCBlbnRyaWVzIHdoaWNoIGhhcyBNLUJpdCBjbGVhcmVk
LiBTbyBJIGJlbGlldmUgYXQgdGhpcyB0aW1lIHRoZSBjb2hlcmVuY3kgaXMgbm90IHRoZSBpc3N1
ZS4gQW55IGZ1cnRoZXIgdGhvdWdodHMgb24gdGhlIGlzc3VlID8NCg0KSSBoYXZlIG1vZGlmaWVk
IGR1bXBfdGxiX2Jvb2szZSBmdW5jdGlvbiAoZm91bmQgaW4gYXJjaC9wb3dlcnBjL3htb24veG1v
bi5jKSBmdW5jdGlvbiBmb3IgQm9va0UgTU1VIHRvIGR1bXAgVExCIGVudHJpZXMuDQoNClJlZ2Fy
ZHMsDQpGYXJydWtoIEFyc2hhZA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiB0aWVqdW4uY2hlbiBbbWFpbHRvOnRpZWp1bi5jaGVuQHdpbmRyaXZlci5jb21dIA0KU2VudDog
VGh1cnNkYXksIEphbnVhcnkgMTIsIDIwMTIgMTowOSBQTQ0KVG86IEFyc2hhZCwgRmFycnVraA0K
Q2M6IFNjb3R0IFdvb2Q7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQpTdWJqZWN0OiBS
ZTogUHJvYmxlbSBpbiBnZXR0aW5nIHNoYXJlZCBtZW1vcnkgYWNjZXNzIG9uIFAxMDIyUkRLDQoN
CkFyc2hhZCwgRmFycnVraCB3cm90ZToNCj4gQWRkaW5nIG1vcmUgaXQsDQo+IA0KPiBJIGhhdmUg
cmVtb3ZlZCB0aGUgc2hhcmVkIG1lbW9yeSBrZXJuZWwgZHJpdmVyIGRlcGVuZGVuY3kganVzdCB0
byBuYXJyb3cgZG93biB0aGUgcHJvYmxlbSBhcmVhIGFuZCBJIGhhdmUgd3JpdHRlbiBhIHNtYWxs
IHBpZWNlIG9mIGNvZGUgaW4gdXNlciBzcGFjZS4gQSB3cml0ZXIgJiBhIHJlYWRlciBhcHBsaWNh
dGlvbiB3aGljaCBhY2Nlc3MgdGhlIHNoYXJlZCBtZW1vcnkgYW5kIEkgZ290IHRoZSBzYW1lIGJl
aGF2aW9yIGFzIHdpdGggdGhlIHNoYXJlZCBtZW1vcnkga2VybmVsIGRyaXZlci4gSW50ZXJlc3Rp
bmdseSwgbXkgdXNlciBzcGFjZSBhcHBsaWNhdGlvbiB3b3JrIGZpbmUgb24gUDEwMjJEUyBidXQg
bm90IG9uIFAxMDIyUkRLIGhvd2V2ZXIgYm90aCB1c2luZyB0aGUgc2FtZSBDUFUgbW9kdWxlcy4N
Cj4gDQo+IFdoZW4gSSB3cml0ZSBhIHNpbXBsZSBzdHJpbmcgb24gc2hhcmVkIG1lbW9yeSBmcm9t
IENvcmUgMSBpdCBpcyByZWFkIA0KPiBhdCBDb3JlIDAgcHJvcGVybHkgV2hlbiBJIHdyaXRlIGEg
c2ltcGxlIHN0cmluZyBvbiBzaGFyZWQgbWVtb3J5IGZyb20gQ29yZSAwIGl0IGlzIG5vdCByZWFk
IGF0IENvcmUgMS4NCj4NCg0KRGlkIHlvdSBkdW1wIFRMQiBlbnRyeSB0byBjaGVjayBwYWdlIG1l
bW9yeSBjb2hlcmVuY2UgYXR0cmlidXRlIGZvciBhIHNoYXJlZCBtZW1vcnkgYXMgSSBtZW50aW9u
ZWQgcHJldmlvdXNseT8gVGhpcyBzaG91bGQgYmUgY29uc2lzdGVudCBvbiBib3RoIHNpZGVzLg0K
DQo+IFdpdGggdGhpcyB0ZXN0IG5vdyBJIGFtIHN1cmUgdGhlIHByb2JsZW0gbGllcyBpbiB0aGUg
a2VybmVsIGl0c2VsZi4gQW55IHBvaW50ZXJzIHRvIGxvb2sgZm9yIHRoZSB0cm91YmxlZCBhcmVh
ID8NCj4gDQo+IE15IGFwcGxpY2F0aW9uIGNvZGUgaXMgKGVycm9yIGNoZWNraW5nIGFuZCBvdGhl
ciBjb2RlIGlzIG9taXR0ZWQpDQo+IA0KPiAjZGVmaW5lIAlTSE1fQkFTRSAJMHgxQzAwMDAwMA0K
PiAjZGVmaW5lCVNITV9TSVpFIAkweDQwMDAwMAkJLy8gNCBNQiBvZiBTaGFyZWQgTWVtb3J5DQo+
ICNkZWZpbmUgCVBBR0VfU0laRSAJKDQqMTAyNCkNCj4gDQo+IGZkID0gb3BlbihkZXZpY2UsIE9f
UkRXUik7DQoNCllvdSBtYXkgbmVlZCB0byBhZGQgd2l0aCAnT19TWU5DJy4NCg0KVGllanVuDQoN
Cj4gDQo+IHNobSA9IG1hbGxvYyhTSE1fU0laRSArIChQQUdFX1NJWkUgLSAxKSk7IGlmICggKHVu
c2lnbmVkIGxvbmcpIHNobSAlIA0KPiBQQUdFX1NJWkUpIHsNCj4gCXNobSArPSBQQUdFX1NJWkUg
LSAoKHVuc2lnbmVkIGxvbmcpc2htICUgUEFHRV9TSVpFKTsgfQ0KPiANCj4gc2htID0gbW1hcChz
aG0sIFNITV9TSVpFLCBQUk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1NIQVJFRCB8IA0KPiBNQVBf
RklYRUQsIGZkLCBTSE1fQkFTRSk7IC4uLi4uLg0KPiAuLi4uLi4gd3JpdGUgc29tZSBzdHJpbmcg
YXQgc2htLg0KPiANCj4gTXkgbWVtb3J5IHBhcnRpdGlvbmluZyBmb3IgYm90aCBzeXN0ZW1zIGlz
DQo+IA0KPiBDb3JlICAgICAgICAgICAgICAgICAJCUJhc2UgQWRkcmVzcyAgICAgICAgIAlTaXpl
DQo+IENvcmUgMCAgICAgICAgICAgICAgIAkJMHgwMDAwLDAwMDAgICAgICAgICAgCTB4MTAwMCww
MDAwDQo+IENvcmUgMSAgICAgICAgICAgICAgIAkJMHgxMDAwLDAwMDAgICAgICAgICAgCTB4MEMw
MCwwMDAwDQo+IFNoYXJlZCBNZW1vcnkgICAgCTB4MUMwMCwwMDAwICAgICAgICAgIAkweDA0MDAs
MDAwMA0KPiANCj4gUmVnYXJkcywNCj4gRmFycnVraCBBcnNoYWQuDQo+IE1lbnRvciBHcmFwaGlj
cyBQYWtpc3Rhbg0KDQo=
^ permalink raw reply
* Re: FSL SPI driver question
From: Norbert van Bolhuis @ 2012-01-25 13:33 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF74786861.90D91C05-ON8825798F.0083A71E-88257990.000118E7@selinc.com>
On 01/25/12 01:11, Bruce_Leonard@selinc.com wrote:
> Good afternoon,
>
> I'm using the 3.0.3 kernel running on an MPC8308 and am trying to
> interface to a Cypress CY14B256Q2A non-volatile RAM via SPI. I've got the
> SPI infrastructure, the Freescale SPI driver (drivers/spi/spi_fsl_spi.c),
> and spidev built into the kernel and everything on the user space/kernel
> side appears to be working correctly (at least when I try to read the
> NvRAM's config register all the right places in the kernel get hit and I
> see the SPI signals active with an o-scope).
>
> I think what I'm hitting is a lack of understanding/documentation on the
> SPI controller in the 8308. To read data from the NvRAM, the Master (the
> 8308 in this case) needs to clock out a byte long "read" command, two
> bytes of address, and then clock in the data from the NvRAM. However, I
> never get any data back. I think the problem is that (direct quote from
> the 8308 reference manual) "SPICLK is a gated clock, active only during
> data transfers". So once the read command and address are sent, the 8308
> considers the data transfer complete and gates off SPICLK. Without
> SPICLK, the NvRAM has no way to clock out it's data. I think it's ready
> to, it just can't.
>
> So the question is, how do I use spidev (or any other means) to get the
> 8308 SPI controller to keep SPICLK active so that the output data from the
> NvRAM gets clocked out to the 8308?
>
> Thanks.
>
> Bruce
Did you see Documentation/spi/spidev_fdx.c:do_msg ?
it perform a full-duplex (actually half-duplex) 1 byte transfer.
In your case you need a transfer that outputs 3 bytes (read cmd + address)
and inputs 1? byte.
If you do it this way I would expect the SPICLK to be active
during the 2nd part of the transfer (whenever the CPU "reads" the
data from SPI client).
hth.
---
NvBolhuis
^ permalink raw reply
* Re: [RFCv2 00/14]
From: Cousson, Benoit @ 2012-01-25 14:13 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-discuss, linux-kernel, Milton Miller, Shawn Guo,
linuxppc-dev
In-Reply-To: <4F1DD6DF.4080706@gmail.com>
On 1/23/2012 10:53 PM, Rob Herring wrote:
> On 01/23/2012 03:07 PM, Grant Likely wrote:
>>
>> Hey everyone,
>>
>> Here's the second RFC for the irq_domain patches. I could use some
>> help testing now. I still expect there will be a few bugs. The
>> series is based on v3.3-rc1, and I've pushed it out to my git server:
>>
>> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
>
> Can you post to linux-arm-kernel too so people are aware of this work
> and stop posting dead-end irqdomain patches.
Good point, I have two pending series that are using the
irq_domain_add() so far, so it will be good to have that branch pulled
in arm-soc.
> I tested what you had as of this morning and it works fine for me. Looks
> like the only diff is the VExpress code. I'm working on rebasing my
> domain support for generic irqchip now.
In fact your generic irqchip should even avoid us to use
irq_domain_add_legacy() since both GPIO and OMAP3 intc are already using
the irqchip.
I guess you are not going to change the interface so the patches I did
on your previous branch to try them should be good already, isn't it?
Thanks,
Benoit
^ permalink raw reply
* Re: [PATCH] powerpc/booke64: Configurable lazy interrupt disabling
From: Tudor Laurentiu @ 2012-01-25 14:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, Stuart Yoder
In-Reply-To: <1327351831.19850.9.camel@pasglop>
On 01/23/2012 10:50 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-01-23 at 13:21 -0600, Scott Wood wrote:
>
>>> BTW, for non-booke, when is DEC checked when interrupts are hard-enabled
>>> as part of exception return? Likewise with the PS3 HV thing. I only
>>> see the iseries check in the exception path.
>
> Exception return restores them to their previous state, so shouldn't be
> a problem unless your exception takes long enough to overflow the DEC in
> which case you have other problems. The PS/3 case might be broken.
>
>> Perhaps the issues with a higher priority interrupt intervening can be
>> addressed by messing around with current task priority at the MPIC (with
>> an hcall introduced for the hv case, since currently task priority is
>> not exposed to the guest). I haven't had time to revisit this, and
>> don't expect to soon. If someone else wants to try, fine. In the
>> meantime, lazy EE is causing problems.
>
> Or by storing pending interrupts in an array.
>
>> I'd still like to know the answer to that last question. It's difficult
>> to determine how to correctly implement this stuff for our hardware if
>> it looks like there are holes in the scheme for hardware that this is
>> supposed to already work with.
>>
>>> Traditionally EE's have always been "level sensitive" on PowerPC,
>>
>> You mean besides the places you already have to work around, such as
>> doorbells
>
> Which you introduced as well... this is especially ironic since BookE
> had the decrementer done right in the first place :-)
>
>> and book3s decrementers
>
> Book3s decrementer is level sensitive based on the sign bit of the
> decrementer (a bit odd but heh....) at least on 64-bit processors.
>
>> and other hypervisors...
>
> I wouldn't take the PS3 HV and legacy iseries HV as good design
> examples :-) The later was working around limited HW functionality at
> the time as well.
>
>> and you force
>> all functions that enable interrupts to create a stack frame to deal
>> with this.
>
> Right, but overall this is still more efficient performance wise on most
> processors than whacking the MSR.
>
> However the main thing is that this significantly improves the quality
> of the samples obtained from performance interrupts which can now act as
> pseudo-NMI up to a certain point.
>
> It also helps with Alex PR KVM but that's just a detail really.
>
>>> the way you changed that is arguably an utterly broken HW design
>>
>> Just because you don't like it, and it doesn't play well with your hack,
>> doesn't make it "utterly broken".
>
> Deal with it. The "hack" has been there for long enough and works well.
> I don't want compile-time conditional to change that behaviour.
>
>>> and I am not too keen on changing our core interrupt handling to deal with it via
>>> ifdef's if we can find a less invasive solution.
>>
>> Wheras having to significantly change the way interrupts work because
>> the register size doubled is so totally reasonable...
>
> We were very tempted at some point to do lazy EE for 32-bit as well,
> eventually decided we didn't care enough :-)
>
>> What is the compelling reason for forcing lazy EE on us? Why is it tied
>> to 64-bit?
>
> Because that's where we historically implemented it and because iSeries
> more/less required to begin with. And I don't want to have a split
> scheme, especially not a compile time one.
I'm thinking that we could get rid of the compile time option by using
the "feature fixup" mechanism.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Grant Likely @ 2012-01-25 17:59 UTC (permalink / raw)
To: Rob Herring; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <CACxGe6s3R0fcBSf_YHTpXp15gtEBHRQg5-YM=cDO5UfY9cRGrQ@mail.gmail.com>
On Tue, Jan 24, 2012 at 10:35 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wrot=
e:
>>
>>
>> On 01/24/2012 06:18 PM, Grant Likely wrote:
>>> Rather than having each interrupt controller driver creating its own ba=
rely
>>> unique .xlate function for irq_domain, create a library of translators =
which
>>> any driver can use directly.
>>>
>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>> index e7379a3..5e497a0 100644
>>> --- a/include/linux/irqdomain.h
>>> +++ b/include/linux/irqdomain.h
>>> @@ -110,6 +110,9 @@ struct irq_domain {
>>> =A0 =A0 =A0 void *host_data;
>>> =A0 =A0 =A0 irq_hw_number_t inval_irq;
>>>
>>> + =A0 =A0 /* Data for common irq xlate functions */
>>> + =A0 =A0 unsigned int xlate_type;
>>> +
>>
>> How does this get set? Do we want interrupt controllers messing with the
>> domain struct directly long term?
>
> It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
> override it. =A0Alternately it could be made part of the
> irq_domain_add() arguments, but I'm not thrilled with adding a whole
> bunch of arguments to the function prototype.
Do you like this better (built on top of this patch)?
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index ef2b1fe..7856c04 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -701,12 +701,10 @@ int irq_domain_xlate_onecell(struct irq_domain
*d, struct device_node *ctrlr,
const u32 *intspec, unsigned int intsize,
unsigned long *out_hwirq, unsigned int *out_type)
{
- if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n",
- ctrlr->full_name, intsize))
+ if (WARN_ON(intsize < 1))
return -EINVAL;
- *out_hwirq =3D intspec[0];
- *out_type =3D d->xlate_type;
- return 0;
+ return irq_domain_xlate_onetwocell(d, ctrlr, intspec, 1,
+ out_hwirq, out_type);
}
EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
@@ -721,12 +719,10 @@ int irq_domain_xlate_twocell(struct irq_domain
*d, struct device_node *ctrlr,
const u32 *intspec, unsigned int intsize,
irq_hw_number_t *out_hwirq, unsigned int *out_type)
{
- if (WARN(intsize < 2, "Bad intspec for %s: intsize=3D%i < 2\n",
- ctrlr->full_name, intsize))
+ if (WARN_ON(intsize < 2))
return -EINVAL;
- *out_hwirq =3D intspec[0];
- *out_type =3D intspec[1] & IRQ_TYPE_SENSE_MASK;
- return 0;
+ return irq_domain_xlate_onetwocell(d, ctrlr, intspec, intsize,
+ out_hwirq, out_type);
}
EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
@@ -746,8 +742,7 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
const u32 *intspec, unsigned int intsize,
unsigned long *out_hwirq, unsigned int *out_type)
{
- if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n",
- ctrlr->full_name, intsize))
+ if (WARN_ON(intsize < 1))
return -EINVAL;
*out_hwirq =3D intspec[0];
*out_type =3D d->xlate_type;
^ permalink raw reply related
* Re: [RFCv2 00/14]
From: Rob Herring @ 2012-01-25 18:51 UTC (permalink / raw)
To: Cousson, Benoit
Cc: devicetree-discuss, linux-kernel, Milton Miller, Shawn Guo,
linuxppc-dev
In-Reply-To: <4F200DFD.7070407@ti.com>
On 01/25/2012 08:13 AM, Cousson, Benoit wrote:
> On 1/23/2012 10:53 PM, Rob Herring wrote:
>> On 01/23/2012 03:07 PM, Grant Likely wrote:
>>>
>>> Hey everyone,
>>>
>>> Here's the second RFC for the irq_domain patches. I could use some
>>> help testing now. I still expect there will be a few bugs. The
>>> series is based on v3.3-rc1, and I've pushed it out to my git server:
>>>
>>> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
>>
>> Can you post to linux-arm-kernel too so people are aware of this work
>> and stop posting dead-end irqdomain patches.
>
> Good point, I have two pending series that are using the
> irq_domain_add() so far, so it will be good to have that branch pulled
> in arm-soc.
>
>> I tested what you had as of this morning and it works fine for me. Looks
>> like the only diff is the VExpress code. I'm working on rebasing my
>> domain support for generic irqchip now.
>
> In fact your generic irqchip should even avoid us to use
> irq_domain_add_legacy() since both GPIO and OMAP3 intc are already using
> the irqchip.
>
> I guess you are not going to change the interface so the patches I did
> on your previous branch to try them should be good already, isn't it?
I've got it rebased on top of Grant's tree. I will send it out soon.
One problem that still remains is it breaks x86 and any platform using
generic irq chip, but not selecting IRQ_DOMAIN. Grant, do you plan to
enable IRQ_DOMAIN for x86 in your series? MIPS may also need fixing.
Rob
^ permalink raw reply
* Re: FSL SPI driver question
From: Bruce_Leonard @ 2012-01-25 19:49 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev
In-Reply-To: <4F2004B1.5030607@aimvalley.nl>
Hi Norbert,
> >
> > So the question is, how do I use spidev (or any other means) to get
the
> > 8308 SPI controller to keep SPICLK active so that the output data from
the
> > NvRAM gets clocked out to the 8308?
> >
>
> Did you see Documentation/spi/spidev_fdx.c:do_msg ?
> it perform a full-duplex (actually half-duplex) 1 byte transfer.
>
> In your case you need a transfer that outputs 3 bytes (read cmd +
address)
> and inputs 1? byte.
>
> If you do it this way I would expect the SPICLK to be active
> during the 2nd part of the transfer (whenever the CPU "reads" the
> data from SPI client).
>
Thanks for the reply. Yes I did find spidev_fdx.c and in fact copied it
for my tests. I still see SPICLK active only during the time the 8308 is
sending data (read cmd + address). Nothing happens with the clock after
that when the NvRAM is ready to send data.
Bruce
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
From: Tabi Timur-B04825 @ 2012-01-25 20:55 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1327035611-22794-2-git-send-email-B32736@freescale.com>
On Thu, Jan 19, 2012 at 11:00 PM, Zhicheng Fan <B32736@freescale.com> wrote=
:
> Signed-off-by: Fanzc <b32736@freeescale.com>
Please fix this. There are only two e's in freescale. In addition,
please use your full name.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [RFCv2 00/14]
From: Mark Salter @ 2012-01-25 22:53 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
linuxppc-dev
In-Reply-To: <1327352870-14687-1-git-send-email-grant.likely@secretlab.ca>
On Mon, 2012-01-23 at 14:07 -0700, Grant Likely wrote:
> Hey everyone,
>
> Here's the second RFC for the irq_domain patches. I could use some
> help testing now. I still expect there will be a few bugs. The
> series is based on v3.3-rc1, and I've pushed it out to my git server:
Hi Grant,
I converted arch/c6x over to the generic irq_domain support and have not
had any problems in testing. The c6x virtual irq support was a nearly
identical copy of the powerpc code, so the patch I ended up with mostly
copied what you did in arch/powerpc. The c6x patch is on the tip of:
git@linux-c6x.org:/git/projects/linux-c6x-upstreaming irq-testing
I think this probably belongs in your series, but I can push it
separately if not.
--Mark
^ permalink raw reply
* [PATCH] irq: make SPARSE_IRQ an optionally hidden option
From: Rob Herring @ 2012-01-26 2:58 UTC (permalink / raw)
To: linux-kernel
Cc: Russell King, linux-c6x-dev, Aurelien Jacquiot, linux-sh,
H. Peter Anvin, Rob Herring, Paul Mundt, Paul Mackerras,
Mark Salter, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
On ARM, we don't want SPARSE_IRQ to be a user visible option. Make
SPARSE_IRQ visible based on MAY_HAVE_SPARSE_IRQ instead of depending
on HAVE_SPARSE_IRQ.
With this, SPARSE_IRQ is not visible on C6X and ARM.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Mark Salter <msalter@redhat.com>
Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
---
This is part of an irq include consolidation series for ARM:
http://www.spinics.net/lists/arm-kernel/msg156492.html
Rob
arch/arm/Kconfig | 1 -
arch/c6x/Kconfig | 2 +-
arch/powerpc/Kconfig | 2 +-
arch/sh/Kconfig | 2 +-
arch/x86/Kconfig | 1 -
kernel/irq/Kconfig | 5 ++---
6 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 24626b0..30e7840 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -28,7 +28,6 @@ config ARM
select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
select HAVE_C_RECORDMCOUNT
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
select GENERIC_IRQ_SHOW
select CPU_PM if (SUSPEND || CPU_IDLE)
select GENERIC_PCI_IOMAP
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index 26e67f0..2f58c61 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -11,7 +11,7 @@ config TMS320C6X
select HAVE_DMA_API_DEBUG
select HAVE_GENERIC_HARDIRQS
select HAVE_MEMBLOCK
- select HAVE_SPARSE_IRQ
+ select SPARSE_IRQ
select OF
select OF_EARLY_FLATTREE
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1919634..06c1cf0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -133,7 +133,7 @@ config PPC
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
+ select MAY_HAVE_SPARSE_IRQ
select IRQ_PER_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 3c8db65..21b82a8 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -22,7 +22,7 @@ config SUPERH
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
+ select MAY_HAVE_SPARSE_IRQ
select IRQ_FORCED_THREADING
select RTC_LIB
select GENERIC_ATOMIC64
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 864cc6e..fb2da44 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -69,7 +69,6 @@ config X86
select HAVE_ARCH_JUMP_LABEL
select HAVE_TEXT_POKE_SMP
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
select SPARSE_IRQ
select GENERIC_FIND_FIRST_BIT
select GENERIC_IRQ_PROBE
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 5a38bf4..1f2dece 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -13,7 +13,7 @@ config GENERIC_HARDIRQS
# Options selectable by the architecture code
# Make sparse irq Kconfig switch below available
-config HAVE_SPARSE_IRQ
+config MAY_HAVE_SPARSE_IRQ
bool
# Enable the generic irq autoprobe mechanism
@@ -61,8 +61,7 @@ config IRQ_FORCED_THREADING
bool
config SPARSE_IRQ
- bool "Support sparse irq numbering"
- depends on HAVE_SPARSE_IRQ
+ bool "Support sparse irq numbering" if MAY_HAVE_SPARSE_IRQ
---help---
Sparse irq numbering is useful for distro kernels that want
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem page
From: Dan Williams @ 2012-01-26 9:12 UTC (permalink / raw)
To: Shi Xuelin-B29237
Cc: vinod.koul@intel.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Li Yang-R58472
In-Reply-To: <DBB740589CE8814680DECFE34BE197AB166593@039-SN1MPN1-006.039d.mgd.msft.net>
2012/1/10 Shi Xuelin-B29237 <B29237@freescale.com>:
> Hello Dan Williams,
>
> Do you have any comment about this patch?
Hi, sorrry for the delay.
>
> Thanks,
> Forrest
>
> -----Original Message-----
> From: Shi Xuelin-B29237
> Sent: 2011=E5=B9=B412=E6=9C=8827=E6=97=A5 14:31
> To: vinod.koul@intel.com; dan.j.williams@intel.com; linuxppc-dev@lists.oz=
labs.org; linux-kernel@vger.kernel.org; Li Yang-R58472
> Cc: Shi Xuelin-B29237
> Subject: [PATCH] dmaengine: async_xor, fix zero address issue when xor hi=
ghmem page
>
> From: Forrest shi <b29237@freescale.com>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0we may do_sync_xor high mem pages, in this cas=
e, page_address will
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return zero address which cause a failure.
In what scenarios do we xor highmem?
In the case of raid we currently always xor on kmalloc'd memory.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0this patch uses kmap_atomic before xor the pag=
es and kunmap_atomic
> =C2=A0 =C2=A0 =C2=A0 =C2=A0after it.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Signed-off-by: b29237@freescale.com <xuelin.sh=
i@freescale.com>
> ---
> =C2=A0crypto/async_tx/async_xor.c | =C2=A0 16 ++++++++++++----
> =C2=A01 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c in=
dex bc28337..5b416d1 100644
> --- a/crypto/async_tx/async_xor.c
> +++ b/crypto/async_tx/async_xor.c
> @@ -26,6 +26,7 @@
> =C2=A0#include <linux/kernel.h>
> =C2=A0#include <linux/interrupt.h>
> =C2=A0#include <linux/mm.h>
> +#include <linux/highmem.h>
> =C2=A0#include <linux/dma-mapping.h>
> =C2=A0#include <linux/raid/xor.h>
> =C2=A0#include <linux/async_tx.h>
> @@ -126,7 +127,7 @@ do_sync_xor(struct page *dest, struct page **src_list=
, unsigned int offset,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int src_cnt, size_t len, struct =
async_submit_ctl *submit) =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int i;
> - =C2=A0 =C2=A0 =C2=A0 int xor_src_cnt =3D 0;
> + =C2=A0 =C2=A0 =C2=A0 int xor_src_cnt =3D 0, kmap_cnt=3D0;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int src_off =3D 0;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0void *dest_buf;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0void **srcs;
> @@ -138,11 +139,13 @@ do_sync_xor(struct page *dest, struct page **src_li=
st, unsigned int offset,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* convert to buffer pointers */
> =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < src_cnt; i++)
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (src_list[i])
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 srcs[xor_src_cnt++] =3D page_address(src_list[i]) + offset;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (src_list[i]) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 srcs[xor_src_cnt++] =3D kmap_atomic(src_list[i], KM_USER1) + offset;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 kmap_cnt =3D xor_src_cnt;
I guess this works now that we have stack based kmap_atomic, but on
older kernels you could not simultaneously map that many buffers with
a single kmap slot. So if you resend, drop the second parameter to
kmap_atomic.
...but unless you have a non md/raid456 use case in mind, or have
patches to convert md/raid to xor straight out of the incoming biovecs
I don't think this patch is needed right?
^ permalink raw reply
* Re: [RFCv2 00/14]
From: Grant Likely @ 2012-01-26 13:38 UTC (permalink / raw)
To: Mark Salter
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
linuxppc-dev
In-Reply-To: <1327532011.24169.6.camel@deneb.redhat.com>
On Wed, Jan 25, 2012 at 3:53 PM, Mark Salter <msalter@redhat.com> wrote:
> On Mon, 2012-01-23 at 14:07 -0700, Grant Likely wrote:
>> Hey everyone,
>>
>> Here's the second RFC for the irq_domain patches. =A0I could use some
>> help testing now. =A0I still expect there will be a few bugs. =A0The
>> series is based on v3.3-rc1, and I've pushed it out to my git server:
>
> Hi Grant,
>
> I converted arch/c6x over to the generic irq_domain support and have not
> had any problems in testing. The c6x virtual irq support was a nearly
> identical copy of the powerpc code, so the patch I ended up with mostly
> copied what you did in arch/powerpc. The c6x patch is on the tip of:
>
> =A0git@linux-c6x.org:/git/projects/linux-c6x-upstreaming irq-testing
>
> I think this probably belongs in your series, but I can push it
> separately if not.
Yes, it should be in my series. Please post the patches and cc me so
there is record of them in the mailing list archives and I'll pick
them up.
g.
^ permalink raw reply
* Re: tlb flushing on Power
From: Brian King @ 2012-01-26 14:41 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Dave Hansen
In-Reply-To: <4F2160B3.60708@linux.vnet.ibm.com>
CC'ing linuxppc-dev...
On 01/26/2012 08:18 AM, Seth Jennings wrote:
> Hey Dave,
>
> So I submitted the zsmalloc patches to lkml at the beginning
> of the year
>
> https://lkml.org/lkml/2012/1/9/389
>
> I found there are two functions Nitin used in the mapping
> functions that are not supported in the powerpc arch:
> set_pte() and __flush_tlb_one().
>
> set_pte() seems straightforward for the ppc64 case, although
> I think Power does some sort of pte hashing that might convolute
> it a little.
>
> My real question is how to achieve the function of __flush_tlb_one()
> on Power. I looked in Docuemntation/cachetlb.txt and it seems like
> the portable tlb flush functions are:
>
> void flush_tlb_all(void)
> void flush_tlb_mm(struct mm_struct *mm)
> void flush_tlb_range(struct vm_area_struct *vma,
> unsigned long start, unsigned long end)
> void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)
>
> Of those options, flush_tlb_page() seems the closest to what
> __flush_tlb_one() does. However, we don't have a vma argument in
> our context (akaik) to send to it.
>
> I was wondering if you have any ideas. Any help is greatly appreciated!
>
> --
> Seth
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Rob Herring @ 2012-01-26 14:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <CACxGe6tgGqQSThzVVEzwOdtYkjKHT1uQhZBOkCTwkutyKXDCAg@mail.gmail.com>
On 01/25/2012 11:59 AM, Grant Likely wrote:
> On Tue, Jan 24, 2012 at 10:35 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wrote:
>>>
>>>
>>> On 01/24/2012 06:18 PM, Grant Likely wrote:
>>>> Rather than having each interrupt controller driver creating its own barely
>>>> unique .xlate function for irq_domain, create a library of translators which
>>>> any driver can use directly.
>>>>
>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>> index e7379a3..5e497a0 100644
>>>> --- a/include/linux/irqdomain.h
>>>> +++ b/include/linux/irqdomain.h
>>>> @@ -110,6 +110,9 @@ struct irq_domain {
>>>> void *host_data;
>>>> irq_hw_number_t inval_irq;
>>>>
>>>> + /* Data for common irq xlate functions */
>>>> + unsigned int xlate_type;
>>>> +
>>>
>>> How does this get set? Do we want interrupt controllers messing with the
>>> domain struct directly long term?
>>
>> It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
>> override it. Alternately it could be made part of the
>> irq_domain_add() arguments, but I'm not thrilled with adding a whole
>> bunch of arguments to the function prototype.
>
> Do you like this better (built on top of this patch)?
Yes, I think it's better.
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index ef2b1fe..7856c04 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -701,12 +701,10 @@ int irq_domain_xlate_onecell(struct irq_domain
> *d, struct device_node *ctrlr,
> const u32 *intspec, unsigned int intsize,
> unsigned long *out_hwirq, unsigned int *out_type)
> {
> - if (WARN(intsize < 1, "Bad intspec for %s: intsize=%i < 1\n",
> - ctrlr->full_name, intsize))
> + if (WARN_ON(intsize < 1))
> return -EINVAL;
> - *out_hwirq = intspec[0];
> - *out_type = d->xlate_type;
> - return 0;
> + return irq_domain_xlate_onetwocell(d, ctrlr, intspec, 1,
> + out_hwirq, out_type);
> }
> EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
>
> @@ -721,12 +719,10 @@ int irq_domain_xlate_twocell(struct irq_domain
> *d, struct device_node *ctrlr,
> const u32 *intspec, unsigned int intsize,
> irq_hw_number_t *out_hwirq, unsigned int *out_type)
> {
> - if (WARN(intsize < 2, "Bad intspec for %s: intsize=%i < 2\n",
> - ctrlr->full_name, intsize))
> + if (WARN_ON(intsize < 2))
> return -EINVAL;
> - *out_hwirq = intspec[0];
> - *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> - return 0;
> + return irq_domain_xlate_onetwocell(d, ctrlr, intspec, intsize,
> + out_hwirq, out_type);
> }
> EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
>
> @@ -746,8 +742,7 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
> const u32 *intspec, unsigned int intsize,
> unsigned long *out_hwirq, unsigned int *out_type)
> {
> - if (WARN(intsize < 1, "Bad intspec for %s: intsize=%i < 1\n",
> - ctrlr->full_name, intsize))
> + if (WARN_ON(intsize < 1))
> return -EINVAL;
> *out_hwirq = intspec[0];
> *out_type = d->xlate_type;
^ permalink raw reply
* Re: FSL SPI driver question
From: Norbert van Bolhuis @ 2012-01-26 15:07 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF248EC14B.3E5BA3A6-ON88257990.006C779B-88257990.006CE971@selinc.com>
Hi Bruce,
On 01/25/12 20:49, Bruce_Leonard@selinc.com wrote:
.
.
.
> Thanks for the reply. Yes I did find spidev_fdx.c and in fact copied it
> for my tests. I still see SPICLK active only during the time the 8308 is
> sending data (read cmd + address). Nothing happens with the clock after
> that when the NvRAM is ready to send data.
>
> Bruce
>
ok, then I don't know.
I doubt this is a spidev or FSP SPI driver problem though.
Questions like:
Could it be a HW problem ?
Is the correct SPI mode used ?
Does it work in u-boot ?
Come to mind in a situation like this.
Norbert.
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Grant Likely @ 2012-01-26 18:15 UTC (permalink / raw)
To: Rob Herring; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <4F216819.7030106@gmail.com>
On Thu, Jan 26, 2012 at 7:50 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 01/25/2012 11:59 AM, Grant Likely wrote:
>> On Tue, Jan 24, 2012 at 10:35 PM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>> On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wr=
ote:
>>>>
>>>>
>>>> On 01/24/2012 06:18 PM, Grant Likely wrote:
>>>>> Rather than having each interrupt controller driver creating its own =
barely
>>>>> unique .xlate function for irq_domain, create a library of translator=
s which
>>>>> any driver can use directly.
>>>>>
>>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>>> index e7379a3..5e497a0 100644
>>>>> --- a/include/linux/irqdomain.h
>>>>> +++ b/include/linux/irqdomain.h
>>>>> @@ -110,6 +110,9 @@ struct irq_domain {
>>>>> =A0 =A0 =A0 void *host_data;
>>>>> =A0 =A0 =A0 irq_hw_number_t inval_irq;
>>>>>
>>>>> + =A0 =A0 /* Data for common irq xlate functions */
>>>>> + =A0 =A0 unsigned int xlate_type;
>>>>> +
>>>>
>>>> How does this get set? Do we want interrupt controllers messing with t=
he
>>>> domain struct directly long term?
>>>
>>> It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
>>> override it. =A0Alternately it could be made part of the
>>> irq_domain_add() arguments, but I'm not thrilled with adding a whole
>>> bunch of arguments to the function prototype.
>>
>> Do you like this better (built on top of this patch)?
>
> Yes, I think it's better.
I've changed my mind on this after looking at the generated code.
These functions are so simple that it actually is larger (both in
source and object size) to call out to a common function. I've gone
back to each _xlate_*() function open coding the two assignments.
g.
>
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index ef2b1fe..7856c04 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -701,12 +701,10 @@ int irq_domain_xlate_onecell(struct irq_domain
>> *d, struct device_node *ctrlr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const u32 *intspe=
c, unsigned int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *ou=
t_hwirq, unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 1))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 *out_hwirq =3D intspec[0];
>> - =A0 =A0 *out_type =3D d->xlate_type;
>> - =A0 =A0 return 0;
>> + =A0 =A0 return irq_domain_xlate_onetwocell(d, ctrlr, intspec, 1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0out_hwirq, out_type);
>> =A0}
>> =A0EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
>>
>> @@ -721,12 +719,10 @@ int irq_domain_xlate_twocell(struct irq_domain
>> *d, struct device_node *ctrlr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned=
int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, =
unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 2, "Bad intspec for %s: intsize=3D%i < 2\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 2))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 *out_hwirq =3D intspec[0];
>> - =A0 =A0 *out_type =3D intspec[1] & IRQ_TYPE_SENSE_MASK;
>> - =A0 =A0 return 0;
>> + =A0 =A0 return irq_domain_xlate_onetwocell(d, ctrlr, intspec, intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0out_hwirq, out_type);
>> =A0}
>> =A0EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
>>
>> @@ -746,8 +742,7 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d=
,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *i=
ntspec, unsigned int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned lon=
g *out_hwirq, unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 1))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> =A0 =A0 =A0 *out_hwirq =3D intspec[0];
>> =A0 =A0 =A0 *out_type =3D d->xlate_type;
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: FSL SPI driver question
From: Bruce_Leonard @ 2012-01-26 19:49 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev
In-Reply-To: <4F216C25.6000303@aimvalley.nl>
Norbert,
>
> ok, then I don't know.
>
> I doubt this is a spidev or FSP SPI driver problem though.
>
> Questions like:
>
> Could it be a HW problem ?
> Is the correct SPI mode used ?
> Does it work in u-boot ?
>
> Come to mind in a situation like this.
>
Thanks for the suggestions. I finally found it in the wee hours this
morning, and it was operator error. The CY14 by default powers up in the
write protect state and from the factory is erased to all zeros. So my
writes and subsequent reads appeared to fail by the "fact" that I could
never read what I wrote. Guess I need better reading glasses in my old
age :-/
Anyway, I'm happily up and talking using the Freescale SPI driver and
spidev. Thanks for the help and sorry for the noise on the list.
Bruce
^ permalink raw reply
* [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-01-26 20:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dan Williams
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Dan Williams <dan.j.williams@intel.com>
---
drivers/dma/fsldma.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..7dc9689 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1052,6 +1052,16 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
stat &= ~FSL_DMA_SR_EOLNI;
}
+ /*
+ * This driver does not use this feature, therefore we shouldn't
+ * ever see this bit set in the status register. However, it has
+ * been observed on MPC8349EA parts.
+ */
+ if (stat & FSL_DMA_SR_EOSI) {
+ chan_dbg(chan, "irq: End-of-Segments INT\n");
+ stat &= ~FSL_DMA_SR_EOSI;
+ }
+
/* check that the DMA controller is really idle */
if (!dma_is_idle(chan))
chan_err(chan, "irq: controller not idle!\n");
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/1] carma-fpga: fix lockdep warning
From: Ira W. Snyder @ 2012-01-26 20:59 UTC (permalink / raw)
To: linuxppc-dev
Lockdep occasionally complains with the message:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
This is caused by calling videobuf_dma_unmap() under spin_lock_irq(). To
fix the warning, we drop the lock before unmapping and freeing the
buffer.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/misc/carma/carma-fpga.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 14e974b2..4fd896d 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -1079,6 +1079,7 @@ static ssize_t data_read(struct file *filp, char __user *ubuf, size_t count,
struct fpga_reader *reader = filp->private_data;
struct fpga_device *priv = reader->priv;
struct list_head *used = &priv->used;
+ bool drop_buffer = false;
struct data_buf *dbuf;
size_t avail;
void *data;
@@ -1166,10 +1167,12 @@ have_buffer:
* One of two things has happened, the device is disabled, or the
* device has been reconfigured underneath us. In either case, we
* should just throw away the buffer.
+ *
+ * Lockdep complains if this is done under the spinlock, so we
+ * handle it during the unlock path.
*/
if (!priv->enabled || dbuf->size != priv->bufsize) {
- videobuf_dma_unmap(priv->dev, &dbuf->vb);
- data_free_buffer(dbuf);
+ drop_buffer = true;
goto out_unlock;
}
@@ -1178,6 +1181,12 @@ have_buffer:
out_unlock:
spin_unlock_irq(&priv->lock);
+
+ if (drop_buffer) {
+ videobuf_dma_unmap(priv->dev, &dbuf->vb);
+ data_free_buffer(dbuf);
+ }
+
return count;
}
--
1.7.3.4
^ permalink raw reply related
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