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 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. 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 -- 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
