If the atomic DMA coherent pool is too small, disable use of hardware
descriptor lists instead of crashing the system:
ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!
Unable to handle kernel NULL pointer dereference at virtual address 00000004
Internal error: Oops: a07 [#1] PREEMPT SMP ARM
PC is at rcar_dmac_chan_reinit+0x3c/0x160
LR is at _raw_spin_lock_irqsave+0x18/0x5c
[<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>] (rcar_dmac_isr_error+0x84/0xa0)
[<80214818>] (rcar_dmac_isr_error) from [<80060484>] (handle_irq_event_percpu+0x50/0x150)
[<80060484>] (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
[<800605c0>] (handle_irq_event) from [<8006350c>] (handle_fasteoi_irq+0xb8/0x198)
[<8006350c>] (handle_fasteoi_irq) from [<8005fdb0>] (generic_handle_irq+0x20/0x30)
[<8005fdb0>] (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4)
[<8000fcd0>] (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c)
[<800092cc>] (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Jürg Billeter <[email protected]>
---
drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index f8f70eb..f18b1b6 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct rcar_dmac_chan *chan,
desc->hwdescs.size = size;
}
-static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
- struct rcar_dmac_desc *desc)
+static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
+ struct rcar_dmac_desc *desc)
{
struct rcar_dmac_xfer_chunk *chunk;
struct rcar_dmac_hw_desc *hwdesc;
@@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
hwdesc = desc->hwdescs.mem;
if (!hwdesc)
- return;
+ return -ENOMEM;
list_for_each_entry(chunk, &desc->chunks, node) {
hwdesc->sar = chunk->src_addr;
@@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
hwdesc->tcr = chunk->size >> desc->xfer_shift;
hwdesc++;
}
+
+ return 0;
}
/* -----------------------------------------------------------------------------
@@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan, struct scatterlist *sgl,
* additional complexity remains to be investigated.
*/
desc->hwdescs.use = !highmem && nchunks > 1;
- if (desc->hwdescs.use)
- rcar_dmac_fill_hwdesc(chan, desc);
+ if (desc->hwdescs.use) {
+ if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
+ desc->hwdescs.use = false;
+ }
return &desc->async_tx;
}
--
2.1.3
Hi J?rg,
Thank you for the patch.
On Tuesday 25 November 2014 15:10:17 J?rg Billeter wrote:
> If the atomic DMA coherent pool is too small, disable use of hardware
> descriptor lists instead of crashing the system:
>
> ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> Internal error: Oops: a07 [#1] PREEMPT SMP ARM
>
> PC is at rcar_dmac_chan_reinit+0x3c/0x160
> LR is at _raw_spin_lock_irqsave+0x18/0x5c
>
> [<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>]
> (rcar_dmac_isr_error+0x84/0xa0) [<80214818>] (rcar_dmac_isr_error) from
> [<80060484>] (handle_irq_event_percpu+0x50/0x150) [<80060484>]
> (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
> [<800605c0>] (handle_irq_event) from [<8006350c>]
> (handle_fasteoi_irq+0xb8/0x198) [<8006350c>] (handle_fasteoi_irq) from
> [<8005fdb0>] (generic_handle_irq+0x20/0x30) [<8005fdb0>]
> (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4) [<8000fcd0>]
> (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c) [<800092cc>]
> (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
>
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Signed-off-by: J?rg Billeter <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
and applied to my tree.
> ---
> drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index f8f70eb..f18b1b6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct
> rcar_dmac_chan *chan, desc->hwdescs.size = size;
> }
>
> -static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> - struct rcar_dmac_desc *desc)
> +static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> + struct rcar_dmac_desc *desc)
> {
> struct rcar_dmac_xfer_chunk *chunk;
> struct rcar_dmac_hw_desc *hwdesc;
> @@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan
> *chan,
>
> hwdesc = desc->hwdescs.mem;
> if (!hwdesc)
> - return;
> + return -ENOMEM;
>
> list_for_each_entry(chunk, &desc->chunks, node) {
> hwdesc->sar = chunk->src_addr;
> @@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan
> *chan, hwdesc->tcr = chunk->size >> desc->xfer_shift;
> hwdesc++;
> }
> +
> + return 0;
> }
>
> /* ------------------------------------------------------------------------
> @@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan,
> struct scatterlist *sgl, * additional complexity remains to be
> investigated.
> */
> desc->hwdescs.use = !highmem && nchunks > 1;
> - if (desc->hwdescs.use)
> - rcar_dmac_fill_hwdesc(chan, desc);
> + if (desc->hwdescs.use) {
> + if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
> + desc->hwdescs.use = false;
> + }
>
> return &desc->async_tx;
> }
--
Regards,
Laurent Pinchart
On Tue, Nov 25, 2014 at 03:10:17PM +0100, J?rg Billeter wrote:
> If the atomic DMA coherent pool is too small, disable use of hardware
> descriptor lists instead of crashing the system:
>
> ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> Internal error: Oops: a07 [#1] PREEMPT SMP ARM
>
> PC is at rcar_dmac_chan_reinit+0x3c/0x160
> LR is at _raw_spin_lock_irqsave+0x18/0x5c
>
> [<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>] (rcar_dmac_isr_error+0x84/0xa0)
> [<80214818>] (rcar_dmac_isr_error) from [<80060484>] (handle_irq_event_percpu+0x50/0x150)
> [<80060484>] (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
> [<800605c0>] (handle_irq_event) from [<8006350c>] (handle_fasteoi_irq+0xb8/0x198)
> [<8006350c>] (handle_fasteoi_irq) from [<8005fdb0>] (generic_handle_irq+0x20/0x30)
> [<8005fdb0>] (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4)
> [<8000fcd0>] (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c)
> [<800092cc>] (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
>
> Kernel panic - not syncing: Fatal exception in interrupt
Can you please rebase this on my next, this fails to apply for me
Thanks
--
~Vinod
>
> Signed-off-by: J?rg Billeter <[email protected]>
> ---
> drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index f8f70eb..f18b1b6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct rcar_dmac_chan *chan,
> desc->hwdescs.size = size;
> }
>
> -static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> - struct rcar_dmac_desc *desc)
> +static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> + struct rcar_dmac_desc *desc)
> {
> struct rcar_dmac_xfer_chunk *chunk;
> struct rcar_dmac_hw_desc *hwdesc;
> @@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
>
> hwdesc = desc->hwdescs.mem;
> if (!hwdesc)
> - return;
> + return -ENOMEM;
>
> list_for_each_entry(chunk, &desc->chunks, node) {
> hwdesc->sar = chunk->src_addr;
> @@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> hwdesc->tcr = chunk->size >> desc->xfer_shift;
> hwdesc++;
> }
> +
> + return 0;
> }
>
> /* -----------------------------------------------------------------------------
> @@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan, struct scatterlist *sgl,
> * additional complexity remains to be investigated.
> */
> desc->hwdescs.use = !highmem && nchunks > 1;
> - if (desc->hwdescs.use)
> - rcar_dmac_fill_hwdesc(chan, desc);
> + if (desc->hwdescs.use) {
> + if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
> + desc->hwdescs.use = false;
> + }
>
> return &desc->async_tx;
> }
> --
> 2.1.3
>
--
Hi Vinod,
On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> Can you please rebase this on my next, this fails to apply for me
This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
to be in your next yet. Laurent has already merged my patch into his
dma/next branch and included it in his pull request from November 27.
[GIT PULL FOR v3.19] R-Car DMA engine driver
http://www.spinics.net/lists/linux-sh/msg37764.html
Please let me know if there is still a rebase required from my side.
Regards,
Jürg
On Mon, Dec 08, 2014 at 05:50:26PM +0100, J?rg Billeter wrote:
> Hi Vinod,
>
> On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > Can you please rebase this on my next, this fails to apply for me
>
> This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> to be in your next yet. Laurent has already merged my patch into his
> dma/next branch and included it in his pull request from November 27.
>
> [GIT PULL FOR v3.19] R-Car DMA engine driver
> http://www.spinics.net/lists/linux-sh/msg37764.html
And I dont seem to have this request in my Inbox :(
Yes I do see it in archieves, so not sure how this is not present, not sure
if the servers mangeled it!!
I will pull this tomorrow...
> Please let me know if there is still a rebase required from my side.
Nope
--
~Vinod
Hi Vinod,
On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 05:50:26PM +0100, J?rg Billeter wrote:
> > Hi Vinod,
> >
> > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > Can you please rebase this on my next, this fails to apply for me
> >
> > This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> > to be in your next yet. Laurent has already merged my patch into his
> > dma/next branch and included it in his pull request from November 27.
> >
> > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > http://www.spinics.net/lists/linux-sh/msg37764.html
>
> And I dont seem to have this request in my Inbox :(
> Yes I do see it in archieves, so not sure how this is not present, not sure
> if the servers mangeled it!!
I haven't CC'ed you, I'll make sure to do so next time. The mail should still
have reached you through the mailing list though (I assume you're subscribed
to [email protected] ;-)).
> I will pull this tomorrow...
Thank you.
> > Please let me know if there is still a rebase required from my side.
>
> Nope
--
Regards,
Laurent Pinchart
On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
>
> On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 05:50:26PM +0100, J?rg Billeter wrote:
> > > Hi Vinod,
> > >
> > > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > > Can you please rebase this on my next, this fails to apply for me
> > >
> > > This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> > > to be in your next yet. Laurent has already merged my patch into his
> > > dma/next branch and included it in his pull request from November 27.
> > >
> > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > http://www.spinics.net/lists/linux-sh/msg37764.html
> >
> > And I dont seem to have this request in my Inbox :(
> > Yes I do see it in archieves, so not sure how this is not present, not sure
> > if the servers mangeled it!!
>
> I haven't CC'ed you, I'll make sure to do so next time. The mail should still
> have reached you through the mailing list though (I assume you're subscribed
> to [email protected] ;-)).
Yes I am, so should have reached me even though i wasnt cced
I do see email reaching me from list without me being in CC, but then it
wont hit my inbox and go to ML folder :)
So generally its a good practice to CC relvant folks, lots of folks do ask
that if ML is high volume
Hopefully the Intel servers are playing nice with vger, that is my bigger
worry here.
--
~Vinod
On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > >
> > > And I dont seem to have this request in my Inbox :(
> > > Yes I do see it in archieves, so not sure how this is not present, not sure
> > > if the servers mangeled it!!
> >
> > I haven't CC'ed you, I'll make sure to do so next time. The mail should still
> > have reached you through the mailing list though (I assume you're subscribed
> > to [email protected] ;-)).
> Yes I am, so should have reached me even though i wasnt cced
> I do see email reaching me from list without me being in CC, but then it
> wont hit my inbox and go to ML folder :)
> So generally its a good practice to CC relvant folks, lots of folks do ask
> that if ML is high volume
Hey Laurent,
I see that the oddity in commitlogs with change since artifacts after SOB,
can you please fix that up
commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
Author: Laurent Pinchart <[email protected]>
Date: Sat Jul 19 00:05:14 2014 +0200
dmaengine: rcar-dmac: Cache hardware descriptors memory
Unlike DMA transfers descriptors that are preallocated and cached,
memory used to store hardware descriptors is allocated and freed with
the DMA coherent allocation API for every transfer. Besides degrading
performances, this creates a CMA stress test that seems to cause issues.
Running dmatest with the noverify option produces
[ 50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
[ 50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e) failed
[ 52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848) failed
[ 54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
[ 56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850) failed
The root cause needs to be fixed, but in the meantime, as a workaround
and a performance improvement, cache hardware descriptors.
Signed-off-by: Laurent Pinchart <[email protected]>
Tested-by: Wolfram Sang <[email protected]>
---
Changes since v2:
- Typo fixes
- Align allocated hwdesc size to page size
- Ignore allocated hwdesc memory when the transfer doesn't use hwdescs
commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
Author: Laurent Pinchart <[email protected]>
Date: Wed Jul 16 23:15:48 2014 +0200
dmaengine: rcar-dmac: Implement support for hardware descriptor lists
The DMAC supports hardware-based auto-configuration from descriptor
lists. This reduces the number of interrupts required for processing a
DMA transfer. Support that mode in the driver.
Signed-off-by: Laurent Pinchart <[email protected]>
Tested-by: Wolfram Sang <[email protected]>
---
Changes since v2:
- Typo fixes
- Use GFP_NOWAIT to allocate hardware descriptors
- Clear descriptor stage end interrupt when halting the channel
and many more...
Thanks
--
~Vinod
Hi Vinod,
On Tuesday 09 December 2014 12:09:12 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > >
> > > > And I dont seem to have this request in my Inbox :(
> > > > Yes I do see it in archieves, so not sure how this is not present, not
> > > > sure if the servers mangeled it!!
> > >
> > > I haven't CC'ed you, I'll make sure to do so next time. The mail should
> > > still have reached you through the mailing list though (I assume you're
> > > subscribed to [email protected] ;-)).
> >
> > Yes I am, so should have reached me even though i wasnt cced
> > I do see email reaching me from list without me being in CC, but then it
> > wont hit my inbox and go to ML folder :)
> > So generally its a good practice to CC relvant folks, lots of folks do ask
> > that if ML is high volume
>
> Hey Laurent,
>
> I see that the oddity in commitlogs with change since artifacts after SOB,
> can you please fix that up
My bad. I've fixed the problem and pushed the result to the same branch
git://linuxtv.org/pinchartl/fbdev.git dma/next
The only difference lies in the commit logs.
> commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
> Author: Laurent Pinchart <[email protected]>
> Date: Sat Jul 19 00:05:14 2014 +0200
>
> dmaengine: rcar-dmac: Cache hardware descriptors memory
>
> Unlike DMA transfers descriptors that are preallocated and cached,
> memory used to store hardware descriptors is allocated and freed with
> the DMA coherent allocation API for every transfer. Besides degrading
> performances, this creates a CMA stress test that seems to cause
> issues. Running dmatest with the noverify option produces
>
> [ 50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846)
> failed [ 50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e)
> failed [ 52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848)
> failed [ 54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844)
> failed [ 56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850)
> failed
>
> The root cause needs to be fixed, but in the meantime, as a
workaround
> and a performance improvement, cache hardware descriptors.
>
> Signed-off-by: Laurent Pinchart
> <[email protected]> Tested-by: Wolfram Sang
> <[email protected]>
>
> ---
>
> Changes since v2:
>
> - Typo fixes
> - Align allocated hwdesc size to page size
> - Ignore allocated hwdesc memory when the transfer doesn't use
hwdescs
>
> commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
> Author: Laurent Pinchart <[email protected]>
> Date: Wed Jul 16 23:15:48 2014 +0200
>
> dmaengine: rcar-dmac: Implement support for hardware descriptor lists
>
> The DMAC supports hardware-based auto-configuration from descriptor
> lists. This reduces the number of interrupts required for processing
a
> DMA transfer. Support that mode in the driver.
>
> Signed-off-by: Laurent Pinchart
> <[email protected]> Tested-by: Wolfram Sang
> <[email protected]>
>
> ---
>
> Changes since v2:
>
> - Typo fixes
> - Use GFP_NOWAIT to allocate hardware descriptors
> - Clear descriptor stage end interrupt when halting the channel
>
> and many more...
--
Regards,
Laurent Pinchart
Hi Laurent
> > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > >
> > > > > And I dont seem to have this request in my Inbox :(
> > > > > Yes I do see it in archieves, so not sure how this is not present, not
> > > > > sure if the servers mangeled it!!
> > > >
> > > > I haven't CC'ed you, I'll make sure to do so next time. The mail should
> > > > still have reached you through the mailing list though (I assume you're
> > > > subscribed to [email protected] ;-)).
> > >
> > > Yes I am, so should have reached me even though i wasnt cced
> > > I do see email reaching me from list without me being in CC, but then it
> > > wont hit my inbox and go to ML folder :)
> > > So generally its a good practice to CC relvant folks, lots of folks do ask
> > > that if ML is high volume
> >
> > Hey Laurent,
> >
> > I see that the oddity in commitlogs with change since artifacts after SOB,
> > can you please fix that up
>
> My bad. I've fixed the problem and pushed the result to the same branch
>
> git://linuxtv.org/pinchartl/fbdev.git dma/next
>
> The only difference lies in the commit logs.
If my understanding was correct, we need to be based on Vinod's
topic/slave_caps_device_control_fix
Best regards
---
Kuninori Morimoto
(Resend, as the message doesn't seem to have made it to the mailing lists)
On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > >>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > >>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > > >>>
> > > >>> And I dont seem to have this request in my Inbox :(
> > > >>> Yes I do see it in archieves, so not sure how this is not present,
> > > >>> not sure if the servers mangeled it!!
> > > >>
> > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > > >> should still have reached you through the mailing list though (I
> > > >> assume you're subscribed to [email protected] ;-)).
> > > >
> > > > Yes I am, so should have reached me even though i wasnt cced
> > > > I do see email reaching me from list without me being in CC, but then
> > > > it wont hit my inbox and go to ML folder :)
> > > > So generally its a good practice to CC relvant folks, lots of folks do
> > > > ask that if ML is high volume
> > >
> > > Hey Laurent,
> > >
> > > I see that the oddity in commitlogs with change since artifacts after
> > > SOB, can you please fix that up
> >
> > My bad. I've fixed the problem and pushed the result to the same branch
> >
> > git://linuxtv.org/pinchartl/fbdev.git dma/next
> >
> > The only difference lies in the commit logs.
>
> If my understanding was correct, we need to be based on Vinod's
> topic/slave_caps_device_control_fix
Vinod, could you please comment on that ? To which kernel version do you plan
to push this series ? Do I need to rebase it ?
--
Regards,
Laurent Pinchart
On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> (Resend, as the message doesn't seem to have made it to the mailing lists)
>
> On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > >>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > >>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > >>>
> > > > >>> And I dont seem to have this request in my Inbox :(
> > > > >>> Yes I do see it in archieves, so not sure how this is not present,
> > > > >>> not sure if the servers mangeled it!!
> > > > >>
> > > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > > > >> should still have reached you through the mailing list though (I
> > > > >> assume you're subscribed to [email protected] ;-)).
> > > > >
> > > > > Yes I am, so should have reached me even though i wasnt cced
> > > > > I do see email reaching me from list without me being in CC, but then
> > > > > it wont hit my inbox and go to ML folder :)
> > > > > So generally its a good practice to CC relvant folks, lots of folks do
> > > > > ask that if ML is high volume
> > > >
> > > > Hey Laurent,
> > > >
> > > > I see that the oddity in commitlogs with change since artifacts after
> > > > SOB, can you please fix that up
> > >
> > > My bad. I've fixed the problem and pushed the result to the same branch
> > >
> > > git://linuxtv.org/pinchartl/fbdev.git dma/next
> > >
> > > The only difference lies in the commit logs.
> >
> > If my understanding was correct, we need to be based on Vinod's
> > topic/slave_caps_device_control_fix
>
> Vinod, could you please comment on that ? To which kernel version do you plan
> to push this series ? Do I need to rebase it ?
Hi Laurent,
I did a quick at the series, looks fine mostly. I have already sent by pull
request to linus earlier last week and its merged, so we need to merge it
for next one. So yes we need to fix and test this for caps and control API
fix. Can you do that and I will pull and put in my next for 3.20
One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
you please explain a bit more on it, why do you need to modify addresses
based on config option?
--
~Vinod
Hi Vinod,
On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> >>>>>>>
> >>>>>>> And I dont seem to have this request in my Inbox :(
> >>>>>>> Yes I do see it in archieves, so not sure how this is not
> >>>>>>> present, not sure if the servers mangeled it!!
> >>>>>>
> >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> >>>>>> should still have reached you through the mailing list though (I
> >>>>>> assume you're subscribed to [email protected] ;-)).
> >>>>>
> >>>>> Yes I am, so should have reached me even though i wasnt cced
> >>>>> I do see email reaching me from list without me being in CC, but
> >>>>> then it wont hit my inbox and go to ML folder :)
> >>>>> So generally its a good practice to CC relvant folks, lots of
> >>>>> folks do ask that if ML is high volume
> >>>>
> >>>> Hey Laurent,
> >>>>
> >>>> I see that the oddity in commitlogs with change since artifacts
> >>>> after SOB, can you please fix that up
> >>>
> >>> My bad. I've fixed the problem and pushed the result to the same
> >>> branch
> >>>
> >>> git://linuxtv.org/pinchartl/fbdev.git dma/next
> >>>
> >>> The only difference lies in the commit logs.
> >>
> >> If my understanding was correct, we need to be based on Vinod's
> >> topic/slave_caps_device_control_fix
> >
> > Vinod, could you please comment on that ? To which kernel version do you
> > plan to push this series ? Do I need to rebase it ?
>
> Hi Laurent,
>
> I did a quick at the series, looks fine mostly. I have already sent by pull
> request to linus earlier last week and its merged, so we need to merge it
> for next one. So yes we need to fix and test this for caps and control API
> fix. Can you do that and I will pull and put in my next for 3.20
That's very annoying given that I have users waiting for the driver to be
merged, and that I've sent the pull request two weeks and a half ago.
I suppose I have no choice anyway. Please provide me with a v3.20 development
branch on which I can rebase the patch set, I don't want to rebase it twice.
> One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> you please explain a bit more on it, why do you need to modify addresses
> based on config option?
Because there's no need to write the upper bits (above 32) of the DMA
addresses when the DMA address spans 32 bits only, and because there's no need
to check for transfers that cross a 4GB boundary (that's a hardware
limitation) when the DMA address space is 4GB in total.
--
Regards,
Laurent Pinchart
On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
>
> On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> > On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > >>>>>>>
> > >>>>>>> And I dont seem to have this request in my Inbox :(
> > >>>>>>> Yes I do see it in archieves, so not sure how this is not
> > >>>>>>> present, not sure if the servers mangeled it!!
> > >>>>>>
> > >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > >>>>>> should still have reached you through the mailing list though (I
> > >>>>>> assume you're subscribed to [email protected] ;-)).
> > >>>>>
> > >>>>> Yes I am, so should have reached me even though i wasnt cced
> > >>>>> I do see email reaching me from list without me being in CC, but
> > >>>>> then it wont hit my inbox and go to ML folder :)
> > >>>>> So generally its a good practice to CC relvant folks, lots of
> > >>>>> folks do ask that if ML is high volume
> > >>>>
> > >>>> Hey Laurent,
> > >>>>
> > >>>> I see that the oddity in commitlogs with change since artifacts
> > >>>> after SOB, can you please fix that up
> > >>>
> > >>> My bad. I've fixed the problem and pushed the result to the same
> > >>> branch
> > >>>
> > >>> git://linuxtv.org/pinchartl/fbdev.git dma/next
> > >>>
> > >>> The only difference lies in the commit logs.
> > >>
> > >> If my understanding was correct, we need to be based on Vinod's
> > >> topic/slave_caps_device_control_fix
> > >
> > > Vinod, could you please comment on that ? To which kernel version do you
> > > plan to push this series ? Do I need to rebase it ?
> >
> > Hi Laurent,
> >
> > I did a quick at the series, looks fine mostly. I have already sent by pull
> > request to linus earlier last week and its merged, so we need to merge it
> > for next one. So yes we need to fix and test this for caps and control API
> > fix. Can you do that and I will pull and put in my next for 3.20
>
> That's very annoying given that I have users waiting for the driver to be
> merged, and that I've sent the pull request two weeks and a half ago.
Sorry cant help if I dont see the PULL request :( Apprently once a year
intel domain gets kicked out causing us to be unsubscribed, just bad timing
here...
> I suppose I have no choice anyway. Please provide me with a v3.20 development
> branch on which I can rebase the patch set, I don't want to rebase it twice.
Please use topic/slave_caps_device_control_fix. I am going to rebase this
once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
impact you.
> > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> > DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> > you please explain a bit more on it, why do you need to modify addresses
> > based on config option?
>
> Because there's no need to write the upper bits (above 32) of the DMA
> addresses when the DMA address spans 32 bits only, and because there's no need
> to check for transfers that cross a 4GB boundary (that's a hardware
> limitation) when the DMA address space is 4GB in total.
I was hoping that dma_addr_t should take care of this... but lots of HW
limitations
--
~Vinod
Hi Vinod,
On Tuesday 16 December 2014 12:34:13 Vinod Koul wrote:
> On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> > On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> >> On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> >>> On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> >>>>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> >>>>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> >>>>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> >>>>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> >>>>>>>>>
> >>>>>>>>> And I dont seem to have this request in my Inbox :(
> >>>>>>>>> Yes I do see it in archieves, so not sure how this is not
> >>>>>>>>> present, not sure if the servers mangeled it!!
> >>>>>>>>
> >>>>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> >>>>>>>> should still have reached you through the mailing list though (I
> >>>>>>>> assume you're subscribed to [email protected] ;-)).
> >>>>>>>
> >>>>>>> Yes I am, so should have reached me even though i wasnt cced
> >>>>>>> I do see email reaching me from list without me being in CC, but
> >>>>>>> then it wont hit my inbox and go to ML folder :)
> >>>>>>> So generally its a good practice to CC relvant folks, lots of
> >>>>>>> folks do ask that if ML is high volume
> >>>>>>
> >>>>>> Hey Laurent,
> >>>>>>
> >>>>>> I see that the oddity in commitlogs with change since artifacts
> >>>>>> after SOB, can you please fix that up
> >>>>>
> >>>>> My bad. I've fixed the problem and pushed the result to the same
> >>>>> branch
> >>>>>
> >>>>> git://linuxtv.org/pinchartl/fbdev.git dma/next
> >>>>>
> >>>>> The only difference lies in the commit logs.
> >>>>
> >>>> If my understanding was correct, we need to be based on Vinod's
> >>>> topic/slave_caps_device_control_fix
> >>>
> >>> Vinod, could you please comment on that ? To which kernel version do
> >>> you plan to push this series ? Do I need to rebase it ?
> >>
> >> Hi Laurent,
> >>
> >> I did a quick at the series, looks fine mostly. I have already sent by
> >> pull request to linus earlier last week and its merged, so we need to
> >> merge it for next one. So yes we need to fix and test this for caps and
> >> control API fix. Can you do that and I will pull and put in my next for
> >> 3.20
> >
> > That's very annoying given that I have users waiting for the driver to be
> > merged, and that I've sent the pull request two weeks and a half ago.
>
> Sorry cant help if I dont see the PULL request :( Apprently once a year
> intel domain gets kicked out causing us to be unsubscribed, just bad timing
> here...
Do you mean that every Intel employee needs to resubscribe to all vger mailing
list once a year ? :-o
> > I suppose I have no choice anyway. Please provide me with a v3.20
> > development branch on which I can rebase the patch set, I don't want to
> > rebase it twice.
>
> Please use topic/slave_caps_device_control_fix. I am going to rebase this
> once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> impact you.
Done. I'll rebase it once again when you will have rebased your branch, and
will then send a pull request. Could you please rebase your branch early after
the -rc1 release ?
> > > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car
> > > Gen2 DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT
> > > code. Can you please explain a bit more on it, why do you need to
> > > modify addresses based on config option?
> >
> > Because there's no need to write the upper bits (above 32) of the DMA
> > addresses when the DMA address spans 32 bits only, and because there's no
> > need to check for transfers that cross a 4GB boundary (that's a hardware
> > limitation) when the DMA address space is 4GB in total.
>
> I was hoping that dma_addr_t should take care of this... but lots of HW
> limitations
dma_addr_t gets a different size depending on whether large physical address
extension is enabled or not, but that's only part of the solution. It doesn't
magically remove code that ends up not being needed anymore, and worse than
that, it causes the following build warnings:
CC [M] drivers/dma/sh/rcar-dmac.o
drivers/dma/sh/rcar-dmac.c: In function ‘rcar_dmac_chan_start_xfer’:
drivers/dma/sh/rcar-dmac.c:333:10: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:377:10: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:379:10: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c: In function ‘rcar_dmac_chan_prep_sg’:
drivers/dma/sh/rcar-dmac.c:873:4: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:873:4: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:875:4: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:875:4: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:883:4: warning: right shift count >= width of type
[enabled by default]
drivers/dma/sh/rcar-dmac.c:883:4: warning: right shift count >= width of type
[enabled by default
--
Regards,
Laurent Pinchart
On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> Do you mean that every Intel employee needs to resubscribe to all vger mailing
> list once a year ? :-o
Unfortuntely yes... :( I need to set my infradead account up again now for
backup..
>
> > > I suppose I have no choice anyway. Please provide me with a v3.20
> > > development branch on which I can rebase the patch set, I don't want to
> > > rebase it twice.
> >
> > Please use topic/slave_caps_device_control_fix. I am going to rebase this
> > once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> > impact you.
>
> Done. I'll rebase it once again when you will have rebased your branch, and
> will then send a pull request. Could you please rebase your branch early after
> the -rc1 release ?
Sure, within a day or so of its release it should be done.
Do note that am out during Christmas and the weekend with no email access,
will be lucky if my phone works, email very unlikely and I think you guys
will be out too.
But if your patches are done, feel free to send them
--
~Vinod
On Wed, Dec 17, 2014 at 06:24:06PM +0530, Vinod Koul wrote:
> On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> > Do you mean that every Intel employee needs to resubscribe to all vger mailing
> > list once a year ? :-o
> Unfortuntely yes... :( I need to set my infradead account up again now for
> backup..
>
> >
> > > > I suppose I have no choice anyway. Please provide me with a v3.20
> > > > development branch on which I can rebase the patch set, I don't want to
> > > > rebase it twice.
> > >
> > > Please use topic/slave_caps_device_control_fix. I am going to rebase this
> > > once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> > > impact you.
> >
> > Done. I'll rebase it once again when you will have rebased your branch, and
> > will then send a pull request. Could you please rebase your branch early after
> > the -rc1 release ?
> Sure, within a day or so of its release it should be done.
>
> Do note that am out during Christmas and the weekend with no email access,
> will be lucky if my phone works, email very unlikely and I think you guys
> will be out too.
>
> But if your patches are done, feel free to send them
And I have rebased and pushed. These should be linux-next for tomorrow
Thanks
--
~Vinod
Hi Vinod,
On Monday 22 December 2014 20:32:19 Vinod Koul wrote:
> On Wed, Dec 17, 2014 at 06:24:06PM +0530, Vinod Koul wrote:
> > On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> >> Do you mean that every Intel employee needs to resubscribe to all vger
> >> mailing list once a year ? :-o
> >
> > Unfortuntely yes... :( I need to set my infradead account up again now for
> > backup..
> >
> >>>> I suppose I have no choice anyway. Please provide me with a v3.20
> >>>> development branch on which I can rebase the patch set, I don't want
> >>>> to rebase it twice.
> >>>
> >>> Please use topic/slave_caps_device_control_fix. I am going to rebase
> >>> this once rc1 is declared (eow i guess). It would plain git rebase, so
> >>> shouldn't impact you.
> >>
> >> Done. I'll rebase it once again when you will have rebased your branch,
> >> and will then send a pull request. Could you please rebase your branch
> >> early after the -rc1 release ?
> >
> > Sure, within a day or so of its release it should be done.
> >
> > Do note that am out during Christmas and the weekend with no email access,
> > will be lucky if my phone works, email very unlikely and I think you guys
> > will be out too.
> >
> > But if your patches are done, feel free to send them
>
> And I have rebased and pushed. These should be linux-next for tomorrow
Thank you. I've rebased my branch, I'm testing it, and will send you a pull
request right afterwards.
--
Regards,
Laurent Pinchart