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 dmaengine@xxxxxxxxxxxxxxx ;-)). > >>>>> > >>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
