DMA API Re: Remove dma_coherent_mem interface

DMA API Re: Remove dma_coherent_mem interface

[ian]

Hi folks.

Please CC me - I am NOT on LKML at present

There was a recent patch to remove the coherent memory interface from
the DMA API.

I'd like to ask that this not happen - there are several users of this
code in the handhelds.org tree, which we hope will merge into mainline.
this code is _essential_ to allow support of these devices.

Removing this from mainline will only increase the hh.org delta which we
are working hard to reduce, and there is no other realistic way to
support these devices.

Thanks,

Ian

Re: DMA API Re: Remove dma_coherent_mem interface

[Matthew Wilcox]

On Wed, Oct 31, 2007 at 09:03:24PM +0000, ian wrote:
> There was a recent patch to remove the coherent memory interface from
> the DMA API.
> 
> I'd like to ask that this not happen - there are several users of this
> code in the handhelds.org tree, which we hope will merge into mainline.
> this code is _essential_ to allow support of these devices.
> 
> Removing this from mainline will only increase the hh.org delta which we
> are working hard to reduce, and there is no other realistic way to
> support these devices.

It's been three years since this API was introduced, and the only
*merged* user is the one that James wrote.  Now it's in the way of some
performance improvements I want to make.  I can't possibly go round every
little platform tree looking for users -- you need to get your drivers
into mainline.  Yes, it's not necessarily a quick process, but equally,
you've had three years.

Now, what driver is it that's going to consume this coherent memory?
Does it use the dma_pool interface, or does it use dma_alloc_coherent
directly?  If the latter, I can retain the dma_declare_coherent_memory
interface.  If the former, then we have to come to a decision between
supporting some drivers that are so unimportant that they haven't been
merged in three years and making a performance win for drivers that are
used every day.

Admittedly, I haven't finished the work to make dma_pool use slub, thus
I don't know what the performance win will turn out to be.  It may not
be significant, so it would be an easy decision to keep the interface.
But if the decision is going to be to keep the interface despite the
lack of users and no matter what the performance win, then I don't need
to finish this work.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: DMA API Re: Remove dma_coherent_mem interface

[ian]

On Wed, 2007-10-31 at 15:34 -0600, Matthew Wilcox wrote:
> On Wed, Oct 31, 2007 at 09:03:24PM +0000, ian wrote:

> It's been three years since this API was introduced, and the only
> *merged* user is the one that James wrote.

Yes I appreciate that.

>   Now it's in the way of some
> performance improvements I want to make.  I can't possibly go round every
> little platform tree looking for users

Agreed - hence why Im taking the trouble to writ e to you now to let you
know the code is in use.

>  -- you need to get your drivers
> into mainline.  Yes, it's not necessarily a quick process, but equally,
> you've had three years.

I've been quite ill, which I admit is not anyone elses fault. Anyhow, to
business...

> Now, what driver is it that's going to consume this coherent memory?

all the TMIO based ASICs that have USB will need this support - thats
three different chips alone.

I believe the mediaQ chipset has similar constraints on its USB and
(IIRC) other devices.

Part of the problem is that these chips are multi-function devices and
as such it takes a lot longer to get all the drivers polished up to a
good state than it would for a single-function chip. I suppose
individual functions could be submitted seperately though.

> Does it use the dma_pool interface, or does it use dma_alloc_coherent
> directly?

At this point, I'd have to check - which I will be doing shortly - I've
jusrt started work on my toshiba devices again, although I started with
AC97, so it wont be right away.

>   If the latter, I can retain the dma_declare_coherent_memory
> interface.  If the former, then we have to come to a decision between
> supporting some drivers that are so unimportant that they haven't been
> merged in three years and making a performance win for drivers that are
> used every day.

As its the OHCI driver doing the allocation, I'd imagine the dma_pool
interface is the one in use.

> Admittedly, I haven't finished the work to make dma_pool use slub, thus
> I don't know what the performance win will turn out to be.

The specific problem for these devices is that they can only DMA to
their internal memory, and cant decode the 32 bit addresses of the bus
they sit on - so whilst they might be mapped at 0x800xxxxx , they see
their address space as being 0x00000 - 0xfffff (for example).

What might work would be if the dma pool interface could use a
device-specified allocator to service its requests, thus most stuff
would use slub (by default) and our devices could specify their own
allocator

>   It may not
> be significant, so it would be an easy decision to keep the interface.
> But if the decision is going to be to keep the interface despite the
> lack of users and no matter what the performance win, then I don't need
> to finish this work.

I dont mind what the interface is as long as we can support devices that
can only DMA from their own local RAM as described above...

:-)

Re: DMA API Re: Remove dma_coherent_mem interface

[Paul Mundt]

On Thu, Nov 01, 2007 at 09:48:46AM +0000, ian wrote:
> On Wed, 2007-10-31 at 15:34 -0600, Matthew Wilcox wrote:
> >   It may not be significant, so it would be an easy decision to keep
> >   the interface.  But if the decision is going to be to keep the
> >   interface despite the lack of users and no matter what the
> >   performance win, then I don't need to finish this work.
> 
> I dont mind what the interface is as long as we can support devices that
> can only DMA from their own local RAM as described above...
> 
Indeed. The SH case for OHCI on MFDs is the same. So that's at least 2
users.

Re: DMA API Re: Remove dma_coherent_mem interface

[ian]

On Thu, 2007-11-01 at 19:07 +0900, Paul Mundt wrote:
> Indeed. The SH case for OHCI on MFDs is the same. So that's at least 2
> users. 

three if you count James SCSI card.

Re: DMA API Re: Remove dma_coherent_mem interface

[Bernhard Walle]

* ian <spyro@f2s.com> [2007-11-01 16:33]:
> On Thu, 2007-11-01 at 19:07 +0900, Paul Mundt wrote:
> > Indeed. The SH case for OHCI on MFDs is the same. So that's at least 2
> > users. 
> 
> three if you count James SCSI card.

Four if you count http://most4linux.sourceforge.net/.


Thanks,
   Bernhard

Re: DMA API Re: Remove dma_coherent_mem interface

[Matthew Wilcox]

On Wed, Oct 31, 2007 at 09:03:24PM +0000, ian wrote:
> I'd like to ask that this not happen - there are several users of this
> code in the handhelds.org tree, which we hope will merge into mainline.
> this code is _essential_ to allow support of these devices.

So ... it's been 4 months.  Any new users merged?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: DMA API Re: Remove dma_coherent_mem interface

[Andi Kleen]

On Wednesday 20 February 2008 18:14:09 Matthew Wilcox wrote:
> On Wed, Oct 31, 2007 at 09:03:24PM +0000, ian wrote:
> > I'd like to ask that this not happen - there are several users of this
> > code in the handhelds.org tree, which we hope will merge into mainline.
> > this code is _essential_ to allow support of these devices.
> 
> So ... it's been 4 months.  Any new users merged?

At least dmam_declare_coherent_memory is completely unused as of 2.6.25-rc*
I plan to remove these.

-Andi
> 

Re: DMA API Re: Remove dma_coherent_mem interface

[ian]

On Wed, 2008-02-20 at 18:49 +0100, Andi Kleen wrote:
> > 
> > So ... it's been 4 months.  Any new users merged?
> 
> At least dmam_declare_coherent_memory is completely unused as of
> 2.6.25-rc* I plan to remove these.

Please do not.

Dmitry and I are still working on getting the users of this into the
kernel.

the chips are multifunction devices, and their drivers are depending on
a lot of incompletely merged code and APIs.

The drivers _are_ working and _are_ in use in a half dozen devices.

I know the delays are a pain but theres a lot of work going on in the
backround on these. The code has not been forgotten.

Re: DMA API Re: Remove dma_coherent_mem interface

[Andi Kleen]

ian wrote:
> On Wed, 2008-02-20 at 18:49 +0100, Andi Kleen wrote:
>>> So ... it's been 4 months.  Any new users merged?
>> At least dmam_declare_coherent_memory is completely unused as of
>> 2.6.25-rc* I plan to remove these.
> 
> Please do not.

Do you use dma_declare_* or dmam_declare_*. The first is used
currently. Only the second is unused.

> 
> Dmitry and I are still working on getting the users of this into the
> kernel.

Is there a time frame on when will this happen? Will you be ready
for the .26 merge window?

> 
> the chips are multifunction devices, and their drivers are depending on
> a lot of incompletely merged code and APIs.

Well if it takes longer the best strategy might be to remove
unused stuff now and you just readd what you need when you
really need it in tree.

-Andi

Re: DMA API Re: Remove dma_coherent_mem interface

[ian]

On Wed, 2008-02-20 at 20:10 +0100, Andi Kleen wrote:
> ian wrote:
> > On Wed, 2008-02-20 at 18:49 +0100, Andi Kleen wrote:
> >>> So ... it's been 4 months.  Any new users merged?
> >> At least dmam_declare_coherent_memory is completely unused as of
> >> 2.6.25-rc* I plan to remove these.
> > 
> > Please do not.
> 
> Do you use dma_declare_* or dmam_declare_*. The first is used
> currently. Only the second is unused.

Ah, sorry, I missed the extra 'm' as I scanned the mail.

We are using the former.

> > Dmitry and I are still working on getting the users of this into the
> > kernel.
> 
> Is there a time frame on when will this happen? Will you be ready
> for the .26 merge window?

I think the big sticking point now is getting the generic clock
interface merged - Dmitry is working hard on that.

The rest of the code is pretty clean now.

> Well if it takes longer the best strategy might be to remove
> unused stuff now and you just readd what you need when you
> really need it in tree.

I think that would not be the best path now.

btw, kernel-discuss@handhelds.org appears to be a dead list these days.

Re: DMA API Re: Remove dma_coherent_mem interface

[Russell King]

On Wed, Feb 20, 2008 at 09:26:55PM +0000, ian wrote:
> 
> On Wed, 2008-02-20 at 20:10 +0100, Andi Kleen wrote:
> > Is there a time frame on when will this happen? Will you be ready
> > for the .26 merge window?
> 
> I think the big sticking point now is getting the generic clock
> interface merged - Dmitry is working hard on that.

And that requires a review from my side, which I've not been able to do
yet...

It seems there's a number of dependencies that the code depends on,
and trying to push to remove an interface which is used on to-be-merged
code which is being _actively_ worked on to bring it to merge standard
is just stupid - that's a recipe for forcing folk into a corner where
they'll never have everything merged that they need for their particular
set of code.

The alternative is that the code which uses it could be merged as is,
albiet without the dependents, so effectively it couldn't be built.
But then it'll satisfy Andi's grep that there are users in the tree.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: DMA API Re: Remove dma_coherent_mem interface

[James Bottomley]

On Wed, 2008-02-20 at 22:55 +0000, Russell King wrote:
> On Wed, Feb 20, 2008 at 09:26:55PM +0000, ian wrote:
> > 
> > On Wed, 2008-02-20 at 20:10 +0100, Andi Kleen wrote:
> > > Is there a time frame on when will this happen? Will you be ready
> > > for the .26 merge window?
> > 
> > I think the big sticking point now is getting the generic clock
> > interface merged - Dmitry is working hard on that.
> 
> And that requires a review from my side, which I've not been able to do
> yet...
> 
> It seems there's a number of dependencies that the code depends on,
> and trying to push to remove an interface which is used on to-be-merged
> code which is being _actively_ worked on to bring it to merge standard
> is just stupid - that's a recipe for forcing folk into a corner where
> they'll never have everything merged that they need for their particular
> set of code.
> 
> The alternative is that the code which uses it could be merged as is,
> albiet without the dependents, so effectively it couldn't be built.
> But then it'll satisfy Andi's grep that there are users in the tree.

Don't worry.  The interface fills a need (allocation of on chip or
behind bridge memory) and we have two in tree users: NCR_Q720 and
ochi-sm501, so it's not going anywhere.

James

Re: DMA API Re: Remove dma_coherent_mem interface

[Paul Mundt]

On Wed, Feb 20, 2008 at 10:14:09AM -0700, Matthew Wilcox wrote:
> On Wed, Oct 31, 2007 at 09:03:24PM +0000, ian wrote:
> > I'd like to ask that this not happen - there are several users of this
> > code in the handhelds.org tree, which we hope will merge into mainline.
> > this code is _essential_ to allow support of these devices.
> 
> So ... it's been 4 months.  Any new users merged?
> 
The sm501 ohci is the case I had mentioned previously, that's in-tree
now.