[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b1dba0ad-f7d6-607b-87f7-d3ca746d19ea@oracle.com>
Date: Wed, 15 Jan 2020 10:26:36 -0800
From: "santosh.shilimkar@...cle.com" <santosh.shilimkar@...cle.com>
To: Vinod Koul <vkoul@...nel.org>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>,
Sekhar Nori <nsekhar@...com>, robh+dt@...nel.org, nm@...com,
ssantosh@...nel.org, dan.j.williams@...el.com,
dmaengine@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
grygorii.strashko@...com, lokeshvutla@...com, t-kristo@...com,
tony@...mide.com, j-keerthy@...com, vigneshr@...com,
frowand.list@...il.com
Subject: Re: [PATCH v8 02/18] soc: ti: k3: add navss ringacc driver
Hi Vinod,
On 1/15/20 4:24 AM, Vinod Koul wrote:
> On 15-01-20, 11:44, Peter Ujfalusi wrote:
>>
>>> I would prefer driver patches to go via driver tree.
>>
>> Not sure what you mean by 'driver patches'...
>> The series to enable DMA support on TI's K3 platform consists:
>> Patch 1-2: Ring Accelerator _driver_ (drivers/soc/ti/)
>> Patch 3-6: DMAengine core patches to add new features needed for k3-udma
>> Patch 7-11: DMA _driver_ patches for K3 (drivers/dma/ti/)
>>
>> Patch 10 depends on the ringacc and the DMAengine core patches
>> Patch 11 depends on patch 10
>>
>> I kept it as a single series in hope that they will go via one subsystem
>> tree to avoid build dependency issues and will have a good amount of
>> time in linux-next for testing.
>>
>>>> Vinod could also perhaps setup an immutable branch based on v5.5-rc1
>>>> with just the drivers/soc/ti parts applied so you can merge that branch
>>>> in case you end up having to send up anything that conflicts.
>>>>
>>> As suggested on other email to Peter, these DMA engine related patches
>>> should be queued up since they don't have any dependency. Based on
>>> the status of that patchset, will take care of pulling in the driver
>>> patches either for this merge window or early part of next merge window.
>>
>> OK, I'll send the two patch for ringacc as a separate series.
>>
>> Vinod: Would it be possible for you to pick up the DMAengine core
>> patches (patch 3-6)?
>> The UDMA driver patches have hard dependency on DMAengine core and
>> ringacc, not sure how they are going to go in...
>
> Since they have build dependency, the usual method for this is:
>
[...]
>
> 2. Santosh picks up ring driver patches, provides a signed immutable tag
> which I will pull in and apply the rest, i.e., dmaengine updates and new
> dmaengine driver
>
I have pushed the ring driver changes with an immutable tag and also
pushed out to next. I will know if it breaks anything in a day.
If all good, will send out the pull request to ARM soc folks.
Since its already late, its not guaranteed that driver will get
picked up for 5.6 but will request and copy you on pull request. Based
on the state of the pull request, I suggest you decide to
pull my tag and rest of the dma patches to your tree so that we
can avoid any breakage in linus's tree. Feel free to add my ack
for rest of the DMA patchset.
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
tags/drivers_soc_for_5.6
Let me know if you have any concerns/questions.
Regards,
Santosh
Powered by blists - more mailing lists