* dma_ops->map_page == NULL
@ 2009-07-06 17:51 Kári Davíðsson
2009-07-07 0:15 ` Mark Nelson
2009-07-07 12:50 ` Jon Smirl
0 siblings, 2 replies; 9+ messages in thread
From: Kári Davíðsson @ 2009-07-06 17:51 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
I am doing a driver that uses dma_map_single().
After changing to to linux 2.6.29.3 I am getting
segfaults in dma_map_single() because dma_ops->map_page is NULL.
Actually dma_ops looks funky too.
The driver is an of_platform_driver which is declared as an child of
the lbp (fsl,lpb) node of the device tree.
This is on powerpc 5200b platform.
rg
kd
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-06 17:51 dma_ops->map_page == NULL Kári Davíðsson
@ 2009-07-07 0:15 ` Mark Nelson
2009-07-07 11:08 ` Benjamin Herrenschmidt
2009-07-07 12:50 ` Jon Smirl
1 sibling, 1 reply; 9+ messages in thread
From: Mark Nelson @ 2009-07-07 0:15 UTC (permalink / raw)
To: Kári Davíðsson; +Cc: linuxppc-dev@ozlabs.org
On Tuesday 07 July 2009 03:51:00 K=E1ri Dav=ED=F0sson wrote:
> I am doing a driver that uses dma_map_single().
>=20
> After changing to to linux 2.6.29.3 I am getting
> segfaults in dma_map_single() because dma_ops->map_page is NULL.
> Actually dma_ops looks funky too.
When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
added in favour of map_/unmap_single() (which was later removed in .29)
so you'll have to replace your calls to dma_map_single() with
dma_map_page(). Just pass it the page and offset rather than the address.
Hope that helps!
Mark.
>=20
> The driver is an of_platform_driver which is declared as an child of
> the lbp (fsl,lpb) node of the device tree.
>=20
> This is on powerpc 5200b platform.
>=20
> rg
> kd
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-07 0:15 ` Mark Nelson
@ 2009-07-07 11:08 ` Benjamin Herrenschmidt
2009-07-07 14:37 ` Kumar Gala
2009-07-08 0:44 ` Mark Nelson
0 siblings, 2 replies; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2009-07-07 11:08 UTC (permalink / raw)
To: Mark Nelson
Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org,
Kumar Gala
On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>
> When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
> added in favour of map_/unmap_single() (which was later removed in .29)
> so you'll have to replace your calls to dma_map_single() with
> dma_map_page(). Just pass it the page and offset rather than the address.
Wait a minute ... dma_map_single() should still work, it will just call
dma_map_page() underneath. All dma_ops should have a ->map page
callback.
Do you have any dma_ops set for your device at all ? I wonder how we
set the dma_ops for platform devices nowadays ... We use to have this
fallback to direct ops when the dma_ops are NULL but that is gone and
I see no suitable replacement to set them on platform devices for
embedded archs ... oops...
Kumar, Becky, what's the situation there ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-06 17:51 dma_ops->map_page == NULL Kári Davíðsson
2009-07-07 0:15 ` Mark Nelson
@ 2009-07-07 12:50 ` Jon Smirl
1 sibling, 0 replies; 9+ messages in thread
From: Jon Smirl @ 2009-07-07 12:50 UTC (permalink / raw)
To: Kári Davíðsson; +Cc: linuxppc-dev@ozlabs.org
On Mon, Jul 6, 2009 at 1:51 PM, K=E1ri Dav=ED=F0sson<kari.davidsson@marel.c=
om> wrote:
> I am doing a driver that uses dma_map_single().
>
> After changing to to linux 2.6.29.3 I am getting
> segfaults in dma_map_single() because dma_ops->map_page is NULL.
> Actually dma_ops looks funky too.
>
> The driver is an of_platform_driver which is declared as an child of
> the lbp (fsl,lpb) node of the device tree.
>
> This is on powerpc 5200b platform.
I have hit this before, in my case the driver pointer was null. It
faulted on dma_ops->map_page which had nothing to do with the real
problem which was the null driver pointer. I spent a long time looking
at this until I figured out that the reported error was bogus compared
to the actual problem.
>
> rg
> kd
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-07 11:08 ` Benjamin Herrenschmidt
@ 2009-07-07 14:37 ` Kumar Gala
2009-07-07 15:24 ` Kári Davíðsson
2009-07-07 15:49 ` Becky Bruce
2009-07-08 0:44 ` Mark Nelson
1 sibling, 2 replies; 9+ messages in thread
From: Kumar Gala @ 2009-07-07 14:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mark Nelson, Kári Davíðsson, Kumar Gala,
linuxppc-dev@ozlabs.org
On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>>
>> When the 32 and 64bit DMA code was merged in .28 , map_/
>> unmap_page() was
>> added in favour of map_/unmap_single() (which was later removed in .
>> 29)
>> so you'll have to replace your calls to dma_map_single() with
>> dma_map_page(). Just pass it the page and offset rather than the
>> address.
>
> Wait a minute ... dma_map_single() should still work, it will just
> call
> dma_map_page() underneath. All dma_ops should have a ->map page
> callback.
>
> Do you have any dma_ops set for your device at all ? I wonder how we
> set the dma_ops for platform devices nowadays ... We use to have this
> fallback to direct ops when the dma_ops are NULL but that is gone and
> I see no suitable replacement to set them on platform devices for
> embedded archs ... oops...
>
> Kumar, Becky, what's the situation there ?
>
> Cheers,
> Ben.
Is it possible the dev pointer is not valid? I can't remember if that
was a .29 or .30 change that requires us to start passing a valid dev
pointer to get the proper dma_ops.
- k
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-07 14:37 ` Kumar Gala
@ 2009-07-07 15:24 ` Kári Davíðsson
2009-07-07 15:45 ` Kumar Gala
2009-07-07 15:49 ` Becky Bruce
1 sibling, 1 reply; 9+ messages in thread
From: Kári Davíðsson @ 2009-07-07 15:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: Mark Nelson, linuxppc-dev@ozlabs.org, Kumar Gala
Yes the device pointer was invalid.
I was passing the of_device pointer instead of
the address of of_device->dev.
But I am sure this was working (passing of_device pointer) with
earlier kernels.
Thanks for the help.
rg
kd
Kumar Gala wrote:
> On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>>> When the 32 and 64bit DMA code was merged in .28 , map_/
>>> unmap_page() was
>>> added in favour of map_/unmap_single() (which was later removed in .
>>> 29)
>>> so you'll have to replace your calls to dma_map_single() with
>>> dma_map_page(). Just pass it the page and offset rather than the
>>> address.
>> Wait a minute ... dma_map_single() should still work, it will just
>> call
>> dma_map_page() underneath. All dma_ops should have a ->map page
>> callback.
>>
>> Do you have any dma_ops set for your device at all ? I wonder how we
>> set the dma_ops for platform devices nowadays ... We use to have this
>> fallback to direct ops when the dma_ops are NULL but that is gone and
>> I see no suitable replacement to set them on platform devices for
>> embedded archs ... oops...
>>
>> Kumar, Becky, what's the situation there ?
>>
>> Cheers,
>> Ben.
>
> Is it possible the dev pointer is not valid? I can't remember if that
> was a .29 or .30 change that requires us to start passing a valid dev
> pointer to get the proper dma_ops.
>
> - k
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-07 15:24 ` Kári Davíðsson
@ 2009-07-07 15:45 ` Kumar Gala
0 siblings, 0 replies; 9+ messages in thread
From: Kumar Gala @ 2009-07-07 15:45 UTC (permalink / raw)
To: Kári Davíðsson
Cc: Mark Nelson, linuxppc-dev@ozlabs.org, Kumar Gala
On Jul 7, 2009, at 10:24 AM, K=E1ri Dav=ED=F0sson wrote:
> Yes the device pointer was invalid.
>
> I was passing the of_device pointer instead of
> the address of of_device->dev.
>
> But I am sure this was working (passing of_device pointer) with
> earlier kernels.
>
> Thanks for the help.
>
> rg
> kd
earlier kernels didn't care if the dev pointer was valid and thus let =20=
it pass if you didn't give the proper thing.
- k=
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-07 14:37 ` Kumar Gala
2009-07-07 15:24 ` Kári Davíðsson
@ 2009-07-07 15:49 ` Becky Bruce
1 sibling, 0 replies; 9+ messages in thread
From: Becky Bruce @ 2009-07-07 15:49 UTC (permalink / raw)
To: Kumar Gala
Cc: Mark Nelson, Kári Davíðsson, Kumar Gala,
linuxppc-dev@ozlabs.org
On Jul 7, 2009, at 9:37 AM, Kumar Gala wrote:
>
> On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>>>
>>> When the 32 and 64bit DMA code was merged in .28 , map_/
>>> unmap_page() was
>>> added in favour of map_/unmap_single() (which was later removed
>>> in .29)
>>> so you'll have to replace your calls to dma_map_single() with
>>> dma_map_page(). Just pass it the page and offset rather than the
>>> address.
>>
>> Wait a minute ... dma_map_single() should still work, it will just
>> call
>> dma_map_page() underneath. All dma_ops should have a ->map page
>> callback.
>>
>>
>> Do you have any dma_ops set for your device at all ? I wonder how we
>> set the dma_ops for platform devices nowadays ... We use to have this
>> fallback to direct ops when the dma_ops are NULL but that is gone and
>> I see no suitable replacement to set them on platform devices for
>> embedded archs ... oops...
There is a platform/of bus notifier that sets the dma_ops to a default
value in arch/powerpc/kernel/setup-common.c.
>>
>>
>> Kumar, Becky, what's the situation there ?
>>
>> Cheers,
>> Ben.
>
> Is it possible the dev pointer is not valid? I can't remember if
> that was a .29 or .30 change that requires us to start passing a
> valid dev pointer to get the proper dma_ops.
I'm pretty sure that went into .29. And invalid dev pointer is the
most likely culprit. IIRC, the usual cause of this is that you're
passing in the *wrong* dev pointer. There are often struct
hierarchies with, confusingly, multiple struct device pointers. You
need the one which has archdata dma_ops setup properly. For an of
device, you want the dev pointer that is part of the of_device struct.
If this isn't your problem, then please post some code so we can look
at this further, and post a log of what's happening.
Cheers,
Becky
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: dma_ops->map_page == NULL
2009-07-07 11:08 ` Benjamin Herrenschmidt
2009-07-07 14:37 ` Kumar Gala
@ 2009-07-08 0:44 ` Mark Nelson
1 sibling, 0 replies; 9+ messages in thread
From: Mark Nelson @ 2009-07-08 0:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: Kári Davíðsson, Kumar Gala,
linuxppc-dev@ozlabs.org
On Tuesday 07 July 2009 21:08:25 Benjamin Herrenschmidt wrote:
> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
> >
> > When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
> > added in favour of map_/unmap_single() (which was later removed in .29)
> > so you'll have to replace your calls to dma_map_single() with
> > dma_map_page(). Just pass it the page and offset rather than the address.
>
> Wait a minute ... dma_map_single() should still work, it will just call
> dma_map_page() underneath. All dma_ops should have a ->map page
> callback.
Sorry my mistake - I was thinking of when we removed the map/unmap_single()
from the dma_mapping_ops.
Mark.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-07-08 0:42 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-06 17:51 dma_ops->map_page == NULL Kári Davíðsson
2009-07-07 0:15 ` Mark Nelson
2009-07-07 11:08 ` Benjamin Herrenschmidt
2009-07-07 14:37 ` Kumar Gala
2009-07-07 15:24 ` Kári Davíðsson
2009-07-07 15:45 ` Kumar Gala
2009-07-07 15:49 ` Becky Bruce
2009-07-08 0:44 ` Mark Nelson
2009-07-07 12:50 ` Jon Smirl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).