* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-09-21 22:07 UTC (permalink / raw)
To: Anderson, Trevor; +Cc: david.hagood@gmail.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1682399277683944B902B3657D2FCE21654570D791@CAREXCLUSTER03.ATL.CW.LOCAL>
On Tue, 21 Sep 2010 17:37:15 -0400
"Anderson, Trevor" <tanderson@curtisswright.com> wrote:
> IRQ assignments for MPC8641D are "virtual",
This is true for powerpc in general.
> meaning "made up" and quite difficult to determine by looking through code.
> But I believe the plan goes something like this:
>
> IRQ
> ---------
> 0 No interrupt
> 1 - 15 External interrupts (only 1..12 would be used)
> 16 - 127 Internal interrupts - see Table 9-2 of 8641D ref man,
> Add 15 to the numbers shown
> 128 - 255 Yours, or your BSP's, to do with as you like
> 256 - 511 Message Signaled Interrupts
>
> If you look in the sample device trees for 8641 cards you'll see that
> the interrupt values cited there for various devices match the 16..127
> group above.
There are two different numberspaces involved here.
The MPIC interrupt numberspace in the device tree (which is not
virtual; it is a private numberspace to MPIC) is based on the offset of
the registers for that interrupt source. External interrupts start at
zero (which is valid), internal at 16, and special things like MSIs at
higher numbers (I don't think it's quite 256).
The numberspace for virtual interrupts, which is what you pass to
request_irq(), is dynamically allocated. You shouldn't need to know
anything about it other than that zero is invalid, and you get the
virtual IRQ from irq_of_parse_and_map() or another such mapping
function.
In neither case is there a range that is set aside for you "to do with
as you like". If you have another interrupt controller and need a
block of virtual interrupts, register the controller with
irq_alloc_host() and you'll get a block assigned.
-Scott
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Timur Tabi @ 2010-09-21 22:04 UTC (permalink / raw)
To: Scott Wood; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <20100921164944.164ed0af@udp111988uds.am.freescale.net>
On Tue, Sep 21, 2010 at 4:49 PM, Scott Wood <scottwood@freescale.com> wrote:
> Look in dmaengine.c, there are calls to dma_map_single() and
> dma_map_page(), using what I assume is that same device pointer --
> unless there's confusion between the channel and the controller.
You're right. I missed this line in the driver:
fdev->common.dev = &op->dev;
Also, the driver does something stupid. Sometimes "chan->dev" refers
to dma_chan.chan, and sometimes it refers to fsldma_chan.chan. I
could have sworn I saw a patch that fixes that, though.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Scott Wood @ 2010-09-21 21:49 UTC (permalink / raw)
To: Timur Tabi; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <AANLkTine--kry0c0n87WOqYyi3AQOb2KnmNRs-MeXcQt@mail.gmail.com>
On Tue, 21 Sep 2010 16:43:12 -0500
Timur Tabi <timur.tabi@gmail.com> wrote:
> On Tue, Sep 21, 2010 at 4:34 PM, Scott Wood <scottwood@freescale.com> wrote:
>
> > This doesn't control allocation (it probably should with
> > dma_alloc_coherent, though I don't see it in the code), it controls
> > whether swiotlb will create a bounce buffer -- defeating the point of
> > using DMA to accelerate a memcpy.
>
> But it would do that only for the 'dev' used in the dma_set_mask()
> call. That dev is only used here:
>
> chan->desc_pool = dma_pool_create("fsl_dma_engine_desc_pool",
> chan->dev,
> sizeof(struct fsl_desc_sw),
> __alignof__(struct fsl_desc_sw), 0);
>
> Since we don't DMA the descriptors themselves, I just don't see how
> this patch does anything.
Look in dmaengine.c, there are calls to dma_map_single() and
dma_map_page(), using what I assume is that same device pointer --
unless there's confusion between the channel and the controller.
-Scott
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Timur Tabi @ 2010-09-21 21:43 UTC (permalink / raw)
To: Scott Wood; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <20100921163456.7e2c9b32@udp111988uds.am.freescale.net>
On Tue, Sep 21, 2010 at 4:34 PM, Scott Wood <scottwood@freescale.com> wrote:
> This doesn't control allocation (it probably should with
> dma_alloc_coherent, though I don't see it in the code), it controls
> whether swiotlb will create a bounce buffer -- defeating the point of
> using DMA to accelerate a memcpy.
But it would do that only for the 'dev' used in the dma_set_mask()
call. That dev is only used here:
chan->desc_pool = dma_pool_create("fsl_dma_engine_desc_pool",
chan->dev,
sizeof(struct fsl_desc_sw),
__alignof__(struct fsl_desc_sw), 0);
Since we don't DMA the descriptors themselves, I just don't see how
this patch does anything.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* RE: Questions on interrupt vector assignment on MPC8641D
From: Anderson, Trevor @ 2010-09-21 21:37 UTC (permalink / raw)
To: david.hagood@gmail.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6e7b840fa55e4fba421e1b1cea2716ec.squirrel@localhost>
IRQ assignments for MPC8641D are "virtual", meaning "made up" and quite di=
fficult to determine by looking through code.
But I believe the plan goes something like this:
IRQ
---------
0 No interrupt
1 - 15 External interrupts (only 1..12 would be used)
16 - 127 Internal interrupts - see Table 9-2 of 8641D ref man,
Add 15 to the numbers shown
128 - 255 Yours, or your BSP's, to do with as you like
256 - 511 Message Signaled Interrupts
If you look in the sample device trees for 8641 cards you'll see that
the interrupt values cited there for various devices match the 16..127
group above.
> -----Original Message-----
> From: linuxppc-dev-bounces+tanderson=3Dcurtisswright.com@lists.ozlabs.or=
g [mailto:linuxppc-dev-
> bounces+tanderson=3Dcurtisswright.com@lists.ozlabs.org] On Behalf Of dav=
id.hagood@gmail.com
> Sent: Tuesday, September 21, 2010 7:12 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: Questions on interrupt vector assignment on MPC8641D
>
> I'm new to developing on the PPC (most of my experience is on x86), and =
I
> have a couple of questions about mapping of interrupts on the PPC,
> specifically on the Freescale 8641D embedded CPU.
>
> 1) How does one allocate interrupt vectors for the embedded devices, suc=
h
> as the MPIC? All the kernel how-tos are really targeting the x86 and PCI=
,
> so I've been unable to find a good document on "that which is not an X86=
".
>
> 2) Are there any good guides to programming the PPC generally, and the
> MPC8641 specifically, that I can go read to answer my other questions?
>
> I'm trying to write a driver to map the 8641D's PCIe controllers *as
> endpoints* into something frobablbe from user space - to allow setting t=
he
> BARs and outbound address translation units via sysfs files, and to allo=
w
> mapping of inbound interrupts to sysfs "doorbell"-style files. If I can
> get it worked out I want to submit it back to the kernel for general
> distribution.
>
> If anybody has any insights, I'd greatly appreciate it if you'd copy my
> work email (david.hagood at aeroflex.com) as well (I am using my persona=
l
> email as work insisted upon adding a one paragraph "wart" to all outboun=
d
> email that isn't acceptable for a list like this.)
>
> Also, if anybody out there has experience with the 8641D PEX's in endpoi=
nt
> mode and wouldn't mind answering a couple of questions about programming=
> the OWBARs, I'd be greatly obliged.
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended=
solely for the use of the individual or entity to whom they are addressed=
. If you have reason to believe that you have received this e-mail in erro=
r, please notify the sender and destroy this email and any attached files.=
Please note that any views or opinions presented in this e-mail are solel=
y those of=20the author and do not necessarily represent those of the Curt=
iss-Wright Corporation or any of its subsidiaries. Documents attached her=
eto may contain technology subject to government export regulations. Recip=
ient is solely responsible for ensuring that any re-export, transfer or di=
sclosure of this information is in accordance with applicable government e=
xport regulations. The recipient should check this e-mail and any attachm=
ents for the presence of viruses. Curtiss-Wright Corporation and its subsi=
diaries accept no liability for any damage caused by any virus transmitted=
by this e-mail.
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Scott Wood @ 2010-09-21 21:34 UTC (permalink / raw)
To: Timur Tabi; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <AANLkTimiwtoa6i10OTcgFnvbvcO9N4KWHyt4Poj-yj=T@mail.gmail.com>
On Tue, 21 Sep 2010 16:24:10 -0500
Timur Tabi <timur.tabi@gmail.com> wrote:
> On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> >
> >> Signed-off-by: Li Yang <leoli@freescale.com>
> >> ---
> >
> > We really should have a sentence about how or why this works to address 36-bit addressing.
>
> For example, I would like to know which memory is going to be
> allocated above 4GB. I don't know much about the kernel's async
> library, but my understanding is that fsldma does not allocate any of
> the memory buffers that it copies data to/from.
This doesn't control allocation (it probably should with
dma_alloc_coherent, though I don't see it in the code), it controls
whether swiotlb will create a bounce buffer -- defeating the point of
using DMA to accelerate a memcpy.
-Scott
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Timur Tabi @ 2010-09-21 21:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <877FD0B5-19A7-4A16-831E-369B80B104EA@kernel.crashing.org>
On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>
> We really should have a sentence about how or why this works to address 36-bit addressing.
For example, I would like to know which memory is going to be
allocated above 4GB. I don't know much about the kernel's async
library, but my understanding is that fsldma does not allocate any of
the memory buffers that it copies data to/from. The only memory that
fsldma allocates is for the DMA descriptors, which are very small and
probably don't take up more than a couple pages.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Kyle Moffett @ 2010-09-21 20:47 UTC (permalink / raw)
To: John Stultz
Cc: Rodolfo Giometti, Arnd Bergmann, netdev, devicetree-discuss,
linux-kernel, linuxppc-dev, Richard Cochran, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <1282948239.2268.155.camel@jstultz-laptop>
On Fri, Aug 27, 2010 at 18:30, John Stultz <johnstul@us.ibm.com> wrote:
> On one side, there is the view that the kernel should abstract and hide
> the hardware details to increase app portability. And the other is that
> the raw hardware details should be exposed, so the OS stays out of the
> way.
>
> Neither of these views are always right. Ideally we can come up with a
> abstracted way to provide the hardware data needed that's generic enough
> that applications don't have to be changed when moving between hardware
> or configurations.
>
> The posix clock id interface is frustrating because the flat static
> enumeration is really limiting.
>
> I wonder if a dynamic enumeration for posix clocks would be possibly a
> way to go?
Well how about something much more straightforward:
#define CLOCK_FD 0x80000000
fd = open("/dev/clocks/some_clock_name", O_RDONLY);
clock_gettime(CLOCK_FD | fd, &ts);
This would provide all of the standard character-device semantics that
everyone is accustomed to, and furthermore you could allow non-root
users to manage specific clocks using just DAC permission bits.
You'd still probably need to add a clock_adjtimex() syscall, but it
could easily fail with EINVAL for software or per-thread clocks, but
that seems like it would nicely abstract the hardware without forcing
a numeric address space.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [U-Boot] cuImage and multi image?
From: Scott Wood @ 2010-09-21 17:52 UTC (permalink / raw)
To: Chen, Tiejun; +Cc: ppcdev, uboot
In-Reply-To: <52CF90264091A14888078A031D780F4306C8BD30@ism-mail03.corp.ad.wrs.com>
On Tue, 21 Sep 2010 03:03:22 +0200
"Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:
> > -----Original Message-----
> > From: Shawn Jin [mailto:shawnxjin@gmail.com]
> > Sent: Tuesday, September 21, 2010 1:53 AM
> > To: Chen, Tiejun
> > Cc: ppcdev; uboot
> > Subject: Re: cuImage and multi image?
> >
> > >> I have a cuImage kernel in order to support legacy u-boot and a
> > >> ramdisk image. Kernel boots fine if these two images are
> > separate and
> > >> "bootm $kernel $ramdisk" is used. But I can not make it to
> > work using
> > >> a single multi image that contains the kernel and ramdisk
> > images. Is
> > >> it even technically possible to boot a multi-image with cuboot
> > >> wrapper?
> > >
> > > Try the following steps:
> > > ------
> > > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > > 2. make cuImage.initrd.<your target>
> > >
> > > You can get one Image, cuImage.initrd.<your target>,
> > including kernel and ramdisk.
> >
> > A follow up question. With this method, the total image size
> > (uncompressed) is limited to the 4MB (the link address of the
> > boot wrapper)?
>
> No.
Yes, unless you change the link address, or provide a vmlinux_alloc
callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The limit applies to
the uncompressed boot image -- anything that the bootwrapper itself is
decompressing. It does not apply to any further uncompression of the
ramdisk itself.
-Scott
^ permalink raw reply
* Re: Generating elf kernel ?
From: Scott Wood @ 2010-09-21 17:00 UTC (permalink / raw)
To: Chen, Tiejun; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <52CF90264091A14888078A031D780F4306C8BD2F@ism-mail03.corp.ad.wrs.com>
On Tue, 21 Sep 2010 03:00:40 +0200
"Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:
> This should be depend on the hypervisor design implementation. I think
> your
> option should be based on the Freescale hypervisor.
Again, I was giving an example, about ELF loading. I was not making any
claims about what all hypervisors do. :-P
-Scott
^ permalink raw reply
* RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Tirumala Marri @ 2010-09-21 16:51 UTC (permalink / raw)
To: Ilya Yanok, linuxppc-dev
In-Reply-To: <loom.20100919T215645-646@post.gmane.org>
> -----Original Message-----
> From: linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org] On
> Behalf Of Ilya Yanok
> Sent: Sunday, September 19, 2010 1:01 PM
> To: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
>
> Hi Tirumala,
>
> > drivers/dma/ppc4xx/adma.c | 4370 +++-------------------------
> ----------
> > drivers/dma/ppc4xx/adma.h | 116 +-
> > drivers/dma/ppc4xx/ppc4xx-adma.h | 4020
> +++++++++++++++++++++++++++++++++++
>
> You've moved tons of code to the header file. Why?
>
> Regards, Ilya.
>
My intention is to keep the SoC specific code in the header files.
Something iop-dma is also doing.
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Stephan Gatzka @ 2010-09-21 16:54 UTC (permalink / raw)
To: netdev, devicetree-discuss, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20100906063327.GA4549@riccoc20.at.omicron.at>
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
Hi Richard,
> 1. Character device
> 2. POSIX clock with dynamic ids
>
> Please, just take your pick ;^)
Just to reopen this nearly dead but very interesting thread: I'm happy
with every solution that has no impact on the accuracy of the PTP clock.
If I can choose, I would prefer the POSIX clock with dynamic ids solution.
Kind regards and thanks for your effort,
Stephan Gatzka
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5136 bytes --]
^ permalink raw reply
* Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-09-21 14:12 UTC (permalink / raw)
To: linuxppc-dev
I'm new to developing on the PPC (most of my experience is on x86), and I
have a couple of questions about mapping of interrupts on the PPC,
specifically on the Freescale 8641D embedded CPU.
1) How does one allocate interrupt vectors for the embedded devices, such
as the MPIC? All the kernel how-tos are really targeting the x86 and PCI,
so I've been unable to find a good document on "that which is not an X86".
2) Are there any good guides to programming the PPC generally, and the
MPC8641 specifically, that I can go read to answer my other questions?
I'm trying to write a driver to map the 8641D's PCIe controllers *as
endpoints* into something frobablbe from user space - to allow setting the
BARs and outbound address translation units via sysfs files, and to allow
mapping of inbound interrupts to sysfs "doorbell"-style files. If I can
get it worked out I want to submit it back to the kernel for general
distribution.
If anybody has any insights, I'd greatly appreciate it if you'd copy my
work email (david.hagood at aeroflex.com) as well (I am using my personal
email as work insisted upon adding a one paragraph "wart" to all outbound
email that isn't acceptable for a list like this.)
Also, if anybody out there has experience with the 8641D PEX's in endpoint
mode and wouldn't mind answering a couple of questions about programming
the OWBARs, I'd be greatly obliged.
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Kumar Gala @ 2010-09-21 12:55 UTC (permalink / raw)
To: Li Yang; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <1285066638-7473-1-git-send-email-leoli@freescale.com>
On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
We really should have a sentence about how or why this works to address =
36-bit addressing.
> drivers/dma/fsldma.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>=20
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index cea08be..9163552 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1,7 +1,7 @@
> /*
> * Freescale MPC85xx, MPC83xx DMA Engine support
> *
> - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights =
reserved.
> + * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights =
reserved.
> *
> * Author:
> * Zhang Wei <wei.zhang@freescale.com>, Jul 2007
> @@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct =
platform_device *op,
> fdev->common.device_control =3D fsl_dma_device_control;
> fdev->common.dev =3D &op->dev;
>=20
> + dma_set_mask(&op->dev, DMA_BIT_MASK(36));
> dev_set_drvdata(&op->dev, fdev);
>=20
> /*
> --=20
> 1.6.6-rc1.GIT
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
From: Detlev Zundel @ 2010-09-21 12:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20100920135136.04ceb772__36164.799918379$1285008751$gmane$org@udp111988uds.am.freescale.net>
Hi Scott,
> On Sat, 18 Sep 2010 14:22:12 -0400
> Josh Boyer <jwboyer@gmail.com> wrote:
>
>> Capitalizing? The patch you posted that uses this symbol is for a GPL
>> driver so you gain or lose nothing by having this symbol be
>> EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort
>> of gain by allowing non-GPL modules? If so, I find that unfortunate.
>> If not, then I guess I don't understand what you mean by capitalizing.
>
> One can dislike DRM (even a very weak form such as this) without having
> a particular desire to go outside the bounds of what it allows.
>
> I thought EXPORT_SYMBOL_GPL was originally meant to indicate the
> symbols whose use is likely to be indicitave of code that is, in some
> copyright-meaningful way, derived from GPL code?
Google finds this, which coincides with what I remmber[1]:
EXPORT_SYMBOL_GPL
Some kernel developers are unhappy with providing external interfaces to
their code, only to see those interfaces being used by binary only
modules. They view it as their work being appropriated. Whether you
agree with that view or not is completely irrelevant, the person who
owns the copyright decides how their work can be used.
EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
available to modules with a GPL compatible license. This is independent
of the kernel tainting, but obviously takes advantage of
MODULE_LICENSE() strings.
EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus has
spoken. I believe the phrase involved killer penguins with chainsaws for
anybody who changed existing exported interfaces.
Cheers
Detlev
[1] http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0369.html
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* [PATCH] fsldma: add support to 36-bit physical address
From: Li Yang @ 2010-09-21 10:57 UTC (permalink / raw)
To: dan.j.williams; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/dma/fsldma.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index cea08be..9163552 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1,7 +1,7 @@
/*
* Freescale MPC85xx, MPC83xx DMA Engine support
*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights reserved.
*
* Author:
* Zhang Wei <wei.zhang@freescale.com>, Jul 2007
@@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct platform_device *op,
fdev->common.device_control = fsl_dma_device_control;
fdev->common.dev = &op->dev;
+ dma_set_mask(&op->dev, DMA_BIT_MASK(36));
dev_set_drvdata(&op->dev, fdev);
/*
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Dual ethernet attachment with single FEC
From: LEROY Christophe @ 2010-09-21 7:30 UTC (permalink / raw)
To: LinuxPPC-dev, netdev
Hello,
I have a board with 2 PHYs attached to one FEC ethernet controler on
powerpc.
I want to implement some kind of main-standby attachment to LAN by
setting the ISOLATE bit on one on the two PHYs then monitoring the link
status and switch to the other PHY when the link status goes down.
I see this behaviour is implemented in the sis900 driver, but it doesn't
use the standard PHY layer as the Freescale FEC driver does.
What would be the most proper way to implement this functionality ?
* Modify FEC driver to manage that ?
* Implement a virtual PHY driver that would manage that ?
* Other solution ?
Best regards
C. Leroy
^ permalink raw reply
* RE: cuImage and multi image?
From: Chen, Tiejun @ 2010-09-21 1:03 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev, uboot
In-Reply-To: <AANLkTikrYdi=V6jM4HS3V4XzMutGdkPA2qHRBgviKHM8@mail.gmail.com>
> -----Original Message-----
> From: Shawn Jin [mailto:shawnxjin@gmail.com]=20
> Sent: Tuesday, September 21, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: cuImage and multi image?
>=20
> >> I have a cuImage kernel in order to support legacy u-boot and a=20
> >> ramdisk image. Kernel boots fine if these two images are=20
> separate and=20
> >> "bootm $kernel $ramdisk" is used. But I can not make it to=20
> work using=20
> >> a single multi image that contains the kernel and ramdisk=20
> images. Is=20
> >> it even technically possible to boot a multi-image with cuboot=20
> >> wrapper?
> >
> > Try the following steps:
> > ------
> > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > 2. make cuImage.initrd.<your target>
> >
> > You can get one Image, cuImage.initrd.<your target>,=20
> including kernel and ramdisk.
>=20
> A follow up question. With this method, the total image size
> (uncompressed) is limited to the 4MB (the link address of the=20
> boot wrapper)?
No.
Cheers
Tiejun
>=20
> Thanks,
> -Shawn.
>=20
^ permalink raw reply
* RE: Generating elf kernel ?
From: Chen, Tiejun @ 2010-09-21 1:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <20100920104353.5dbd9201@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: Monday, September 20, 2010 11:44 PM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
>=20
> On Sun, 19 Sep 2010 09:40:15 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>=20
> > Scott Wood wrote:
> > > On Fri, 17 Sep 2010 09:58:41 +0800
> > > "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> > >=20
> > >> Scott Wood wrote:
> > >>> The guest OS *is* the same as native Linux, as far as=20
> TLB handling=20
> > >>> is concerned.
> > >> Looks you means the TLB exception handler should be same between=20
> > >> the native and the guest OS. Right?
> > >=20
> > > Yes.
> >=20
> > I don't think so. The HY should assist the guest OS on MMU since I=20
> > already point the guest OS have no authority to create a=20
> real TLB directly as I previously said.
>=20
> Of course the hypervisor assists, when a trap is taken. That=20
> doesn't mean the code is any different in the guest.
This should be depend on the hypervisor design implementation. I think
your=20
option should be based on the Freescale hypervisor.
>=20
> > > Yes, of course. But that's not the point. I was just=20
> using it as a=20
> > > convenient example because that's what I've recently done ELF=20
> > > loading with... There's no reason U-Boot couldn't do the same if=20
> > > its ELF loader were updated to support device trees. Currently=20
> > > U-Boot loads bootwrapperless uImages to physical address zero.
> >=20
> > I never doubt the U-boot can do this for uImage. But I think we're=20
> > always talking about vmlinux, a bare Image.
>=20
> uImage is pretty much a bare image. It just has a header=20
> with a checksum and some info like OS/architecture, kernel=20
> version, build date, etc.
Yes. But it also inlcude load address and entry point used to u-boot.
>=20
> There would be *no* problem doing this with vmlinux in U-Boot=20
> if someone put in the code to pass a device tree.
This is just I always emphasize previously.
Cheers
Tiejun
>=20
> -Scott
>=20
>=20
^ permalink raw reply
* Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Wolfgang Denk @ 2010-09-20 21:31 UTC (permalink / raw)
To: Tirumala Marri
Cc: neilb, yur, linux-raid, herbert, linux-crypto, dan.j.williams,
linuxppc-dev
In-Reply-To: <7707889dee57e97ad50b4ce5c7697466@mail.gmail.com>
Dear Tirumala Marri,
In message <7707889dee57e97ad50b4ce5c7697466@mail.gmail.com> you wrote:
>
> > > +/**
> > > + * ppc440spe_can_rxor - check if the operands may be processed with RXOR
> > > + */
> > > +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt,
> > size_t len)
> >
> > Again, should this then not be in ppc440spe specific files?
> >
> >
> > It seems the split / generalization is highly incomplete yet.
>
> [Marri] Some of the stuff can go into ppc440spe-dma.h. This is just
> Beginning to add more new DMA engines support. I expect more changes to
> come in.
Why would that go into a header file? This is source code, not header
stuff. It should stay in a .c file! [Note that Ilya asked the same
question.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Intel's new motto: United we stand. Divided we fall!
^ permalink raw reply
* Re: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Micha Nelissen @ 2010-09-20 20:40 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, Andrew Morton, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201303D0E@CORPEXCH1.na.ads.idt.com>
Hi Alex,
Bounine, Alexandre wrote:
> struct rio_dev {
> struct list_head global_list;
> struct list_head net_list;
> .....
> ..... rest of rio_dev
> .....
> struct rio_switch switch[0];
> }
It makes sense to let rio_dev structures point to the switch they are
attached to. That can be useful in various situations, but is not
possible with this setup.
If a rio_dev is a switch then rdev->rswitch->rdev == rdev holds.
> This will remove extra memory allocation, remove overlapping structure
> members and clean code sections like one shown below:
>
> u8 hopcount = 0xff;
> u16 destid = rdev->destid;
>
> if (rdev->rswitch) {
> destid = rdev->rswitch->destid;
> hopcount = rdev->rswitch->hopcount;
> }
Note that it is possible for rdev->destid to differ from
rdev->rswitch->destid even if rswitch->rdev == rdev (for non-hosts i.e.
agents). rswitch->destid is the destid by which we discovered the switch
(and can reach it) but rdev->destid is the actual id given to the switch.
Micha
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Timur Tabi @ 2010-09-20 19:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, kumar.gala, linux-watchdog
In-Reply-To: <20100920193016.GA3845@zod.rchland.ibm.com>
Josh Boyer wrote:
> I guess I don't see what you mean. It talks about e500 but it doesn't
> say "Book-E" anywhere in that comment. (Though I'm pretty sure that
> comment does apply to 4xx.)
That was my point. The comment says e500, but the code is also intended for
4xx.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* RE: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Bounine, Alexandre @ 2010-09-20 19:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100920121725.66bb96d0.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>=20
> The "variable length array at the end of the struct" thing is pretty
> commonly used and works well. As long as we never want to change the
> number of switches on the fly (hotplug?).
This is expected to be a "strange" array - its size can be 0 or 1 only.
No number of switches in that array should be changed on the fly.
In the hotplug situation entire rio_dev structure should be added (or
removed).
RIO device can be endpoint or switch. If a RIO device is a switch - the
rio_switch
structure will be added at the end.
^ permalink raw reply
* Re: [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Josh Boyer @ 2010-09-20 19:30 UTC (permalink / raw)
To: Timur Tabi; +Cc: kumar.gala, linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
On Mon, Sep 20, 2010 at 11:23:41AM -0500, Timur Tabi wrote:
>Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
>watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
>to a GPL-only export. This is okay, because any module that needs this symbol
>should be an actual Linux driver, which must be GPL-licensed.
>
>Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>---
>
>This export is necessary for the Book-E watchdog driver to be compiled as a
>module.
>
> arch/powerpc/kernel/time.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>index 8533b3b..0c0c241 100644
>--- a/arch/powerpc/kernel/time.c
>+++ b/arch/powerpc/kernel/time.c
>@@ -161,8 +161,9 @@ extern struct timezone sys_tz;
> static long timezone_offset;
>
> unsigned long ppc_proc_freq;
>-EXPORT_SYMBOL(ppc_proc_freq);
>+EXPORT_SYMBOL_GPL(ppc_proc_freq);
> unsigned long ppc_tb_freq;
>+EXPORT_SYMBOL_GPL(ppc_tb_freq);
>
> static DEFINE_PER_CPU(u64, last_jiffy);
>
>--
>1.7.2.3
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Josh Boyer @ 2010-09-20 19:30 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala, linux-watchdog
In-Reply-To: <AANLkTimp-0zdw-fAaX8qCwHW0NMn--6RK0_USDGOSe47@mail.gmail.com>
On Mon, Sep 20, 2010 at 10:51:37AM -0500, Timur Tabi wrote:
>On Fri, Sep 17, 2010 at 7:37 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> config BOOKE_WDT
>>> - bool "PowerPC Book-E Watchdog Timer"
>>> + tristate "PowerPC Book-E Watchdog Timer"
>>> depends on BOOKE || 4xx
>>> ---help---
>>> + Watchdog driver for PowerPC e500 chips, such as the Freescale
>>> + MPC85xx SOCs.
>>> +
>>
>> Again, used for more than e500. That || 4xx in the depends statement
>> right above your addition isn't there for fun :).
>
>Does this mean that this comment which is already in the driver is
>wrong? It alludes that "Book-E" is synonymous with "e500".
>
>/* If the kernel parameter wdt=1, the watchdog will be enabled at boot.
> * Also, the wdt_period sets the watchdog timer period timeout.
> * For E500 cpus the wdt_period sets which bit changing from 0->1 will
> * trigger a watchog timeout. This watchdog timeout will occur 3 times, the
> * first time nothing will happen, the second time a watchdog exception will
> * occur, and the final time the board will reset.
> */
I guess I don't see what you mean. It talks about e500 but it doesn't
say "Book-E" anywhere in that comment. (Though I'm pretty sure that
comment does apply to 4xx.)
>
>#ifdef CONFIG_FSL_BOOKE
>#define WDT_PERIOD_DEFAULT 38 /* Ex. wdt_period=28 bus=333Mhz,reset=~40sec */
>#else
>#define WDT_PERIOD_DEFAULT 3 /* Refer to the PPC40x and PPC4xx manuals */
>#endif /* for timing information */
And this bit is marked as "FSL_BOOKE" vs. 40x and 44x.
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox