[PATCH 1/8] ARM i.MX dma: implement wrapper for dma functions

[PATCH 1/8] ARM i.MX dma: implement wrapper for dma functions

Post by Linus Wall » Wed, 11 Aug 2010 07:50:02


2010/8/9 Sascha Hauer < XXXX@XXXXX.COM >:

> + int (*setup_single)(int channel, dma_addr_t mem, int dma_len>th,
> + unsigned in> dmamode);
> + int (*setup_sg)(int channel, struct sc>tterlist *sg,
> + unsigned int sgcount,>unsigned int dma_length,
> + > unsigned int dmamode); >> + void (*enable)(int channel)>
> + void (*disable)(int channel); >> + int (*request)(enum imx_>ma_prio);
> + void>(*free)(int channel);
> + int num_channels;
> +};

This is just getting *so* close to the drivers/dma dmaengine API.

We decided to use the damengine for all our DMA drivers and we
haven't regretted one bit.

There has been some noise about too many drivers stacking up
below arch/arm instead of going to the apropriate subsystem, can't
you atleast contemplate using the dmaengine and help us improve
that subsystem?

I sent some patches to Dan which essentially is a single-buffer
(non-sglist) API, which is all I see missing to fit this need.

Yours,
Linus Walleij
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[PATCH 1/8] ARM i.MX dma: implement wrapper for dma functions

Post by Linus Wall » Wed, 11 Aug 2010 07:50:02

2010/8/9 Sascha Hauer < XXXX@XXXXX.COM >:

> + int (*setup_single)(int channel, dma_addr_t mem, int dma_len>th,
> + unsigned in> dmamode);
> + int (*setup_sg)(int channel, struct sc>tterlist *sg,
> + unsigned int sgcount,>unsigned int dma_length,
> + > unsigned int dmamode); >> + void (*enable)(int channel)>
> + void (*disable)(int channel); >> + int (*request)(enum imx_>ma_prio);
> + void>(*free)(int channel);
> + int num_channels;
> +};

This is just getting *so* close to the drivers/dma dmaengine API.

We decided to use the damengine for all our DMA drivers and we
haven't regretted one bit.

There has been some noise about too many drivers stacking up
below arch/arm instead of going to the apropriate subsystem, can't
you atleast contemplate using the dmaengine and help us improve
that subsystem?

I sent some patches to Dan which essentially is a single-buffer
(non-sglist) API, which is all I see missing to fit this need.

Yours,
Linus Walleij
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

 
 
 

[PATCH 1/8] ARM i.MX dma: implement wrapper for dma functions

Post by Linus Wall » Wed, 11 Aug 2010 07:50:02

2010/8/9 Sascha Hauer < XXXX@XXXXX.COM >:

> + int (*setup_single)(int channel, dma_addr_t mem, int dma_len>th,
> + unsigned in> dmamode);
> + int (*setup_sg)(int channel, struct sc>tterlist *sg,
> + unsigned int sgcount,>unsigned int dma_length,
> + > unsigned int dmamode); >> + void (*enable)(int channel)>
> + void (*disable)(int channel); >> + int (*request)(enum imx_>ma_prio);
> + void>(*free)(int channel);
> + int num_channels;
> +};

This is just getting *so* close to the drivers/dma dmaengine API.

We decided to use the damengine for all our DMA drivers and we
haven't regretted one bit.

There has been some noise about too many drivers stacking up
below arch/arm instead of going to the apropriate subsystem, can't
you atleast contemplate using the dmaengine and help us improve
that subsystem?

I sent some patches to Dan which essentially is a single-buffer
(non-sglist) API, which is all I see missing to fit this need.

Yours,
Linus Walleij
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[PATCH 1/8] ARM i.MX dma: implement wrapper for dma functions

Post by Linus Wall » Wed, 11 Aug 2010 07:50:02

2010/8/9 Sascha Hauer < XXXX@XXXXX.COM >:

> + int (*setup_single)(int channel, dma_addr_t mem, int dma_len>th,
> + unsigned in> dmamode);
> + int (*setup_sg)(int channel, struct sc>tterlist *sg,
> + unsigned int sgcount,>unsigned int dma_length,
> + > unsigned int dmamode); >> + void (*enable)(int channel)>
> + void (*disable)(int channel); >> + int (*request)(enum imx_>ma_prio);
> + void>(*free)(int channel);
> + int num_channels;
> +};

This is just getting *so* close to the drivers/dma dmaengine API.

We decided to use the damengine for all our DMA drivers and we
haven't regretted one bit.

There has been some noise about too many drivers stacking up
below arch/arm instead of going to the apropriate subsystem, can't
you atleast contemplate using the dmaengine and help us improve
that subsystem?

I sent some patches to Dan which essentially is a single-buffer
(non-sglist) API, which is all I see missing to fit this need.

Yours,
Linus Walleij
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[PATCH 1/8] ARM i.MX dma: implement wrapper for dma functions

Post by Sascha Hau » Wed, 11 Aug 2010 21:40:02

Hi Linus,


> > + unsigned in> >mamode);
> > + int (*setup_sg)(int channel, struct sc>t>erlist *sg,
> > + unsigned int sgcount,>u>signed int dma_length,
> > + > > unsigned int dmamode);
>>>>+ void (*enable)(int channel); >>>> + void (*disable)(int channel);
>>>>+ int (*request)(enum imx_dm>_>rio);
> > + void (>f>ee)(in> ch>nnel);
> > + int num_channels;
> > +};
>
> This is just getting *so* close to the drivers/dma dmaengin> AP>.

I was afraid somewone would say this ;)

>
> We decided >o use the damengine for all o>r D>A drivers and we
> haven't regretted one bit.
>
> There has>been some noise about too many drivers stacking up
> below arch/arm >nstead of going to the apropriate subsystem, can't
> you atleast >ontemplate using the dmaengine and help us improve
> that subsystem?

The last time I looked into dmaengine I failed to see how this API
could help me. Looking at it again it seems that this is the way
to go. I will definitely have a closer look. I can't promise though that
this will be before the next merge window. The SDMA engine on the other
hand is of great value for the i.MX community, so if anyone is willing
to help here, please step forward.

Sascha


--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.yqcomputer.com/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/