* 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-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
* 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
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).