Re: Latest randconfig build errors
On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren t...@atomide.com wrote: drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here Rob, I assume you'll do a patch for this one? oh, I apologize for the late reply, I didn't see this email... There is a patch that we can merge to make tilcdc bool instead of tristate[1], which I suppose is ok for a temporary fix. Although I'm all-ears if someone has a better idea about how to fix this. The problem is that we have multiple sub-devices for different possible panel drivers, so that depending on DT tables, the correct ones get loaded for the hw. But they are all built into a single module. Splitting them into multiple modules will be problematic, as panel drivers which are present really need to get probed before the toplevel drm device.. I suppose in theory it is possible to make drm cope better with dynamically loaded outputs, but I'm not sure that there is any way to do this without breaking userspace which expects that all of the connectors/encoders are present once the drm device is loaded. BR, -R [1] https://patchwork.kernel.org/patch/2376061/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430sdp nfsroot broken with ff5c9059
* Jon Hunter jon-hun...@ti.com [130412 19:22]: On 04/12/2013 07:06 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130410 15:32]: * Jon Hunter jon-hun...@ti.com [130410 15:30]: Are you saying that you want to use the version with that is using the pre-processor definitions? I was thinking that may be we could do that as a clean-up for v3.11 and just use the original version I posted earlier. Seems cleaner to me. No let's do that the preprocessor conversion for v3.11. Hmm looks like there are few more 3430sdp dt nfsroot exposed issues in today's linux next. I don't even see any ethernet devices defined in the omap3430-sdp.dts file. Is this something that you have added on top? Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430. To get nfsroot to behave, I had to have your earlier fix from this thread and also revert a2797bea (gpio/omap: force restore if context loss is not detectable). Otherwise nfsroot fails, but not necessarily every time? Well this patch is going to force a gpio restore everytime we call pm_runtime_get() when the use-count is 0. Yes this is not efficient, however, without this patch you run the risk of context being lost and you would never know. Per the changelog, long term a better solution is needed. It seems that this patch kills the ks8851 GPIO interrupt somehow, at least most of the time. I could not git bisect it down to the commit above, had to manually figure it out.. There may also be DMA related issues, but I don't know for sure any longer. I made a patch to fix SPI PIO mode and then hacked SPI to always use PIO to leave out the DMA related parts. Anyways, will post that separately, let's hope the DMA related issues I saw earlier are also related to dt + a2797bea. Ok, I don't follow that. I am not sure how gpio is related to DMA in this case. I think the DMA issues might be related to the GPIO interrupt not working properly. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Nishanth Menon n...@ti.com [130412 16:43]:
Thanks for checking up. Fixed all of them below, will post part of
series again, only if I need to address further comments in other
patches..
Thanks it seems that the other ones are ready to go, just one
more comment below.
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,95 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon n...@ti.com
+ * Tony Lindgren t...@atomide.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/string.h
+
+static const struct of_device_id omap_clk_of_match[] = {
+ {.compatible = ti,omap-clock,},
+ {},
+};
+
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec: clkspec argument
+ * @data:unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void
*data)
+{
+ struct clk *clk;
+ char clk_name[32];
+ struct device_node *np = clkspec-np;
+
+ snprintf(clk_name, 32, %s_ck, np-name);
+ clk = clk_get(NULL, clk_name);
+ if (IS_ERR(clk)) {
+ pr_err(%s: could not get clock %s(%ld)\n, __func__,
+clk_name, PTR_ERR(clk));
+ goto out;
+ }
+ clk_put(clk);
It seems that clk_put() is actually wrong here. That's because
of_clk_get() should boild down to just the look up of the clock
and then clk_get() on it, so no double clk_get() is done in this
case. Once the consumer driver is done, it will just call clk_put()
on it.
+out:
+ return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:device node
+ *
+ * NOTE: we look up the clock lazily when the consumer driver does
+ * of_clk_get() and initialize a NULL clock here.
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ int res;
+ struct device_node *np = pdev-dev.of_node;
+
+ /* This allows the driver to of_clk_get() */
+ res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+ if (res)
+ dev_err(pdev-dev, could not add provider(%d)\n, res);
+
+ return res;
+}
+
+static struct platform_driver omap_clk_driver = {
+ .probe = omap_clk_probe,
+ .driver = {
+.name = omap_clk,
+.of_match_table = of_match_ptr(omap_clk_of_match),
+},
+};
+
+static int __init omap_clk_init(void)
+{
+ return platform_driver_register(omap_clk_driver);
+}
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION(OMAP Clock driver);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_LICENSE(GPL v2);
Other than that looks OK to me.
Tony
--
To unsubscribe from this list: send the line unsubscribe 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] net: smsc911x: adopt pinctrl support
This patch is derived from 2d4b4520a i2c: omap: adopt pinctrl support:
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch takes advantage of defer probe feature
and pin control in order to wait until pin control probing before
GPIO driver probing.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
drivers/net/ethernet/smsc/smsc911x.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index da5cc9a..3e3547c 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
#include linux/of_device.h
#include linux/of_gpio.h
#include linux/of_net.h
+#include linux/pinctrl/consumer.h
#include smsc911x.h
#define SMSC_CHIPNAME smsc911x
@@ -144,6 +145,8 @@ struct smsc911x_data {
/* regulators */
struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
+
+ struct pinctrl *pins;
};
/* Easy access to information */
@@ -2433,6 +2436,18 @@ static int smsc911x_drv_probe(struct platform_device
*pdev)
if (retval 0)
goto out_disable_resources;
+ pdata-pins = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pdata-pins)) {
+ if (PTR_ERR(pdata-pins) == -EPROBE_DEFER) {
+ retval = -EPROBE_DEFER;
+ goto out_disable_resources;
+ }
+
+ dev_warn(pdev-dev, No pins for smsc911x error: %li\n,
+PTR_ERR(pdata-pins));
+ pdata-pins = NULL;
+ }
+
/* configure irq polarity and type before connecting isr */
if (pdata-config.irq_polarity == SMSC911X_IRQ_POLARITY_ACTIVE_HIGH)
intcfg |= INT_CFG_IRQ_POL_;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe 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] omap: mux: add AM/DM37x gpios
This patch adds GPIO pins found on AM/DM37x. Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- arch/arm/mach-omap2/mux34xx.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/mux34xx.h b/arch/arm/mach-omap2/mux34xx.h index 6543ebf..3f26d29 100644 --- a/arch/arm/mach-omap2/mux34xx.h +++ b/arch/arm/mach-omap2/mux34xx.h @@ -393,6 +393,10 @@ #define OMAP3_CONTROL_PADCONF_SAD2D_SWAKEUP_OFFSET 0xa1c #define OMAP3_CONTROL_PADCONF_JTAG_RTCK_OFFSET 0xa1e #define OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET 0xa20 +#define OMAP3_CONTROL_PADCONF_GPIO_127 0xa24 +#define OMAP3_CONTROL_PADCONF_GPIO_126 0xa26 +#define OMAP3_CONTROL_PADCONF_GPIO_128 0xa28 +#define OMAP3_CONTROL_PADCONF_GPIO_129 0xa2a #define OMAP3_CONTROL_PADCONF_MUX_SIZE \ - (OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET + 0x2) + (OMAP3_CONTROL_PADCONF_GPIO_129 + 0x2) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-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][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:
[0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040:
0x00ff
[0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010:
0x0007
[0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000:
0x0007
And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
[2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
[2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x
And the IRQ source for the network chip (smsc911x) is disabled :-(
Do you have any idea how to (quick) fix this?
A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
*/
#undef DEBUG
+#include linux/gpio.h
#include linux/irq.h
#include linux/kernel.h
#include linux/init.h
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ ret = gpio_request_one(176, GPIOF_IN, smsc911x irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 176);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
pdata = netdev_priv(dev);
dev-irq = irq_res-start;
-irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
+ irq_flags = IRQF_TRIGGER_LOW;
pdata-ioaddr = ioremap_nocache(res-start, res_size);
pdata-dev = dev;
Thanks
-- Christoph
I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).
Any updates on this issue?
For me it works when doing this in the device tree:
+omap3_pmx_wkup {
+ pinctrl-names = default;
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins =
+ 0x5A 0x104 /* gpio_129, INPUT | MODE4 */
+ ;
+ };
+};
+
SNIP
+ lan9221@1500 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 0x1500 0x400;
+ phy-mode = mii;
+ interrupt-parent = gpio5;
+ interrupts = 1 0x2; /* gpio_129, trigger: falling-edge */
+ reg-io-width = 4;
+ vdd33a-supply = reg_vcc3;
+ vddvario-supply = reg_vcc3;
+ pinctrl-names = default;
+ pinctrl-0 = lan9221_pins;
+ };
but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:
+ ret = gpio_request_one(129, GPIOF_IN, lan9221 irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 129);
+ return ret;
+ }
The following patches (already sent mainline) are also applied:
arm/dts: OMAP3: fix pinctrl-single configuration
net: smsc911x: adopt pinctrl support
Thanks
-- Christoph
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] omap: mfd/regulator: twl/core: init order
Hi while testing an omap3 board with device tree support I stumbled upon a bug which is due to wrong initialization order of twl-core and twl-regulator (I suppose): In the boot process they get loaded way too late so that a lot of drivers before where configured wrong or just refuse to load. For example the real time clock driver: The RTC kicks in way before twl_probe() and due to that it configures its register map wrong (at this time twl_priv-twl_id isn't configured yet). Another example is the omap display subsystem. It (DSS) fails loading while trying to register some not yet existent regulators and because it lacks EPROBE_DEFER. USB and MMC is also not working and I'm suspicious of the same cause. Any ideas? Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-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][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
On Mon, 2013-04-01 at 22:05 +0200, Javier Martinez Canillas wrote:
On Mon, Apr 1, 2013 at 6:41 PM, Christoph Fritz
As a quick-fix (hack) I wrote directly to the registers in gpio_probe()
to enable GPIO banks. I now geht this:
[0.214630] omap_gpio_probe, 1133, CM_CLKSEL_PER 0x48005040:
0x00ff
[0.214660] omap_gpio_probe, 1136, CM_ICLKEN_PER 0x48005010:
0x0007
[0.214660] omap_gpio_probe, 1139, CM_FCLKEN_PER 0x48005000:
0x0007
And it works for me. _But_ when I do enable regulator twl4030
(CONFIG_REGULATOR_TWL4030=y) in my config these registers get reset:
[2.935455] smsc911x_open, 1537, CM_CLKSEL_PER 0x48005040: 0x00ff
[2.942291] smsc911x_open, 1540, CM_ICLKEN_PER 0x48005010: 0x00040fff
[2.949066] smsc911x_open, 1543, CM_FCLKEN_PER 0x48005000: 0x
And the IRQ source for the network chip (smsc911x) is disabled :-(
Do you have any idea how to (quick) fix this?
A quick hack is to call gpio_request() explicitly before calling to
irq_set_type() is made.
I've this patch just to make it work until we find a clean solution:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 90c15ee..d594e1d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -14,6 +14,7 @@
*/
#undef DEBUG
+#include linux/gpio.h
#include linux/irq.h
#include linux/kernel.h
#include linux/init.h
@@ -1528,6 +1529,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ ret = gpio_request_one(176, GPIOF_IN, smsc911x irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 176);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
This solves the issue of the non-initialized GPIO bank before that
makes the kernel to hang. Since I've to configure the IRQ polarity as
active low level-sensitive on my board and the flags are not set by
the IRQ core, I've another ugly hack that forces this:
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc
index da5cc9a..27e46f9 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2390,6 +2390,9 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
pdata = netdev_priv(dev);
dev-irq = irq_res-start;
-irq_flags = irq_res-flags IRQF_TRIGGER_MASK;
+ irq_flags = IRQF_TRIGGER_LOW;
pdata-ioaddr = ioremap_nocache(res-start, res_size);
pdata-dev = dev;
Thanks
-- Christoph
I hope to find some time this week to work on this and at least find a
solution for the second issue (IORESOURCE_IRQ struct resource flags
not being set).
Any updates on this issue?
Yes, my last approach to solve the IRQ flags not saved on the
IORESOURCE_IRQ struct resource issue is to add a new
irq_get_trigger_type() function to get the edge/level flags from an
IRQ number and use that function on the smsc911x driver probe function
to get the IRQ flags.
The patch-set is composed of these patches:
[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ [2]
and the cover letter is this [3]
It would be great if you can test these patches and give some feedback.
For me it works when doing this in the device tree:
+omap3_pmx_wkup {
+ pinctrl-names = default;
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins =
+ 0x5A 0x104 /* gpio_129, INPUT | MODE4 */
+ ;
+ };
+};
+
SNIP
+ lan9221@1500 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 0x1500 0x400;
If I understood correctly your smsc ethernet chip is connected to the
OMAP through the GPMC, then you should use a chip-select, base address
and size instead of the physical address and size.
Do you have commit 5330dc161 (ARM: OMAP2+: Add GPMC DT support for
Ethernet child nodes) already on your tree? [4]
+ phy-mode = mii;
+ interrupt-parent = gpio5;
+ interrupts = 1 0x2; /* gpio_129, trigger: falling-edge */
I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
type flag on the smsc911x driver probe function?
+ reg-io-width = 4;
+ vdd33a-supply = reg_vcc3;
+ vddvario-supply = reg_vcc3;
+ pinctrl-names = default;
+ pinctrl-0 = lan9221_pins;
+ };
but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:
+ ret = gpio_request_one(129, GPIOF_IN, lan9221 irq);
+ if (ret) {
+
Re: [PATCH] net: smsc911x: adopt pinctrl support
On Sat, Apr 13, 2013 at 7:22 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
This patch is derived from 2d4b4520a i2c: omap: adopt pinctrl support:
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch takes advantage of defer probe feature
and pin control in order to wait until pin control probing before
GPIO driver probing.
Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
drivers/net/ethernet/smsc/smsc911x.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index da5cc9a..3e3547c 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,6 +59,7 @@
#include linux/of_device.h
#include linux/of_gpio.h
#include linux/of_net.h
+#include linux/pinctrl/consumer.h
#include smsc911x.h
#define SMSC_CHIPNAME smsc911x
@@ -144,6 +145,8 @@ struct smsc911x_data {
/* regulators */
struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
+
+ struct pinctrl *pins;
};
/* Easy access to information */
@@ -2433,6 +2436,18 @@ static int smsc911x_drv_probe(struct platform_device
*pdev)
if (retval 0)
goto out_disable_resources;
+ pdata-pins = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pdata-pins)) {
+ if (PTR_ERR(pdata-pins) == -EPROBE_DEFER) {
+ retval = -EPROBE_DEFER;
+ goto out_disable_resources;
+ }
+
+ dev_warn(pdev-dev, No pins for smsc911x error: %li\n,
+PTR_ERR(pdata-pins));
+ pdata-pins = NULL;
+ }
+
/* configure irq polarity and type before connecting isr */
if (pdata-config.irq_polarity == SMSC911X_IRQ_POLARITY_ACTIVE_HIGH)
intcfg |= INT_CFG_IRQ_POL_;
--
1.7.10.4
Hi Christoph,
This is handled from the device core after from v3.9.
Please take a loot at this:
http://marc.info/?l=linux-kernelm=135887740715083w=2
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-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][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, 2013-04-13 at 20:30 +0200, Javier Martinez Canillas wrote:
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Yes, my last approach to solve the IRQ flags not saved on the
IORESOURCE_IRQ struct resource issue is to add a new
irq_get_trigger_type() function to get the edge/level flags from an
IRQ number and use that function on the smsc911x driver probe function
to get the IRQ flags.
The patch-set is composed of these patches:
[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ [2]
and the cover letter is this [3]
It would be great if you can test these patches and give some feedback.
For me it works when doing this in the device tree:
+omap3_pmx_wkup {
+ pinctrl-names = default;
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins =
+ 0x5A 0x104 /* gpio_129, INPUT | MODE4 */
+ ;
+ };
+};
+
SNIP
+ lan9221@1500 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 0x1500 0x400;
If I understood correctly your smsc ethernet chip is connected to the
OMAP through the GPMC, then you should use a chip-select, base address
and size instead of the physical address and size.
Yes, it's connected with GPMC.
Do you have commit 5330dc161 (ARM: OMAP2+: Add GPMC DT support for
Ethernet child nodes) already on your tree? [4]
No I haven't.
+ phy-mode = mii;
+ interrupt-parent = gpio5;
+ interrupts = 1 0x2; /* gpio_129, trigger: falling-edge
*/
I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
type flag on the smsc911x driver probe function?
I added printks for irq_res-flags and irq_flags:
[1.259857] smsc911x_drv_probe, 2396, irq_res-flags 0x0400
[1.266113] smsc911x_drv_probe, 2397, irq_flags 0x
So the answer is no. But weird that the smsc911x works nevertheless.
+ reg-io-width = 4;
+ vdd33a-supply = reg_vcc3;
+ vddvario-supply = reg_vcc3;
+ pinctrl-names = default;
+ pinctrl-0 = lan9221_pins;
+ };
but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:
+ ret = gpio_request_one(129, GPIOF_IN, lan9221 irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 129);
+ return ret;
+ }
Yes, this hack is still needed until we figure out how to enable the
GPIO bank before a call to request_irq() is made.
The following patches (already sent mainline) are also applied:
arm/dts: OMAP3: fix pinctrl-single configuration
net: smsc911x: adopt pinctrl support
Yes, but that patch is not needed anymore from 3.9, look at this [5]
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg88241.html
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg88225.html
[3]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg88224.html
[4]: https://patchwork.kernel.org/patch/2273851/
[5]: http://marc.info/?l=linux-kernelm=135887740715083w=2
Thanks
-- Christoph
--
To unsubscribe from this list: send the line unsubscribe linux-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][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Apr 13, 2013 at 8:59 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
On Sat, 2013-04-13 at 20:30 +0200, Javier Martinez Canillas wrote:
On Sat, Apr 13, 2013 at 7:42 PM, Christoph Fritz
chf.fr...@googlemail.com wrote:
Yes, my last approach to solve the IRQ flags not saved on the
IORESOURCE_IRQ struct resource issue is to add a new
irq_get_trigger_type() function to get the edge/level flags from an
IRQ number and use that function on the smsc911x driver probe function
to get the IRQ flags.
The patch-set is composed of these patches:
[PATCH v2 1/2] genirq: add function to get IRQ edge/level flags [1]
[PATCH 2/2] net: smsc911x: get IRQ flags from chip if not present in
IORESOURCE_IRQ [2]
and the cover letter is this [3]
It would be great if you can test these patches and give some feedback.
For me it works when doing this in the device tree:
+omap3_pmx_wkup {
+ pinctrl-names = default;
+
+ lan9221_pins: pinmux_lan9221_pins {
+ pinctrl-single,pins =
+ 0x5A 0x104 /* gpio_129, INPUT | MODE4 */
+ ;
+ };
+};
+
SNIP
+ lan9221@1500 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 0x1500 0x400;
If I understood correctly your smsc ethernet chip is connected to the
OMAP through the GPMC, then you should use a chip-select, base address
and size instead of the physical address and size.
Yes, it's connected with GPMC.
Do you have commit 5330dc161 (ARM: OMAP2+: Add GPMC DT support for
Ethernet child nodes) already on your tree? [4]
No I haven't.
In that case you should have that commit on your tree. But the GPMC
driver has changed a lot for 3.9 and 3.10, so I recommend you to base
your work on linux-next that has the latest changes.
And then you will need something like this on your DT (in this example
is using the chip-select 5 but adjust according to your board):
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
reg = 0x6e00 0x1000;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
#address-cells = 2;
#size-cells = 1;
ranges = 5 0 0x2c00 0x100;
ethernet@5,0 {
pinctrl-names = default;
pinctrl-0 = lan9221_pins;
compatible = smsc,lan9221, smsc,lan9115;
reg = 5 0 0xff;
bank-width = 2;
gpmc,mux-add-data;
gpmc,cs-on-ns = 0;
gpmc,cs-rd-off-ns = 186;
gpmc,cs-wr-off-ns = 186;
gpmc,adv-on-ns = 12;
gpmc,adv-rd-off-ns = 48;
gpmc,adv-wr-off-ns = 48;
gpmc,oe-on-ns = 54;
gpmc,oe-off-ns = 168;
gpmc,we-on-ns = 54;
gpmc,we-off-ns = 168;
gpmc,rd-cycle-ns = 186;
gpmc,wr-cycle-ns = 186;
gpmc,access-ns = 114;
gpmc,page-burst-access-ns = 6;
gpmc,bus-turnaround-ns = 12;
gpmc,cycle2cycle-delay-ns = 18;
gpmc,wr-data-mux-bus-ns = 90;
gpmc,wr-access-ns = 186;
gpmc,cycle2cycle-samecsen;
gpmc,cycle2cycle-diffcsen;
interrupt-parent = gpio5;
interrupts = 1 0x2;
reg-io-width = 4;
vdd33a-supply = reg_vcc3;
vmmc_aux-supply = vdd33a;
vddvario-supply = reg_vcc3;
};
};
+ phy-mode = mii;
+ interrupt-parent = gpio5;
+ interrupts = 1 0x2; /* gpio_129, trigger: falling-edge
*/
I'm confused here, do you get the IRQ_TYPE_EDGE_FALLING (0x2) trigger
type flag on the smsc911x driver probe function?
I added printks for irq_res-flags and irq_flags:
[1.259857] smsc911x_drv_probe, 2396, irq_res-flags 0x0400
[1.266113] smsc911x_drv_probe, 2397, irq_flags 0x
So the answer is no. But weird that the smsc911x works nevertheless.
Yes, that's what I thought. You will need patch [1] and [2] to allow
smsc911x driver to get the GPIO-IRQ trigger type flags.
With those patches + linux-next + the device node I posted above +
your gpio_request_one() hack on gpmc_probe_dt() should be enough to
have your smsc ethernet chip working on your board.
+ reg-io-width = 4;
+ vdd33a-supply = reg_vcc3;
+ vddvario-supply = reg_vcc3;
+ pinctrl-names = default;
+ pinctrl-0 = lan9221_pins;
+ };
but in arch/arm/mach-omap2/gpmc.c gpmc_probe_dt() I still need this
hack:
+ ret = gpio_request_one(129, GPIOF_IN, lan9221 irq);
+ if (ret) {
+ pr_err(Failed to request IRQ GPIO%d\n, 129);
+ return ret;
+ }
Yes, this hack is still needed until
Re: Latest randconfig build errors
On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote: On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren t...@atomide.com wrote: drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here Rob, I assume you'll do a patch for this one? oh, I apologize for the late reply, I didn't see this email... There is a patch that we can merge to make tilcdc bool instead of tristate[1], which I suppose is ok for a temporary fix. Although I'm all-ears if someone has a better idea about how to fix this. The problem is that we have multiple sub-devices for different possible panel drivers, so that depending on DT tables, the correct ones get loaded for the hw. But they are all built into a single module. Splitting them into multiple modules will be problematic, as panel drivers which are present really need to get probed before the toplevel drm device.. You could look at the Tegra driver. I had to solve a similar problem there. What I did is basically parse the DT in the host1x driver and add all device nodes which are required by DRM to a list. Later when the individual devices are probed they are removed from that list, so that when the list becomes empty we are sure that all required devices are there and only then call the drm_platform_init() function. This fits very well with how Tegra hardware is designed because host1x is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is probed before any of its children and it can easily parse the DT upfront and initialize the list of required devices. I suppose in theory it is possible to make drm cope better with dynamically loaded outputs, but I'm not sure that there is any way to do this without breaking userspace which expects that all of the connectors/encoders are present once the drm device is loaded. I had been thinking about this on and off for a while, but I haven't come up with anything concrete. Ideally we could just have some kind of event that userspace would listen for, so that new outputs can be dynamically added and userspace informed about them. Last time I checked most of the helpers assumed that the complete output configuration is known when the DRM device is registered, so some major rework will be required to efficiently make use of such dynamicity. Thierry pgpUedh6e2UTT.pgp Description: PGP signature
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Apr 12, 2013 at 12:47 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 04/11/2013 04:16 PM, Linus Walleij wrote:
On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 04/10/2013 03:28 PM, Linus Walleij wrote:
So the only reason I'm rambing on about this is that it breaks the
I'm not sure I understand this paragraph; what is it in the line above.
If it is this patch, then should breaks be re-establishes?
No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernelm=136334655902407w=2
which is stating a question to grand, and contains the below
hunk:
+static int gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return gpio_request(irq_to_gpio(bank, d-irq), gpio-irq);
+}
irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
OK, right. sorry for being so confused/confusing.
Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
more like omap_gpio__irq_request() too, so the names don't look like
they'd clash with global functions. (__ added for clarity but probably
only one _ at a time)
Stephen, Linus,
Is the following inlined patch [1] what you were thinking that would
be the right approach?
With this patch an explicit call to call gpio_request() before a call
to chip-irq_set_type() is needed. I've tested both with DT and
without DT where a explicit call to gpio_request() is made and it
works in both cases. So it shouldn't have a functional change for
non-DT cases as far as I know.
If you agree with [1] then I'll split in two patches (one that adds
the irq_request function pointer to irq_chip and another one that adds
the implementation for gpio-omap) and send as a patch-set. I just
thought that it would be easier for you if I posted here an inlined
patch so you could have context.
Thanks a lot for your feedback and best regards,
Javier
[1]
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 685e850..e035e64 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -811,6 +811,13 @@ static void gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
+static int omap_gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return omap_gpio_request(bank-chip, d-hwirq);
+}
+
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.irq_shutdown = gpio_irq_shutdown,
@@ -819,6 +826,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .irq_request= omap_gpio_irq_request,
};
/*-*/
@@ -1028,6 +1036,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank,
unsigned int irq_start,
ct-chip.irq_mask = irq_gc_mask_set_bit;
ct-chip.irq_unmask = irq_gc_mask_clr_bit;
ct-chip.irq_set_type = gpio_irq_type;
+ ct-chip.irq_request = omap_gpio_irq_request;
if (bank-regs-wkup_en)
ct-chip.irq_set_wake = gpio_wake_enable,
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 0e8e3a6..85596cc 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -303,6 +303,7 @@ struct irq_chip {
void(*irq_shutdown)(struct irq_data *data);
void(*irq_enable)(struct irq_data *data);
void(*irq_disable)(struct irq_data *data);
+ int (*irq_request)(struct irq_data *data);
void(*irq_ack)(struct irq_data *data);
void(*irq_mask)(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index fa17855..a4bd4f7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -588,6 +588,12 @@ int __irq_set_trigger(struct irq_desc *desc,
unsigned int irq,
unmask = 1;
}
+ if (chip-irq_request) {
+ ret = chip-irq_request(desc-irq_data);
+ if (ret)
+ return ret;
+ }
+
/* caller masked out all except trigger mode flags */
ret = chip-irq_set_type(desc-irq_data, flags);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest randconfig build errors
On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Sat, Apr 13, 2013 at 08:54:22AM -0400, Rob Clark wrote: On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren t...@atomide.com wrote: drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here Rob, I assume you'll do a patch for this one? oh, I apologize for the late reply, I didn't see this email... There is a patch that we can merge to make tilcdc bool instead of tristate[1], which I suppose is ok for a temporary fix. Although I'm all-ears if someone has a better idea about how to fix this. The problem is that we have multiple sub-devices for different possible panel drivers, so that depending on DT tables, the correct ones get loaded for the hw. But they are all built into a single module. Splitting them into multiple modules will be problematic, as panel drivers which are present really need to get probed before the toplevel drm device.. You could look at the Tegra driver. I had to solve a similar problem there. What I did is basically parse the DT in the host1x driver and add all device nodes which are required by DRM to a list. Later when the individual devices are probed they are removed from that list, so that when the list becomes empty we are sure that all required devices are there and only then call the drm_platform_init() function. thx, ok, I'll have a look at this This fits very well with how Tegra hardware is designed because host1x is the parent for all DRM subdevices (DC, RGB/LVDS, HDMI, ...). So it is probed before any of its children and it can easily parse the DT upfront and initialize the list of required devices. I suppose in theory it is possible to make drm cope better with dynamically loaded outputs, but I'm not sure that there is any way to do this without breaking userspace which expects that all of the connectors/encoders are present once the drm device is loaded. I had been thinking about this on and off for a while, but I haven't come up with anything concrete. Ideally we could just have some kind of event that userspace would listen for, so that new outputs can be dynamically added and userspace informed about them. Last time I checked most of the helpers assumed that the complete output configuration is known when the DRM device is registered, so some major rework will be required to efficiently make use of such dynamicity. I'm less worried about the kernel re-work.. more worried about the fact that we have no way to know whether userspace knows to listen for this new event. So anything down this path could, I think, be considered as breaking userspace. I think in the end, we need some way to have sort of dummy connectors for output drivers which might or might not be probed, so that from userspace perspective, non-present panels appear as displays that are not plugged in. BR, -R Thierry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
