Re: [PATCH v2 0/5] mfd: twl6030-irq: rework and add twl6032 support
On Tue, Aug 20, 2013 at 08:13:54AM +0100, Graeme Gregory wrote: On 20/08/13 02:01, Samuel Ortiz wrote: Hi Grygorii, On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote: This patch series intorduces twl6030-irq module rework to use Threaded IRQ and linear irq_domain, and adds support for PMIC TWL6032 IRQs. After this patch series TWL6030/6032 IRQs will be supported only for DT boot mode. Changes since v1: - Added new patch mfd: twl6030-irq: create struct twl6030_irq which introduces struct twl6030_irq to store all local variables inside it. - Patch mfd: twl6030-irq: migrate to IRQ threaded handler: Minor comments applied; fixed twl6030_exit_irq(); The Parent IRQ has been set for each nested IRQ. - Patch mfd: twl6030-irq: convert to use linear irq_domain: The irq_find_mapping() is used in twl6030_mmc_card_detect_config() to get virtual IRQ number. This looks good to me. Kevin, Graeme, any further comments/ACKs ? Cheers, Samuel. Yes, it looked good to me as well. Acked-by: Graeme Gregory g...@slimlogic.co.uk Thanks. All 5 patches applied to mfd-next. 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: [PATCH v2 0/5] mfd: twl6030-irq: rework and add twl6032 support
Hi Grygorii, On Thu, Jul 25, 2013 at 04:15:46PM +0300, Grygorii Strashko wrote: This patch series intorduces twl6030-irq module rework to use Threaded IRQ and linear irq_domain, and adds support for PMIC TWL6032 IRQs. After this patch series TWL6030/6032 IRQs will be supported only for DT boot mode. Changes since v1: - Added new patch mfd: twl6030-irq: create struct twl6030_irq which introduces struct twl6030_irq to store all local variables inside it. - Patch mfd: twl6030-irq: migrate to IRQ threaded handler: Minor comments applied; fixed twl6030_exit_irq(); The Parent IRQ has been set for each nested IRQ. - Patch mfd: twl6030-irq: convert to use linear irq_domain: The irq_find_mapping() is used in twl6030_mmc_card_detect_config() to get virtual IRQ number. This looks good to me. Kevin, Graeme, any further comments/ACKs ? 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: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi, On Thu, Jun 20, 2013 at 04:32:15PM +0530, J Keerthy wrote: Add TPS659038 support. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Mark Brown broo...@linaro.org --- drivers/regulator/palmas-regulator.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Applied to mfd-next, thanks. 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: [PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support
Hi, On Thu, Jun 20, 2013 at 04:35:16PM +0530, J Keerthy wrote: The Patch adds TPS659038 PMIC support in the palmas mfd driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/palmas.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Applied, thanks. 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: [PATCH] MFD: Change TWL6025 references to TWL6032
Hi Oleksandr, On Wed, Jun 19, 2013 at 03:24:02PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there are no users of TWL6025 in the code. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com Acked-by: Lee Jones lee.jo...@linaro.org --- There are non-mainline branches that use twl6032 by its name (for example git://git.omapzoom.org/kernel/omap.git). There is intention to add support of twl6032 device in mainline, but we'd like to know if we can use twl6032 instead of twl6025 in our new patches, that we are going to provide. Related discussion: https://patchwork.kernel.org/patch/2686331/ .../bindings/regulator/twl-regulator.txt | 26 +++ .../devicetree/bindings/usb/twl-usb.txt|2 +- drivers/mfd/twl-core.c | 46 ++-- drivers/regulator/twl-regulator.c | 76 ++-- drivers/usb/phy/phy-twl6030-usb.c |2 +- include/linux/i2c/twl.h| 30 6 files changed, 91 insertions(+), 91 deletions(-) Applied to mfd-next, thanks. 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: [PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
Hi, On Wed, Jun 19, 2013 at 11:27:46AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html V3: Implements Interrupts check using i2c-irq variable instead of DT interrupts property. Cleans ups in assiging the features variable in patch 2. V2: Implements Interrupts checking via DT instead of creating flags and checking based on chip ID. J Keerthy (4): MFD: Palmas: Check if irq is valid MFD: Palmas: Add SMPS10_BOOST feature mfd: Palmas: Add TPS659038 PMIC support regulator: Palmas: Add TPS659038 support I took the first 2 patches, but patch #3 does not apply. 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: [PATCH v3 3/4] mfd: Palmas: Add TPS659038 PMIC support
Hi, On Wed, Jun 19, 2013 at 11:27:49AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com The Patch adds TPS659038 PMIC support in the palmas mfd driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. Signed-off-by: J Keerthy j-keer...@ti.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ drivers/mfd/palmas.c |5 + 2 files changed, 7 insertions(+), 0 deletions(-) This one does not apply against mfd-next as I don't have the palmas.txt. For Grant to take this one: Acked-by: Samuel Ortiz sa...@linux.intel.com If that creates conflicts (I already have a few palmas.c changes) then we'll have to find a way to fix them (Me taking the bindings file ?). 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: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hi, On Thu, Jun 20, 2013 at 04:34:42AM +, J, KEERTHY wrote: -Original Message- From: J, KEERTHY Sent: Wednesday, June 19, 2013 11:28 AM To: linux-omap@vger.kernel.org Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature From: J Keerthy j-keer...@ti.com The SMPS10 regulator is not presesnt in all the variants of the PALMAS PMIC family. Hence adding a feature to distingush between them. Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. 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: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
On Thu, Jun 20, 2013 at 09:13:06AM +, J, KEERTHY wrote: Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. So the of_match_device parts can come under #ifdef CONFIG_OF? Nevermind, you were just missing an of_device.h inclusion. I fixed that up and applied your patch. 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: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
Hi Lee, On Wed, Jun 19, 2013 at 09:26:33AM +0100, Lee Jones wrote: On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. It's already in mfd-next. 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: [PATCH v2] mfd: Palmas: Remove code which is not necessary for a device tree boot
Hi, On Mon, Jun 17, 2013 at 05:17:58PM +0530, J Keerthy wrote: Remove code which is not necessary for a device tree boot. Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Laxman Dewangan ldewan...@nvidia.com Acked-by: Graeme Gregory g...@slimlogic.co.uk --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) Applied to mfd-next, thanks. 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: [PATCH] mfd: twl4030: allow IRQ wake enable to succeed on subchip IRQs
Hi Kevin, On Fri, May 31, 2013 at 02:44:54PM -0700, Kevin Hilman wrote: The genirq IRQ wake method will default to failure if the irq_chip does not provide a set_wake method. However, for TWL4030 sub-chip IRQs, we want the wake enable to succeed even though we don't provide a set_wake method. This allows sub-chip IRQs to still be flagged as wakeup capable, and allow them to wakeup from suspend (or abort suspend if they fire during suspend.) To fix, use the IRQCHIP_SKIP_SET_WAKE flag in the irq_chip. Signed-off-by: Kevin Hilman khil...@linaro.org --- drivers/mfd/twl4030-irq.c | 1 + 1 file changed, 1 insertion(+) Applied to mfd-next, thanks. 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 5
Hi Sebastian, On Wed, Jun 12, 2013 at 06:58:01PM +0200, Sebastian Andrzej Siewior wrote: Hi Samuel, I did the cosmetic changes of the subject line and removed the changes from within the sob lines in each patch. I dropped the #define XPP STEPCONFIG_XPP thingy and patch #1 which removed regmap from mfd. Not that I agree with it, I just do not want to miss the merge window due to this. 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 Pulled and pushed back to mfd-next, thanks. I fixed a couple of unused variable warnings on top of it. 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 5
Hi Sebastian, On Thu, Jun 13, 2013 at 11:25:26AM +0200, Sebastian Andrzej Siewior wrote: I fixed a couple of unused variable warnings on top of it. I saw your patch at git.k.o and I am asking you not to taking it :) I understand why now, I'll remove it. Sorry about that. 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 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 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: [PATCH 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:50PM +0200, Sebastian Andrzej Siewior wrote: diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h index eeead15..2d78af8 100644 --- a/include/linux/mfd/ti_am335x_tscadc.h +++ b/include/linux/mfd/ti_am335x_tscadc.h @@ -71,8 +71,6 @@ #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8) #define STEPCONFIG_INP_MASK (0xF 19) #define STEPCONFIG_INP(val) ((val) 19) -#define STEPCONFIG_INP_AN2 STEPCONFIG_INP(2) -#define STEPCONFIG_INP_AN3 STEPCONFIG_INP(3) #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4) #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8) #define STEPCONFIG_FIFO1 BIT(26) @@ -94,7 +92,6 @@ #define STEPCHARGE_INM_AN1 STEPCHARGE_INM(1) #define STEPCHARGE_INP_MASK (0xF 19) #define STEPCHARGE_INP(val) ((val) 19) -#define STEPCHARGE_INP_AN1 STEPCHARGE_INP(1) #define STEPCHARGE_RFM_MASK (3 23) #define STEPCHARGE_RFM(val) ((val) 23) #define STEPCHARGE_RFM_XNUR STEPCHARGE_RFM(1) @@ -116,6 +113,13 @@ #define CNTRLREG_8WIRE CNTRLREG_AFE_CTRL(3) #define CNTRLREG_TSCENB BIT(7) +#define XPP STEPCONFIG_XPP +#define XNP STEPCONFIG_XNP +#define XNN STEPCONFIG_XNN +#define YPP STEPCONFIG_YPP +#define YPN STEPCONFIG_YPN +#define YNN STEPCONFIG_YNN What is that for ? Isn't STEPCONFIG_XPP explicit enough ? 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: [PATCH 01/22] mfd/ti_am335x_tscadc: remove regmap
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:47PM +0200, Sebastian Andrzej Siewior wrote: The MFD part uses regmap without caching and is the only user of the regmap. The child drivers, that is input(touch) and iio(adc), use direct reg access. There is a patch which converts them to use regmap as well but I see no benefit at all doing this. There is a direct MMIO bus access with no need to cache values like for I2C or SPI devices. Furthermore, most (if not all) of the access done by the touch ADC driver read volatile register. Therefore this patch removes regmap part of the driver. NAK. Using regmap is better than open coding your register accesses, and the children not using this API is not a reason for the MFD driver to do the same. 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 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: [PATCH 10/22] mfd/ti_am335x_tscadc: Add DT support
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:56PM +0200, Sebastian Andrzej Siewior wrote: From: Patil, Rachna rac...@ti.com Make changes to add DT support in the MFD core driver. Which changes ? [ pa...@antoniou-consulting.com : use of_get_child_by_name instead of of_find_node_by_name ] I have no idea where that is coming from. Please remove this kind of stuff and build a proper commit log instead. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Patil, Rachna rac...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com [bigeasy: module alias, rename to ti,am3359-tscadc as it was tested on AM3359] I honestly can't tell if this is a change from the last version of your patchset or a description of this patch changes in general. This is cluttering your commit logs, please remove this as well. 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: [PATCH 10/22] mfd/ti_am335x_tscadc: Add DT support
Hi Sebastian, On Tue, Jun 11, 2013 at 04:42:30PM +0200, Sebastian Andrzej Siewior wrote: In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? You probably don't want to change authorship unless the final patch is really far from the original one. In which case you can change it and mention the original author name in the commit log. If you have only made a few changes on top of the original patch, please say so explicitely in the commit log. Don't bother if we're talking about small changes or cosmetic ones. But your commit log has to be readable and clear. 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 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
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: [PATCH 2/2] mfd: twl-core: convert to module_i2c_driver()
Hi Grygorii, On Tue, Apr 23, 2013 at 04:19:10PM +0300, Grygorii Strashko wrote: Shift TWL initialization to module/device init layer, because I2C now is not initialized on subsys init layer and shifted to module/device init layer instead. The I2C -- TWL dependency should be resolved in drivers/Makefile now. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/mfd/twl-core.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) I applied this one to mfd-next for now, and will move it to mfd-fixes if someone confirms that this is indeed a fix. 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: [RFC PATCH v2 1/4] retu-mfd: support also Tahvo
Hi Aaro, On Tue, Apr 09, 2013 at 10:51:25PM +0300, Aaro Koskinen wrote: Tahvo is a multi-function device on Nokia 770, implementing USB transceiver and charge/battery control. It's so close to Retu that a single driver can support both. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/Kconfig |6 ++-- drivers/mfd/retu-mfd.c | 85 -- include/linux/mfd/retu.h |8 - 3 files changed, 85 insertions(+), 14 deletions(-) Simple and good enough, I applied this one. 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: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
Hi Roger, On Mon, Mar 25, 2013 at 12:42:04PM +0200, Roger Quadros wrote: Hi Samuel, I've rebased this now on top of 3.9-rc4. Please pull this into your next branch when appropriate. Thanks. The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: Linux 3.9-rc4 (2013-03-23 16:52:44 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-mfd-next Roger Quadros (5): mfd: omap-usb-host: update nports in platform_data mfd: omap-usb-host: Remove PHY reset handling code mfd: omap-usb-tll: move configuration code to omap_tll_init() mfd: omap-usb-tll: Add device tree support and binding information mfd: omap-usb-host: Add device tree support and binding information I had to apply them manually, as patches #2 and #5 do not apply. I am pushing #1, #3 and #4, please rebase 2 and 5 on top of mfd-next and resend them to me. 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: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
On Tue, Apr 09, 2013 at 11:39:16AM +0300, Roger Quadros wrote: Samuel, You had the conflicts because a patch [*] was introduced and is not required since the reset logic is being removed from the driver. Anyways, I've rebased the 2 patches on top of mfd-next, so now it shouldn't matter. Both patches applied, thanks a lot. 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: [RFC PATCH 1/4] retu-mfd: support also Tahvo
Hi Aaro, On Thu, Mar 07, 2013 at 04:40:18PM +0200, Aaro Koskinen wrote: Tahvo is a multi-function device on Nokia 770, implementing USB transceiver and charge/battery control. It's so close to Retu that a single driver can support both. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/Kconfig |6 +-- drivers/mfd/retu-mfd.c | 95 +++--- include/linux/mfd/retu.h |8 +++- 3 files changed, 92 insertions(+), 17 deletions(-) Overall the patch looks good, but could you please adress Felipe's comments on it ? 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: [GIT PULL] common: OMAP USB Host cleanup for 3.9
Hi Roger, On Thu, Feb 14, 2013 at 02:01:25PM +0200, Roger Quadros wrote: Hi Tony Samuel, This is the common patch for the OMAP USB Host cleanup series for 3.9. It makes changes to platform headers only. The other 2 pull requests, one for each of you will be based on this. This is based on 3.8-rc6. Please pull. Thanks. The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://github.com/rogerq/linux.git usbhost17-common Pulled, thanks. 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: [PATCH v2 00/11] MFD: twl-core: Cleanup part 2 for 3.9
Hi Peter, On Wed, Jan 16, 2013 at 02:53:48PM +0100, Peter Ujfalusi wrote: Hello Samuel, Changes since v1: - Patch for zoom-display to avoid build issus with this set I had a patch on top of this series to move the zoom board to use bl-pwm for display backlight. Because of this I have not noticed that the zoom-display.c still have twl related code in upstream. Cover letter from v1: Second part of the cleanup of twl-core which aims to make the code a bit more readable. It has been tested on: OMAP4 PandaBoard, OMAP4 Blaze, OMAP3 BeagleBoard, OMAP3 Zoom2. Regards, Peter --- Peter Ujfalusi (11): ARM: OMAP: zoom-display: Remove the use of TWL4030_MODULE_PWM1 mfd: twl-core: Clean up module id lookup and definitions mfd: twl-core: No need to check for invalid subchip ID mfd: twl-core: Use the lookup table to find the correct subchip for the modules mfd: twl-core: Allocate twl_modules dynamically mfd: twl-core: Do not try to call legacy mfd add_children() when booted with DT mfd: twl-core: Do not create dummy pdata when booted with DT mfd: twl-core: Move 'inuse' check early at probe time mfd: twl-core: Collect global variables behind one private structure (global) mfd: twl-core: Remove no longer valid comment regarding to write buffer size mfd: twl-core: Move twl_i2c_read/write_u8 to header as inline function arch/arm/mach-omap2/board-zoom-display.c | 14 +- drivers/mfd/twl-core.c | 362 ++- include/linux/i2c/twl.h | 84 +++ 3 files changed, 212 insertions(+), 248 deletions(-) Thanks, all 11 patches applied to my for-next branch. 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: [PATCH v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Hi Tony, On Thu, Dec 13, 2012 at 01:49:49PM -0800, Tony Lindgren wrote: Hi Samuel, * Roger Quadros rog...@ti.com [121210 02:23]: Instead of using cpu_is_omap..() macros in the device driver we rely on information provided in the platform data. The only information we need is whether the USB Host module has a single ULPI bypass control bit for all ports or individual bypass control bits for each port. OMAP3 REV2.1 and earlier have the former. I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h for omaps by -rc1 before more drivers start using it again. That is assuming nobody else is planning on merging this series for v3.8 presumably. This should go into 3.9, yes. Want to ack this one? Looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH v3 2/5] mfd: tps65217: Set PMIC to shutdown on PWR_EN toggle
Hi Anilkumar, On Tue, Nov 20, 2012 at 03:18:44PM +0530, AnilKumar Ch wrote: From: Colin Foe-Parker colin.foepar...@logicpd.com Set tps65217 PMIC status to OFF if power enable toggle is supported. By setting this bit to 1 to enter PMIC to OFF state when PWR_EN pin is pulled low. Also adds a DT flag to specify that device pmic supports shutdown control or not. Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com [anilku...@ti.com: move the additions to tps65217 MFD driver] Signed-off-by: AnilKumar Ch anilku...@ti.com --- .../devicetree/bindings/regulator/tps65217.txt |4 drivers/mfd/tps65217.c | 12 2 files changed, 16 insertions(+) Applied, thanks. I suppose you're not expecting the whole patchset to go through one tree ? 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: [PATCH v4 2/4] mfd: introduce retu-mfd driver
Hi Aaro, On Sun, Nov 18, 2012 at 06:36:20PM +0200, Aaro Koskinen wrote: Retu is a multi-function device found on Nokia Internet Tablets implementing at least watchdog, RTC, headset detection and power button functionality. This patch implements minimum functionality providing register access, IRQ handling and power off functions. Cc: Samuel Ortiz sa...@linux.intel.com Acked-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/mfd/Kconfig |9 ++ drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 264 ++ include/linux/mfd/retu.h | 22 4 files changed, 296 insertions(+) create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 include/linux/mfd/retu.h Thanks, I applied this one to my for-next branch. 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: [PATCH 00/13] MFD: twl drivers: Convert to regmap IO and cleanups
Hi Peter, On Tue, Nov 13, 2012 at 09:28:41AM +0100, Peter Ujfalusi wrote: Hello, This series converts the twl-core to use regmap for IO towards the chip. With the conversion to regmap IO we no longer need to allocate bigger buffer for writes. I have appended patches to this series to make some cleanups which will help in the future to further clean up the twl stack. The series depends on a regression fix patch for the twl-core: https://patchwork.kernel.org/patch/1679421/ Regards, Peter --- Peter Ujfalusi (13): MFD: twl-core: Register twl4030-madc child only for twl4030 class MFD: twl-core: Support for proper PWM drivers MFD: twl-core: Convert to use regmap for I/O MFD/rtc/gpio: twl: No need to allocate bigger buffer for write MFD: twl-core: Clean up and correct child registration mfd: twl: Remove unused TWL_MODULE definitions mfd: twl: Convert module id definitions to enums mfd: twl: Use decimal numbers for TWL6030_MODULE_IDs MFD: twl-core: re-group the twl_mapping table for easier reading mfd: twl4030-madc: Change TWL4030_MODULE_* ids to TWL_MODULE_* mfd: twl4030-power: Change TWL4030_MODULE_* ids to TWL_MODULE_* mfd: twl4030-irq: Change TWL4030_MODULE_* ids to TWL_MODULE_* mfd: twl-core: Change TWL4030_MODULE_* ids to TWL_MODULE_* All patches applied now, thanks. 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: [PATCH 1/1] twl4030: Fix chained irq handling on resume from suspend
Hi Kalle, On Tue, Oct 16, 2012 at 05:59:35PM +0300, Kalle Jokiniemi wrote: The irqs are enabled one-by-one in pm core resume_noirq phase. This leads to situation where the twl4030 primary interrupt handler (PIH) is enabled before the chained secondary handlers (SIH). As the PIH cannot clear the pending interrupt, and SIHs have not been enabled yet, a flood of interrupts hangs the device. Fixed the issue by setting the SIH irqs with IRQF_EARLY_RESUME flags, so they get enabled before the PIH. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com --- drivers/mfd/twl4030-irq.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Thanks, patch applied to my for-linus branch. 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: [PATCH 08/16] ARM: OMAP2: Move plat/menelaus.h to linux/mfd/menelaus.h
Hi Tony, On Thu, Oct 04, 2012 at 03:04:52PM -0700, Tony Lindgren wrote: We can move menelaus.h to live with other mfd headers to get it out of plat for ARM common zImage support. Cc: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi Sourav, On Mon, Oct 01, 2012 at 04:31:22PM +0530, Sourav Poddar wrote: smsc ece1099 is a keyboard scan or gpio expansion device. The patch create keypad and gpio expander child for this multi function smsc driver. Tested on omap5430 evm with 3.6-rc6 custom kernel. Cc: Samuel Ortiz sa...@linux.intel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- Changes since v2: - Change the cache type, max register assignment - remove of_device_table, since i2c based device gets probed according to i2c_device_id through dt. - Modify the remove function - Minor return patch cleanups. Documentation/smsc_ece1099.txt | 56 drivers/mfd/Kconfig| 12 drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 113 include/linux/mfd/smsc.h | 109 ++ 5 files changed, 291 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h Applied with a warning fix for the !CONFIG_OF case. 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: [PATCH v4 2/2] mfd: Add backlight as subdevice to the tps65217
Hi Matthias, On Mon, Sep 24, 2012 at 10:25:34PM +0200, Matthias Kaehlcke wrote: mfd: Add backlight as subdevice to the tps65217 Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- drivers/mfd/tps65217.c |3 +++ 1 file changed, 3 insertions(+) Applied, thanks. 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: [PATCH v4 1/2] backlight: Add TPS65217 WLED driver
Hi Matthias, On Mon, Sep 24, 2012 at 10:25:28PM +0200, Matthias Kaehlcke wrote: The TPS65217 chip contains a boost converter and current sinks which can be used to drive LEDs for use as backlights. Expose this functionality via the backlight API. Tested on an AM335x based custom board with a single WLED string, using different values for ISEL and FDIM (though it would be hard to tell the difference except for the value in WLEDCTRL1). Both instantiation through the device tree and by passing platform data have been tested. Testing has been done with an Androidized 3.2 kernel from the rowboat project. Koen Kooi reported the driver to be working on a Beaglebone board with LCD3 cape This patch is based on the mfd branch (20120924) Changes since v3: * split in two patches, one for the driver another for adding the mfd subdevice * renamed variable on to is_enabled and changed type to boolean Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- drivers/video/backlight/Kconfig |7 + drivers/video/backlight/Makefile |1 + drivers/video/backlight/tps65217_bl.c | 352 + include/linux/mfd/tps65217.h | 18 ++ 4 files changed, 378 insertions(+) create mode 100644 drivers/video/backlight/tps65217_bl.c Applied as well, although it could go through Richard's tree. Having his review would be nice anyway. 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: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation
Hi Paul, On Wed, Sep 19, 2012 at 08:39:40PM +, Paul Walmsley wrote: Hi Samuel, I've queued patch 1 of this series for 3.7, which should go upstream via the OMAP - arm-soc path. Also asked Keshava to re-send patch 5 to me once patches 2-4 have been merged. It's up to you how to handle patches 2-4. The series is a good step forward for us in terms of cleanup. But what is probably worthwhile at some point is for that USB TLL phy code (added in patch 2) to be moved into some place like drivers/usb/phy, since it's not MFD-related. That would be ideal, yes. I kept patches 2-4 as they're alreeady going in the right direction (I dropped patches 1 and 5). Thanks for the heads up. 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: omap-usb-tll build broken in linux next
Hi Tony, On Thu, Sep 20, 2012 at 11:34:42AM -0700, Tony Lindgren wrote: Hi Keshava Felipe, Looks like we have something broken in linux next: make[2]: *** No rule to make target `drivers/mfd/omap-usb-tll.o', needed by `drivers/mfd/built-in.o'. Stop. This is at least with my n8x0 config, see the attached file. Thanks for the notification. Felipe was right, I forgot a git add...It should be all fixed now. 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: [PATCH v2 0/3] MFD/GPIO: Add twl6040 GPO driver
Hi Peter, On Thu, Aug 16, 2012 at 03:13:12PM +0300, Peter Ujfalusi wrote: Hello, Changes since v1: - Removed the ti,use-gpo property from DT bindings - Register the GPO driver if we booted with DT blob or in legacy if the pdata for the GPO driver is present - DT binding Documentation update The Documentation update has reference to the twl6040.dtsi file which will be created to hold the common/static properties for the twl6040. To avoid cross tree merge issues later I have only included the Documentation update to this series and I will send the actual .dtsi/.dts changes via linux-omap. If this is not a problem. The dependencies for this series are in mainline and I think this series can go via GPIO if Samuel agrees with the changes. Intro mail from v1: The following series adds support for the GPO (General Purpose Output) on the twl6040/41 audio chip. The series has been tested on SDP4430, compile tested for x86_64 and x86_32 bit to be sure it does not introduce build breakage. Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Fix GPO mask mfd: twl6040: Add twl6040-gpio child gpio: Add basic support for TWL6040 GPOs All 3 patches applied, thanks. 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: [PATCH v2 0/3] MFD/GPIO: Add twl6040 GPO driver
Hi Peter, On Thu, Aug 16, 2012 at 03:13:12PM +0300, Peter Ujfalusi wrote: Hello, Changes since v1: - Removed the ti,use-gpo property from DT bindings - Register the GPO driver if we booted with DT blob or in legacy if the pdata for the GPO driver is present - DT binding Documentation update The Documentation update has reference to the twl6040.dtsi file which will be created to hold the common/static properties for the twl6040. To avoid cross tree merge issues later I have only included the Documentation update to this series and I will send the actual .dtsi/.dts changes via linux-omap. If this is not a problem. The dependencies for this series are in mainline and I think this series can go via GPIO if Samuel agrees with the changes. Intro mail from v1: The following series adds support for the GPO (General Purpose Output) on the twl6040/41 audio chip. The series has been tested on SDP4430, compile tested for x86_64 and x86_32 bit to be sure it does not introduce build breakage. Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Fix GPO mask mfd: twl6040: Add twl6040-gpio child gpio: Add basic support for TWL6040 GPOs All 3 patches applied, thanks. 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: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation
Hi Keshava, On Mon, Jul 16, 2012 at 07:01:06PM +0530, Keshava Munegowda wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks All 5 patches applied now. I had to manually apply patches #1 and #5. Could you please check that it's looking good 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: [PATCH v2] backlight: Add TPS65217 WLED driver
Hi Matthias, On Tue, Sep 18, 2012 at 10:05:07PM +0200, Matthias Kaehlcke wrote: The MFD API probably allows you to do exactly that by defining a specific cell for bl. Could you please try to use this API or otherwise justify not using it? you seem to have missed v3 of the patch which addresses this, it was sent on 22 Aug 2012 Indeed, I missed it. Looks much better. in the next days i'll submit v4, with changes based on the comments received for v3 Sounds good. 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: [RFC PATCH 2/5] mfd: introduce retu-mfd driver
Hi Aaro, On Wed, Aug 29, 2012 at 12:34:24AM +0300, Aaro Koskinen wrote: Retu is a multi-function device found on Nokia Internet Tablets implementing at least watchdog, RTC, headset detection and power button functionality. This patch implements a minimum functionality providing only register access functions. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sa...@linux.intel.com --- drivers/mfd/Kconfig |8 +++ drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 114 ++ include/linux/mfd/retu.h | 20 4 files changed, 143 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 include/linux/mfd/retu.h Besides Felipe's comments, you probably want to use regmap I2C for this driver. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b1a1462..8ca1270 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1003,6 +1003,14 @@ config MFD_PALMAS If you say yes here you get support for the Palmas series of PMIC chips from Texas Instruments. +config MFD_RETU + tristate Support for Retu multi-function device + select MFD_CORE + depends on I2C + help + Retu is a multi-function device found on Nokia Internet Tables + (770, N800 and N810). Which sub devices does it come with ? 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: [PATCH 2/4] mfd: introduce retu-mfd driver
Hi Aaro, On Mon, Sep 03, 2012 at 11:23:23PM +0300, Aaro Koskinen wrote: Retu is a multi-function device found on Nokia Internet Tablets implementing at least watchdog, RTC, headset detection and power button functionality. This patch implements minimum functionality providing register access, IRQ handling and power off functions. Cc: sa...@linux.intel.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/mfd/Kconfig |8 + drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 347 ++ include/linux/mfd/retu.h | 22 +++ 4 files changed, 378 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 include/linux/mfd/retu.h Now with the IRQ chip code, using the regmap APIs would be even more benefitial. 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: [PATCH v4 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support
Hi Peter, On Mon, Sep 10, 2012 at 01:46:18PM +0300, Peter Ujfalusi wrote: Hello, Generated on top of: git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/omap I applied the first 8 patches, but I'd like to get Mark's ACK for the rest of the serie. Unless you're expecting Mark to take the whole thing, in which case you can add my: Acked-by: Samuel Ortiz sa...@linux.intel.com to the MFD patches. Please let me know how you'd like to proceed. 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: [PATCH] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
Hi Tony, On Mon, Sep 17, 2012 at 01:29:44PM -0700, Tony Lindgren wrote: Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke compile for non-omap as include plat/cpu.h was added: drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or directory This header was indirectly included earlier when SPARSE_IRQ was not set, but does not exist on most platforms. Fix the problem by removing the cpu_is_omap usage that should not exist in drivers at all. We can do this by adding proper clock aliases for the twl-core.c drivers, and drop separate handling for cases when clock framework is not available as the behaviour will stay the same. Note that we need to add a platform device to avoid using the i2c provided names that may be different on various omaps. Reported-by: Fengguang Wu fengguang...@intel.com Reported-by: Stephen Rothwell s...@canb.auug.org.au Cc: Paul Walmsley p...@pwsan.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Arnd Bergmann a...@arndb.de Cc: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com --- Samuel, I'd like to queue this via arm-soc as that's where I have the breaking patch is if this patch is OK with you. That's fine with me: Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH v2] backlight: Add TPS65217 WLED driver
Hi Matthias,
On Thu, Aug 09, 2012 at 10:42:31PM +0200, Matthias Kaehlcke wrote:
The TPS65217 chip contains a boost converter and current sinks which can be
used to drive LEDs for use as backlights. Expose this functionality via the
backlight API.
Tested on an AM335x based custom board with a single WLED string, using
different values for ISEL and FDIM (though it would be hard to tell the
difference except for the value in WLEDCTRL1). Both instantiation through the
device tree and by passing platform data have been tested. Testing has been
done with an Androidized 3.2 kernel from the rowboat project
This patch is based on the mfd tree, it also applies on linux-next (20120809)
It doesn't seem to apply to my for-next branch.
Also, some comments:
@@ -174,6 +174,10 @@ static struct tps65217_board *tps65217_parse_dt(struct
i2c_client *client)
pdata-of_node[i] = reg_matches[i].of_node;
}
+ node = of_find_node_by_name(node, backlight);
+ if (node)
+ pdata-of_node[TPS65217_SUBDEV_BL] = node;
+
return pdata;
}
@@ -250,7 +254,32 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
platform_device_add(pdev);
}
+ if (pdata-bl_pdata || pdata-of_node[TPS65217_SUBDEV_BL]) {
+ tps-bl_pdev = platform_device_alloc(tps65217-bl, 0);
+ if (!tps-bl_pdev) {
+ dev_err(tps-dev, Cannot create backlight platform
device\n);
+ ret = -ENOMEM;
+ goto err_alloc_bl_pdev;
+ }
+
+ tps-bl_pdev-dev.parent = tps-dev;
+
+ if (pdata-bl_pdata)
+ tps-bl_pdev-dev.platform_data = pdata-bl_pdata;
+ else
+ tps-bl_pdev-dev.of_node =
+ pdata-of_node[TPS65217_SUBDEV_BL];
+
+ platform_device_add(tps-bl_pdev);
+ }
+
The MFD API probably allows you to do exactly that by defining a specific cell
for bl. Could you please try to use this API or otherwise justify not using
it?
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: [PATCH v2] mfd/regulator: tps65217: Move regulator plat data handling to regulator
Hi AnilKumar, On Mon, Aug 13, 2012 at 08:36:05PM +0530, AnilKumar Ch wrote: Regulator platform data handling was mistakenly added to MFD driver. So we will see build errors if we compile MFD drivers without CONFIG_REGULATOR. This patch moves regulator platform data handling from TPS65217 MFD driver to regulator driver. This makes MFD driver independent of REGULATOR framework so build error is fixed if CONFIG_REGULATOR is not set. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' This patch also fix allocation size of tps65217 platform data. Current implementation allocates a struct tps65217_board for each regulator specified in the device tree. But the structure itself provides array of regulators so one instance of it is sufficient. Signed-off-by: AnilKumar Ch anilku...@ti.com --- This patch is tested on BeagleBone with regulator device node additions. And this is based on mfd/master. Changes from v1: - Incorporated Matthias Kaehlcke's commets on v1 * Fixed allocation size of tps65217 platform data drivers/mfd/tps65217.c | 130 +++- drivers/regulator/tps65217-regulator.c | 124 ++ include/linux/mfd/tps65217.h | 12 ++- 3 files changed, 161 insertions(+), 105 deletions(-) Applied to my for-next and for-linus branches, thanks. Btw, this is too big of a patch for stable. 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: [PATCH] mfd/regulator: tps65217: Move regulator plat data handling to regulator
Hi Anilkumar, On Fri, Jul 20, 2012 at 03:00:01PM +0530, AnilKumar Ch wrote: Regulator platform data handling was mistakenly added to MFD driver. So we will see build errors if we compile MFD drivers without CONFIG_REGULATOR. This patch moves regulator platform data handling from TPS65217 MFD driver to regulator driver. This makes MFD driver independent of REGULATOR framework so build error is fixed if CONFIG_REGULATOR is not set. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' This patch is based on linux-next (20120720) tree Signed-off-by: AnilKumar Ch anilku...@ti.com --- drivers/mfd/tps65217.c | 130 +++- drivers/regulator/tps65217-regulator.c | 124 ++ include/linux/mfd/tps65217.h | 12 ++- 3 files changed, 161 insertions(+), 105 deletions(-) It doesn't apply to my for-next branch. Could you please re-send this one after the merge window is closed ? I'll push that as part of the MFD fixes for 3.6. 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: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? 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: [PATCH] MFD: twl-core: move device_init_wakeup to after platform_device_add.
Hi Neil, On Sat, Jul 07, 2012 at 08:51:03AM +1000, NeilBrown wrote: device_init_wakeup uses the dev_name() of the device to set the name of the wakeup_source which appears in /sys/kernel/debug/wakeup_sources. For a platform device, that name is not set until platform_device_add calls dev_set_name. So the call to device_init_wakeup() must be after the call to platform_device_add(). Making this change causes correct names to appear in the wakeup_sources file. Applied, thanks. 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: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Kevin, Keshava, On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash Or, use the patches from Russ Dill where were more targetted fixes. Either way, I'm OK with that. Keshava, I'll wait for your decision here to know which patch you want me to take. 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. Yes. Please disabled it by default. Until PM in this driver can work without breaking PM for the whole SoC, it should remain disabled. So, I should expect another patch here as well. FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus tomorrow, but I'll wait for you. Hopefully I should be able to send it on Monday. 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: [PATCH 07/29] mfd: omap-usb: use clk_prepare_enable and clk_disable_unprepare
Hi Rajendra, On Mon, Jul 02, 2012 at 04:46:21PM +0530, Rajendra Nayak wrote: Hi Samuel, On Monday 02 July 2012 04:48 PM, Samuel Ortiz wrote: Hi Rajendra, On Thu, Jun 14, 2012 at 06:16:56PM +0530, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Samuel Ortizsa...@linux.intel.com --- drivers/mfd/omap-usb-host.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) Patch applied, many thanks. Sorry, I was asked to base these changes on top of work done by Keshava [1], to split the driver, which is still under review/not pulled. I am waiting for those to settle to repost these changes. Can you please drop this one for now? I just did, although I think Keshava could have based his work on top of yours, as he's rebasing his patchset at the moment. Anyway, patch is removed now. 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: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi Kevin, On Mon, Jul 02, 2012 at 10:55:39AM -0700, Kevin Hilman wrote: I'm also worried that the owners of this code are running out of time to fix these several serious regresions for v3.5. FYI, I only have one omap-usb fix queued for 3.5 in my for-linus branch, see http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=shortlog;h=refs/heads/for-linus 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: [PATCH 07/29] mfd: omap-usb: use clk_prepare_enable and clk_disable_unprepare
Hi Rajendra, On Thu, Jun 14, 2012 at 06:16:56PM +0530, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/omap-usb-host.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) Patch applied, many thanks. 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: [PATCH v3] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset fix issues.
Hi Russ, On Thu, Jun 14, 2012 at 09:24:21AM -0700, Russ Dill wrote: From: Russ Dill russ.d...@gmail.com 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller. However, it also changes behavior in omap-usb-host.c omap_usbhs_init by releasing reset while the configuration in that function was done. This change caused a regression on BB-xM where USB would not function if 'usb start' had been run from u-boot before booting. A change was made to release reset a little bit earlier which fixed the issue on BB-xM and did not cause any regressions on 3430 sdp, the board for which the fix was originally made. This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle before adding hcd.', (3aa2ae74) caused a regression on OMAP5. The original fix to hold the EHCI controller in reset during initialization was correct, however it appears that changing omap_usbhs_init to not hold the PHYs in reset during it's configuration was incorrect. This patch first reverts both fixes, and then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in reset as the original patch had done. It also is sure to incorporate the _cansleep change that has been made in the meantime. I've tested this on Beagleboard xM, I'd really like to get an ack from the 3430 sdp and OMAP5 guys before getting this merged. v3 - Brown paper bag its too early in the morning actually run git commit amend fix v2 - Put cansleep gpiolib call outside of spinlock Signed-off-by: Russ Dill russ.d...@gmail.com --- drivers/mfd/omap-usb-host.c | 48 +- drivers/usb/host/ehci-omap.c | 18 +++- 2 files changed, 55 insertions(+), 11 deletions(-) I applied this one to my for-linus branch, it will be part of my next 3.5 pull request to Linus. 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: [PATCH 0/5 V2 RESEND] ARM: OMAP: TLL driver implementation for USB host driver
Hi Keshava, On Tue, Jun 26, 2012 at 04:56:02PM +0530, Keshava Munegowda wrote: The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. I'm sort of ok with that split although the new driver is definitely not an MFD one, but I guess there's no better place for it. Now, a few comments before applying it: - I'd appreciate to get ACKs from e.g. Tony for the OMAP parts. - Patch #3 doesn't apply on top of my for-next branch. Would you mind rebasing it properly ? - Fix the coypright years to 2012. 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: [PATCHv2 1/4] MFD: palmas PMIC device support
Hi Mark, On Tue, May 15, 2012 at 07:14:51PM +0100, Mark Brown wrote: On Tue, May 15, 2012 at 03:48:56PM +0900, Graeme Gregory wrote: Palmas is a PMIC from Texas Instruments and this is the MFD part of the driver for this chip. The PMIC has SMPS and LDO regulators, a general purpose ADC, GPIO, USB OTG mode detection, watchdog and RTC features. Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com however this depends on some new regmap-irq changes that Graeme posted a couple of days ago and are only on regmap at the minute - Samuel, if you're OK with this I guess the easiest thing is if I apply there? I'm fine with it. For the MFD parts: Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH 2/2] mfd: twl: remove pdata-irq_base/_end, no more users
Hi Kevin, On Tue, May 08, 2012 at 10:19:02AM -0700, Kevin Hilman wrote: After converstion to SPARSE_IRQ, the driver doesn't use the pdata-irq_base/irq_end fields anymore. The last users have been cleanup up, and now these fields can be removed. Cc: Benoit Cousson b-cous...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Kevin Hilman khil...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH 3/3] twl4030: enable wakeup on twl4030 IRQ.
Hi Neil, On Wed, Apr 25, 2012 at 01:05:24PM +1000, NeilBrown wrote: Most of the interrupts that come through this line should trigger wakeups: power button RTC alarm power available usb plug/unplug so mark the interrupt as a wakeup interrupt. This is particularly important for when the interrupt arrives during the late suspend phase. Without this setting it will be ignored. Signed-off-by: NeilBrown ne...@suse.de --- drivers/mfd/twl4030-irq.c |1 + 1 file changed, 1 insertion(+) Patch applied, thanks. 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: [PATCH 4/6] twl4030_charger: Allow charger to control the regulator that feeds it.
Hi Neil, On Wed, Apr 25, 2012 at 05:33:11PM +1000, NeilBrown wrote: The charger needs usb3v1 to be running, so add a new consumer to keep it running. This allows the charger to draw current even when the USB driver has powered down. Signed-off-by: NeilBrown ne...@suse.de --- drivers/mfd/twl-core.c |9 + drivers/power/twl4030_charger.c | 15 +++ 2 files changed, 20 insertions(+), 4 deletions(-) In case Anton has not taken that patchset yet: Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH] MFD: twl6040: Add regulator support for VIO, V2V1 supplies
Hi Peter, On Wed, May 02, 2012 at 04:54:42PM +0300, Peter Ujfalusi wrote: twl6040 has three power supply source: VBAT needs to be connected to VBAT, VIO, and V2V1. Add regulator support for the VIO, V2V1 supplies. Initially handle the two supply together with bulk commands. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com --- drivers/mfd/twl6040-core.c | 33 + include/linux/mfd/twl6040.h |2 ++ 2 files changed, 31 insertions(+), 4 deletions(-) Hi Samuel, The runtime dependencies for this patch has been sent to linux-omap list: http://marc.info/?l=linux-omapm=133596645010228w=2 http://marc.info/?l=linux-omapm=133596645610232w=2 http://marc.info/?l=linux-omapm=133596644310224w=2 http://marc.info/?l=linux-omapm=133596643310220w=2 Alone this patch does not cause compile time regression but in runtime it needs the arch/arm/mach-omap2 patches. I try to avoid cross tree issues as much as I can and I'm happy if these will come together in linux-next (and finally in 3.5). I applied this one to my nfc-next branch, thanks. 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: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
Hi Igor, On Sun, May 06, 2012 at 09:25:05AM +0300, Igor Grinberg wrote: Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) Sorry about that. and I'd like this to go into 3.5. Then you may need a better changelog explaining how this fixes a regression, runtime crash or build failure. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? At that point, it definitely makes more sense for Alan to push it. 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: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
Hi Igor, On Mon, May 07, 2012 at 02:46:35PM +0300, Igor Grinberg wrote: Hi Samuel, On 05/07/12 11:09, Samuel Ortiz wrote: Hi Igor, On Sun, May 06, 2012 at 09:25:05AM +0300, Igor Grinberg wrote: Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) Sorry about that. and I'd like this to go into 3.5. Then you may need a better changelog explaining how this fixes a regression, runtime crash or build failure. Well, I did not say it is a regression. In fact it is not. I just finally sent a fix to eliminate a runtime warning which was there for a long time and can be seen on specific configurations. That is why, I want it into 3.5 during the merge window Sorry, I misread that part. Getting that one for the next merge window is just fine. 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: [PATCH] Fix build breakage in omap-usb-host.c
Hi Russ, On Sun, Apr 22, 2012 at 01:48:18AM -0700, Russ Dill wrote: 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' removes the include for linux/gpio.h from omap-usb-host.c. This include indirectly includes plat/cpu.h which is required by omap-usb-host.c. Fix the build breakage by including it directly. Signed-off-by: Russ Dill russ.d...@ti.com Patch applied, thanks. I'm planning to send an MFD pull request including this fix to Linus, in time for rc6. 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: [PATCH] Fix build breakage in omap-usb-host.c
Hi Kevin, On Fri, Apr 27, 2012 at 01:36:28PM -0700, Kevin Hilman wrote: Samuel, Munegowda, Keshava keshava_mgo...@ti.com writes: On Sun, Apr 22, 2012 at 2:20 PM, Russ Dill russ.d...@ti.com wrote: On Sun, Apr 22, 2012 at 1:48 AM, Russ Dill russ.d...@ti.com wrote: 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' removes the include for linux/gpio.h from omap-usb-host.c. This include indirectly includes plat/cpu.h which is required by omap-usb-host.c. Fix the build breakage by including it directly. (Sorry, I should add some detail, this is a build breakage in linux-next) Russ Dill and Anatolij Gustschin Both patches fixes the same issue; But here , I am seeing Russ Dill has sent earlier (in my mailbox it shows 21 hours ago) Here my ack by: Acked-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Kevin Hilman khil...@ti.com Can you pick this up for v3.4-rc5? The breakage was introduced in v3.4-rc4. I will, 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: [PATCH for 3.4] MFD: twl6040: Convert to i2c driver, and separate it from twl core
Hi Peter, On Tue, Apr 03, 2012 at 11:56:51AM +0300, Peter Ujfalusi wrote: Complete the separation of the twl6040 from the twl core since it is a separate chip, not part of the twl6030 PMIC. Make the needed Kconfig changes for the depending drivers at the same time to avoid breaking the kernel build (vibra, ASoC components). Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Reviewed-by: Mark Brown broo...@opensource.wolfsonicro.com Acked-by: Tony Lindgren t...@atomide.com Acked-by: Samuel Ortiz sa...@linux.intel.com Acked-by: Dmitry Torokhov d...@mail.ru --- Hi Samuel, Tony, Liam, Due to some cross tree issues 3.4-rc1 have big regression in OMAP4 audio: The twl6040 mfd driver (and codec, vibra) is no longer probe since the twl-core now did not create the platform device for it. This means we do not have audio working in rc1. This patch meant to follow the twl-core change (to not probe the twll6040 as platform device), but there were some glitch in the logistics so this patch is not in 3.4-rc1. I have forward ported it on top of 3.4-rc1, and you can also find the patch in: g...@gitorious.org:omap-audio/linux-audio.git peter/upstream/for-3.4-rc2 Can someone take this patch further to be included in 3.4-rc2? Applied to my for-linus branch. I'll send a pull request this week, so I expect it to make it to rc4. 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: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Keshava, On Wed, Apr 11, 2012 at 05:15:03PM +0530, Munegowda, Keshava wrote: On Tue, Mar 27, 2012 at 8:40 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 03/19/12 08:42, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Both EHCI ports worked on cm-t3730 previously and no regression is seen with this patch. Tested-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. Hi sameo Since I am not seeing this patch in linux-next labled 3.4.rc2 on 10th april 2012; please let me know your plan to queue this patch for the main line. I applied this one to my for-linus branch, thanks. 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: [PATCH for 3.4] MFD: twl6040: Convert to i2c driver, and separate it from twl core
Hi Peter, On Thu, Apr 12, 2012 at 09:39:28AM +0300, Peter Ujfalusi wrote: Hi Samuel, Liam, Tony, Now rc2 is out, and the the OMAP4 audio is still broken. Can you please queue this patch for 3.4? I'm busy this week, but I'll queue this one up beginning of next week. I have several MFD fixes pending, so I'll send a pull request before rc4 I hope. 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: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Igor, On Tue, Mar 27, 2012 at 04:18:49PM +0200, Igor Grinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Felipe, Samuel, On 03/20/12 17:55, Felipe Balbi wrote: On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. I've just sent a patch that depends on this one (ehci-omap.c part), though it needs a review, but Samuel, you still haven't applied/pushed the patch to your git.kernel.org, so can this one go through Felipe's tree to minimize the dependencies/conflicts? Once (and if) Linus pulls from my for-next branch, I'll start taking patches again. It's a matter of days, so you can either wait for me to apply this patch or have Felipe taking both. I'm fine either ways. 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: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. 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: [PATCH] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Keshava, On Thu, Mar 08, 2012 at 08:30:21PM +0530, Munegowda, Keshava wrote: On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Feb 24, 2012 at 03:36:15PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com won't this cause issues with EHCI/OHCI interactions ? I mean, what if you connect a FS/LS device and port is handed over to OHCI, does OHCI have any needs to reset the PHY or something similar ? No, it will not cause any issues with EHCI-OHCI issues. But its difficult to comment on this because we don't have port handoff supported in hardware. regards keshava Hi Samuel please let me know if you have any comments on this patch. This is required patch for omap3 ehci enumeration instabilities. Regards Keshava Hi Samuel do you have any comments on this patch? I actually never received the actual patch, I think. Felipe has reviewed this patch and he is agreed for this patch. there are no comments from your side, requesting to push this change to mainline. I looked at it on gmame, and it seems fine to me. If you want me to push this patch, then please (re-)send it to me, even privately. 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: [PATCH 0/5] ARM: OMAP: TLL driver implementation for USB host driver
Hi Keshava, On Mon, Mar 05, 2012 at 08:13:45PM +0530, Munegowda, Keshava wrote: On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Keshava Munegowda (5): ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Build the USB HOST TLL omap device ARM: OMAP: USB: Remove TLL specific code ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: change the USB TLL clocks device name arch/arm/mach-omap2/clock3xxx_data.c | 8 +- arch/arm/mach-omap2/clock44xx_data.c | 4 +- arch/arm/mach-omap2/usb-host.c | 28 ++- arch/arm/plat-omap/include/plat/usb.h | 9 + drivers/mfd/Kconfig | 2 +- drivers/mfd/Makefile | 2 +- drivers/mfd/omap-usb-host.c | 232 + drivers/mfd/omap-usb-tll.c | 463 + 8 files changed, 513 insertions(+), 235 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c Hi Samuel just to get your attention; I have added your mail id in the to list. please let me know your comments on this patch series; Here as well, I don't think I was cc'ed on the original submission. Without getting the actual patch, I'll have hard time reviewing it. 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: Lost fixes?
On Thu, Mar 15, 2012 at 10:28:45AM +, Russell King - ARM Linux wrote: These fixes are a collection from other people which resolve various issues found with the new kautobuilder. They're now a month old, and as far as I can see, have not been merged into Linus' tree. What's the status of them, and when are they going to be merged? For the drivers/mfd/da9052-spi.c part: A patch from Axel Lin has been living in my for-next branch for a while now. It's a section mismatch warning fix, so not something I consider worth sending to Linus after the merge window is closed. So it's queued for the next one. 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: [PATCH 0/5] MFD: Reverting twl6040 patches going for 3.4
Hi Peter, On Tue, Mar 06, 2012 at 02:35:11PM +0200, Peter Ujfalusi wrote: Hello Samuel, this series reverts the twl6040 related patches aimed for 3.4 merge window from MFD for-next branch. As we already discussed the relevant patches will be going through audio since we have some dependencies going via that route. I removed all 5 patches from my for-next branch. 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: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
Hi Tony, On Thu, Mar 01, 2012 at 10:55:35AM -0800, Tony Lindgren wrote: There's no need to use callbacks for this, we can do it directly between MMC driver and twl6030. Cc: Samuel Ortiz sa...@linux.intel.com Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH 1/4] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
Hi, On Tue, Feb 28, 2012 at 03:09:10PM +0530, Rajendra Nayak wrote: From: Tero Kristo t-kri...@ti.com vdd1 and vdd2 are now common regulators for twl4030 and twl6030. Also added vdd3 as a new regulator for twl6030. twl6030 vdd1...vdd3 smps regulator voltages can only be controlled through the smartreflex voltage channel, thus the support for the voltage_get and set is minimal and requires external controller. Signed-off-by: Tero Kristo t-kri...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Liam Girdwood l...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Acked-by: Samuel Ortiz sa...@linux.intel.com Mark, Liam, are you guys taking this one ? 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: [PATCH] MFD: TWL 6030: clear IRQ status register only once
Hi Nishan, On Wed, Feb 22, 2012 at 08:03:45PM -0600, Nishanth Menon wrote: TWL6030 family of PMIC use a shadow interrupt status register while kernel processes the current interrupt event. However, any write(0 or 1) to register INT_STS_A, INT_STS_B or INT_STS_C clears all 3 interrupt status registers. Since clear of the interrupt is done on 32k clk, depending on I2C bus speed, we could in-adverently clear the status of a interrupt status pending on shadow register in the current implementation. This is due to the fact that multi-byte i2c write operation into three seperate status register could result in multiple load and clear of status and result in lost interrupts. Instead, doing a single byte write to INT_STS_A register with 0x0 will clear all three interrupt status registers without the related risk. Applied, thanks. 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: [PATCH] MFD: TWL 6030: make twl6030_irq_set_wake static
Hi Nishan, On Wed, Feb 22, 2012 at 08:03:59PM -0600, Nishanth Menon wrote: twl6030_irq_set_wake is not used anywhere else in the kernel except as irq_chip.irq_set_wake. No reason for it to be exported. Also fixes build warning: drivers/mfd/twl6030-irq.c:230:5: warning: symbol 'twl6030_irq_set_wake' was not declared. Should it be static? Applied as well, thanks. 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: [PATCH 3/7] MFD: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS
Hi Peter, On Fri, Feb 10, 2012 at 12:05:12PM +0200, Peter Ujfalusi wrote: To be able to attach consumers to these supplies from board files we need to have regulator_init_data for them. If I understand correctly, this should also go through Liam's tree. If that's so, please add my: Acked-by: Samuel Ortiz sa...@linux.intel.com 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: [PATCH 0/2] mfd: omap-usb-host: Minor omap-usb host fixes
Hi Govindraj, On Wed, Feb 15, 2012 at 03:53:32PM +0530, Govindraj.R wrote: From: Govindraj.R govindraj.r...@ti.com Minor fixes, boot tested on panda with ehci enabled. Patches based on 3.3-rc3 Govindraj.R (2): mfd: omap-usb-host: Remove magic numbers for dev dma mask mfd: omap-usb-host: Move usbhs init before allocing child dev Both patches applied (v2 for the first one). 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: [PATCH v3 0/3] MFD: twl6040: Conversion to i2c driver
Hi Peter, On Tue, Feb 21, 2012 at 12:33:07PM +0200, Peter Ujfalusi wrote: I'm not sure hwo we could handle that properly. Either by letting Tony carrying this patchset, or by sending me the panda patch that adds those structures. As you prefer. If Liam would take this series that would be probably the way forward. If he does not have objections. Liam: I can create a branch for you to pull from as soon as all other patch receives the needed acks... Samuel: if Liam agrees is it possible for you to drop the twl6040 related patches from your for-next branch? That would make sense to me, yes. Liam, if you're ok with taking it, please add my: Acked-by: Samuel Ortiz sa...@linux.intel.com to this 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: [PATCH V4 1/2] MFD: TPS65217: Add new mfd device for TPS65217
Hi Anilkumar, On Wed, Jan 11, 2012 at 04:11:41PM +0530, AnilKumar Ch wrote: The TPS65217 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators - White LED - USB battery charger This patch adds support for tps65217 mfd device. At this time only the regulator functionality is made available. Patch applied, thanks. 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: [PATCH] mfd: twl4030: trivial code-style fixes
Hi Felipe, On Wed, Feb 01, 2012 at 03:02:48AM +0200, Felipe Contreras wrote: Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Applied, thanks. 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: [PATCH v3 0/3] MFD: twl6040: Conversion to i2c driver
Hi Peter,
On Fri, Feb 10, 2012 at 12:00:15PM +0200, Peter Ujfalusi wrote:
Hello,
Changes since v2:
- soc/codec/Kconfig: make twl6040 depend on I2C
- Regulator related patches has been removed (to be sent as separate series)
I applied all 3 patches. Patch #2 did not apply cleanly, due to the fact that
several struct twl4030_codec_data omap4panda.c references are not upstream
yet. This is my .rej:
--- arch/arm/mach-omap2/board-omap4panda.c
+++ arch/arm/mach-omap2/board-omap4panda.c
@@ -278,7 +279,7 @@
return 0;
}
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
@@ -286,17 +287,14 @@
.hf_right_step = 0x1d,
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
/* Panda board uses the common PMIC configuration */
-static struct twl4030_platform_data omap4_panda_twldata = {
- .audio = twl6040_audio,
-};
+static struct twl4030_platform_data omap4_panda_twldata;
I'm not sure hwo we could handle that properly. Either by letting Tony
carrying this patchset, or by sending me the panda patch that adds those
structures. As you prefer.
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: [PATCH v2 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies
Hi Peter, On Tue, Feb 07, 2012 at 03:01:18PM +0200, Peter Ujfalusi wrote: twl6040 has three power supply source: VBAT needs to be connected to VBAT, VIO, and V2V1. Add regulator support for the VIO, V2V1 supplies. Initially handle the two supply together with bulk commands. I applied this one. 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: [PATCH v4 03/12] mfd: twl-core: Add initial DT support for twl4030/twl6030
Hi Benoit, On Tue, Jan 03, 2012 at 03:09:49PM +0100, Cousson, Benoit wrote: On 1/2/2012 10:04 AM, Grant Likely wrote: On Thu, Dec 22, 2011 at 03:56:37PM +0100, Benoit Cousson wrote: Add initial device-tree support for twl familly chips. The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly. Add irqdomain support. Add documentation for the Texas Instruments TWL Integrated Chip. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Balaji T Kbalaj...@ti.com Cc: Graeme Gregoryg...@slimlogic.co.uk Cc: Samuel Ortizsa...@linux.intel.com --- diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index f1391c2..f0de088 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -200,6 +200,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS + select IRQ_DOMAIN As discussed on linux-next, this breaks powerpc. Drivers cannot select IRQ_DOMAIN, it can only be selected by architectures. Drivers must depend on it instead. OK, good to know. The previous version was already breaking non-ARM platform because the IRQ_DOMAIN was not defined, hence this update. I was able to check that this patch was fixing at least x86... but did not have any way to check the PPC build. To be honest, I did not fully understand that this flag was there because some arch does not support IRQ domain yet and thus it should be selected at arch level. Samuel, Here is the updated version, and hopefully the last one, including Grant's fix. Thanks, I applied it now. 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: [PATCH v4 03/12] mfd: twl-core: Add initial DT support for twl4030/twl6030
Hi Benoit, On Thu, Dec 22, 2011 at 03:56:37PM +0100, Benoit Cousson wrote: Add initial device-tree support for twl familly chips. The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly. Add irqdomain support. Add documentation for the Texas Instruments TWL Integrated Chip. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Graeme Gregory g...@slimlogic.co.uk Cc: Samuel Ortiz sa...@linux.intel.com --- .../devicetree/bindings/mfd/twl-familly.txt| 47 ++ drivers/mfd/Kconfig|1 + drivers/mfd/twl-core.c | 51 +++- 3 files changed, 98 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt Patch applied instead of the previous one, thanks for the quick fix. 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: [PATCHv8 4/5] twl4030: add support for external voltage get/set
Hi Tero, On Fri, Dec 09, 2011 at 05:29:48PM +0200, Tero Kristo wrote: This is needed for SMPS regulators, which use the OMAP voltage processor for voltage get/set functions instead of the normal I2C channel. For this purpose, regulator_init_data-driver_data contents are expanded, it is now a struct which contains function pointers for the set/get voltage operations, a data pointer for these, and the previously used features bitmask. Looks better than the previous versions. For the MFD part: Acked-by: Samuel Ortiz sa...@linux.intel.com Liam, I assume this is going through your tree ? 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: [PATCH v2 03/10] mfd: twl-core: Add initial DT support for twl4030/twl6030
Hi Benoit, On Fri, Dec 09, 2011 at 03:02:34PM +0100, Benoit Cousson wrote: Add initial device-tree support for twl familly chips. The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly. Add documentation for the Texas Instruments TWL Integrated Chip. Thanks, patch applied. 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: [PATCH 0/4] fixes for twl4030-irq in mainline
Hi Neil, On Tue, Dec 13, 2011 at 08:39:59AM +1100, NeilBrown wrote: The following 4 patches make it work for me and addresses some other less critical issues like a typo in a comment :-) Thanks, I applied all 4 of them. Thanks. I have a couple of other twl4030 patches, these ones related to battery charging. Hopefully I'll be ready to post them later this week. Would they go through you too? They most likely would, 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: [PATCH 0/4] fixes for twl4030-irq in mainline
Hi Felipe, On Tue, Dec 13, 2011 at 04:12:02PM +0200, Felipe Contreras wrote: Hi, On Mon, Dec 12, 2011 at 7:38 PM, Samuel Ortiz sa...@linux.intel.com wrote: On Sun, Nov 27, 2011 at 07:17:41AM +1100, NeilBrown wrote: The recent tidying up of twl4030-irq seems to have left it broken. At least it doesn't work for me on my gta04 (www.gta04.org). The first interrupt from the device freezes the whole system (by being constantly delivered) The following 4 patches make it work for me and addresses some other less critical issues like a typo in a comment :-) Thanks, I applied all 4 of them. Did you apply them for 3.2 or 3.3? Without the first patch any system that has a twl4030 chip will immediately hang on the first interrupt, and many functions of twl4030 will just not work without the second one. Thanks for the heads up. I applied the first 2 patches to my for-linus branch. 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: [PATCH RESEND v2 0/2] PMIC TPS65910 fixes
Hi Mohamed, On Tue, Nov 08, 2011 at 06:53:35PM +0530, Afzal Mohammed wrote: Hi, This series applies over Kyle Manna's v3 patch series, https://lkml.org/lkml/2011/11/3/257, with changes as per comments on his/her 1/6 mfd: TPS65910: Handle non-existent devices Kyle has not updated the patchset, afaik. So your patches don't apply on top of my for-next branch. Please rebase them. 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: [PATCH 0/4] fixes for twl4030-irq in mainline
Hi Neil, On Sun, Nov 27, 2011 at 07:17:41AM +1100, NeilBrown wrote: Hi, The recent tidying up of twl4030-irq seems to have left it broken. At least it doesn't work for me on my gta04 (www.gta04.org). The first interrupt from the device freezes the whole system (by being constantly delivered) The following 4 patches make it work for me and addresses some other less critical issues like a typo in a comment :-) Thanks, I applied all 4 of them. 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: [PATCHv7 5/7] mfd: twl-core: pass driver data from pdata to add_regulator for VDD1 and VDD2
Hi Tero, On Mon, Nov 28, 2011 at 04:53:23PM +0200, Tero Kristo wrote: This way, we can add custom flags for VDD1 and VDD2 regulators that get passed all the way to regulator init. This is needed for SMPS regulator support to select used controller mode for these regulators (either voltage processor or default.) Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/twl-core.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c index 01ecfee..af93fce 100644 --- a/drivers/mfd/twl-core.c +++ b/drivers/mfd/twl-core.c @@ -846,12 +846,14 @@ add_children(struct twl4030_platform_data *pdata, unsigned long features) return PTR_ERR(child); child = add_regulator(TWL4030_REG_VDD1, pdata-vdd1, - features); + features | + (u32)pdata-vdd1-driver_data); That looks hackish to me. Do you have any guarantee that your driver_data and your features bitmaps have zero intersections ? 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: [PATCH 1/2] mfd: twl6030: fix lockdep recursion warning on setting wake IRQs
Hi Todd, On Mon, Sep 26, 2011 at 04:44:23PM -0700, Todd Poynor wrote: LOCKDEP explicitly sets all irq_desc locks as a single lock-class, causing possible recursive locking detected when the TWL RTC driver calls through enable_irq_wake to twl6030_irq_set_wake, which recursively calls irq_set_irq_wake. Although the irq_desc and lock are different, LOCKDEP treats these as equivalent, presumably due to problems that can be incurred when locking more than one irq_desc, so best to avoid this. Suspend/resume actions implemented as PM notifiers to avoid touch the TWL core for this. Thanks for that, I applied this patch. 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
