Re: [PATCH RESEND 1/4] ARM: OMAP2+: AM33XX: Add tps65910 device tree data
On 23/07/12 14:34, Mark Brown wrote: On Mon, Jul 23, 2012 at 01:23:50PM +, AnilKumar, Chimata wrote: By the way, if we look at all the regulator added (DT supported) till now have the similar problem. arch/arm/boot/dts/imx6q.dtsi This is fine - the SoC contains integrated regulators which supply other bits of the Soc so we can be confident that the hookup is good just based on the silicon. arch/arm/boot/dts/twl4030.dtsi arch/arm/boot/dts/twl6030.dtsi These appear to have similar issues and should be fixed, at least as far as the voltage ranges go. arch/arm/boot/dts/db8500.dtsi I'm not actually seeing anything terribly problematic here, though the regulator-name properties should really be removed as they're fairly useless and seem to be missing the point of having the property. I've missed the context of the thread, so can't comment, but I'm happy to remove the regulator-name properties from db8500.dts. Adding to my TODO. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 1/4] ARM: OMAP2+: AM33XX: Add tps65910 device tree data
Hi Mark, arch/arm/boot/dts/db8500.dtsi I'm not actually seeing anything terribly problematic here, though the regulator-name properties should really be removed as they're fairly useless and seem to be missing the point of having the property. Just looking at this now. The regulator-name property is used to populate constrains-name. Are you sure you still want them all removed? Kind regards, Lee -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 1/4] ARM: OMAP2+: AM33XX: Add tps65910 device tree data
On Tue, Aug 28, 2012 at 10:21:33AM -0700, Mark Brown wrote: On Tue, Aug 28, 2012 at 12:26:07PM +0100, Lee Jones wrote: arch/arm/boot/dts/db8500.dtsi I'm not actually seeing anything terribly problematic here, though the regulator-name properties should really be removed as they're fairly useless and seem to be missing the point of having the property. Just looking at this now. The regulator-name property is used to populate constrains-name. Are you sure you still want them all removed? Yes, of course. There's no way that a generic .dtsi used for any possible board could come up with a sensible value. So how should constrains-name be populated then? Would you prefer regulator-names moved to the .dts file(s), or something else? -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, 08 Jan 2013, Pantelis Antoniou wrote: Hi Lee, On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. I see. What I'm asking about is whether there's a method where you can read an EEPROM, or some GPIO code combination where I can find out what kind of board is plugged each time. If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, 08 Jan 2013, Arnd Bergmann wrote: On Tuesday 08 January 2013, Pantelis Antoniou wrote: On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: On Tuesday 08 January 2013, Lee Jones wrote: If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( I thought that some of the newer UIBs had it, just not the old ones. As Pantelis says, we could at least detect the ones that have an EEPROM on them, and use a command line option or device tree attribute for the others. Arnd So I gather the new ones have an eeprom? I don't remember the details unfortunately. Lee should be the one who can find out. IIRC there was at least a single integeger number on them. Not as far as I can remember. There was (is?) a crude method of identifying UIBs, but attempting to obtain certain I2C lines and testing which ones were accessible. However, if there is an issue with I2C, the wrong UIB was 'probed'. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add dtsi for palmas
Totally agree to all the above concerns. So can we have a custom .dtsi file for a board+pmic combination? Or have only the required properties over ridden in the board file? The common approach is to only apply nodes and node properties to the .dtsi files which are appropriate for _all_ platforms which include them. Anything that is only relevant to a sub-set of boards should be in a higher ranking .dtsi file and finally, any settings which are board specific should be in the board's .dts file. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldoln_reg: ldoln {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldousb_reg: ldousb {
+ regulator-min-microvolt = 325;
+ regulator-max-microvolt = 325;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
};
i2c5 {
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldoln_reg: ldoln {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldousb_reg: ldousb {
+ regulator-min-microvolt = 325;
+ regulator-max-microvolt = 325;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
};
i2c5 {
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC ADC reworking including DT pieces, take 4
I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. I added Lee Jones because I hear no sign of life from Samuel. Unfortunately I can't be of any added help here, as I also send my pull-requests though Sam. Sorry I couldn't be of any more use Sebastian. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/22] mfd/ti_am335x_tscadc: Add DT support
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Patil, Rachna rac...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com [bigeasy: module alias, rename to ti,am3359-tscadc as it was tested on AM3359] I honestly can't tell if this is a change from the last version of your patchset or a description of this patch changes in general. This is cluttering your commit logs, please remove this as well. I took the original patch. Every change I made to it because people asked to merge changes into the patch where the problem occurred I added it here before my sign-off. In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? Generally speaking, if it is necessary to merge various author's patches into one, then you can the merger will tend to take authorship of the commit. Note that just because you are the author of the commit, it doesn't mean you authored the patch. I also use the rule of thumb that if you make significant changes to a patch, then you can also assume authorship too. I'll leave the 'how much is significant' to your own good judgement. If you're just making a few fixups, then just add your SOB in the normal way. That should be enough reward for a mere few patch fixes. Adding little 'I-did-this' notes to the commit log should mostly be avoided IMO. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/22] mfd/ti_am335x_tscadc: Add DT support
On Tue, 11 Jun 2013, Sebastian Andrzej Siewior wrote: On 06/11/2013 05:05 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 04:42:30PM +0200, Sebastian Andrzej Siewior wrote: In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? You probably don't want to change authorship unless the final patch is really far from the original one. In which case you can change it and mention the original author name in the commit log. If you have only made a few changes on top of the original patch, please say so explicitely in the commit log. Don't bother if we're talking about small changes or cosmetic ones. But your commit log has to be readable and clear. Commit 06c9494 on of many examples where cosmetic are recorded. But to make some progress I rewrite the commit log to resolve this and don't add anything to the sign-off area. If you are submitting the patch, you still have to add your own SOB. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt
On Thu, 13 Jun 2013, Linus Walleij wrote: On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K balaj...@ti.com wrote: PBIAS register configuration is based on the regulator voltage which supplies these pbias cells, sd i/o pads. With PBIAS register address and bit definitions different across omap[3,4,5], Simplify PBIAS configuration under three different regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pinctrl states are defined as pbias_off, pbias_1v8, pbias_3v. pinctrl state mmc_init is used for configuring speed mode, loopback clock (in devconf0/devconf1/prog_io1 register for omap3) and pull strength configuration (in control_mmc1 for omap4) Signed-off-by: Balaji T K balaj...@ti.com You *need* Lee Jones and Mark Brown to review this. Maybe Laurent has something to add too. Ux500 had the very same thing, and there this was solved using a GPIO regulator for vqmmc a level-shifter. I vaguely remember Laurent doing something similar with the SH stuff. I haven't seem much of this patch-set, but this certainly looks like it should be handled by a GPIO regulator instead of pinctrl. States are easily declared in a 'struct gpio_regulator_state', which the framework then uses to set the correct pins for the required voltage. And yes, 'vqmmc' is a good place to store the this regulator. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt
On Thu, 13 Jun 2013, Balaji T K wrote:
On Thursday 13 June 2013 04:17 PM, Lee Jones wrote:
On Thu, 13 Jun 2013, Linus Walleij wrote:
On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K balaj...@ti.com wrote:
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit definitions different across
omap[3,4,5], Simplify PBIAS configuration under three different
regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pinctrl states
are defined as pbias_off, pbias_1v8, pbias_3v.
pinctrl state mmc_init is used for configuring speed mode, loopback clock
(in devconf0/devconf1/prog_io1 register for omap3) and pull strength
configuration (in control_mmc1 for omap4)
Signed-off-by: Balaji T K balaj...@ti.com
You *need* Lee Jones and Mark Brown to review this.
Maybe Laurent has something to add too.
Ux500 had the very same thing, and there this was solved using
a GPIO regulator for vqmmc a level-shifter. I vaguely remember
Laurent doing something similar with the SH stuff.
I haven't seem much of this patch-set, but this certainly looks like
it should be handled by a GPIO regulator instead of pinctrl. States
are easily declared in a 'struct gpio_regulator_state', which the
framework then uses to set the correct pins for the required voltage.
Thanks for the pointer, but wondering why is it named as gpio-regulator
and how it is different from fixed-regulator.
After going through git log description, I understand that voltage/current
level
for a particular regulator is controlled by a set of pad/pin on the POWER IC
and pad/pin may be usually connected to gpio pins if it is needs to be
configurable and ground/pulled for constant voltage.
Collection of gpios logic level are modeled as state for particular voltage.
But gpio is not used in my case.
And yes, 'vqmmc' is a good place to store the this regulator.
As I say, I didn't see much of the code, only parts which looked
similar a voltage level-shifter.
The difference between fixed and gpio regulators, is that the former
is exactly that, 'fixed'. You can turn voltage on and off using a gpio
pin, but you can't shift the voltage. Something which is required of
your use-case. The latter switches between voltgages via a set of gpio
pins, for instance, your use-case could look somelike like:
static struct gpio_regulator_state sdi0_reg_states[] = {
{ .value = 330, .gpios = (1 0) },
{ .value = 180, .gpios = (0 0) },
};
But if there aren't any gpio pins involved, then this isn't what you
want either.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1] MFD: Change TWL6025 references to TWL6032
On Fri, 07 Jun 2013, 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 is 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 --- 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. 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 +++ 4 files changed, 77 insertions(+), 77 deletions(-) If the TWL6025 truly didn't enter production then I'm okay with this as long as Mark and the other maintainers are. For the MFD parts: Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Wed, 19 Jun 2013, Lee Jones wrote: On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. Ah, it looks like Sam must have already applied this. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Wed, 19 Jun 2013, Samuel Ortiz wrote: Hi Lee, On Wed, Jun 19, 2013 at 09:26:33AM +0100, Lee Jones wrote: On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. It's already in mfd-next. I noticed. Odd that I didn't receive you applied message. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Hello Grant, Hi Grant, Hello Grant, Could you pull this Please? A gentle ping on this. A gentle ping on this. Could you pull this one? Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com Why does Grant have to pull this? Do you know why Sam didn't take it? I'd be happy to, if it wasn't stepping on anyone's toes. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
On Thu, 20 Jun 2013, J Keerthy wrote: Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs Applied. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On Wed, 19 Jun 2013, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Applied with Stephen and Mark's RB. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On Thu, 11 Jul 2013, Lee Jones wrote: On Wed, 19 Jun 2013, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Applied with Stephen and Mark's RB. Scrap that, it appears to be applied already. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/2] mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
,
+ },
+};
+
+module_platform_driver(twl6030_gpadc_driver);
+
+MODULE_ALIAS(platform: DRIVER_NAME);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_DESCRIPTION(twl6030 ADC driver);
+MODULE_LICENSE(GPL);
diff --git a/include/linux/i2c/twl6030-gpadc.h
b/include/linux/i2c/twl6030-gpadc.h
new file mode 100644
index 000..5cd11e7
--- /dev/null
+++ b/include/linux/i2c/twl6030-gpadc.h
@@ -0,0 +1,51 @@
+/*
+ * include/linux/i2c/twl6030-gpadc.h
+ *
+ * TWL6030 GPADC module driver header
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Nishant Kamat nska...@ti.com
+ *
+ * Based on twl4030-madc.h
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen mikko.k.yli...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef _TWL6030_GPADC_H
+#define _TWL6030_GPADC_H
+
+
+/** struct twl6030_gpadc_result
+ * @raw_code raw adc value from GPADC
+ * @corrected_code corrected code calibrated adc value
+ * @result calculated value
+ */
+struct twl6030_gpadc_result {
+ int raw_code;
+ int corrected_code;
+ int result;
+};
+
+/*
+ * the user passes the bit mask of channels he wants to read converted values
+ * end pointer to buffer allocated for the conversion results
+ * on success returns 0.
+ */
+int twl6030_gpadc_conversion(u32 channels, struct twl6030_gpadc_result *res);
+
+#endif
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/2] mfd: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
Thank you for the review. There is v3 of this patch. My bad I didn't put it in reply to v1. I'll address you comments in v4. Would you care to review v3, please. I'd rather go straight on to review v4 with my comments addressed, if it's all the same to you? -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/22] ARM: ux500: Remove '0x's from OMAP5 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..be58604 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,7 +604,7 @@
ti,hwmods = wd_timer2;
};
- emif1: emif@0x4c00 {
+ emif1: emif@4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
phy-type= 2; /* DDR PHY type: Intelli PHY */
@@ -615,7 +615,7 @@
hw-caps-temp-alert;
};
- emif2: emif@0x4d00 {
+ emif2: emif@4d00 {
compatible = ti,emif-4d5;
ti,hwmods = emif2;
phy-type= 2; /* DDR PHY type: Intelli PHY */
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/22] ARM: ux500: Remove '0x's from OMAP3 IGEP0020 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0020.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..f7a8122 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -99,19 +99,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/22] ARM: ux500: Remove '0x's from OMAP2420 H4 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
label = bootloader;
reg = 0 0x2;
};
- partition@0x2 {
+ partition@2 {
label = params;
reg = 0x2 0x2;
};
- partition@0x4 {
+ partition@4 {
label = kernel;
reg = 0x4 0x20;
};
- partition@0x24 {
+ partition@24 {
label = file-system;
reg = 0x24 0x3dc;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/22] ARM: ux500: Remove '0x's from OMAP3 IGEP0030 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0030.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d0538..f628200 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -74,19 +74,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/22] ARM: ux500: Remove '0x's from OMAP3 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..16420ae 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,7 +111,7 @@
pinctrl-single,function-mask = 0x7f1f;
};
- omap3_pmx_wkup: pinmux@0x48002a00 {
+ omap3_pmx_wkup: pinmux@48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002a00 0x5c;
#address-cells = 1;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/22] ARM: ux500: Remove '0x's from OMAP3430 SDP DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3430-sdp.dts | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..281914e 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -84,15 +84,15 @@
label = bootloader-nor;
reg = 0 0x4;
};
- partition@0x4 {
+ partition@4 {
label = params-nor;
reg = 0x4 0x4;
};
- partition@0x8 {
+ partition@8 {
label = kernel-nor;
reg = 0x8 0x20;
};
- partition@0x28 {
+ partition@28 {
label = filesystem-nor;
reg = 0x24 0x7d8;
};
@@ -125,19 +125,19 @@
label = xloader-nand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-nand;
reg = 0x8 0x14;
};
- partition@0x1c {
+ partition@1c {
label = params-nand;
reg = 0x1c 0xc;
};
- partition@0x28 {
+ partition@28 {
label = kernel-nand;
reg = 0x28 0x50;
};
- partition@0x78 {
+ partition@78 {
label = filesystem-nand;
reg = 0x78 0x788;
};
@@ -170,19 +170,19 @@
label = xloader-onenand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-onenand;
reg = 0x8 0x4;
};
- partition@0xc {
+ partition@c {
label = params-onenand;
reg = 0xc 0x2;
};
- partition@0xe {
+ partition@e {
label = kernel-onenand;
reg = 0xe 0x20;
};
- partition@0x2e {
+ partition@2e {
label = filesystem-onenand;
reg = 0x2e 0xfd2;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/22] ARM: ux500: Remove '0x's from OMAP4 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..45708e1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -56,7 +56,7 @@
cache-level = 2;
};
- local-timer@0x48240600 {
+ local-timer@48240600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x48240600 0x20;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_HIGH);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/22] ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
label = bootloader;
reg = 0 0x2;
};
- partition@0x2 {
+ partition@2 {
label = params;
reg = 0x2 0x2;
};
- partition@0x4 {
+ partition@4 {
label = kernel;
reg = 0x4 0x20;
};
- partition@0x24 {
+ partition@24 {
label = file-system;
reg = 0x24 0x3dc;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/22] ARM: dts: Remove '0x's from OMAP4 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..45708e1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -56,7 +56,7 @@
cache-level = 2;
};
- local-timer@0x48240600 {
+ local-timer@48240600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x48240600 0x20;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_HIGH);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/22] ARM: dts: Remove '0x's from OMAP3 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..16420ae 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,7 +111,7 @@
pinctrl-single,function-mask = 0x7f1f;
};
- omap3_pmx_wkup: pinmux@0x48002a00 {
+ omap3_pmx_wkup: pinmux@48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002a00 0x5c;
#address-cells = 1;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/22] ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0020.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..f7a8122 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -99,19 +99,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/22] ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3430-sdp.dts | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..281914e 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -84,15 +84,15 @@
label = bootloader-nor;
reg = 0 0x4;
};
- partition@0x4 {
+ partition@4 {
label = params-nor;
reg = 0x4 0x4;
};
- partition@0x8 {
+ partition@8 {
label = kernel-nor;
reg = 0x8 0x20;
};
- partition@0x28 {
+ partition@28 {
label = filesystem-nor;
reg = 0x24 0x7d8;
};
@@ -125,19 +125,19 @@
label = xloader-nand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-nand;
reg = 0x8 0x14;
};
- partition@0x1c {
+ partition@1c {
label = params-nand;
reg = 0x1c 0xc;
};
- partition@0x28 {
+ partition@28 {
label = kernel-nand;
reg = 0x28 0x50;
};
- partition@0x78 {
+ partition@78 {
label = filesystem-nand;
reg = 0x78 0x788;
};
@@ -170,19 +170,19 @@
label = xloader-onenand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-onenand;
reg = 0x8 0x4;
};
- partition@0xc {
+ partition@c {
label = params-onenand;
reg = 0xc 0x2;
};
- partition@0xe {
+ partition@e {
label = kernel-onenand;
reg = 0xe 0x20;
};
- partition@0x2e {
+ partition@2e {
label = filesystem-onenand;
reg = 0x2e 0xfd2;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/22] ARM: dts: Remove '0x's from OMAP5 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..be58604 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,7 +604,7 @@
ti,hwmods = wd_timer2;
};
- emif1: emif@0x4c00 {
+ emif1: emif@4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
phy-type= 2; /* DDR PHY type: Intelli PHY */
@@ -615,7 +615,7 @@
hw-caps-temp-alert;
};
- emif2: emif@0x4d00 {
+ emif2: emif@4d00 {
compatible = ti,emif-4d5;
ti,hwmods = emif2;
phy-type= 2; /* DDR PHY type: Intelli PHY */
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/22] ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0030.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d0538..f628200 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -74,19 +74,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: twl6030-irq: migrate to IRQ threaded handler
);
}
- /*
- * NOTE:
- * Simulation confirms that documentation is wrong w.r.t the
- * interrupt status clear operation. A single *byte* write to
- * any one of STS_A to STS_C register results in all three
- * STS registers being reset. Since it does not matter which
- * value is written, all three registers are cleared on a
- * single byte write, so we just use 0x0 to clear.
- */
- ret = twl_i2c_write_u8(TWL_MODULE_PIH, 0x00, REG_INT_STS_A);
- if (ret)
- pr_warning(twl6030: I2C error in clearing PIH ISR\n);
-
- enable_irq(irq);
- }
-
- return 0;
-}
+ /*
+ * NOTE:
+ * Simulation confirms that documentation is wrong w.r.t the
+ * interrupt status clear operation. A single *byte* write to
+ * any one of STS_A to STS_C register results in all three
+ * STS registers being reset. Since it does not matter which
+ * value is written, all three registers are cleared on a
+ * single byte write, so we just use 0x0 to clear.
+ */
+ ret = twl_i2c_write_u8(TWL_MODULE_PIH, 0x00, REG_INT_STS_A);
+ if (ret)
+ pr_warn(twl6030: I2C error in clearing PIH ISR\n);
-/*
- * handle_twl6030_int() is the desc-handle method for the twl6030 interrupt.
- * This is a chained interrupt, so there is no desc-action method for it.
- * Now we need to query the interrupt controller in the twl6030 to determine
- * which module is generating the interrupt request. However, we can't do
i2c
- * transactions in interrupt context, so we must defer that work to a kernel
- * thread. All we do here is acknowledge and mask the interrupt and wakeup
- * the kernel thread.
- */
-static irqreturn_t handle_twl6030_pih(int irq, void *devid)
-{
- disable_irq_nosync(irq);
- complete(devid);
return IRQ_HANDLED;
}
@@ -351,7 +312,6 @@ int twl6030_init_irq(struct device *dev, int irq_num)
{
struct device_node *node = dev-of_node;
int nr_irqs, irq_base, irq_end;
- struct task_struct *task;
static struct irq_chip twl6030_irq_chip;
int status = 0;
int i;
@@ -396,36 +356,25 @@ int twl6030_init_irq(struct device *dev, int irq_num)
irq_set_chip_and_handler(i, twl6030_irq_chip,
handle_simple_irq);
irq_set_chip_data(i, (void *)irq_num);
+ irq_set_nested_thread(i, true);
activate_irq(i);
}
- dev_info(dev, PIH (irq %d) chaining IRQs %d..%d\n,
- irq_num, irq_base, irq_end);
+ dev_info(dev, PIH (irq %d) nested IRQs %d..%d\n,
+ irq_num, irq_base, irq_end);
/* install an irq handler to demultiplex the TWL6030 interrupt */
- init_completion(irq_event);
-
- status = request_irq(irq_num, handle_twl6030_pih, 0, TWL6030-PIH,
- irq_event);
+ status = request_threaded_irq(irq_num, NULL, twl6030_irq_thread,
+ IRQF_ONESHOT, TWL6030-PIH, NULL);
if (status 0) {
dev_err(dev, could not claim irq %d: %d\n, irq_num, status);
goto fail_irq;
}
- task = kthread_run(twl6030_irq_thread, (void *)irq_num, twl6030-irq);
- if (IS_ERR(task)) {
- dev_err(dev, could not create irq %d thread!\n, irq_num);
- status = PTR_ERR(task);
- goto fail_kthread;
- }
-
twl_irq = irq_num;
register_pm_notifier(twl6030_irq_pm_notifier_block);
return irq_base;
-fail_kthread:
- free_irq(irq_num, irq_event);
-
fail_irq:
for (i = irq_base; i irq_end; i++)
irq_set_chip_and_handler(i, NULL, NULL);
@@ -437,10 +386,13 @@ int twl6030_exit_irq(void)
{
unregister_pm_notifier(twl6030_irq_pm_notifier_block);
- if (twl6030_irq_base) {
+ if (!twl6030_irq_base) {
pr_err(twl6030: can't yet clean up IRQs?\n);
return -ENOSYS;
}
+
+ free_irq(twl_irq, NULL);
+
If request_threaded_irq() fails, isn't there a chance that
twl6030_irq_base will be allocated, but twl_irq will still be
undefined?
return 0;
}
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mfd: twl6030-irq: convert to use linear irq_domain
] = 0xFF;
@@ -346,8 +365,6 @@ int twl6030_init_irq(struct device *dev, int irq_num)
return status;
}
- twl6030_irq_base = irq_base;
-
/*
* install an irq handler for each of the modules;
* clone dummy irq_chip since PIH can't *do* anything
@@ -357,20 +374,18 @@ int twl6030_init_irq(struct device *dev, int irq_num)
twl6030_irq_chip.irq_set_type = NULL;
twl6030_irq_chip.irq_set_wake = twl6030_irq_set_wake;
- for (i = irq_base; i irq_end; i++) {
- irq_set_chip_and_handler(i, twl6030_irq_chip,
- handle_simple_irq);
- irq_set_chip_data(i, (void *)irq_num);
- irq_set_nested_thread(i, true);
- activate_irq(i);
+ irq_domain = irq_domain_add_linear(node, nr_irqs,
+twl6030_irq_domain_ops, NULL);
+ if (!irq_domain) {
+ dev_err(dev, Can't add irq_domain\n);
+ return -ENOMEM;
}
- dev_info(dev, PIH (irq %d) nested IRQs %d..%d\n,
- irq_num, irq_base, irq_end);
+ dev_info(dev, PIH (irq %d) nested IRQs\n, irq_num);
/* install an irq handler to demultiplex the TWL6030 interrupt */
status = request_threaded_irq(irq_num, NULL, twl6030_irq_thread,
- IRQF_ONESHOT, TWL6030-PIH, NULL);
+ IRQF_ONESHOT, TWL6030-PIH, irq_domain);
if (status 0) {
dev_err(dev, could not claim irq %d: %d\n, irq_num, status);
goto fail_irq;
@@ -378,26 +393,19 @@ int twl6030_init_irq(struct device *dev, int irq_num)
twl_irq = irq_num;
register_pm_notifier(twl6030_irq_pm_notifier_block);
- return irq_base;
+ return irq_num;
I think you need to change twl-core to now expect the total number of
IRQs rather than the base one now.
fail_irq:
- for (i = irq_base; i irq_end; i++)
- irq_set_chip_and_handler(i, NULL, NULL);
-
+ irq_domain_remove(irq_domain);
Why do you kill the irqdomain here, but not in exit()?
return status;
}
int twl6030_exit_irq(void)
{
- unregister_pm_notifier(twl6030_irq_pm_notifier_block);
-
- if (!twl6030_irq_base) {
- pr_err(twl6030: can't yet clean up IRQs?\n);
- return -ENOSYS;
+ if (twl_irq) {
+ unregister_pm_notifier(twl6030_irq_pm_notifier_block);
+ free_irq(twl_irq, NULL);
}
Ah yes, that's better.
-
- free_irq(twl_irq, NULL);
-
return 0;
}
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mfd: twl6030-irq: Add interrupt mapping table for the twl6032
); + return -EINVAL; + } + + irq_mapping_tbl = of_id-data; nr_irqs = TWL6030_NR_IRQS; -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: twl6030-irq: migrate to IRQ threaded handler
On Tue, 23 Jul 2013, Grygorii Strashko wrote:
From: Naga Venkata Srikanth V vnv.srika...@samsung.com
1) Removed request_irq() and replaced it with request_threaded_irq().
2) Removed generic_handle_irq() and replaced it with
handle_nested_irq().
Handling of these interrupts is nested, as we are handling an
interrupt (for e.g rtc, mmc1) when we are still servicing TWL irq.
3) Removed I2C read-retry logic for the case when twl_i2c_read() is
failed inside IRQ handler - there is no sense to do that, so just report
an error and return.
Signed-off-by: Naga Venkata Srikanth V vnv.srika...@samsung.com
Signed-off-by: Oleg_Kosheliev oleg.koshel...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 146
+++--
1 file changed, 49 insertions(+), 97 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
snip
+ status = request_threaded_irq(irq_num, NULL, twl6030_irq_thread,
+ IRQF_ONESHOT, TWL6030-PIH, NULL);
Oh, and please use managed resources for this: devm_*
if (status 0) {
dev_err(dev, could not claim irq %d: %d\n, irq_num, status);
goto fail_irq;
}
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: twl6030-irq: migrate to IRQ threaded handler
+ if (ret) {
+ pr_warn(%s: I2C error %d reading PIH ISR\n, __func__, ret);
Does the user really care which function we're returning from.
Would it be better if you replace '__func__' with the device name?
This module hasn't been converted to the device yet:(
(I mean interrupt-controller).
But I'm thinking about it as the next step :) and then It will be
absolutely reasonable change to replace pr_*() with dev_*() and
remove __func__.
I don't mean anything as compicated as that for 'this' patch. (NB: See my
comment in subsequent patches about creating a 'struct twl6030' where
you could store 'struct dev'.) In this patch I mean litterally
replacing %s: , with tw16030_irq: . Simples. :)
Now, the pointer on dev (in our case twl-core device) isn't passed
in IRQ handler, so It can't be used here.
Of course it can be done, but would it make code better?
My opinion - no.
+ if (sts.bytes[2] 0x10)
+ sts.bytes[2] |= 0x08;
- for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
- local_irq_disable();
- if (sts.int_sts 0x1) {
- int module_irq = twl6030_irq_base +
+ for (i = 0; sts.int_sts; sts.int_sts = 1, i++)
+ if (sts.int_sts 0x1) {
I'm a little confused by this. Where does sts.int_sts come from?
See my comment above, pls
Okay, that's my fault for not understanding unions properly as I've
never had to use one, but now I do, thanks.
@@ -437,10 +386,13 @@ int twl6030_exit_irq(void)
{
unregister_pm_notifier(twl6030_irq_pm_notifier_block);
- if (twl6030_irq_base) {
+ if (!twl6030_irq_base) {
pr_err(twl6030: can't yet clean up IRQs?\n);
return -ENOSYS;
}
+
+ free_irq(twl_irq, NULL);
+
If request_threaded_irq() fails, isn't there a chance that
twl6030_irq_base will be allocated, but twl_irq will still be
undefined?
Yes. A mess is here (historically:), thanks. Will use twl_irq
instead of twl6030_irq_base (I did it, actually, in patch [3]:).
Yes, I saw it. It would be better if you still fixed up this patch to
be correct though. Even if you break it out and add it as [PATCH 1/x].
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/22] ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3430-sdp.dts | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..281914e 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -84,15 +84,15 @@
label = bootloader-nor;
reg = 0 0x4;
};
- partition@0x4 {
+ partition@4 {
label = params-nor;
reg = 0x4 0x4;
};
- partition@0x8 {
+ partition@8 {
label = kernel-nor;
reg = 0x8 0x20;
};
- partition@0x28 {
+ partition@28 {
label = filesystem-nor;
reg = 0x24 0x7d8;
};
@@ -125,19 +125,19 @@
label = xloader-nand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-nand;
reg = 0x8 0x14;
};
- partition@0x1c {
+ partition@1c {
label = params-nand;
reg = 0x1c 0xc;
};
- partition@0x28 {
+ partition@28 {
label = kernel-nand;
reg = 0x28 0x50;
};
- partition@0x78 {
+ partition@78 {
label = filesystem-nand;
reg = 0x78 0x788;
};
@@ -170,19 +170,19 @@
label = xloader-onenand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-onenand;
reg = 0x8 0x4;
};
- partition@0xc {
+ partition@c {
label = params-onenand;
reg = 0xc 0x2;
};
- partition@0xe {
+ partition@e {
label = kernel-onenand;
reg = 0xe 0x20;
};
- partition@0x2e {
+ partition@2e {
label = filesystem-onenand;
reg = 0x2e 0xfd2;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/22] ARM: dts: Remove '0x's from OMAP4 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..45708e1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -56,7 +56,7 @@
cache-level = 2;
};
- local-timer@0x48240600 {
+ local-timer@48240600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x48240600 0x20;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_HIGH);
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/22] ARM: dts: Remove '0x's from OMAP3 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..16420ae 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,7 +111,7 @@
pinctrl-single,function-mask = 0x7f1f;
};
- omap3_pmx_wkup: pinmux@0x48002a00 {
+ omap3_pmx_wkup: pinmux@48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002a00 0x5c;
#address-cells = 1;
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/22] ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0030.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d0538..f628200 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -74,19 +74,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/22] ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0020.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..f7a8122 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -99,19 +99,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/22] ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
label = bootloader;
reg = 0 0x2;
};
- partition@0x2 {
+ partition@2 {
label = params;
reg = 0x2 0x2;
};
- partition@0x4 {
+ partition@4 {
label = kernel;
reg = 0x4 0x20;
};
- partition@0x24 {
+ partition@24 {
label = file-system;
reg = 0x24 0x3dc;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/22] ARM: dts: Remove '0x's from OMAP5 DTS file
Tony, Benoit,
Poke
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..be58604 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,7 +604,7 @@
ti,hwmods = wd_timer2;
};
- emif1: emif@0x4c00 {
+ emif1: emif@4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
phy-type= 2; /* DDR PHY type: Intelli PHY */
@@ -615,7 +615,7 @@
hw-caps-temp-alert;
};
- emif2: emif@0x4d00 {
+ emif2: emif@4d00 {
compatible = ti,emif-4d5;
ti,hwmods = emif2;
phy-type= 2; /* DDR PHY type: Intelli PHY */
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/22] ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
Looks like Benoit's new email address is bcous...@baylibre.com. Probably best for Benoit to pick these to avoid merge conflicts. Ah nice, thanks Tony. I've just applied the 7 following patches. Let me know if I missed something. 6b9fa1b ARM: dts: Remove '0x's from OMAP5 DTS file 79390b8 ARM: dts: Remove '0x's from OMAP4 DTS file dd60fef ARM: dts: Remove '0x's from OMAP3430 SDP DTS file bfef1cb ARM: dts: Remove '0x's from OMAP3 DTS file 5f547ac ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file 27939fc ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file 62eb4d1 ARM: dts: Remove '0x's from OMAP2420 H4 DTS file Nope, looks good. Thanks Benoit. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] typo fixes (coordiante - coordinate) in am335x
On Sat, 19 Oct 2013, Jan Lübbe wrote: On Wed, 2013-08-21 at 00:58 -0700, Tony Lindgren wrote: * Zubair Lutfullah zubair.lutful...@gmail.com [130715 08:33]: Did a grep for coordiante and replaced them all with coordinate. This applies to the mfd-next tree. This should be safe to apply via the MFD tree as a non-critical fix assuming the bootloaders are not yet using this: Acked-by: Tony Lindgren t...@atomide.com It seems this didn't get applied. It fixes the touchscreen on a BeagleBone black with the 7 LCD and we should avoid having people use the wrong binding. Samuel or Lee: Could you take this patch? This is the first time this patch has been sent to me. I need Dmitry's input (no pun intended) on how he's like to deal with this. At a bare minimum I'd like his Ack. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] typo fixes (coordiante - coordinate) in am335x
On Tue, 05 Nov 2013, Jan Lübbe wrote: On Tue, 2013-10-22 at 10:05 +0100, Lee Jones wrote: This is the first time this patch has been sent to me. I need Dmitry's input (no pun intended) on how he's like to deal with this. At a bare minimum I'd like his Ack. Is there anything I can do to push this forward? The earlier we get the typo fixed in the documentation, the less chance that someone will use it that way. I think you should sent it again, but this time Cc the Device Tree list, Dmitry and myself when you submit. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] typo fixes (coordiante - coordinate) in am335x
On Tue, 05 Nov 2013, Jan Lübbe wrote: On Tue, 2013-11-05 at 17:15 +, Lee Jones wrote: On Tue, 05 Nov 2013, Jan Lübbe wrote: On Tue, 2013-10-22 at 10:05 +0100, Lee Jones wrote: This is the first time this patch has been sent to me. I need Dmitry's input (no pun intended) on how he's like to deal with this. At a bare minimum I'd like his Ack. Is there anything I can do to push this forward? The earlier we get the typo fixed in the documentation, the less chance that someone will use it that way. I think you should sent it again, but this time Cc the Device Tree list, Dmitry and myself when you submit. The original patch was not from me. But sure, I can resend it. I'm not worried about who re-sends the patch. Just make sure whoever does sends in correctly with regards to the $SUBJECT line etc. The one on this patch looks odd. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
Since we still need to rely on a mix of device tree initialized
drivers and legacy platform data initialize drivers, let's fix
the passing of platform data to twl4030-gpio.
As the twl4030 GPIO is initialized by twl-core.c, we need to register
the auxdata for twl4030 GPIO in twl-core.c.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
Samuel Lee, I'd like to merge this fix via arm-soc tree if this looks
OK to you as I have other patches that depend on this.
---
drivers/mfd/twl-core.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 29473c2..d5b3dd8 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client)
return 0;
}
+static struct of_dev_auxdata twl_auxdata_lookup[] = {
+ OF_DEV_AUXDATA(ti,twl4030-gpio, 0, twl4030-gpio, NULL),
+ { /* sentinel */ },
+};
+
/* NOTE: This driver only handles a single twl4030/tps659x0 chip */
static int
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
}
- if (node)
- status = of_platform_populate(node, NULL, NULL, client-dev);
- else
+ if (node) {
+ if (pdata)
+ twl_auxdata_lookup[0].platform_data = pdata-gpio;
+ status = of_platform_populate(node, NULL, twl_auxdata_lookup,
+ client-dev);
+ } else {
status = add_children(pdata, irq_base, id-driver_data);
Why doesn't the TWL driver use the MFD framework for this stuff?
+ }
fail:
if (status 0)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 12/23] mfd: omap-usb-tll: raw read and write endian fix
On Sat, 16 Nov 2013, Taras Kondratiuk wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org --- drivers/mfd/omap-usb-tll.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 11/23] mfd: omap-usb-host: raw read and write endian fix
On Sat, 16 Nov 2013, Taras Kondratiuk wrote: From: Victor Kamensky victor.kamen...@linaro.org All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky victor.kamen...@linaro.org Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org --- drivers/mfd/omap-usb-host.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
+static struct of_dev_auxdata twl_auxdata_lookup[] = {
+ OF_DEV_AUXDATA(ti,twl4030-gpio, 0, twl4030-gpio, NULL),
+ { /* sentinel */ },
+};
+
/* NOTE: This driver only handles a single twl4030/tps659x0 chip */
static int
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
}
- if (node)
- status = of_platform_populate(node, NULL, NULL, client-dev);
- else
+ if (node) {
+ if (pdata)
+ twl_auxdata_lookup[0].platform_data = pdata-gpio;
+ status = of_platform_populate(node, NULL, twl_auxdata_lookup,
+ client-dev);
+ } else {
status = add_children(pdata, irq_base, id-driver_data);
Why doesn't the TWL driver use the MFD framework for this stuff?
that's reminiscent from years ago and, surely, needs to be fixed. Should
we gate $subject for that, though ? This has been in tree for quite a
few years already and Tony's patch is still a step forward, since most
omap3 platforms would break on DT-only without it.
I didn't say that I would reject the patch. I was just surprised to
see so much hand-rolling, as the MFD core code does much of it
automatically. This is the first time I've taken a look at this and it
seems to be quite the relic.
There are quite a few folks who could volunteer to fixing that after
Tony's patch is in (me included, although there could be better choices
hehe).
Well it's not doing any harm. I'll make a note to fix it myself if a)
no one has done so already and b) I manage to find some spare
time. The latter issue is less likely to be resolved. :)
Are you Acking this patch by the way?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
Are you Acking this patch by the way? If this looks acceptable to you guys, I'd like to merge this via my fixes branch this week with your acks if that works for you. That way I can base my omap legacy platform data removal patches on my fixes branch while keep things working for the drivers. Alternatively I can naturally base my legacy data removal on -rc2 too if this gets merged to mainline by then via the MFD tree. I can either send it up for the -rcs, or I can create an immutable branch for you to pull from. That way the patch can do in via ARM-SoC and MFD and we can let Git sort it out. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
On Mon, 18 Nov 2013, Tony Lindgren wrote: * Lee Jones lee.jo...@linaro.org [131118 11:10]: Are you Acking this patch by the way? If this looks acceptable to you guys, I'd like to merge this via my fixes branch this week with your acks if that works for you. That way I can base my omap legacy platform data removal patches on my fixes branch while keep things working for the drivers. Alternatively I can naturally base my legacy data removal on -rc2 too if this gets merged to mainline by then via the MFD tree. I can either send it up for the -rcs, or I can create an immutable branch for you to pull from. That way the patch can do in via ARM-SoC and MFD and we can let Git sort it out. OK great, I'd prefer an immutable branch that I can merge in too. Then you can bundle it with other MFD fixes for the -rc series and send it in when it suits you :) That's fine. It's 19:30 here now and I still have a shed load of debugging to do, so I'll deal with this tomorrow if it's all the same to you? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
On Mon, 18 Nov 2013, Tony Lindgren wrote: * Lee Jones lee.jo...@linaro.org [131118 11:10]: Are you Acking this patch by the way? If this looks acceptable to you guys, I'd like to merge this via my fixes branch this week with your acks if that works for you. That way I can base my omap legacy platform data removal patches on my fixes branch while keep things working for the drivers. Alternatively I can naturally base my legacy data removal on -rc2 too if this gets merged to mainline by then via the MFD tree. I can either send it up for the -rcs, or I can create an immutable branch for you to pull from. That way the patch can do in via ARM-SoC and MFD and we can let Git sort it out. OK great, I'd prefer an immutable branch that I can merge in too. Then you can bundle it with other MFD fixes for the -rc series and send it in when it suits you :) https://git.linaro.org/gitweb?p=people/ljones/mfd.git;a=shortlog;h=refs/heads/for-mfd-fixes Here Tony, you can take this one. I will simply apply my other fixes on top of it. The issue is, I will most likely have to rebase it on top of -rc1 prior to sending a request to Linus, so in that regard it's not exactly immutable. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
Here Tony, you can take this one. I will simply apply my other fixes on top of it. The issue is, I will most likely have to rebase it on top of -rc1 prior to sending a request to Linus, so in that regard it's not exactly immutable. Ignore the above. This is what you want: The following changes since commit 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52: Linux 3.12 (2013-11-03 15:41:51 -0800) are available in the git repository at: git://git.linaro.org/people/ljones/mfd.git tags/ib-tony for you to fetch changes up to f984370913d3ba5d13806cc8ac6fc26f8ebd1694: mfd: twl-core: Fix passing of platform data in the device tree case (2013-11-21 10:42:36 +) warning: refname 'ib-tony' is ambiguous. Immutable branch for Tony Lindgren Tony Lindgren (1): mfd: twl-core: Fix passing of platform data in the device tree case drivers/mfd/twl-core.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_LDOLN, pdata-ldoln,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_LDO2, pdata-ldo2,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_LDO4, pdata-ldo4,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_LDO3, pdata-ldo3,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_SMPS3, pdata-smps3,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_SMPS4, pdata-smps4,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- child = add_regulator(TWL6032_REG_VIO, pdata-vio6025,
- features);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- }
-
if (IS_ENABLED(CONFIG_CHARGER_TWL4030) pdata-bci
!(features (TPS_SUBSET | TWL5031))) {
child = add_child(TWL_MODULE_MAIN_CHARGE, twl4030_bci,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] mfd: menelaus: a few cleanups
Awesome, should I add your tested-by ? I also added a few extra patches on top which I'll send soon. When you next submit, can you capitalise the first character of the subject line after the final ':' also please, it will save me the trouble. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
Attn: Tony
Since currently nobody uses TWL603x platform data and all new
Hmm... when you say nobody, how did you come to this conclusion?
Without digging into it and probably not that relevant, it
appears there is some references to it in platform data still:
$ git grep twl603 -- arch/ | grep -v dts
arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers);
arch/arm/mach-omap2/omap4-common.c:static int
omap4_twl6030_hsmmc_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: irq =
twl6030_mmc_card_detect_config();
arch/arm/mach-omap2/omap4-common.c:
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
arch/arm/mach-omap2/omap4-common.c:static __init void
omap4_twl6030_hsmmc_set_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: pdata-init =
omap4_twl6030_hsmmc_late_init;
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap4-common.c:
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap_twl.c:static unsigned long
twl6030_vsel_to_uv(const u8 vsel)
arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned long
uv)
arch/arm/mach-omap2/omap_twl.c: if (uv twl6030_vsel_to_uv(0x39)) {
arch/arm/mach-omap2/omap_twl.c: __func__, uv,
twl6030_vsel_to_uv(0x39));
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
Looks like some misunderstanding is here. This patch *only* removes
platform data for TWL603x
which were used to create TWL sub-devices like regulators, adc's,
watchdogs, etc.
Previously it was set up in twl_common.c by omap4_pmic_init(), which was
called from board files
with specific pmic config.
Since now in Linux kernel 3.13 OMAP4 non-DT boot is not supported and all
OMAP4 board files
have been removed omap4_pmic_init() is never called and all TWL603x
sub-devices are created
from device tree data.
I'm not overly familiar with this driver (it looks like a big
historical mess to me), or the current state of the OMAP4 platform, so
I would like a second opinion on this.
Tony would you be kind enough to oblige?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
Since currently nobody uses TWL603x platform data and all new
Hmm... when you say nobody, how did you come to this conclusion?
Without digging into it and probably not that relevant, it
appears there is some references to it in platform data still:
$ git grep twl603 -- arch/ | grep -v dts
arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers);
arch/arm/mach-omap2/omap4-common.c:static int
omap4_twl6030_hsmmc_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: irq =
twl6030_mmc_card_detect_config();
arch/arm/mach-omap2/omap4-common.c:
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
arch/arm/mach-omap2/omap4-common.c:static __init void
omap4_twl6030_hsmmc_set_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: pdata-init =
omap4_twl6030_hsmmc_late_init;
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap4-common.c:
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap_twl.c:static unsigned long
twl6030_vsel_to_uv(const u8 vsel)
arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned
long
uv)
arch/arm/mach-omap2/omap_twl.c: if (uv twl6030_vsel_to_uv(0x39)) {
arch/arm/mach-omap2/omap_twl.c: __func__, uv,
twl6030_vsel_to_uv(0x39));
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
Looks like some misunderstanding is here. This patch *only* removes
platform data for TWL603x
which were used to create TWL sub-devices like regulators, adc's,
watchdogs, etc.
Previously it was set up in twl_common.c by omap4_pmic_init(), which was
called from board files
with specific pmic config.
Since now in Linux kernel 3.13 OMAP4 non-DT boot is not supported and all
OMAP4 board files
have been removed omap4_pmic_init() is never called and all TWL603x
sub-devices are created
from device tree data.
I'm not overly familiar with this driver (it looks like a big
historical mess to me), or the current state of the OMAP4 platform, so
I would like a second opinion on this.
Tony would you be kind enough to oblige?
We've moved omap4 to boot based on device tree only, so that legacy
platform data is no longer being used. It might be worth checking if
we do have bindings in place for all of that, or if some of it may
still be needed to be passed as auxdata while we wait for the bindings.
Ruslan, do you know the answer to these concerns?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
On Thu, 21 Nov 2013, Ruslan Ruslichenko wrote: Since currently nobody uses TWL603x platform data and all new users will supply it through device tree, handling of these data within twl-core will never be used, so remove it. Signed-off-by: Ruslan Ruslichenko ruslan.rusliche...@globallogic.com --- Tested on TI SDP/Tablet OMAP4460 board Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git commit 5e01dc7 Linux 3.12 drivers/mfd/twl-core.c | 198 - 1 file changed, 198 deletions(-) Okay, I'm suitably happy with yours and Tony's responses. Patch applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
The TPS65218 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- Over Temperature warning and Shut down.
This patch adds support for tps65218 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/tps65218.c | 281 +
include/linux/mfd/tps65218.h | 288
++
snip
+config MFD_TPS65218
+ tristate TI TPS65218 Power Management chips
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the TPS65218 series of
+ Power Management chips.
+ These include voltage regulators, gpio and other features
+ that are often used in portable devices.
Perhaps you should add a note that only the regulator component is
currently supported.
snip
new file mode 100644
index 000..8c61640
--- /dev/null
+++ b/drivers/mfd/tps65218.c
@@ -0,0 +1,281 @@
+/*
+ * TPS65218 chip family multi-function driver
Instead of calling it an MFD driver (is there such a thing?) I think
you should mention its true purpose, as per the datasheet.
snip
+static const struct of_device_id of_tps65218_match_table[] = {
+ { .compatible = ti,tps65218, },
+ { /* end */ }
I think the end comment is superfluous.
However, if you _really_ want to put something in there, I dislike
/* Sentinel */ the least.
+static int tps65218_probe(struct i2c_client *client,
+ const struct i2c_device_id *ids)
+{
snip
+ ret = of_platform_populate(client-dev.of_node, NULL, NULL,
+client-dev);
What are you trying to do here?
Register each regulator as a platform device?
snip
+static const struct i2c_device_id tps65218_id_table[] = {
+ {tps65218, TPS65218},
+};
This has a different structure to of_tps65218_match_table, please
ensure they're the same. I prefer spaces after '{' and before '}'.
snip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: DT bindings for TPS65218 PMIC
Add DT bindings for TPS65218 PMIC.
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 27
.../devicetree/bindings/regulator/tps65218.txt | 22
2 files changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..87cb7a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,27 @@
+The TPS65218 Integrated Power Management Chips.
+These chips are connected to an i2c bus.
I2C
+Required properties:
+- compatible : Must be ti,tps65218;
+- interrupts : This i2c device has an IRQ line connected to the main SoC
I2C
+- interrupt-controller : Since the tps65218 support several interrupts
support(s) (hosts?)
+ internally, it is considered as an interrupt controller cascaded to the
SoC.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller.
Phandle to ...
+Optional node:
node(s):
+- Child nodes contain in the tps65218.
+ It supports a number of features.
Please re-phase the above two sentences to something decipherable.
+ The children nodes will thus depend of the capability of the variant.
Please, go on ...
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps@24 {
+compatible = ti,tps65218;
+reg = 0x24;
+interrupt-controller;
+#interrupt-cells = 2;
+interrupt-parent = gic;
+};
Perhaps it would be better to centralise the documentation inclusive
of the regulator contingent. Or at least provide a _full_ example in
each document.
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..1ccf170
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,22 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1 LDO
Why aren't you using 'regulator-compatible'?
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+ xyz: regulator@0 {
Genuine question: Is the @0 meaningful?
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. Also use the full length of the provided buffer, which I believe is 72 chars, but happy to be correct on that one. It's certainly not 40 chars however. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: DT bindings for TPS65218 PMIC
+- interrupt-controller : Since the tps65218 support several interrupts support(s) (hosts?) Yes Supports multiple interrupts from the sub-modules. I think 'support' should be the plural 'supports'. snip Why aren't you using 'regulator-compatible'? I referred tps65217.txt the predecessors and used the compatible. I also referred twl-regulator.txt. That doesn't mean that they are correct/better. ;) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
+ ret = of_platform_populate(client-dev.of_node, NULL, NULL,
+ client-dev);
What are you trying to do here?
Register each regulator as a platform device?
Yeah. The probe will be called for every regulator separately.
So there are two schools of thought on this. One is that if you want
to do it that way you should use the MFD framework to do this for you.
There is no need to recreate functionality that already exists. The
other is that you shouldn't be doing this at all with regulators. Mark
likes the idea of having a single regulator controller node which
contains all of these individual regulator sub-nodes and you initiate
a single call to for_each_child_of_node() within the driver in order
to register them all.
snip
This has a different structure to of_tps65218_match_table, please
ensure they're the same. I prefer spaces after '{' and before '}'.
Ok. I will add a space after '{' and before '}'. Sorry I did not
follow tps65218_id_table being different than of_tps65218_match_table.
One is of the type of_device_id and the other i2c_device_id.
Shouldn't matter, it's just a formatting thing.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. example ? All of your commit messages. that macro just helps removing some extra ^- Sentences start with an uppercase character. line of code and hides ffs() calls. while at that, also fix a variable shadowing ^- Sentences start with an uppercase character. bug where 'int irq' was being redeclared inside inner loop while it was also argument to interrupt handler. --- 50 chars - Please use the full 72 char (or there abouts) width of the buffer. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. example ? All of your commit messages. that macro just helps removing some extra ^- Sentences start with an uppercase character. line of code and hides ffs() calls. while at that, also fix a variable shadowing ^- Sentences start with an uppercase character. bug where 'int irq' was being redeclared inside inner loop while it was also argument to interrupt handler. --- 50 chars - Please use the full 72 char (or there abouts) width of the buffer. I don't see any mention of punctuation problems, however. Also, you're not complaining about the content at all, which tells me those sentences aren't as incoherent as you claimed before. I didn't read them in any detail. I traversed through the patches and saw that the formatting looked obscure on all of them. As I have come to expect more of your submissions, I provided a generic reply detailing how I expected the commit logs to be. I wasn't insinuated that you failed to meet all of the criteria, but they definitely fell short of the mark. But fair enough, I'll fix those up and add Aaro's Tested-by Thank you. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 07/15] mfd: menelaus: Limit the usage of the_menelaus
Pass a menelaus_chip pointer as argument to most functions so we can minimize the usage of the global the_menelaus pointer. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 265 ++--- 1 file changed, 142 insertions(+), 123 deletions(-) How is this different from patch 6? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/15] mfd: menelaus: Pass menelaus_chip pointer to add/remove irq functions
On Mon, 09 Dec 2013, Felipe Balbi wrote: Those functions are static and can receive a menelaus_chip pointer very easily. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 57 ++ 1 file changed, 30 insertions(+), 27 deletions(-) Same here. I think this should be done in one fell swoop. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/15] mfd: menelaus: Pass menelaus_chip pointer to get/set voltage
On Mon, 09 Dec 2013, Felipe Balbi wrote: Those functions are static and can easily receive a menelaus_chip pointer argument. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 50 +++--- 1 file changed, 27 insertions(+), 23 deletions(-) I see a theme forming. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/15] mfd: menelaus: Pass menelaus_chip argument to menelaus - time helpers
On Mon, 09 Dec 2013, Felipe Balbi wrote: time_to_menelaus() and menelaus_to_time() are static and can easily receive a struct menelaus_chip pointer argument. After this patch, the_menelaus is only used on exported functions which are currently being used by board-n8x0.c. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) Same. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/15] mfd: menelaus: Start to use irqdomain
Introduce an irq_chip and irq_domain for menelaus driver. Following
patches will convert uses to traditional request_threaded_irq().
While at that, some better error handling had to be added, so we could
free irq descs we allocated.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 127
++---
snip
+ irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0,
+ irq_domain_simple_ops, m);
When will this driver become DT compliant?
I think you should use irq_domain_add_simple() to future proof
yourself a little.
+ m-irq_base = irq_base;
+
+ for (i = irq_base; i irq_base + MENELAUS_NR_IRQS; i++) {
+ irq_set_chip_data(i, m);
+ irq_set_chip_and_handler(i, menelaus_irq_chip,
+ handle_simple_irq);
+ irq_set_nested_thread(i, 1);
+ set_irq_flags(i, IRQF_VALID);
This assumes that this h/w only exists on ARM platforms. Is that true?
+ }
This is usually completed in an *_irq_map() operation call-back.
I can't see where you reverse this process either (usually *_irq_unmap())
snip
- mutex_init(m-lock);
-
This doesn't belong in this patch.
It should have been removed with the final use of the lock was.
snip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 15/15] mfd: menelaus: Use devm_request_threaded_irq()
On Mon, 09 Dec 2013, Felipe Balbi wrote: By using devm_request_threaded_irq() we can drop a few extra lines of code and rely on device managed resources layer to free our IRQ for us. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c index bffe978..b87c2bd 100644 --- a/drivers/mfd/menelaus.c +++ b/drivers/mfd/menelaus.c @@ -1271,8 +1271,8 @@ static int menelaus_probe(struct i2c_client *client, /* Set output buffer strengths */ menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73); - err = request_threaded_irq(client-irq, NULL, menelaus_irq, - IRQF_ONESHOT, DRIVER_NAME, m); + err = devm_request_threaded_irq(client-dev, client-irq, + NULL, menelaus_irq, IRQF_ONESHOT, DRIVER_NAME, m); No need for a separate patch here. Convert straight from request_irq() to devm_request_threaded_irq() in patch 3. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/15] mfd: menelaus: Convert to threaded irq
On Mon, 09 Dec 2013, Felipe Balbi wrote: We don't need that extra workqueue when we have generic threaded irq handlers support. This patch just moves over to threaded irqs and deletes the unnecessary workqueue. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 29 - 1 file changed, 4 insertions(+), 25 deletions(-) snip - err = request_irq(client-irq, menelaus_irq, 0, - DRIVER_NAME, menelaus); + err = request_threaded_irq(client-irq, NULL, menelaus_irq, + IRQF_ONESHOT, DRIVER_NAME, menelaus); devm_* managed resources please. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 15/15] mfd: menelaus: Use devm_request_threaded_irq()
On Tue, 10 Dec 2013, Felipe Balbi wrote: On Tue, Dec 10, 2013 at 09:30:42AM +, Lee Jones wrote: On Mon, 09 Dec 2013, Felipe Balbi wrote: By using devm_request_threaded_irq() we can drop a few extra lines of code and rely on device managed resources layer to free our IRQ for us. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c index bffe978..b87c2bd 100644 --- a/drivers/mfd/menelaus.c +++ b/drivers/mfd/menelaus.c @@ -1271,8 +1271,8 @@ static int menelaus_probe(struct i2c_client *client, /* Set output buffer strengths */ menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73); - err = request_threaded_irq(client-irq, NULL, menelaus_irq, - IRQF_ONESHOT, DRIVER_NAME, m); + err = devm_request_threaded_irq(client-dev, client-irq, + NULL, menelaus_irq, IRQF_ONESHOT, DRIVER_NAME, m); No need for a separate patch here. Convert straight from request_irq() to devm_request_threaded_irq() in patch 3. that would be 2 changes in a single patch. I think it's the right thing to do. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/15] mfd: menelaus: Start to use irqdomain
Introduce an irq_chip and irq_domain for menelaus driver. Following
patches will convert uses to traditional request_threaded_irq().
While at that, some better error handling had to be added, so we could
free irq descs we allocated.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 127
++---
snip
+ irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0,
+ irq_domain_simple_ops, m);
When will this driver become DT compliant?
when OMAP2 becomes DT-compliant. It still boots with legacy board-file +
platform_data.
Really? Tony, are there any plans to DT the platform?
Felipe, what did you think about using irq_domain_add_simple()?
+ m-irq_base = irq_base;
+
+ for (i = irq_base; i irq_base + MENELAUS_NR_IRQS; i++) {
+ irq_set_chip_data(i, m);
+ irq_set_chip_and_handler(i, menelaus_irq_chip,
+ handle_simple_irq);
+ irq_set_nested_thread(i, 1);
+ set_irq_flags(i, IRQF_VALID);
This assumes that this h/w only exists on ARM platforms. Is that true?
it was made *only* for Nokia to use on their ARM-only internet tablets.
If the IP is genuinely not reusable, them I'm fine with it.
I see that the Kconfig is setup in the correct way too, so we're good.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/15] mfd: menelaus: Pass menelaus_chip pointer to add/remove irq functions
On Tue, 10 Dec 2013, Felipe Balbi wrote: On Tue, Dec 10, 2013 at 09:00:21AM +, Lee Jones wrote: On Mon, 09 Dec 2013, Felipe Balbi wrote: Those functions are static and can receive a menelaus_chip pointer very easily. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 57 ++ 1 file changed, 30 insertions(+), 27 deletions(-) Same here. I think this should be done in one fell swoop. then it would become a much, much larger patch which would become a pain to review. If the patch was doing lots of different things then I'd be inclined to agree, but although large, the changes here are pretty trivial. I tend to break up patches based on; subsystem, file, device (for platform/dts adaptions) and functionality. Rather than just because the 'lines changed' count is large. Please squash them and I'll review it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/15] mfd: menelaus: Start to use irqdomain
On Tue, 10 Dec 2013, Tony Lindgren wrote: * Lee Jones lee.jo...@linaro.org [131210 10:39]: Introduce an irq_chip and irq_domain for menelaus driver. Following patches will convert uses to traditional request_threaded_irq(). While at that, some better error handling had to be added, so we could free irq descs we allocated. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 127 ++--- snip + irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0, + irq_domain_simple_ops, m); When will this driver become DT compliant? when OMAP2 becomes DT-compliant. It still boots with legacy board-file + platform_data. Really? Tony, are there any plans to DT the platform? Yeah and what Felipe is doing here is an important step towards that. We'll be booting omap2 in DT only mode with v3.14 Okay, sounds good. Thanks for the clarification. but we still need to rely on some pdata quirks at least for the MMC because Menelaus does not provide the needed regulator phandles for the .dts files for the driver to use. I'll take your word for it. :) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 07/15] mfd: menelaus: Limit the usage of the_menelaus
On Tue, 10 Dec 2013, Felipe Balbi wrote: On Tue, Dec 10, 2013 at 08:57:01AM +, Lee Jones wrote: Pass a menelaus_chip pointer as argument to most functions so we can minimize the usage of the global the_menelaus pointer. Tested-by: Aaro Koskinen aaro.koski...@iki.fi Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/mfd/menelaus.c | 265 ++--- 1 file changed, 142 insertions(+), 123 deletions(-) How is this different from patch 6? have you read the patch ? patch 6 converts *only* enable/disable irq functions. Well it actually converts menelaus_ack_irq() too, but that's not the point I was making. I can see that the 'code' is different, but the functionality of the patch is the same i.e. converting functions to pass around the menelaus_chip pointer for eradication of the_menelaus global pointer. I'm not concerned about the 'lines changed' count. The change your making is trivial, thus there is no requirement to split unnecessarily over 5 patches. Please squash them into a single functionality patch. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
Are you planning on re-submitting this patch-set anytime soon? I thought Tony said it was important? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] mfd: menelaus: Start to use irqdomain
On Mon, 16 Dec 2013, Felipe Balbi wrote:
Introduce an irq_chip and irq_domain for menelaus driver. Following
patches will convert uses to traditional request_threaded_irq().
While at that, some better error handling had to be added, so we could
free irq descs we allocated.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 123
+++--
1 file changed, 119 insertions(+), 4 deletions(-)
snip
+static void menelaus_irq_ack(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
Shoudn't this now be?
int irq = data-hwirq;
+ if (irq 7) {
+ m-ack2 |= BIT(irq);
+ m-ack2_pending = true;
+ } else {
+ m-ack1 |= BIT(irq);
+ m-ack1_pending = true;
+ }
+}
+
+static void menelaus_irq_mask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
Same for here, and all the others.
snip
+ irq_domain_add_legacy(node, MENELAUS_NR_IRQS, irq_base, 0,
+ irq_domain_simple_ops, m);
Please use irq_domain_add_simple() here.
+ m-irq_base = irq_base;
I don't think you need this.
+ for (i = irq_base; i irq_base + MENELAUS_NR_IRQS; i++) {
+ irq_set_chip_data(i, m);
+ irq_set_chip_and_handler(i, menelaus_irq_chip,
+ handle_simple_irq);
+ irq_set_nested_thread(i, 1);
+ set_irq_flags(i, IRQF_VALID);
+ }
You should put this in the .map() operation and the reverse in .unmap().
fail:
+ irq_free_descs(irq_base, MENELAUS_NR_IRQS);
I don't think you need to do this.
static int menelaus_remove(struct i2c_client *client)
{
+ struct menelaus_chip*m = i2c_get_clientdata(client);
+
+ irq_free_descs(m-irq_base, MENELAUS_NR_IRQS);
Nor here.
the_menelaus = NULL;
Shouldn't this have been removed in patch 6?
return 0;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mfd: menelaus: Switch all children to threaded_irq
Now that we have our own irq_chip, all children can use traditional request_threaded_irq(). Is it possible to convert these to managed resources (*_devm)? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.9+
---
drivers/mfd/omap-usb-tll.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0d946ae1..248004c 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -346,7 +346,9 @@ int omap_tll_init(struct usbhs_omap_platform_data *pdata)
for (i = 0; i tll-nch; i++)
needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
This is pretty ugly. Can't you move it above the spin_lock() instead?
snip
tll = dev_get_drvdata(tll_dev);
+ spin_unlock(tll_lock);
pm_runtime_get_sync(tll_dev);
+ spin_lock(tll_lock);
Same here?
for (i = 0; i tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
@@ -438,7 +441,6 @@ int omap_tll_enable(struct usbhs_omap_platform_data
*pdata)
}
spin_unlock(tll_lock);
-
This doesn't belong in this patch and is now inconsistent with the
other functions in the driver.
return 0;
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
@@ -464,9 +466,8 @@ int omap_tll_disable(struct usbhs_omap_platform_data
*pdata)
}
}
- pm_runtime_put_sync(tll_dev);
-
spin_unlock(tll_lock);
+ pm_runtime_put_sync(tll_dev);
return 0;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while calling them. This patch prevents a BUG() during system suspend when CONFIG_DEBUG_ATOMIC_SLEEP is enabled. Bug is present in Kernel versions v3.9 onwards. Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Tested-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: sta...@vger.kernel.org # 3.9+ --- drivers/mfd/omap-usb-tll.c | 36 1 file changed, 12 insertions(+), 24 deletions(-) Patch looks good to me now. Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/9] mfd: omap-usb-host: Update DT clock binding information
On Thu, 09 Jan 2014, Roger Quadros wrote: The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. Use clock names as per function for reference clocks. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ drivers/mfd/omap-usb-host.c| 6 +++--- 2 files changed, 26 insertions(+), 3 deletions(-) Please don't mix up binding changes with code ones. Separate patch please. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/9] mfd: omap-usb-host: Use resource managed clk_get()
Use devm_clk_get() instead of clk_get(). CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 81 + 1 file changed, 16 insertions(+), 65 deletions(-) Nice clean up. Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/9] mfd: omap-usb-host: Get clocks based on hardware revision
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 93
+++--
1 file changed, 64 insertions(+), 29 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1c9bca2..7202cc6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -92,7 +92,6 @@
#define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL)
#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
-
Sneaky! ;)
struct usbhs_hcd_omap {
int nports;
struct clk **utmi_clk;
@@ -665,22 +664,41 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-EINVAL);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-EINVAL);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-EINVAL);
I don't think this is the correct error code.
-EINVAL means 'invalid parameter'.
You probably want -ENODEV or -ENOSYS ('function not implemented'
probably isn't ideal either tbh, but you get the idea). Perhaps you
can set them as NULL and check for IS_ERR_OR_NULL() instead?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/9] mfd: omap-usb-host: Get clocks based on hardware revision
On Fri, 10 Jan 2014, Arnd Bergmann wrote:
On Friday 10 January 2014, Lee Jones wrote:
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-EINVAL);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-EINVAL);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-EINVAL);
I don't think this is the correct error code.
-EINVAL means 'invalid parameter'.
You probably want -ENODEV or -ENOSYS ('function not implemented'
probably isn't ideal either tbh, but you get the idea). Perhaps you
can set them as NULL and check for IS_ERR_OR_NULL() instead?
I think ENODEV is ok here, I'd much prefer this over IS_ERR_OR_NULL().
Sounds good to me.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 00/10] USB Host support for OMAP5 uEVM (for 3.14)
This patchset brings up USB Host ports and Ethernet port on the OMAP5 uEVM board. I'd keep hold of this and send it out again when the merge-window is closed. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
The TPS65218 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Over Temperature warning and Shut down. This patch adds support for tps65218 mfd device. At this time only the regulator functionality is made available. Signed-off-by: Keerthy j-keer...@ti.com --- drivers/mfd/Kconfig | 15 +++ drivers/mfd/Makefile |1 + drivers/mfd/tps65218.c | 281 + How much different is the TPS65218 to all the other TPS drivers? drivers/mfd/tps6105x.c drivers/mfd/tps65010.c drivers/mfd/tps6507x.c drivers/mfd/tps65090.c drivers/mfd/tps65217.c drivers/mfd/tps6586x.c drivers/mfd/tps65910.c drivers/mfd/tps65911-comparator.c drivers/mfd/tps65912-core.c drivers/mfd/tps65912-i2c.c drivers/mfd/tps65912-irq.c drivers/mfd/tps65912-spi.c drivers/mfd/tps80031.c Perhaps some consolidating might be in order? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
On Thu, 06 Feb 2014, Keerthy wrote: The TPS65218 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Over Temperature warning and Shut down. This patch adds support for tps65218 mfd device. At this time only the regulator functionality is made available. Signed-off-by: Keerthy j-keer...@ti.com --- drivers/mfd/Kconfig | 15 +++ drivers/mfd/Makefile |1 + drivers/mfd/tps65218.c | 281 + include/linux/mfd/tps65218.h | 284 ++ 4 files changed, 581 insertions(+) create mode 100644 drivers/mfd/tps65218.c create mode 100644 include/linux/mfd/tps65218.h Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 01/12] mfd: omap-usb-host: Use resource managed clk_get()
Use devm_clk_get() instead of clk_get(). CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Lee Jones lee.jo...@linaro.org --- drivers/mfd/omap-usb-host.c | 81 + 1 file changed, 16 insertions(+), 65 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
