Messages in this thread | | | Date | Fri, 15 Dec 2023 15:28:13 +0530 | Subject | Re: [PATCH 11/11] ASoC: SOF: topology: Add new DAI type entry for SOF_DAI_AMD_BT | From | Venkata Prasad Potturu <> |
| |
On 12/14/23 22:12, Cristian Ciocaltea wrote: > On 12/14/23 15:15, Venkata Prasad Potturu wrote: >> On 12/14/23 17:53, Cristian Ciocaltea wrote: >>> On 12/11/23 07:58, Venkata Prasad Potturu wrote: >>>> On 12/10/23 21:20, Cristian Ciocaltea wrote: >>>>> On 12/10/23 16:01, Mark Brown wrote: >>>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote: >>>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote: >>>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers >>>>>>>> approved >>>>>>>> this, again need to send to broonie git. >>>>>>>> All the changes in sound/soc/sof/ path should go to SOF git. >>>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not >>>>>>> enough to have this patch cc-ed to >>>>>>> sound-open-firmware@alsa-project.org? >>>>>> The SOF people basically do their own thing in github at >>>>>> >>>>>> https://github.com/thesofproject/linux >>>>>> >>>>>> with a github workflow and submit their patches upstream in batches a >>>>>> few times a release, however my understanding is that their >>>>>> workflow can >>>>>> cope with things going in directly upstream as well. >>>>> Thanks for clarifying, Mark! That would greatly simplify and speedup >>>>> the whole process, at least for trivial patches like this one. >>>> Hi Cristian, >>>> >>>> We have created a Pull request in SOF git hub for I2S BT support. >>>> please hold v2 version SOF patches till below PR get's merged. >>>> PR:- https://github.com/thesofproject/linux/pull/4742 >>> Hi Venkata, >>> >>> If this is going to be handled via the github workflow, this patch >>> should be removed from the series. Since there is no dependency on it, >>> I cannot see a reason to put v2 on hold. >>> >>> Do I miss something? >> Non-sof driver related patches can directly send to broonie git ad v2 >> series. >> SOF driver patches should send to SOF github to avoid merge conflicts >> as per guidelines of SOF community. > Honestly, I don't really see a high risk of conflicts, the patches are > not that complex and can be simply cherry-picked when needed. Moreover, > as we already had people reviewing this, splitting this up will only add > confusion and unnecessary burden. > > Are there any specific changes you are concerned about and cannot be > really handled here? This is not the concern about this patch series, Generally sof driver patches sends to SOF git hub as a PR, these are the guidelines by SOF maintainers. If you still want to send alsa devel list directly, please discuss with SOF maintainers.
| |