From: Greg KH <greg@kroah.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ian Abbott <abbotti@mev.co.uk>,
Frank Mori Hess <fmhess@users.sourceforge.net>
Cc: David Miller <davem@davemloft.net>,
subrata@linux.vnet.ibm.com, sachinp@linux.vnet.ibm.com,
sfr@canb.auug.org.au, linux-kernel@vger.kernel.org,
Linuxppc-dev@ozlabs.org, linux-next@vger.kernel.org,
paulus@samba.org, Geert.Uytterhoeven@sonycom.com,
geert@linux-m68k.org
Subject: Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
Date: Fri, 5 Jun 2009 22:51:03 -0700 [thread overview]
Message-ID: <20090606055103.GA9446@kroah.com> (raw)
In-Reply-To: <1244261806.31984.36.camel@pasglop>
On Sat, Jun 06, 2009 at 02:16:46PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote:
> > >
> > > Read my reply to Greg. Why the heck are you trying to map memory
> > > non-cacheable in the first place ?
> >
> > I agree, this is extremely fishy.
> >
> > I guess the issue is that the driver wants consistent DMA memory
> > but wants to allocate a huge area vmap() style.
>
> That's my guess too, and I suppose we should be able to provide an
> appropriate interface for that... There are two aspects that
> are completely separate here:
>
> - One is the allocation of the pages themselves which much match
> the various criteria for DMA'bility to the target device (fit the
> DMA mask, etc...)
>
> - One is the creation of the virtual mapping in kernel space for which
> appropriate pgprot for DMA must be provided.
>
> For the first one, I don't know how legit it would be to allocate the
> pages using dma_alloc_coherent one page at a time and try to figure out
> the struct page * out of it. Sounds fishy and possibly non-portable. So
> appart from using normal GFP and crossing fingers I'm not sure what
> would be the right way to obtain the pages in the first place. Maybe we
> should provide something.
>
> The second could be as simple as having a pgprot_dma_coherent() like we
> have a pgprot_uncached() for example, which would be either uncached or
> cached depending on the consistency of DMA on the platform. But we need
> to run that through things like MIPS which may have additional virtual
> address space requirements.
All good questions. So, let's ask the original authors :)
Frank and Ian, any thoughts about the vmap call in the
comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
is the prealloc_buf buffer used for?
The problem is that PAGE_KERNEL_NOCACHE isn't a "standard" interface,
and not all architectures support it.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ian Abbott <abbotti@mev.co.uk>,
Frank Mori Hess <fmhess@users.sourceforge.net>
Cc: sachinp@linux.vnet.ibm.com, sfr@canb.auug.org.au,
linux-kernel@vger.kernel.org, Linuxppc-dev@ozlabs.org,
linux-next@vger.kernel.org, paulus@samba.org,
Geert.Uytterhoeven@sonycom.com, geert@linux-m68k.org,
subrata@linux.vnet.ibm.com, David Miller <davem@davemloft.net>
Subject: Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
Date: Fri, 5 Jun 2009 22:51:03 -0700 [thread overview]
Message-ID: <20090606055103.GA9446@kroah.com> (raw)
In-Reply-To: <1244261806.31984.36.camel@pasglop>
On Sat, Jun 06, 2009 at 02:16:46PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote:
> > >
> > > Read my reply to Greg. Why the heck are you trying to map memory
> > > non-cacheable in the first place ?
> >
> > I agree, this is extremely fishy.
> >
> > I guess the issue is that the driver wants consistent DMA memory
> > but wants to allocate a huge area vmap() style.
>
> That's my guess too, and I suppose we should be able to provide an
> appropriate interface for that... There are two aspects that
> are completely separate here:
>
> - One is the allocation of the pages themselves which much match
> the various criteria for DMA'bility to the target device (fit the
> DMA mask, etc...)
>
> - One is the creation of the virtual mapping in kernel space for which
> appropriate pgprot for DMA must be provided.
>
> For the first one, I don't know how legit it would be to allocate the
> pages using dma_alloc_coherent one page at a time and try to figure out
> the struct page * out of it. Sounds fishy and possibly non-portable. So
> appart from using normal GFP and crossing fingers I'm not sure what
> would be the right way to obtain the pages in the first place. Maybe we
> should provide something.
>
> The second could be as simple as having a pgprot_dma_coherent() like we
> have a pgprot_uncached() for example, which would be either uncached or
> cached depending on the consistency of DMA on the platform. But we need
> to run that through things like MIPS which may have additional virtual
> address space requirements.
All good questions. So, let's ask the original authors :)
Frank and Ian, any thoughts about the vmap call in the
comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
is the prealloc_buf buffer used for?
The problem is that PAGE_KERNEL_NOCACHE isn't a "standard" interface,
and not all architectures support it.
thanks,
greg k-h
next prev parent reply other threads:[~2009-06-06 5:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 18:26 [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o] Subrata Modak
2009-06-05 18:26 ` Subrata Modak
2009-06-05 18:26 ` Subrata Modak
2009-06-05 18:26 ` Greg KH
2009-06-05 18:26 ` Greg KH
2009-06-05 23:31 ` Benjamin Herrenschmidt
2009-06-05 23:31 ` Benjamin Herrenschmidt
2009-06-05 23:32 ` Benjamin Herrenschmidt
2009-06-05 23:32 ` Benjamin Herrenschmidt
2009-06-06 0:56 ` David Miller
2009-06-06 0:56 ` David Miller
2009-06-06 0:56 ` David Miller
2009-06-06 4:16 ` Benjamin Herrenschmidt
2009-06-06 4:16 ` Benjamin Herrenschmidt
2009-06-06 5:51 ` Greg KH [this message]
2009-06-06 5:51 ` Greg KH
2009-06-06 13:36 ` Frank Mori Hess
2009-06-06 13:36 ` Frank Mori Hess
2009-06-07 14:36 ` Subrata Modak
2009-06-07 14:36 ` Subrata Modak
2009-06-09 3:50 ` Benjamin Herrenschmidt
2009-06-09 3:50 ` Benjamin Herrenschmidt
2009-06-09 18:34 ` Subrata Modak
2009-06-09 18:34 ` Subrata Modak
2009-06-09 18:54 ` Geert Uytterhoeven
2009-06-09 18:54 ` Geert Uytterhoeven
2009-06-09 18:54 ` Geert Uytterhoeven
2009-06-09 22:34 ` Benjamin Herrenschmidt
2009-06-09 22:34 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2009-06-04 13:31 Subrata Modak
2009-06-04 13:31 ` Subrata Modak
2009-06-04 13:31 ` Subrata Modak
2009-06-04 18:07 ` Greg KH
2009-06-04 18:07 ` Greg KH
2009-06-04 18:07 ` Greg KH
2009-06-04 20:40 ` Geert Uytterhoeven
2009-06-04 20:40 ` Geert Uytterhoeven
2009-06-04 20:40 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090606055103.GA9446@kroah.com \
--to=greg@kroah.com \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=Linuxppc-dev@ozlabs.org \
--cc=abbotti@mev.co.uk \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=fmhess@users.sourceforge.net \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=paulus@samba.org \
--cc=sachinp@linux.vnet.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=subrata@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.