Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1521302 > unrolled thread
| Started by | Vinod Koul <vinod.koul@intel.com> |
|---|---|
| First post | 2016-11-14 06:10 +0100 |
| Last post | 2016-11-18 17:50 +0100 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver Vinod Koul <vinod.koul@intel.com> - 2016-11-14 06:10 +0100
Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver Peter Griffin <peter.griffin@linaro.org> - 2016-11-14 12:50 +0100
Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver Vinod Koul <vinod.koul@intel.com> - 2016-11-16 04:30 +0100
Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-11-17 07:40 +0100
Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver Vinod Koul <vinod.koul@intel.com> - 2016-11-17 10:50 +0100
Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-11-18 17:50 +0100
| From | Vinod Koul <vinod.koul@intel.com> |
|---|---|
| Date | 2016-11-14 06:10 +0100 |
| Subject | Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver |
| Message-ID | <sDhGN-2pH-5@gated-at.bofh.it> |
On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote: > > > > As you now make changes to the entire remoteproc Kconfig file, rather > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree > > without providing Linus with a messy merge conflict. > > > > So the remoteproc parts now has to go through my tree. > > OK, I think the best approach is for Vinod to create an immutable > branch with the entire fdma series on, and then both of you merge that branch into > your respective trees. my topic/st_fdma is immutable branch. You cna merge it, if you need a signed tag, please do let me know > > That way there won't be any conflicts and you can both accept further changes > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work > because they have dependencies on each other. > > I will send a v11 series in a moment which includes the feedback in this email > and also include the additional fixes which Vinod has applied since the driver > has been in linux-next. WHY.. Stuff is already merged twice! Please send updated on top of already merged code! This is how kernel developement is done... -- ~Vinod
[toc] | [next] | [standalone]
| From | Peter Griffin <peter.griffin@linaro.org> |
|---|---|
| Date | 2016-11-14 12:50 +0100 |
| Message-ID | <sDnVT-6qJ-1@gated-at.bofh.it> |
| In reply to | #1521302 |
Hi Vinod, On Mon, 14 Nov 2016, Vinod Koul wrote: > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote: > > > > > > As you now make changes to the entire remoteproc Kconfig file, rather > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree > > > without providing Linus with a messy merge conflict. > > > > > > So the remoteproc parts now has to go through my tree. > > > > OK, I think the best approach is for Vinod to create an immutable > > branch with the entire fdma series on, and then both of you merge that branch into > > your respective trees. > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed > tag, please do let me know OK. > > > > > That way there won't be any conflicts and you can both accept further changes > > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work > > because they have dependencies on each other. > > > > I will send a v11 series in a moment which includes the feedback in this email > > and also include the additional fixes which Vinod has applied since the driver > > has been in linux-next. > > WHY.. Stuff is already merged twice! When the feedback is "there is an unrelated change in this patch", the only way you can fix that is by having a new version of the patch. >Please send updated on top of already > merged code! You have dropped the remoteproc parts which were updated in v11, so it is no longer merged. Bjorn can now pick the v11 versions if he chooses which incporporates his feedback. >This is how kernel developement is done... regards, Peter.
[toc] | [prev] | [next] | [standalone]
| From | Vinod Koul <vinod.koul@intel.com> |
|---|---|
| Date | 2016-11-16 04:30 +0100 |
| Message-ID | <sDZ57-5t5-5@gated-at.bofh.it> |
| In reply to | #1521564 |
On Mon, Nov 14, 2016 at 11:42:16AM +0000, Peter Griffin wrote: > Hi Vinod, > > On Mon, 14 Nov 2016, Vinod Koul wrote: > > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote: > > > > > > > > As you now make changes to the entire remoteproc Kconfig file, rather > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree > > > > without providing Linus with a messy merge conflict. > > > > > > > > So the remoteproc parts now has to go through my tree. > > > > > > OK, I think the best approach is for Vinod to create an immutable > > > branch with the entire fdma series on, and then both of you merge that branch into > > > your respective trees. > > > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed > > tag, please do let me know > > OK. > > > > > > > > > That way there won't be any conflicts and you can both accept further changes > > > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work > > > because they have dependencies on each other. > > > > > > I will send a v11 series in a moment which includes the feedback in this email > > > and also include the additional fixes which Vinod has applied since the driver > > > has been in linux-next. > > > > WHY.. Stuff is already merged twice! > > When the feedback is "there is an unrelated change in this patch", the only way > you can fix that is by having a new version of the patch. It can be reverted and clean patch applied.. -- ~Vinod
[toc] | [prev] | [next] | [standalone]
| From | Bjorn Andersson <bjorn.andersson@linaro.org> |
|---|---|
| Date | 2016-11-17 07:40 +0100 |
| Message-ID | <sEowx-5vR-7@gated-at.bofh.it> |
| In reply to | #1521302 |
On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote: > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote: > > > > > > As you now make changes to the entire remoteproc Kconfig file, rather > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree > > > without providing Linus with a messy merge conflict. > > > > > > So the remoteproc parts now has to go through my tree. > > > > OK, I think the best approach is for Vinod to create an immutable > > branch with the entire fdma series on, and then both of you merge that branch into > > your respective trees. > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed > tag, please do let me know > Hi Vinod, It looks like you reverted the wrong Kconfig fix, the one I objected to was the change in drivers/remoteproc, not the one in drivers/dma. The ST_FMDA depends on functions exposed by REMOTEPROC and ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you guys made user selectable - and as such should not be selected - but I think we should move forward and get everything merged and then we can go back and figure out how this should be addressed (or left alone?). I have merged "topic/st_fdma" into rproc-next, so that I can fix up the now broken drivers/remoteproc/Kconfig. We do however both need to revert the revert or there will be link errors if you build the dma driver with remoteproc=n. If you do this I can merge the topic once more and we'll keep the set of changes in sync. Regards, Bjorn
[toc] | [prev] | [next] | [standalone]
| From | Vinod Koul <vinod.koul@intel.com> |
|---|---|
| Date | 2016-11-17 10:50 +0100 |
| Message-ID | <sErup-7iB-1@gated-at.bofh.it> |
| In reply to | #1524118 |
On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote: > On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote: > > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote: > > > > > > > > As you now make changes to the entire remoteproc Kconfig file, rather > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree > > > > without providing Linus with a messy merge conflict. > > > > > > > > So the remoteproc parts now has to go through my tree. > > > > > > OK, I think the best approach is for Vinod to create an immutable > > > branch with the entire fdma series on, and then both of you merge that branch into > > > your respective trees. > > > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed > > tag, please do let me know > > > > Hi Vinod, > > It looks like you reverted the wrong Kconfig fix, the one I objected to > was the change in drivers/remoteproc, not the one in drivers/dma. > > The ST_FMDA depends on functions exposed by REMOTEPROC and > ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you > guys made user selectable - and as such should not be selected - but I > think we should move forward and get everything merged and then we can > go back and figure out how this should be addressed (or left alone?). > > I have merged "topic/st_fdma" into rproc-next, so that I can fix up the > now broken drivers/remoteproc/Kconfig. > > We do however both need to revert the revert or there will be link > errors if you build the dma driver with remoteproc=n. If you do this I > can merge the topic once more and we'll keep the set of changes in sync. Oops my bad, thanks for letting me know. I have reverted this now and pushing out. Please do let me know if this was fine Thanks -- ~Vinod
[toc] | [prev] | [next] | [standalone]
| From | Bjorn Andersson <bjorn.andersson@linaro.org> |
|---|---|
| Date | 2016-11-18 17:50 +0100 |
| Message-ID | <sEUwp-1by-11@gated-at.bofh.it> |
| In reply to | #1524204 |
On Thu 17 Nov 01:52 PST 2016, Vinod Koul wrote: > On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote: > > On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote: > > > > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote: > > > > > > > > > > As you now make changes to the entire remoteproc Kconfig file, rather > > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree > > > > > without providing Linus with a messy merge conflict. > > > > > > > > > > So the remoteproc parts now has to go through my tree. > > > > > > > > OK, I think the best approach is for Vinod to create an immutable > > > > branch with the entire fdma series on, and then both of you merge that branch into > > > > your respective trees. > > > > > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed > > > tag, please do let me know > > > > > > > Hi Vinod, > > > > It looks like you reverted the wrong Kconfig fix, the one I objected to > > was the change in drivers/remoteproc, not the one in drivers/dma. > > > > The ST_FMDA depends on functions exposed by REMOTEPROC and > > ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you > > guys made user selectable - and as such should not be selected - but I > > think we should move forward and get everything merged and then we can > > go back and figure out how this should be addressed (or left alone?). > > > > I have merged "topic/st_fdma" into rproc-next, so that I can fix up the > > now broken drivers/remoteproc/Kconfig. > > > > We do however both need to revert the revert or there will be link > > errors if you build the dma driver with remoteproc=n. If you do this I > > can merge the topic once more and we'll keep the set of changes in sync. > > Oops my bad, thanks for letting me know. I have reverted this now and > pushing out. Please do let me know if this was fine > Thanks for the update Vinod, I've merged in your updated branch into mine, so now we should be good. Regards, Bjorn
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web