* Re: [PATCH V3] fsl-sata: add support for interrupt coalsecing feature
From: Li Yang @ 2012-02-15 7:51 UTC (permalink / raw)
To: Qiang Liu; +Cc: linux-ide, linuxppc-dev, jgarzik, linux-kernel
In-Reply-To: <1329291634-883-1-git-send-email-qiang.liu@freescale.com>
On Wed, Feb 15, 2012 at 3:40 PM, Qiang Liu <qiang.liu@freescale.com> wrote:
> Adds support for interrupt coalescing feature to reduce interrupt events.
> Provides a mechanism of adjusting coalescing count and timeout tick by sysfs
> at runtime, so that tradeoff of latency and CPU load can be made depending
> on different applications.
>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
Acked-by: Li Yang <leoli@freescale.com>
- Leo
^ permalink raw reply
* RE: [RFC] usb: Fix build error due to dma_mask is not at pdev_archdata at ARM
From: Mehresh Ramneek-B31383 @ 2012-02-15 8:47 UTC (permalink / raw)
To: Chen Peter-B29397, stern@rowland.harvard.edu, agust@denx.de
Cc: Estevam Fabio-R49496, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, kernel@pengutronix.de
In-Reply-To: <1329210695-14492-1-git-send-email-peter.chen@freescale.com>
-----Original Message-----
From: Chen Peter-B29397=20
Sent: Tuesday, February 14, 2012 2:42 PM
To: stern@rowland.harvard.edu; agust@denx.de
Cc: kernel@pengutronix.de; linuxppc-dev@lists.ozlabs.org; Mehresh Ramneek-B=
31383; Estevam Fabio-R49496; linux-usb@vger.kernel.org
Subject: [RFC] usb: Fix build error due to dma_mask is not at pdev_archdata=
at ARM
When build i.mx platform with imx_v6_v7_defconfig, and after adding USB Gad=
get support, it has below build error:
CC drivers/usb/host/fsl-mph-dr-of.o
drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
has no member named 'dma_mask'
It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
For PowerPC, there is dma_mask at struct pdev_archdata, but there is no dma=
_mask at struct pdev_archdata for ARM. The pdev_archdata is related to spec=
ific platform, it should NOT be accessed by cross platform drivers, like US=
B.
The code for pdev_archdata should be useless, as for PowerPC, it has alread=
y gotten the value for pdev->dev.dma_mask at function arch_setup_pdev_archd=
ata of arch/powerpc/kernel/setup-common.c.
Anyone who has PowerPC hardware with USB host enabled, and uses this code c=
an help me a test? Thank you
[Ramneek]: Hi Peter, the code is working for Host stack on PowerPC.
=20
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/host/fsl-mph-dr-of.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr=
-of.c
index 7916e56..ab333ac 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -94,7 +94,6 @@ struct platform_device * __devinit fsl_usb2_device_regist=
er(
pdev->dev.parent =3D &ofdev->dev;
=20
pdev->dev.coherent_dma_mask =3D ofdev->dev.coherent_dma_mask;
- pdev->dev.dma_mask =3D &pdev->archdata.dma_mask;
*pdev->dev.dma_mask =3D *ofdev->dev.dma_mask;
=20
retval =3D platform_device_add_data(pdev, pdata, sizeof(*pdata));
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 6/12] arch/powerpc: remove references to cpu_*_map.
From: Srivatsa S. Bhat @ 2012-02-15 9:21 UTC (permalink / raw)
To: Rusty Russell
Cc: Venkatesh Pallipadi, linux-kernel, Paul Mackerras,
akpm@linux-foundation.org, linuxppc-dev
In-Reply-To: <1329281884.20466.rusty@rustcorp.com.au>
On 02/15/2012 10:28 AM, Rusty Russell wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
>
> This has been obsolescent for a while; time for the final push.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: [PATCH v3 24/25] irq_domain: remove "hint" when allocating irq numbers
From: Nicolas Ferre @ 2012-02-15 15:04 UTC (permalink / raw)
To: Grant Likely, devicetree-discuss, Rob Herring
Cc: Stephen Rothwell, linux-kernel, Milton Miller, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F316848.4060100@atmel.com>
On 02/07/2012 07:07 PM, Nicolas Ferre :
> On 01/27/2012 10:36 PM, Grant Likely :
>> The 'hint' used to try and line up irq numbers with hw irq numbers is
>> rather a hack and not very useful. Now that /proc/interrupts also outputs
>> the hwirq number, it is even less useful to keep around the 'hint' heuristic.
>>
>> This patch removes it.
>
> Grant,
>
> While trying your patch series in conjunction with Rob one, I do not
> find this patch in your irqdomain/next branch (and a couple of others).
> Can you tell me if this v3 series is available as a git tree?
I am still interested by patch 24-25 of this series but still cannot
find them in your irqdomain/next branch:
Are they also expected to join the 3.4 merge window material?
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v3 25/25] irq_domain: mostly eliminate slow-path revmap lookups
From: Nicolas Ferre @ 2012-02-15 16:36 UTC (permalink / raw)
To: Grant Likely, devicetree-discuss
Cc: Stephen Rothwell, linux-kernel, Rob Herring, Milton Miller,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1327700179-17454-26-git-send-email-grant.likely@secretlab.ca>
Grant,
I do not know if it is the latest revision but I have identified some
issues on error/slow paths...
On 01/27/2012 10:36 PM, Grant Likely :
> With the current state of irq_domain, the reverse map is always used when
> new IRQs get mapped. This means that the irq_find_mapping() function
> can be simplified to always call out to the revmap-specific lookup function.
>
> This patch adds lookup functions for the revmaps that don't yet have one
> and removes the slow path lookup from most of the code paths. The only
> place where the slow path legitimately remains is when the linear map
> is used with a hwirq number larger than the revmap size.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Milton Miller <miltonm@bga.com>
> ---
> arch/powerpc/sysdev/xics/xics-common.c | 3 -
> include/linux/irqdomain.h | 3 +-
> kernel/irq/irqdomain.c | 94 +++++++++++++++++---------------
> 3 files changed, 51 insertions(+), 49 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
> index ea5e204..1d7067d 100644
> --- a/arch/powerpc/sysdev/xics/xics-common.c
> +++ b/arch/powerpc/sysdev/xics/xics-common.c
> @@ -330,9 +330,6 @@ static int xics_host_map(struct irq_domain *h, unsigned int virq,
>
> pr_devel("xics: map virq %d, hwirq 0x%lx\n", virq, hw);
>
> - /* Insert the interrupt mapping into the radix tree for fast lookup */
> - irq_radix_revmap_insert(xics_host, virq, hw);
> -
> /* They aren't all level sensitive but we just don't really know */
> irq_set_status_flags(virq, IRQ_LEVEL);
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 0b00f83..38314f2 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -93,6 +93,7 @@ struct irq_domain {
> struct list_head link;
>
> /* type of reverse mapping_technique */
> + unsigned int (*revmap)(struct irq_domain *host, irq_hw_number_t hwirq);
> unsigned int revmap_type;
> union {
> struct {
> @@ -155,8 +156,6 @@ extern void irq_dispose_mapping(unsigned int virq);
> extern unsigned int irq_find_mapping(struct irq_domain *host,
> irq_hw_number_t hwirq);
> extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
> -extern void irq_radix_revmap_insert(struct irq_domain *host, unsigned int virq,
> - irq_hw_number_t hwirq);
> extern unsigned int irq_radix_revmap_lookup(struct irq_domain *host,
> irq_hw_number_t hwirq);
> extern unsigned int irq_linear_revmap(struct irq_domain *host,
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 5b4fc4d..91c1cb7 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -104,6 +104,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
> domain->revmap_data.legacy.first_irq = first_irq;
> domain->revmap_data.legacy.first_hwirq = first_hwirq;
> domain->revmap_data.legacy.size = size;
> + domain->revmap = irq_domain_legacy_revmap;
>
> mutex_lock(&irq_domain_mutex);
> /* Verify that all the irqs are available */
> @@ -174,18 +175,35 @@ struct irq_domain *irq_domain_add_linear(struct device_node *of_node,
> }
> domain->revmap_data.linear.size = size;
> domain->revmap_data.linear.revmap = revmap;
> + domain->revmap = irq_linear_revmap;
> irq_domain_add(domain);
> return domain;
> }
>
> +static unsigned int irq_domain_nomap_revmap(struct irq_domain *domain,
> + irq_hw_number_t hwirq)
> +{
> + struct irq_data *data = irq_get_irq_data(hwirq);
> +
> + if (WARN_ON_ONCE(domain->revmap_type != IRQ_DOMAIN_MAP_NOMAP))
> + return irq_find_mapping(domain, hwirq);
Should be:
return irq_find_mapping_slow(domain, hwirq);
Recursion otherwise...
> +
> + /* Verify that the map has actually been established */
> + if (data && (data->domain == domain) && (data->hwirq == hwirq))
> + return hwirq;
> + return 0;
> +}
> +
> struct irq_domain *irq_domain_add_nomap(struct device_node *of_node,
> const struct irq_domain_ops *ops,
> void *host_data)
> {
> struct irq_domain *domain = irq_domain_alloc(of_node,
> IRQ_DOMAIN_MAP_NOMAP, ops, host_data);
> - if (domain)
> + if (domain) {
> + domain->revmap = irq_domain_nomap_revmap;
> irq_domain_add(domain);
> + }
> return domain;
> }
>
> @@ -205,6 +223,7 @@ struct irq_domain *irq_domain_add_tree(struct device_node *of_node,
> IRQ_DOMAIN_MAP_TREE, ops, host_data);
> if (domain) {
> INIT_RADIX_TREE(&domain->revmap_data.tree, GFP_KERNEL);
> + domain->revmap = irq_radix_revmap_lookup;
> irq_domain_add(domain);
> }
> return domain;
> @@ -378,6 +397,19 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
> return 0;
> }
>
> + switch(domain->revmap_type) {
> + case IRQ_DOMAIN_MAP_LINEAR:
> + if (hwirq < domain->revmap_data.linear.size)
> + domain->revmap_data.linear.revmap[hwirq] = irq;
> + break;
> + case IRQ_DOMAIN_MAP_TREE:
> + mutex_lock(&revmap_trees_mutex);
> + radix_tree_insert(&domain->revmap_data.tree, hwirq,
> + irq_get_irq_data(irq));
> + mutex_unlock(&revmap_trees_mutex);
> +
> + break;
> + }
> pr_debug("irq: irq %lu on domain %s mapped to virtual irq %u\n",
> hwirq, domain->of_node ? domain->of_node->full_name : "null", virq);
>
> @@ -478,25 +510,27 @@ EXPORT_SYMBOL_GPL(irq_dispose_mapping);
> * irq_find_mapping() - Find a linux irq from an hw irq number.
> * @domain: domain owning this hardware interrupt
> * @hwirq: hardware irq number in that domain space
> - *
> - * This is a slow path, for use by generic code. It's expected that an
> - * irq controller implementation directly calls the appropriate low level
> - * mapping function.
> */
> unsigned int irq_find_mapping(struct irq_domain *domain,
> irq_hw_number_t hwirq)
> {
> - unsigned int i;
> -
> - /* Look for default domain if nececssary */
> - if (domain == NULL)
> + if (!domain)
> domain = irq_default_domain;
> - if (domain == NULL)
> - return 0;
> + return domain ? domain->revmap(domain, hwirq) : 0;
> +}
> +EXPORT_SYMBOL_GPL(irq_find_mapping);
>
> - /* legacy -> bail early */
> - if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
> - return irq_domain_legacy_revmap(domain, hwirq);
> +/**
> + * irq_find_mapping_slow() - slow path for finding the irq mapped to a hwirq
> + *
> + * This is the failsafe slow path for finding an irq mapping. The only time
> + * this will reasonably get called is when the linear map is used with a
> + * hwirq number larger than the size of the reverse map.
> + */
> +static unsigned int irq_find_mapping_slow(struct irq_domain *domain,
> + irq_hw_number_t hwirq)
> +{
> + int i;
>
> /* Slow path does a linear search of the map */
> for (i = 0; i < irq_virq_count; i++) {
> @@ -506,7 +540,6 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
> }
> return 0;
> }
> -EXPORT_SYMBOL_GPL(irq_find_mapping);
>
> /**
> * irq_radix_revmap_lookup() - Find a linux irq from a hw irq number.
> @@ -537,31 +570,7 @@ unsigned int irq_radix_revmap_lookup(struct irq_domain *domain,
> * Else fallback to linear lookup - this should not happen in practice
> * as it means that we failed to insert the node in the radix tree.
> */
> - return irq_data ? irq_data->irq : irq_find_mapping(domain, hwirq);
> -}
> -
> -/**
> - * irq_radix_revmap_insert() - Insert a hw irq to linux irq number mapping.
> - * @domain: domain owning this hardware interrupt
> - * @virq: linux irq number
> - * @hwirq: hardware irq number in that domain space
> - *
> - * This is for use by irq controllers that use a radix tree reverse
> - * mapping for fast lookup.
> - */
> -void irq_radix_revmap_insert(struct irq_domain *domain, unsigned int virq,
> - irq_hw_number_t hwirq)
> -{
> - struct irq_data *irq_data = irq_get_irq_data(virq);
> -
> - if (WARN_ON(domain->revmap_type != IRQ_DOMAIN_MAP_TREE))
> - return;
> -
> - if (virq) {
> - mutex_lock(&revmap_trees_mutex);
> - radix_tree_insert(&domain->revmap_data.tree, hwirq, irq_data);
> - mutex_unlock(&revmap_trees_mutex);
> - }
> + return irq_data ? irq_data->irq : irq_find_mapping_slow(domain, hwirq);
> }
>
> /**
> @@ -585,14 +594,11 @@ unsigned int irq_linear_revmap(struct irq_domain *domain,
> if (unlikely(hwirq >= domain->revmap_data.linear.size))
> return irq_find_mapping(domain, hwirq);
Ditto here. And same whith previous one in same function. Check in
irq_radix_revmap_lookup() there is the same issue on the "WARN_ON_ONCE"
path...
>
> - /* Check if revmap was allocated */
> revmap = domain->revmap_data.linear.revmap;
> - if (unlikely(revmap == NULL))
> - return irq_find_mapping(domain, hwirq);
>
> /* Fill up revmap with slow path if no mapping found */
> if (unlikely(!revmap[hwirq]))
> - revmap[hwirq] = irq_find_mapping(domain, hwirq);
> + revmap[hwirq] = irq_find_mapping_slow(domain, hwirq);
>
> return revmap[hwirq];
> }
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Alexander Graf @ 2012-02-15 19:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F0B8B7D.4@freescale.com>
On 10.01.2012, at 01:51, Scott Wood wrote:
> On 01/09/2012 11:46 AM, Alexander Graf wrote:
>>=20
>> On 21.12.2011, at 02:34, Scott Wood wrote:
>=20
[...]
>>> Current issues include:
>>> - Machine checks from guest state are not routed to the host =
handler.
>>> - The guest can cause a host oops by executing an emulated =
instruction
>>> in a page that lacks read permission. Existing e500/4xx support =
has
>>> the same problem.
>>=20
>> We solve that in book3s pr by doing
>>=20
>> LAST_INST =3D <known bad value>;
>> PACA->kvm_mode =3D <recover at next inst>;
>> lwz(guest pc);
>> do_more_stuff();
>>=20
>> That way when an exception occurs at lwz() the DO_KVM handler checks =
that we're in kvm mode "recover" which does basically srr0+=3D4; rfi;.
>=20
> I was thinking we'd check ESR[EPID] or SRR1[IS] as appropriate, and
> treat it as a kernel fault (search exception table) -- but this works
> too and is a bit cleaner (could be other uses of external pid), at the
> expense of a couple extra instructions in the emulation path (but
> probably a slightly faster host TLB handler).
>=20
> The check wouldn't go in DO_KVM, though, since on bookehv that only
> deals with diverting flow when xSRR1[GS] is set, which wouldn't be the
> case here.
Thinking about it a bit more, how is this different from a failed =
get_user()? We can just use the same fixup mechanism as there, right?
Alex
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Scott Wood @ 2012-02-15 19:40 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <ADC42EDC-6F11-419E-9F31-B9E23D80FFE1@suse.de>
On 02/15/2012 01:36 PM, Alexander Graf wrote:
>
> On 10.01.2012, at 01:51, Scott Wood wrote:
>> I was thinking we'd check ESR[EPID] or SRR1[IS] as appropriate, and
>> treat it as a kernel fault (search exception table) -- but this works
>> too and is a bit cleaner (could be other uses of external pid), at the
>> expense of a couple extra instructions in the emulation path (but
>> probably a slightly faster host TLB handler).
>>
>> The check wouldn't go in DO_KVM, though, since on bookehv that only
>> deals with diverting flow when xSRR1[GS] is set, which wouldn't be the
>> case here.
>
> Thinking about it a bit more, how is this different from a failed get_user()? We can just use the same fixup mechanism as there, right?
The fixup mechanism can be the same (we'd like to know whether it failed
due to TLB miss or DSI, so we know which to reflect -- but if necessary
I think we can figure that out with a tlbsx). What's different is that
the page fault handler needs to know that any external pid (or AS1)
fault is bad, same as if the address were in the kernel area, and it
should go directly to searching the exception tables instead of trying
to page something in.
-Scott
^ permalink raw reply
* Re: [PATCH v3 24/25] irq_domain: remove "hint" when allocating irq numbers
From: Grant Likely @ 2012-02-15 20:21 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Rob Herring,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F3BC97C.6030203@atmel.com>
On Wed, Feb 15, 2012 at 04:04:28PM +0100, Nicolas Ferre wrote:
> On 02/07/2012 07:07 PM, Nicolas Ferre :
> > On 01/27/2012 10:36 PM, Grant Likely :
> >> The 'hint' used to try and line up irq numbers with hw irq numbers is
> >> rather a hack and not very useful. Now that /proc/interrupts also outputs
> >> the hwirq number, it is even less useful to keep around the 'hint' heuristic.
> >>
> >> This patch removes it.
> >
> > Grant,
> >
> > While trying your patch series in conjunction with Rob one, I do not
> > find this patch in your irqdomain/next branch (and a couple of others).
> > Can you tell me if this v3 series is available as a git tree?
>
> I am still interested by patch 24-25 of this series but still cannot
> find them in your irqdomain/next branch:
> Are they also expected to join the 3.4 merge window material?
I've held off on putting them in irqdomain/next because they are a bit more
risky than the other patches, and I want an explicit ack from Ben for patches
24 & 25. However, that shouldn't really cause any issues since the changes
in 24 & 25 don't impact the irq_domain functionality or API. They are just
optimizations.
Also on 25, I'm not yet convinced that breaking out the revmap functions
into ops is the right thing to do. It actually makes the .text size quite
a bit larger. I may very well rewrite it.
g.
^ permalink raw reply
* Re: [PATCH v3 25/25] irq_domain: mostly eliminate slow-path revmap lookups
From: Grant Likely @ 2012-02-15 20:29 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Stephen Rothwell, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F3BDF1E.4040506@atmel.com>
On Wed, Feb 15, 2012 at 05:36:46PM +0100, Nicolas Ferre wrote:
> Grant,
>
> I do not know if it is the latest revision but I have identified some
> issues on error/slow paths...
>
>
> On 01/27/2012 10:36 PM, Grant Likely :
> > With the current state of irq_domain, the reverse map is always used when
> > new IRQs get mapped. This means that the irq_find_mapping() function
> > can be simplified to always call out to the revmap-specific lookup function.
> >
> > This patch adds lookup functions for the revmaps that don't yet have one
> > and removes the slow path lookup from most of the code paths. The only
> > place where the slow path legitimately remains is when the linear map
> > is used with a hwirq number larger than the revmap size.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Milton Miller <miltonm@bga.com>
> > ---
> > arch/powerpc/sysdev/xics/xics-common.c | 3 -
> > include/linux/irqdomain.h | 3 +-
> > kernel/irq/irqdomain.c | 94 +++++++++++++++++---------------
> > 3 files changed, 51 insertions(+), 49 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
> > index ea5e204..1d7067d 100644
> > --- a/arch/powerpc/sysdev/xics/xics-common.c
> > +++ b/arch/powerpc/sysdev/xics/xics-common.c
> > @@ -330,9 +330,6 @@ static int xics_host_map(struct irq_domain *h, unsigned int virq,
> >
> > pr_devel("xics: map virq %d, hwirq 0x%lx\n", virq, hw);
> >
> > - /* Insert the interrupt mapping into the radix tree for fast lookup */
> > - irq_radix_revmap_insert(xics_host, virq, hw);
> > -
> > /* They aren't all level sensitive but we just don't really know */
> > irq_set_status_flags(virq, IRQ_LEVEL);
> >
> > diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> > index 0b00f83..38314f2 100644
> > --- a/include/linux/irqdomain.h
> > +++ b/include/linux/irqdomain.h
> > @@ -93,6 +93,7 @@ struct irq_domain {
> > struct list_head link;
> >
> > /* type of reverse mapping_technique */
> > + unsigned int (*revmap)(struct irq_domain *host, irq_hw_number_t hwirq);
> > unsigned int revmap_type;
> > union {
> > struct {
> > @@ -155,8 +156,6 @@ extern void irq_dispose_mapping(unsigned int virq);
> > extern unsigned int irq_find_mapping(struct irq_domain *host,
> > irq_hw_number_t hwirq);
> > extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
> > -extern void irq_radix_revmap_insert(struct irq_domain *host, unsigned int virq,
> > - irq_hw_number_t hwirq);
> > extern unsigned int irq_radix_revmap_lookup(struct irq_domain *host,
> > irq_hw_number_t hwirq);
> > extern unsigned int irq_linear_revmap(struct irq_domain *host,
> > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > index 5b4fc4d..91c1cb7 100644
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -104,6 +104,7 @@ struct irq_domain *irq_domain_add_legacy(struct device_node *of_node,
> > domain->revmap_data.legacy.first_irq = first_irq;
> > domain->revmap_data.legacy.first_hwirq = first_hwirq;
> > domain->revmap_data.legacy.size = size;
> > + domain->revmap = irq_domain_legacy_revmap;
> >
> > mutex_lock(&irq_domain_mutex);
> > /* Verify that all the irqs are available */
> > @@ -174,18 +175,35 @@ struct irq_domain *irq_domain_add_linear(struct device_node *of_node,
> > }
> > domain->revmap_data.linear.size = size;
> > domain->revmap_data.linear.revmap = revmap;
> > + domain->revmap = irq_linear_revmap;
> > irq_domain_add(domain);
> > return domain;
> > }
> >
> > +static unsigned int irq_domain_nomap_revmap(struct irq_domain *domain,
> > + irq_hw_number_t hwirq)
> > +{
> > + struct irq_data *data = irq_get_irq_data(hwirq);
> > +
> > + if (WARN_ON_ONCE(domain->revmap_type != IRQ_DOMAIN_MAP_NOMAP))
> > + return irq_find_mapping(domain, hwirq);
>
> Should be:
> return irq_find_mapping_slow(domain, hwirq);
>
> Recursion otherwise...
Good catch; but it's not the whole story. Part of the problem when looking
at the other revmap functions is that the revmaps can be called by external
code and there is the possibility that the wrong revmap got called. In that
case, calling the normal path is the right thing to do. However, it is also
possible (but unlikely) to have a ->revmap() and ->revmap_type mismatch where
calling the normal path would indeed cause a recursion.
So, the whole ->revmap thing is a weak design and needs to be rethought.
However, for the time being, I'll change all the revmaps to use the slow
path because it is safer.
g.
^ permalink raw reply
* Re: [PATCH v3 00/25] irq_domain generalization and refinement
From: Grant Likely @ 2012-02-15 20:33 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Rothwell, Russell King - ARM Linux, Tony Lindgren,
devicetree-discuss, linux-kernel, Rob Herring, Milton Miller,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120207152627.GA17825@sirena.org.uk>
On Tue, Feb 07, 2012 at 03:26:27PM +0000, Mark Brown wrote:
> On Sun, Feb 05, 2012 at 04:13:48PM +0000, Russell King - ARM Linux wrote:
>
> > It's not quite correct, because OMAP4 has issues in this area as well
> > (which does select IRQ_DOMAIN but can be without OF.) The result is
> > an oops from irq_domain_add() because domain->ops is NULL.
>
> > The right solution is three fold:
>
> > 1. Wrap the bits of code in CONFIG_IRQ_DOMAIN
> > 2. Get rid of the #ifdef CONFIG_OF there, so the 'ops' member can be
> > initialized.
> > 3. Fix the OMAP vp code not to oops when voltdm->pmic is NULL
>
> > which I have in my combined patch for fixing OMAP so far.
>
> It'd also help if we supported null ops, I sent patches for that a few
> times over the 3.3 cycle since I was running into it on my systems but
> apparently to /dev/null and further changes in this area have made the
> patches not apply any more.
I've avoided allowing null ops so that the drivers are forced to be explicit
about what they want, and it makes for (IMHO) simpler to follow code in the
core.
Sorry I missed your patches though.
g.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] of: Only compile OF_DYNAMIC on PowerPC pseries and iseries
From: David Miller @ 2012-02-15 21:42 UTC (permalink / raw)
To: grant.likely; +Cc: devicetree-discuss, linuxppc-dev, linux-kernel, rob.herring
In-Reply-To: <1329240330-3539-1-git-send-email-grant.likely@secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 14 Feb 2012 10:25:30 -0700
> Only two architectures use the OF node reference counting and reclaim bits.
> There is no need to compile it for the rest of the PowerPC platforms or for
> any of the other architectures. This patch makes iseries and pseries
> select CONFIG_OF_DYNAMIC, and makes it default to off for everything else.
>
> It is still safe to turn on CONFIG_OF_DYNAMIC on all architectures, it just
> isn't necessary.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v3 24/25] irq_domain: remove "hint" when allocating irq numbers
From: Shawn Guo @ 2012-02-15 21:50 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, devicetree-discuss, Nicolas Ferre, linux-kernel,
Rob Herring, Milton Miller, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20120215202145.GH25779@ponder.secretlab.ca>
On Wed, Feb 15, 2012 at 01:21:45PM -0700, Grant Likely wrote:
> On Wed, Feb 15, 2012 at 04:04:28PM +0100, Nicolas Ferre wrote:
> > On 02/07/2012 07:07 PM, Nicolas Ferre :
> > > On 01/27/2012 10:36 PM, Grant Likely :
> > >> The 'hint' used to try and line up irq numbers with hw irq numbers is
> > >> rather a hack and not very useful. Now that /proc/interrupts also outputs
> > >> the hwirq number, it is even less useful to keep around the 'hint' heuristic.
> > >>
> > >> This patch removes it.
> > >
> > > Grant,
> > >
> > > While trying your patch series in conjunction with Rob one, I do not
> > > find this patch in your irqdomain/next branch (and a couple of others).
> > > Can you tell me if this v3 series is available as a git tree?
> >
> > I am still interested by patch 24-25 of this series but still cannot
> > find them in your irqdomain/next branch:
> > Are they also expected to join the 3.4 merge window material?
>
> I've held off on putting them in irqdomain/next because they are a bit more
> risky than the other patches, and I want an explicit ack from Ben for patches
> 24 & 25. However, that shouldn't really cause any issues since the changes
> in 24 & 25 don't impact the irq_domain functionality or API. They are just
> optimizations.
>
I'm seeing that patch 24 does impact on irq_domain functionality
a little bit. On next tree which has no this patch yet,
irq_create_mapping can reasonably create virq in range 1..15, while
irq_find_mapping will only try to find the virq from 16
(NUM_ISA_INTERRUPTS). This will result in that any hwirq that is < 16
gets multiple entries in the mapping table with different virq numbers
mapped to the same one hwirq.
That's why I have to apply patch #24 (with one line change below) on
top of next tree to get my imx irqdomain series work properly.
@@ -371,7 +371,7 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
return irq_domain_legacy_revmap(domain, hwirq);
/* Allocate a virtual interrupt number */
- virq = irq_alloc_desc(0);
+ virq = irq_alloc_desc_from(1, 0);
if (!virq) {
pr_debug("irq: -> virq allocation failed\n");
return 0;
I need this line of change, because the first call on irq_alloc_desc
will always return 0 to virq and in turn irq_create_mapping fails.
On imx, that's the mapping for timer irq. Hence, the system will hang
there due to irq mapping failure.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: Thiago Jung Bauermann @ 2012-02-15 22:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, K.Prasad, Edjunior Barbosa Machado
In-Reply-To: <20120116081833.GG4512@truffala.fritz.box>
On Mon, 2012-01-16 at 19:18 +1100, David Gibson wrote:
> Hrm. An EXACT breakpoint is not exactly the same as a range
> breakpoint of length 1 (consider unaligned accesses). But despite
> that, it should be possible to implement exact breakpoints on Book3S
> server hardware with some software filtering.
>
> And since that leaves no hardware that *can't* implement exact
> breakpoints (directly or indirectly), I'm not yet convinced of the
> need for a flag bit.
I agree.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Build fail in hugetlbpage.c with linux-next and mpc85xx_defconfig
From: Michael Neuling @ 2012-02-15 23:08 UTC (permalink / raw)
To: galak, Becky Bruce; +Cc: linuxppc-dev, linux-next
Becky,
This has been broken in linux-next for a while. Looks like a merge
issue but you were the last to touch it...
arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
arch/powerpc/mm/hugetlbpage.c:313: error: passing argument 5 of 'parse_args' makes integer from pointer without a cast
include/linux/moduleparam.h:317: note: expected 's16' but argument is of type 'int (*)(char *, char *)'
arch/powerpc/mm/hugetlbpage.c:313: error: too few arguments to function 'parse_args'
Mikey
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Alexander Graf @ 2012-02-15 23:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4F3C0A2B.9000105@freescale.com>
On 15.02.2012, at 20:40, Scott Wood wrote:
> On 02/15/2012 01:36 PM, Alexander Graf wrote:
>>=20
>> On 10.01.2012, at 01:51, Scott Wood wrote:
>>> I was thinking we'd check ESR[EPID] or SRR1[IS] as appropriate, and
>>> treat it as a kernel fault (search exception table) -- but this =
works
>>> too and is a bit cleaner (could be other uses of external pid), at =
the
>>> expense of a couple extra instructions in the emulation path (but
>>> probably a slightly faster host TLB handler).
>>>=20
>>> The check wouldn't go in DO_KVM, though, since on bookehv that only
>>> deals with diverting flow when xSRR1[GS] is set, which wouldn't be =
the
>>> case here.
>>=20
>> Thinking about it a bit more, how is this different from a failed =
get_user()? We can just use the same fixup mechanism as there, right?
>=20
> The fixup mechanism can be the same (we'd like to know whether it =
failed
> due to TLB miss or DSI, so we know which to reflect
No, we only want to know "fast path failed". The reason is a different =
pair of shoes and should be evaluated in the slow path. We shouldn't =
ever fault here during normal operation btw. We already executed a guest =
instruction, so there's almost no reason it can't be read.
> -- but if necessary
> I think we can figure that out with a tlbsx). What's different is =
that
> the page fault handler needs to know that any external pid (or AS1)
> fault is bad, same as if the address were in the kernel area, and it
> should go directly to searching the exception tables instead of trying
> to page something in.
Yes and no. We need to force it to search the exception tables. We don't =
care if the page fault handlers knows anything about external pids.
Either way, we discussed the further stuff on IRC and came to a working =
solution :). Stay tuned.
Alex
^ permalink raw reply
* [PATCH] powerpc/hugepage: Fix missing header file for parse_args
From: Matthew McClintock @ 2012-02-15 23:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-next
In-Reply-To: <14174.1329347321@neuling.org>
This seems to fix the following issue:
arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
arch/powerpc/mm/hugetlbpage.c:313: error: passing argument 5 of 'parse_args' makes integer from pointer without a cast
include/linux/moduleparam.h:317: note: expected 's16' but argument is of type 'int (*)(char *, char *)'
arch/powerpc/mm/hugetlbpage.c:313: error: too few arguments to function 'parse_args'
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/mm/hugetlbpage.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 79c575d..a8b3cc7 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -15,6 +15,7 @@
#include <linux/of_fdt.h>
#include <linux/memblock.h>
#include <linux/bootmem.h>
+#include <linux/moduleparam.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/tlb.h>
--
1.7.6.1
^ permalink raw reply related
* Re: Build fail in hugetlbpage.c with linux-next and mpc85xx_defconfig
From: McClintock Matthew-B29882 @ 2012-02-15 23:32 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev@ozlabs.org, linux-next@vger.kernel.org
In-Reply-To: <14174.1329347321@neuling.org>
On Wed, Feb 15, 2012 at 11:08 PM, Michael Neuling <mikey@neuling.org> wrote=
:
> Becky,
>
> This has been broken in linux-next for a while. =A0Looks like a merge
> issue but you were the last to touch it...
>
> arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
> arch/powerpc/mm/hugetlbpage.c:313: error: passing argument 5 of 'parse_ar=
gs' makes integer from pointer without a cast
> include/linux/moduleparam.h:317: note: expected 's16' but argument is of =
type 'int (*)(char *, char *)'
> arch/powerpc/mm/hugetlbpage.c:313: error: too few arguments to function '=
parse_args'
A suggest fix has been submitted.
-M=
^ permalink raw reply
* Re: Build fail in hugetlbpage.c with linux-next and mpc85xx_defconfig
From: Michael Neuling @ 2012-02-15 23:37 UTC (permalink / raw)
To: McClintock Matthew-B29882
Cc: linuxppc-dev@ozlabs.org, linux-next@vger.kernel.org
In-Reply-To: <CAEsOVNcpBLmsmyZLW2HNe3MDR5cx5oJnPMmGD6Mqz4AjG16=9A@mail.gmail.com>
> > Becky,
> >
> > This has been broken in linux-next for a while. =A0Looks like a merge
> > issue but you were the last to touch it...
> >
> > arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
> > arch/powerpc/mm/hugetlbpage.c:313: error: passing argument 5 of 'parse_ar=
> gs' makes integer from pointer without a cast
> > include/linux/moduleparam.h:317: note: expected 's16' but argument is of =
> type 'int (*)(char *, char *)'
> > arch/powerpc/mm/hugetlbpage.c:313: error: too few arguments to function '=
> parse_args'
>
> A suggest fix has been submitted.
Do you have a link? Which tree is it going in?
Mikey
^ permalink raw reply
* Re: Build fail in hugetlbpage.c with linux-next and mpc85xx_defconfig
From: McClintock Matthew-B29882 @ 2012-02-15 23:40 UTC (permalink / raw)
To: Michael Neuling
Cc: McClintock Matthew-B29882, linuxppc-dev@ozlabs.org,
linux-next@vger.kernel.org
In-Reply-To: <16098.1329349063@neuling.org>
On Wed, Feb 15, 2012 at 11:37 PM, Michael Neuling <mikey@neuling.org> wrote=
:
>> > Becky,
>> >
>> > This has been broken in linux-next for a while. =3DA0Looks like a merg=
e
>> > issue but you were the last to touch it...
>> >
>> > arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
>> > arch/powerpc/mm/hugetlbpage.c:313: error: passing argument 5 of 'parse=
_ar=3D
>> gs' makes integer from pointer without a cast
>> > include/linux/moduleparam.h:317: note: expected 's16' but argument is =
of =3D
>> type 'int (*)(char *, char *)'
>> > arch/powerpc/mm/hugetlbpage.c:313: error: too few arguments to functio=
n '=3D
>> parse_args'
>>
>> A suggest fix has been submitted.
>
> Do you have a link? =A0Which tree is it going in?
http://lists.ozlabs.org/pipermail/linuxppc-dev/2012-February/095903.html
I just sent it. I'm not sure who would pick this up. Ideally it would
go in the next release.
-M=
^ permalink raw reply
* Re: Build fail in hugetlbpage.c with linux-next and mpc85xx_defconfig
From: Stephen Rothwell @ 2012-02-16 0:15 UTC (permalink / raw)
To: Rusty Russell
Cc: Michael Neuling, Pawel Moll, linuxppc-dev, linux-next,
McClintock Matthew-B29882
In-Reply-To: <14174.1329347321@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
Hi Rusty,
On Thu, 16 Feb 2012 10:08:41 +1100 Michael Neuling <mikey@neuling.org> wrote:
>
> This has been broken in linux-next for a while. Looks like a merge
> issue but you were the last to touch it...
>
> arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
> arch/powerpc/mm/hugetlbpage.c:313: error: passing argument 5 of 'parse_args' makes integer from pointer without a cast
> include/linux/moduleparam.h:317: note: expected 's16' but argument is of type 'int (*)(char *, char *)'
> arch/powerpc/mm/hugetlbpage.c:313: error: too few arguments to function 'parse_args'
This was broken by commit b8076966e8e1 ("params: <level>_initcall-like
kernel parameters") from the rr tree which changed the parse_args() API without fixing all
the callers ....
Please add a fix ...
Grep is your friend:
$ git grep -l '\<parse_args(' v3.3-rc1
v3.3-rc1:Documentation/target/tcm_mod_builder.py
v3.3-rc1:arch/powerpc/mm/hugetlbpage.c
v3.3-rc1:arch/x86/tools/insn_sanity.c
v3.3-rc1:arch/x86/tools/test_get_len.c
v3.3-rc1:include/linux/moduleparam.h
v3.3-rc1:init/main.c
v3.3-rc1:kernel/module.c
v3.3-rc1:kernel/params.c
(The Documentation and x86 ones are a false positives, the powerpc one is real)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2] [v4] powerpc/85xx: create 32-bit DTS for the P1022DS
From: Timur Tabi @ 2012-02-16 0:25 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <1329351948-20581-1-git-send-email-timur@freescale.com>
Create a 32-bit address space version of p1022ds.dts. To avoid confusion,
p1022ds.dts is renamed to p1022ds_36b.dts. We also create p1022ds.dtsi
to store some common nodes.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/p1022ds.dts | 274 ---------------------------------
arch/powerpc/boot/dts/p1022ds.dtsi | 234 ++++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1022ds_32b.dts | 103 ++++++++++++
arch/powerpc/boot/dts/p1022ds_36b.dts | 103 ++++++++++++
4 files changed, 440 insertions(+), 274 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/p1022ds.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds.dtsi
create mode 100644 arch/powerpc/boot/dts/p1022ds_32b.dts
create mode 100644 arch/powerpc/boot/dts/p1022ds_36b.dts
diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts
deleted file mode 100644
index ef95717..0000000
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ /dev/null
@@ -1,274 +0,0 @@
-/*
- * P1022 DS 36Bit Physical Address Map Device Tree Source
- *
- * Copyright 2010 Freescale Semiconductor, Inc.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-/include/ "fsl/p1022si-pre.dtsi"
-/ {
- model = "fsl,P1022DS";
- compatible = "fsl,P1022DS";
-
- memory {
- device_type = "memory";
- };
-
- lbc: localbus@fffe05000 {
- reg = <0xf 0xffe05000 0 0x1000>;
- ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
- 0x1 0x0 0xf 0xe0000000 0x08000000
- 0x2 0x0 0xf 0xff800000 0x00040000
- 0x3 0x0 0xf 0xffdf0000 0x00008000>;
-
- /*
- * This node is used to access the pixis via "indirect" mode,
- * which is done by writing the pixis register index to chip
- * select 0 and the value to/from chip select 1. Indirect
- * mode is the only way to access the pixis when DIU video
- * is enabled. Note that this assumes that the first column
- * of the 'ranges' property above is the chip select number.
- */
- board-control@0,0 {
- compatible = "fsl,p1022ds-indirect-pixis";
- reg = <0x0 0x0 1 /* CS0 */
- 0x1 0x0 1>; /* CS1 */
- };
-
- nor@0,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "cfi-flash";
- reg = <0x0 0x0 0x8000000>;
- bank-width = <2>;
- device-width = <1>;
-
- partition@0 {
- reg = <0x0 0x03000000>;
- label = "ramdisk-nor";
- read-only;
- };
-
- partition@3000000 {
- reg = <0x03000000 0x00e00000>;
- label = "diagnostic-nor";
- read-only;
- };
-
- partition@3e00000 {
- reg = <0x03e00000 0x00200000>;
- label = "dink-nor";
- read-only;
- };
-
- partition@4000000 {
- reg = <0x04000000 0x00400000>;
- label = "kernel-nor";
- read-only;
- };
-
- partition@4400000 {
- reg = <0x04400000 0x03b00000>;
- label = "jffs2-nor";
- };
-
- partition@7f00000 {
- reg = <0x07f00000 0x00080000>;
- label = "dtb-nor";
- read-only;
- };
-
- partition@7f80000 {
- reg = <0x07f80000 0x00080000>;
- label = "u-boot-nor";
- read-only;
- };
- };
-
- nand@2,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,elbc-fcm-nand";
- reg = <0x2 0x0 0x40000>;
-
- partition@0 {
- reg = <0x0 0x02000000>;
- label = "u-boot-nand";
- read-only;
- };
-
- partition@2000000 {
- reg = <0x02000000 0x10000000>;
- label = "jffs2-nand";
- };
-
- partition@12000000 {
- reg = <0x12000000 0x10000000>;
- label = "ramdisk-nand";
- read-only;
- };
-
- partition@22000000 {
- reg = <0x22000000 0x04000000>;
- label = "kernel-nand";
- };
-
- partition@26000000 {
- reg = <0x26000000 0x01000000>;
- label = "dtb-nand";
- read-only;
- };
-
- partition@27000000 {
- reg = <0x27000000 0x19000000>;
- label = "reserved-nand";
- };
- };
-
- board-control@3,0 {
- compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
- reg = <3 0 0x30>;
- interrupt-parent = <&mpic>;
- /*
- * IRQ8 is generated if the "EVENT" switch is pressed
- * and PX_CTL[EVESEL] is set to 00.
- */
- interrupts = <8 8 0 0>;
- };
- };
-
- soc: soc@fffe00000 {
- ranges = <0x0 0xf 0xffe00000 0x100000>;
-
- i2c@3100 {
- wm8776:codec@1a {
- compatible = "wlf,wm8776";
- reg = <0x1a>;
- /*
- * clock-frequency will be set by U-Boot if
- * the clock is enabled.
- */
- };
- };
-
- spi@7000 {
- flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "spansion,s25sl12801";
- reg = <0>;
- spi-max-frequency = <40000000>; /* input clock */
-
- partition@0 {
- label = "u-boot-spi";
- reg = <0x00000000 0x00100000>;
- read-only;
- };
- partition@100000 {
- label = "kernel-spi";
- reg = <0x00100000 0x00500000>;
- read-only;
- };
- partition@600000 {
- label = "dtb-spi";
- reg = <0x00600000 0x00100000>;
- read-only;
- };
- partition@700000 {
- label = "file system-spi";
- reg = <0x00700000 0x00900000>;
- };
- };
- };
-
- ssi@15000 {
- fsl,mode = "i2s-slave";
- codec-handle = <&wm8776>;
- fsl,ssi-asynchronous;
- };
-
- usb@22000 {
- phy_type = "ulpi";
- };
-
- usb@23000 {
- status = "disabled";
- };
-
- mdio@24000 {
- phy0: ethernet-phy@0 {
- interrupts = <3 1 0 0>;
- reg = <0x1>;
- };
- phy1: ethernet-phy@1 {
- interrupts = <9 1 0 0>;
- reg = <0x2>;
- };
- tbi-phy@2 {
- device_type = "tbi-phy";
- reg = <0x2>;
- };
- };
-
- ethernet@b0000 {
- phy-handle = <&phy0>;
- phy-connection-type = "rgmii-id";
- };
-
- ethernet@b1000 {
- phy-handle = <&phy1>;
- phy-connection-type = "rgmii-id";
- };
- };
-
- pci0: pcie@fffe09000 {
- reg = <0xf 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
- pcie@0 {
- ranges = <0x2000000 0x0 0xe0000000
- 0x2000000 0x0 0xe0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci1: pcie@fffe0a000 {
- reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x40000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x10000>;
- pcie@0 {
- reg = <0x0 0x0 0x0 0x0 0x0>;
- ranges = <0x2000000 0x0 0xe0000000
- 0x2000000 0x0 0xe0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci2: pcie@fffe0b000 {
- reg = <0xf 0xffe0b000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
- pcie@0 {
- ranges = <0x2000000 0x0 0xe0000000
- 0x2000000 0x0 0xe0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-};
-
-/include/ "fsl/p1022si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi b/arch/powerpc/boot/dts/p1022ds.dtsi
new file mode 100644
index 0000000..7cdb505
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -0,0 +1,234 @@
+/*
+ * P1022 DS Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&board_lbc {
+ /*
+ * This node is used to access the pixis via "indirect" mode,
+ * which is done by writing the pixis register index to chip
+ * select 0 and the value to/from chip select 1. Indirect
+ * mode is the only way to access the pixis when DIU video
+ * is enabled. Note that this assumes that the first column
+ * of the 'ranges' property above is the chip select number.
+ */
+ board-control@0,0 {
+ compatible = "fsl,p1022ds-indirect-pixis";
+ reg = <0x0 0x0 1 /* CS0 */
+ 0x1 0x0 1>; /* CS1 */
+ interrupt-parent = <&mpic>;
+ interrupts = <8 0 0 0>;
+ };
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ reg = <0x0 0x03000000>;
+ label = "ramdisk-nor";
+ read-only;
+ };
+
+ partition@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ label = "diagnostic-nor";
+ read-only;
+ };
+
+ partition@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ label = "dink-nor";
+ read-only;
+ };
+
+ partition@4000000 {
+ reg = <0x04000000 0x00400000>;
+ label = "kernel-nor";
+ read-only;
+ };
+
+ partition@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ label = "jffs2-nor";
+ };
+
+ partition@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ label = "dtb-nor";
+ read-only;
+ };
+
+ partition@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ label = "u-boot-nor";
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ partition@0 {
+ reg = <0x0 0x02000000>;
+ label = "u-boot-nand";
+ read-only;
+ };
+
+ partition@2000000 {
+ reg = <0x02000000 0x10000000>;
+ label = "jffs2-nand";
+ };
+
+ partition@12000000 {
+ reg = <0x12000000 0x10000000>;
+ label = "ramdisk-nand";
+ read-only;
+ };
+
+ partition@22000000 {
+ reg = <0x22000000 0x04000000>;
+ label = "kernel-nand";
+ };
+
+ partition@26000000 {
+ reg = <0x26000000 0x01000000>;
+ label = "dtb-nand";
+ read-only;
+ };
+
+ partition@27000000 {
+ reg = <0x27000000 0x19000000>;
+ label = "reserved-nand";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
+ reg = <3 0 0x30>;
+ interrupt-parent = <&mpic>;
+ /*
+ * IRQ8 is generated if the "EVENT" switch is pressed
+ * and PX_CTL[EVESEL] is set to 00.
+ */
+ interrupts = <8 0 0 0>;
+ };
+};
+
+&board_soc {
+ i2c@3100 {
+ wm8776:codec@1a {
+ compatible = "wlf,wm8776";
+ reg = <0x1a>;
+ /*
+ * clock-frequency will be set by U-Boot if
+ * the clock is enabled.
+ */
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <40000000>; /* input clock */
+
+ partition@0 {
+ label = "u-boot-spi";
+ reg = <0x00000000 0x00100000>;
+ read-only;
+ };
+ partition@100000 {
+ label = "kernel-spi";
+ reg = <0x00100000 0x00500000>;
+ read-only;
+ };
+ partition@600000 {
+ label = "dtb-spi";
+ reg = <0x00600000 0x00100000>;
+ read-only;
+ };
+ partition@700000 {
+ label = "file system-spi";
+ reg = <0x00700000 0x00900000>;
+ };
+ };
+ };
+
+ ssi@15000 {
+ fsl,mode = "i2s-slave";
+ codec-handle = <&wm8776>;
+ fsl,ssi-asynchronous;
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ usb@23000 {
+ status = "disabled";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupts = <3 1 0 0>;
+ reg = <0x1>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <9 1 0 0>;
+ reg = <0x2>;
+ };
+ tbi-phy@2 {
+ device_type = "tbi-phy";
+ reg = <0x2>;
+ };
+ };
+
+ ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ ethernet@b1000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1022ds_32b.dts b/arch/powerpc/boot/dts/p1022ds_32b.dts
new file mode 100644
index 0000000..d96cae0
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds_32b.dts
@@ -0,0 +1,103 @@
+/*
+ * P1022 DS 32-bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1022si-pre.dtsi"
+/ {
+ model = "fsl,P1022DS";
+ compatible = "fsl,P1022DS";
+
+ memory {
+ device_type = "memory";
+ };
+
+ board_lbc: lbc: localbus@ffe05000 {
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x1 0x0 0x0 0xe0000000 0x08000000
+ 0x2 0x0 0x0 0xff800000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000>;
+ reg = <0x0 0xffe05000 0 0x1000>;
+ };
+
+ board_soc: soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges = <0x2000000 0x0 0xe0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg = <0x0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ ranges = <0x2000000 0x0 0xe0000000 0 0xc0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
+ reg = <0 0xffe0a000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci2: pcie@ffe0b000 {
+ ranges = <0x2000000 0x0 0xe0000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ reg = <0 0xffe0b000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "fsl/p1022si-post.dtsi"
+/include/ "p1022ds.dtsi"
diff --git a/arch/powerpc/boot/dts/p1022ds_36b.dts b/arch/powerpc/boot/dts/p1022ds_36b.dts
new file mode 100644
index 0000000..f7aacce
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1022ds_36b.dts
@@ -0,0 +1,103 @@
+/*
+ * P1022 DS 36-bit Physical Address Map Device Tree Source
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1022si-pre.dtsi"
+/ {
+ model = "fsl,P1022DS";
+ compatible = "fsl,P1022DS";
+
+ memory {
+ device_type = "memory";
+ };
+
+ board_lbc: lbc: localbus@fffe05000 {
+ ranges = <0x0 0x0 0xf 0xe8000000 0x08000000
+ 0x1 0x0 0xf 0xe0000000 0x08000000
+ 0x2 0x0 0xf 0xff800000 0x00040000
+ 0x3 0x0 0xf 0xffdf0000 0x00008000>;
+ reg = <0xf 0xffe05000 0 0x1000>;
+ };
+
+ board_soc: soc: soc@fffe00000 {
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe09000 {
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ reg = <0xf 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x40000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc20000 0x0 0x10000>;
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci2: pcie@fffe0b000 {
+ ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ reg = <0xf 0xffe0b000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xe0000000
+ 0x2000000 0x0 0xe0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "fsl/p1022si-post.dtsi"
+/include/ "p1022ds.dtsi"
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] [v4] powerpc/85xx: p1022ds: disable the NOR flash node if video is enabled
From: Timur Tabi @ 2012-02-16 0:25 UTC (permalink / raw)
To: galak, linuxppc-dev
The Freescale P1022 has a unique pin muxing "feature" where the DIU video
controller's video signals are muxed with 24 of the local bus address signals.
When the DIU is enabled, the bulk of the local bus is disabled, preventing
access to memory-mapped devices like NOR flash and the pixis FPGA.
Therefore, if the DIU is going to be enabled, then memory-mapped devices on
the localbus, like NOR flash, need to be disabled.
This also means that the localbus is not a 'simple-bus' any more, so remove
that string from the compatible node.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 6 ++-
arch/powerpc/platforms/85xx/p1022_ds.c | 71 +++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
index ff9ed1d..16f27c7 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
@@ -35,7 +35,11 @@
&lbc {
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,p1022-elbc", "fsl,elbc", "simple-bus";
+ /*
+ * The localbus on the P1022 is not a simple-bus because of the eLBC
+ * pin muxing when the DIU is enabled.
+ */
+ compatible = "fsl,p1022-elbc", "fsl,elbc";
interrupts = <19 2 0 0>;
};
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index b0984ad..bbdb38c 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -251,6 +251,49 @@ void __init p1022_ds_pic_init(void)
mpic_init(mpic);
}
+#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/*
+ * Disables a node in the device tree.
+ *
+ * This function is called before kmalloc() is available, so the 'new' object
+ * should be allocated in the global area. The easiest way is to do that is
+ * to allocate one static local variable for each call to this function.
+ */
+static void __init disable_one_node(struct device_node *np, struct property *new)
+{
+ struct property *old;
+
+ old = of_find_property(np, new->name, NULL);
+ if (old)
+ prom_update_property(np, new, old);
+ else
+ prom_add_property(np, new);
+}
+
+/* TRUE if there is a "video=fslfb" command-line parameter. */
+static bool fslfb;
+
+/*
+ * Search for a "video=fslfb" command-line parameter, and set 'fslfb' to
+ * true if we find it.
+ *
+ * We need to use early_param() instead of __setup() because the normal
+ * __setup() gets called to late. However, early_param() gets called very
+ * early, before the device tree is unflattened, so all we can do now is set a
+ * global variable. Later on, p1022_ds_setup_arch() will use that variable
+ * to determine if we need to update the device tree.
+ */
+static int __init early_video_setup(char *options)
+{
+ fslfb = (strncmp(options, "fslfb:", 6) == 0);
+
+ return 0;
+}
+early_param("video", early_video_setup);
+
+#endif
+
/*
* Setup the architecture
*/
@@ -288,6 +331,34 @@ static void __init p1022_ds_setup_arch(void)
diu_ops.set_monitor_port = p1022ds_set_monitor_port;
diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
diu_ops.valid_monitor_port = p1022ds_valid_monitor_port;
+
+ /*
+ * Disable the NOR flash node if there is video=fslfb... command-line
+ * parameter. When the DIU is active, NOR flash is unavailable, so we
+ * have to disable the node before the MTD driver loads.
+ */
+ if (fslfb) {
+ struct device_node *np =
+ of_find_compatible_node(NULL, NULL, "fsl,p1022-elbc");
+
+ if (np) {
+ np = of_find_compatible_node(np, NULL, "cfi-flash");
+ if (np) {
+ static struct property nor_status = {
+ .name = "status",
+ .value = "disabled",
+ .length = sizeof("disabled"),
+ };
+
+ pr_info("p1022ds: disabling %s node",
+ np->full_name);
+ disable_one_node(np, &nor_status);
+ of_node_put(np);
+ }
+ }
+
+ }
+
#endif
mpc85xx_smp_init();
--
1.7.3.4
^ permalink raw reply related
* RE: [RFC] usb: Fix build error due to dma_mask is not at pdev_archdata at ARM
From: Chen Peter-B29397 @ 2012-02-16 1:12 UTC (permalink / raw)
To: Mehresh Ramneek-B31383, stern@rowland.harvard.edu, agust@denx.de
Cc: Estevam Fabio-R49496, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, kernel@pengutronix.de
In-Reply-To: <75A6930FC6B2FE479E2BC468C9240CE0026C19@039-SN1MPN1-002.039d.mgd.msft.net>
=20
> When build i.mx platform with imx_v6_v7_defconfig, and after adding USB
> Gadget support, it has below build error:
>=20
> CC drivers/usb/host/fsl-mph-dr-of.o
> drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
> drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
> has no member named 'dma_mask'
>=20
> It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
>=20
> For PowerPC, there is dma_mask at struct pdev_archdata, but there is no
> dma_mask at struct pdev_archdata for ARM. The pdev_archdata is related to
> specific platform, it should NOT be accessed by cross platform drivers,
> like USB.
>=20
> The code for pdev_archdata should be useless, as for PowerPC, it has
> already gotten the value for pdev->dev.dma_mask at function
> arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c.
>=20
> Anyone who has PowerPC hardware with USB host enabled, and uses this code
> can help me a test? Thank you
>=20
> [Ramneek]: Hi Peter, the code is working for Host stack on PowerPC.
=20
Thanks, Ramneek. I will post PATCH and add:
Tested-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
^ permalink raw reply
* [PATCH] usb: Fix build error due to dma_mask is not at pdev_archdata at ARM
From: Peter Chen @ 2012-02-16 1:41 UTC (permalink / raw)
To: stern
Cc: fabio.estevam, linux-usb, ramneek.mehresh, agust, linuxppc-dev,
stable
When build i.mx platform with imx_v6_v7_defconfig, and after adding
USB Gadget support, it has below build error:
CC drivers/usb/host/fsl-mph-dr-of.o
drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
has no member named 'dma_mask'
It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
For PowerPC, there is dma_mask at struct pdev_archdata, but there is
no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is
related to specific platform, it should NOT be accessed by
cross platform drivers, like USB.
The code for pdev_archdata should be useless, as for PowerPC,
it has already gotten the value for pdev->dev.dma_mask at function
arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c.
Tested-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
---
drivers/usb/host/fsl-mph-dr-of.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 7916e56..ab333ac 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -94,7 +94,6 @@ struct platform_device * __devinit fsl_usb2_device_register(
pdev->dev.parent = &ofdev->dev;
pdev->dev.coherent_dma_mask = ofdev->dev.coherent_dma_mask;
- pdev->dev.dma_mask = &pdev->archdata.dma_mask;
*pdev->dev.dma_mask = *ofdev->dev.dma_mask;
retval = platform_device_add_data(pdev, pdata, sizeof(*pdata));
--
1.7.0.4
^ permalink raw reply related
* Re: Build fail in hugetlbpage.c with linux-next and mpc85xx_defconfig
From: Stephen Rothwell @ 2012-02-16 2:14 UTC (permalink / raw)
To: Rusty Russell
Cc: Michael Neuling, Pawel Moll, linuxppc-dev, linux-next,
McClintock Matthew-B29882
In-Reply-To: <20120216111513.918494b07a5331eabe3d32ac@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
Hi Rusty,
On Thu, 16 Feb 2012 11:15:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This was broken by commit b8076966e8e1 ("params: <level>_initcall-like
> kernel parameters") from the rr tree which changed the parse_args() API without fixing all
> the callers ....
I have reverted the above commit (and the following fix one) for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox