Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
Hi Heiko, On Thu, Dec 09, 2010 at 07:49:45AM +0100, Heiko Schocher wrote: Hello Paul, Paul Mundt wrote: On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote: - add binding to OF, compatible name smi,sm501 [...] Documentation/kernel-parameters.txt |7 + Documentation/powerpc/dts-bindings/sm501.txt | 30 +++ drivers/mfd/sm501.c | 141 -- drivers/video/sm501fb.c | 264 +- include/linux/sm501.h|8 + 5 files changed, 299 insertions(+), 151 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt Given that this is all SM501 dependent, is there some particular reason why you neglected to Cc the author or the MFD folks? Hups, sorry! No, there is no reason, thanks for detecting this. Hmm.. couldn;t find a MFD maillinglist? We use lkml. Could you please re-send the patch to me ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
Hi Heiko, On Mon, Jan 24, 2011 at 10:57:38AM +0100, Heiko Schocher wrote: - add binding to OF, compatible name smi,sm501 The MFD part looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4 v4] video, sm501: add I/O functions for use on powerpc
Hi Heiko, On Mon, Jan 24, 2011 at 10:57:20AM +0100, Heiko Schocher wrote: - add read/write functions for using this driver also on powerpc plattforms Not sure whose tree this is going through. Probably Paul's one though. The mfd part looks fine to me, please add my: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mfd: Add basic device tree binding for wm8994
Hi Mark, On Tue, Nov 22, 2011 at 06:59:28PM +, Mark Brown wrote: Add a placeholder device tree binding for the wm8994 driver. At present the binding is essentially null as none of the platform data is supported, and at least some of that will depend on the pending regulator bindings. I applied this one to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] mfd: mc13xxx: add device tree probe support
Hi Shawn, On Tue, Dec 06, 2011 at 11:04:43PM +0800, Shawn Guo wrote: It adds device tree probe support for mc13xxx mfd driver. Thanks, I applied this one. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/4] regulator: mc13892: add device tree probe support
On Thu, Dec 01, 2011 at 05:21:07PM +0800, Shawn Guo wrote: It adds device tree probe support for mc13892-regulator driver. Signed-off-by: Shawn Guo shawn@linaro.org Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Liam Girdwood l...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] mfd: improve mc13xxx dt binding document
Hi Shawn, On Wed, Dec 21, 2011 at 11:00:44PM +0800, Shawn Guo wrote: It improves mc13xxx dt binding document on how the regulator name is being used for binding a mc13892 regulator device. Signed-off-by: Shawn Guo shawn@linaro.org Cc: Samuel Ortiz sa...@linux.intel.com Thanks, patch applied. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] devicetree: Add empty of_platform_populate() for !CONFIG_OF_ADDRESS (sparc)
Hi Grant, On Fri, Feb 24, 2012 at 03:06:58PM -0700, Grant Likely wrote: Sparc has its own helpers for translating address ranges when the device tree is parsed at boot time, and it isn't able to use of_platform_populate(). However, there are some device drivers that want to use that function on other DT enabled platforms (ie. TWL4030). This patch adds an empty of_platform_populate() implementation that returns an error when CONFIG_OF_ADDRESS is not selected. Applied as well. Please let me know if you'd prefer to see this one going through your irqdomain/next branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/2] mfd: add irq domain support for max8997 interrupts
Hi Mark, On Wed, Apr 04, 2012 at 10:22:57PM +0100, Mark Brown wrote: On Sat, Mar 24, 2012 at 03:19:49PM +0530, Thomas Abraham wrote: Add irq domain support for max8997 interrupts. The reverse mapping method used is linear mapping since the sub-drivers of max8997 such as regulator and charger drivers can use the max8997 irq_domain to get the linux irq number for max8997 interrupts. All uses of irq_base in platform data and max8997 driver private data are removed. Cc: MyungJoo Ham myungjoo@samsung.com Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Grant Likely grant.lik...@secretlab.ca CCing in Samuel for the MFD review - review tends to be faster if you CC maintainers! Samuel, there's a followup patch for the regulator API which is likely to collide with some API updates so is it OK to merge via regulator if the patch is OK? Yes, the patch looks fine, you can merge it through the regulator tree with my Acked-by: Samuel Ortiz sa...@linux.intel.com if you think that's necessary. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/6 v3] Update TPS65910 to boot using devicetree
Hi Rhyland, On Tue, May 08, 2012 at 11:42:37AM -0700, Rhyland Klein wrote: This patch set updates the tps65910 driver to boot using devicetree. This patch set now uses the new addition to the of_regulator code, of_regulator_match to find all the regulator init data for the device. Rhyland Klein (6): mfd: tps65910: Commonize regmap access through header regulator: tps65910: Add device tree bindings mfd: tps65910: Add device-tree support regulator: tps65910 regulator: add device tree support mfd: tps65910-irq: Add devicetree init support ARM: Tegra: Add support for TPS65910 PMIC I applied patches 1,2 and 3 to my for-next branch. Patch 4 is a regulator one, I assume Mark is going to take it. And patch 5 needs some additional work. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/4] MFD: twl6040: Device tree support
Hi Peter, On Wed, May 16, 2012 at 02:11:54PM +0300, Peter Ujfalusi wrote: Hello, Changes since v2: - Child devices are no longer described in dts, they are created with mfd_add_devices() - ASoC codec device is created unconditionally (main function of twl6040) Changes since v1: - Commit message for patch 2 (Allocate IRQ numbers dynamically) has been updated to describe that the twl6040 can not be used as IRQ extender type of device. Commit message from v1: The following series adds device tree support for the twl6040 MFD core driver. Support for the child drivers (vibra, ASoC codec) will be submitted via the corresponding subsystem since there is no compile time dependency between them. The first patch is a minor clean up patch to remove wrapped lines in the twl6040-irq.c. The resulting code is more natural to read to me. The series depends on the regulator support patch for the twl6040: http://marc.info/?l=linux-kernelm=133596703610515w=2 All 4 patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] mfd: tps65910: add support for enabling external 32-kHz oscillator
Hi Johan, On Thu, Jun 28, 2012 at 12:20:20PM +0200, Johan Hovold wrote: These patches (against v3.5-rc4) add support for enabling the external 32-kHz oscillator input in tps6591x devices. Depending on boot-mode, the internal RC-oscillator may be used by default and the external crystal-oscillator input must be enabled by clearing a flag in the device-control register. These patches are needed in order to get an accurate system clock on boards such as the Craneboard. Thanks, Johan Johan Hovold (2): mfd: tps65910: add support for enabling external 32-kHz oscillator mfd: tps65910: add device-tree entry to enable external 32-kHz oscillator Both patches applied, although the misc_init() naming is quite vague. If you can come up with a follow up patch for a better name, I'll take it. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mfd: add tps65910 32-kHz-crystal-input init
Hi Johan, On Wed, Jul 11, 2012 at 03:44:33PM +0200, Johan Hovold wrote: Replace tps65910_misc_init with a dedicated init function for the 32-kHz-crystal input. Signed-off-by: Johan Hovold jhov...@gmail.com --- Hi Samuel, How about something like this? My thought with misc_init was that it could be extended should more simple initialisation like for the ck32k_xtal need to be done, but perhaps it's cleaner to stick with dedicated init functions through-out. At least for now. Yes, it's clearer, at least to me. I applied this patch, thanks for following up. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/2] mfd: dt: add power off support for Tegra20/Tegra30
Hi Bill, On Sun, Aug 19, 2012 at 06:07:54PM -0700, Bill Huang wrote: This patch series add new property into regulator DT for telling whether or not to hook pmic's power off routine to system call pm_power_off. Patch 1 add power off support for Tegra20 boards using TPS6586x Patch 2 add power off support for Tegra30 boards using TPS65910 Verified on Seaboard (Tegra20) and Cardhu (Tegra30) V2: * Take multiple pmic instances into consideration while assigning global variables as per suggestion from Thierry Reding thierry.red...@avionic-design.de V1: * Based on master branch of sameo/mfd-2.6.git Bill Huang (2): mfd: dt: tps6586x: Add power off control mfd: dt: tps65910: add power off control Documentation/devicetree/bindings/mfd/tps65910.txt |4 +++ .../devicetree/bindings/regulator/tps6586x.txt |6 + drivers/mfd/tps6586x.c | 19 + drivers/mfd/tps65910.c | 22 include/linux/mfd/tps6586x.h |1 + include/linux/mfd/tps65910.h |3 ++ 6 files changed, 55 insertions(+), 0 deletions(-) I applied those 2 patches to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/2] mfd: dt: add power off support for Tegra20/Tegra30
Hi Stephen, On Tue, Sep 11, 2012 at 09:15:07AM -0600, Stephen Warren wrote: On 09/11/2012 04:46 AM, Thierry Reding wrote: On Tue, Sep 11, 2012 at 06:25:14PM +0800, Bill Huang wrote: Hi all, Could somebody review this? Given that I haven't been able to test yet (due to time constraints) with PM_SLEEP_SMP enabled, I don't want to give you a Tested-by, but the code looks okay to me, so for both patches: Reviewed-by: Thierry Reding thierry.red...@avionic-design.de I have tested this with PM_SLEEP_SMP enabled, and it solved the problem. I think I already gave my Tested-by, but if not: Tested-by: Stephen Warren swar...@wwwdotorg.org I hope that this gets applied to the MFD tree early enough (i.e. within the next 2-3 days or so) that I can rely on the binding be accepted, and hence apply patches to Tegra's device tree to enable this functionality for 3.7. Bill, given this was posted about 3 weeks ago, perhaps repost the series in case Samuel doesn't have it any more, and hence can't apply it. No need for that. Sorry for the delay, I just applied and pushed those 2 patches. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/2] mfd: dt: add power off support for Tegra20/Tegra30
On Tue, Sep 11, 2012 at 10:26:55AM -0600, Stephen Warren wrote: On 09/11/2012 10:08 AM, Samuel Ortiz wrote: Hi Stephen, On Tue, Sep 11, 2012 at 09:15:07AM -0600, Stephen Warren wrote: On 09/11/2012 04:46 AM, Thierry Reding wrote: On Tue, Sep 11, 2012 at 06:25:14PM +0800, Bill Huang wrote: Hi all, Could somebody review this? Given that I haven't been able to test yet (due to time constraints) with PM_SLEEP_SMP enabled, I don't want to give you a Tested-by, but the code looks okay to me, so for both patches: Reviewed-by: Thierry Reding thierry.red...@avionic-design.de I have tested this with PM_SLEEP_SMP enabled, and it solved the problem. I think I already gave my Tested-by, but if not: Tested-by: Stephen Warren swar...@wwwdotorg.org I hope that this gets applied to the MFD tree early enough (i.e. within the next 2-3 days or so) that I can rely on the binding be accepted, and hence apply patches to Tegra's device tree to enable this functionality for 3.7. Bill, given this was posted about 3 weeks ago, perhaps repost the series in case Samuel doesn't have it any more, and hence can't apply it. No need for that. Sorry for the delay, I just applied and pushed those 2 patches. Great! Thanks. Do you have [PATCH V4 REPOST] mfd: add MAX8907 core driver on your list too? Yes, I'll be chewing my MFD pending patches list in the next days, and this one is on the list. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 REPOST] mfd: add MAX8907 core driver
Hi Stephen, On Wed, Sep 12, 2012 at 10:29:04AM -0600, Stephen Warren wrote: On 09/06/2012 05:10 PM, Stephen Warren wrote: From: Gyungoh Yoo jack@maxim-ic.com The MAX8907 is an I2C-based power-management IC containing voltage regulators, a reset controller, a real-time clock, and a touch-screen controller. Samuel, This patch as-is won't compile due to the mfd_add_devices() API change. Do you want to fix this up when you apply (simply add an extra parameter NULL to the mfd_add_devices() call), or should I send an updated V5 for this? I'll fix it up, don't bother sending a v5. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/4] add syscon driver based on regmap for general registers access
Hi Dong, On Mon, Sep 17, 2012 at 06:10:29PM +0800, Dong Aisheng wrote: Hi Samuel, On Wed, Sep 05, 2012 at 01:54:12PM +0800, Shawn Guo wrote: Hi Samuel, The series needs to go via mfd or arm-soc tree as a whole. In case you want to take it through mfd tree, here is my ack. Acked-by: Shawn Guo shawn@linaro.org Otherwise, I can take it via arm-soc tree with your ack. Ping... All 4 patches applied to my for-next branch. Sorry for the delay. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH REPOST] mfd: max8907: add power off control
Hi Stephen, On Tue, Sep 18, 2012 at 04:51:19PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Add DT property maxim,system-power-controller to indicate whether the PMIC is in charge of controlling the system power. If this is set, the driver will provide the pm_power_off() function. Signed-off-by: Stephen Warren swar...@nvidia.com --- Samuel, I'm not sure if you have this in your list to process or not, nor if you prefer a patch to be reposted vs. a response to the original email; Mark Brown requested that for him at least I repost rather than reply, so I'm giving that a go everywhere. Thanks for reposting. Patch is applied to my for-next branch now. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] mfd: max8907: remove regulator-compatible from DT docs
Hi Stephen, On Mon, Sep 24, 2012 at 01:25:03PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Commit regulator: deprecate regulator-compatible DT property deprecated the use of the regulator-compatible DT property. Update the DT example in the MAX8907 binding documentation to reflect this. Signed-off-by: Stephen Warren swar...@nvidia.com --- This commit is based on the MFD branch. --- .../devicetree/bindings/regulator/max8907.txt | 24 ++- 1 files changed, 8 insertions(+), 16 deletions(-) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] mfd: stmpe: Use devm_*() routines
Hi Viresh, On Fri, Nov 09, 2012 at 09:01:54PM +0530, Viresh Kumar wrote: This patch frees stmpe driver from tension of freeing resources :) devm_* derivatives of multiple routines are used while allocating resources, which would be freed automatically by kernel. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/mfd/stmpe.c | 46 +++--- 1 file changed, 15 insertions(+), 31 deletions(-) This one does not apply on top of my for-next branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] mfd: stmpe: Add DT support in stmpe driver
Hi Viresh, On Fri, Nov 09, 2012 at 09:01:55PM +0530, Viresh Kumar wrote: From: Vipul Kumar Samar vipulkumar.sa...@st.com This patch adds support to probe stmpe devices via DT. Bindings are mentioned in binding document. Signed-off-by: Vipul Kumar Samar vipulkumar.sa...@st.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- Documentation/devicetree/bindings/mfd/stmpe.txt | 121 +++ drivers/mfd/stmpe-i2c.c | 23 ++- drivers/mfd/stmpe-spi.c | 15 ++ drivers/mfd/stmpe.c | 264 +++- 4 files changed, 418 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/stmpe.txt Lee Jones (cc'ed) submitted a patch for the same purpose, see commit 909582ca from my for-next branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RESEND 0/7] MFD: ti_am335x_tscadc: DT support and TSC features addition
Hi Rachna, On Fri, Nov 16, 2012 at 10:33:00AM +, Patil, Rachna wrote: Hi, This is just a gentle reminder of the patch set I had posted earlier viz. [PATCH RESEND 0/7] MFD: ti_am335x_tscadc: DT support and TSC features addition Can this patch set be pulled in if there are no review comments. This patch set does not break anything existing, it just adds new features and DT support for the MFD core and its clients. I'm fine with the MFD part, but did you get Dmitry's ACK on the input ones ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/2] mfd: stmpe: Use devm_*() routines
Hi Viresh, On Thu, Nov 22, 2012 at 10:40:29AM +0530, Viresh Kumar wrote: This patch frees stmpe driver from tension of freeing resources :) devm_* derivatives of multiple routines are used while allocating resources, which would be freed automatically by kernel. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org Applied, with Lee's Ack. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] Documentation: Fix historical inconsistency in STMPE DT doc
Hi Lee, On Thu, Nov 22, 2012 at 12:24:24PM +, Lee Jones wrote: Previously a generic binding 'i2c-client-wake' was created which enabled I2C devices to register themselves as wake-up devices. This binding was later over-thrown by 'wakeup-source'. The STMPE driver was fixed-up, but the document was neglected. This patch aims to rectify that. Cc: Samuel Ortiz sa...@linux.intel.com Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Lee Jones lee.jo...@linaro.org --- Documentation/devicetree/bindings/mfd/stmpe.txt |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V1 2/3] mfd: stmpe-i2c: Move .driver structure fields inside {} in stmpe_i2c_driver
Hi Viresh,
On Fri, Nov 23, 2012 at 12:26:19AM +0530, Viresh Kumar wrote:
Currently, few fields in stmpe_i2c_driver are initialized as:
.driver.owner = THIS_MODULE,
Group them under {}, like:
.driver = {
.owner = THIS_MODULE,
...
},
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/mfd/stmpe-i2c.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Applied, thanks.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V1 1/3] mfd: stmpe: Arrange #include header files in alphabetical order
Hi Viresh, On Fri, Nov 23, 2012 at 12:26:18AM +0530, Viresh Kumar wrote: This helps managing them better and also reduces chances of adding an header file twice. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/mfd/stmpe-spi.c | 2 +- drivers/mfd/stmpe.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) I fail to see the point of this patch, sorry. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
Hi Viresh, Lee, On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote: From: Vipul Kumar Samar vipulkumar.sa...@st.com This patch extends existing DT support for stmpe devices. This updates: - DT support from stmpe SPI and I2C drivers - missing header files in stmpe.c - stmpe_of_probe() with pwm, rotator and new bindings. - Bindings are updated in binding document. Signed-off-by: Vipul Kumar Samar vipulkumar.sa...@st.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- V4-V5: -- - 2/3 and 3/3 merged. - irq_trigger is kept same for non-DT booti. @Lee: I haven't added your Acked-by, because this differs from your Acked version. Lee, are you ok with this one ? Could you give it a test ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V7] mfd: stmpe: Update DT support for stmpe driver
Hi Viresh, On Fri, Dec 07, 2012 at 08:29:37PM +0530, Viresh Kumar wrote: From: Vipul Kumar Samar vipulkumar.sa...@st.com This patch extends existing DT support for stmpe devices. This updates: - missing header files in stmpe.c - stmpe_of_probe() with pwm, rotator and new bindings. - Bindings are updated in binding document. Acked-by: Lee Jones lee.jo...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Vipul Kumar Samar vipulkumar.sa...@st.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- V6-V7: - Minor grammer correction in stmpe.txt - Removed comment over pdata-id = -1 Very good, patch applied to my for-next branch now. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mfd/regulator: tps65090: add DT support and suspend/resume cleanups
Hi Laxman, On Fri, Dec 28, 2012 at 02:59:37PM +0530, Laxman Dewangan wrote: The patch series add DT support on TPS65090 device. Also remove the suspend/resume implementation as it duplicates with irq_suspend/irq_resume(). Laxman Dewangan (4): mfd: tps65090: add DT support for tps65090 regulator: tps65090: add DT support mfd: tps65090: Pass irq domain when adding mfd sub devices mfd: tps65090: remove suspend/resume callbacks .../devicetree/bindings/regulator/tps65090.txt | 121 drivers/mfd/tps65090.c | 77 drivers/regulator/tps65090-regulator.c | 96 +++- include/linux/mfd/tps65090.h |1 + 4 files changed, 266 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/tps65090.txt All 4 patches applied to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 4/6] mfd: tps6507x: add device-tree support.
Hi Manish, On Tue, Jan 29, 2013 at 01:08:52PM +0530, Vishwanathrao Badarkhe, Manish wrote: Add device tree based initialization support for TI's tps6507x mfd device. Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com --- Changes since V1: - updated subject line for commit. :100644 100644 409afa2... 5ad4b77... Mdrivers/mfd/tps6507x.c drivers/mfd/tps6507x.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mfd/regulator: tps65090: add DT support and suspend/resume cleanups
Hi Laxman, On Sun, Feb 03, 2013 at 03:19:31PM +0100, Samuel Ortiz wrote: Hi Laxman, On Fri, Dec 28, 2012 at 02:59:37PM +0530, Laxman Dewangan wrote: The patch series add DT support on TPS65090 device. Also remove the suspend/resume implementation as it duplicates with irq_suspend/irq_resume(). Laxman Dewangan (4): mfd: tps65090: add DT support for tps65090 regulator: tps65090: add DT support mfd: tps65090: Pass irq domain when adding mfd sub devices mfd: tps65090: remove suspend/resume callbacks .../devicetree/bindings/regulator/tps65090.txt | 121 drivers/mfd/tps65090.c | 77 drivers/regulator/tps65090-regulator.c | 96 +++- include/linux/mfd/tps65090.h |1 + 4 files changed, 266 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/tps65090.txt All 4 patches applied to my for-next branch, thanks. Sorry for the confusion: I took v2 of your patchset, skipping the regulator patch who will go through Mark's tree. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/7] mfd: update on max8925 for DT support
Hi Haojian, On Mon, Feb 04, 2013 at 09:05:09AM +0800, Haojian Zhuang wrote: Hi Samuel, Are they merged into your git tree? No, they're not. Qing sent several versions for many of the patches in this patchset: Could you please send a rebased patchset (on top of for-next) with the latest versions of each patch ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/6] mfd: max8925: add irqdomain for dt
Hi Haojian, On Mon, Feb 04, 2013 at 11:40:42PM +0800, Haojian Zhuang wrote: From: Qing Xu qi...@marvell.com Add irqdomains for max8925's main irq, wrap irq register operations into irqdomain's map func. it is necessary for dt support. Also, add dt support for max8925 driver. Signed-off-by: Qing Xu qi...@marvell.com Signed-off-by: Haojian Zhuang haojian.zhu...@gmail.com --- drivers/mfd/max8925-core.c | 73 +-- drivers/mfd/max8925-i2c.c | 36 +++-- include/linux/mfd/max8925.h |3 +- 3 files changed, 78 insertions(+), 34 deletions(-) This and the next 5 patches applied, thanks for the heads up. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
Hi Simon, On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: The ChromeOS Embedded Controller (EC) is an Open Source EC implementation used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt line is used to indicate when the EC needs service. All 6 patches applied to my mfd-next tree, thanks a lot. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote: Hi Simon, On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: The ChromeOS Embedded Controller (EC) is an Open Source EC implementation used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt line is used to indicate when the EC needs service. All 6 patches applied to my mfd-next tree, thanks a lot. Actually, this one fails to build when CONFIG_OF is not set: drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function ‘of_device_is_available’ [-Werror=implicit-function-declaration] If the check in cros_ec_probe_i2c() is really needed then you'll need to inline of_device_is_available() into a NOP in include/linux/of.h. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
Hi Simon, On Tue, Mar 19, 2013 at 07:01:42PM -0700, Simon Glass wrote: Hi Samuel, On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz sa...@linux.intel.com wrote: On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote: Hi Simon, On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: The ChromeOS Embedded Controller (EC) is an Open Source EC implementation used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt line is used to indicate when the EC needs service. All 6 patches applied to my mfd-next tree, thanks a lot. Actually, this one fails to build when CONFIG_OF is not set: drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function ‘of_device_is_available’ [-Werror=implicit-function-declaration] If the check in cros_ec_probe_i2c() is really needed then you'll need to inline of_device_is_available() into a NOP in include/linux/of.h. Actually I suppose that call is not really needed. Would you like to remove it, or shall I send a new patch? I will remove it. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support
Hi Simon, On Wed, Mar 20, 2013 at 09:14:56AM +0100, Samuel Ortiz wrote: On Tue, Mar 19, 2013 at 07:01:42PM -0700, Simon Glass wrote: Hi Samuel, On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz sa...@linux.intel.com wrote: On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote: Hi Simon, On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote: The ChromeOS Embedded Controller (EC) is an Open Source EC implementation used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt line is used to indicate when the EC needs service. All 6 patches applied to my mfd-next tree, thanks a lot. Actually, this one fails to build when CONFIG_OF is not set: drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function ‘of_device_is_available’ [-Werror=implicit-function-declaration] If the check in cros_ec_probe_i2c() is really needed then you'll need to inline of_device_is_available() into a NOP in include/linux/of.h. Actually I suppose that call is not really needed. Would you like to remove it, or shall I send a new patch? I will remove it. This is fixed and pushed. I also fixed some warnings and another build failure for the case when all of your code is modular. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] mfd: as3711: add OF support
Hi Guennadi, On Wed, Mar 20, 2013 at 08:40:15PM +0100, Guennadi Liakhovetski wrote: Hi all On Sat, 2 Mar 2013, Mark Brown wrote: On Mon, Feb 18, 2013 at 10:57:44AM +0100, Guennadi Liakhovetski wrote: Add device-tree bindings to the AS3711 regulator and backlight drivers. Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com This patch has been submitted more than a month ago and only has got one reviewed-be (thanks) and no comments otherwise. The patch touches multiple subsystems, so, it is a bit difficult to decide via which tree it should be pushed. Since the least trivial and largest portion of the patch is backlight-related, maybe Samuel could add his ack and then Andrew could pull it via his tree? We could do that, yes. But it also seems to me that this patch could be split into 3 different ones that could go in via their own trees. Is there a runtime dependency that I'm missing here ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/3] mfd: as3711: add OF support
Hi Guennadi, On Fri, Mar 22, 2013 at 05:15:47PM +0100, Guennadi Liakhovetski wrote: Add Flat Device Tree support to the AS3711 MFD driver. This patch just allows to bind the driver to I2C devices, instantiated from the DT. DT support for AS3711 cell drivers will be added in separate drivers. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com --- Documentation/devicetree/bindings/mfd/as3711.txt | 73 ++ drivers/mfd/as3711.c | 27 +++- 2 files changed, 96 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/as3711.txt Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] mfd: stmpe: DT: Enable no-irq mode configuration
Hi Linus, On Fri, Mar 01, 2013 at 01:07:16PM +0100, Linus Walleij wrote: From: Gabriel Fernandez gabriel.fernan...@stericsson.com If there is no interrupt property into stmpe node then activate the no-irq mode by setting the irq value to -1. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Gabriel Fernandez gabriel.fernan...@stericsson.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/mfd/stmpe.c | 3 +++ 1 file changed, 3 insertions(+) Applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] mfd: stmpe: DT: Add stmpe-i2c dt alias to get id device
Hi Linus, On Fri, Mar 01, 2013 at 01:07:26PM +0100, Linus Walleij wrote: From: Gabriel Fernandez gabriel.fernan...@stericsson.com This patch augments the STMP driver to read the device id from the stmpe-i2c dt alias if present. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Gabriel Fernandez gabriel.fernan...@stericsson.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/mfd/stmpe.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Applied to mfd-next as well. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 0/12] Palmas updates
Hi Ian, On Fri, Mar 22, 2013 at 02:55:10PM +, Ian Lartey wrote: This patchset adds to the support for the Palmas series of PMIC chips. Some of the patches have previously been submitted individually. The DT bindings doc has been added first due to comments that it was missing. Patches based on linux-next-20130319 Are you expecting all those patches to go through the MFD tree ? Also, you stil have a few comments from Milo and Stephen to adress. Are you planning to send a v11 ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 03/12] mfd: palmas add variant and OTP detection
Hi Ian,
On Fri, Mar 22, 2013 at 02:55:13PM +, Ian Lartey wrote:
@@ -278,20 +329,20 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
int ret;
u32 prop;
- ret = of_property_read_u32(node, ti,mux_pad1, prop);
+ ret = of_property_read_u32(node, ti,mux-pad1, prop);
if (!ret) {
pdata-mux_from_pdata = 1;
pdata-pad1 = prop;
}
- ret = of_property_read_u32(node, ti,mux_pad2, prop);
+ ret = of_property_read_u32(node, ti,mux-pad2, prop);
if (!ret) {
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
/* The default for this register is all masked */
- ret = of_property_read_u32(node, ti,power_ctrl, prop);
+ ret = of_property_read_u32(node, ti,power-ctrl, prop);
if (!ret)
pdata-power_ctrl = prop;
else
@@ -309,7 +360,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg;
int slave;
struct mfd_cell *children;
The '-' to '_' fix has been sent by J Keerthy and is on my mfd-next tree
aready. Would you mind removing it from this patch ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 04/14] mfd: Add Samsung PWM/timer master driver
Hi Tomasz, On Thu, Apr 04, 2013 at 06:37:01PM +0200, Tomasz Figa wrote: This patch adds master driver for PWM/timer block available on many Samsung SoCs providing clocksource and PWM output capabilities. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/pwm/pwm-samsung.txt| 37 ++ drivers/clocksource/Kconfig| 1 + drivers/mfd/Kconfig| 3 + drivers/mfd/Makefile | 1 + drivers/mfd/samsung-pwm.c | 439 + drivers/pwm/Kconfig| 1 + include/linux/mfd/samsung-pwm.h| 49 +++ include/linux/platform_data/samsung-pwm.h | 28 ++ 8 files changed, 559 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-samsung.txt create mode 100644 drivers/mfd/samsung-pwm.c create mode 100644 include/linux/mfd/samsung-pwm.h create mode 100644 include/linux/platform_data/samsung-pwm.h Why is that an MFD driver, and why aren't you using the PWM APIs for it ? Also, you probably want to look at using the regmap APIs for your IO. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mfd: Add device tree bindings for Arizona class devices
Hi Mark, On Tue, Apr 02, 2013 at 10:38:48PM +0100, Mark Brown wrote: Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- Documentation/devicetree/bindings/mfd/arizona.txt | 62 drivers/mfd/arizona-core.c| 64 + drivers/mfd/arizona-i2c.c | 10 +++- drivers/mfd/arizona-spi.c | 10 +++- drivers/mfd/arizona.h | 12 5 files changed, 154 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/arizona.txt Applied as well, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mfd: Add device tree bindings for Arizona class devices
Hi Mark, On Tue, Apr 02, 2013 at 10:38:48PM +0100, Mark Brown wrote: Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- Documentation/devicetree/bindings/mfd/arizona.txt | 62 drivers/mfd/arizona-core.c| 64 + drivers/mfd/arizona-i2c.c | 10 +++- drivers/mfd/arizona-spi.c | 10 +++- drivers/mfd/arizona.h | 12 5 files changed, 154 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/arizona.txt This is the one that caused the build failure around missing arizona_of_get_core_pdata() with !CONFIG_OF, so I'm leaving this one out for now. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC v2 1/2] max77693: added device tree support
Hi Andrzej, On Tue, Feb 19, 2013 at 04:36:16PM +0100, Andrzej Hajda wrote: max77693 mfd main device uses only wakeup field from max77693_platform_data. This field is mapped to wakeup-source property in device tree. Device tree bindings doc will be added in max77693-led patch. Signed-off-by: Andrzej Hajda a.ha...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mfd/max77693.c | 40 +--- 1 file changed, 33 insertions(+), 7 deletions(-) This patch looks good to me, but doesn't apply to mfd-next. Would you mind rebasing it ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 02/12] mfd: palmas: is_palmas_charger needed by multiple drivers
Hi Ian, On Fri, Mar 22, 2013 at 02:55:12PM +, Ian Lartey wrote: is_palmas_charger checks for the presence of charging functionality in the device Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Ian Lartey i...@slimlogic.co.uk Acked-by: Laxman Dewangani ldewan...@nvidia.com --- include/linux/mfd/palmas.h | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) I applied this one now, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10 0/12] Palmas updates
Hi Graeme, On Mon, Apr 08, 2013 at 04:55:58PM +0100, Graeme Gregory wrote: On 05/04/13 17:30, Samuel Ortiz wrote: Hi Ian, On Fri, Mar 22, 2013 at 02:55:10PM +, Ian Lartey wrote: This patchset adds to the support for the Palmas series of PMIC chips. Some of the patches have previously been submitted individually. The DT bindings doc has been added first due to comments that it was missing. Patches based on linux-next-20130319 Are you expecting all those patches to go through the MFD tree ? Also, you stil have a few comments from Milo and Stephen to adress. Are you planning to send a v11 ? Hi Samuel, The device is an MFD so I suspect the best path is through MFD tree Yes, that's fine. I just need to make sure everyone is on sync. although I notice you have applied the patch that was required by all other patches so maybe this is not so much the case now! Real life has got in the way of the next updated series of patches but they will be issued just as soon as we can. I know about real life getting in the way, no worries ;) Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] mfd: wm8994: Add device ID data to WM8994 OF device IDs
Hi Mark, On Thu, Apr 11, 2013 at 06:11:50PM +0100, Mark Brown wrote: We can actually read this back from the device but we use this when registered using standard I2C board data registration so make sure it's there for OF too. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/mfd/wm8994-core.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Both patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Lorenzo,
I don't particularily like this code, but I guess most of my dislike
comes from the whole bridge interface API and how that forces you into
implementing pretty much static code.
A few nitpicks:
On Thu, Jun 06, 2013 at 10:59:23AM +0100, Lorenzo Pieralisi wrote:
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..391eda1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1148,3 +1148,10 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+config VEXPRESS_SPC
+ bool Versatile Express SPC driver support
+ depends on ARM
+ depends on VEXPRESS_CONFIG
+ help
Please provide a detailed help entry here.
+ Serial Power Controller driver for ARM Ltd. test chips.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..3a01203 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-config.o vexpress-sysreg.o
+obj-$(CONFIG_VEXPRESS_SPC) += vexpress-spc.o
So you have Versatile Express platforms that will not need SPC ? i.e.
why isn't all that stuff under a generic CONFIG_VEXPRESS symbol ?
+static struct vexpress_spc_drvdata *info;
+static u32 *vexpress_spc_config_data;
+static struct vexpress_config_bridge *vexpress_spc_config_bridge;
+static struct vexpress_config_func *opp_func, *perf_func;
+
+static int vexpress_spc_load_result = -EAGAIN;
As I said, quite static...
+irqreturn_t vexpress_spc_irq_handler(int irq, void *data)
missing a static here ?
+static bool __init __vexpress_spc_check_loaded(void);
+/*
+ * Pointer spc_check_loaded is swapped after init hence it is safe
+ * to initialize it to a function in the __init section
+ */
+static bool (*spc_check_loaded)(void) __refdata =
__vexpress_spc_check_loaded;
+
+static bool __init __vexpress_spc_check_loaded(void)
+{
+ if (vexpress_spc_load_result == -EAGAIN)
+ vexpress_spc_load_result = vexpress_spc_init();
+ spc_check_loaded = vexpress_spc_initialized;
+ return vexpress_spc_initialized();
+}
+
+/*
+ * Function exported to manage early_initcall ordering.
+ * SPC code is needed very early in the boot process
+ * to bring CPUs out of reset and initialize power
+ * management back-end. After boot swap pointers to
+ * make the functionality check available to loadable
+ * modules, when early boot init functions have been
+ * already freed from kernel address space.
+ */
+bool vexpress_spc_check_loaded(void)
+{
+ return spc_check_loaded();
+}
+EXPORT_SYMBOL_GPL(vexpress_spc_check_loaded);
That one and the previous function look really nasty to me.
The simple fact that you need a static variable in your code to check if
your module is loaded sounds really fishy.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support
Hi Lorenzo, On Tue, Jun 11, 2013 at 10:05:45AM +0100, Lorenzo Pieralisi wrote: Hi Samuel, if nobody has objections I think this set is ready to get merged. As Nico mentioned in: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173541.html since we would like to get it merged through the ARM SoC tree owing to dependencies between this code and ARM power management back-ends, your ack would be appreciated, if you think it is worth it of course. I'm fine with it going through the arm-soc tree, but please prepare a branch for me to pull from. AFAIR, we got a merge conflict during the last merge window with the vexpress driver, I want to avoid that for the next one. Now, about the driver itself, besides the really odd code design, the static variables all over the place, the nasty init hacks and the unneeded long function names, someone should refresh my memory and explain to me why is this guy under mfd. I can see it somehow supports IP blocks providing different functions, but the design is not sharing anything with most of the rest of the mfd drivers. Not only that, but the whole vexpress-config code design is not the nicest piece of code I've ever seen. And I'm usually not picky. e.g. the whole vexpress-config ad-hoc API is awkward and I wonder if it could be implemented as a bus instead. FWIW I take the blame here for not reviewing the initial driver submission that Arnd kindly sent to me...But now that I'm looking at it, I think it really is on the edge of being staging material. Any thought on that ? Cheers, Samuel. Thank you very much indeed, Lorenzo On Thu, Jun 06, 2013 at 10:59:21AM +0100, Lorenzo Pieralisi wrote: This patch is v3 of a previous posting: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173464.html v3 changes: - added __refdata to spc_check_loaded pointer - removed some exported symbols - added node pointer check in vexpress_spc_init() v2 changes: - Dropped timeout interface patch - Converted interfaces to non-timeout ones, integrated and retested - Removed mutex used at init - Refactored code to work around init sections warning - Fixed two minor bugs This patch series introduces support for the Versatile Express Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles. SPC driver is a fundamental component of TC2 power management and allows to carry out C-state management and DVFS for A15 and A7 clusters. First patch provides changes required by SPC to comply with the Versatile Express config API, second patch is the SPC driver implementation. Code extensively exercised through CPUidle and CPUfreq power states and operating point transitions. Lorenzo Pieralisi (1): drivers: mfd: vexpress: add Serial Power Controller (SPC) support Pawel Moll (1): drivers: mfd: refactor the vexpress config bridge API Documentation/devicetree/bindings/mfd/vexpress-spc.txt | 35 + drivers/mfd/Kconfig| 7 + drivers/mfd/Makefile | 1 + drivers/mfd/vexpress-config.c | 61 +- drivers/mfd/vexpress-spc.c | 633 ++ drivers/mfd/vexpress-sysreg.c | 2 +- include/linux/vexpress.h | 59 +- 7 files changed, 770 insertions(+), 28 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt create mode 100644 drivers/mfd/vexpress-spc.c -- 1.8.2.2 -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: twl4030-power: Split from twl-core into a dedicated module
Hi Florian,
On Thu, May 30, 2013 at 03:51:54PM +0200, Florian Vaussard wrote:
For now, the call to twl4030-power is hard-wired inside twl-core.
To ease the future transition to DT, make twl4030-power as a
separate module, like what is already done for twl4030-audio
and others.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl-core.c | 12 ++---
drivers/mfd/twl4030-power.c | 54
+++
include/linux/i2c/twl.h |1 -
3 files changed, 52 insertions(+), 15 deletions(-)
Looks good, I only have one comment:
+static struct platform_driver twl4030_power_driver = {
+ .driver = {
+ .name = twl4030_power,
+ .owner = THIS_MODULE,
+ },
+ .probe = twl4030_power_probe,
+ .remove = twl4030_power_remove,
+};
+
+static int __init twl4030_power_init(void)
+{
+ return platform_driver_register(twl4030_power_driver);
}
+subsys_initcall(twl4030_power_init);
+
+static void __exit twl4030_power_exit(void)
+{
+ platform_driver_unregister(twl4030_power_driver);
+}
+module_exit(twl4030_power_exit);
Please use module_platform_driver() here.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] mfd: twl4030-power: Start transition to DT
Hi Florian,
On Thu, May 30, 2013 at 03:51:55PM +0200, Florian Vaussard wrote:
int twl4030_power_probe(struct platform_device *pdev)
{
struct twl4030_power_data *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
int err = 0;
- int i;
- struct twl4030_resconfig *resconfig;
- u8 val, address = twl4030_start_script_address;
+ u8 val;
+
+ if (!pdata !node) {
+ dev_err(pdev-dev, Platform data is missing\n);
+ return -EINVAL;
+ }
err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
TWL4030_PM_MASTER_PROTECT_KEY);
@@ -525,26 +575,17 @@ int twl4030_power_probe(struct platform_device *pdev)
if (err)
goto unlock;
- for (i = 0; i pdata-num; i++) {
- err = load_twl4030_script(pdata-scripts[i], address);
+ if (pdata) {
+ err = twl4030_power_configure_scripts(pdata);
if (err)
goto load;
- address += pdata-scripts[i]-size;
- }
-
- resconfig = pdata-resource_config;
- if (resconfig) {
- while (resconfig-resource) {
- err = twl4030_configure_resource(resconfig);
- if (err)
- goto resource;
- resconfig++;
-
- }
+ err = twl4030_power_configure_resources(pdata);
+ if (err)
+ goto resource;
You're simplifying the probe routine here by defining 2
twl4030_power_configure_* functions. That's good, but it should be a
separate patch as it's not related to the DT porting effort.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Olof, On Mon, Jun 17, 2013 at 10:44:51AM -0700, Olof Johansson wrote: On Mon, Jun 17, 2013 at 04:51:09PM +0100, Lorenzo Pieralisi wrote: The TC2 versatile express core tile integrates a logic block that provides the interface between the dual cluster test-chip and the M3 microcontroller that carries out power management. The logic block, called Serial Power Controller (SPC), contains several memory mapped registers to control among other things low-power states, operating points and reset control. This patch provides a driver that enables run-time control of features implemented by the SPC control logic. The SPC control logic is required to be programmed very early in the boot process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and wake-up IRQs for power management. Since the SPC logic is also used to control clocks and operating points, that have to be initialized early as well, the SPC interface consumers can not rely on early initcalls ordering, which is inconsistent, to wait for SPC initialization. Hence, in order to keep the components relying on the SPC coded in a sane way, the driver puts in place a synchronization scheme that allows kernel drivers to check if the SPC driver has been initialized and if not, to initialize it upon check. A status variable is kept in memory so that loadable modules that require SPC interface (eg CPUfreq drivers) can still check the correct initialization and use the driver correctly after functions used at boot to init the driver are freed. The driver also provides a bridge interface through the vexpress config infrastructure. Operations allowing to read/write operating points are made to go via the same interface as configuration transactions so that all requests to M3 are serialized. Device tree bindings documentation for the SPC component is provided with the patchset. Sorry, I got to think of this over the weekend and should have replied before you had a chance to repost, but still: Why is the operating point and frequency change code in this driver at all? Usually, the MFD driver contains a shared method to access register space on a multifunction device, but the actual operation of each subdevice is handled by individual drivers in the regular locations. I suppose that's what I meant with my initial comment: Why is that stuff under drivers/mfd/ ? So, in the case of operating points and requencies, that should be in a cpufreq driver. And the clock setup should presumably be in a clk framework driver if needed. Yep, several drivers do that already. Then all that would be left here is the functionality for submitting the two kinds of commands, and handling interrupts. That'll trim down the driver to a point where I think you'll find it much easier to get merged. :-) Definitely, yes. And the code would be a lot easier to review and maintain too. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support
Hi Pawell, On Thu, Jun 13, 2013 at 10:45:57AM +0100, Pawel Moll wrote: On Thu, 2013-06-13 at 01:13 +0100, Samuel Ortiz wrote: Now, about the driver itself, besides the really odd code design, the static variables all over the place, the nasty init hacks and the unneeded long function names, someone should refresh my memory and explain to me why is this guy under mfd. I can see it somehow supports IP blocks providing different functions, but the design is not sharing anything with most of the rest of the mfd drivers. I belive the vexpress-sysreg.c is a Multi Function Device by all means. It does so many things that only a water fountain is missing ;-) If you feel strongly about it, I'm ready to split it into mfd_cells and move the gpio and leds code into separate drivers, however I'm not convinced that it's worth the effort. Well, after seeing your last patch for ifdef'ing the GPIO and LED code, I think it is worth the effort. Now, as to the vexpress-config.c... The first time I've posted the series, all parts lived in driver/misc(/vexpress), but (if I remember correctly) Arnd had some feelings about misc existence at all... I was thinking about a separate directory for random system/platform/machine configuration drivers, but the idea didn't get any traction. drivers/misc would already have been a nicer option imo. Not only that, but the whole vexpress-config code design is not the nicest piece of code I've ever seen. And I'm usually not picky. e.g. the whole vexpress-config ad-hoc API is awkward and I wonder if it could be implemented as a bus instead. Funny you mention this :-) Again, the first version actually was a vexpress-config bus. The feedback was - a whole bus_type is over the top (I'm simplifying the letter slightly but this was the spirit). I think it would make sense to have it under drivers/bus/. It might be a little over the top, but when I look at the current code I'd be really happy to read an over-the-top bus driver instead. At least we'd know straight away what youre trying to achieve with this code and it would probably remove a fair chunk of the weird bridge API (the registering and the function reference stuff). Do you have a reference for the patch first version ? FWIW I take the blame here for not reviewing the initial driver submission that Arnd kindly sent to me...But now that I'm looking at it, I think it really is on the edge of being staging material. Any thought on that ? I'm more than happy to improve it. The infrastructure (as in: the hardware) itself is slightly strange and the code pretty much reflects the situation. There is also a very good reason for some of the oddities like static bridges array etc - the infrastructure must be functional very early, long before slab is available (this also caused a lot of issues with the bus-based implementation, as the device model does kmalloc all over the place). So to summarize - I'm open to any suggestions and ready to spend time on this stuff. I'd say splitting the sysreg driver and leaving only the MFD bits in the MFD driver would be a first step. Also, re-considering the bus implementation for the config part would also be interesting. I'd be interested in looking at your first version of the patch. Regards and thanks for your time! Thanks for your understanding. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/5] mfd: twl4030-power: Start DT conversion and updates
Hi Florian, On Tue, Jun 18, 2013 at 03:17:55PM +0200, Florian Vaussard wrote: Hello, This series enables a partial DT support for twl4030-power. The missing part is the power management scripts, as the required binding should be defined first. It however enables the complete shutdown of the processor at poweroff when booting with DT, dropping the power consumption from around 350 mA on Overo+Tobi to about 40 mA. The poweroff callback was tested with both DT and non-DT boots. The last two patches simplify the error path in the probe function, and fix registers relocking on error. Best regards, Florian Since v1: - use module_platform_driver() - split the refactoring of the probe function into a dedicated patch - new patch to fix registers relocking on error - rebased on mfd-next Florian Vaussard (5): mfd: twl4030-power: Split from twl-core into a dedicated module mfd: twl4030-power: Simplify probing of power scripts and resources mfd: twl4030-power: Start transition to DT mfd: twl4030-power: Simplify error path mfd: twl4030-power: Fix relocking on error All 5 patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support
Hi Pawel, On Tue, Jun 18, 2013 at 10:29:42AM +0100, Pawel Moll wrote: On Tue, 2013-06-18 at 10:09 +0100, Samuel Ortiz wrote: Hi Pawell, Double l in the wrong place ;-) Apologies... If you feel strongly about it, I'm ready to split it into mfd_cells and move the gpio and leds code into separate drivers, however I'm not convinced that it's worth the effort. Well, after seeing your last patch for ifdef'ing the GPIO and LED code, I think it is worth the effort. Good point. But as this - obviously - won't happen on time for 3.11, I hope you would be kind enough to take the #ifdef patch in for now. I see that you guys are willing to improve this stuff, so I can take it, yes. Now, as to the vexpress-config.c... The first time I've posted the series, all parts lived in driver/misc(/vexpress), but (if I remember correctly) Arnd had some feelings about misc existence at all... I was thinking about a separate directory for random system/platform/machine configuration drivers, but the idea didn't get any traction. drivers/misc would already have been a nicer option imo. Ok. Quite conveniently Arnd is the driver/misc maintainer so I'll get first-hand feedback on this. Not only that, but the whole vexpress-config code design is not the nicest piece of code I've ever seen. And I'm usually not picky. e.g. the whole vexpress-config ad-hoc API is awkward and I wonder if it could be implemented as a bus instead. Funny you mention this :-) Again, the first version actually was a vexpress-config bus. The feedback was - a whole bus_type is over the top (I'm simplifying the letter slightly but this was the spirit). I think it would make sense to have it under drivers/bus/. It might be a little over the top, but when I look at the current code I'd be really happy to read an over-the-top bus driver instead. At least we'd know straight away what youre trying to achieve with this code and it would probably remove a fair chunk of the weird bridge API (the registering and the function reference stuff). Do you have a reference for the patch first version ? http://thread.gmane.org/gmane.linux.ports.arm.kernel/185014/focus=185019 So to summarize - I'm open to any suggestions and ready to spend time on this stuff. I'd say splitting the sysreg driver and leaving only the MFD bits in the MFD driver would be a first step. Also, re-considering the bus implementation for the config part would also be interesting. Ok, so what I'll do: 1. Split vexpress-sysreg into * gpio driver * leds driver * the rest (still in mfd though) Sounds good to me. 2. Move the vexpress-sysreg platform management functions into misc (unless we get any better place for it) This is for Arnd and Greg to decide I suppose. 3. Move vexpress-config into drivers/bus as it is (however I see no one in MAINTAINERS for this directory) ISTR that Arnd originally created that directory, so he may help here. Arnd also had some concerns about implementing this code as a bus, mostly about it not being a discoverable bus. IMHO that's a valid concern, and this is why you ended up putting it under MFD which can be seen as some sort of platform devices bus. But I still believe the bus API would make this code look cleaner and easier to maintain. 4. *Try* to use more of the standard bus (aka bus_type) infrastructure, however this will be the trickiest part of this all - as I've mentioned the code must be functional before SLAB is up... You shall see some patches before 3.11-rc1. Ok, we'll have plenty of time to have it ready for the 3.12 merge window then. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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-o...@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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Lorenzo, On Tue, Jul 16, 2013 at 05:05:42PM +0100, Lorenzo Pieralisi wrote: Hello, version v5 of VExpress SPC driver, please read on the changelog for major changes and explanations. The probing scheme is unchanged, since after trying the early platform devices approach it appeared that the end result was no better than the current one. The only clean solution relies either on changing how secondaries are brought up in the kernel (later than now) or enable early platform device registration through DT. Please check this thread for the related discussion: https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html The interface was adapted to regmap and again reverted to old driver for the following reasons: - Power down registers locking is hairy and requires arch spinlocks in the MCPM back end to work properly, normal spinlocks cannot be used - Regmap adds unnecessary code to manage SPC since it is just a bunch of registers used to control power management flags, the overhead is just not worth it (talking about power down registers, not the vexpress config interface) - The locking scheme behind regmap requires all registers in the map to be protected with the same lock, which is not exactly what we want here - Given the reasons above, adding a regmap interface buys us nothing from a driver readability and maintainability perspective (again just talking about the power interface, a few registers) because for the SPC it would simply not be used /drivers/mfd is probably not the right place for this code as it stands (but probably will be when the entire driver, with DVFS and config interface, is complete). Could you please elaborate on how will the SPC driver extend into an MFD driver? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Pawel, On Wed, Jul 17, 2013 at 03:20:11PM +0100, Pawel Moll wrote: On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote: On Wed, 17 Jul 2013, Pawel Moll wrote: On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote: If this is really miscelaneous code that really doesn't fit anywhere else, it should rather go into drivers/misc/ as a last resort. Interestingly enough drivers/misc was my first choice for all the vexpress stuff, but it wasn't received well... Anyway, the SPC driver as it is now seem to be a power management system driver. Maybe a relevant directory would be in place? Wouldn't PSCI belong there as well? (there are two psci.c files in arch/arm and arch/arm64, surprisingly similar ones ;-) The bottom line is: today it is not an MFD driver. But we know it will, right? So better save some churn by storing the initial code where it would end up anyway once complete. Not in that form, no. The code living in mfd will just register mfd_cells while functional parts are going to live elsewhere. This is how I understand what Samuel asked me to do and that's what is happening to vexpress-sysreg now. Very good, I'll happily apply such changes. If I understand the IP correctly, the SPC driver will stay as a set of runtime APIs for controlling the SPC features. If that's the case, then misc sounds like a more appropriate place for this driver. drivers/power/ really is for power supplies and charging drivers. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Hi Nicolas, On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote: On Wed, 17 Jul 2013, Russell King - ARM Linux wrote: On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote: The sanest location at this point might simply be drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c depending on whether or not more such driver glue is expected in the vexpress future. No point putting arm in the path, especially if this is later reused on arm64. You wouldn't be making that argument if it were arch/arm64 and arch/arm32 - you'd probably be arguing that arm made perfect sense. Well... in a sense: yes. But in the end, having per arch directories under drivers/ is silly. We already have per arch directories under arch/already. Don't get too hung up on names please, it's really not worth the time and effort being soo pedantic, and being soo pedantic leads to pointless churn when someone comes along and wants to pedantically change the names because it no longer matches the users. At this point I don't really care about the name. I just want the damn thing merged upstream. But after several iterations to either fit one or another maintainers taste, each rework ends up in that maintainer saying: Now that you've reworked the code, I still don't like it since this no longer fits in my subsystem tree. FWIW, we asked Pawel to rework the sysreg and config parts of the vexpress driver, make it an actual MFD driver, and spread the remaining bits of the code into their respective subsystems. I don't think this is an eccentric requirement. In fact what we'd need at this point is drivers/code_that_no_subsystem_maintainers_wants/. Which is what some people think drivers/mfd/ is... I don't mind merging Lorenzo's SPC driver as it is if he can explain to me how it will eventually evolve into an actual MFD driver. If that's not the case, I don't see how I could justify merging it through the MFD tree. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
