* Re: [RFC] Inter-processor Mailboxes Drivers
From: Blanchard, Hollis @ 2011-02-14 23:05 UTC (permalink / raw)
To: Linus Walleij
Cc: Inge, Meador, openmcapi-dev, Hiroshi DOYU, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <AANLkTin+ZSNHX2iv=XwWCgxy330UJwhkf1T=4BMXZ22s@mail.gmail.com>
On 02/13/2011 01:24 PM, Linus Walleij wrote:
>> > 3. Userspace interfaces for accessing the mailboxes. A
>> > '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for =
example.
> What kind of business does userspace have with directly using
> mailboxes? Enlighten me so I get it... in our system these are
> used by protocols, such as net/caif/* thru drivers/net/caif/*, and
> we have similar kernelspace functionality for Phonet.
>
> CAIF and Phonet on the other hand, have custom openings
> down to the thing that exists on the other end of the mailbox.
> Most of these systems tend to talk some funny protocol that
> is often better handled by the kernel than by any userspace.
>
> So is this for the situation when you have no intermediate
> protocol between your userpace and the other CPU's
> subsystem? Or are you thinking about handling that
> protocol in userspace? That is generally not such a good idea
> for efficiency reasons.
OpenMCAPI (http://openmcapi.org) implements the MCAPI specification,=20
which is a simple application-level communication API that uses shared=20
memory. The API could be layered over any protocol, but was more or less =
designed for simple shared-memory systems, e.g. fixed topology, no=20
retransmission, etc.
Currently, we implement almost all of this as a shared library, plus a=20
very small kernel driver. The only requirements on the kernel are to=20
allow userspace to map the shared memory area, and provide an IPI=20
mechanism (and allow the process to sleep while waiting). Applications=20
sync with each other using normal atomic memory operations.
We're now trying to optimize the transfer of scalars on platforms that=20
provide mailboxes (beyond simple IPIs), which is why we're looking at=20
defining a user-facing API to such hardware.
I'll add that we haven't done serious optimization yet, but the numbers=20
we do have seem reasonable. What are the "efficiency" issues you're=20
worried about?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [PATCH V8 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core InterfaceLayer
From: Greg KH @ 2011-02-15 1:04 UTC (permalink / raw)
To: David Laight
Cc: Tirumala Marri, linux-usb, Alexander Gordeev, Mark Miesfeld,
linuxppc-dev, Fushen Chen
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC4D@saturn3.aculab.com>
On Mon, Feb 14, 2011 at 08:53:21AM -0000, David Laight wrote:
>
> > > Sorry, I don't understand that. I think u32 is always 32bit
> > > 4byte on all archs. Right?
> >
> > Yes.
> >
> > Use an unsigned long if you want to hold a pointer correctly on all
> > arches.
>
> Although that is true for many systems (and probably all ppc Linux)
> it isn't necessarily true (eg 64 bit Microsoft Windows).
Again, it is true for all Linux architectures. We aren't caring about
any other operating systems here, sorry.
> C99 inttypes.h should define uintptr_t as an unsigned integer
> type that is large enough to hold a (data) pointer.
> I'm not sure if this is defined for the Linux kernel.
uint* aren't to be used within the kernel as they make no sense.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc: irq_data conversion
From: Lennert Buytenhek @ 2011-02-15 6:01 UTC (permalink / raw)
To: Grant Likely; +Cc: tglx, linuxppc-dev, glikely
In-Reply-To: <20110214180715.GA30647@angua.secretlab.ca>
On Mon, Feb 14, 2011 at 11:07:15AM -0700, Grant Likely wrote:
> > This patch converts powerpc over to the new irq_data based irq_chip
> > functions, as was done earlier for ARM and some other architectures.
> >
> > struct irq_data is described here:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ff7dcd44dd446db2c3e13bdedf2d52b8e0127f16
> >
> > The new irq_chip functions are described here:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8822657e799b02c55556c99a601261e207a299d
> >
> > As I don't have powerpc hardware myself, this hasn't been well-tested
> > at all -- build and run-time testing would be much appreciated.
>
> Apply warning:
>
> /home/grant/hacking/linux-2.6/.git/rebase-apply/patch:3470: space before tab in indent.
> .irq_mask_ack = uic_mask_ack_irq,
> warning: 1 line adds whitespace errors.
The original uic.c already had the space there, but yes, there's no
reason not to fix that while we're at it -- thanks.
> It seems to work fine on my ppc32 MPC5200 based Lite5200 board.
>
> Got a build failure from my limited build farm:
>
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] cc1: warnings being treated as errors
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/platforms/pasemi/setup.c: In function 'pas_init_IRQ':
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/platforms/pasemi/setup.c:243: error: passing argument 1 of 'mpic_unmask_irq' makes pointer from integer without a cast
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/include/asm/mpic.h:470: note: expected 'struct irq_data *' but argument is of type 'int'
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/platforms/pasemi/setup.c: In function 'pas_machine_check_handler':
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/platforms/pasemi/setup.c:269: error: passing argument 1 of 'mpic_end_irq' makes pointer from integer without a cast
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/include/asm/mpic.h:474: note: expected 'struct irq_data *' but argument is of type 'int'
> 02/14 10:38:57 ERROR|base_utils:0106| [stderr] make[3]: *** [arch/powerpc/platforms/pasemi/setup.o] Error 1
OK, that should be fixed by this:
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index f372ec1..a6067b3 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -240,7 +240,7 @@ static __init void pas_init_IRQ(void)
nmi_virq = irq_create_mapping(NULL, *nmiprop);
mpic_irq_set_priority(nmi_virq, 15);
set_irq_type(nmi_virq, IRQ_TYPE_EDGE_RISING);
- mpic_unmask_irq(nmi_virq);
+ mpic_unmask_irq(irq_get_irq_data(nmi_virq));
}
of_node_put(mpic_node);
@@ -266,7 +266,7 @@ static int pas_machine_check_handler(struct pt_regs *regs)
if (nmi_virq != NO_IRQ && mpic_get_mcirq() == nmi_virq) {
printk(KERN_ERR "NMI delivered\n");
debugger(regs);
- mpic_end_irq(nmi_virq);
+ mpic_end_irq(irq_get_irq_data(nmi_virq));
goto out;
}
> I'm running it through the ozlabs build tester:
>
> http://kisskb.ellerman.id.au/kisskb/branch/13/
>
> Results should be available there sometime in the next 6-12 hours
Great, thanks.
thanks,
Lennert
^ permalink raw reply related
* Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2011-02-15 14:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
Please pull the 'next' branch of the 4xx tree. These commits have been
sitting there for a while and I wanted to get them into your branch
before tackling the latest round of 476 stuff from Shaggy.
josh
The following changes since commit 5d7d8072edc11080a7cf6cc37c9f4e61ca1e93c9:
powerpc/pseries: Fix build of topology stuff without CONFIG_NUMA (2011-01-12 10:56:29 +1100)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Dave Kleikamp (2):
powerpc/476: define specific cpu table entry DD2 core
powerpc/476: Workaround for PLB6 hang
Rupjyoti Sarmah (1):
powerpc/44x: PHY fixup for USB on canyonlands board
Tirumala Marri (1):
powerpc/44x: Add USB DWC DTS entry to Canyonlands board
arch/powerpc/boot/dts/canyonlands.dts | 24 +++++
arch/powerpc/include/asm/cputable.h | 3 +-
arch/powerpc/kernel/cputable.c | 22 ++++-
arch/powerpc/mm/tlb_nohash_low.S | 35 +++++++
arch/powerpc/platforms/44x/44x.h | 4 +
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/canyonlands.c | 134 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 -
9 files changed, 218 insertions(+), 7 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
^ permalink raw reply
* FSL USB in 2.6.37
From: Gary Thomas @ 2011-02-15 17:47 UTC (permalink / raw)
To: Linux PPC Development
I'm trying to get my platform support working in mainline
2.6.37. I have a MPC8379 which is working well in 2.6.32.
When I just move my platform to the new kernel, everything
works except for USB host mode. Nothing special about my
platform - it's pretty much like the FSL eval boards (as
far as this part is concerned). I can see it start up,
claim to power up the internal hub, but I never see the
state change interrupt from the hub.
Are there any known gotchas here? Any ideas?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: FSL USB in 2.6.37
From: Anatolij Gustschin @ 2011-02-15 18:18 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4D5ABC25.80104@mlbassoc.com>
On Tue, 15 Feb 2011 10:47:17 -0700
Gary Thomas <gary@mlbassoc.com> wrote:
> I'm trying to get my platform support working in mainline
> 2.6.37. I have a MPC8379 which is working well in 2.6.32.
>
> When I just move my platform to the new kernel, everything
> works except for USB host mode. Nothing special about my
> platform - it's pretty much like the FSL eval boards (as
> far as this part is concerned). I can see it start up,
> claim to power up the internal hub, but I never see the
> state change interrupt from the hub.
>
> Are there any known gotchas here? Any ideas?
Does this patch [1] help?
[1] http://patchwork.ozlabs.org/patch/78260/
^ permalink raw reply
* Re: [PATCH] powerpc: irq_data conversion
From: Grant Likely @ 2011-02-15 20:06 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: tglx, linuxppc-dev
In-Reply-To: <20110215060158.GG1727@mail.wantstofly.org>
On Mon, Feb 14, 2011 at 11:01 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> On Mon, Feb 14, 2011 at 11:07:15AM -0700, Grant Likely wrote:
>
>> > This patch converts powerpc over to the new irq_data based irq_chip
>> > functions, as was done earlier for ARM and some other architectures.
>> >
>> > struct irq_data is described here:
>> >
>> > =A0 =A0 http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6=
.git;a=3Dcommit;h=3Dff7dcd44dd446db2c3e13bdedf2d52b8e0127f16
>> >
>> > The new irq_chip functions are described here:
>> >
>> > =A0 =A0 http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6=
.git;a=3Dcommit;h=3Df8822657e799b02c55556c99a601261e207a299d
>> >
>> > As I don't have powerpc hardware myself, this hasn't been well-tested
>> > at all -- build and run-time testing would be much appreciated.
>>
>> Apply warning:
>>
>> /home/grant/hacking/linux-2.6/.git/rebase-apply/patch:3470: space before=
tab in indent.
>> =A0 =A0 =A0 .irq_mask_ack =A0 =3D uic_mask_ack_irq,
>> warning: 1 line adds whitespace errors.
>
> The original uic.c already had the space there, but yes, there's no
> reason not to fix that while we're at it -- thanks.
Particularly when you're touching that particular line. :-)
More errors with ppc64_defconfig:
02/15 12:55:39 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/sysdev/mpic.c: In
function 'mpic_from_ipi': 02/15 12:55:39 ERROR|base_utils:0106|
[stderr] /home/autotest/data/kernelcross/linux/arch/powerpc/sysdev/mpic.c:6=
41:
error: 'struct irq_desc' has no member named 'chip_data' 02/15
12:55:39 ERROR|base_utils:0106| [stderr] make[2]: ***
[arch/powerpc/sysdev/mpic.o] Error 1
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:
In function 'ps3_virq_setup':
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:205:
error: passing argument 1 of 'ps3_chip_mask' makes pointer from
integer without a cast
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:102:
note: expected 'struct irq_data *' but argument is of type 'unsigned
int'
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:
In function 'ps3_irq_plug_destroy':
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:299:
error: passing argument 1 of 'ps3_chip_mask' makes pointer from
integer without a cast
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:102:
note: expected 'struct irq_data *' but argument is of type 'unsigned
int'
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:
In function 'ps3_event_receive_port_destroy':
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:360:
error: passing argument 1 of 'ps3_chip_mask' makes pointer from
integer without a cast
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:102:
note: expected 'struct irq_data *' but argument is of type 'unsigned
int'
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:
In function 'ps3_io_irq_destroy':
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:495:
error: passing argument 1 of 'ps3_chip_mask' makes pointer from
integer without a cast
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:102:
note: expected 'struct irq_data *' but argument is of type 'unsigned
int'
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:
In function 'ps3_vuart_irq_destroy':
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:556:
error: passing argument 1 of 'ps3_chip_mask' makes pointer from
integer without a cast
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:102:
note: expected 'struct irq_data *' but argument is of type 'unsigned
int'
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:
In function 'ps3_spe_irq_destroy':
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:608:
error: passing argument 1 of 'ps3_chip_mask' makes pointer from
integer without a cast
02/15 12:55:58 ERROR|base_utils:0106| [stderr]
/home/autotest/data/kernelcross/linux/arch/powerpc/platforms/ps3/interrupt.=
c:102:
note: expected 'struct irq_data *' but argument is of type 'unsigned
int'
02/15 12:55:58 ERROR|base_utils:0106| [stderr] make[3]: ***
[arch/powerpc/platforms/ps3/interrupt.o] Error 1
Also running it through the ozlabs build tester again:
http://kisskb.ellerman.id.au/kisskb/branch/13/
Results should be available there sometime in the next 6-12 hours
g.
>
>
> diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platfor=
ms/pasemi/setup.c
> index f372ec1..a6067b3 100644
> --- a/arch/powerpc/platforms/pasemi/setup.c
> +++ b/arch/powerpc/platforms/pasemi/setup.c
> @@ -240,7 +240,7 @@ static __init void pas_init_IRQ(void)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nmi_virq =3D irq_create_mapping(NULL, *nmi=
prop);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mpic_irq_set_priority(nmi_virq, 15);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set_irq_type(nmi_virq, IRQ_TYPE_EDGE_RISIN=
G);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpic_unmask_irq(nmi_virq);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpic_unmask_irq(irq_get_irq_data(nmi_virq))=
;
> =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0of_node_put(mpic_node);
> @@ -266,7 +266,7 @@ static int pas_machine_check_handler(struct pt_regs *=
regs)
> =A0 =A0 =A0 =A0if (nmi_virq !=3D NO_IRQ && mpic_get_mcirq() =3D=3D nmi_vi=
rq) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "NMI delivered\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0debugger(regs);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpic_end_irq(nmi_virq);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpic_end_irq(irq_get_irq_data(nmi_virq));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;
> =A0 =A0 =A0 =A0}
>
>
>> I'm running it through the ozlabs build tester:
>>
>> http://kisskb.ellerman.id.au/kisskb/branch/13/
>>
>> Results should be available there sometime in the next 6-12 hours
>
> Great, thanks.
>
>
> thanks,
> Lennert
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] Inter-processor Mailboxes Drivers
From: Meador Inge @ 2011-02-15 21:58 UTC (permalink / raw)
To: Jamie Iles
Cc: openmcapi-dev, Blanchard, Hollis, Hiroshi DOYU, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20110214100104.GC4371@pulham.picochip.com>
On 02/14/2011 04:01 AM, Jamie Iles wrote:
> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>> 1. Hardware specific bits somewhere under '.../arch/*'. Drivers
>> for the MPIC message registers on Power and OMAP4 mailboxes, for
>> example.
>> 2. A higher level driver under '.../drivers/mailbox/*'. That the
>> pieces in (1) would register with. This piece would expose the
>> main kernel API.
>> 3. Userspace interfaces for accessing the mailboxes. A
>> '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for example.
>
> How about using virtio for all of this and having the mailbox as a
> notification/message passing driver for the virtio backend? There are
> already virtio console and network drivers that could be useful for the
> userspace part of it. drivers/virtio/virtio_ring.c might be a good
> starting point if you thought there was some mileage in this approach.
To be honest, I am not that familiar with 'virtio', but I will take a
look. Thanks for the pointer. Maybe Hollis can speak to this idea more.
> Jamie
>
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [RFC] Inter-processor Mailboxes Drivers
From: Blanchard, Hollis @ 2011-02-15 23:38 UTC (permalink / raw)
To: Inge, Meador
Cc: openmcapi-dev, Jamie Iles, Hiroshi DOYU, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <4D5AF712.3080509@mentor.com>
On 02/15/2011 01:58 PM, Meador Inge wrote:
> On 02/14/2011 04:01 AM, Jamie Iles wrote:
>> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>>> 1. Hardware specific bits somewhere under '.../arch/*'. =
Drivers
>>> for the MPIC message registers on Power and OMAP4 mailboxes, =
>>> for
>>> example.
>>> 2. A higher level driver under '.../drivers/mailbox/*'. That =
the
>>> pieces in (1) would register with. This piece would expose =
the
>>> main kernel API.
>>> 3. Userspace interfaces for accessing the mailboxes. A
>>> '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for =
example.
>>
>> How about using virtio for all of this and having the mailbox as a
>> notification/message passing driver for the virtio backend? There =
are
>> already virtio console and network drivers that could be useful for =
the
>> userspace part of it. drivers/virtio/virtio_ring.c might be a good
>> starting point if you thought there was some mileage in this =
approach.
>
> To be honest, I am not that familiar with 'virtio', but I will take a=20
> look. Thanks for the pointer. Maybe Hollis can speak to this idea =
more.
My opinion is that virtio is (over?) complicated.
I've looked into it in the past, and I'm definitely open to using it if=20
somebody can demonstrate how easy it is, but adopting it wouldn't have=20
helped OpenMCAPI with our use cases, and would have incurred extra pain, =
so we didn't.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: FSL USB in 2.6.37
From: Gary Thomas @ 2011-02-16 0:25 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: Linux PPC Development
In-Reply-To: <20110215191856.67f8f0c4@wker>
On 02/15/2011 11:18 AM, Anatolij Gustschin wrote:
> On Tue, 15 Feb 2011 10:47:17 -0700
> Gary Thomas<gary@mlbassoc.com> wrote:
>
>> I'm trying to get my platform support working in mainline
>> 2.6.37. I have a MPC8379 which is working well in 2.6.32.
>>
>> When I just move my platform to the new kernel, everything
>> works except for USB host mode. Nothing special about my
>> platform - it's pretty much like the FSL eval boards (as
>> far as this part is concerned). I can see it start up,
>> claim to power up the internal hub, but I never see the
>> state change interrupt from the hub.
>>
>> Are there any known gotchas here? Any ideas?
>
> Does this patch [1] help?
>
> [1] http://patchwork.ozlabs.org/patch/78260/
Indeed, it fixes my problem :-)
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Question about flash allocation
From: Mitsutaka Amano @ 2011-02-16 4:28 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Why does CFI(or other flash memory) have to alloc amount of flash
memory size to the vmalloc area(such as PHYSMAP or PHYSMAP_OF)?
I wondered other devices seems to not allocating(e.g, most NAND flash,
flash on ARM, MIPS and so on). I don't know difference between my
board and other. Doesn't other devices need to allocate to vmalloc?
Thanks,
Mitsutaka
^ permalink raw reply
* Per process DSCR + somefixes (try#3)
From: Alexey Kardashevskiy @ 2011-02-16 5:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
step1: http://patchwork.ozlabs.org/patch/71489/
step2: http://patchwork.ozlabs.org/patch/81423/
In step2 I defined sysfs node as:
static SYSDEV_ATTR(dscr_default, 0600, show_dscr_default,
store_dscr_default);
and it caused problems with rhel6.
Now it is:
static SYSDEV_CLASS_ATTR(dscr_default, 0600, show_dscr_default,
store_dscr_default);
It works now on both 2.6.32 and 2.6.36 but is that correct?
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
[-- Attachment #2: dscr.2.patch --]
[-- Type: text/x-patch, Size: 7077 bytes --]
diff -Nuar ../linus-before-dscr/arch/powerpc//include/asm/emulated_ops.h linus-dscr/arch/powerpc//include/asm/emulated_ops.h
--- ../linus-before-dscr/arch/powerpc//include/asm/emulated_ops.h 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//include/asm/emulated_ops.h 2011-01-04 12:53:50.000000000 +1100
@@ -52,6 +52,10 @@
#ifdef CONFIG_VSX
struct ppc_emulated_entry vsx;
#endif
+#ifdef CONFIG_PPC64
+ struct ppc_emulated_entry mfdscr;
+ struct ppc_emulated_entry mtdscr;
+#endif
} ppc_emulated;
extern u32 ppc_warn_emulated;
diff -Nuar ../linus-before-dscr/arch/powerpc//include/asm/ppc-opcode.h linus-dscr/arch/powerpc//include/asm/ppc-opcode.h
--- ../linus-before-dscr/arch/powerpc//include/asm/ppc-opcode.h 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//include/asm/ppc-opcode.h 2011-01-04 12:53:50.000000000 +1100
@@ -39,6 +39,10 @@
#define PPC_INST_RFCI 0x4c000066
#define PPC_INST_RFDI 0x4c00004e
#define PPC_INST_RFMCI 0x4c00004c
+#define PPC_INST_MFSPR_DSCR 0x7c1102a6
+#define PPC_INST_MFSPR_DSCR_MASK 0xfc1fffff
+#define PPC_INST_MTSPR_DSCR 0x7c1103a6
+#define PPC_INST_MTSPR_DSCR_MASK 0xfc1fffff
#define PPC_INST_STRING 0x7c00042a
#define PPC_INST_STRING_MASK 0xfc0007fe
diff -Nuar ../linus-before-dscr/arch/powerpc//include/asm/processor.h linus-dscr/arch/powerpc//include/asm/processor.h
--- ../linus-before-dscr/arch/powerpc//include/asm/processor.h 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//include/asm/processor.h 2011-02-02 10:36:21.000000000 +1100
@@ -240,6 +240,10 @@
#ifdef CONFIG_KVM_BOOK3S_32_HANDLER
void* kvm_shadow_vcpu; /* KVM internal data */
#endif /* CONFIG_KVM_BOOK3S_32_HANDLER */
+#ifdef CONFIG_PPC64
+ unsigned long dscr;
+ int dscr_inherit;
+#endif
};
#define ARCH_MIN_TASKALIGN 16
diff -Nuar ../linus-before-dscr/arch/powerpc//kernel/asm-offsets.c linus-dscr/arch/powerpc//kernel/asm-offsets.c
--- ../linus-before-dscr/arch/powerpc//kernel/asm-offsets.c 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//kernel/asm-offsets.c 2011-01-04 12:53:50.000000000 +1100
@@ -74,6 +74,7 @@
DEFINE(AUDITCONTEXT, offsetof(struct task_struct, audit_context));
DEFINE(SIGSEGV, SIGSEGV);
DEFINE(NMI_MASK, NMI_MASK);
+ DEFINE(THREAD_DSCR, offsetof(struct thread_struct, dscr));
#else
DEFINE(THREAD_INFO, offsetof(struct task_struct, stack));
#endif /* CONFIG_PPC64 */
diff -Nuar ../linus-before-dscr/arch/powerpc//kernel/entry_64.S linus-dscr/arch/powerpc//kernel/entry_64.S
--- ../linus-before-dscr/arch/powerpc//kernel/entry_64.S 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//kernel/entry_64.S 2011-02-02 06:13:17.000000000 +1100
@@ -421,6 +421,12 @@
std r24,THREAD_VRSAVE(r3)
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
#endif /* CONFIG_ALTIVEC */
+#ifdef CONFIG_PPC64
+BEGIN_FTR_SECTION
+ mfspr r25,SPRN_DSCR
+ std r25,THREAD_DSCR(r3)
+END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
+#endif
and. r0,r0,r22
beq+ 1f
andc r22,r22,r0
@@ -522,6 +528,15 @@
mtspr SPRN_VRSAVE,r0 /* if G4, restore VRSAVE reg */
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
#endif /* CONFIG_ALTIVEC */
+#ifdef CONFIG_PPC64
+BEGIN_FTR_SECTION
+ ld r0,THREAD_DSCR(r4)
+ cmpd r0,r25
+ beq 1f
+ mtspr SPRN_DSCR,r0
+1:
+END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
+#endif
/* r3-r13 are destroyed -- Cort */
REST_8GPRS(14, r1)
diff -Nuar ../linus-before-dscr/arch/powerpc//kernel/process.c linus-dscr/arch/powerpc//kernel/process.c
--- ../linus-before-dscr/arch/powerpc//kernel/process.c 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//kernel/process.c 2011-02-16 16:27:37.000000000 +1100
@@ -700,6 +700,8 @@
/*
* Copy a thread..
*/
+extern unsigned long dscr_default; /* defined in arch/powerpc/kernel/sysfs.c */
+
int copy_thread(unsigned long clone_flags, unsigned long usp,
unsigned long unused, struct task_struct *p,
struct pt_regs *regs)
@@ -767,6 +769,20 @@
p->thread.ksp_vsid = sp_vsid;
}
#endif /* CONFIG_PPC_STD_MMU_64 */
+#ifdef CONFIG_PPC64
+ if (cpu_has_feature(CPU_FTR_DSCR)) {
+ if (current->thread.dscr_inherit) {
+ p->thread.dscr_inherit = 1;
+ p->thread.dscr = current->thread.dscr;
+ } else if (0 != dscr_default) {
+ p->thread.dscr_inherit = 1;
+ p->thread.dscr = dscr_default;
+ } else {
+ p->thread.dscr_inherit = 0;
+ p->thread.dscr = 0;
+ }
+ }
+#endif
/*
* The PPC64 ABI makes use of a TOC to contain function
diff -Nuar ../linus-before-dscr/arch/powerpc//kernel/sysfs.c linus-dscr/arch/powerpc//kernel/sysfs.c
--- ../linus-before-dscr/arch/powerpc//kernel/sysfs.c 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//kernel/sysfs.c 2011-02-16 16:27:58.000000000 +1100
@@ -182,6 +182,41 @@
static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
static SYSDEV_ATTR(dscr, 0600, show_dscr, store_dscr);
static SYSDEV_ATTR(purr, 0600, show_purr, store_purr);
+
+unsigned long dscr_default = 0;
+EXPORT_SYMBOL(dscr_default);
+
+static ssize_t show_dscr_default(struct sysdev_class *class,
+ struct sysdev_class_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%lx\n", dscr_default);
+}
+
+static ssize_t __used store_dscr_default(struct sysdev_class *class,
+ struct sysdev_class_attribute *attr, const char *buf,
+ size_t count)
+{
+ unsigned long val;
+ int ret = 0;
+
+ ret = sscanf(buf, "%lx", &val);
+ if (ret != 1)
+ return -EINVAL;
+ dscr_default = val;
+
+ return count;
+}
+
+static SYSDEV_CLASS_ATTR(dscr_default, 0600,
+ show_dscr_default, store_dscr_default);
+
+static void sysfs_create_dscr_default(void)
+{
+ int err = 0;
+ if (cpu_has_feature(CPU_FTR_DSCR))
+ err = sysfs_create_file(&cpu_sysdev_class.kset.kobj,
+ &attr_dscr_default.attr);
+}
#endif /* CONFIG_PPC64 */
#ifdef HAS_PPC_PMC_PA6T
@@ -617,6 +652,9 @@
if (cpu_online(cpu))
register_cpu_online(cpu);
}
+#ifdef CONFIG_PPC64
+ sysfs_create_dscr_default();
+#endif /* CONFIG_PPC64 */
return 0;
}
diff -Nuar ../linus-before-dscr/arch/powerpc//kernel/traps.c linus-dscr/arch/powerpc//kernel/traps.c
--- ../linus-before-dscr/arch/powerpc//kernel/traps.c 2010-10-27 14:25:45.000000000 +1100
+++ linus-dscr/arch/powerpc//kernel/traps.c 2011-02-16 16:00:18.000000000 +1100
@@ -919,6 +919,26 @@
return emulate_isel(regs, instword);
}
+#ifdef CONFIG_PPC64
+ /* Emulate the mfspr rD, DSCR. */
+ if (((instword & PPC_INST_MFSPR_DSCR_MASK) == PPC_INST_MFSPR_DSCR) &&
+ cpu_has_feature(CPU_FTR_DSCR)) {
+ PPC_WARN_EMULATED(mfdscr, regs);
+ rd = (instword >> 21) & 0x1f;
+ regs->gpr[rd] = mfspr(SPRN_DSCR);
+ return 0;
+ }
+ /* Emulate the mtspr DSCR, rD. */
+ if (((instword & PPC_INST_MTSPR_DSCR_MASK) == PPC_INST_MTSPR_DSCR) &&
+ cpu_has_feature(CPU_FTR_DSCR)) {
+ PPC_WARN_EMULATED(mtdscr, regs);
+ rd = (instword >> 21) & 0x1f;
+ mtspr(SPRN_DSCR, regs->gpr[rd]);
+ current->thread.dscr_inherit = 1;
+ return 0;
+ }
+#endif
+
return -EINVAL;
}
@@ -1516,6 +1536,10 @@
#ifdef CONFIG_VSX
WARN_EMULATED_SETUP(vsx),
#endif
+#ifdef CONFIG_PPC64
+ WARN_EMULATED_SETUP(mfdscr),
+ WARN_EMULATED_SETUP(mtdscr),
+#endif
};
u32 ppc_warn_emulated;
^ permalink raw reply
* Re: [RFC] Inter-processor Mailboxes Drivers
From: Hiroshi DOYU @ 2011-02-16 6:22 UTC (permalink / raw)
To: Hollis_Blanchard
Cc: meador_inge, jamie, linuxppc-dev, openmcapi-dev, linux-arm-kernel
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FAAF0@na3-mail.mgc.mentorg.com>
From: "ext Blanchard, Hollis" <Hollis_Blanchard@mentor.com>
Subject: Re: [RFC] Inter-processor Mailboxes Drivers
Date: Tue, 15 Feb 2011 15:38:25 -0800
> On 02/15/2011 01:58 PM, Meador Inge wrote:
>> On 02/14/2011 04:01 AM, Jamie Iles wrote:
>>> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>>>> 1. Hardware specific bits somewhere under '.../arch/*'. Drivers
>>>> for the MPIC message registers on Power and OMAP4 mailboxes,
>>>> for
>>>> example.
>>>> 2. A higher level driver under '.../drivers/mailbox/*'. That the
>>>> pieces in (1) would register with. This piece would expose the
>>>> main kernel API.
>>>> 3. Userspace interfaces for accessing the mailboxes. A
>>>> '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for example.
>>>
>>> How about using virtio for all of this and having the mailbox as a
>>> notification/message passing driver for the virtio backend? There are
>>> already virtio console and network drivers that could be useful for the
>>> userspace part of it. drivers/virtio/virtio_ring.c might be a good
>>> starting point if you thought there was some mileage in this approach.
>>
>> To be honest, I am not that familiar with 'virtio', but I will take a
>> look. Thanks for the pointer. Maybe Hollis can speak to this idea more.
> My opinion is that virtio is (over?) complicated.
Considering the case of omap mailbox H/W, it is just a simple one way
4 slot x 32bit H/W FIFO, I also may think that this may be a bit too
much...
> I've looked into it in the past, and I'm definitely open to using it if
> somebody can demonstrate how easy it is, but adopting it wouldn't have
> helped OpenMCAPI with our use cases, and would have incurred extra pain,
> so we didn't.
>
> Hollis Blanchard
> Mentor Graphics, Embedded Systems Division
>
^ permalink raw reply
* Re: Question about flash allocation
From: Josh Boyer @ 2011-02-16 11:26 UTC (permalink / raw)
To: Mitsutaka Amano; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimW1yZ+H=X+j=TYMM8-zZx5XaEPczek05KtKKxN@mail.gmail.com>
On Tue, Feb 15, 2011 at 11:28 PM, Mitsutaka Amano
<mitsutaka.amano@gmail.com> wrote:
> Hi,
>
> Why does CFI(or other flash memory) have to alloc amount of flash
> memory size to the vmalloc area(such as PHYSMAP or PHYSMAP_OF)?
> I wondered other devices seems to not allocating(e.g, most NAND flash,
> flash on ARM, MIPS and so on). I don't know difference between my
> board and other. Doesn't other devices need to allocate to vmalloc?
You asked this on the MTD mailing list already:
http://lists.infradead.org/pipermail/linux-mtd/2011-January/033787.html
The answers aren't going to change based on which list you ask.
As for the last question, the memory space for modules are in vmalloc
space, and any HW resources they ioremap are as well. However for
true memory allocations, most device drivers use kmalloc. Some use
vmalloc for large buffers that don't need to be physically contiguous
but there aren't that many.
josh
^ permalink raw reply
* Bug in arch/powerpc/sysdev/fsl_gtm.c
From: Jean-Denis Boyer @ 2011-02-16 14:59 UTC (permalink / raw)
To: 'Anton Vorontsov',
'linuxppc-dev@lists.ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
Hi.
There is a bug in the function gtm_set_ref_timer16.
When called, it correctly sets the requested timer,
but the other timer that shares the register GTCFR is reset.
The parameter 'clear' passed to macro clrsetbits_8 should not be
a bitwise complement, since the macro already complements it.
Here is a patch that should fix this issue.
--- linux-2.6.35.11/arch/powerpc/sysdev/fsl_gtm.c
+++ linux/arch/powerpc/sysdev/fsl_gtm.c
@@ -203,13 +203,10 @@
spin_lock_irqsave(>m->lock, flags);
/*
- * Properly reset timers: stop, reset, set up prescalers, reference
+ * Properly set timers: stop, set up prescalers, reference
* value and clear event register.
*/
- clrsetbits_8(tmr->gtcfr, ~(GTCFR_STP(num) | GTCFR_RST(num)),
- GTCFR_STP(num) | GTCFR_RST(num));
-
- setbits8(tmr->gtcfr, GTCFR_STP(num));
+ setbits8(tmr->gtcfr, GTCFR_STP(num) | GTCFR_RST(num));
if (tmr->gtpsr)
out_be16(tmr->gtpsr, psr);
Regards,
Jean-Denis Boyer, Eng.
Media5 Corporation - Mediatrix, M5T, Media5Boss
4229 Garlock Street, Sherbrooke (Québec), J1L 2C8, CANADA
(819)829-8749 x5241
[-- Attachment #2: fsl_gtm.patch --]
[-- Type: application/octet-stream, Size: 585 bytes --]
--- linux-2.6.35.11/arch/powerpc/sysdev/fsl_gtm.c
+++ linux/arch/powerpc/sysdev/fsl_gtm.c
@@ -203,13 +203,10 @@
spin_lock_irqsave(>m->lock, flags);
/*
- * Properly reset timers: stop, reset, set up prescalers, reference
+ * Properly set timers: stop, set up prescalers, reference
* value and clear event register.
*/
- clrsetbits_8(tmr->gtcfr, ~(GTCFR_STP(num) | GTCFR_RST(num)),
- GTCFR_STP(num) | GTCFR_RST(num));
-
- setbits8(tmr->gtcfr, GTCFR_STP(num));
+ setbits8(tmr->gtcfr, GTCFR_STP(num) | GTCFR_RST(num));
if (tmr->gtpsr)
out_be16(tmr->gtpsr, psr);
^ permalink raw reply
* Using CONFIG_PHYSICAL_START
From: Meador Inge @ 2011-02-16 18:00 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev@lists.ozlabs.org
Hi Kumar,
Quick question about the support for booting at a non-zero base address
(as committed here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=37dd2badcfcec35f5e21a0926968d77a404f03c3).
Is booting from a non-zero address as simple as changing
"CONFIG_PHYSICAL_START" (assuming it meets the alignment constraints, of
course)?
For example, I want to boot from a non-zero address on the P1022DS. I
should just be able to change "CONFIG_PHYSICAL_START" to, say,
0x08000000, and it should work, right? Any other bits that need to be
done (i.e. U-Boot or device tree magic)?
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: Using CONFIG_PHYSICAL_START
From: Scott Wood @ 2011-02-16 19:24 UTC (permalink / raw)
To: Meador Inge; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4D5C10B9.9010702@mentor.com>
On Wed, 16 Feb 2011 12:00:25 -0600
Meador Inge <meador_inge@mentor.com> wrote:
> Hi Kumar,
>
> Quick question about the support for booting at a non-zero base address
> (as committed here:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=37dd2badcfcec35f5e21a0926968d77a404f03c3).
> Is booting from a non-zero address as simple as changing
> "CONFIG_PHYSICAL_START" (assuming it meets the alignment constraints, of
> course)?
Another option is to turn on CONFIG_RELOCATABLE. Note that you'll still
have the same alignment constraints; it doesn't generate a truly relocatable
binary (the effective addresses are fixed). But you don't have to specify
the physical address at compile-time. This allows you to use the same
kernel image for multiple AMP partitions.
> For example, I want to boot from a non-zero address on the P1022DS. I
> should just be able to change "CONFIG_PHYSICAL_START" to, say,
> 0x08000000, and it should work, right? Any other bits that need to be
> done (i.e. U-Boot or device tree magic)?
You'll want the memory node adjusted for your restricted address range
(I'm assuming that this is why you want to start at non-zero, and that
you're not trying to have the kernel be located in the middle of its
partition).
There are some special u-boot variables (bootm_low/bootm_size) that govern
placement of the kernel, fdt, etc.
-Scott
^ permalink raw reply
* Re: Using CONFIG_PHYSICAL_START
From: Meador Inge @ 2011-02-16 20:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110216132403.3466a83e@schlenkerla>
On 02/16/2011 01:24 PM, Scott Wood wrote:
> On Wed, 16 Feb 2011 12:00:25 -0600
> Meador Inge<meador_inge@mentor.com> wrote:
>
>> Hi Kumar,
>>
>> Quick question about the support for booting at a non-zero base address
>> (as committed here:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=37dd2badcfcec35f5e21a0926968d77a404f03c3).
>> Is booting from a non-zero address as simple as changing
>> "CONFIG_PHYSICAL_START" (assuming it meets the alignment constraints, of
>> course)?
>
> Another option is to turn on CONFIG_RELOCATABLE. Note that you'll still
> have the same alignment constraints; it doesn't generate a truly relocatable
> binary (the effective addresses are fixed). But you don't have to specify
> the physical address at compile-time. This allows you to use the same
> kernel image for multiple AMP partitions.
>
>> For example, I want to boot from a non-zero address on the P1022DS. I
>> should just be able to change "CONFIG_PHYSICAL_START" to, say,
>> 0x08000000, and it should work, right? Any other bits that need to be
>> done (i.e. U-Boot or device tree magic)?
>
> You'll want the memory node adjusted for your restricted address range
> (I'm assuming that this is why you want to start at non-zero, and that
> you're not trying to have the kernel be located in the middle of its
> partition).
>
> There are some special u-boot variables (bootm_low/bootm_size) that govern
> placement of the kernel, fdt, etc.
Thanks Scott. I should have looked in the u-boot docs. There are very
clear instructions on how to setup an AMP environment in
'.../doc/README.mpc8572ds'
(http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/README.mpc8572ds;h=06dab596bea52ab8d8c2ba89d86f793cc4881ccb;hb=HEAD).
> -Scott
>
>
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [openmcapi-dev] Re: [RFC] Inter-processor Mailboxes Drivers
From: Blanchard, Hollis @ 2011-02-16 20:22 UTC (permalink / raw)
To: Hiroshi DOYU
Cc: Inge, Meador, jamie, linuxppc-dev, openmcapi-dev,
linux-arm-kernel
In-Reply-To: <20110216.082228.814509512977216497.Hiroshi.DOYU@nokia.com>
On 02/15/2011 10:22 PM, Hiroshi DOYU wrote:
> From: "ext Blanchard, Hollis"<Hollis_Blanchard@mentor.com>
> Subject: Re: [RFC] Inter-processor Mailboxes Drivers
> Date: Tue, 15 Feb 2011 15:38:25 -0800
>
>> On 02/15/2011 01:58 PM, Meador Inge wrote:
>>> On 02/14/2011 04:01 AM, Jamie Iles wrote:
>>>> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>>>>> 1. Hardware specific bits somewhere under '.../arch/*'. =
Drivers
>>>>> for the MPIC message registers on Power and OMAP4 =
mailboxes,
>>>>> for
>>>>> example.
>>>>> 2. A higher level driver under '.../drivers/mailbox/*'. =
That the
>>>>> pieces in (1) would register with. This piece would =
expose the
>>>>> main kernel API.
>>>>> 3. Userspace interfaces for accessing the mailboxes. A
>>>>> '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for =
example.
>>>> How about using virtio for all of this and having the mailbox as a
>>>> notification/message passing driver for the virtio backend? There =
are
>>>> already virtio console and network drivers that could be useful for =
the
>>>> userspace part of it. drivers/virtio/virtio_ring.c might be a good
>>>> starting point if you thought there was some mileage in this =
approach.
>>> To be honest, I am not that familiar with 'virtio', but I will take =
a
>>> look. Thanks for the pointer. Maybe Hollis can speak to this idea =
more.
>> My opinion is that virtio is (over?) complicated.
> Considering the case of omap mailbox H/W, it is just a simple one way
> 4 slot x 32bit H/W FIFO, I also may think that this may be a bit too
> much...
I think the proposal is to implement a virtio link using the OMAP=20
mailboxes as the interrupt mechanism, and shared memory to carry the=20
data and descriptor rings.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [PATCH OF 07/14] of: move of_irq_map_pci() into generic code
From: Grant Likely @ 2011-02-16 21:53 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss, x86,
linux-kernel, sodaville, Sebastian Andrzej Siewior, linuxppc-dev
In-Reply-To: <1295843342-1122-8-git-send-email-bigeasy@linutronix.de>
On Sun, Jan 23, 2011 at 9:28 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
> There is a tiny difference between PPC32 and PPC64. Microblaze uses the
> PPC32 variant.
>
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
I've got this one in my devicetree/next branch which is pulled into
linux-next. I've not received an ack from Ben yet. Michal, is this
okay by you?
http://git.secretlab.ca/?p=3Dlinux-2.6.git;a=3Dcommit;h=3D04bea68b2f0eeebb0=
89ecc67b618795925268b4a
g.
> ---
> =A0arch/microblaze/include/asm/pci-bridge.h | =A0 12 ++++
> =A0arch/microblaze/include/asm/prom.h =A0 =A0 =A0 | =A0 15 -----
> =A0arch/microblaze/kernel/prom_parse.c =A0 =A0 =A0| =A0 77 --------------=
-------------
> =A0arch/microblaze/pci/pci-common.c =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/include/asm/pci-bridge.h =A0 =A0| =A0 10 ++++
> =A0arch/powerpc/include/asm/prom.h =A0 =A0 =A0 =A0 =A0| =A0 15 -----
> =A0arch/powerpc/kernel/pci-common.c =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/kernel/prom_parse.c =A0 =A0 =A0 =A0 | =A0 84 ------------=
------------------
> =A0drivers/of/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =
=A06 ++
> =A0drivers/of/Makefile =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =
=A01 +
> =A0drivers/of/of_pci.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 8=
0 ++++++++++++++++++++++++++++
> =A0include/linux/of_pci.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 20 ++=
+++++
> =A012 files changed, 131 insertions(+), 191 deletions(-)
> =A0create mode 100644 drivers/of/of_pci.c
> =A0create mode 100644 include/linux/of_pci.h
>
> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/i=
nclude/asm/pci-bridge.h
> index 0c68764..c2a40a4 100644
> --- a/arch/microblaze/include/asm/pci-bridge.h
> +++ b/arch/microblaze/include/asm/pci-bridge.h
> @@ -104,11 +104,22 @@ struct pci_controller {
> =A0 =A0 =A0 =A0int global_number; =A0 =A0 =A0/* PCI domain number */
> =A0};
>
> +#ifdef CONFIG_PCI
> =A0static inline struct pci_controller *pci_bus_to_host(const struct pci_=
bus *bus)
> =A0{
> =A0 =A0 =A0 =A0return bus->sysdata;
> =A0}
>
> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus=
)
> +{
> + =A0 =A0 =A0 struct pci_controller *host;
> +
> + =A0 =A0 =A0 if (bus->self)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return pci_device_to_OF_node(bus->self);
> + =A0 =A0 =A0 host =3D pci_bus_to_host(bus);
> + =A0 =A0 =A0 return host ? host->dn : NULL;
> +}
> +
> =A0static inline int isa_vaddr_is_ioport(void __iomem *address)
> =A0{
> =A0 =A0 =A0 =A0/* No specific ISA handling on ppc32 at this stage, it
> @@ -116,6 +127,7 @@ static inline int isa_vaddr_is_ioport(void __iomem *a=
ddress)
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0return 0;
> =A0}
> +#endif
>
> =A0/* These are used for config access before all the PCI probing
> =A0 =A0has been done. */
> diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include=
/asm/prom.h
> index 2e72af0..d0890d3 100644
> --- a/arch/microblaze/include/asm/prom.h
> +++ b/arch/microblaze/include/asm/prom.h
> @@ -64,21 +64,6 @@ extern void kdump_move_device_tree(void);
> =A0/* CPU OF node matching */
> =A0struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
>
> -/**
> - * of_irq_map_pci - Resolve the interrupt for a PCI device
> - * @pdev: =A0 =A0 =A0the device whose interrupt is to be resolved
> - * @out_irq: =A0 structure of_irq filled by this function
> - *
> - * This function resolves the PCI interrupt for a given PCI device. If a
> - * device-node exists for a given pci_dev, it will use normal OF tree
> - * walking. If not, it will implement standard swizzling and walk up the
> - * PCI tree until an device-node is found, at which point it will finish
> - * resolving using the OF tree walking.
> - */
> -struct pci_dev;
> -struct of_irq;
> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> -
> =A0#endif /* __ASSEMBLY__ */
> =A0#endif /* __KERNEL__ */
>
> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel=
/prom_parse.c
> index 9ae24f4..47187cc 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -2,88 +2,11 @@
>
> =A0#include <linux/kernel.h>
> =A0#include <linux/string.h>
> -#include <linux/pci_regs.h>
> =A0#include <linux/module.h>
> =A0#include <linux/ioport.h>
> =A0#include <linux/etherdevice.h>
> =A0#include <linux/of_address.h>
> =A0#include <asm/prom.h>
> -#include <asm/pci-bridge.h>
> -
> -#ifdef CONFIG_PCI
> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
> -{
> - =A0 =A0 =A0 struct device_node *dn, *ppnode;
> - =A0 =A0 =A0 struct pci_dev *ppdev;
> - =A0 =A0 =A0 u32 lspec;
> - =A0 =A0 =A0 u32 laddr[3];
> - =A0 =A0 =A0 u8 pin;
> - =A0 =A0 =A0 int rc;
> -
> - =A0 =A0 =A0 /* Check if we have a device node, if yes, fallback to stan=
dard OF
> - =A0 =A0 =A0 =A0* parsing
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 dn =3D pci_device_to_OF_node(pdev);
> - =A0 =A0 =A0 if (dn)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return of_irq_map_one(dn, 0, out_irq);
> -
> - =A0 =A0 =A0 /* Ok, we don't, time to have fun. Let's start by building =
up an
> - =A0 =A0 =A0 =A0* interrupt spec. =A0we assume #interrupt-cells is 1, wh=
ich is standard
> - =A0 =A0 =A0 =A0* for PCI. If you do different, then don't use that rout=
ine.
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 rc =3D pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> - =A0 =A0 =A0 if (rc !=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> - =A0 =A0 =A0 /* No pin, exit */
> - =A0 =A0 =A0 if (pin =3D=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> -
> - =A0 =A0 =A0 /* Now we walk up the PCI tree */
> - =A0 =A0 =A0 lspec =3D pin;
> - =A0 =A0 =A0 for (;;) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Get the pci_dev of our parent */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppdev =3D pdev->bus->self;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ouch, it's a host bridge... */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppdev =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pci_controller *host=
;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host =3D pci_bus_to_host(pd=
ev->bus);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D host ? host->dn =
: NULL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* No node for host bridge =
? give up */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode =3D=3D NULL)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EIN=
VAL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We found a P2P bridge, c=
heck if it has a node */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_device_to_OF=
_node(ppdev);
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ok, we have found a parent with a device=
-node, hand over to
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the OF parsing code.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We build a unit address from the linux=
device to be used for
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* resolution. Note that we use the linux=
bus number which may
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* not match your firmware bus numbering.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fortunately, in most cases, interrupt-=
map-mask doesn't
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* include the bus number as part of the =
matching.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* You should still be careful about that=
though if you intend
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to rely on this function (you ship =A0=
a firmware that doesn't
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* create device nodes for all PCI device=
s).
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We can only get here if we hit a P2P bri=
dge with no node,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* let's do standard swizzling and try ag=
ain
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 lspec =3D pci_swizzle_interrupt_pin(pdev, l=
spec);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdev =3D ppdev;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 laddr[0] =3D (pdev->bus->number << 16)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (pdev->devfn << 8);
> - =A0 =A0 =A0 laddr[1] =A0=3D laddr[2] =3D 0;
> - =A0 =A0 =A0 return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
> -}
> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
> -#endif /* CONFIG_PCI */
>
> =A0void of_parse_dma_window(struct device_node *dn, const void *dma_windo=
w_prop,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *busno, unsigned long *phys,=
unsigned long *size)
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-c=
ommon.c
> index e363615..1e01a12 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -29,6 +29,7 @@
> =A0#include <linux/slab.h>
> =A0#include <linux/of.h>
> =A0#include <linux/of_address.h>
> +#include <linux/of_pci.h>
>
> =A0#include <asm/processor.h>
> =A0#include <asm/io.h>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include=
/asm/pci-bridge.h
> index 51e9e6f..edeb80f 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -171,6 +171,16 @@ static inline struct pci_controller *pci_bus_to_host=
(const struct pci_bus *bus)
> =A0 =A0 =A0 =A0return bus->sysdata;
> =A0}
>
> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus=
)
> +{
> + =A0 =A0 =A0 struct pci_controller *host;
> +
> + =A0 =A0 =A0 if (bus->self)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return pci_device_to_OF_node(bus->self);
> + =A0 =A0 =A0 host =3D pci_bus_to_host(bus);
> + =A0 =A0 =A0 return host ? host->dn : NULL;
> +}
> +
> =A0static inline int isa_vaddr_is_ioport(void __iomem *address)
> =A0{
> =A0 =A0 =A0 =A0/* No specific ISA handling on ppc32 at this stage, it
> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/p=
rom.h
> index d727575..c189aa5 100644
> --- a/arch/powerpc/include/asm/prom.h
> +++ b/arch/powerpc/include/asm/prom.h
> @@ -70,21 +70,6 @@ static inline int of_node_to_nid(struct device_node *d=
evice) { return 0; }
> =A0#endif
> =A0#define of_node_to_nid of_node_to_nid
>
> -/**
> - * of_irq_map_pci - Resolve the interrupt for a PCI device
> - * @pdev: =A0 =A0 =A0the device whose interrupt is to be resolved
> - * @out_irq: =A0 structure of_irq filled by this function
> - *
> - * This function resolves the PCI interrupt for a given PCI device. If a
> - * device-node exists for a given pci_dev, it will use normal OF tree
> - * walking. If not, it will implement standard swizzling and walk up the
> - * PCI tree until an device-node is found, at which point it will finish
> - * resolving using the OF tree walking.
> - */
> -struct pci_dev;
> -struct of_irq;
> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> -
> =A0extern void of_instantiate_rtc(void);
>
> =A0/* These includes are put at the bottom because they may contain thing=
s
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-c=
ommon.c
> index 10a44e6..eb341be 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -22,6 +22,7 @@
> =A0#include <linux/init.h>
> =A0#include <linux/bootmem.h>
> =A0#include <linux/of_address.h>
> +#include <linux/of_pci.h>
> =A0#include <linux/mm.h>
> =A0#include <linux/list.h>
> =A0#include <linux/syscalls.h>
> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_=
parse.c
> index c2b7a07..47187cc 100644
> --- a/arch/powerpc/kernel/prom_parse.c
> +++ b/arch/powerpc/kernel/prom_parse.c
> @@ -2,95 +2,11 @@
>
> =A0#include <linux/kernel.h>
> =A0#include <linux/string.h>
> -#include <linux/pci_regs.h>
> =A0#include <linux/module.h>
> =A0#include <linux/ioport.h>
> =A0#include <linux/etherdevice.h>
> =A0#include <linux/of_address.h>
> =A0#include <asm/prom.h>
> -#include <asm/pci-bridge.h>
> -
> -#ifdef CONFIG_PCI
> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
> -{
> - =A0 =A0 =A0 struct device_node *dn, *ppnode;
> - =A0 =A0 =A0 struct pci_dev *ppdev;
> - =A0 =A0 =A0 u32 lspec;
> - =A0 =A0 =A0 u32 laddr[3];
> - =A0 =A0 =A0 u8 pin;
> - =A0 =A0 =A0 int rc;
> -
> - =A0 =A0 =A0 /* Check if we have a device node, if yes, fallback to stan=
dard OF
> - =A0 =A0 =A0 =A0* parsing
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 dn =3D pci_device_to_OF_node(pdev);
> - =A0 =A0 =A0 if (dn) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D of_irq_map_one(dn, 0, out_irq);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!rc)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 /* Ok, we don't, time to have fun. Let's start by building =
up an
> - =A0 =A0 =A0 =A0* interrupt spec. =A0we assume #interrupt-cells is 1, wh=
ich is standard
> - =A0 =A0 =A0 =A0* for PCI. If you do different, then don't use that rout=
ine.
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 rc =3D pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> - =A0 =A0 =A0 if (rc !=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> - =A0 =A0 =A0 /* No pin, exit */
> - =A0 =A0 =A0 if (pin =3D=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> -
> - =A0 =A0 =A0 /* Now we walk up the PCI tree */
> - =A0 =A0 =A0 lspec =3D pin;
> - =A0 =A0 =A0 for (;;) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Get the pci_dev of our parent */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppdev =3D pdev->bus->self;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ouch, it's a host bridge... */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppdev =3D=3D NULL) {
> -#ifdef CONFIG_PPC64
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_bus_to_OF_no=
de(pdev->bus);
> -#else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pci_controller *host=
;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host =3D pci_bus_to_host(pd=
ev->bus);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D host ? host->dn =
: NULL;
> -#endif
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* No node for host bridge =
? give up */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode =3D=3D NULL)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EIN=
VAL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We found a P2P bridge, c=
heck if it has a node */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_device_to_OF=
_node(ppdev);
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ok, we have found a parent with a device=
-node, hand over to
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the OF parsing code.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We build a unit address from the linux=
device to be used for
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* resolution. Note that we use the linux=
bus number which may
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* not match your firmware bus numbering.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fortunately, in most cases, interrupt-=
map-mask doesn't include
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the bus number as part of the matching=
.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* You should still be careful about that=
though if you intend
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to rely on this function (you ship =A0=
a firmware that doesn't
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* create device nodes for all PCI device=
s).
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We can only get here if we hit a P2P bri=
dge with no node,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* let's do standard swizzling and try ag=
ain
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 lspec =3D pci_swizzle_interrupt_pin(pdev, l=
spec);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdev =3D ppdev;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 laddr[0] =3D (pdev->bus->number << 16)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (pdev->devfn << 8);
> - =A0 =A0 =A0 laddr[1] =A0=3D laddr[2] =3D 0;
> - =A0 =A0 =A0 return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
> -}
> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
> -#endif /* CONFIG_PCI */
>
> =A0void of_parse_dma_window(struct device_node *dn, const void *dma_windo=
w_prop,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *busno, unsigned long *phys,=
unsigned long *size)
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 3c6e100..c71cff1 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -69,4 +69,10 @@ config OF_MDIO
> =A0 =A0 =A0 =A0help
> =A0 =A0 =A0 =A0 =A0OpenFirmware MDIO bus (Ethernet PHY) accessors
>
> +config OF_PCI
> + =A0 =A0 =A0 def_tristate PCI
> + =A0 =A0 =A0 depends on PCI && !SPARC
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 OpenFirmware PCI bus accessors
> +
> =A0endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 3ab21a0..f7861ed 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_I2C) =A0 =A0+=3D of_i2c.o
> =A0obj-$(CONFIG_OF_NET) =A0 +=3D of_net.o
> =A0obj-$(CONFIG_OF_SPI) =A0 +=3D of_spi.o
> =A0obj-$(CONFIG_OF_MDIO) =A0+=3D of_mdio.o
> +obj-$(CONFIG_OF_PCI) =A0 +=3D of_pci.o
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> new file mode 100644
> index 0000000..dd862d2
> --- /dev/null
> +++ b/drivers/of/of_pci.c
> @@ -0,0 +1,80 @@
> +#include <linux/kernel.h>
> +#include <linux/of_pci.h>
> +#include <asm/prom.h>
> +
> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
> +{
> + =A0 =A0 =A0 struct device_node *dn, *ppnode;
> + =A0 =A0 =A0 struct pci_dev *ppdev;
> + =A0 =A0 =A0 u32 lspec;
> + =A0 =A0 =A0 __be32 lspec_be;
> + =A0 =A0 =A0 __be32 laddr[3];
> + =A0 =A0 =A0 u8 pin;
> + =A0 =A0 =A0 int rc;
> +
> + =A0 =A0 =A0 /* Check if we have a device node, if yes, fallback to stan=
dard OF
> + =A0 =A0 =A0 =A0* parsing
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 dn =3D pci_device_to_OF_node(pdev);
> + =A0 =A0 =A0 if (dn) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D of_irq_map_one(dn, 0, out_irq);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!rc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* Ok, we don't, time to have fun. Let's start by building =
up an
> + =A0 =A0 =A0 =A0* interrupt spec. =A0we assume #interrupt-cells is 1, wh=
ich is standard
> + =A0 =A0 =A0 =A0* for PCI. If you do different, then don't use that rout=
ine.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 rc =3D pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> + =A0 =A0 =A0 if (rc !=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> + =A0 =A0 =A0 /* No pin, exit */
> + =A0 =A0 =A0 if (pin =3D=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> +
> + =A0 =A0 =A0 /* Now we walk up the PCI tree */
> + =A0 =A0 =A0 lspec =3D pin;
> + =A0 =A0 =A0 for (;;) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Get the pci_dev of our parent */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppdev =3D pdev->bus->self;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ouch, it's a host bridge... */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppdev =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_bus_to_OF_no=
de(pdev->bus);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* No node for host bridge =
? give up */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EIN=
VAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We found a P2P bridge, c=
heck if it has a node */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_device_to_OF=
_node(ppdev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ok, we have found a parent with a device=
-node, hand over to
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the OF parsing code.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We build a unit address from the linux=
device to be used for
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* resolution. Note that we use the linux=
bus number which may
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* not match your firmware bus numbering.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fortunately, in most cases, interrupt-=
map-mask doesn't
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* include the bus number as part of the =
matching.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* You should still be careful about that=
though if you intend
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to rely on this function (you ship =A0=
a firmware that doesn't
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* create device nodes for all PCI device=
s).
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We can only get here if we hit a P2P bri=
dge with no node,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* let's do standard swizzling and try ag=
ain
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 lspec =3D pci_swizzle_interrupt_pin(pdev, l=
spec);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdev =3D ppdev;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 lspec_be =3D cpu_to_be32(lspec);
> + =A0 =A0 =A0 laddr[0] =3D cpu_to_be32((pdev->bus->number << 16) | (pdev-=
>devfn << 8));
> + =A0 =A0 =A0 laddr[1] =A0=3D laddr[2] =3D cpu_to_be32(0);
> + =A0 =A0 =A0 return of_irq_map_raw(ppnode, &lspec_be, 1, laddr, out_irq)=
;
> +}
> +EXPORT_SYMBOL_GPL(of_irq_map_pci);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> new file mode 100644
> index 0000000..9b0ba67
> --- /dev/null
> +++ b/include/linux/of_pci.h
> @@ -0,0 +1,20 @@
> +#ifndef __OF_PCI_H
> +#define __OF_PCI_H
> +
> +#include <linux/pci.h>
> +
> +/**
> + * of_irq_map_pci - Resolve the interrupt for a PCI device
> + * @pdev: =A0 =A0 =A0 the device whose interrupt is to be resolved
> + * @out_irq: =A0 =A0structure of_irq filled by this function
> + *
> + * This function resolves the PCI interrupt for a given PCI device. If a
> + * device-node exists for a given pci_dev, it will use normal OF tree
> + * walking. If not, it will implement standard swizzling and walk up the
> + * PCI tree until an device-node is found, at which point it will finish
> + * resolving using the OF tree walking.
> + */
> +struct pci_dev;
> +struct of_irq;
> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> +#endif
> --
> 1.7.3.2
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] Inter-processor Mailboxes Drivers
From: Linus Walleij @ 2011-02-16 21:54 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: Inge, Meador, openmcapi-dev, Hiroshi DOYU, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FAADB@na3-mail.mgc.mentorg.com>
2011/2/15 Blanchard, Hollis <Hollis_Blanchard@mentor.com>:
> OpenMCAPI (http://openmcapi.org) implements the MCAPI specification,
> which is a simple application-level communication API that uses shared
> memory. The API could be layered over any protocol, but was more or less
> designed for simple shared-memory systems, e.g. fixed topology, no
> retransmission, etc.
Cool...
> Currently, we implement almost all of this as a shared library, plus a
> very small kernel driver. The only requirements on the kernel are to
> allow userspace to map the shared memory area, and provide an IPI
> mechanism (and allow the process to sleep while waiting). Applications
> sync with each other using normal atomic memory operations.
Can't this real small kernel driver take care of the mailbox
business as well?
It seems a bit backward if you have say /dev/mcapi0, /dev/mcapi1
etc (or however you expose this to userspace) and /dev/mailbox0
/dev/mailbox1 etc on top of that. One device node per communication
channel instead of this would certainly be nicer? Then you would
have some ioctl() on the /dev/mcapi0 etc node to trigger the
transport and need not worry that it's a mailbox doing the sync.
What I'm after is that whatever datapath you have should include
the control mechanism, now it's like you're opening two interfaces
into the kernel, one for mapping in data pages, one for synchronizing
the transfers, or am I getting things wrong?
I think nominally all mailbox users would be in-kernel like the
MCAPI driver, so they don't need a userspace interface, to me
it feels like say /dev/mutex0, /dev/mutex1 for some other
shared memory opening into the kernel (such as the framebuffer),
and that would look a bit funny.
> I'll add that we haven't done serious optimization yet, but the numbers
> we do have seem reasonable. What are the "efficiency" issues you're
> worried about?
For huge data flows I think you may get into trouble, needing things
like queueing, descriptor pools etc. But if you're convinced this will
work, do go ahead.
Linus Walleij
^ permalink raw reply
* Re: [PATCH OF 07/14] of: move of_irq_map_pci() into generic code
From: Michal Simek @ 2011-02-17 7:49 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss, x86,
linux-kernel, sodaville, Sebastian Andrzej Siewior, linuxppc-dev,
Sebastian Andrzej Siewior
In-Reply-To: <AANLkTimE=mB_yWsOeD3zw+b4cHFx591h-605tK4yWAJr@mail.gmail.com>
Grant Likely wrote:
> On Sun, Jan 23, 2011 at 9:28 PM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>>
>> There is a tiny difference between PPC32 and PPC64. Microblaze uses the
>> PPC32 variant.
>>
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
> I've got this one in my devicetree/next branch which is pulled into
> linux-next. I've not received an ack from Ben yet. Michal, is this
> okay by you?
yep. No problem. I don't have pci hw for testing but compilation is fine.
If you like:
Acked-by: Michal Simek <monstr@monstr.eu>
Thanks,
Michal
>
> http://git.secretlab.ca/?p=linux-2.6.git;a=commit;h=04bea68b2f0eeebb089ecc67b618795925268b4a
>
> g.
>
>> ---
>> arch/microblaze/include/asm/pci-bridge.h | 12 ++++
>> arch/microblaze/include/asm/prom.h | 15 -----
>> arch/microblaze/kernel/prom_parse.c | 77 ---------------------------
>> arch/microblaze/pci/pci-common.c | 1 +
>> arch/powerpc/include/asm/pci-bridge.h | 10 ++++
>> arch/powerpc/include/asm/prom.h | 15 -----
>> arch/powerpc/kernel/pci-common.c | 1 +
>> arch/powerpc/kernel/prom_parse.c | 84 ------------------------------
>> drivers/of/Kconfig | 6 ++
>> drivers/of/Makefile | 1 +
>> drivers/of/of_pci.c | 80 ++++++++++++++++++++++++++++
>> include/linux/of_pci.h | 20 +++++++
>> 12 files changed, 131 insertions(+), 191 deletions(-)
>> create mode 100644 drivers/of/of_pci.c
>> create mode 100644 include/linux/of_pci.h
>>
>> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
>> index 0c68764..c2a40a4 100644
>> --- a/arch/microblaze/include/asm/pci-bridge.h
>> +++ b/arch/microblaze/include/asm/pci-bridge.h
>> @@ -104,11 +104,22 @@ struct pci_controller {
>> int global_number; /* PCI domain number */
>> };
>>
>> +#ifdef CONFIG_PCI
>> static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
>> {
>> return bus->sysdata;
>> }
>>
>> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
>> +{
>> + struct pci_controller *host;
>> +
>> + if (bus->self)
>> + return pci_device_to_OF_node(bus->self);
>> + host = pci_bus_to_host(bus);
>> + return host ? host->dn : NULL;
>> +}
>> +
>> static inline int isa_vaddr_is_ioport(void __iomem *address)
>> {
>> /* No specific ISA handling on ppc32 at this stage, it
>> @@ -116,6 +127,7 @@ static inline int isa_vaddr_is_ioport(void __iomem *address)
>> */
>> return 0;
>> }
>> +#endif
>>
>> /* These are used for config access before all the PCI probing
>> has been done. */
>> diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h
>> index 2e72af0..d0890d3 100644
>> --- a/arch/microblaze/include/asm/prom.h
>> +++ b/arch/microblaze/include/asm/prom.h
>> @@ -64,21 +64,6 @@ extern void kdump_move_device_tree(void);
>> /* CPU OF node matching */
>> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
>>
>> -/**
>> - * of_irq_map_pci - Resolve the interrupt for a PCI device
>> - * @pdev: the device whose interrupt is to be resolved
>> - * @out_irq: structure of_irq filled by this function
>> - *
>> - * This function resolves the PCI interrupt for a given PCI device. If a
>> - * device-node exists for a given pci_dev, it will use normal OF tree
>> - * walking. If not, it will implement standard swizzling and walk up the
>> - * PCI tree until an device-node is found, at which point it will finish
>> - * resolving using the OF tree walking.
>> - */
>> -struct pci_dev;
>> -struct of_irq;
>> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
>> -
>> #endif /* __ASSEMBLY__ */
>> #endif /* __KERNEL__ */
>>
>> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel/prom_parse.c
>> index 9ae24f4..47187cc 100644
>> --- a/arch/microblaze/kernel/prom_parse.c
>> +++ b/arch/microblaze/kernel/prom_parse.c
>> @@ -2,88 +2,11 @@
>>
>> #include <linux/kernel.h>
>> #include <linux/string.h>
>> -#include <linux/pci_regs.h>
>> #include <linux/module.h>
>> #include <linux/ioport.h>
>> #include <linux/etherdevice.h>
>> #include <linux/of_address.h>
>> #include <asm/prom.h>
>> -#include <asm/pci-bridge.h>
>> -
>> -#ifdef CONFIG_PCI
>> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
>> -{
>> - struct device_node *dn, *ppnode;
>> - struct pci_dev *ppdev;
>> - u32 lspec;
>> - u32 laddr[3];
>> - u8 pin;
>> - int rc;
>> -
>> - /* Check if we have a device node, if yes, fallback to standard OF
>> - * parsing
>> - */
>> - dn = pci_device_to_OF_node(pdev);
>> - if (dn)
>> - return of_irq_map_one(dn, 0, out_irq);
>> -
>> - /* Ok, we don't, time to have fun. Let's start by building up an
>> - * interrupt spec. we assume #interrupt-cells is 1, which is standard
>> - * for PCI. If you do different, then don't use that routine.
>> - */
>> - rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>> - if (rc != 0)
>> - return rc;
>> - /* No pin, exit */
>> - if (pin == 0)
>> - return -ENODEV;
>> -
>> - /* Now we walk up the PCI tree */
>> - lspec = pin;
>> - for (;;) {
>> - /* Get the pci_dev of our parent */
>> - ppdev = pdev->bus->self;
>> -
>> - /* Ouch, it's a host bridge... */
>> - if (ppdev == NULL) {
>> - struct pci_controller *host;
>> - host = pci_bus_to_host(pdev->bus);
>> - ppnode = host ? host->dn : NULL;
>> - /* No node for host bridge ? give up */
>> - if (ppnode == NULL)
>> - return -EINVAL;
>> - } else
>> - /* We found a P2P bridge, check if it has a node */
>> - ppnode = pci_device_to_OF_node(ppdev);
>> -
>> - /* Ok, we have found a parent with a device-node, hand over to
>> - * the OF parsing code.
>> - * We build a unit address from the linux device to be used for
>> - * resolution. Note that we use the linux bus number which may
>> - * not match your firmware bus numbering.
>> - * Fortunately, in most cases, interrupt-map-mask doesn't
>> - * include the bus number as part of the matching.
>> - * You should still be careful about that though if you intend
>> - * to rely on this function (you ship a firmware that doesn't
>> - * create device nodes for all PCI devices).
>> - */
>> - if (ppnode)
>> - break;
>> -
>> - /* We can only get here if we hit a P2P bridge with no node,
>> - * let's do standard swizzling and try again
>> - */
>> - lspec = pci_swizzle_interrupt_pin(pdev, lspec);
>> - pdev = ppdev;
>> - }
>> -
>> - laddr[0] = (pdev->bus->number << 16)
>> - | (pdev->devfn << 8);
>> - laddr[1] = laddr[2] = 0;
>> - return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
>> -}
>> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
>> -#endif /* CONFIG_PCI */
>>
>> void of_parse_dma_window(struct device_node *dn, const void *dma_window_prop,
>> unsigned long *busno, unsigned long *phys, unsigned long *size)
>> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
>> index e363615..1e01a12 100644
>> --- a/arch/microblaze/pci/pci-common.c
>> +++ b/arch/microblaze/pci/pci-common.c
>> @@ -29,6 +29,7 @@
>> #include <linux/slab.h>
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>> +#include <linux/of_pci.h>
>>
>> #include <asm/processor.h>
>> #include <asm/io.h>
>> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
>> index 51e9e6f..edeb80f 100644
>> --- a/arch/powerpc/include/asm/pci-bridge.h
>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>> @@ -171,6 +171,16 @@ static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
>> return bus->sysdata;
>> }
>>
>> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
>> +{
>> + struct pci_controller *host;
>> +
>> + if (bus->self)
>> + return pci_device_to_OF_node(bus->self);
>> + host = pci_bus_to_host(bus);
>> + return host ? host->dn : NULL;
>> +}
>> +
>> static inline int isa_vaddr_is_ioport(void __iomem *address)
>> {
>> /* No specific ISA handling on ppc32 at this stage, it
>> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
>> index d727575..c189aa5 100644
>> --- a/arch/powerpc/include/asm/prom.h
>> +++ b/arch/powerpc/include/asm/prom.h
>> @@ -70,21 +70,6 @@ static inline int of_node_to_nid(struct device_node *device) { return 0; }
>> #endif
>> #define of_node_to_nid of_node_to_nid
>>
>> -/**
>> - * of_irq_map_pci - Resolve the interrupt for a PCI device
>> - * @pdev: the device whose interrupt is to be resolved
>> - * @out_irq: structure of_irq filled by this function
>> - *
>> - * This function resolves the PCI interrupt for a given PCI device. If a
>> - * device-node exists for a given pci_dev, it will use normal OF tree
>> - * walking. If not, it will implement standard swizzling and walk up the
>> - * PCI tree until an device-node is found, at which point it will finish
>> - * resolving using the OF tree walking.
>> - */
>> -struct pci_dev;
>> -struct of_irq;
>> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
>> -
>> extern void of_instantiate_rtc(void);
>>
>> /* These includes are put at the bottom because they may contain things
>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>> index 10a44e6..eb341be 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -22,6 +22,7 @@
>> #include <linux/init.h>
>> #include <linux/bootmem.h>
>> #include <linux/of_address.h>
>> +#include <linux/of_pci.h>
>> #include <linux/mm.h>
>> #include <linux/list.h>
>> #include <linux/syscalls.h>
>> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
>> index c2b7a07..47187cc 100644
>> --- a/arch/powerpc/kernel/prom_parse.c
>> +++ b/arch/powerpc/kernel/prom_parse.c
>> @@ -2,95 +2,11 @@
>>
>> #include <linux/kernel.h>
>> #include <linux/string.h>
>> -#include <linux/pci_regs.h>
>> #include <linux/module.h>
>> #include <linux/ioport.h>
>> #include <linux/etherdevice.h>
>> #include <linux/of_address.h>
>> #include <asm/prom.h>
>> -#include <asm/pci-bridge.h>
>> -
>> -#ifdef CONFIG_PCI
>> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
>> -{
>> - struct device_node *dn, *ppnode;
>> - struct pci_dev *ppdev;
>> - u32 lspec;
>> - u32 laddr[3];
>> - u8 pin;
>> - int rc;
>> -
>> - /* Check if we have a device node, if yes, fallback to standard OF
>> - * parsing
>> - */
>> - dn = pci_device_to_OF_node(pdev);
>> - if (dn) {
>> - rc = of_irq_map_one(dn, 0, out_irq);
>> - if (!rc)
>> - return rc;
>> - }
>> -
>> - /* Ok, we don't, time to have fun. Let's start by building up an
>> - * interrupt spec. we assume #interrupt-cells is 1, which is standard
>> - * for PCI. If you do different, then don't use that routine.
>> - */
>> - rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>> - if (rc != 0)
>> - return rc;
>> - /* No pin, exit */
>> - if (pin == 0)
>> - return -ENODEV;
>> -
>> - /* Now we walk up the PCI tree */
>> - lspec = pin;
>> - for (;;) {
>> - /* Get the pci_dev of our parent */
>> - ppdev = pdev->bus->self;
>> -
>> - /* Ouch, it's a host bridge... */
>> - if (ppdev == NULL) {
>> -#ifdef CONFIG_PPC64
>> - ppnode = pci_bus_to_OF_node(pdev->bus);
>> -#else
>> - struct pci_controller *host;
>> - host = pci_bus_to_host(pdev->bus);
>> - ppnode = host ? host->dn : NULL;
>> -#endif
>> - /* No node for host bridge ? give up */
>> - if (ppnode == NULL)
>> - return -EINVAL;
>> - } else
>> - /* We found a P2P bridge, check if it has a node */
>> - ppnode = pci_device_to_OF_node(ppdev);
>> -
>> - /* Ok, we have found a parent with a device-node, hand over to
>> - * the OF parsing code.
>> - * We build a unit address from the linux device to be used for
>> - * resolution. Note that we use the linux bus number which may
>> - * not match your firmware bus numbering.
>> - * Fortunately, in most cases, interrupt-map-mask doesn't include
>> - * the bus number as part of the matching.
>> - * You should still be careful about that though if you intend
>> - * to rely on this function (you ship a firmware that doesn't
>> - * create device nodes for all PCI devices).
>> - */
>> - if (ppnode)
>> - break;
>> -
>> - /* We can only get here if we hit a P2P bridge with no node,
>> - * let's do standard swizzling and try again
>> - */
>> - lspec = pci_swizzle_interrupt_pin(pdev, lspec);
>> - pdev = ppdev;
>> - }
>> -
>> - laddr[0] = (pdev->bus->number << 16)
>> - | (pdev->devfn << 8);
>> - laddr[1] = laddr[2] = 0;
>> - return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
>> -}
>> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
>> -#endif /* CONFIG_PCI */
>>
>> void of_parse_dma_window(struct device_node *dn, const void *dma_window_prop,
>> unsigned long *busno, unsigned long *phys, unsigned long *size)
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index 3c6e100..c71cff1 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -69,4 +69,10 @@ config OF_MDIO
>> help
>> OpenFirmware MDIO bus (Ethernet PHY) accessors
>>
>> +config OF_PCI
>> + def_tristate PCI
>> + depends on PCI && !SPARC
>> + help
>> + OpenFirmware PCI bus accessors
>> +
>> endmenu # OF
>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>> index 3ab21a0..f7861ed 100644
>> --- a/drivers/of/Makefile
>> +++ b/drivers/of/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_I2C) += of_i2c.o
>> obj-$(CONFIG_OF_NET) += of_net.o
>> obj-$(CONFIG_OF_SPI) += of_spi.o
>> obj-$(CONFIG_OF_MDIO) += of_mdio.o
>> +obj-$(CONFIG_OF_PCI) += of_pci.o
>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>> new file mode 100644
>> index 0000000..dd862d2
>> --- /dev/null
>> +++ b/drivers/of/of_pci.c
>> @@ -0,0 +1,80 @@
>> +#include <linux/kernel.h>
>> +#include <linux/of_pci.h>
>> +#include <asm/prom.h>
>> +
>> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
>> +{
>> + struct device_node *dn, *ppnode;
>> + struct pci_dev *ppdev;
>> + u32 lspec;
>> + __be32 lspec_be;
>> + __be32 laddr[3];
>> + u8 pin;
>> + int rc;
>> +
>> + /* Check if we have a device node, if yes, fallback to standard OF
>> + * parsing
>> + */
>> + dn = pci_device_to_OF_node(pdev);
>> + if (dn) {
>> + rc = of_irq_map_one(dn, 0, out_irq);
>> + if (!rc)
>> + return rc;
>> + }
>> +
>> + /* Ok, we don't, time to have fun. Let's start by building up an
>> + * interrupt spec. we assume #interrupt-cells is 1, which is standard
>> + * for PCI. If you do different, then don't use that routine.
>> + */
>> + rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>> + if (rc != 0)
>> + return rc;
>> + /* No pin, exit */
>> + if (pin == 0)
>> + return -ENODEV;
>> +
>> + /* Now we walk up the PCI tree */
>> + lspec = pin;
>> + for (;;) {
>> + /* Get the pci_dev of our parent */
>> + ppdev = pdev->bus->self;
>> +
>> + /* Ouch, it's a host bridge... */
>> + if (ppdev == NULL) {
>> + ppnode = pci_bus_to_OF_node(pdev->bus);
>> +
>> + /* No node for host bridge ? give up */
>> + if (ppnode == NULL)
>> + return -EINVAL;
>> + } else {
>> + /* We found a P2P bridge, check if it has a node */
>> + ppnode = pci_device_to_OF_node(ppdev);
>> + }
>> +
>> + /* Ok, we have found a parent with a device-node, hand over to
>> + * the OF parsing code.
>> + * We build a unit address from the linux device to be used for
>> + * resolution. Note that we use the linux bus number which may
>> + * not match your firmware bus numbering.
>> + * Fortunately, in most cases, interrupt-map-mask doesn't
>> + * include the bus number as part of the matching.
>> + * You should still be careful about that though if you intend
>> + * to rely on this function (you ship a firmware that doesn't
>> + * create device nodes for all PCI devices).
>> + */
>> + if (ppnode)
>> + break;
>> +
>> + /* We can only get here if we hit a P2P bridge with no node,
>> + * let's do standard swizzling and try again
>> + */
>> + lspec = pci_swizzle_interrupt_pin(pdev, lspec);
>> + pdev = ppdev;
>> + }
>> +
>> + lspec_be = cpu_to_be32(lspec);
>> + laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
>> + laddr[1] = laddr[2] = cpu_to_be32(0);
>> + return of_irq_map_raw(ppnode, &lspec_be, 1, laddr, out_irq);
>> +}
>> +EXPORT_SYMBOL_GPL(of_irq_map_pci);
>> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
>> new file mode 100644
>> index 0000000..9b0ba67
>> --- /dev/null
>> +++ b/include/linux/of_pci.h
>> @@ -0,0 +1,20 @@
>> +#ifndef __OF_PCI_H
>> +#define __OF_PCI_H
>> +
>> +#include <linux/pci.h>
>> +
>> +/**
>> + * of_irq_map_pci - Resolve the interrupt for a PCI device
>> + * @pdev: the device whose interrupt is to be resolved
>> + * @out_irq: structure of_irq filled by this function
>> + *
>> + * This function resolves the PCI interrupt for a given PCI device. If a
>> + * device-node exists for a given pci_dev, it will use normal OF tree
>> + * walking. If not, it will implement standard swizzling and walk up the
>> + * PCI tree until an device-node is found, at which point it will finish
>> + * resolving using the OF tree walking.
>> + */
>> +struct pci_dev;
>> +struct of_irq;
>> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
>> +#endif
>> --
>> 1.7.3.2
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>
>
>
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-17 20:17 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: Text/Plain, Size: 831 bytes --]
Hello!
About two years ago Johannes Berg wrote support for the PowerMac3,6 aka G4 MDD
which I was using as a desktop computer then. Johannes wrote all the code, and
I tested it.
I now have a PowerMac3,5 – yes, an earlier model.
This patch makes the snd-aoa ALSA sound module support the TAS3001C codec of
my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also work
for the "Quicksilver 2002", since both identify as PowerMac3,5.
The patch also changes a few comments to name the exact Power Mac model more
accurately in sound/aoa/fabrics/layout.c.
This is my first contribution to the linux kernel ever, so I hope you will be
kind to me. I am not a programmer, but adding already supported devices was a
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
[-- Attachment #2: Quicksilver-aoa.patch --]
[-- Type: text/x-patch, Size: 2692 bytes --]
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
--- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 2011-02-17 18:43:26.000000000 +0100
@@ -111,6 +111,7 @@
MODULE_ALIAS("sound-layout-100");
MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-21");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
@@ -333,14 +334,14 @@
.connections = topaz_input,
},
},
- /* Quad PowerMac (analog in, analog/digital out) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital out) */
{ .layout_id = 68,
.codecs[0] = {
.name = "onyx",
.connections = onyx_connections_nomic,
},
},
- /* Quad PowerMac (digital in) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
{ .layout_id = 69,
.codecs[0] = {
.name = "topaz",
@@ -521,14 +522,21 @@
.connections = onyx_connections_noheadphones,
},
},
- /* PowerMac3,4 */
+ /* PowerMac3,4 (Digital Audio) */
{ .device_id = 14,
.codecs[0] = {
.name = "tas",
.connections = tas_connections_noline,
},
},
- /* PowerMac3,6 */
+ /* PowerMac3,5 (Quicksilver) */
+ { .device_id = 21,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 (Mirrored Drive Doors) */
{ .device_id = 22,
.codecs[0] = {
.name = "tas",
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
--- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-05 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c 2011-02-17 18:44:36.000000000 +0100
@@ -200,7 +200,7 @@
* We probably cannot handle all device-id machines,
* so restrict to those we do handle for now.
*/
- if (id && (*id == 22 || *id == 14 || *id == 35)) {
+ if (id && (*id == 22 || *id == 21 || *id == 14 || *id == 35)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok = 1;
^ permalink raw reply
* [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-17 20:53 UTC (permalink / raw)
To: linuxppc-dev
Hello!
About two years ago Johannes Berg wrote support for the PowerMac3,6 aka G4 =
MDD=20
which I was using as a desktop computer then. Johannes wrote all the code, =
and=20
I tested it.
I now have a PowerMac3,5 =E2=80=93 yes, an earlier model.
This patch makes the snd-aoa ALSA sound module support the TAS3001C codec o=
f=20
my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also wo=
rk=20
for the "Quicksilver 2002", since both identify as PowerMac3,5.
The patch also changes a few comments to name the exact Power Mac model mor=
e=20
accurately in sound/aoa/fabrics/layout.c.
This is my first contribution to the linux kernel ever, so I hope you will =
be=20
kind to me. I am not a programmer, but adding already supported devices was=
a=20
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
=2D--
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc=
5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:=
19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 201=
1-02-17 18:43:26.000000000 +0100
@@ -111,6 +111,7 @@
MODULE_ALIAS("sound-layout-100");
=20
MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-21");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
=20
@@ -333,14 +334,14 @@
.connections =3D topaz_input,
},
},
=2D /* Quad PowerMac (analog in, analog/digital out) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital =
out) */
{ .layout_id =3D 68,
.codecs[0] =3D {
.name =3D "onyx",
.connections =3D onyx_connections_nomic,
},
},
=2D /* Quad PowerMac (digital in) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
{ .layout_id =3D 69,
.codecs[0] =3D {
.name =3D "topaz",
@@ -521,14 +522,21 @@
.connections =3D onyx_connections_noheadphones,
},
},---
=2D /* PowerMac3,4 */
+ /* PowerMac3,4 (Digital Audio) */
{ .device_id =3D 14,
.codecs[0] =3D {
.name =3D "tas",
.connections =3D tas_connections_noline,
},
},
=2D /* PowerMac3,6 */
+ /* PowerMac3,5 (Quicksilver) */
+ { .device_id =3D 21,
+ .codecs[0] =3D {
+ .name =3D "tas",
+ .connections =3D tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 (Mirrored Drive Doors) */
{ .device_id =3D 22,
.codecs[0] =3D {
.name =3D "tas",
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6=
=2E38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-0=
5 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c =
2011-02-17 18:44:36.000000000 +0100
@@ -200,7 +200,7 @@
* We probably cannot handle all device-id machines,
* so restrict to those we do handle for now.
*/
=2D if (id && (*id =3D=3D 22 || *id =3D=3D 14 || *id =
=3D=3D 35)) {
+ if (id && (*id =3D=3D 22 || *id =3D=3D 21 || *id =
=3D=3D 14 || *id =3D=3D 35)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok =3D 1;
^ permalink raw reply
* [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
From: Prabhakar Kushwaha @ 2011-02-18 5:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ashish Kalra, Prabhakar Kushwaha
When a single device error is detected, the device under the error is indicated
by the error bit set in the DER. There is a one to one mapping between register
bit and devices on Port multiplier(PMP) i.e. bit 0 represents PMP device 0 and
bit 1 represents PMP device 1 etc.
Current implementation treats Device error register value as device number not
set of bits representing multiple device on PMP. It is changed to consider bit
level.
No need to check for each set bit as all command is going to be aborted.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Ashish Kalra <B00888@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch master)
drivers/ata/sata_fsl.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 2546f38..8ad335f 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1047,8 +1047,9 @@ static void sata_fsl_error_intr(struct ata_port *ap)
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
- if (dereg < ap->nr_pmp_links) {
- link = &ap->pmp_link[dereg];
+ if ((ffs(dereg)-1) < ap->nr_pmp_links) {
+ /* array start from 0 */
+ link = &ap->pmp_link[ffs(dereg)-1];
ehi = &link->eh_info;
qc = ata_qc_from_tag(ap, link->active_tag);
/*
--
1.7.3
^ 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