* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Becky Bruce @ 2009-05-27 19:11 UTC (permalink / raw)
To: Ian Campbell
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org, Jeremy Fitzhardinge,
linux-kernel@vger.kernel.org
In-Reply-To: <1243342307.9295.86.camel@zakaz.uk.xensource.com>
On May 26, 2009, at 7:51 AM, Ian Campbell wrote:
> On Fri, 2009-05-22 at 19:55 -0400, Jeremy Fitzhardinge wrote:
>> Ian Campbell wrote:
>>> On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
>>>
>>>> I can work with that, but it's going to be a bit inefficient, as I
>>>> actually need the dma_addr_t, not the phys_addr_t, so I'll have to
>>>> convert. In every case, this is a conversion I've already done and
>>>> that I need in the calling code as well.
>>>>
>>>
>>> Does
>>>
>>> dma_addr_t dma_map_range(struct device *hwdev, phys_addr_t addr,
>>> size_t size);
>>>
>>> work for you?
>>>
>>> If the range does not need mapping then it returns the dma
>>> address, if
>>> you needed to calculate the dma address anyway to figure out if
>>> mapping
>>> is required then this is fine. If the range does need mapping then
>>> it
>>> returns NULL.
>>>
>>
>> My only concern is whether dma_addr_t == 0 is actually equivalent to
>> NULL. That is, can we be sure that address 0 will never be used?
>
> It seems not, ~0UL might have been an option, but...
>
>> Taking dma_alloc_coherent as a model, we could have something like:
>>
>> int dma_map_range(struct device *hwdev, phys_addr_t addr, size_t
>> size, dma_addr_t *dma_addrp);
>>
>>
>> where *dma_addrp is set if the function returns success (bool return
>> type might be clearer).
>
> ... this sounds like a good idea to me.
I agree. This will work for me as well.
-becky
^ permalink raw reply
* [Solved/Patch Question] Weird 5200/mtd-ram problem
From: Albrecht Dreß @ 2009-05-27 19:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090525214718.GA8152@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
Hi all:
Am 25.05.09 23:47 schrieb(en) Wolfram Sang:
>> A word or long copy of 0x0055aaff with U-Boot works fine, but a byte
>> copy filled the whole ram with 0x0000aaaa. The reason is apparently
>> that the chip is attached to the local bus in 16-bit mode, which is
>> incompatible with byte accesses. However, the Local Bus doesn't
>> provide "low byte" or "high byte" indicators in non-muxed mode. How
>> is this supposed to work then?
>
> Hmm, as I feared... we were bitten by this, too:
>
> http://thread.gmane.org/gmane.linux.drivers.mtd/21521
>
> There is no generic solution yet :(
At least for my case, I could completely (afaict) solve the problem,
i.e. I can now access the 16-bit nv ram as mtd char and block device,
the latter with jffs2. I would like to submit a patch, but I actually
don't know exactly how...
The solution itself is quite simple: add a new method which works like
memcpy_toio, but respects the fact that no single bytes may be written
(reading through memcpy_fromio works painlessly). I think this
function should go into arch/powerpc/kernel/io.c, depending upon
CONFIG_PPC_MPC52xx, and the prototype into
arch/powerpc/include/asm/io.h, right?
The harder part is to actually call this function properly. I now call
it in include/linux/mtd/map.h, function inline_map_copy_to(), if
CONFIG_PPC_MPC52xx is defined and if map->bankwidth is 2. However, is
it acceptable to have a processor-type dependency in a top-level
include file? Or what would be the proper way to implement it?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Albrecht Dreß @ 2009-05-27 20:00 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
This trivial patch changes memcpy_(to|from)io as to transfer as many
32-bit words as possible in 32-bit accesses (in the current solution,
the last 32-bit word was transferred as 4 byte accesses).
Signed-off-by: Albrecht Dreß <albrecht.dress@arcor.de>
---
diff -urpN -X linux-2.6.29.1.orig/Documentation/dontdiff
linux-2.6.29.1.orig/arch/powerpc/kernel/io.c
linux-2.6.29.1/arch/powerpc/kernel/io.c
--- linux-2.6.29.1.orig/arch/powerpc/kernel/io.c 2009-04-02
22:55:27.000000000 +0200
+++ linux-2.6.29.1/arch/powerpc/kernel/io.c 2009-05-27
11:36:09.000000000 +0200
@@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const vo
dest++;
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
vsrc += 4;
@@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem
vdest++;
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
vdest += 4;
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Ian Campbell @ 2009-05-27 20:29 UTC (permalink / raw)
To: Becky Bruce
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org, Jeremy Fitzhardinge,
linux-kernel@vger.kernel.org
In-Reply-To: <0628DF07-E085-4CC8-ADFC-1B0798343159@kernel.crashing.org>
On Wed, 2009-05-27 at 15:05 -0400, Becky Bruce wrote:
> On May 22, 2009, at 6:11 AM, Ian Campbell wrote:
> >
> >
> > BTW do you need swiotlb_bus_to_virt to be __weak or is the fact that
> > it
> > is implemented in terms of swiotlb_bus_to_phys sufficient?
>
> The default one in swiotlb calls phys_to_virt on the result of
> swiotlb_bus_to_phys, which only works on lowmem.
Perhaps we can simply enhance the default one to handle highmem instead
of making it arch specific?
Ian.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Becky Bruce @ 2009-05-27 22:11 UTC (permalink / raw)
To: Ian Campbell
Cc: FUJITA Tomonori, linuxppc-dev@ozlabs.org, Jeremy Fitzhardinge,
linux-kernel@vger.kernel.org
In-Reply-To: <1243456159.4399.42.camel@localhost.localdomain>
On May 27, 2009, at 3:29 PM, Ian Campbell wrote:
> On Wed, 2009-05-27 at 15:05 -0400, Becky Bruce wrote:
>> On May 22, 2009, at 6:11 AM, Ian Campbell wrote:
>>>
>>>
>>> BTW do you need swiotlb_bus_to_virt to be __weak or is the fact that
>>> it
>>> is implemented in terms of swiotlb_bus_to_phys sufficient?
>>
>> The default one in swiotlb calls phys_to_virt on the result of
>> swiotlb_bus_to_phys, which only works on lowmem.
>
> Perhaps we can simply enhance the default one to handle highmem
> instead
> of making it arch specific?
That's fine by me - as long as what I've got will work for you guys
I'm happy to stick it in the standard one (inside a nice pretty #ifdef
CONFIG_HIGHMEM, of course).
Cheers,
B
^ permalink raw reply
* Re: [PATCH] v2: Display processor virtualization resource allocations in lparcfg
From: Michael Ellerman @ 2009-05-28 0:31 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <4A1D5111.10505@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
On Wed, 2009-05-27 at 09:41 -0500, Nathan Fontenot wrote:
> This patch updates the output from /proc/ppc64/lparcfg to display the
> processor virtualization resource allocations for a shared processor
> partition.
>
> This information is already gathered via the h_get_ppp call, we just
> have to make sure that the ibm,partition-performance-parameters-level
> property is >= 1 to ensure that the information is valid.
> @@ -267,6 +281,28 @@
> seq_printf(m, "capped=%d\n", ppp_data.capped);
> seq_printf(m, "unallocated_capacity=%lld\n",
> ppp_data.unallocated_entitlement);
> +
> + /* The last bits of information returned from h_get_ppp are only
> + * valid if the ibm,partition-performance-parameters-level
> + * property is >= 1.
> + */
> + root = of_find_node_by_path("/");
> + if (root) {
> + perf_level = of_get_property(root,
> + "ibm,partition-performance-parameters-level",
> + NULL);
> + if (perf_level && (*perf_level >= 1)) {
Yep that looks better, thanks.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Solved/Patch Question] Weird 5200/mtd-ram problem
From: Jon Smirl @ 2009-05-28 3:10 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <1243454097.3489.0@antares>
On Wed, May 27, 2009 at 3:54 PM, Albrecht Dre=DF <albrecht.dress@arcor.de> =
wrote:
> Hi all:
>
> Am 25.05.09 23:47 schrieb(en) Wolfram Sang:
>>>
>>> A word or long copy of 0x0055aaff with U-Boot works fine, but a byte co=
py
>>> filled the whole ram with 0x0000aaaa. =A0The reason is apparently that =
the
>>> chip is attached to the local bus in 16-bit mode, which is incompatible=
with
>>> byte accesses. =A0However, the Local Bus doesn't provide "low byte" or =
"high
>>> byte" indicators in non-muxed mode. =A0How is this supposed to work the=
n?
>>
>> Hmm, as I feared... we were bitten by this, too:
>>
>> http://thread.gmane.org/gmane.linux.drivers.mtd/21521
>>
>> There is no generic solution yet :(
>
> At least for my case, I could completely (afaict) solve the problem, i.e.=
I
> can now access the 16-bit nv ram as mtd char and block device, the latter
> with jffs2. =A0I would like to submit a patch, but I actually don't know
> exactly how...
>
> The solution itself is quite simple: add a new method which works like
> memcpy_toio, but respects the fact that no single bytes may be written
> (reading through memcpy_fromio works painlessly). =A0I think this functio=
n
> should go into arch/powerpc/kernel/io.c, depending upon CONFIG_PPC_MPC52x=
x,
> and the prototype into arch/powerpc/include/asm/io.h, right?
>
> The harder part is to actually call this function properly. =A0I now call=
it
> in include/linux/mtd/map.h, function inline_map_copy_to(), if
> CONFIG_PPC_MPC52xx is defined and if map->bankwidth is 2. =A0However, is =
it
> acceptable to have a processor-type dependency in a top-level include fil=
e?
> =A0Or what would be the proper way to implement it?
This is an old jffs2 patch that was addressing this same problem.
diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index 272872d..c982adc 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -16,6 +16,7 @@
#include <linux/pagemap.h>
#include <linux/crc32.h>
#include <linux/compiler.h>
+#include <asm/io.h>
#include "nodelist.h"
#include "summary.h"
#include "debug.h"
@@ -505,7 +506,7 @@ static int jffs2_scan_eraseblock (struct
jffs2_sb_info *c, struct jffs2_eraseblo
sumptr =3D kmalloc(sumlen, GFP_KERNEL);
if (!sumptr)
return -ENOMEM;
- memcpy(sumptr + sumlen - buf_len, buf + buf_size - buf_len, buf_len);
+ memcpy_fromio(sumptr + sumlen - buf_len, buf + buf_size -
buf_len, buf_len);
}
if (buf_len < sumlen) {
/* Need to read more so that the entire summary node is present */
@@ -1035,7 +1036,7 @@ static int jffs2_scan_dirent_node(struct
jffs2_sb_info *c, struct jffs2_eraseblo
if (!fd) {
return -ENOMEM;
}
- memcpy(&fd->name, rd->name, checkedlen);
+ memcpy_fromio(&fd->name, rd->name, checkedlen);
fd->name[checkedlen] =3D 0;
crc =3D crc32(0, fd->name, rd->nsize);
>
> Thanks, Albrecht.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Sean MacLennan @ 2009-05-28 3:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243226023.24376.23.camel@pasglop>
On Mon, 25 May 2009 14:33:43 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This is going to .30 if nobody hollers. I've done some testing here
> and it seems to be fine, but more eyes at this stage are much welcome.
Sigh, I didn't get a chance to look at this until tonight. I use
__dma_alloc_coherent in one of the warp drivers because I don't have a
device to pass to dma_alloc_coherent. I was hoping to put it off until
the summer.
I assume I am scuppered without a device:
[ 260.101751] coherent allocation too big (requested 0x5000 mask 0x0)
[ 260.108054] pikadma: Unable to allocate SGL
This is with a NULL passed as the device. And it looks
like if the device is null, it just defaults to ISA_DMA_THRESHOLD,
which is 0 as shown above.
Is there a global platform device or something similar that I can
piggyback off of? There is no bus associated with this driver, so no
device.
Maybe set ISA_DMA_THRESHOLD somewhere? Some platforms seem to set it:
./platforms/52xx/efika.c: ISA_DMA_THRESHOLD = ~0L;
./platforms/amigaone/setup.c: ISA_DMA_THRESHOLD = 0x00ffffff;
./platforms/chrp/setup.c: ISA_DMA_THRESHOLD = ~0L;
./platforms/powermac/setup.c: ISA_DMA_THRESHOLD = ~0L;
So if anybody knows another way around this? The driver is basically
allocating a scatter gather list that is passed to a DMA engine in the
FPGA.
This isn't a showstopper.... we are not planning to move to 2.6.30 in
the near future.
Cheers,
Sean
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Grant Likely @ 2009-05-28 3:42 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090527233451.2d02343d@lappy.seanm.ca>
On Wed, May 27, 2009 at 9:34 PM, Sean MacLennan <smaclennan@pikatech.com> w=
rote:
> On Mon, 25 May 2009 14:33:43 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> This is going to .30 if nobody hollers. I've done some testing here
>> and it seems to be fine, but more eyes at this stage are much welcome.
>
> Sigh, I didn't get a chance to look at this until tonight. I use
> __dma_alloc_coherent in one of the warp drivers because I don't have a
> device to pass to dma_alloc_coherent. I was hoping to put it off until
> the summer.
>
> I assume I am scuppered without a device:
>
> [ =A0260.101751] coherent allocation too big (requested 0x5000 mask 0x0)
> [ =A0260.108054] pikadma: Unable to allocate SGL
>
> This is with a NULL passed as the device. And it looks
> like if the device is null, it just defaults to ISA_DMA_THRESHOLD,
> which is 0 as shown above.
>
> Is there a global platform device or something similar that I can
> piggyback off of? There is no bus associated with this driver, so no
> device.
Make your driver use a platform device or an of_platform device. It's
not at all hard.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Benjamin Herrenschmidt @ 2009-05-28 3:52 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090527233451.2d02343d@lappy.seanm.ca>
On Wed, 2009-05-27 at 23:34 -0400, Sean MacLennan wrote:
> On Mon, 25 May 2009 14:33:43 +1000
../..
You can just make it a platform device I suppose. In the meantime...
> Maybe set ISA_DMA_THRESHOLD somewhere? Some platforms seem to set it:
>
> ./platforms/52xx/efika.c: ISA_DMA_THRESHOLD = ~0L;
> ./platforms/amigaone/setup.c: ISA_DMA_THRESHOLD = 0x00ffffff;
> ./platforms/chrp/setup.c: ISA_DMA_THRESHOLD = ~0L;
> ./platforms/powermac/setup.c: ISA_DMA_THRESHOLD = ~0L;
>
> So if anybody knows another way around this? The driver is basically
> allocating a scatter gather list that is passed to a DMA engine in the
> FPGA.
>
> This isn't a showstopper.... we are not planning to move to 2.6.30 in
> the near future.
Can't you set ISA_DMA_THRESHOLD = ~0L from your warp.c platform file ?
Cheers,
Ben.
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Sean MacLennan @ 2009-05-28 4:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1243482749.3171.80.camel@pasglop>
On Thu, 28 May 2009 13:52:29 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Can't you set ISA_DMA_THRESHOLD = ~0L from your warp.c platform file ?
I actually set it in the driver proper since it is faster to test, but
it works. I am just wondering how kosher that is.
The advantage of the platform_device is I can go back to using the top
level function. And I suspect down the road the __dma* functions may
require a real device.
However, the ISA_DMA_THRESHOLD = ~0L is a less intrusive patch.
Cheers,
Sean
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Benjamin Herrenschmidt @ 2009-05-28 4:19 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090528001152.6c00b238@lappy.seanm.ca>
On Thu, 2009-05-28 at 00:11 -0400, Sean MacLennan wrote:
> On Thu, 28 May 2009 13:52:29 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Can't you set ISA_DMA_THRESHOLD = ~0L from your warp.c platform file ?
>
> I actually set it in the driver proper since it is faster to test, but
> it works. I am just wondering how kosher that is.
Set it in warp.c and send me a patch for 2.6.30, we can have a proper
device bound to it for .31.
> The advantage of the platform_device is I can go back to using the top
> level function. And I suspect down the road the __dma* functions may
> require a real device.
>
> However, the ISA_DMA_THRESHOLD = ~0L is a less intrusive patch.
Yes until you have a proper device probed of the device-tree.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Kumar Gala @ 2009-05-28 4:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: FUJITA Tomonori, linuxppc-dev list
In-Reply-To: <13F18475-1D3E-4D9E-B10C-8BE48FBA9DF5@kernel.crashing.org>
Ben,
Any comments on this.. need a decision so we can have patches ready
for .31.
- k
On May 19, 2009, at 8:04 AM, Kumar Gala wrote:
>
> On May 18, 2009, at 4:49 PM, Benjamin Herrenschmidt wrote:
>
>> On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
>>>
>>> Part of this is how the generic swiotlb code works and part of it
>>> was
>>> our desire not to bloat dev archdata by adding such info that as you
>>> say is either bus specific or conveyed in the dma addr mask.
>>
>> Right but perf sucks :-)
>>
>> Maybe an option is to clamp the DMA mask when it's set by the
>> driver to
>> limit it to the available inbound window ?
>
> Clamping the DMA mask is even worse than the additional indirection
> for us. We have valid scenarios in which we'd have 512M of outbound
> PCI address space and 4G of mem and thus 3.5G of inbound PCI address
> space. With the DMA mask we'd be limited to 2G and bouncing from
> 2..3.5G when we don't need to.
>
> I think our options are to change archdata as follows:
>
> Option 1 - just add a new data member to dev_archdata
>
> struct dev_archdata {
> /* Optional pointer to an OF device node */
> struct device_node *of_node;
>
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> void *dma_data;
> dma_addr_t direct_dma_addr;
> };
>
> Option 2 - introduce a proper container for how we use dma_data.
> This may just be moving the indirection from an indirection function
> call to an indirection data reference:
>
> struct dma_data {
> dma_addr_t offset;
> dma_addr_t direct_dma_addr;
> struct iommu_table *iommu_table;
> };
>
> struct dev_archdata {
> /* Optional pointer to an OF device node */
> struct device_node *of_node;
>
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> struct dma_data *dma_data;
> };
>
> Option 3 - use dma_data to keep the addr at which we need to bounce
> vs not for SWIOTLB - this has potential issues w/conflicting with
> dma_data being used as the dma_offset. (need to think on that a bit
> more). Additionally this has the benefit in that we need dma_data
> to be a 64-bit quantity on ppc32 w/>32-bit phys addr.
>
> struct dev_archdata {
> /* Optional pointer to an OF device node */
> struct device_node *of_node;
>
> /* DMA operations on that device */
> struct dma_mapping_ops *dma_ops;
> dma_addr_t dma_data;
> };
>
> others??
>
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Sean MacLennan @ 2009-05-28 5:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list
In-Reply-To: <fa686aa40905272042yd7b4698gbd1133b4c61c9b87@mail.gmail.com>
On Wed, 27 May 2009 21:42:18 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> Make your driver use a platform device or an of_platform device. It's
> not at all hard.
Here is my first shot.... any other fields that I need to fill in so I
don't have any gotchas?
/* This must exist */
static void warp_device_release(struct device *dev) {}
static struct platform_device warp_device = {
.name = "warp-device",
.id = 0,
.num_resources = 0,
.dev = {
.coherent_dma_mask = ~0ULL,
.release = warp_device_release,
},
};
platform_device_register(&warp_device);
Cheers,
Sean
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Grant Likely @ 2009-05-28 5:09 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090528010000.31423083@lappy.seanm.ca>
On Wed, May 27, 2009 at 11:00 PM, Sean MacLennan
<smaclennan@pikatech.com> wrote:
> On Wed, 27 May 2009 21:42:18 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> Make your driver use a platform device or an of_platform device. =A0It's
>> not at all hard.
>
> Here is my first shot.... any other fields that I need to fill in so I
> don't have any gotchas?
>
> /* This must exist */
> static void warp_device_release(struct device *dev) {}
It will be easier if you do it as an of_device. Then you just need to
add a node to the device tree and it will get registered correctly
without any platform specific registration code. That gives your
driver something to bind against.
However, if you do want to do it this way...
> static struct platform_device warp_device =3D {
> =A0 =A0 =A0 =A0.name =3D "warp-device",
> =A0 =A0 =A0 =A0.id =3D 0,
> =A0 =A0 =A0 =A0.num_resources =3D 0,
> =A0 =A0 =A0 =A0.dev =3D {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.coherent_dma_mask =3D ~0ULL,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.release =3D warp_device_release,
> =A0 =A0 =A0 =A0},
> };
No need for all this. use platform_device_register_simple() instead.
Again, that gives your driver something to bind again, this time on
the platform bus (instead of of_platform bus).
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Benjamin Herrenschmidt @ 2009-05-28 6:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: FUJITA Tomonori, linuxppc-dev list
In-Reply-To: <2CCC4C06-15EC-438B-8BEA-A31690B4FB2C@kernel.crashing.org>
On Wed, 2009-05-27 at 23:42 -0500, Kumar Gala wrote:
> Ben,
>
> Any comments on this.. need a decision so we can have patches ready
> for .31.
> > Clamping the DMA mask is even worse than the additional indirection
> > for us. We have valid scenarios in which we'd have 512M of outbound
> > PCI address space and 4G of mem and thus 3.5G of inbound PCI address
> > space. With the DMA mask we'd be limited to 2G and bouncing from
> > 2..3.5G when we don't need to.
Ok and agreed.
> > I think our options are to change archdata as follows:
> >
> > Option 1 - just add a new data member to dev_archdata
> >
> > struct dev_archdata {
> > /* Optional pointer to an OF device node */
> > struct device_node *of_node;
> >
> > /* DMA operations on that device */
> > struct dma_mapping_ops *dma_ops;
> > void *dma_data;
> > dma_addr_t direct_dma_addr;
> > };
That sounds like the "simple" option, might want for now to make
it conditional on SWIOTLB but the bloat is reasonably small I would
expect.
> > Option 2 - introduce a proper container for how we use dma_data.
> > This may just be moving the indirection from an indirection function
> > call to an indirection data reference:
Right, it somewhat defeats the purpose though an indirect data reference
tends to hit the pipeline less hard than an indirect function call...
> > Option 3 - use dma_data to keep the addr at which we need to bounce
> > vs not for SWIOTLB - this has potential issues w/conflicting with
> > dma_data being used as the dma_offset. (need to think on that a bit
> > more). Additionally this has the benefit in that we need dma_data
> > to be a 64-bit quantity on ppc32 w/>32-bit phys addr.
Well, that means that swiotlb can not be used with a !0 offset. That
-might- be an issue if the PCI is setup "backward", ie with 0..N being
the outbound MMIO and N..4G the DMA region, remapped to 0. There are
reasons to do it this way, it's not invalid, for example it allow easy
access to ISA/VGA holes.
At this stage I have no firm opinion. I'm thinking that either we try
to limit the overhead and option 1 is probably the simplest, at the
expense of a little bit of memory, or we think the overhead is going
to be minimum and we may as well stick to 2 functions since that's
going to be more flexible.
Cheers,
Ben.
^ permalink raw reply
* MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Daniel Ng @ 2009-05-28 7:37 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
a MPC8272-based platform.
So far, the kernel crashes when the driver tries to open (see below).
It seems that the interrupt handler fails to register, with the
following condition in setup_irq() in manage.c:
desc->chip == &no_irq_chip
I notice that the only place where desc->chip is assigned to anything
else besides &no_irq_chip is in __set_irq_handler() in
kernel/irq/chip.c
In that file, __set_irq_handler() assigns desc->chip to
&dummy_irq_chip, but this seems to be done for a special ARM-specific
case, according to the commenting:
/*
* Some ARM implementations install a handler for really dumb
* interrupt hardware without setting an irq_chip. This worked
* with the ARM no_irq_chip but the check in setup_irq would
* prevent us to setup the interrupt at all. Switch it to
* dummy_irq_chip for easy transition.
*/
Should I try to somehow call __set_irq_handler(), or should I be
looking elsewhere?
If I should be calling __set_irq_handler(), it seems the only relevant
function that calls this is cpm2_pic_host_map().
The only relevant functions which call cpm2_pic_host_map() are
irq_setup_virq() or irq_alloc_hosts() with the IRQ_HOST_MAP_LEGACY
parameter. IRQ_HOST_MAP_LEGACY seems to be irrelevant. Can someone
tell me what a virq is?
Cheers,
Daniel
Badness at c00224ec [verbose debug info unavailable]
NIP: c00224ec LR: c019b254 CTR: c01aa9f8
REGS: c1a49c70 TRAP: 0700 Not tainted (2.6.27.19-800-OS-03050107)
MSR: 00021032 <ME,IR,DR> CR: 22002022 XER: 00000000
TASK = c1bda400[306] 'pppd' THREAD: c1a48000
GPR00: 00000001 c1a49d20 c1bda400 00000000 c0318880 c19c4d80 c1b92211 00000000
GPR08: 00001032 c02cb240 00000000 00000000 22002022 fffffffe 01ff8000 00000000
GPR16: 10344020 00000000 00000002 10049ac0 c194f800 ffff8914 c18cd900 c18cd90c
GPR24: c1a49e48 00009032 c1a48000 c02b5fdc 00000002 c19c4d80 c1a48000 c1a48000
NIP [c00224ec] local_bh_enable+0x94/0xb4
LR [c019b254] dev_queue_xmit+0x108/0x580
Call Trace:
[c1a49d20] [c19c4d80] 0xc19c4d80 (unreliable)
[c1a49d30] [c019b254] dev_queue_xmit+0x108/0x580
[c1a49d50] [c016ac98] sppp_flush_xmit+0x20/0x44
[c1a49d60] [c016c0b4] sppp_open+0x80/0xac
[c1a49d80] [c016a104] ppp_open+0x70/0x98
--- Exception: bfd26bb0 at 0x8914
LR = 0xc1a49e90
[c1a49da0] [c01699e0] hdlc_open+0x3c/0x104 (unreliable)
[c1a49dc0] [c016cdd4] ethos_wan_genhdlc_open+0xb0/0xef8
[c1a49df0] [c019c490] dev_open+0xbc/0x120
[c1a49e00] [c019bbc8] dev_change_flags+0x8c/0x1d0
[c1a49e20] [c01e1678] devinet_ioctl+0x700/0x7ac
[c1a49e90] [c01e2538] inet_ioctl+0xcc/0xf8
[c1a49ea0] [c018b584] sock_ioctl+0x60/0x268
[c1a49ec0] [c0084ab0] vfs_ioctl+0x3c/0xc4
[c1a49ee0] [c0084bb8] do_vfs_ioctl+0x80/0x454
[c1a49f10] [c0084fcc] sys_ioctl+0x40/0x88
[c1a49f40] [c000f928] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x480af50c
LR = 0x480af5e4
Instruction dump:
41a20008 482044e1 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c02d
3929b240 800900dc 7c000034 5400d97e <0f000000> 2f800000 41beff90 38000001
hdlc2: Carrier detected
setup_irq()- desc->chip == &no_irq_chip
request_irq()- setup_irq() FAILED
ethos_wan_genhdlc_open(): request_irq() FAILED! ethos_wan->io_addr: 0xc5080000
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Norbert van Bolhuis @ 2009-05-28 10:33 UTC (permalink / raw)
To: Daniel Ng; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <547eba1b0905280037j3336d0av7cc5d4069622d8f4@mail.gmail.com>
Hi Daniel,
"Ethos" driver... hmm. sounds familiar!
(good to hear that it is still used in active development)
About your question.
Since almost 2 years (kernel 2.6.22 from july 2007) the rule is that you can't
directly map a hardware irq number because the powerpc kernel keeps a
mapping between hardware irq numbers and virtual irq numbers.
request_irq() expects a virtual irq number.
Here's some background info why the linux PowerPC kernel works this way:
The basic request_irq() function is generic, but the value of the
arguments (especially the number for the IRQ line) is architecture
specific in many ways. This is one difference between the i386 code
and the powerpc code inside Linux. Most i386 hardware is standard
PC hardware with very clearly defined interrupt sources. Because of
this, the mapping from the numeric IRQ value to a real hardware
interrupt source is defined pretty clearly.
(In fact, not even clearly anymore :-) IE, there are still some legacy
interrupts at fixed numbers but most things are remapped on x86 too
nowadays when using IO_APICs, the kernel obtains numbers from ACPI,
remaps them etc...)
The powerpc architecture code has to support almost arbitrarily complex
hardware, and the embedded world is the source of most of the complexity.
Because of this, the powerpc code has to dynamically allocate those numeric
IRQ sources and tie them to a specific hardware interrupt.
This is why there's a mapping between hardware irq numbers and virtual
irq numbers.
this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel driver
registers for the PIT IRQ (Interrupt ID 65)
#define PIT_IRQ 65
virq = irq_create_mapping(NULL, PIT_IRQ);
set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0)) {
printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n", PIT_IRQ, virq);
}
All the above info comes from this mailing (and the linuxppc-embedd list) though.
If you search these lists you'll find plenty of answers to similar questions.
---
N. van Bolhuis
AimValley
Daniel Ng wrote:
> Hi,
>
> I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
> a MPC8272-based platform.
>
> So far, the kernel crashes when the driver tries to open (see below).
>
> It seems that the interrupt handler fails to register, with the
> following condition in setup_irq() in manage.c:
>
> desc->chip == &no_irq_chip
>
> I notice that the only place where desc->chip is assigned to anything
> else besides &no_irq_chip is in __set_irq_handler() in
> kernel/irq/chip.c
>
> In that file, __set_irq_handler() assigns desc->chip to
> &dummy_irq_chip, but this seems to be done for a special ARM-specific
> case, according to the commenting:
>
> /*
> * Some ARM implementations install a handler for really dumb
> * interrupt hardware without setting an irq_chip. This worked
> * with the ARM no_irq_chip but the check in setup_irq would
> * prevent us to setup the interrupt at all. Switch it to
> * dummy_irq_chip for easy transition.
> */
>
> Should I try to somehow call __set_irq_handler(), or should I be
> looking elsewhere?
>
> If I should be calling __set_irq_handler(), it seems the only relevant
> function that calls this is cpm2_pic_host_map().
>
> The only relevant functions which call cpm2_pic_host_map() are
> irq_setup_virq() or irq_alloc_hosts() with the IRQ_HOST_MAP_LEGACY
> parameter. IRQ_HOST_MAP_LEGACY seems to be irrelevant. Can someone
> tell me what a virq is?
>
> Cheers,
> Daniel
>
>
>
> Badness at c00224ec [verbose debug info unavailable]
> NIP: c00224ec LR: c019b254 CTR: c01aa9f8
> REGS: c1a49c70 TRAP: 0700 Not tainted (2.6.27.19-800-OS-03050107)
> MSR: 00021032 <ME,IR,DR> CR: 22002022 XER: 00000000
> TASK = c1bda400[306] 'pppd' THREAD: c1a48000
> GPR00: 00000001 c1a49d20 c1bda400 00000000 c0318880 c19c4d80 c1b92211 00000000
> GPR08: 00001032 c02cb240 00000000 00000000 22002022 fffffffe 01ff8000 00000000
> GPR16: 10344020 00000000 00000002 10049ac0 c194f800 ffff8914 c18cd900 c18cd90c
> GPR24: c1a49e48 00009032 c1a48000 c02b5fdc 00000002 c19c4d80 c1a48000 c1a48000
> NIP [c00224ec] local_bh_enable+0x94/0xb4
> LR [c019b254] dev_queue_xmit+0x108/0x580
> Call Trace:
> [c1a49d20] [c19c4d80] 0xc19c4d80 (unreliable)
> [c1a49d30] [c019b254] dev_queue_xmit+0x108/0x580
> [c1a49d50] [c016ac98] sppp_flush_xmit+0x20/0x44
> [c1a49d60] [c016c0b4] sppp_open+0x80/0xac
> [c1a49d80] [c016a104] ppp_open+0x70/0x98
> --- Exception: bfd26bb0 at 0x8914
> LR = 0xc1a49e90
> [c1a49da0] [c01699e0] hdlc_open+0x3c/0x104 (unreliable)
> [c1a49dc0] [c016cdd4] ethos_wan_genhdlc_open+0xb0/0xef8
> [c1a49df0] [c019c490] dev_open+0xbc/0x120
> [c1a49e00] [c019bbc8] dev_change_flags+0x8c/0x1d0
> [c1a49e20] [c01e1678] devinet_ioctl+0x700/0x7ac
> [c1a49e90] [c01e2538] inet_ioctl+0xcc/0xf8
> [c1a49ea0] [c018b584] sock_ioctl+0x60/0x268
> [c1a49ec0] [c0084ab0] vfs_ioctl+0x3c/0xc4
> [c1a49ee0] [c0084bb8] do_vfs_ioctl+0x80/0x454
> [c1a49f10] [c0084fcc] sys_ioctl+0x40/0x88
> [c1a49f40] [c000f928] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0x480af50c
> LR = 0x480af5e4
> Instruction dump:
> 41a20008 482044e1 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c02d
> 3929b240 800900dc 7c000034 5400d97e <0f000000> 2f800000 41beff90 38000001
> hdlc2: Carrier detected
> setup_irq()- desc->chip == &no_irq_chip
> request_irq()- setup_irq() FAILED
> ethos_wan_genhdlc_open(): request_irq() FAILED! ethos_wan->io_addr: 0xc5080000
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- "no_irq_chip" error
From: Wolfram Sang @ 2009-05-28 12:33 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev@ozlabs.org, Daniel Ng
In-Reply-To: <4A1E6877.2060106@aimvalley.nl>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
> this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel driver
> registers for the PIT IRQ (Interrupt ID 65)
>
> #define PIT_IRQ 65
>
> virq = irq_create_mapping(NULL, PIT_IRQ);
> set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
>
> if(request_irq(virq, (irq_handler_t)timerEvent, 0, "timer2", (void *)0)) {
> printk(KERN_ERR "request_irq() returned error for irq=%d virq=%d\n", PIT_IRQ, virq);
> }
It is some time ago, but when I did something similar I needed the
following patch in order to use NULL for irq_create_mapping(). Have a
try, and if it is still needed (as it looks from a glimpse), then maybe
we should get it merged?
===
From: Wolfram Sang <w.sang@pengutronix.de>
Subject: [PATCH] powerpc/cpm2: make cpm2_pic the default host
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/powerpc/sysdev/cpm2_pic.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2_pic.c b/arch/powerpc/sysdev/cpm2_pic.c
index 78f1f7c..7a7d4e5 100644
--- a/arch/powerpc/sysdev/cpm2_pic.c
+++ b/arch/powerpc/sysdev/cpm2_pic.c
@@ -272,4 +272,5 @@ void cpm2_pic_init(struct device_node *node)
printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
return;
}
+ irq_set_default_host(cpm2_pic_host);
}
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Kumar Gala @ 2009-05-28 13:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: FUJITA Tomonori, linuxppc-dev list
In-Reply-To: <1243491063.3171.117.camel@pasglop>
On May 28, 2009, at 1:11 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-05-27 at 23:42 -0500, Kumar Gala wrote:
>> Ben,
>>
>> Any comments on this.. need a decision so we can have patches ready
>> for .31.
>
>>> Clamping the DMA mask is even worse than the additional indirection
>>> for us. We have valid scenarios in which we'd have 512M of outbound
>>> PCI address space and 4G of mem and thus 3.5G of inbound PCI address
>>> space. With the DMA mask we'd be limited to 2G and bouncing from
>>> 2..3.5G when we don't need to.
>
> Ok and agreed.
>
>>> I think our options are to change archdata as follows:
>>>
>>> Option 1 - just add a new data member to dev_archdata
>>>
>>> struct dev_archdata {
>>> /* Optional pointer to an OF device node */
>>> struct device_node *of_node;
>>>
>>> /* DMA operations on that device */
>>> struct dma_mapping_ops *dma_ops;
>>> void *dma_data;
>>> dma_addr_t direct_dma_addr;
>>> };
>
> That sounds like the "simple" option, might want for now to make
> it conditional on SWIOTLB but the bloat is reasonably small I would
> expect.
>
>>> Option 2 - introduce a proper container for how we use dma_data.
>>> This may just be moving the indirection from an indirection function
>>> call to an indirection data reference:
>
> Right, it somewhat defeats the purpose though an indirect data
> reference
> tends to hit the pipeline less hard than an indirect function call...
>
>>> Option 3 - use dma_data to keep the addr at which we need to bounce
>>> vs not for SWIOTLB - this has potential issues w/conflicting with
>>> dma_data being used as the dma_offset. (need to think on that a bit
>>> more). Additionally this has the benefit in that we need dma_data
>>> to be a 64-bit quantity on ppc32 w/>32-bit phys addr.
>
> Well, that means that swiotlb can not be used with a !0 offset. That
> -might- be an issue if the PCI is setup "backward", ie with 0..N being
> the outbound MMIO and N..4G the DMA region, remapped to 0. There are
> reasons to do it this way, it's not invalid, for example it allow easy
> access to ISA/VGA holes.
Yeah, realized that after thinking about it a bit more.
> At this stage I have no firm opinion. I'm thinking that either we try
> to limit the overhead and option 1 is probably the simplest, at the
> expense of a little bit of memory, or we think the overhead is going
> to be minimum and we may as well stick to 2 functions since that's
> going to be more flexible.
If you don't have a firm opinion I would ask you pull in this patch as
it is in your next tree. If we decide to move away from the 2
function method and use a little bit more memory per dev_archdata we
at least have the history in the tree of the 2 function method.
- k
^ permalink raw reply
* [PATCH 2/4] fsl_pq_mido: Set the first UCC as the mii management interface master
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
In-Reply-To: <12435168302841-git-send-email-Haiying.Wang@freescale.com>
Current code makes the UCC whose register range includes the current mdio
register to be the MII managemnt interface master of the QE. If there is more
than one mdio bus for QE, the UCC of the last mdio bus will be the MII
management interface master which will make the primary mdio bus working
unproperly, e.g. can notget the right clock. Normally the primary mdio bus is
the first UEC's mdio bus.
This patch allows the first UCC to be the MII management interface master of the
multiple UCC mdio buses.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/net/fsl_pq_mdio.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index aa1eb88..fd317a0 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -338,13 +338,17 @@ static int fsl_pq_mdio_probe(struct of_device *ofdev,
of_device_is_compatible(np, "ucc_geth_phy")) {
#ifdef CONFIG_UCC_GETH
u32 id;
+ static u32 mii_mng_master;
tbipa = ®s->utbipar;
if ((err = get_ucc_id_for_range(addr, addr + size, &id)))
goto err_free_irqs;
- ucc_set_qe_mux_mii_mng(id - 1);
+ if (!mii_mng_master) {
+ mii_mng_master = id;
+ ucc_set_qe_mux_mii_mng(id - 1);
+ }
#else
err = -ENODEV;
goto err_free_irqs;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
In-Reply-To: <12435168351655-git-send-email-Haiying.Wang@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
arch/powerpc/boot/dts/mpc8569mds.dts | 63 ++++++++++++++++++++++++++++++++++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..4e95abd 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -24,6 +24,8 @@
ethernet1 = &enet1;
ethernet2 = &enet2;
ethernet3 = &enet3;
+ ethernet5 = &enet5;
+ ethernet7 = &enet7;
pci1 = &pci1;
rapidio0 = &rio0;
};
@@ -466,6 +468,37 @@
reg = <0x3>;
device_type = "ethernet-phy";
};
+ qe_phy5: ethernet-phy@04 {
+ interrupt-parent = <&mpic>;
+ reg = <0x04>;
+ device_type = "ethernet-phy";
+ };
+ qe_phy7: ethernet-phy@06 {
+ interrupt-parent = <&mpic>;
+ reg = <0x6>;
+ device_type = "ethernet-phy";
+ };
+ };
+ mdio@3520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3520 0x18>;
+ compatible = "fsl,ucc-mdio";
+
+ tbi0: tbi-phy@15 {
+ reg = <0x15>;
+ device_type = "tbi-phy";
+ };
+ };
+ mdio@3720 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3720 0x38>;
+ compatible = "fsl,ucc-mdio";
+ tbi1: tbi-phy@17 {
+ reg = <0x17>;
+ device_type = "tbi-phy";
+ };
};
enet2: ucc@2200 {
@@ -513,6 +546,36 @@
phy-connection-type = "rgmii-id";
};
+ enet5: ucc@3400 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <6>;
+ reg = <0x3400 0x200>;
+ interrupts = <41>;
+ interrupt-parent = <&qeic>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ rx-clock-name = "none";
+ tx-clock-name = "none";
+ tbi-handle = <&tbi0>;
+ phy-handle = <&qe_phy5>;
+ phy-connection-type = "sgmii";
+ };
+
+ enet7: ucc@3600 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ cell-index = <8>;
+ reg = <0x3600 0x200>;
+ interrupts = <43>;
+ interrupt-parent = <&qeic>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ rx-clock-name = "none";
+ tx-clock-name = "none";
+ tbi-handle = <&tbi1>;
+ phy-handle = <&qe_phy7>;
+ phy-connection-type = "sgmii";
+ };
+
muram@10000 {
#address-cells = <1>;
#size-cells = <1>;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/4] net/phy/marvell: update m88e1111 support for SGMII mode
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
Disable fiber/copper auto selection for Marvell m88e1111 SGMII support.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/net/phy/marvell.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7a3ec9d..dd6f54d 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -243,6 +243,7 @@ static int m88e1111_config_init(struct phy_device *phydev)
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
temp |= MII_M1111_HWCFG_MODE_SGMII_NO_CLK;
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 3/4] net/ucc_geth: Add SGMII support for UEC GETH driver Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
From: Haiying Wang @ 2009-05-28 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, galak; +Cc: Haiying Wang
In-Reply-To: <1243516833328-git-send-email-Haiying.Wang@freescale.com>
---
arch/powerpc/include/asm/qe.h | 2 +
drivers/net/ucc_geth.c | 79 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/ucc_geth.h | 28 ++++++++++++++-
3 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index e0faf33..157c5ca 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -675,6 +675,8 @@ struct ucc_slow_pram {
#define UCC_GETH_UPSMR_RMM 0x00001000
#define UCC_GETH_UPSMR_CAM 0x00000400
#define UCC_GETH_UPSMR_BRO 0x00000200
+#define UCC_GETH_UPSMR_SMM 0x00000080
+#define UCC_GETH_UPSMR_SGMM 0x00000020
/* UCC Transmit On Demand Register (UTODR) */
#define UCC_SLOW_TOD 0x8000
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9dd16c9..dca4f4e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2007 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2009 Freescale Semicondutor, Inc. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -64,6 +64,8 @@
static DEFINE_SPINLOCK(ugeth_lock);
+static void uec_configure_serdes(struct net_device *dev);
+
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -1409,6 +1411,9 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UCC_GETH_UPSMR_TBIM;
}
+ if ((ugeth->phy_interface == PHY_INTERFACE_MODE_SGMII))
+ upsmr |= UCC_GETH_UPSMR_SGMM;
+
out_be32(&uf_regs->upsmr, upsmr);
/* Disable autonegotiation in tbi mode, because by default it
@@ -1546,6 +1551,9 @@ static int init_phy(struct net_device *dev)
phydev = phy_connect(dev, ug_info->phy_bus_id, &adjust_link, 0,
priv->phy_interface);
+ if (priv->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ uec_configure_serdes(dev);
+
if (IS_ERR(phydev)) {
printk("%s: Could not attach to PHY\n", dev->name);
return PTR_ERR(phydev);
@@ -1566,7 +1574,41 @@ static int init_phy(struct net_device *dev)
return 0;
}
+/* Initialize TBI PHY interface for communicating with the
+ * SERDES lynx PHY on the chip. We communicate with this PHY
+ * through the MDIO bus on each controller, treating it as a
+ * "normal" PHY at the address found in the UTBIPA register. We assume
+ * that the UTBIPA register is valid. Either the MDIO bus code will set
+ * it to a value that doesn't conflict with other PHYs on the bus, or the
+ * value doesn't matter, as there are no other PHYs on the bus.
+ */
+static void uec_configure_serdes(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ if (!ugeth->tbiphy) {
+ printk(KERN_WARNING "SGMII mode requires that the device "
+ "tree specify a tbi-handle\n");
+ return;
+ }
+
+ /*
+ * If the link is already up, we must already be ok, and don't need to
+ * configure and reset the TBI<->SerDes link. Maybe U-Boot configured
+ * everything for us? Resetting it takes the link down and requires
+ * several seconds for it to come back.
+ */
+ if (phy_read(ugeth->tbiphy, ENET_TBI_MII_SR) & TBISR_LSTATUS)
+ return;
+
+ /* Single clk mode, mii mode off(for serdes communication) */
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_ANA, TBIANA_SETTINGS);
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_TBICON, TBICON_CLK_SELECT);
+
+ phy_write(ugeth->tbiphy, ENET_TBI_MII_CR, TBICR_SETTINGS);
+
+}
static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
{
@@ -3506,6 +3548,8 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
+ if (strcasecmp(phy_connection_type, "sgmii") == 0)
+ return PHY_INTERFACE_MODE_SGMII;
return PHY_INTERFACE_MODE_MII;
}
@@ -3552,6 +3596,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
PHY_INTERFACE_MODE_RMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_GMII, PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_TBI, PHY_INTERFACE_MODE_RTBI,
+ PHY_INTERFACE_MODE_SGMII,
};
ugeth_vdbg("%s: IN", __func__);
@@ -3694,6 +3739,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
+ case PHY_INTERFACE_MODE_SGMII:
max_speed = SPEED_1000;
break;
default:
@@ -3776,6 +3822,37 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ugeth->ndev = dev;
ugeth->node = np;
+ /* Find the TBI PHY. If it's not there, we don't support SGMII */
+ ph = of_get_property(np, "tbi-handle", NULL);
+ if (ph) {
+ struct device_node *tbi = of_find_node_by_phandle(*ph);
+ struct of_device *ofdev;
+ struct mii_bus *bus;
+ const unsigned int *id;
+
+ if (!tbi)
+ return 0;
+
+ mdio = of_get_parent(tbi);
+ if (!mdio)
+ return 0;
+
+ ofdev = of_find_device_by_node(mdio);
+
+ of_node_put(mdio);
+
+ id = of_get_property(tbi, "reg", NULL);
+ if (!id)
+ return 0;
+ of_node_put(tbi);
+
+ bus = dev_get_drvdata(&ofdev->dev);
+ if (!bus)
+ return 0;
+
+ ugeth->tbiphy = bus->phy_map[*id];
+ }
+
return 0;
}
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 46bb1d2..24a9739 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ * Copyright (C) Freescale Semicondutor, Inc. 2006-2009. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
*
@@ -193,6 +193,31 @@ struct ucc_geth {
#define ENET_TBI_MII_JD 0x10 /* Jitter diagnostics */
#define ENET_TBI_MII_TBICON 0x11 /* TBI control */
+/* TBI MDIO register bit fields*/
+#define TBISR_LSTATUS 0x0004
+#define TBICON_CLK_SELECT 0x0020
+#define TBIANA_ASYMMETRIC_PAUSE 0x0100
+#define TBIANA_SYMMETRIC_PAUSE 0x0080
+#define TBIANA_HALF_DUPLEX 0x0040
+#define TBIANA_FULL_DUPLEX 0x0020
+#define TBICR_PHY_RESET 0x8000
+#define TBICR_ANEG_ENABLE 0x1000
+#define TBICR_RESTART_ANEG 0x0200
+#define TBICR_FULL_DUPLEX 0x0100
+#define TBICR_SPEED1_SET 0x0040
+
+#define TBIANA_SETTINGS ( \
+ TBIANA_ASYMMETRIC_PAUSE \
+ | TBIANA_SYMMETRIC_PAUSE \
+ | TBIANA_FULL_DUPLEX \
+ )
+#define TBICR_SETTINGS ( \
+ TBICR_PHY_RESET \
+ | TBICR_ANEG_ENABLE \
+ | TBICR_FULL_DUPLEX \
+ | TBICR_SPEED1_SET \
+ )
+
/* UCC GETH MACCFG1 (MAC Configuration 1 Register) */
#define MACCFG1_FLOW_RX 0x00000020 /* Flow Control
Rx */
@@ -1189,6 +1214,7 @@ struct ucc_geth_private {
struct ugeth_mii_info *mii_info;
struct phy_device *phydev;
+ struct phy_device *tbiphy;
phy_interface_t phy_interface;
int max_speed;
uint32_t msg_enable;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH V3 4/4] Fabric bindings for STAC9766 on the Efika
From: Peter Korsgaard @ 2009-05-28 14:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090525013853.3073.78627.stgit@terra>
>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:
Hi,
Jon> Fabric bindings for STAC9766 AC97 codec on the Efika.
Jon> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Jon> ---
Jon> sound/soc/fsl/Kconfig | 8 +++
Jon> sound/soc/fsl/Makefile | 1
Jon> sound/soc/fsl/efika-audio-fabric.c | 95 ++++++++++++++++++++++++++++++++++++
Jon> 3 files changed, 104 insertions(+), 0 deletions(-)
Jon> create mode 100644 sound/soc/fsl/efika-audio-fabric.c
Jon> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
Jon> index 79579ae..f571c6e 100644
Jon> --- a/sound/soc/fsl/Kconfig
Jon> +++ b/sound/soc/fsl/Kconfig
Jon> @@ -47,3 +47,11 @@ config SND_MPC52xx_SOC_PCM030
Jon> help
Jon> Say Y if you want to add support for sound on the Phytec pcm030 baseboard.
Jon> +config SND_MPC52xx_SOC_EFIKA
Jon> + tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
Jon> + depends on PPC_EFIKA
Jon> + select SND_SOC_MPC5200_AC97
Jon> + select SND_SOC_STAC9766
Jon> + help
Jon> + Say Y if you want to add support for sound on the Efika.
Jon> +
Wouldn't it make more sense to make this default y when it has such
specific dependencies and is so deep down in the tree - Most efika
users probably want to enable this if they have enabled ALSA and
SND_SOC?
--
Bye, Peter Korsgaard
^ 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