From: Vinod Koul <vkoul@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>, santosh.shilimkar@oracle.com
Cc: Sekhar Nori <nsekhar@ti.com>,
robh+dt@kernel.org, nm@ti.com, ssantosh@kernel.org,
dan.j.williams@intel.com, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, grygorii.strashko@ti.com,
lokeshvutla@ti.com, t-kristo@ti.com, tony@atomide.com,
j-keerthy@ti.com, vigneshr@ti.com, frowand.list@gmail.com
Subject: Re: [PATCH v8 02/18] soc: ti: k3: add navss ringacc driver
Date: Wed, 15 Jan 2020 17:54:40 +0530 [thread overview]
Message-ID: <20200115122440.GI2818@vkoul-mobl> (raw)
In-Reply-To: <2c933a6c-37c6-3ef6-7c37-ae36e8c49bf7@ti.com>
On 15-01-20, 11:44, Peter Ujfalusi wrote:
>
>
> On 14/01/2020 20.06, santosh.shilimkar@oracle.com wrote:
> >>>>> Can you please giver your Acked-by for the ringacc patches if they are
> >>>>> still OK from your point of view as you had offered to take them
> >>>>> before
> >>>>> I got comments from Lokesh.
> >>>>>
> >>>> Sure. But you really need to split the series so that dma engine and
> >>>> soc driver patches can be applied independently.
> >>>
> >>> The ringacc is a build and runtime dependency for the DMA. I have hoped
> >>> that all of them can go via DMAengine (hence asking for your ACK on the
> >>> drivers/soc/ti/ patches) for 5.6.
> >>>
> >>>> Can you please do that?
> >>>
> >>> This late in the merge window that would really mean that I will miss
> >>> another release for the KS3 DMA...
> >>> I can live with that if you can pick the ringacc for 5.6 and if Vinod
> >>> takes the DMAengine core changes as well.
> >>>
> >>> That would leave only the DMA drivers for 5.7 and we can also queue up
> >>> changes for 5.7 which depends on the DMAengine API (ASoC changes, UART,
> >>> sa2ul, etc).
> >>>
> >>> If they go independently and nothing makes it to 5.6 then 5.8 is the
> >>> realistic target for the DMA support for the KS3 family of devices...
> >>
> >> Thats too many kernel versions to get this important piece in.
> >>
> >> Santosh, if you do not have anything else queued up that clashes with
> >> this, can the whole series be picked up by Vinod with your ack on the
> >> drivers/soc/ti/ pieces?
> >>
> > 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:
1. Santosh acks the dependent patches and I will apply the rest (nice
and simple)
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
That way we are all okay and changes get merged now.. there is a 3rd
option
3. Santosh picks ring driver patches, and Vinod picks rest after next
rc1 (provided they make to linus in merge window)
I would love to see either 1 or 2 whichever way folks are comfortable
to deal with :)
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>, santosh.shilimkar@oracle.com
Cc: nm@ti.com, devicetree@vger.kernel.org, grygorii.strashko@ti.com,
vigneshr@ti.com, lokeshvutla@ti.com, j-keerthy@ti.com,
Sekhar Nori <nsekhar@ti.com>,
linux-kernel@vger.kernel.org, t-kristo@ti.com, tony@atomide.com,
robh+dt@kernel.org, ssantosh@kernel.org,
dmaengine@vger.kernel.org, dan.j.williams@intel.com,
frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 02/18] soc: ti: k3: add navss ringacc driver
Date: Wed, 15 Jan 2020 17:54:40 +0530 [thread overview]
Message-ID: <20200115122440.GI2818@vkoul-mobl> (raw)
In-Reply-To: <2c933a6c-37c6-3ef6-7c37-ae36e8c49bf7@ti.com>
On 15-01-20, 11:44, Peter Ujfalusi wrote:
>
>
> On 14/01/2020 20.06, santosh.shilimkar@oracle.com wrote:
> >>>>> Can you please giver your Acked-by for the ringacc patches if they are
> >>>>> still OK from your point of view as you had offered to take them
> >>>>> before
> >>>>> I got comments from Lokesh.
> >>>>>
> >>>> Sure. But you really need to split the series so that dma engine and
> >>>> soc driver patches can be applied independently.
> >>>
> >>> The ringacc is a build and runtime dependency for the DMA. I have hoped
> >>> that all of them can go via DMAengine (hence asking for your ACK on the
> >>> drivers/soc/ti/ patches) for 5.6.
> >>>
> >>>> Can you please do that?
> >>>
> >>> This late in the merge window that would really mean that I will miss
> >>> another release for the KS3 DMA...
> >>> I can live with that if you can pick the ringacc for 5.6 and if Vinod
> >>> takes the DMAengine core changes as well.
> >>>
> >>> That would leave only the DMA drivers for 5.7 and we can also queue up
> >>> changes for 5.7 which depends on the DMAengine API (ASoC changes, UART,
> >>> sa2ul, etc).
> >>>
> >>> If they go independently and nothing makes it to 5.6 then 5.8 is the
> >>> realistic target for the DMA support for the KS3 family of devices...
> >>
> >> Thats too many kernel versions to get this important piece in.
> >>
> >> Santosh, if you do not have anything else queued up that clashes with
> >> this, can the whole series be picked up by Vinod with your ack on the
> >> drivers/soc/ti/ pieces?
> >>
> > 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:
1. Santosh acks the dependent patches and I will apply the rest (nice
and simple)
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
That way we are all okay and changes get merged now.. there is a 3rd
option
3. Santosh picks ring driver patches, and Vinod picks rest after next
rc1 (provided they make to linus in merge window)
I would love to see either 1 or 2 whichever way folks are comfortable
to deal with :)
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-15 12:24 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-23 11:04 [PATCH v8 00/18] dmaengine/soc: Add Texas Instruments UDMA support Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 01/18] bindings: soc: ti: add documentation for k3 ringacc Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 02/18] soc: ti: k3: add navss ringacc driver Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:38 ` Peter Ujfalusi
2019-12-23 11:38 ` Peter Ujfalusi
2020-01-13 21:28 ` santosh.shilimkar
2020-01-13 21:28 ` santosh.shilimkar
2020-01-14 6:58 ` Peter Ujfalusi
2020-01-14 6:58 ` Peter Ujfalusi
2020-01-14 8:11 ` Sekhar Nori
2020-01-14 8:11 ` Sekhar Nori
2020-01-14 18:06 ` santosh.shilimkar
2020-01-14 18:06 ` santosh.shilimkar
2020-01-15 9:44 ` Peter Ujfalusi
2020-01-15 9:44 ` Peter Ujfalusi
2020-01-15 12:24 ` Vinod Koul [this message]
2020-01-15 12:24 ` Vinod Koul
2020-01-15 18:26 ` santosh.shilimkar
2020-01-15 18:26 ` santosh.shilimkar
2019-12-23 11:04 ` [PATCH v8 03/18] dmaengine: doc: Add sections for per descriptor metadata support Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 04/18] dmaengine: Add metadata_ops for dma_async_tx_descriptor Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 05/18] dmaengine: Add support for reporting DMA cached data amount Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 06/18] dmaengine: Add helper function to convert direction value to text Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 07/18] dmaengine: ti: Add cppi5 header for K3 NAVSS/UDMA Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 08/18] dmaengine: ti: k3 PSI-L remote endpoint configuration Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 09/18] dt-bindings: dma: ti: Add document for K3 UDMA Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 10/18] dmaengine: ti: New driver " Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 11/18] dmaengine: ti: k3-udma: Add glue layer for non DMAengine users Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 12/18] firmware: ti_sci: rm: Add support for tx_tdtype parameter for tx channel Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 13/18] dmaengine: ti: k3-udma: Wait for peer teardown completion if supported Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 14/18] of: irq: Export of_msi_get_domain Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:36 ` Peter Ujfalusi
2019-12-23 11:36 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 15/18] firmware: ti_sci: Export devm_ti_sci_get_of_resource for modules Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 16/18] dmaengine: ti: k3-udma: Allow the driver to be built as module Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 17/18] dmaengine: ti: k3-udma-glue: " Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2019-12-23 11:04 ` [PATCH v8 18/18] soc: ti: k3-ringacc: " Peter Ujfalusi
2019-12-23 11:04 ` Peter Ujfalusi
2020-01-21 7:41 ` [PATCH v8 00/18] dmaengine/soc: Add Texas Instruments UDMA support Vinod Koul
2020-01-21 7:41 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200115122440.GI2818@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=grygorii.strashko@ti.com \
--cc=j-keerthy@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--cc=santosh.shilimkar@oracle.com \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
--cc=tony@atomide.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.