Dan,
What's going on with the dma engine drivers for 2.6.25? We had a
Freescale dma driver from Zhang Wei queued up but seems to have been
lost.
- k
On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala <[email protected]> wrote:
> Dan,
>
> What's going on with the dma engine drivers for 2.6.25? We had a
> Freescale dma driver from Zhang Wei queued up but seems to have been
> lost.
I pulled it into my tree and am holding it until Zhang has an
opportunity to address the pending review comments [1]. I also did
not feel comfortable pushing it to Linus without a PPC maintainer's
Acked-by/Reviewed-by.
I have attached the version I am carrying.
--
Dan
[1] http://marc.info/?l=linux-kernel&m=119998939916613&w=2
On Feb 14, 2008, at 12:14 PM, Dan Williams wrote:
> On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala
> <[email protected]> wrote:
>> Dan,
>>
>> What's going on with the dma engine drivers for 2.6.25? We had a
>> Freescale dma driver from Zhang Wei queued up but seems to have been
>> lost.
>
> I pulled it into my tree and am holding it until Zhang has an
> opportunity to address the pending review comments [1]. I also did
> not feel comfortable pushing it to Linus without a PPC maintainer's
> Acked-by/Reviewed-by.
>
> I have attached the version I am carrying.
What issues are still open. I was under the belief that Zhang had
resolved all the issues.
- k
On Thu, Feb 14, 2008 at 8:44 PM, Kumar Gala <[email protected]> wrote:
>
> On Feb 14, 2008, at 12:14 PM, Dan Williams wrote:
>
> > On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala
> > <[email protected]> wrote:
> >> Dan,
> >>
> >> What's going on with the dma engine drivers for 2.6.25? We had a
> >> Freescale dma driver from Zhang Wei queued up but seems to have been
> >> lost.
> >
> > I pulled it into my tree and am holding it until Zhang has an
> > opportunity to address the pending review comments [1]. I also did
> > not feel comfortable pushing it to Linus without a PPC maintainer's
> > Acked-by/Reviewed-by.
> >
> > I have attached the version I am carrying.
>
> What issues are still open. I was under the belief that Zhang had
> resolved all the issues.
>
The high priority review item is that the driver performs operation
completion callbacks in hardirq context. Clients of the API assume
that callbacks will happen in softirq context. Of lesser concern is
the use of GFP_ATOMIC in fsl_dma_alloc_descriptor. Other drivers
preallocate a small pool of descriptors.
Regards,
Dan
On Thu, Feb 14, 2008 at 10:29 PM, Dan Williams <[email protected]> wrote:
> On Thu, Feb 14, 2008 at 8:44 PM, Kumar Gala <[email protected]> wrote:
> >
> > On Feb 14, 2008, at 12:14 PM, Dan Williams wrote:
> >
> > > On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala
> > > <[email protected]> wrote:
> > >> Dan,
> > >>
> > >> What's going on with the dma engine drivers for 2.6.25? We had a
> > >> Freescale dma driver from Zhang Wei queued up but seems to have been
> > >> lost.
> > >
> > > I pulled it into my tree and am holding it until Zhang has an
> > > opportunity to address the pending review comments [1]. I also did
> > > not feel comfortable pushing it to Linus without a PPC maintainer's
> > > Acked-by/Reviewed-by.
> > >
> > > I have attached the version I am carrying.
> >
> > What issues are still open. I was under the belief that Zhang had
> > resolved all the issues.
> >
>
> The high priority review item is that the driver performs operation
> completion callbacks in hardirq context. Clients of the API assume
> that callbacks will happen in softirq context. Of lesser concern is
> the use of GFP_ATOMIC in fsl_dma_alloc_descriptor. Other drivers
> preallocate a small pool of descriptors.
>
Have not received a response, so let's try this the other way. I took
a closer look and found that my concern should be addressed by the
following one-liner:
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 902e852..cc9a681 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -685,7 +685,6 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int
irq, void *data)
"nlndar 0x%016llx\n", (u64)get_cdar(fsl_chan),
(u64)get_ndar(fsl_chan));
stat &= ~FSL_DMA_SR_EOSI;
- fsl_chan_ld_cleanup(fsl_chan);
}
/* If it current transfer is the end-of-transfer,
With your ack I'll push the driver plus this fixlet for the current kernel.
Regards,
Dan
Hi,
Sorry for missing lots of emails in my long vacation. :)
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Dan Williams
> Sent: Sunday, February 24, 2008 10:06 AM
> To: Kumar Gala
> Cc: LKML Kernel; Zhang Wei
> Subject: Re: dma engine drivers for 2.6.25?
>
> On Thu, Feb 14, 2008 at 10:29 PM, Dan Williams
> <[email protected]> wrote:
> > On Thu, Feb 14, 2008 at 8:44 PM, Kumar Gala
> <[email protected]> wrote:
> > >
> > > On Feb 14, 2008, at 12:14 PM, Dan Williams wrote:
> > >
> > > > On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala
> > > > <[email protected]> wrote:
> > > >> Dan,
> > > >>
> > > >> What's going on with the dma engine drivers for
> 2.6.25? We had a
> > > >> Freescale dma driver from Zhang Wei queued up but
> seems to have been
> > > >> lost.
> > > >
> > > > I pulled it into my tree and am holding it until Zhang has an
> > > > opportunity to address the pending review comments
> [1]. I also did
> > > > not feel comfortable pushing it to Linus without a
> PPC maintainer's
> > > > Acked-by/Reviewed-by.
> > > >
> > > > I have attached the version I am carrying.
> > >
> > > What issues are still open. I was under the belief
> that Zhang had
> > > resolved all the issues.
> > >
> >
> > The high priority review item is that the driver performs operation
> > completion callbacks in hardirq context. Clients of the API assume
> > that callbacks will happen in softirq context. Of lesser
> concern is
> > the use of GFP_ATOMIC in fsl_dma_alloc_descriptor. Other drivers
> > preallocate a small pool of descriptors.
> >
>
> Have not received a response, so let's try this the other way. I took
> a closer look and found that my concern should be addressed by the
> following one-liner:
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 902e852..cc9a681 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -685,7 +685,6 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int
> irq, void *data)
> "nlndar 0x%016llx\n",
> (u64)get_cdar(fsl_chan),
> (u64)get_ndar(fsl_chan));
> stat &= ~FSL_DMA_SR_EOSI;
> - fsl_chan_ld_cleanup(fsl_chan);
> }
>
> /* If it current transfer is the end-of-transfer,
>
> With your ack I'll push the driver plus this fixlet for the
> current kernel.
I agree with you to remove the fsl_chan_ld_cleanup() function calling in
Interrupt action, which is already called in tasklet. I forgot to remove it.
Thanks!
Cheers!
Wei.