* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Jochen Friedrich @ 2008-07-18 15:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Scott Wood
In-Reply-To: <C98DF5D7-0E3D-4FDA-A831-55CFD5F4590C@kernel.crashing.org>
Hi Kumar,
> but ports a-d are different on cpm1? I guess I'd like to see both
> patches to understand the commonality and differences.
Yes. Both patches are still in patchwork:
http://patchwork.ozlabs.org/linuxppc/patch?id=19045
http://patchwork.ozlabs.org/linuxppc/patch?id=19386
Thanks,
Jochen
^ permalink raw reply
* Re: hang on "booting the kernel ...."
From: David Baird @ 2008-07-18 15:51 UTC (permalink / raw)
To: wsz_422; +Cc: linuxppc-embedded
In-Reply-To: <11945316.455961216349028828.JavaMail.coremail@bj126app95.126.com>
On Thu, Jul 17, 2008 at 8:43 PM, wsz_422 <wsz_422@126.com> wrote:
>
> Hello!
> When I boot the kerenl which was compiled by myself on the ML403,but
> it hang on "booting the kernel ",the prompt information is as follow:
> Linux
> uncompressing the kernel ....done
> Now booting the kernel
> and then there is nothing .
This problem comes up a lot. Try searching the archives for ML403 and
__log_buf.
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-18 15:46 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev list, Scott Wood
In-Reply-To: <4880B730.8050801@scram.de>
On Jul 18, 2008, at 10:30 AM, Jochen Friedrich wrote:
> Hi Kumar,
>
>> On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
>>
>>> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
>>> +
>>> +struct cpm2_ioports {
>>> + u32 dir, par, sor, odr, dat;
>>> + u32 res[3];
>>> +};
>>> +
>>
>> is this really common for both CPM2 and 8xx? if so why the name?
>
> It is common to CPM2 and Port E of CPM1.
but ports a-d are different on cpm1? I guess I'd like to see both
patches to understand the commonality and differences.
- k
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Jochen Friedrich @ 2008-07-18 15:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Scott Wood
In-Reply-To: <8D84340F-427C-403B-8121-481642478B8C@kernel.crashing.org>
Hi Kumar,
> On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
>
>> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
>> +
>> +struct cpm2_ioports {
>> + u32 dir, par, sor, odr, dat;
>> + u32 res[3];
>> +};
>> +
>
> is this really common for both CPM2 and 8xx? if so why the name?
It is common to CPM2 and Port E of CPM1.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-18 15:28 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <200806181908.41525.laurentp@cse-semaphore.com>
On Jun 18, 2008, at 12:08 PM, Laurent Pinchart wrote:
> +#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
> +
> +struct cpm2_ioports {
> + u32 dir, par, sor, odr, dat;
> + u32 res[3];
> +};
> +
is this really common for both CPM2 and 8xx? if so why the name?
- k
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-18 15:28 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <200807181707.56921.laurentp@cse-semaphore.com>
On Jul 18, 2008, at 10:07 AM, Laurent Pinchart wrote:
> On Friday 18 July 2008, Kumar Gala wrote:
>>
>> On Jul 18, 2008, at 9:38 AM, Laurent Pinchart wrote:
>>
>>> On Friday 27 June 2008, Jochen Friedrich wrote:
>>>> Hi Laurent,
>>>>
>>>>> Is there any pending issue or can this be applied to powerpc-
>>>>> next ?
>>>>
>>>> Looks OK to me.
>>>>
>>>>>> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
>>>>>> Cc: Jochen Friedrich <jochen@scram.de>
>>>> Acked-by: Jochen Friedrich <jochen@scram.de>
>>>
>>> Any news on this patch ? Kumar, could you apply it to your tree for
>>> 2.6.27 ?
>>
>> Can you repost it. I not sure what patch 2/2 was and if I've already
>> dealt with it.
>
> 2/2 was "[PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1
> Freescale SoC." posted by Jochen Friedrich. You haven't dealt with
> it yet as far as I know, but it would be up to Jochen to resubmit.
Since it sounds like CPM1 and CPM2 gpio are different I'd like a new
patch. I'll send comments on v3.
> The "PATCHv3 1/2" patch can be considered as-is, as it doesn't
> depend on 2/2. Should I resubmit a "PATCHv4" that just changes the
> subject line ?
You can generate a v4 w/my desired changes.
- k
^ permalink raw reply
* Re: going to OLS?
From: Becky Bruce @ 2008-07-18 15:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list
In-Reply-To: <1216390949.12864.22.camel@weaponx>
On Jul 18, 2008, at 9:22 AM, Josh Boyer wrote:
> On Fri, 2008-07-18 at 08:35 -0500, Kumar Gala wrote:
>> Since OLS is next week I figured I see who around here is going.
>>
>> I'm always interested in putting faces to names and having a lively
>> discussions over beer.
>>
>> So if your headed to OLS respond to this thread and maybe we'll have
>> an inform PPC BoF @ a pub.
>
> I'll be there.
<Acked-by-with-a-woohoo> Becky Bruce
-B
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Laurent Pinchart @ 2008-07-18 15:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <97D0950D-BBCA-4859-936E-774D887B05DC@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
On Friday 18 July 2008, Kumar Gala wrote:
>
> On Jul 18, 2008, at 9:38 AM, Laurent Pinchart wrote:
>
> > On Friday 27 June 2008, Jochen Friedrich wrote:
> >> Hi Laurent,
> >>
> >>> Is there any pending issue or can this be applied to powerpc-next ?
> >>
> >> Looks OK to me.
> >>
> >>>> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> >>>> Cc: Jochen Friedrich <jochen@scram.de>
> >> Acked-by: Jochen Friedrich <jochen@scram.de>
> >
> > Any news on this patch ? Kumar, could you apply it to your tree for
> > 2.6.27 ?
>
> Can you repost it. I not sure what patch 2/2 was and if I've already
> dealt with it.
2/2 was "[PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC." posted by Jochen Friedrich. You haven't dealt with it yet as far as I know, but it would be up to Jochen to resubmit.
The "PATCHv3 1/2" patch can be considered as-is, as it doesn't depend on 2/2. Should I resubmit a "PATCHv4" that just changes the subject line ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Timur Tabi @ 2008-07-18 14:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080718071720.GA2174@secretlab.ca>
Grant Likely wrote:
> Okay, I've changed my mind. :-) I'll back off a bit from this extreme and
> call it:
>
> sound/soc/fsl/soc-of-simple.c
That works for me.
And please don't forget to CC: me on any discussion involving sound/soc/fsl.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Timur Tabi @ 2008-07-18 14:57 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18525063.post@talk.nabble.com>
Misbah khan wrote:
> 4. Now we want our 9MB SDRAM to point to the kernel circular buffer we want
> our circular buffer to be mapped to continues paged so that we could map it
> to user space.
Physically contiguous or virtually contiguous? I think you only need the
buffer to be virtually contiguous, which vmalloc gives you. You only need it
to be physically contiguous if you are passing this buffer to hardware via DMA
(and the hardware cannot handle scatter/gather).
If you need it to be physically contiguous, you'll have to use a function like
alloc_pages() (or the new alloc_pages_exact, which will be in 2.6.27). To
allocate 9MB, you'll need to increase CONFIG_FORCE_MAX_ZONEORDER to 12.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Kumar Gala @ 2008-07-18 14:50 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <200807181638.42485.laurentp@cse-semaphore.com>
On Jul 18, 2008, at 9:38 AM, Laurent Pinchart wrote:
> On Friday 27 June 2008, Jochen Friedrich wrote:
>> Hi Laurent,
>>
>>> Is there any pending issue or can this be applied to powerpc-next ?
>>
>> Looks OK to me.
>>
>>>> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
>>>> Cc: Jochen Friedrich <jochen@scram.de>
>> Acked-by: Jochen Friedrich <jochen@scram.de>
>
> Any news on this patch ? Kumar, could you apply it to your tree for
> 2.6.27 ?
Can you repost it. I not sure what patch 2/2 was and if I've already
dealt with it.
- k
^ permalink raw reply
* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Laurent Pinchart @ 2008-07-18 14:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <48651A70.2050608@scram.de>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
On Friday 27 June 2008, Jochen Friedrich wrote:
> Hi Laurent,
>
> > Is there any pending issue or can this be applied to powerpc-next ?
>
> Looks OK to me.
>
> >> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> >> Cc: Jochen Friedrich <jochen@scram.de>
> Acked-by: Jochen Friedrich <jochen@scram.de>
Any news on this patch ? Kumar, could you apply it to your tree for 2.6.27 ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Stefan Roese @ 2008-07-18 14:24 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, Victor Gallardo, fkan
In-Reply-To: <1216186406-27993-1-git-send-email-fkan@amcc.com>
On Wednesday 16 July 2008, fkan@amcc.com wrote:
> From: Victor Gallardo <vgallard@amcc.com>
>
> ppc4xx: Add AMCC Arches 460GT eval board support
>
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
Please put a brief description of Arches in the patch description.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches DTS
From: Stefan Roese @ 2008-07-18 14:24 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, Victor Gallardo, fkan
In-Reply-To: <1216186476-28018-1-git-send-email-fkan@amcc.com>
On Wednesday 16 July 2008, fkan@amcc.com wrote:
> From: Victor Gallardo <vgallard@amcc.com>
>
> ppc4xx: Add AMCC Arches DTS
>
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
> ---
> arch/powerpc/boot/dts/arches.dts | 522
> ++++++++++++++++++++++++++++++++++++++ 1 files changed, 522 insertions(+),
> 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/arches.dts
>
> diff --git a/arch/powerpc/boot/dts/arches.dts
<snip>
> + nor_flash@0,0 {
> + compatible = "amd,s29gl256n", "cfi-flash";
So its a S29GL256 with 32MBytes...
> + bank-width = <2>;
> + reg = <0 000000 4000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "kernel";
> + reg = <0 1e0000>;
> + };
> + partition@1e0000 {
> + label = "dtb";
> + reg = <1e0000 20000>;
> + };
> + partition@200000 {
> + label = "ramdisk";
> + reg = <200000 1400000>;
> + };
> + partition@1600000 {
> + label = "jffs2";
> + reg = <1600000 400000>;
> + };
> + partition@1a00000 {
> + label = "user";
> + reg = <1a00000 2560000>;
> + };
> + partition@3f60000 {
> + label = "env";
> + reg = <3f60000 40000>;
> + };
> + partition@3fa0000 {
> + label = "u-boot";
> + reg = <3fa0000 60000>;
> + };
... and this partition scheme is for 64MByte.
<snip>
> + EMAC0: ethernet@ef600e00 {
> + device_type = "network";
> + compatible = "ibm,emac-460gt", "ibm,emac4";
That's not correct anymore. A recent patch from Grant Erickson [ibm_newemac:
Parameterize EMAC Multicast Match Handling] changed these compatible entries.
You should use "ibm_emac4sync" here now.
> + interrupt-parent = <&EMAC0>;
> + interrupts = <0 1>;
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = </*Status*/ 0 &UIC2 10 4
> + /*Wake*/ 1 &UIC2 14 4>;
> + reg = <ef600e00 70>;
The patch mentioned above also cfixed the incorrect size here. Please fix this
too.
> + local-mac-address = [000000000000]; /* Filled in by U-Boot */
> + mal-device = <&MAL0>;
> + mal-tx-channel = <0>;
> + mal-rx-channel = <0>;
> + cell-index = <0>;
> + max-frame-size = <2328>;
> + rx-fifo-size = <1000>;
> + tx-fifo-size = <800>;
> + phy-mode = "rgmii";
SGMII, right?
> + phy-map = <00000000>;
> + rgmii-device = <&RGMII0>;
> + rgmii-channel = <0>;
> + tah-device = <&TAH0>;
> + tah-channel = <0>;
> + has-inverted-stacr-oc;
> + has-new-stacr-staopc;
> + };
All EMAC related comment above are valid for all EMAC nodes of course.
Best regards,
Stefan
^ permalink raw reply
* Re: going to OLS?
From: Josh Boyer @ 2008-07-18 14:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
On Fri, 2008-07-18 at 08:35 -0500, Kumar Gala wrote:
> Since OLS is next week I figured I see who around here is going.
>
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
>
> So if your headed to OLS respond to this thread and maybe we'll have
> an inform PPC BoF @ a pub.
I'll be there.
josh
^ permalink raw reply
* Re: going to OLS?
From: Stefan Roese @ 2008-07-18 14:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven
In-Reply-To: <Pine.LNX.4.64.0807181548290.8276@vixen.sonytel.be>
On Friday 18 July 2008, Geert Uytterhoeven wrote:
> On Fri, 18 Jul 2008, Kumar Gala wrote:
> > Since OLS is next week I figured I see who around here is going.
> >
> > I'm always interested in putting faces to names and having a lively
> > discussions over beer.
> >
> > So if your headed to OLS respond to this thread and maybe we'll have an
> > inform PPC BoF @ a pub.
>
> Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
> So I'll be there.
Me too. :)
Best regards,
Stefan
^ permalink raw reply
* No filesystem could mount root
From: mahendra varman @ 2008-07-18 14:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
Hi all
We are porting linux 2.6.24 on a board with powerpc processor and with AMD
79C972 ethernet chip
Thru ramdisk I can able to boot the board and i can do the ifconfig eth0
up..
When I try to boot the board with nfs iam getting the following
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module
List of all partitions:
No filesystem could mount root, tried: ext3 ext2 msdos ntfs
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
Rebooting in 180 seconds..
1. In the kernel the nfs related configs are enabled properly
2. The nfs server and file system is proper( I have mounted and checked the
nfs server & file system thru another working setup)
3. The ethernet driver pcnet32.c under drivers/net is okkk it seems becaz
it is working when i boot the board thru ramdisk
Please shed me some light where to look and what may be the reason iam
getting the above error when i boot thru NFS
Thanks in advance
[-- Attachment #2: Type: text/html, Size: 1183 bytes --]
^ permalink raw reply
* Re: going to OLS?
From: Geert Uytterhoeven @ 2008-07-18 13:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 796 bytes --]
On Fri, 18 Jul 2008, Kumar Gala wrote:
> Since OLS is next week I figured I see who around here is going.
>
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
>
> So if your headed to OLS respond to this thread and maybe we'll have an inform
> PPC BoF @ a pub.
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
So I'll be there.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@eu.sony.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
From: Kumar Gala @ 2008-07-18 13:40 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Scott Wood, linuxppc-dev, Jeff Garzik, Vitaly Bordug, netdev
In-Reply-To: <200807181126.48246.laurentp@cse-semaphore.com>
On Jul 18, 2008, at 4:26 AM, Laurent Pinchart wrote:
> On Thursday 26 June 2008, Vitaly Bordug wrote:
>> On Thu, 26 Jun 2008 13:21:23 +0200
>> Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
>>
>>>> There should be no dependencies. When the OF GPIO support is not
>>>> selected linux/of_gpio.h will define of_get_gpio() as a stub, so
>>>> the
>>>> fs_enet driver will fall back to the legacy binding.
>>>
>>> Have we reached a consensus on which tree the patch should go to ?
>> I think it should go through powerpc tree, not seeing too much
>> netdev-generic stuff in here. If noone will object, Kumar will pick
>> it up I
>> guess...
>
> Kumar, could you pick it up ? I'd like to see this in 2.6.27.
>
> Best regards,
Jeff said he applied both to his tree already.
- k
^ permalink raw reply
* going to OLS?
From: Kumar Gala @ 2008-07-18 13:35 UTC (permalink / raw)
To: linuxppc-dev list
Since OLS is next week I figured I see who around here is going.
I'm always interested in putting faces to names and having a lively
discussions over beer.
So if your headed to OLS respond to this thread and maybe we'll have
an inform PPC BoF @ a pub.
- k
^ permalink raw reply
* [PATCH] Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU code
From: Arnd Bergmann @ 2008-07-18 13:03 UTC (permalink / raw)
To: benh
Cc: Mark Nelson, Roland Dreier, Hans Boettiger, linuxppc-dev,
Peter Altevogt, cbe-oss-dev
In-Reply-To: <1216325457.7740.357.camel@pasglop>
Introduce a new dma attriblue DMA_ATTR_WEAK_ORDERING to use weak ordering
on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU
implementation to use this code.
Dynamic mappings can be weakly or strongly ordered on an individual basis
but the fixed mapping has to be either completely strong or completely weak.
This is currently decided by a kernel boot option (pass iommu_fixed=weak
for a weakly ordered fixed linear mapping, strongly ordered is the default).
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
On Thursday 17 July 2008, Benjamin Herrenschmidt wrote:
> In the meantime, send a patch that defaults to strong with explicit
> weak, we can easily fixup after that.
>
Ok, this is the previous version of the patch from Mark, which
does exactly that. Please use this one instead.
Documentation/DMA-attributes.txt | 9 ++
arch/powerpc/platforms/cell/iommu.c | 113 ++++++++++++++++++++++++++++++++++--
include/linux/dma-attrs.h | 1
3 files changed, 118 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux-2.6/arch/powerpc/platforms/cell/iommu.c
@@ -198,6 +198,8 @@ static void tce_build_cell(struct iommu_
base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW |
(window->ioid & IOPTE_IOID_Mask);
#endif
+ if (unlikely(dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs)))
+ base_pte &= ~IOPTE_SO_RW;
io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
@@ -538,7 +540,9 @@ static struct cbe_iommu *cell_iommu_for_
static unsigned long cell_dma_direct_offset;
static unsigned long dma_iommu_fixed_base;
-struct dma_mapping_ops dma_iommu_fixed_ops;
+
+/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */
+static int iommu_fixed_is_weak;
static struct iommu_table *cell_get_iommu_table(struct device *dev)
{
@@ -562,6 +566,98 @@ static struct iommu_table *cell_get_iomm
return &window->table;
}
+/* A coherent allocation implies strong ordering */
+
+static void *dma_fixed_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+ if (iommu_fixed_is_weak)
+ return iommu_alloc_coherent(dev, cell_get_iommu_table(dev),
+ size, dma_handle,
+ device_to_mask(dev), flag,
+ dev->archdata.numa_node);
+ else
+ return dma_direct_ops.alloc_coherent(dev, size, dma_handle,
+ flag);
+}
+
+static void dma_fixed_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle)
+{
+ if (iommu_fixed_is_weak)
+ iommu_free_coherent(cell_get_iommu_table(dev), size, vaddr,
+ dma_handle);
+ else
+ dma_direct_ops.free_coherent(dev, size, vaddr, dma_handle);
+}
+
+static dma_addr_t dma_fixed_map_single(struct device *dev, void *ptr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ return dma_direct_ops.map_single(dev, ptr, size, direction,
+ attrs);
+ else
+ return iommu_map_single(dev, cell_get_iommu_table(dev), ptr,
+ size, device_to_mask(dev), direction,
+ attrs);
+}
+
+static void dma_fixed_unmap_single(struct device *dev, dma_addr_t dma_addr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ dma_direct_ops.unmap_single(dev, dma_addr, size, direction,
+ attrs);
+ else
+ iommu_unmap_single(cell_get_iommu_table(dev), dma_addr, size,
+ direction, attrs);
+}
+
+static int dma_fixed_map_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ return dma_direct_ops.map_sg(dev, sg, nents, direction, attrs);
+ else
+ return iommu_map_sg(dev, cell_get_iommu_table(dev), sg, nents,
+ device_to_mask(dev), direction, attrs);
+}
+
+static void dma_fixed_unmap_sg(struct device *dev, struct scatterlist *sg,
+ int nents, enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (iommu_fixed_is_weak == dma_get_attr(DMA_ATTR_WEAK_ORDERING, attrs))
+ dma_direct_ops.unmap_sg(dev, sg, nents, direction, attrs);
+ else
+ iommu_unmap_sg(cell_get_iommu_table(dev), sg, nents, direction,
+ attrs);
+}
+
+static int dma_fixed_dma_supported(struct device *dev, u64 mask)
+{
+ return mask == DMA_64BIT_MASK;
+}
+
+static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask);
+
+struct dma_mapping_ops dma_iommu_fixed_ops = {
+ .alloc_coherent = dma_fixed_alloc_coherent,
+ .free_coherent = dma_fixed_free_coherent,
+ .map_single = dma_fixed_map_single,
+ .unmap_single = dma_fixed_unmap_single,
+ .map_sg = dma_fixed_map_sg,
+ .unmap_sg = dma_fixed_unmap_sg,
+ .dma_supported = dma_fixed_dma_supported,
+ .set_dma_mask = dma_set_mask_and_switch,
+};
+
static void cell_dma_dev_setup_fixed(struct device *dev);
static void cell_dma_dev_setup(struct device *dev)
@@ -918,9 +1014,16 @@ static void cell_iommu_setup_fixed_ptab(
pr_debug("iommu: mapping 0x%lx pages from 0x%lx\n", fsize, fbase);
- base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW
+ base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M
| (cell_iommu_get_ioid(np) & IOPTE_IOID_Mask);
+ if (iommu_fixed_is_weak)
+ pr_info("IOMMU: Using weak ordering for fixed mapping\n");
+ else {
+ pr_info("IOMMU: Using strong ordering for fixed mapping\n");
+ base_pte |= IOPTE_SO_RW;
+ }
+
for (uaddr = 0; uaddr < fsize; uaddr += (1 << 24)) {
/* Don't touch the dynamic region */
ioaddr = uaddr + fbase;
@@ -1036,9 +1139,6 @@ static int __init cell_iommu_fixed_mappi
cell_iommu_setup_window(iommu, np, dbase, dsize, 0);
}
- dma_iommu_fixed_ops = dma_direct_ops;
- dma_iommu_fixed_ops.set_dma_mask = dma_set_mask_and_switch;
-
dma_iommu_ops.set_dma_mask = dma_set_mask_and_switch;
set_pci_dma_ops(&dma_iommu_ops);
@@ -1052,6 +1152,9 @@ static int __init setup_iommu_fixed(char
if (strcmp(str, "off") == 0)
iommu_fixed_disabled = 1;
+ else if (strcmp(str, "weak") == 0)
+ iommu_fixed_is_weak = 1;
+
return 1;
}
__setup("iommu_fixed=", setup_iommu_fixed);
Index: linux-2.6/Documentation/DMA-attributes.txt
===================================================================
--- linux-2.6.orig/Documentation/DMA-attributes.txt
+++ linux-2.6/Documentation/DMA-attributes.txt
@@ -22,3 +22,12 @@ ready and available in memory. The DMA
could race with data DMA. Mapping the memory used for completion
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
+DMA_ATTR_WEAK_ORDERING
+----------------------
+
+DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
+may be weakly ordered, that is that reads and writes may pass each other.
+
+Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
+those that do not will simply ignore the attribute and exhibit default
+behavior.
Index: linux-2.6/include/linux/dma-attrs.h
===================================================================
--- linux-2.6.orig/include/linux/dma-attrs.h
+++ linux-2.6/include/linux/dma-attrs.h
@@ -12,6 +12,7 @@
*/
enum dma_attr {
DMA_ATTR_WRITE_BARRIER,
+ DMA_ATTR_WEAK_ORDERING,
DMA_ATTR_MAX,
};
^ permalink raw reply
* Re: 2.6.26 does not boot on Pegasos
From: Matt Sealey @ 2008-07-18 12:14 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev list
In-Reply-To: <20080715155944.GA11881@iram.es>
Gabriel Paubert wrote:
> On Tue, Jul 15, 2008 at 04:27:49PM +0100, Matt Sealey wrote:
>> If you built this kernel yourself, you need to do it from a system with
>> an up-to-date binutils (2.18) otherwise, it does this.
Note to the linux-ppc guys; is there any changelog entry which reports
this requirement somewhere? I didn't find one...
> Thanks, this is likely the problem. The distribution is Debian stable
> with all security udates but the binutils are still 2.17.
That's generally the problem we had with SuSE 10.3. Debian stable
should be updated by Christmas.. :D
> Trying to add Lenny source does not help, bummer. Aptitude fails
> with an error message like "Dynamic MMap ran out of room".
Ouch. Well, all I can recommend is grabbing the source files from;
http://packages.debian.org/source/testing/binutils
And compiling and installing it manually. There is a bit of a
disparity between glibc support between testing and stable that
the prebuild packages will complain about (you have to install
half of Lenny to do it, which is a bad idea just to update one
package).
Once you have the files you can just use "dpkg -x binutils-blah.dsc"
to get going.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
From: Sebastian Siewior @ 2008-07-18 12:10 UTC (permalink / raw)
To: Andy Fleming; +Cc: Nate Case, netdev, linuxppc-dev, Vitaly Bordug, Li Yang
Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping]
changed the phydev->lock from spinlock into a mutex. Now, the following
code path got triggered while NFS was unavailable:
|[ 21.287359] nfs: server 10.11.3.47 not responding, still trying
|[ 38.891373] nfs: server 10.11.3.47 not responding, still trying
|[ 148.179592] INFO: task udevd:1762 blocked for more than 120 seconds.
|[ 148.185967] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|[ 148.193810] udevd D 0fef1dd8 0 1762 1761
|[ 148.199055] Call Trace:
|[ 148.201504] [cecdda80] [c00071e4] __switch_to+0x6c/0x84
|[ 148.206764] [cecddaa0] [c025973c] schedule+0x46c/0x4cc
|[ 148.211937] [cecddad0] [c00f3d84] nfs_wait_schedule+0x24/0x38
|[ 148.217712] [cecddae0] [c0259b74] __wait_on_bit_lock+0x68/0xcc
|[ 148.223576] [cecddb00] [c0259c4c] out_of_line_wait_on_bit_lock+0x74/0x88
|[ 148.230300] [cecddb50] [c00f3e6c] __nfs_revalidate_inode+0xd4/0x264
|[ 148.236597] [cecddc20] [c00f1298] nfs_lookup_revalidate+0x1bc/0x3d4
|[ 148.243071] [cecddd80] [c0081db8] do_lookup+0x148/0x1a0
|[ 148.248361] [cecdddb0] [c0083bac] __link_path_walk+0x930/0xe24
|[ 148.254219] [cecdde00] [c00840e8] path_walk+0x48/0xa8
|[ 148.259293] [cecdde30] [c008442c] do_path_lookup+0x160/0x194
|[ 148.264982] [cecdde60] [c0084fe0] __path_lookup_intent_open+0x58/0xa4
|[ 148.271444] [cecdde80] [c007ea54] open_exec+0x2c/0xdc
|[ 148.276525] [cecddef0] [c007efa4] do_execve+0x58/0x1c4
|[ 148.281704] [cecddf20] [c0007568] sys_execve+0x58/0x84
|[ 148.286873] [cecddf40] [c000df58] ret_from_syscall+0x0/0x3c
|[ 169.651632] INFO: task udevsettle:1053 blocked for more than 120 seconds.
some more of this and now the interresting part:
|[ 194.859659] NETDEV WATCHDOG: eth0: transmit timed out
|[ 194.864733] BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:87
|[ 194.875529] in_atomic():1, irqs_disabled():0
|[ 194.879805] Call Trace:
|[ 194.882250] [c0383d90] [c0006dd8] show_stack+0x48/0x184 (unreliable)
|[ 194.888649] [c0383db0] [c001e938] __might_sleep+0xe0/0xf4
|[ 194.894069] [c0383dc0] [c025a43c] mutex_lock+0x24/0x3c
|[ 194.899234] [c0383de0] [c019005c] phy_stop+0x20/0x70
|[ 194.904234] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4
|[ 194.909305] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60
|[ 194.914638] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144
|[ 194.920064] [c0383e30] [c002f93c] run_timer_softirq+0x148/0x1c8
|[ 194.926008] [c0383e60] [c002b084] __do_softirq+0x5c/0xc4
|[ 194.931350] [c0383e80] [c00046fc] do_softirq+0x3c/0x54
|[ 194.936515] [c0383e90] [c002ac60] irq_exit+0x3c/0x5c
|[ 194.941499] [c0383ea0] [c000b378] timer_interrupt+0xe0/0xf8
|[ 194.947097] [c0383ec0] [c000e5ac] ret_from_except+0x0/0x18
|[ 194.952610] [c0383f80] [c000804c] cpu_idle+0xcc/0xdc
|[ 194.957592] [c0383fa0] [c025c07c] etext+0x7c/0x90
|[ 194.962322] [c0383fc0] [c0338960] start_kernel+0x294/0x2a8
|[ 194.967839] [c0383ff0] [c00003dc] skpinv+0x304/0x340
|[ 194.972833] ------------[ cut here ]------------
|[ 194.977450] Badness at /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:134
|[ 194.984589] NIP: c025a268 LR: c025a250 CTR: c017e224
|[ 194.989557] REGS: c0383cf0 TRAP: 0700 Not tainted (2.6.26)
|[ 194.995302] MSR: 00029000 <EE,ME> CR: 28002022 XER: 00000000
|[ 195.001167] TASK = c035e500[0] 'swapper' THREAD: c0382000
|[ 195.006390] GPR00: 00000000 c0383da0 c035e500 00000001 c035e500 00000010 00000000 c0360000
|[ 195.014798] GPR08: 00000000 c0390000 00000001 c0360000 00006353 628a87a2 0ffe8600 00000000
|[ 195.023206] GPR16: cab54ee3 00000000 00000000 0ffe7384 00000000 00000000 0ff904a0 00000000
|[ 195.031612] GPR24: 00000000 00000000 c038e5a4 d1058000 c035e500 cf86b570 cf9c3888 cf9c3888
|[ 195.040199] NIP [c025a268] __mutex_lock_slowpath+0x44/0x1f4
|[ 195.045783] LR [c025a250] __mutex_lock_slowpath+0x2c/0x1f4
|[ 195.051277] Call Trace:
|[ 195.053721] [c0383da0] [cf9c3888] 0xcf9c3888 (unreliable)
|[ 195.059146] [c0383de0] [c019005c] phy_stop+0x20/0x70
|[ 195.064135] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4
|[ 195.069202] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60
|[ 195.074529] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144
|[ 195.079946] [c0383e30] [c002f93c] run_timer_softirq+0x148/0x1c8
|[ 195.085885] [c0383e60] [c002b084] __do_softirq+0x5c/0xc4
|[ 195.091219] [c0383e80] [c00046fc] do_softirq+0x3c/0x54
|[ 195.096374] [c0383e90] [c002ac60] irq_exit+0x3c/0x5c
|[ 195.101353] [c0383ea0] [c000b378] timer_interrupt+0xe0/0xf8
|[ 195.106944] [c0383ec0] [c000e5ac] ret_from_except+0x0/0x18
|[ 195.112447] [c0383f80] [c000804c] cpu_idle+0xcc/0xdc
|[ 195.117426] [c0383fa0] [c025c07c] etext+0x7c/0x90
|[ 195.122147] [c0383fc0] [c0338960] start_kernel+0x294/0x2a8
|[ 195.127655] [c0383ff0] [c00003dc] skpinv+0x304/0x340
|[ 195.132633] Instruction dump:
|[ 195.135422] 90010044 7c5c1378 8009000c 5409012f 41a20024 4bee78dd 2f830000 419e0018
|[ 195.143222] 3d20c039 80098714 2f800000 409e0008 <0fe00000> 7fc000a6 7c000146 801f0024
I found out that the same code path may be trigger in
- drivers/net/ucc_geth.c
- drivers/net/fec_mpc52xx.c
- drivers/net/fs_enet/fs_enet-main.c
other drivers use phy_stop() in ->close only.
Sebastian
^ permalink raw reply
* ml403_emb_ref_ppc_81.zip problem
From: Naresh Bhat @ 2008-07-18 11:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
My problem is explained here...
While creating the new XPS project using Base system Builder:
Step 1.
New Project->Base System builder Project-> Create a new XPS project using
Base system Builder->Browse system.xps project from "ml403_emb_ref_ppc_81"
directory and overite it.
Step 2.
I am selecting "I would like to create the new design"
and then
Board Vendor "Xilinx"
Board name "ML403"
Board version "1"
Step 3:
I just click "Next"
Step 4:
I am selecting the Processor Cloclk Frequency as "300Mhz"
Step 5: Configuring the IO interfaces
Here is my problem.
In RS232 UART I am having the only 2 option
1. XPS_UARTLITE
2. XPS_UART16550
If I use the same base system builder (ml403_emb_ref_ppc_81) with other
version of the EDK tools (like 8.1iSP2, 9.2iSP2). and repeat the same steps
I am able to see the options like
1. OPB_UARTLITE
2. OPB_UART16550
3. PLB_UART16550
Do you have any idea on this Why it is not getting displayed on the
EDK10.1iSP2 version?
Thanks
Naresh Bhat
[-- Attachment #2: Type: text/html, Size: 1389 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-18 10:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080718062937.GA10988@secretlab.ca>
On Fri, Jul 18, 2008 at 12:29:37AM -0600, Grant Likely wrote:
> On Mon, Jul 14, 2008 at 12:45:55PM +0100, Mark Brown wrote:
> > On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
> > This configuration is also exposed via a sysfs file, including some of
> > the configurability. Exposing the information via sysfs isn't a
> > particular problem but allowing it to be written to without going
> > through ALSA seems wrong.
> All the written bit does is trigger the keyclick event. It doesn't
> adjust the parameters in any way.
That should be OK for now but we ought to work out a way of doing this
via an ALSA control so it can be standardised over the devices that
support it. I can't see anything suitable currently, though.
> > > +#if defined(CONFIG_SND_SOC_OF)
> > > + /* Tell the of_soc helper about this codec */
> > > + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
> > > + spi->dev.archdata.of_node);
> > > +#endif
> > CONFIG_SND_SOC_OF could be a module - this needs to also check for it
> > being a module.
> Doesn't #if defined() match on both static and module selection?
Sadly not.
^ 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