Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131010 09:19]: On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. If the rearm() function is calling this _reconfigure_io_chain my comments on the fact that this is something that should be handled by the pin control driver still apply I think Yes, except that the reconfigure_io_chain registers are in the PRM module, not in the SCM module where the pinctrl registers are.. And that shared PRM interrupt is used mostly for the internal domain wake-ups, so we should keep that in the PRM driver. That depends. One-iorange-equals-one-driver is a fallacy, especially given that MFD for memory-mapped things exist for a reason. What the pin control driver should do is control the pins. Whether the registers are spread out in the entire IO-memory does not matter. We did have one system which placed the IO-muxing together with each peripheral (!) and I did still want that to be handled by a single pinctrl driver picking out windows to all these IO-ranges. Things like the PRM which has (my guess) a gazillion registers related to its deep-core SoC stuff should be handled by things like drivers/mfd/syscon.c, which means it is dead simple for some other driver using just this one register in that range to get a handle at it and poke it using syscon_node_to_regmap() (just derference an ampersand ref) syscon_regmap_lookup_by_compatible() (use a compatible string) all returning a regmap * that you can use to poke these registers. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? The general idea is however that large monolitic drivers for a certain IO-range such as arch/arm/mach-omap2/prm3xxx.c doesn't scale - we saw this with the Ux500 PRCMU driver in mfd/* to the point that our patches to extend it were NACK:ed until we refactor it. This stuff in mach-omap2 is in the same bad design pattern, and need to get out of it. The approach chosen for the Ux500 PRCMU was to distribute out the driver into the places where it's actually used, like the clock driver etc. The accessor functions to do some stuff over in the PRCMU was just adding a layer of cruft. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131011 03:40]: On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? Uhh, let's not go there.. The resource availability needs to be handled transparently in regmap code and the reg provider hardware module driver using runtime PM. OK we can surely discuss this with broonie, it makes sense to have regmap be able to do its deed transparently. Yours, Linus Walleij -- 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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
On Fri, Oct 11, 2013 at 6:13 PM, Roger Quadros rog...@ti.com wrote: On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). Signed-off-by: Roger Quadros rog...@ti.com If Tony needs to apply this with the other patches: Acked-by. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] gpio/omap: use gpiolib API to mark a GPIO used as an IRQ
On Wed, Oct 16, 2013 at 2:47 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The OMAP GPIO driver keeps track about GPIO pins that are used as IRQ lines for two reasons: 1) To prevent GPIO banks to be disabled while one of their GPIO pins are only used as an interrupt line. 2) To not allow another caller to set the GPIO pin as output. Now gpiolib has an API to mark GPIO pins as used as IRQ lines so the GPIO core only allows to set as output GPIO pins not tied to an IRQ. So there is no need to have custom code for 2). The IRQ usage still has to be maintained locally for 1) though. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Patch applied. I had to merge in v3.12-rc4 to get the dependency fixes, so I guess you did something similar when developing this... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On Tue, Oct 22, 2013 at 3:01 PM, Sebastian Reichel s...@debian.org wrote: This patch moves the handling of the chip's enable pin from the board code into the driver. It also updates all board-code files using the driver to incorporate this change. This is needed for device tree support of the enable pin. Signed-off-by: Sebastian Reichel s...@debian.org Looks good to me. Acked-by: Linus Walleij linus.wall...@linaro.org BTW: should we disable the GPIO when remove()ing the module? This is a topic of another patch but... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] leds: lp55xx: handle enable pin in driver
On Tue, Oct 22, 2013 at 6:57 PM, Linus Walleij linus.wall...@linaro.org wrote: BTW: should we disable the GPIO when remove()ing the module? This is a topic of another patch but... Bah forget this stupid comment, I misread it, obviously you're doing this. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/11] Embeddable Position Independent Executable
On Tue, Sep 17, 2013 at 2:43 PM, Russ Dill russ.d...@ti.com wrote: This patch adds support for and demonstrates the usage of an embedded position independent executable (PIE). The goal is to allow the use of C code in situations where carefully written position independent assembly was previously required. This is perfectly applicable to the ARM TCM memory as well. Currently we have arch/arm/kernel/tcm.c and related extensions to kernel/vmlinux.kds.S, which enables us to tag some certain code to be compiled into TCM memory which we map statically to 0xfffe thru 0xfffe, but this is a better approach, especially nice since it is the solution to the multiplatform situation, as we need to select to copy code into that memory only on the specific target. I'll try to have a deeper look at this, please keep me on CC for this series. Yours, Linus Walleij -- 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 4/4] ASoC: RX-51: Add DT support to sound driver
On Sun, Oct 27, 2013 at 2:24 PM, Sebastian Reichel s...@debian.org wrote: +- eci-sw-gpio: GPIO for ECI SW +- speaker-amp-gpio: GPIO for Speaker Amp Can you please spell out the acronyms? ECI? SW? Amp? I guess SW=switch, Amp=amplifier, but ECI beats me. Yours, Linus Walleij -- 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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
On Fri, Oct 11, 2013 at 7:23 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131011 09:27]: On Fri, Oct 11, 2013 at 6:13 PM, Roger Quadros rog...@ti.com wrote: On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). Signed-off-by: Roger Quadros rog...@ti.com If Tony needs to apply this with the other patches: Acked-by. Just replied with a slightly modified version of Roger's patch suggesting you pull in the signed tag I posted for you yesterday and then you can pick up Roger's fix into the pinctrl tree :) Hm now that I go over these old mails in my inbox I start to worry that I missed something here, I have no memory of pulling a tag for OMAP... is this all in the state it needs to be for OMAP? Yours, Linus Walleij -- 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 5/8] gpio: twl4030: Fix regression for twl gpio output
On Thu, Nov 14, 2013 at 3:35 AM, Tony Lindgren t...@atomide.com wrote: Commit c111feabe2e2 (gpio: twl4030: Cache the direction and output states in private data) improved things in general, but caused a regression for setting the GPIO output direction. The change reorganized twl_direction_out() and twl_set() and swapped the function names around in the process. While doing that, a bug got introduced that's not obvious while reading the patch as it appears as no change to the code. The bug is we now call function twl4030_set_gpio_dataout() twice in both twl_direction_out() and twl_set(). Instead, we should first call twl_direction_out() in twl_direction_out() followed by twl4030_set_gpio_dataout() in twl_set(). This regression probably has gone unnoticed for a long time as the bootloader may have set the GPIO direction properly in many cases. This fixes at least the LCD panel not turning on omap3 LDP for example. Cc: Linus Walleij linus.wall...@linaro.org Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: linux-g...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- If this looks OK, I'd like to merge this as a fix via arm-soc tree along with the other patches in this series as my later patches depend on patches in this series. Sure: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 6/8] gpio: twl4030: Fix passing of pdata in the device tree case
On Mon, Nov 18, 2013 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [131113 18:37]: We still have some legacy code needing the callback functions that won't work properly without platform data. To use platform data for twl4030-gpio, we need to not trash the possible data. Cc: Linus Walleij linus.wall...@linaro.org Cc: linux-g...@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- If this looks OK, I'd like to merge this as a fix via arm-soc tree along with the other patches in this series as my later patches depend on patches in this series. Here's this one with a fix from Fengguang Wu to use struct assignment instead of memcpy folded in. Looks allright: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP
On Thu, Nov 14, 2013 at 1:18 PM, Sricharan R r.sricha...@ti.com wrote: The minimal crossbar driver to track and allocate free GIC lines and configure the crossbar is added here, along with the DT bindings. V4: Addressed a couple of comments and split the DTS file updates in to a separate series. I'm pretty happy with the work and effort put into this now it's looking real elegant. FWIW: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
On Thu, Nov 14, 2013 at 7:24 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [131112 11:57]: The fix from Roger is still missing. You can go ahead and queue it, or if you prefer me to do it I can add it to my fixes. Actually Linus, I'll queue this with your ack as the interrupts-extended property is now merged in and I can also enable some minimal wake-up events for omap3. OK thanks for the heads-up, go ahead. Yours, Linus Walleij -- 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 01/23] gpio/omap: raw read and write endian fix
On Sat, Nov 16, 2013 at 1:01 AM, Taras Kondratiuk taras.kondrat...@linaro.org 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 Since I generally just dislike __raw accessors I went and applied this. If it collides with any of Tony's fixup work I might need to take the patch out again, no big deal. Some ACKs would be nice, but unless there are major objections this stays merged. Yours, Linus Walleij -- 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] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
On Tue, Nov 26, 2013 at 11:46 PM, Chao Xu caesarxuc...@gmail.com wrote: From: Felipe Balbi ba...@ti.com try to keep gpio block suspended as much as possible. Tested with pandaboard and a sysfs exported gpio. Signed-off-by: Felipe Balbi balbi at ti.com [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision check to enable aggressive pm_runtime on OMAP4-only. Because am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. Tested on Pandaboard rev A2.] Signed-off-by: Chao Xu caesarxuc...@gmail.com I'd like Tony and/or Kevin to have a look at this from a PM point of view so I get some confirmation from the core maintainers that this is the way forward. Yours, Linus Walleij -- 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/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu caesarxuc...@gmail.com wrote: From: Felipe Balbi ba...@ti.com try to keep gpio block suspended as much as possible. Tested with pandaboard and a sysfs exported gpio. Signed-off-by: Felipe Balbi balbi at ti.com [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision check to enable aggressive pm_runtime on OMAP4-only. Because am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. Tested on Pandaboard rev A2.] Signed-off-by: Chao Xu caesarxuc...@gmail.com Kevin/Santosh: you're maintainers for this driver, can you ACK/NACK this patch? Yours, Linus Walleij -- 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 5/8] gpio: twl4030: Fix regression for twl gpio output
On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros rog...@ti.com wrote: (...) This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2. As one of the LED GPO is used for USB host on beagleboard, it will cause failure of USB host probe. (...) Below is a proposed fix for this. Roger, Tony: what happened with this? Have you hashed this out? I ACK Roger's fixup too if that needs to be merged into the OMAP tree. Yours, Linus Walleij -- 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 1/1] gpio: twl4030: Fix regression for twl gpio LED output
On Thu, Dec 5, 2013 at 10:23 AM, Roger Quadros rog...@ti.com wrote: Commit 0b2aa8be introduced a regression that causes failure in setting LED GPO direction to OUT. This causes USB host probe failures for Beagleboard C4. [2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests probe deferral [2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22 [2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register regulator: -22 [2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with error -22 direction_out/direction_in must return 0 if the operation succeeded. Also, don't update direction flag and output data if twl4030_set_gpio_direction() failed inside twl_direction_out(); Signed-off-by: Roger Quadros rog...@ti.com Patch applied for fixes with Tony's ACK. Thanks! Linus Walleij -- 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 5/8] gpio: twl4030: Fix regression for twl gpio output
On Mon, Dec 9, 2013 at 6:10 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131209 05:10]: On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros rog...@ti.com wrote: (...) This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2. As one of the LED GPO is used for USB host on beagleboard, it will cause failure of USB host probe. (...) Below is a proposed fix for this. Roger, Tony: what happened with this? Have you hashed this out? I ACK Roger's fixup too if that needs to be merged into the OMAP tree. There's an updated version from Roger posted that I acked: [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output http://lkml.org/lkml/2013/12/5/65 I also commented on the dependencies there, but basically you can pick it up unless you want me to. Should be cc stable as well. OK I have picked this now, I'll add a CC to stable. Yours, Linus Walleij -- 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/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu caesarxuc...@gmail.com wrote: From: Felipe Balbi ba...@ti.com try to keep gpio block suspended as much as possible. Tested with pandaboard and a sysfs exported gpio. Signed-off-by: Felipe Balbi balbi at ti.com [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision check to enable aggressive pm_runtime on OMAP4-only. Because am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. Tested on Pandaboard rev A2.] Signed-off-by: Chao Xu caesarxuc...@gmail.com --- changes since v2: *add wrapper function to avoid 'is_aggressive_pm' check everywhere, as suggested by Santosh Shilimkar *fix format issue in commit log I'm dropping this until you convince Kevin/Tony that this is the way to go. One thing caught my eye, you add: +static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank) +static void _aggressive_pm_runtime_put(struct gpio_bank *bank) (..) Then everywhere: + _aggressive_pm_runtime_get_sync(bank); (...) + _aggressive_pm_runtime_put(bank); Aggressive, argh, runtime PM is agressive by definition. If you want to switch this on and off use the compile option to enable/disable runtime PM altogether and do not wrap it like this. Yours, Linus Walleij -- 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/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
On Thu, Dec 12, 2013 at 7:28 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Dec 12, 2013 at 07:19:35PM +0100, Linus Walleij wrote: One thing caught my eye, you add: +static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank) +static void _aggressive_pm_runtime_put(struct gpio_bank *bank) (..) Then everywhere: + _aggressive_pm_runtime_get_sync(bank); (...) + _aggressive_pm_runtime_put(bank); Aggressive, argh, runtime PM is agressive by definition. If you want to switch this on and off use the compile option to enable/disable runtime PM altogether and do not wrap it like this. heh, OMAP doesn't work without pm_runtime. Hm then maybe that needs to be fixed ... or the runtime PM people need to be convinced to support different levels of aggressiveness in the core? Yours, Linus Walleij -- 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: [RFCv4 06/11] misc: Introduce Nokia CMT driver
On Mon, Dec 16, 2013 at 12:27 AM, Sebastian Reichel s...@debian.org wrote:
Add driver handling GPIO pins of Nokia modems. The
driver provides reset notifications, so that SSI
clients can subscribe to them easily.
Signed-off-by: Sebastian Reichel s...@debian.org
If the driver provides reset notifications, should it rather be
in drivers/reset?
I'm thinking of a generic GPIO reset driver with a generic
notification mechanism, which seems to be what this is.
I.e. it doesn't look device-specific at all, just like some
generic glue code that could be useful to many such
scenarios.
+config NOKIA_CMT
+ tristate Enable CMT support
+ help
+ If you say Y here, you will enable CMT support.
+
+ If unsure, say Y, or else you will not be able to use the CMT.
None of this explains what this driver actually does and what
CMT means, so please rewrite this a bit to be more helpful.
The way it is written it could as well say enable FOO support.
+++ b/drivers/misc/nokia-cmt.c
@@ -0,0 +1,298 @@
+/*
+ * CMT support.
So CMT = ...?
+/**
+ * struct cmt_device - CMT device data
+ * @cmt_rst_ind_tasklet: Bottom half for CMT reset line events
+ * @cmt_rst_ind_irq: IRQ number of the CMT reset line
+ * @n_head: List of notifiers registered to get CMT events
+ * @node: Link on the list of available CMTs
+ * @device: Reference to the CMT platform device
+ */
+struct cmt_device {
+ struct tasklet_struct cmt_rst_ind_tasklet;
+ unsigned intcmt_rst_ind_irq;
+ struct atomic_notifier_head n_head;
+ struct list_headnode;
+ struct device *device;
+ struct cmt_gpio *gpios;
+ int gpio_amount;
+};
The kerneldoc and and the struct are not in sync. Look
this over.
+static LIST_HEAD(cmt_list);/* List of CMT devices */
(...)
+struct cmt_device *cmt_get(const char *name)
+{
+ struct cmt_device *p, *cmt = ERR_PTR(-ENODEV);
+
+ list_for_each_entry(p, cmt_list, node)
+ if (strcmp(name, dev_name(p-device)) == 0) {
+ cmt = p;
+ break;
+ }
+
+ return cmt;
+}
+EXPORT_SYMBOL_GPL(cmt_get);
Is this driver used on non-DT platforms, or can we skip this
struct device * referencing altogether?
I would feel better if this driver looked more like
drivers/mfd/syscon.c
+static irqreturn_t cmt_rst_ind_isr(int irq, void *cmtdev)
+{
+ struct cmt_device *cmt = (struct cmt_device *)cmtdev;
+
+ tasklet_schedule(cmt-cmt_rst_ind_tasklet);
+
+ return IRQ_HANDLED;
+}
Why are you using a tasklet rather than a work
for this?
Yours,
Linus Walleij
--
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: [RFCv4 06/11] misc: Introduce Nokia CMT driver
On Mon, Dec 16, 2013 at 1:15 PM, Sebastian Reichel s...@debian.org wrote:
On Mon, Dec 16, 2013 at 10:48:06AM +0100, Linus Walleij wrote:
I.e. it doesn't look device-specific at all, just like some
generic glue code that could be useful to many such
scenarios.
I like the idea.
Probably the remaining gpio exporting code can be converted into
some generic gpio-sysfs-export driver as well.
I am very reluctant in letting device trees specify exports of GPIOs
to userspace, not so much because it's Linux-specific but for
the fact that people are doing things in userspace that should not
be done in userspace.
Last time it was proposed I asked to the specific usecase,
exactly why userspace needed this handle on a physical
GPIO line, and why it can't use another userspace interface
(example: leds, keys etc.)
What do you think about the following?
/*
* driver, which provides generic reset notifications
*/
cmt_reset: reset-notifier {
compatible = linux,reset-notification;
interrupts = gpio;
};
Looks good to me.
/*
* driver, which exports the specified gpios in sysfs with the
* supplied names. The device will be named according to the
* label
*/
cmt_gpios: gpio-sysfs-export {
compatible = linux,gpio-sysfs-export;
label = nokia-cmt;
gpios = A, B, ...;
gpio-names = A, B, ...;
};
Please follow the discussion on this topic:
http://marc.info/?l=linux-gpiom=138201170431416w=2
Why are you using a tasklet rather than a work
for this?
No particular reason. I just took this over from Nokia's code.
Can you try to use a work instead?
Yours,
Linus Walleij
--
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: Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver
On Wed, Dec 18, 2013 at 12:25 AM, Sebastian Reichel s...@ring0.de wrote: I had a look at both ofono's and freesmartphone.org's implementation for the GPIO handling and both implementations are very similar. I think it should be possible to move the state machine described in [0] into the kernel and provide a simple sysfs/uevent interface. I was thinking of something like /sys/devices/platform/nokia-cmt/state, which accepts enable, disable and reset as input and outputs the current state. [0] https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c Yes this looks like kernel code shoehorned into userspace. As it deals with suspending/resuming hardware for example, and that is something the kernel needs to coordinate and do uniformly across all devices (IMO). A while back Arun Murthy was working on creating an embedded modem subsystem but the development stopped. However such a subsystem is a generic problem of general interest and this would be one of the candidates for drivers/modem I think. Sadly creating it may be a lot of work, I don't know exactly. http://marc.info/?l=linux-kernelm=135027904405680w=2 Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] gpio: add GPIO hogging mechanism
On Mon, Dec 30, 2013 at 10:48 AM, boris brezillon b.brezil...@overkiz.com wrote: On 19/12/2013 19:22, Felipe Balbi wrote: that's quite a weird argument from Linus W, considering you _do_ have a discrete mux on the board. We have quite a few of such crazy scenarios here at TI and we were going to send a pinctrl-gpio driver. Hm I'm all in the blue as to what a pinctrl-gpio driver is ... I'm confused :-) If that's not acceptable, then I suppose there is no way to boot from NAND on a board where NAND signals go through a discrete mux where the select signal is a GPIO pin. One problem I have is that I still don't really understand if this is a pin mux, i.e. changing the connection to a certain device onto some actual *PIN* or just some other mux muxing some certain line from one silicon block to another. Linus, tell me if I'm wrong, but I think, the pinctrl-gpio is the right way to solve the at91rm9200ek board use case. I don't know, because I don't know exactly what you mean by pinctrl-gpio. Yours, Linus Walleij -- 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] power_supply: Introduce PSE compliant algorithm
On Wed, Feb 26, 2014 at 3:54 AM, Jenny Tc jenny...@intel.com wrote: The idea is to allow pluggable charging algorithms. Currently we have only one charging algorithm proposed, but can have other charging algorithms (like pulse charging, rule based charging etc.). Based on the platform need, the algorithms can be selected. So this should be a user configurable option. I can add more explanation on when to select this option. Do you see a generic framework for pluggable algorithms on an abstracted level, so that it could be used for the CC/CV charging, measurement and temperature check algorithm that is found in e.g. drivers/power/abx500_chargalg.c drivers/power/ab8500_charger.c etc, or do you envision a set of pluggable algorithms for this one hardware? I'm asking because these drivers are a massive set of code and we may need to start to abstract out and define library functions and frameworks already now before it becomes impossible to contain. Yours, Linus Walleij -- 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] power_supply: Introduce generic psy charging driver
power_supply_register_charger(struct power_supply_charger *psyc);
+extern int power_supply_unregister_charger(struct power_supply_charger
*psyc);
+extern int power_supply_register_charging_algo(struct psy_charging_algo *);
+extern int power_supply_unregister_charging_algo(struct psy_charging_algo *);
+extern int psy_get_battery_prop(struct psy_batt_chrg_prof *batt_prop);
+extern void psy_battery_prop_changed(int battery_conn_stat,
+ struct psy_batt_chrg_prof *batt_prop);
+
+#else
+
+static int power_supply_register_charger(struct power_supply_charger *psyc)
+{ return 0; }
+static int power_supply_unregister_charger(struct power_supply_charger
*psyc)
+{ return 0; }
+static int power_supply_register_charging_algo(struct psy_charging_algo
*algo)
+{ return 0; }
+static int power_supply_unregister_charging_algo(struct psy_charging_algo
*algo)
+{ return 0; }
Why do these return 0? Should they not just fail if the power supply
charger support is not compiled in, like return -EINVAL etc?
Sorry for just making some random review of the header files, but
this caught my attention and I couldn't resist.
Yours,
Linus Walleij
--
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] power_supply: Introduce PSE compliant algorithm
On Tue, Feb 4, 2014 at 6:12 AM, Jenny TC jenny...@intel.com wrote:
+static inline bool __is_battery_full
+ (long volt, long cur, long iterm, unsigned long cv)
Overall I wonder if you've run checkpatch on these patches, but why
are you naming this one function with a double __underscore?
Just is_battery_full_check() or something would work fine I guess?
(...)
+/* Parameters defining the charging range */
+struct psy_ps_temp_chg_table {
+ /* upper temperature limit for each zone */
+ short int temp_up_lim; /* Degree Celsius */
+
+ /* charge current and voltage */
+ short int full_chrg_vol; /* mV */
+ short int full_chrg_cur; /* mA */
+
+ /*
+ * Maintenance charging thresholds.
+ * Maintenance charging voltage lower limit - Once battery hits full,
+ * charging will be resumed when battery voltage = this voltage
+ */
+ short int maint_chrg_vol_ll; /* mV */
+
+ /* Charge current and voltage in maintenance charging mode */
+ short int maint_chrg_vol_ul; /* mV */
+ short int maint_chrg_cur; /* mA */
+} __packed;
Why are you packing these structs? If no real reason, remove it.
The compiler will pack what it thinks is appropriate anyway.
Convert all comments to kerneldoc.
+#define BATTID_STR_LEN 8
+#define BATT_TEMP_NR_RNG 6
+
+struct psy_pse_chrg_prof {
+ /* battery id */
+ char batt_id[BATTID_STR_LEN];
+ u16 battery_type; /* Defined as POWER_SUPPLY_TECHNOLOGY_* */
Use a named enum by patching that in linux/power_supply.h?
+ u16 capacity; /* mAh */
+ u16 voltage_max; /* mV */
+ /* charge termination current */
+ u16 chrg_term_mA;
+ /* Low battery level voltage */
+ u16 low_batt_mV;
+ /* upper and lower temperature limits on discharging */
+ s8 disch_temp_ul; /* Degree Celsius */
+ s8 disch_temp_ll; /* Degree Celsius */
+ /* number of temperature monitoring ranges */
+ u16 temp_mon_ranges;
+ struct psy_ps_temp_chg_table temp_mon_range[BATT_TEMP_NR_RNG];
+ /* lowest temperature supported */
+ s8 temp_low_lim;
+} __packed;
Why packed, and convert to kerneldoc for this struct.
Yours,
Linus Walleij
--
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] power_supply: Introduce generic psy charging driver
On Fri, Feb 28, 2014 at 12:27 PM, Jenny Tc jenny...@intel.com wrote:
On Thu, Feb 27, 2014 at 09:08:01PM +0100, Linus Walleij wrote:
On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC jenny...@intel.com wrote:
+++ b/include/linux/power/power_supply_charger.h
+#define MAX_CUR_VOLT_SAMPLES 3
+#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ)
Why are things defined in Jiffies like this insead of seconds, milliseconds
etc? This will vary with the current operating frequency of the system,
why should physical measurements do that?
Is it fine if I use msecs_to_jiffies(3)?
Keep the
#define DEF_CUR_VOLT_SAMPLE_PERIOD 3
Then use msecs_to_jiffies(DEF_CUR_VOLT_SAMPLE_PERIOD)
in the call site.
+enum psy_charger_cable_event {
+ PSY_CHARGER_CABLE_EVENT_DISCONNECT = 0,
+ PSY_CHARGER_CABLE_EVENT_CONNECT,
+ PSY_CHARGER_CABLE_EVENT_UPDATE,
+ PSY_CHARGER_CABLE_EVENT_RESUME,
+ PSY_CHARGER_CABLE_EVENT_SUSPEND,
+};
+
+enum psy_charger_cable_type {
+ PSY_CHARGER_CABLE_TYPE_NONE = 0,
+ PSY_CHARGER_CABLE_TYPE_USB_SDP = 1 0,
+ PSY_CHARGER_CABLE_TYPE_USB_DCP = 1 1,
+ PSY_CHARGER_CABLE_TYPE_USB_CDP = 1 2,
+ PSY_CHARGER_CABLE_TYPE_USB_ACA = 1 3,
+ PSY_CHARGER_CABLE_TYPE_AC = 1 4,
+ PSY_CHARGER_CABLE_TYPE_ACA_DOCK = 1 5,
+ PSY_CHARGER_CABLE_TYPE_ACA_A = 1 6,
+ PSY_CHARGER_CABLE_TYPE_ACA_B = 1 7,
+ PSY_CHARGER_CABLE_TYPE_ACA_C = 1 8,
+ PSY_CHARGER_CABLE_TYPE_SE1 = 1 9,
+ PSY_CHARGER_CABLE_TYPE_MHL = 1 10,
+ PSY_CHARGER_CABLE_TYPE_B_DEVICE = 1 11,
+};
Why is this even an enum? It is clearly bitfields. I would just:
#include linux/bitops.h
#define PSY_CHARGER_CABLE_TYPE_NONE 0x0
#define PSY_CHARGER_CABLE_TYPE_USB_SDP BIT(0)
#define PSY_CHARGER_CABLE_TYPE_USB_DCP BIT(1)
(etc)
This is to ensure type checks when the cable types are handled, #defines will
not help in type checks.
Type checks with static code check tools? But misrepresenting
a bitfield as an enum just to satisfy a static code checker is not
OK IMO.
Yours,
Linus Walleij
--
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] power_supply: Introduce generic psy charging driver
On Fri, Feb 28, 2014 at 6:01 PM, Pavel Machek pa...@ucw.cz wrote: On Thu 2014-02-27 21:08:01, Linus Walleij wrote: On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC jenny...@intel.com wrote: +++ b/include/linux/power/power_supply_charger.h +#define MAX_CUR_VOLT_SAMPLES 3 +#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ) Why are things defined in Jiffies like this insead of seconds, milliseconds etc? This will vary with the current operating frequency of the system, why should physical measurements do that? It is actually ok. The define is relative to jiffies, and that's what interface expects. So consider the option that the interface is wrong. Stating something like a sample period in system-specific jiffies instead of period time T is just weird. What control systems guy would understand this? Yours, Linus Walleij -- 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] power_supply: Introduce PSE compliant algorithm
On Fri, Feb 28, 2014 at 11:07 AM, Jenny Tc jenny...@intel.com wrote: On Thu, Feb 27, 2014 at 09:18:57PM +0100, Linus Walleij wrote: On Tue, Feb 4, 2014 at 6:12 AM, Jenny TC jenny...@intel.com wrote: +static inline bool __is_battery_full + (long volt, long cur, long iterm, unsigned long cv) Overall I wonder if you've run checkpatch on these patches, but why are you naming this one function with a double __underscore? Just is_battery_full_check() or something would work fine I guess? Just to convey that is_battery_full is a local function and not generic. You can find similar usage in power_supply_core.c (__power_supply_changed_work) and in other drivers. Isn't it advised to have __ prefixes? The preference is different, usually __ is for compiler things, but while I dislike it (disturbs my perception) I can sure live with it. Why are you packing these structs? If no real reason, remove it. The compiler will pack what it thinks is appropriate anyway. The structure is part of the battery charging profile which can be read directly from an EEPROM or from secondary storage (emmc). So it should be packed to keep it align with the stored format. OK I buy that. Make sure this is noted somewhere (or maybe I missed it). Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Mon, Mar 10, 2014 at 5:33 AM, Jenny Tc jenny...@intel.com wrote: On Fri, Mar 07, 2014 at 09:25:20PM +0100, Pavel Machek wrote: + /* sort based on priority. 0 has the highest priority */ + for (i = 0; i cnt; ++i) + for (j = 0; j cnt; ++j) + if (psy_prioirty(psy_lst[j]) psy_prioirty(psy_lst[i])) + swap(psy_lst[j], psy_lst[i]); + WTF? Bubble sort in kernel? Yes, it's bubble sort. Since the number of power supply objects in real systems (max 4) are limited, I feel the complexity would be as same as any other sorting algorithms. Any suggestions? You already have a kernel quicksort implementation in lib/sort.c. Please restructure the code to make use of this as it is already compiled into every kernel. Yours, Linus Walleij -- 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] power_supply: Introduce generic psy charging driver
On Fri, Mar 7, 2014 at 9:10 PM, Pavel Machek pa...@ucw.cz wrote: On Fri 2014-03-07 11:04:59, Linus Walleij wrote: On Fri, Feb 28, 2014 at 6:01 PM, Pavel Machek pa...@ucw.cz wrote: On Thu 2014-02-27 21:08:01, Linus Walleij wrote: On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC jenny...@intel.com wrote: +++ b/include/linux/power/power_supply_charger.h +#define MAX_CUR_VOLT_SAMPLES 3 +#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ) Why are things defined in Jiffies like this insead of seconds, milliseconds etc? This will vary with the current operating frequency of the system, why should physical measurements do that? It is actually ok. The define is relative to jiffies, and that's what interface expects. So consider the option that the interface is wrong. Stating something like a sample period in system-specific jiffies instead of period time T is just weird. What control systems guy would understand this? 30*HZ means 30 seconds in the kernel... what is hard to understand about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. One reason is that this kind of code actually needs review from non-programmers, people like chemists and physicists. I know it may be far fetched so no strong preference for sure. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 7, 2014 at 6:29 AM, Jenny TC jenny...@intel.com wrote:
+enum psy_charger_cable_type {
+ PSY_CHARGER_CABLE_TYPE_NONE = 0,
+ PSY_CHARGER_CABLE_TYPE_USB_SDP = 1 0,
+ PSY_CHARGER_CABLE_TYPE_USB_DCP = 1 1,
+ PSY_CHARGER_CABLE_TYPE_USB_CDP = 1 2,
+ PSY_CHARGER_CABLE_TYPE_USB_ACA = 1 3,
+ PSY_CHARGER_CABLE_TYPE_AC = 1 4,
+ PSY_CHARGER_CABLE_TYPE_ACA_DOCK = 1 5,
+ PSY_CHARGER_CABLE_TYPE_ACA_A = 1 6,
+ PSY_CHARGER_CABLE_TYPE_ACA_B = 1 7,
+ PSY_CHARGER_CABLE_TYPE_ACA_C = 1 8,
+ PSY_CHARGER_CABLE_TYPE_SE1 = 1 9,
+ PSY_CHARGER_CABLE_TYPE_MHL = 1 10,
+ PSY_CHARGER_CABLE_TYPE_B_DEVICE = 1 11,
+};
I still disagree with using an enum as bitfield.
Atleast
#include linux/bitops.h
and use BIT(0), BIT(1) etc to define the bits.
Yours,
Linus Walleij
--
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] power_supply: Introduce generic psy charging driver
On Thu, Mar 13, 2014 at 10:12 AM, Pavel Machek pa...@ucw.cz wrote: Hi! 30*HZ means 30 seconds in the kernel... what is hard to understand about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. I agree HZ is badly named, but hopefully anyone working on kernel is already familiar with it. But... what would actually help: I believe we should introduce milivolt_t, miliamp_t, milisec_t etc... types. Storing milivolts in int, then having comment saying milivolts is just wrong. Hm! I bet the regulator subsystem maintainers have opinions on that. Yours, Linus Walleij -- 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 49/75] ARM: l2c: fix register naming
On Fri, Mar 28, 2014 at 4:18 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: We have a mixture of different devices with different register layouts, but we group all the bits together in an opaque mess. Split them out into those which are L2C-310 specific and ones which refer to earlier devices. Provide full auxiliary control register definitions. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Linus Walleij linus.wall...@linaro.org For ux500. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Now that you have sent your changes for v3.15 to Torvalds, here are some changes for the OMAP GPIO driver targeted to v3.16. Mostly improvements so nothing here is -rc material. I like this series so I have applied them for v3.16, pending some ACK from Kevin | Santosh. The biggest change is Patch 4 that converts the driver to use the newly introduced generic irqchip helpers in the gpiolib core which allows to remove some driver specific logic that should really be generic. Excellent, I will take a closer look at this, it seems there is some cruft still in but let me look. Yours, Linus Walleij -- 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/5] gpio: omap: convert driver to use gpiolib irqchip
On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
+#ifdef CONFIG_ARCH_OMAP1
+ /*
+ * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
+ * irq_alloc_descs() since a base IRQ offset will no longer be needed.
+ */
+ irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
+ if (irq_base 0) {
+ dev_err(bank-dev, Couldn't allocate IRQ numbers\n);
+ return -ENODEV;
+ }
+#endif
+
Do we still need above after first patch ? Would be good
to get rid of above ugly #ifdef on the middle of the code.
I don't think so actually, simple irqdomain adds descriptors
for irqbase != 0, and the gpiochip irqchip helpers call
irq_create_mapping() on all offsets.
Preferably a separate patch on top of this removing that code
though so it's bisectable.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] add gpio_chip_ops to hold GPIO operations
On Tue, Apr 8, 2014 at 8:20 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Overall I like this. However I don't want to see any transitional phase. I prefer a BIG fat patch converting everyone and its dog to the new vtable and removing the old function pointers. This can be based on the HEAD of my GPIO devel branch. It may be a good idea to use coccinelle for this refactoring in order not to miss any users. Yours, Linus Walleij -- 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 11/11] pinctrl: single: Clear pin interrupts enabled by bootloader
On Fri, Apr 11, 2014 at 1:47 AM, Tony Lindgren t...@atomide.com wrote: Since we set up device wake-up interrupts as pinctrl-single interrupts, we now must use the standard request_irq and related functions to manage them. If the pin interrupts are enabled for some pins at boot, the wake-up events can show up as constantly pending at least on omaps and will hang the system unless the related device driver clears the event at the device. To fix this, let's clear the interrupt flags during init, and print out a warning so the board maintainers can update their drivers to do proper request_irq for the driver specific wake-up events. Cc: Haojian Zhuang haojian.zhu...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Looks clean. Acked-by: Linus Walleij linus.wall...@linaro.org Shall I apply this patch or will you funnel it through ARM SoC due to deps? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] GPIO OMAP driver changes for v3.16
On Fri, Apr 11, 2014 at 5:03 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Aaro,
On Thu, Apr 10, 2014 at 11:22 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
On Thu, Apr 10, 2014 at 10:17:44PM +0200, Javier Martinez Canillas wrote:
The same happens also on Nokia 770:
[0.118896] genirq: Setting trigger mode 0 for irq 128 failed
(gpio_irq_type+0x0/0x220)
I don't have those errors when booting on my DM3730 IGEPv2 board but
it seems that for some reason on omap1 __irq_set_trigger() complains
when IRQ_TYPE_NONE is used as a default flag when calling
gpiochip_irqchip_add()
Could you please test the following patch and tell me if your board
still works and makes the errors go away?
Now it complains about mode 8...
[0.118835] genirq: Setting trigger mode 8 for irq 128 failed
(gpio_irq_type
+0x0/0x220)
A.
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..5bc8aec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1122,7 +1122,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
irq_base, gpio_irq_handler,
- IRQ_TYPE_NONE);
+ IRQ_TYPE_LEVEL_LOW);
if (ret) {
dev_err(bank-dev, Couldn't add irqchip to gpiochip
%d\n, ret);
Best regards,
Javier
Thanks for testing. Unfortunately I'm out of ideas on why that error
could be shown and I don't have a way to further debug it without an
omap1 board. I wonder why that pr_err() message is shown or why it is
still working when an error happens.
Maybe Linus or Santosh could give us a hint on what is happening here.
Isn't an edge IRQ more apropriate as default then?
The code contains this:
if (!bank-regs-leveldetect0
(type (IRQ_TYPE_LEVEL_LOW|IRQ_TYPE_LEVEL_HIGH)))
return -EINVAL;
Meaning sometimes the banks don't support level IRQs.
Yours,
Linus Walleij
--
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: regressions in linux-next?
On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: I've revised the patch again and I couldn't find the reason why certain boards are failing to boot. I can't reproduce this issue since I only have a DM3730 IGEPv2 board which boots fine but I should have access to an AM3354 IGEP Aquila board which is similar to the am335x-evmsk so I may be able to debug it. It would really REALLY appreciate if some of the people maintaining and using OMAP1 would help Javier out in this refactoring operation. I'd really *hate* to have to drop his patches because of a lack of boards. This refactoring is necessary to handle the exploding multitude of GPIO drivers moving forward. We even tried to get an Innovator to boot just to be able to refactor OMAP stuff but fell short on some special JTAG reflash snag so we are dependent on maintainers to help out here :-/ Yours, Linus Walleij -- 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: regressions in linux-next?
On Wed, Apr 23, 2014 at 9:24 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: Linus, what do you think of the following patch? From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas javier.marti...@collabora.co.uk Date: Wed, 23 Apr 2014 09:13:54 +0200 Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map function (...) So no setting a default type in the mapping function... - irq_set_irq_type(irq, chip-irq_default_type); But there are drivers exploiting this to set up the hardware to some default state :-( What about this: if (chip-irq_default_type != IRQ_TYPE_NONE) irq_set_irq_type(irq, chip-irq_default_type); This way you can pass IRQ_TYPE_NONE and nothing happens in the mapping. Yours, Linus Walleij -- 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] gpio: omap: implement get_direction
On Tue, Apr 22, 2014 at 3:31 PM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
Changes:
v2: rework return value calculation
(...)
I don't see why this need to be a broken-out function? Can it not
be factored into gpio_get_direction?
+static int _get_gpio_direction(struct gpio_bank *bank, int gpio)
+{
+ void __iomem *reg = bank-base;
+ u32 l;
+
+ reg += bank-regs-direction;
+ l = (readl_relaxed(reg) gpio);
+
+ return (l 0x0001);
Rewrite the last two statements like this:
#include linux/bitops.h
return !!(readl_relaxed(reg) BIT(gpio));
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ int dir;
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ spin_lock_irqsave(bank-lock, flags);
+ dir = _get_gpio_direction(bank, offset);
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
So since _get_gpio_direction is never called from unlocked context,
can it not just be part of this function then?
(I make a mental note to prefix all functions in this driver
with omap_*)
Yours,
Linus Walleij
--
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 11/11] pinctrl: single: Clear pin interrupts enabled by bootloader
On Tue, Apr 22, 2014 at 6:10 PM, Tony Lindgren t...@atomide.com wrote: Shall I apply this patch or will you funnel it through ARM SoC due to deps? No deps except boards hanging without it.. Please feel free to take this one, prererrably as a fix for the -rc series if no objections. Yes this is -rc material. Queued for fixes. Thanks! Yours, Linus Walleij -- 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: regressions in linux-next?
On Wed, Apr 23, 2014 at 3:29 PM, Nishanth Menon n...@ti.com wrote: On 04/23/2014 08:01 AM, Linus Walleij wrote: What about this: if (chip-irq_default_type != IRQ_TYPE_NONE) irq_set_irq_type(irq, chip-irq_default_type); This way you can pass IRQ_TYPE_NONE and nothing happens in the mapping. What if these drivers depend on IRQ_TYPE_NONE to do something for the GPIO pins? Yeah :-( would you expect these drivers to pass IRQ_TYPE_DEFAULT? Actually that sounds like a good idea. Maybe we can go over the few drivers that pass IRQ_TYPE_NONE and see what they actually want. There are not *too* many users of this call yet. OR I wonder if we could pass some flag like -1 for platforms that dont care? The flags parameter to gpiochip_irqchip_add() is unsigned... Switching to IRQ_TYPE_DEFAULT for drivers that want this is likely the sane thing to do. Yours, Linus Walleij -- 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] gpio: do not set up hardware for IRQ_TYPE_NONE
Some GPIO irqchip drivers exploit the irqdomain mapping function to set up the IRQ default type in the hardware, make sure that if we pass IRQ_TYPE_NONE, no hardware setup whatsoever takes place (this should be the norm) until later when the IRQ gets utilized. Cc: Nishanth Menon n...@ti.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap linux-omap@vger.kernel.org Signed-off-by: Linus Walleij linus.wall...@linaro.org --- TI folks: can you provide a Tested-by tag if this makes your OMAPs work? I am pretty sure the other platforms will be unaffected, if they aren't I will switch them over to react to IRQ_TYPE_DEFAULT. --- drivers/gpio/gpiolib.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index ee1819fdcf35..97d173e9aa2d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1409,7 +1409,12 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip-irq_default_type); + /* +* No set-up of the hardware will happen if IRQ_TYPE_NONE +* is passed as default type. +*/ + if (chip-irq_default_type != IRQ_TYPE_NONE) + irq_set_irq_type(irq, chip-irq_default_type); return 0; } @@ -1490,7 +1495,8 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip) * @first_irq: if not dynamically assigned, the base (first) IRQ to * allocate gpiochip irqs from * @handler: the irq handler to use (often a predefined irq core function) - * @type: the default type for IRQs on this irqchip + * @type: the default type for IRQs on this irqchip, pass IRQ_TYPE_NONE + * to have the core avoid setting up any default type in the hardware. * * This function closely associates a certain irqchip with a certain * gpiochip, providing an irq domain to translate the local IRQs to -- 1.9.0 -- 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: regressions in linux-next?
On Wed, Apr 23, 2014 at 4:50 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: What do you think about the following patch? Although I agree that if we can use IRQ_TYPE_NONE as you propose then tht is a much better and efficient solution that this patch. Let's try IRQ_TYPE_NONE first and if that fails we go back to this. I've pushed the current patch to linux-next. Yours, Linus Walleij -- 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] gpio: omap: implement get_direction
On Thu, Apr 24, 2014 at 8:57 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch implements gpio_chip's get_direction() routine, that
lets other drivers get particular GPIOs direction using
struct gpio_desc.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
Changes:
v3: get rid of _get_gpio_direction() (Linus Walleij)
v2: rework return value calculation
Looks good to me, Kevin, Santosh?
Part of me wants to list Javier as maintainer for this driver.
+static int gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct gpio_bank *bank;
+ unsigned long flags;
+ void __iomem *reg;
+ int dir;
That is a bool, actually. But no big deal.
+
+ bank = container_of(chip, struct gpio_bank, chip);
+ reg = bank-base + bank-regs-direction;
+ spin_lock_irqsave(bank-lock, flags);
+ dir = !!(readl_relaxed(reg) BIT(offset));
+ spin_unlock_irqrestore(bank-lock, flags);
+ return dir;
+}
Yours,
Linus Walleij
--
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] gpio: omap: implement get_direction
On Thu, Apr 24, 2014 at 8:57 AM, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com This patch implements gpio_chip's get_direction() routine, that lets other drivers get particular GPIOs direction using struct gpio_desc. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org --- Changes: v3: get rid of _get_gpio_direction() (Linus Walleij) v2: rework return value calculation This v3 version applied with Santosh's ACK. Yours, Linus Walleij -- 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] gpio: always enable GPIO_OMAP on ARCH_OMAP
On Mon, Apr 28, 2014 at 11:07 AM, Arnd Bergmann a...@arndb.de wrote: Commit 4df42de9d3e gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP made it possible to build OMAP kernels without the GPIO driver, which at least on OMAP2 and OMAP3 causes build errors because of functions used by the platform power management code: arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle': arch/arm/mach-omap2/pm24xx.c:129: undefined reference to `omap2_gpio_prepare_for_idle' arch/arm/mach-omap2/pm24xx.c:129: undefined reference to `omap2_gpio_resume_after_idle' We presumably always want the GPIO driver on OMAP, so this adds a slightly broader dependency and only allows disabling the driver only when no OMAP2PLUS platform is selected. However, it seems entirely reasonable to include the driver in build tests on other platforms, so we should also allow building it for COMPILE_TEST builds and select the required GENERIC_IRQ_CHIP that may not already be enabled on other platforms. Signed-off-by: Arnd Bergmann a...@arndb.de Patch applied to my devel branch, this is not a fix to Torvalds HEAD AFAICT, but a fix to v3.16? Else poke me. Yours, Linus Walleij -- 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] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
On Fri, May 9, 2014 at 5:42 AM, Jingoo Han jg1@samsung.com wrote: Linus Walleij, Is there any reason to keep these two functions such as gpiod_set_raw_value_cansleep() and gpiod_set_raw_value()? Yes, the former can *not* be called from interrupt context, and thus erroneous usage can be detected with runtime checks. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
On Thu, May 8, 2014 at 9:06 AM, Rajendra Nayak rna...@ti.com wrote: Do you mind picking this fix up via the GPIO tree? Yes, it's merged to my devel branch now with the ACKs. Alternatively you could Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from this series via the OMAP tree. This probably will not work as I have a set of other changes to this driver in my tree. Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that order else gpio would break. More discussions are here [1]. Tell me if I should prepare an immutable tag on my branch that you can pull in. I want an explicit handshake with the platform maintainer for this kind of stuff. Yours, Linus Walleij -- 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: Accessing GPIOs from userspace using recent kernels
Hi Peter, I think you have already understood from the rest of the conversation that pin control configuration shall be done in the device tree and not from userspace, which is a good start. As shown by Javier many things people sometimes do in userspace should rather be done in kernelspace, such as controlling LEDs and reading pushbuttons etc. On Fri, May 16, 2014 at 12:15 PM, Peter TB Brett pe...@peter-b.co.uk wrote: On 2014-05-15 19:54, Javier Martinez Canillas wrote: 0x5e (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_sda.hdmi_sda */ 0x12e (PIN_OUTPUT | MUX_MODE5) /* dispc2_data15 */ Yes, that's my mistake. I took the pin control register addresses from the OMAP4 documentation and forgot that you have to subtract 0x40 to get the correct address for use in the device tree. The correct snippet has 0x1e and 0xee. I find the pinctrl-single hexdigit syntax infinitely complex and confusing, but it was chosen by its designers. Most drivers use strings to configure muxing and biasing etc. Is what you shared your real change or just an example that does not apply to the Pandaboard? Could you please share your complete DTS? The attached .dts file sort of works-ish. It's an ugly hack, but I don't have the time to do any more investigation into this now, unfortunately. I guess my main question is: if I use /sys/class/gpio/export to export a GPIO for userspace control, Which you should avoid, if possible. it would make sense for the kernel to try and ensure that the GPIO is actually connected to something! How should we do that? The physics of that request evades me. The pin control subsystem will however refuse to use the pin if it is used for something else. The current call chain seems to be: gpiod_export() -- gpiod_request() -- omap_gpio_request(). Looking at other GPIO drivers, it seems like omap_gpio_request() should eventually call pinctrl_request_gpio(). Would be useful if someone who knows about OMAP4/gpio/pinctrl could take a look at this. That is Tony Lindgren and the linux-omap mailing list. Yours, Linus Walleij -- 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] gpio: of: Allow -gpio suffix for property names
On Tue, Jun 3, 2014 at 1:14 AM, Tony Lindgren t...@atomide.com wrote: Looks like something like below fixes the issue. Regards, Tony 8 --- From: Tony Lindgren t...@atomide.com Date: Mon, 2 Jun 2014 16:13:46 -0700 Subject: [PATCH] gpio: of: Fix handling for deferred probe for -gpio suffix Commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names) added parsing for both -gpio and -gpios suffix but also changed the handling for deferred probe unintentionally. Because of the looping the second name will now return -ENOENT instead of -EPROBE_DEFER. Fix the issue by breaking out of the loop if -EPROBE_DEFER is encountered. Signed-off-by: Tony Lindgren t...@atomide.com Patch applied for fixes with Thierry's Reveiwed-by tag. Yours, Linus Walleij -- 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 1/6] ARM: mm: cache-l2x0: Add base address argument to write_sec callback
On Wed, Jun 25, 2014 at 3:37 PM, Tomasz Figa t.f...@samsung.com wrote: For certain platforms (e.g. Exynos) it is necessary to read back some values from registers before they can be written (i.e. SMC calls that set multiple registers per call), so base address of L2C controller is needed for .write_sec operation. This patch adds base argument to .write_sec callback so that its implementation can also access registers directly. Signed-off-by: Tomasz Figa t.f...@samsung.com arch/arm/mach-ux500/cache-l2x0.c | 3 ++- In our case just changing the signature of the function I see so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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/3] gpio: omap: Remove unnecessary lockdep class
On Fri, Jun 27, 2014 at 10:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: GPIO irqchips assign to the cascaded IRQs their own lock class in order to avoid warnings about lockdep recursions since that allow the lockdep core to keep track of things. Since commit e45d1c80 (gpio: put GPIO IRQs into their own lock class) there is no need to do this in a driver if it's using the GPIO irqchip helpers since gpiolib already assigns a lockdep class. Signed-off-by: Javier Martinez Canillas jmarti...@softcrates.net That's right. Patch applied. Yours, Linus Walleij -- 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/3] gpio: omap: Remove unneeded include
On Fri, Jun 27, 2014 at 10:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: The linux/irqchip/chained_irq.h header is already included when selecting GPIOLIB_IRQCHIP so there is no need to do it in the driver. This is a left over from commit fb655f5 (gpio: omap: convert driver to use gpiolib irqchip). Signed-off-by: Javier Martinez Canillas jmarti...@softcrates.net Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] gpio: omap: Add an omap prefix to all functions
On Fri, Jun 27, 2014 at 10:17 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: The GPIO OMAP driver didn't have a consistent naming scheme for all its functions. Some of them had an omap prefix while others didn't. There are many advantages on having a separate namespace for driver functions so let's add an omap prefix to all of them. Signed-off-by: Javier Martinez Canillas jmarti...@softcrates.net Yeah that was very disturbing, patch applied, thanks! Yours, Linus Walleij -- 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/3] pinctrl: bindings: Add OMAP pinctrl binding
On Mon, Aug 25, 2014 at 9:03 PM, Nishanth Menon n...@ti.com wrote: ---8--- From 74121c6a2524048eb02c3b33a25e13261edd2e99 Mon Sep 17 00:00:00 2001 From: Nishanth Menon n...@ti.com Date: Thu, 22 May 2014 23:32:09 -0500 Subject: [PATCH V2] pinctrl: bindings: Add OMAP pinctrl binding Add basic skeleton of OMAP pinctrl bindings. This is compatible with pinctrl,single bindings and is meant purely as a reference point. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com Applied this inline v2 version. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pinctrl: single: AM437x: Add pinctrl compatibility
On Fri, Aug 22, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote: From: Keerthy j-keer...@ti.com AM437x pinctrl definitions now differ from traditional 16 bit OMAP pin ctrl definitions, in that all 32 bits are used to describe a single pin Also the location of wakeupenable and event bits have changed. Signed-off-by: Keerthy j-keer...@ti.com [n...@ti.com: minor updates] Signed-off-by: Nishanth Menon n...@ti.com Patch applied with Tony's ACK. Yours, Linus Walleij -- 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/3] pinctrl: single: Add DRA7 pinctrl compatibility
On Fri, Aug 22, 2014 at 4:01 PM, Nishanth Menon n...@ti.com wrote: DRA7 pinctrl definitions now differ from traditional 16 bit OMAP pin ctrl definitions, in that all 32 bits are used to describe a single pin Also the location of wakeupenable and event bits have changed. Signed-off-by: Nishanth Menon n...@ti.com Patch applied with Tony's ACK. Yours, Linus Walleij -- 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/3] kbuild: remove unnecessary variable initializaions
On Tue, Sep 9, 2014 at 12:26 PM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Clearing obj-y, obj-m, obj-n, obj- in each Makefile is a useless habit. They are non-exported variables; therefore they are always empty whenever descending into each subdirectory. (Moreorver, obj-y and obj-m are also set to empty at the beginning of scripts/Makefile.build) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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: [RESEND PATCH] gpio: omap: Fix interrupt names
On Fri, Sep 5, 2014 at 9:52 PM, Nishanth Menon n...@ti.com wrote: When viewing the /proc/interrupts, there is no information about which GPIO bank a specific gpio interrupt is hooked on to. This is more than a bit irritating as such information can esily be provided back to the user and at times, can be crucial for debug. So, instead of displaying something like: 31: 0 0 GPIO 0 palmas 32: 0 0 GPIO 27 mmc0 Display the following with appropriate device name: 31: 0 0 4ae1.gpio 0 palmas 32: 0 0 4805d000.gpio 27 mmc0 This requires that we create irq_chip instance specific for each GPIO bank which is trivial to achieve. Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Kevin Hilman khil...@linaro.org --- Requested to be resend by Javier with linux-gpio maintainers in CC. Original V1 of the patch: https://patchwork.kernel.org/patch/4757891/ Probably belongs to 3.18 kernel series at this point in time. Changes since v1: just picked up Acks. Patch applied. Yours, Linus Walleij -- 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/8] usb: musb: Change to use new IO access
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: Change to use new IO access. This allows us to build in multiple MUSB glue layers. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 6/8] net: can: c_can: Disable pins when CAN interface is down
On Fri, Nov 14, 2014 at 4:40 PM, Roger Quadros rog...@ti.com wrote: DRA7 CAN IP suffers from a problem which causes it to be prevented from fully turning OFF (i.e. stuck in transition) if the module was disabled while there was traffic on the CAN_RX line. To work around this issue we select the SLEEP pin state by default on probe and use the DEFAULT pin state on CAN up and back to the SLEEP pin state on CAN down. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Linus Walleij linus.wall...@linaro.org I see you figured it out all by yourselves :D (Sorry for being absent.) +#include linux/pinctrl/consumer.h + pinctrl_pm_select_default_state(dev-dev.parent); + pinctrl_pm_select_sleep_state(dev-dev.parent); + pinctrl_pm_select_sleep_state(dev-dev.parent); NB: in drivers/base/pinctrl.c: #ifdef CONFIG_PM /* * If power management is enabled, we also look for the optional * sleep and idle pin states, with semantics as defined in * linux/pinctrl/pinctrl-state.h */ dev-pins-sleep_state = pinctrl_lookup_state(dev-pins-p, PINCTRL_STATE_SLEEP); So if these states are necessary for the driver to work, put depends on PM or select PM in the Kconfig. Yours, Linus Walleij -- 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 6/8] net: can: c_can: Disable pins when CAN interface is down
On Fri, Nov 14, 2014 at 2:43 PM, Roger Quadros rog...@ti.com wrote: On 11/13/2014 06:03 PM, Marc Kleine-Budde wrote: On 11/13/2014 04:23 PM, Roger Quadros wrote: I just stumbled over pinctrl_pm_select_sleep_state(), is it possible to integrate this into runtime pm? http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1282 I think those functions are there for the same reason but not sure why aren't they used in runtime pm core. Linus W. any hints? It is not used from PM core because there are cases where you may want to put pins to sleep for completely PM-core unrelated things. Things like turning off a serial port from userspace, for example. That should put the pins to sleep. Yours, Linus Walleij -- 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 6/8] usb: musb: Pass fifo_mode in platform data
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: This allows setting the correct fifo_mode when multiple MUSB glue layers are built-in. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Apelete Seketeli apel...@seketeli.net Cc: Lars-Peter Clausen l...@metafoo.de Signed-off-by: Tony Lindgren t...@atomide.com Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 5/8] usb: musb: Change end point selection to use new IO access
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: This allows the endpoints to work when multiple MUSB glue layers are built in. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Apelete Seketeli apel...@seketeli.net Cc: Lars-Peter Clausen l...@metafoo.de Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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] gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On Wed, Dec 3, 2014 at 2:50 AM, Rafael J. Wysocki r...@rjwysocki.net wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM in drivers/gpio/gpio-omap.c. Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) which is only in linux-next at the moment (via the linux-pm tree). Please let me know if it is OK to take this one into linux-pm. Go ahead. Should be no collissions. Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] gpio: omap: Fix bad device access with setup_irq()
On Fri, Jan 16, 2015 at 11:50 PM, Tony Lindgren t...@atomide.com wrote: Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Kevin Hilman khil...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Russell King - ARM Linux li...@arm.linux.org.uk Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Patch applied for fixes with Felipe's Tested-by. Yours, Linus Walleij -- 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 14/21] ARM: imx6: convert GPC to stacked domains
On Mon, Jan 12, 2015 at 7:26 PM, Marc Zyngier marc.zyng...@arm.com wrote: IMX6 has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the fact that the GPC block is actually the first interrupt controller in the chain, kernels with this patch applied wont have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs won't even boot. Tested-by: Stefan Agner ste...@agner.ch Acked-by: Stefan Agner ste...@agner.ch Signed-off-by: Marc Zyngier marc.zyng...@arm.com (...) +static int imx_gpc_domain_alloc(struct irq_domain *domain, + unsigned int virq, Nutcase nitpick on this nice patch series: every time I see virq my OCD triggers, as I think the v in virq stand for virtual. These irqs are no more virtual than any other Linux irq numbers, hwirq is more to the point. I just refer to these as irq (sans v) in any code I write. Yours, Linus Walleij -- 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] gpio: pcf857x: restore the initial line state of all pcf lines
On Mon, Jan 5, 2015 at 7:26 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Thursday 18 December 2014 07:41 PM, Nishanth Menon wrote:
On 12/18/2014 12:18 AM, Kishon Vijay Abraham I wrote:
On Tuesday 16 December 2014 02:20 AM, Nishanth Menon wrote:
On 12/12/2014 02:06 AM, Kishon Vijay Abraham I wrote:
The reset values for all the PCF lines are high and hence on shutdown
we should drive all the lines high in order to bring it to the reset
state.
This is actually required since pcf doesn't have a reset line and even
after
warm reset (by invoking reboot in prompt) the pcf lines maintains it's
previous programmed state. This becomes a problem if the boards are
designed
to work with the default initial state.
DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to MMC/SD
and
this line should be driven high in order for the MMC/SD to be detected.
This line is modelled as regulator and the hsmmc driver takes care of
enabling
and disabling it. In the case of 'reboot', during shutdown path as part
of it's
cleanup process the hsmmc driver disables this regulator. This makes MMC
boot
not functional.
Fixed it by driving high all the pcf lines.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/gpio/gpio-pcf857x.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 236708a..00b15b2 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -448,6 +448,14 @@ static int pcf857x_remove(struct i2c_client *client)
return status;
}
+static void pcf857x_shutdown(struct i2c_client *client)
+{
+ struct pcf857x *gpio = i2c_get_clientdata(client);
+
+ /* Drive all the I/O lines high */
+ gpio-write(gpio-client, BIT(gpio-chip.ngpio) - 1);
you might force a contention here - depending on System configuration.
example:
+---+
| |
| U1 | +--+ +---+
| +- | | |
+---+ | | | |
| Switch-+SoC|
+---+ | | | |
| | | | | |
| U2-+--^---+ +---+
| ||
| ||
+---+|
+--+--+
| |
| PCF |
| |
+-+
At low, SoC pin is connected to U2 as drive. when reset to high, you
now have U1 driving to the same pin that SoC has, potentially
resulting in contention.
Unfortunately, at this level, you do not know what the state of the
system is, blindly forcing a pin level will potentially cause
contention risk depending on pin configuration.
Assume we are doing a reset when the system is powered on, irrespective of
the
state of the system, we'll be forcing the pin level to the default state.
Yes, I dont deny that system will be fine *after* reset sequence is
started or completed. However there is a duration between the pcf
shutdown handler is called and the final reset handler is invoked -
that is the duration when the contention might cause device behavior.
Essentially ignoring the state various drivers have asked PCF to setup
the pins and doing a hands down configuration may have side effects we
cant properly expect.
The solution might be to invoke the shutdown handler of the various drivers
using the PCF before the shutdown handler of the PCF driver itself gets
invoked? But I'm not sure how can that be achieved in linux kernel :-(
#include linux/reboot.h
static int foo_reboot_handler(struct notifier_block *this,
unsigned long code,
void *unused)
{
pr_crit(do some last minute stuff\n);
return NOTIFY_OK;
}
static struct notifier_block foo_reboot_notifier = {
.notifier_call = foo_reboot_handler,
};
register_reboot_notifier(foo_reboot_notifier);
Yours,
Linus Walleij
--
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] gpio: pcf857x: restore the initial line state of all pcf lines
On Mon, Mar 16, 2015 at 9:46 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Wednesday 14 January 2015 05:28 PM, Linus Walleij wrote:
#include linux/reboot.h
static int foo_reboot_handler(struct notifier_block *this,
unsigned long code,
void *unused)
{
pr_crit(do some last minute stuff\n);
return NOTIFY_OK;
}
static struct notifier_block foo_reboot_notifier = {
.notifier_call = foo_reboot_handler,
};
register_reboot_notifier(foo_reboot_notifier);
Added debug prints and found the reboot notifier gets invoked before the
shutdown handler which means some stuff can be done after this reboot
notifier:-(
Specify exactly what stuff may happen after the reboot notifier.
Of course stuff happens both before and after the reboot
notifier, the question is exactly what, that may conflict with this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On Tue, Mar 10, 2015 at 7:33 PM, Nishanth Menon n...@ti.com wrote:
On 03/10/2015 12:31 PM, Tony Lindgren wrote:
Yes except I'd make use of some kind of #pinctrl-cells here just like
interrupt controller has #interrupt-cells. Then you can have the values
seprate and the controller knows what to do with them based on the
compatible flag and #pinctrl-cells.
Something like the following I suppose, where pinctrl-cells is optional?
dra7_pmx_core: pinmux@4a003400 {
compatible = ti,dra7-padconf, pinctrl-single;
reg = 0x4a003400 0x0464;
#address-cells = 1;
#size-cells = 0;
#interrupt-cells = 1;
interrupt-controller;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x3fff;
};
dra7_iodelay_core: padconf@4844a000 {
compatible = ti,dra7-iodelay;
reg = 0x4844a000 0x0d1c;
#address-cells = 1;
#size-cells = 0;
#pinctrl-cells = 2;
};
Linus,
I hope you are ok with the above?
Hm depends on where the documentation hits I guess?
Such a generic cell count property has to be to the generic
pinctrl-bindings.txt document if I read it right.
Overall I guess this will be acceptable but you really need to
reuse some more code between this driver and pinctrl-single.c
if I read it right.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irq
On Fri, Mar 6, 2015 at 8:26 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org GPIOLib core implemnts irqchip-irq_request/release_resources callbacks internally and these callbacks already contain clalls of gpiochip_lock/unlock_as_irq(). Hence, remove unnecessary call of gpiochip_unlock_as_irq() from omap_gpio_irq_shutdown(). Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Looks like a simple oversight. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On Wed, Mar 4, 2015 at 1:00 AM, Nishanth Menon n...@ti.com wrote:
+Configuration definition follows similar model as the pinctrl-single:
+The groups of pin configuration are defined under pinctrl-single,pins
+
+dra7_iodelay_core {
+ mmc2_iodelay_3v3_conf: mmc2_iodelay_3v3_conf {
+ pinctrl-single,pins =
+ 0x18c (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A19_IN */
+ 0x1a4 (A_DELAY(265) | G_DELAY(360)) /*
CFG_GPMC_A20_IN */
+ 0x1b0 (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A21_IN */
+ 0x1bc (A_DELAY(0) | G_DELAY(120)) /*
CFG_GPMC_A22_IN */
+ 0x1c8 (A_DELAY(287) | G_DELAY(420)) /*
CFG_GPMC_A23_IN */
+ 0x1d4 (A_DELAY(144) | G_DELAY(240)) /*
CFG_GPMC_A24_IN */
+ 0x1e0 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_A25_IN */
+ 0x1ec (A_DELAY(120) | G_DELAY(0)) /*
CFG_GPMC_A26_IN */
+ 0x1f8 (A_DELAY(120) | G_DELAY(180)) /*
CFG_GPMC_A27_IN */
+ 0x360 (A_DELAY(0) | G_DELAY(0)) /*
CFG_GPMC_CS1_IN */
+ ;
+ };
+};
But wait.
The promise when we merged pinctrl-single was that this driver was to be used
when the system had a one-register-per-pin layout and it was easy to do device
trees based on that.
We were very reluctant to accept that even though we didn't even have the
generic pin control bindings in place, the argument being that the driver
should know the detailed register layout, it should not be described in the
device tree. We eventually caved in and accepted it as an exception.
Since this pin controller is not using pinctrl-single it does not enjoy that
privilege and you need to explain why this pin controller cannot use the
generic bindings like so many other pin controllers have since started
to do. (It is in the same SoC is not an acceptable argument.)
What is wrong with this:
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
We can add generic delay bindings to the list, it even seems like
a good idea to do so, as it is likely something that will come up in
other hardware and will be needed for ACPI etc going forward.
Yours,
Linus Walleij
--
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] pinctrl: Introduce TI IOdelay configuration driver
PLL or something?
+ r = regmap_read(iod-regmap, reg-reg_coarse_offset, val);
+ if (r)
+ return r;
+ ival-coarse_ref_count =
+ ti_iodelay_extract(val, reg-coarse_ref_count_mask);
+ ival-coarse_delay_count =
+ ti_iodelay_extract(val, reg-coarse_delay_count_mask);
+ if (!ival-coarse_delay_count) {
+ dev_err(dev, Invalid Coarse delay count (0) (reg=0x%08x)\n,
+ val);
+ return -EINVAL;
+ }
+ ival-cdpe = ti_iodelay_compute_dpe(ival-ref_clk_period,
+ ival-coarse_ref_count,
+ ival-coarse_delay_count, 88);
88? What does that mean... This should be #defined I think.
+static int ti_iodelay_dt_node_to_map(struct pinctrl_dev *pctldev,
+struct device_node *np,
+struct pinctrl_map **map,
+unsigned *num_maps)
If you use the generic bindings this quite complex parsing and
everything associated with it goes away into the core.
+static void ti_iodelay_dt_free_map(struct pinctrl_dev *pctldev,
+ struct pinctrl_map *map, unsigned num_maps)
Dito.
BTW even if you proceed this way I suspect these are verbatim
copies from pinctrl-single so they shold obviouslyt be abstracted
out as library functions in that case.
+/**
+ * ti_iodelay_pinctrl_get_group_pins() - get group pins
+ * @pctldev: pinctrl device representing IODelay device
+ * @gselector: Group selector
+ * @pins: pointer to the pins
+ * @npins: number of pins
+ *
+ * Dummy implementation since we do not track pins, we track configurations
+ * Forced by pinctrl's pinctrl_check_ops()
+ *
+ * Return: -EINVAL
+ */
+static int ti_iodelay_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
+unsigned gselector,
+const unsigned **pins,
+unsigned *npins)
+{
+ /* Dummy implementation - we dont do pin mux */
+ return -EINVAL;
+}
This is not about muxing. It is about enumerating the pins in the
group that will be affected by the setting, which is something you
will want to do when using the generic bindings.
+ group = ti_iodelay_get_group(iod, gselector);
And this seems to be your re-implementation of exactly that pin control
core functionality. Which again should be shared with pinctrl-single if
you anyway go down this path.
I'll halt review here pending discussion on the bindings stuff.
Yours,
Linus Walleij
--
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] gpio: pcf857x: restore the initial line state of all pcf lines
On Wed, Mar 18, 2015 at 2:21 PM, Kishon Vijay Abraham I kis...@ti.com wrote: [Me] Specify exactly what stuff may happen after the reboot notifier. okay, it's assumed the device may be used (active) till the shutdown handler of that particular device is called. In this particular case we are restoring the initial line state of all pcf lines even though we don't know if the devices connected to it are still being active, which might cause a contention as explained by NM [1] OK I understand this, just that I want to know if it is a practical problem, i.e. do you run into it? Does the system lock up? If the reboot notifier gets invoked after the shutdown handler then we could be sure that restoring the initial line state of the pcf lines wouldn't affect the devices connected to it. OK so does it? ftrace is your friend. Yours, Linus Walleij -- 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 4/8] gpio: omap: drop 'gpio' param from omap_gpio_init_irq()
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org The 'gpio' parameter isn't needed any more as it duplicates 'offset' parameter, so drop it. Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 1/8] gpio: omap: convert omap_gpio_is_input() to use gpio offset
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Convert omap_gpio_is_input() to use GPIO offset instead of mask and, in such way, make code simpler and remove few lines of code. Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 8/8] gpio: omap: get rid of GPIO_INDEX() macro
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now OMAP GPIO driver prepared for GPIO_INDEX() macro removing. Do It ;) Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 5/8] gpio: omap: convert gpio irq functions to use GPIO offset
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Convert GPIO IRQ functions to use GPIO offset instead of system GPIO numbers. This allows to drop unneeded conversations between system GPIO - GPIO offset which are done in many places and many times. It is safe to do now because: - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data-hwirq contains GPIO offset This is preparation step before removing: #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 6/8] gpio: omap: get rid of GPIO_BIT() macro
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now OMAP GPIO driver prepared for GPIO_BIT() macro removing. Do it ;) Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/8] gpio: omap: get rid of omap_irq_to_gpio()
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now OMAP GPIO driver prepared for omap_irq_to_gpio() removing. Do it ;) Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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/8] gpio: omap: simplify omap_set_gpio_dataout_x()
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Both functions omap_set_gpio_dataout_reg() and omap_set_gpio_dataout_mask() accept GPIO offset as 'gpio' input parameter, so rename it to 'offset' and drop usage of GPIO_BIT() macro. Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 3/8] gpio: omap: convert debounce functions switch to use gpio offset
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Convert debounce functions to use GPIO offset instead of system GPIO numbers. This allows to drop unneeded conversations between system GPIO - GPIO offset which are done in many places and many times. It is safe to do now because: - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain This is preparation step before removing: #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 09/15] mfd: kill off set_irq_flags usage
On Tue, Jun 9, 2015 at 8:26 PM, Rob Herring r...@kernel.org wrote: set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID - !IRQ_NOREQUEST IRQF_PROBE - !IRQ_NOPROBE IRQF_NOAUTOEN - IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also set IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring r...@kernel.org Cc: Samuel Ortiz sa...@linux.intel.com Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Milo Kim milo@ti.com Cc: Kumar Gala ga...@codeaurora.org Cc: Andy Gross agr...@codeaurora.org Cc: David Brown dav...@codeaurora.org Cc: Tony Lindgren t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org Cc: patc...@opensource.wolfsonmicro.com Cc: linux-arm-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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: [RFT v2 45/48] genirq, gpio: Kill the first parameter 'irq' of irq_flow_handler_t
On Thu, Jun 4, 2015 at 6:13 AM, Jiang Liu jiang@linux.intel.com wrote: Now most IRQ flow handlers make no use of the first parameter 'irq'. And for those who do make use of 'irq', we could easily get the irq number through irq_desc-irq_data-irq. So kill the first parameter 'irq' of irq_flow_handler_t. To ease review, I have split the changes into several parts, though they should be merge as one to support bisecting. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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] usb: dwc3: pci: make better use of gpiod API
On Fri, Jun 12, 2015 at 9:10 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Furthermore there is devm_gpiod_get_optional which is designed to get optional gpios. Also use devm_gpiod_get* because otherwise the gpio might be grabbed by a different driver. Simplify driver accordingly. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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/7] gpio: omap: fix omap_gpio_free to not clean up irq configuration
On Fri, May 22, 2015 at 4:35 PM, Grygorii Strashko grygorii.stras...@linaro.org wrote: This patch fixes following issue: - GPIOn is used as IRQ by some dev, for example PCF8575.INT - gpio6.11 - PCFx driver knows nothing about type of IRQ line (GPIO or not) so it doesn't request gpio and just do request_irq() - If gpio6.11 will be exported through the sysfs and then un-xeported then IRQs from PCFx will not be received any more, because IRQ configuration for gpio6.11 will be cleaned up unconditionally in omap_gpio_free. Fix this by removing all GPIO IRQ specific code from omap_gpio_free() and also do GPIO clean up (change direction to 'in' and disable debounce) only if corresponding GPIO is not used as IRQ too. GPIO IRQ will be properly cleaned up by GPIO irqchip code. Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Can I get an ACK or comment from one of the three (!) maintainers on atleast these non-RFC patches? Yours, Linus Walleij -- 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 05/25] gpio: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
On Wed, May 20, 2015 at 11:59 AM, Jiang Liu jiang@linux.intel.com wrote: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org Are there dependencies on this patch or can I just apply it directly to the GPIO tree? Yours, Linus Walleij -- 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/RFT PATCH 0/7] gpio: omap: rework and fixes
On Fri, May 22, 2015 at 9:03 PM, Tony Lindgren t...@atomide.com wrote: * Grygorii Strashko grygorii.stras...@linaro.org [150522 07:37]: Patches 1-5 seem to work for me, patch 6 does not. So for patches 1-5, please feel free to add: Tested-by: Tony Lindgren t...@atomide.com OK I take this as an excuse to apply patches 1-5 with Tony's test tag. The maintainers can cheer in if they want, I will anyway take the OMAP maintainers test tag as a good quality indication. Yours, Linus Walleij -- 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] gpio: omap: Fix missing raw locks conversion
On Wed, Aug 5, 2015 at 4:37 PM, Axel Lin axel@ingics.com wrote: Fix below build warning: CC drivers/gpio/gpio-omap.o drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_type': drivers/gpio/gpio-omap.c:504:3: warning: passing argument 1 of 'spin_unlock_irqrestore' from incompatible pointer type [enabled by default] include/linux/spinlock.h:360:29: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *' Fixes: commit 4dbada2be460 (gpio: omap: use raw locks for locking) Signed-off-by: Axel Lin axel@ingics.com Fixed by merging in -rc4 and applying this patch for next. Thanks! Yours, Linus Walleij -- 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: [4.2-rc1][PATCH] gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_type
On Fri, Aug 7, 2015 at 9:34 AM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
Hi Tony,
On 08/07/2015 06:36 AM, Tony Lindgren wrote:
* Linus Walleij linus.wall...@linaro.org [150716 01:38]:
On Wed, Jun 24, 2015 at 4:54 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Add missed spin_unlock_irqrestore in omap_gpio_irq_type when
omap_set_gpio_triggering() is failed.
It fixes static checker warning:
drivers/gpio/gpio-omap.c:523 omap_gpio_irq_type()
warn: inconsistent returns 'spin_lock:bank-lock'.
This fixes commit:
1562e4618ded ('gpio: omap: fix error handling in omap_gpio_irq_type')
Reported-by: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Patch applied for fixes.
Linus, looks like we now have a new build warning in Linux next
with the fixes and raw_spinlock_t change, so a merge or a commit
is needed. If you prefer a patch, here's one below.
Yes. It seems merge/rebase issue between fixes next:
- this patch went through fixes and RAW spinlock conversation
patch through -next, and without merge conflicts.
and patch has been posted already by Axel Lin:
http://www.spinics.net/lists/linux-omap/msg121031.html
I merged v4.2-rc4 into my devel branch and applied Axel's
patch to fix this mess. Check that it looks OK now...
Yours,
Linus Walleij
--
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] gpiolib: irqchip: use different lockdep class for each gpio irqchip
On Fri, Aug 14, 2015 at 2:40 PM, Lars-Peter Clausen l...@metafoo.de wrote: On 08/14/2015 02:34 PM, Linus Walleij wrote: [...] Every chip will get their own lock class on the heap. But I think it is a bit kludgy. Is it not possible to have the lock key in struct gpio_chip be a real member instead of a pointer and get a per-chip lock that way? (...) struct lock_class_key lock_key; instead of: struct lock_class_key *lock_key; - problem solved, without kludgy header defines? Lock keys need to be in persistent memory since they have a unlimited life time. Once registered it is expected to exist until the system is reset. Aha I see. OK if we fix the documentation comment I guess we can go with this, even if it makes the header file somewhat hard to read. I have a bit of problem with it, because lockdep instrumentation is supposed to make development easier, not harder, now it helps in one end with lock validation and screws up in another end by creating API headers that are hopeless to read :( Linus -- 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 1/2] gpiolib: irqchip: use different lockdep class for each gpio irqchip
On Mon, Aug 17, 2015 at 2:35 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: Since IRQ chip helpers were introduced drivers lose ability to register separate lockdep classes for each registered GPIO IRQ chip and the gpiolib now is using shared lockdep class for all GPIO IRQ chips (gpiochip_irq_lock_class). As result, lockdep will produce warning when there are min two stacked GPIO chips and all of them are interrupt controllers. HW configuration which generates lockdep warning (TI dra7-evm): (...) Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Roger Quadros rog...@ti.com Reported-by: Roger Quadros rog...@ti.com Tested-by: Roger Quadros rog...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- Changes in v2: - removed accidental change in gpio chip structure description. This v2 patch applied. I see no better alternative. Yours, Linus Walleij -- 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] gpio: omap: use raw locks for locking
On Thu, Feb 12, 2015 at 5:10 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This patch converts gpio_bank.lock from a spin_lock into a raw_spin_lock. The call path to access this lock is always under a raw_spin_lock, for instance - __setup_irq() holds desc-lock with irq off + __irq_set_trigger() + omap_gpio_irq_type() - handle_level_irq() (runs with irqs off therefore raw locks) + mask_ack_irq() + omap_gpio_mask_irq() This fixes the obvious backtrace on -RT. However I noticed two cases where it looks wrong and this is not limited to -RT: - omap_gpio_irq_type() is called with IRQ off and has an conditional call to pm_runtime_get_sync() which may sleep. Either it may happen or it may not happen but pm_runtime_get_sync() should not be called in an atomic section. - omap_gpio_debounce() is holding the lock with IRQs off. + omap2_set_gpio_debounce() + clk_prepare_enable() + clk_prepare() this one might sleep. The number of users of gpiod_set_debounce() / gpio_set_debounce() looks low but still this is not good. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de This doesn't apply to the current development tree. Can you rebase this patch in Torvalds' HEAD, add Javier's ACK and resend? Please put me on the To: line, I have no time to read all mail that I'm only CC on. Yours, Linus Walleij -- 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] gpiolib: irqchip: use different lockdep class for each gpio irqchip
On Thu, Aug 13, 2015 at 4:58 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
Since IRQ chip helpers were introduced drivers lose ability to
register separate lockdep classes for each registered GPIO IRQ
chip and the gpiolib now is using shared lockdep class for
all GPIO IRQ chips (gpiochip_irq_lock_class).
As result, lockdep will produce warning when there are min two
stacked GPIO chips and all of them are interrupt controllers.
HW configuration which generates lockdep warning (TI dra7-evm):
(...)
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Roger Quadros rog...@ti.com
Reported-by: Roger Quadros rog...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Ah, I see...
* implies that if the chip supports IRQs, these IRQs need to be threaded
* as the chip access may sleep when e.g. reading out the IRQ status
* registers.
+ * @exported: flags if the gpiochip is exported for use from sysfs. Private.
* @irq_not_threaded: flag must be set if @can_sleep is set but the
* IRQs don't need to be threaded
*
@@ -126,6 +128,7 @@ struct gpio_chip {
irq_flow_handler_t irq_handler;
unsigned intirq_default_type;
int irq_parent;
+ struct lock_class_key *lock_key;
There is something weird with the kerneldoc. It is documenting something
else but not documenting the new member.
Anyway, so here:
+int _gpiochip_irqchip_add(struct gpio_chip *gpiochip,
+ struct irq_chip *irqchip,
+ unsigned int first_irq,
+ irq_flow_handler_t handler,
+ unsigned int type,
+ struct lock_class_key *lock_key);
+
+#ifdef CONFIG_LOCKDEP
+#define gpiochip_irqchip_add(...) \
+( \
+ ({ \
+ static struct lock_class_key _key; \
+ _gpiochip_irqchip_add(__VA_ARGS__, _key); \
+ }) \
+)
+#else
+#define gpiochip_irqchip_add(...) \
+ _gpiochip_irqchip_add(__VA_ARGS__, NULL)
+#endif
Every chip will get their own lock class on the heap.
But I think it is a bit kludgy.
Is it not possible to have the lock key in struct gpio_chip
be a real member instead of a pointer and get a per-chip
lock that way?
(...)
struct lock_class_key lock_key;
instead of:
struct lock_class_key *lock_key;
- problem solved, without kludgy header defines?
Yours,
Linus Walleij
--
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
