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
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. The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linux 3.10-rc4 (2013-06-02 17:11:17 +0900) are available in the git repository at: git://breakpoint.cc/bigeasy/linux tags/am335x_tsc-adc for you to fetch changes up to fe12425dd7e93db2dfdfa4eb9289036100cb0338: iio/ti_am335x_adc: check if we found the value (2013-06-11 13:11:35 +0200) A complete refurbished series inclunding: - DT support for the MFD, TSC and ADC driver platform device support, which has no users, has been killed. - iio_map from last series is gone and replaced by proper nodes in the device tree. - suspend fixes which means correct data structs are taken and no interrupt storm - fifo split which should problem with TSC ADC beeing used at the same time - The ADC channels are now checked before blindly applied. That means the touch part reads X, Y and Z coordinates and does not mix them up. Same goes for the IIO ADC driver. - The IIO ADC driver now creates files named in_voltageX_raw where X represents the ADC line instead of a number starting at 0. A read from this file can return -EBUSY in case touch is busy and the ADC didn't collect a value. Pantelis Antoniou (2): iio/ti_tscadc: provide datasheet_name and scan_type mfd/ti_tscadc: deal with partial activation Patil, Rachna (7): input/ti_am33x_tsc: Step enable bits made configurable input/ti_am33x_tsc: Order of TSC wires, made configurable input/ti_am33x_tsc: remove unwanted fifo flush input/ti_am33x_tsc: Add DT support iio/ti_am335x_adc: Add DT support mfd/ti_am335x_tscadc: Add DT support arm/am33xx: add TSC/ADC mfd device support Sebastian Andrzej Siewior (13): mfd/ti_am335x_tscadc: remove regmap mfd input iio/ti_am335x_adc: use one structure for ti_tscadc_dev input/ti_am33x_tsc: remove platform_data support iio/ti_am335x_adc: remove platform_data support mfd/ti_am335x_tscadc: remove platform_data support input mfd: ti_am335x_tsc remove remaining platform data pieces mfd input/ti_am335x_tsc: rename device from tsc to TI-am335x-tsc mfd iio/ti_am335x_adc: rename device from tiadc to TI-am335x-adc input/ti_am335x_adc: use only FIFO0 and clean up a little input/ti_am335x_tsc: ACK the HW_PEN irq in ISR input/ti_am335x_tsc: return IRQ_NONE if there was no IRQ for us iio/ti_am335x_adc: Allow to specify input line iio/ti_am335x_adc: check if we found the value .../bindings/input/touchscreen/ti-tsc-adc.txt | 44 +++ arch/arm/boot/dts/am335x-evm.dts | 14 + arch/arm/boot/dts/am33xx.dtsi | 18 ++ drivers/iio/adc/ti_am335x_adc.c| 132 ++--- drivers/input/touchscreen/ti_am335x_tsc.c | 288 ++-- drivers/mfd/ti_am335x_tscadc.c | 133 ++--- include/linux/input/ti_am335x_tsc.h| 23 -- include/linux/mfd/ti_am335x_tscadc.h | 43 +-- include/linux/platform_data/ti_am335x_adc.h| 14 - 9 files changed, 494 insertions(+), 215 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt delete mode 100644 include/linux/input/ti_am335x_tsc.h delete mode 100644 include/linux/platform_data/ti_am335x_adc.h 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
