set_dma_addr missing ?

set_dma_addr missing ?

[Francis Moreau]

Hello,

Sorry to be blind but I can't figure out why this function is missing
for SH architecture ?

Thanks for any helps.
-- 
Francis

Re: set_dma_addr missing ?

[Paul Mundt]

On Sat, Jan 26, 2008 at 10:02:02PM +0100, Francis Moreau wrote:
> Sorry to be blind but I can't figure out why this function is missing
> for SH architecture ?
> 
It's not "missing", it's only enabled if you specifically request support
for the ISA DMA API wrapper. It's a total kludge, since the SH DMAC has
very little in common with how ISA DMA works, but it's provided for
compatability anyways. If you're trying to use this API in a driver,
you're almost definitely doing the wrong thing.

Anyways, you can have it supported by selecting ISA_DMA_API in
arch/sh/Kconfig.

Re: set_dma_addr missing ?

[Francis Moreau]

Hello Paul,

On Jan 28, 2008 3:47 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Sat, Jan 26, 2008 at 10:02:02PM +0100, Francis Moreau wrote:
> > Sorry to be blind but I can't figure out why this function is missing
> > for SH architecture ?
> >
> It's not "missing", it's only enabled if you specifically request support
> for the ISA DMA API wrapper. It's a total kludge, since the SH DMAC has
> very little in common with how ISA DMA works, but it's provided for
> compatability anyways. If you're trying to use this API in a driver,
> you're almost definitely doing the wrong thing.

But what's the other alternative ?

I have a DMA controller, which has very little in common with ISA DMA
as you said.
I'd like to use it from a generic driver. Which API should I use then ?

Thanks
-- 
Francis

Re: set_dma_addr missing ?

[Paul Mundt]

On Mon, Jan 28, 2008 at 09:48:59AM +0100, Francis Moreau wrote:
> On Jan 28, 2008 3:47 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Sat, Jan 26, 2008 at 10:02:02PM +0100, Francis Moreau wrote:
> > > Sorry to be blind but I can't figure out why this function is missing
> > > for SH architecture ?
> > >
> > It's not "missing", it's only enabled if you specifically request support
> > for the ISA DMA API wrapper. It's a total kludge, since the SH DMAC has
> > very little in common with how ISA DMA works, but it's provided for
> > compatability anyways. If you're trying to use this API in a driver,
> > you're almost definitely doing the wrong thing.
> 
> But what's the other alternative ?
> 
> I have a DMA controller, which has very little in common with ISA DMA
> as you said.
> I'd like to use it from a generic driver. Which API should I use then ?
> 
Well, there are two options, either using the existing SH DMA API, or
trying to hook something in through the dmaengine API. The latter is the
way that we'll be moving in the near future, but we do still need to keep
compatability with the existing SH DMA API around in order to avoid
breaking the existing in-tree users.

You may wish to poke around arch/sh/drivers/dma/. There are lots of
greppable things you can find in the rest of tree that show the API,
in-tree users, etc. Post if you have any problems.

Re: set_dma_addr missing ?

[Francis Moreau]

On Jan 28, 2008 10:09 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>
> On Mon, Jan 28, 2008 at 09:48:59AM +0100, Francis Moreau wrote:
> > On Jan 28, 2008 3:47 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > > On Sat, Jan 26, 2008 at 10:02:02PM +0100, Francis Moreau wrote:
> > > > Sorry to be blind but I can't figure out why this function is missing
> > > > for SH architecture ?
> > > >
> > > It's not "missing", it's only enabled if you specifically request support
> > > for the ISA DMA API wrapper. It's a total kludge, since the SH DMAC has
> > > very little in common with how ISA DMA works, but it's provided for
> > > compatability anyways. If you're trying to use this API in a driver,
> > > you're almost definitely doing the wrong thing.
> >
> > But what's the other alternative ?
> >
> > I have a DMA controller, which has very little in common with ISA DMA
> > as you said.
> > I'd like to use it from a generic driver. Which API should I use then ?
> >
> Well, there are two options, either using the existing SH DMA API, or
> trying to hook something in through the dmaengine API.

Woh ! I completely missed the dmaengine API. All DMA documentations I found
were about the DMA-mapping API or the old ISA DMA API.

> The latter is the
> way that we'll be moving in the near future, but we do still need to keep
> compatability with the existing SH DMA API around in order to avoid
> breaking the existing in-tree users.
>

Great. Does that mean that all drivers found in arch/sh/drivers/dma/ will
be converted to use the damengine API except for dma-isa.c ?

> You may wish to poke around arch/sh/drivers/dma/. There are lots of
> greppable things you can find in the rest of tree that show the API,
> in-tree users, etc. Post if you have any problems.

I'll take a deep look into this.

Do you know when the move will happen ?

BTW, I asked some questions about the DMA API on LKML. Here is the
pointer if you're interested:

http://lkml.org/lkml/2008/1/28/65

Thanks a lot
-- 
Francis

Re: set_dma_addr missing ?

[Paul Mundt]

On Mon, Jan 28, 2008 at 11:00:33AM +0100, Francis Moreau wrote:
> On Jan 28, 2008 10:09 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Mon, Jan 28, 2008 at 09:48:59AM +0100, Francis Moreau wrote:
> > > I have a DMA controller, which has very little in common with ISA DMA
> > > as you said.  I'd like to use it from a generic driver. Which API
> > > should I use then ?
> > >
> > Well, there are two options, either using the existing SH DMA API, or
> > trying to hook something in through the dmaengine API.
> 
> Woh ! I completely missed the dmaengine API. All DMA documentations I found
> were about the DMA-mapping API or the old ISA DMA API.
> 
There's accurate kernel documentation now? When did we start doing that? ;-)

> > The latter is the way that we'll be moving in the near future, but we
> > do still need to keep compatability with the existing SH DMA API
> > around in order to avoid breaking the existing in-tree users.
> 
> Great. Does that mean that all drivers found in arch/sh/drivers/dma/ will
> be converted to use the damengine API except for dma-isa.c ?
> 
That's the plan, yes. DMABRG will probably need some special handling,
but that's pretty isolated. The ST40 DMACs will also prove to be a source
of irritation, so it's still going to take some iterations before
everything is happily migrated. I'll probably start with the SH DMAC (or
the assorted Dreamcast DMACs) and work back from there.

> > You may wish to poke around arch/sh/drivers/dma/. There are lots of
> > greppable things you can find in the rest of tree that show the API,
> > in-tree users, etc. Post if you have any problems.
> 
> I'll take a deep look into this.
> 
> Do you know when the move will happen ?
> 
We are working on 2.6.25 now, so this work will target 2.6.26 at the
absolute earliest. It really depends on how much other stuff goes through
the merge window to see how long we're going to be stuck trying to get
2.6.25 in to reasonable shape.

Once we're in to -rc2 or so I'll see about starting up the 2.6.26
development queue and we can start prioritizing at that point. It is on
the TODO list at least, along with far too many other things there aren't
enough time in the year for.

> BTW, I asked some questions about the DMA API on LKML. Here is the
> pointer if you're interested:
> 
> http://lkml.org/lkml/2008/1/28/65
> 
Thanks, I vaguely recall having read this when it went by, but I'll dig
in to my archives again to make sure I didn't miss anything.

Re: set_dma_addr missing ?

[Francis Moreau]

On Jan 28, 2008 11:17 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> That's the plan, yes. DMABRG will probably need some special handling,
> but that's pretty isolated. The ST40 DMACs will also prove to be a source
> of irritation, so it's still going to take some iterations before
> everything is happily migrated

Sorry to be blind again but I can't find the current DMAC for the ST40...

-- 
Francis

Re: set_dma_addr missing ?

[Stuart MENEFY]

Francis

Francis Moreau wrote:
> On Jan 28, 2008 11:17 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>> That's the plan, yes. DMABRG will probably need some special handling,
>> but that's pretty isolated. The ST40 DMACs will also prove to be a source
>> of irritation, so it's still going to take some iterations before
>> everything is happily migrated
> 
> Sorry to be blind again but I can't find the current DMAC for the ST40...

I don't think there is much (if any) of it in the kernel.org trees
at the moment, have a look at the latest source release:
http://stlinux.com/pub/stlinux/2.3/updates/RPMS/host/stlinux23-host-kernel-source-sh4-2.6.23.13_stm23_0106-106.noarch.rpm

The FDMA stuff is all in drivers/stm (as in theory it should be shared
between a couple of architectures, in practice it isn't yet).

And yes, I know it is in need of a good clean up, sounds like moving
to the dmaengine API would be a good opportunity!

Stuart

Re: set_dma_addr missing ?

[Paul Mundt]

On Mon, Jan 28, 2008 at 02:50:31PM +0100, Francis Moreau wrote:
> On Jan 28, 2008 11:17 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > That's the plan, yes. DMABRG will probably need some special handling,
> > but that's pretty isolated. The ST40 DMACs will also prove to be a source
> > of irritation, so it's still going to take some iterations before
> > everything is happily migrated
> 
> Sorry to be blind again but I can't find the current DMAC for the ST40...
> 
Not merged yet. Sitting in a pile with the rest of the ST40 patches at
the moment.

Re: set_dma_addr missing ?

[Francis Moreau]

Hello Stuart,

On Jan 28, 2008 3:00 PM, Stuart MENEFY <stuart.menefy@st.com> wrote:
> I don't think there is much (if any) of it in the kernel.org trees
> at the moment, have a look at the latest source release:
> http://stlinux.com/pub/stlinux/2.3/updates/RPMS/host/stlinux23-host-kernel-source-sh4-2.6.23.13_stm23_0106-106.noarch.rpm
>

Isn't there a git tree (or any other scm tree) somewhere instead of a RPM
package ?

> The FDMA stuff is all in drivers/stm (as in theory it should be shared
> between a couple of architectures, in practice it isn't yet).
>

Are we taking about the DMAC of the ST40 ?

-- 
Francis

Re: set_dma_addr missing ?

[Francis Moreau]

On Jan 28, 2008 3:14 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>
> On Mon, Jan 28, 2008 at 02:50:31PM +0100, Francis Moreau wrote:
> > On Jan 28, 2008 11:17 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> > > That's the plan, yes. DMABRG will probably need some special handling,
> > > but that's pretty isolated. The ST40 DMACs will also prove to be a source
> > > of irritation, so it's still going to take some iterations before
> > > everything is happily migrated
> >
> > Sorry to be blind again but I can't find the current DMAC for the ST40...
> >
> Not merged yet. Sitting in a pile with the rest of the ST40 patches at
> the moment.
>

Any pointers available for looking at them ?

Thanks
-- 
Francis

Re: set_dma_addr missing ?

[Stuart MENEFY]

Francis Moreau wrote:
> Hello Stuart,
> 
> On Jan 28, 2008 3:00 PM, Stuart MENEFY <stuart.menefy@st.com> wrote:
>> I don't think there is much (if any) of it in the kernel.org trees
>> at the moment, have a look at the latest source release:
>> http://stlinux.com/pub/stlinux/2.3/updates/RPMS/host/stlinux23-host-kernel-source-sh4-2.6.23.13_stm23_0106-106.noarch.rpm
>>
> 
> Isn't there a git tree (or any other scm tree) somewhere instead of a RPM
> package ?

Not a publicly visible one I'm afraid. There is an SRPM which contains the
component patches, but there are rather a lot of them now.

We're moving to git internally at the moment, so hopefully sometime in
the not too distant future we'll be able to do something better, but not
at the moment.

>> The FDMA stuff is all in drivers/stm (as in theory it should be shared
>> between a couple of architectures, in practice it isn't yet).
>>
> 
> Are we taking about the DMAC of the ST40 ?

Yep.

Stuart

Re: set_dma_addr missing ?

[Francis Moreau]

On Jan 28, 2008 3:40 PM, Stuart MENEFY <stuart.menefy@st.com> wrote:
> Not a publicly visible one I'm afraid. There is an SRPM which contains the
> component patches, but there are rather a lot of them now.
>

I'm just interested in the patches. I would prefer not to download your
huge RPM, including the kernel source I assume. It's really pointless.

> We're moving to git internally at the moment, so hopefully sometime in
> the not too distant future we'll be able to do something better, but not
> at the moment.
>

Well, IMHO you should really consider to use decent tools. I can't imagine to
do serious work on the kernel without using GIT ! It really should be the first
thing to setup before doing any hacks...


-- 
Francis

Re: set_dma_addr missing ?

[Paul Mundt]

On Mon, Jan 28, 2008 at 05:36:47PM +0100, Francis Moreau wrote:
> On Jan 28, 2008 3:40 PM, Stuart MENEFY <stuart.menefy@st.com> wrote:
> > Not a publicly visible one I'm afraid. There is an SRPM which contains the
> > component patches, but there are rather a lot of them now.
> 
> I'm just interested in the patches. I would prefer not to download your
> huge RPM, including the kernel source I assume. It's really pointless.
> 
The patches are also quite huge, even though they're generally pretty
well isolated. Even if we merge all of the arch/sh bits from the
outstanding patches, the remaining delta is still significant, and is
something that ST will ultimately have to merge through different
channels as they see fit. The problem is that this is such a significant
divergence that it will become a huge time investment, and it's not
obvious that that's something that will happen. Unfortunately due to a
busy travel schedule and other factors I didn't get as much time to get
ST40 bits merged for this merge window, so it's something that will
gradually trickle in. In the DMA case, it's not really worth merging in
half-steps, so starting out with a dmaengine target is probably the most
sensible way to go (otherwise by the time the ST40 DMAC stuff is ready,
all of the rest of arch/sh/drivers/dma/ drivers will have gone away).

Despite that, the ST40 tree has a lot of quirks/features/changes that we
do want to roll back in to the mainline tree so all of the other users
benefit also, but this is a very gradual process, especially on core
issues like 32-bits phys where ST and Renesas parts take some
irritatingly conflicting approaches ;-)