Re: am335x: TSC ADC reworking including DT pieces, take 4
On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: On 06/11/2013 04:23 PM, Samuel Ortiz wrote: Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. I usually do subsystem / driver: short description but if you want the : as delimiter I can do this. You should always aim to be consistent with the style used by the code you're updating - do a git log and make sure your patches don't have changelogs that are obivously using a different style. signature.asc Description: Digital signature
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/11/2013 07:55 PM, Samuel Ortiz wrote: Hi Jonathan, Hi Samuel, Sebastian, please address the commit log and cosmetic issues I pointed out, keep the regmap code and I'll pull this patchset in. By keep the regmap code you mean I am allowed to remove the regmap usage in mfd (keep patch #1) or do you insist on adding its usage in iio and input? Cheers, Samuel. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Hi Sebastian, On Wed, Jun 12, 2013 at 03:29:43PM +0200, Sebastian Andrzej Siewior wrote: On 06/11/2013 07:55 PM, Samuel Ortiz wrote: Hi Jonathan, Hi Samuel, Sebastian, please address the commit log and cosmetic issues I pointed out, keep the regmap code and I'll pull this patchset in. By keep the regmap code you mean I am allowed to remove the regmap usage in mfd (keep patch #1) or do you insist on adding its usage in iio and input? I insist on keeping it on the MFD driver, i.e. _not_ keeping patch #1. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/12/2013 03:50 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, By keep the regmap code you mean I am allowed to remove the regmap usage in mfd (keep patch #1) or do you insist on adding its usage in iio and input? I insist on keeping it on the MFD driver, i.e. _not_ keeping patch #1. This forces me redo a few things and most likely adding it to the iio and input driver to be consistent here. Could you please give a reason why using the regmap here is a good thing? I mentioned a few why it is not and why is better to leave it out. Cheers, Samuel. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On Wed, Jun 12, 2013 at 04:02:00PM +0200, Sebastian Andrzej Siewior wrote: By keep the regmap code you mean I am allowed to remove the regmap usage in mfd (keep patch #1) or do you insist on adding its usage in iio and input? I insist on keeping it on the MFD driver, i.e. _not_ keeping patch #1. This forces me redo a few things and most likely adding it to the iio and input driver to be consistent here. I'm not asking for that. The current MFD code uses regmap fine without the iio and input using it, I don't see why you would have to add regmap support there. Could you please give a reason why using the regmap here is a good thing? I mentioned a few why it is not and why is better to leave it out. Yes, and I'm not convinced obviously. regmap prevents you from open coding your MMIO access, and this is the right approach. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/12/2013 04:41 PM, Samuel Ortiz wrote: This forces me redo a few things and most likely adding it to the iio and input driver to be consistent here. I'm not asking for that. The current MFD code uses regmap fine without the iio and input using it, I don't see why you would have to add regmap support there. Right. Since no reg-cache is used then this should be fine then. Could you please give a reason why using the regmap here is a good thing? I mentioned a few why it is not and why is better to leave it out. Yes, and I'm not convinced obviously. regmap prevents you from open coding your MMIO access, and this is the right approach. I am not convinced that adding another layer of indirection for doing the same thing is a good approach. Pointer chasing _is_ expensive. _None_ of the regmap features are used here. I would understand if I would re-implement register caching or a wrapper across multiple buses but nothing of this is the case. The current code even ignores the return value. So, are we going to convert all drivers to use regmap now? Cheers, Samuel. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. I added Lee Jones because I hear no sign of life from Samuel. Unfortunately I can't be of any added help here, as I also send my pull-requests though Sam. Sorry I couldn't be of any more use Sebastian. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/11/2013 02:05 PM, Lee Jones wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. I added Lee Jones because I hear no sign of life from Samuel. Unfortunately I can't be of any added help here, as I also send my pull-requests though Sam. Sorry I couldn't be of any more use Sebastian. It sometimes takes him a week or two to respond, but Samuel is pretty reliable when it comes to merging patches, so I wouldn't worry about it. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/11/2013 04:23 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. I usually do subsystem / driver: short description but if you want the : as delimiter I can do this. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. They somehow depend on each other. Otherwise I would have sent three series, one per subsystem. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? The device renaming shouldn't matter since I added DT nodes for the mfd child devices earlier. But then the of_compatible assignments should go hand in hand. However if I split this then the driver won't work but then it does not now as well (because there is no platform_data provider in tree). Still. There is #18 which reworks the step addressing and involves changes in both (iio input) at the same time. There is #21. Adding this to the initial DT support patch would be bad I think because it requires some changes on the iio side which have nothing to do with DT. Putting the iio changes before DT would require to make some change to platform-data part which will go away anyway. So I started collecting ACKs from input and iio to avoid this split. If you really want the split then I will start doing so… Cheers, Samuel. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Hi Samuel, On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Hi Sebastian, On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. They somehow depend on each other. Otherwise I would have sent three series, one per subsystem. Of course they depend on each other, but the dependency is mostly for iio and input to depend on the MFD changes. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? The device renaming shouldn't matter since I added DT nodes for the mfd child devices earlier. But then the of_compatible assignments should go hand in hand. However if I split this then the driver won't work but then it does not now as well (because there is no platform_data provider in tree). Still. There is #18 which reworks the step addressing and involves changes in both (iio input) at the same time. Would splitting iio and input break anything there ? There is #21. Adding this to the initial DT support patch would be bad I think because it requires some changes on the iio side which have nothing to do with DT. Putting the iio changes before DT would require to make some change to platform-data part which will go away anyway. Wouldn't it workif you split this one into an MFD+dts file changes and another one for the iio changes ? So I started collecting ACKs from input and iio to avoid this split. If you really want the split then I will start doing so… I think it would be nicer, yes. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? Sabastian, hold on before reworking your patchset. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/11/2013 06:10 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. They somehow depend on each other. Otherwise I would have sent three series, one per subsystem. Of course they depend on each other, but the dependency is mostly for iio and input to depend on the MFD changes. Except for the one #18 as mentioned below. Still. There is #18 which reworks the step addressing and involves changes in both (iio input) at the same time. Would splitting iio and input break anything there ? Yes. Once the header files is modified without the two .c files the driver is not working. To fix this I need another patch making sure input + iio does not the header files and another to user it (once everything is merged). There is #21. Adding this to the initial DT support patch would be bad I think because it requires some changes on the iio side which have nothing to do with DT. Putting the iio changes before DT would require to make some change to platform-data part which will go away anyway. Wouldn't it workif you split this one into an MFD+dts file changes and another one for the iio changes ? It would work in general. The first few DT-iio patches wouldn't make sense but then why not. So I started collecting ACKs from input and iio to avoid this split. If you really want the split then I will start doing so… I think it would be nicer, yes. Nicer. I see. Please tell me what you think about #1 because I really would like to drop regmap and then I can start reshuffle the series :) Cheers, Samuel. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Samuel Ortiz sa...@linux.intel.com wrote: Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? I have also been avoiding taking any of these and there are unlikely to be any iio wide changes merging at this stage in cycle. Hence these going through MFD is best plan. Lars raised a couple of issues so would be best to wait for his ack if he hasn't already looked at this revision. Thanks Jonathan. Sabastian, hold on before reworking your patchset. Cheers, Samuel. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/11/2013 06:27 PM, Jonathan Cameron wrote: Samuel Ortiz sa...@linux.intel.com wrote: Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? I have also been avoiding taking any of these and there are unlikely to be any iio wide changes merging at this stage in cycle. Hence these going through MFD is best plan. Lars raised a couple of issues so would be best to wait for his ack if he hasn't already looked at this revision. The IIO bits look fine to me in this version. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
Hi Jonathan, On Tue, Jun 11, 2013 at 05:27:48PM +0100, Jonathan Cameron wrote: Samuel Ortiz sa...@linux.intel.com wrote: On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? I have also been avoiding taking any of these and there are unlikely to be any iio wide changes merging at this stage in cycle. Hence these going through MFD is best plan. Thanks. Then I'm willing to try and see if linux-next does not complain too hard about that. Sebastian, please address the commit log and cosmetic issues I pointed out, keep the regmap code and I'll pull this patchset in. If further down the road we get some nasty merge conflicts from linux-next, I might ask you to re-work it. Let's see. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
On 06/11/2013 03:23 PM, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your commit logs, and your subject lines. It should be e.g. mfd: input: ti_am335x_adc: Blablabla if it's mostly an mfd patch that also touches an input driver. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I'd just like to note for future reference that I would prefer Samuels approach of such a branch for future cases where things touch on iio and another subsystem. Now as I've expressed I am happy with this set going through mfd but there is never anything wrong with agreeing how things 'should' be done ;) AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? Cheers, Samuel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html