Re: [PATCH 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare
Hi, On Fri, Mar 15, 2013 at 11:36:00AM +0530, Vivek Gautam wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Felipe Balbi ba...@ti.com CC: Kukjin Kim kgene@samsung.com --- drivers/usb/dwc3/dwc3-exynos.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 66ca9ac..b03f609 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) exynos-dev = dev; exynos-clk = clk; - clk_enable(exynos-clk); + clk_prepare_enable(exynos-clk); eventually we need to pass this clock handling to dwc3/core.c. Just make sure it's optional since not all platforms need it. True, as of now i could see only exynos platform getting a device clock for dwc3-glue. So, if not all platforms need to do this, why should we plan to move this to dwc3/core.c ? what if dwc3.ko's probe fail ? Clock will be left enabled ;-) I guess the best way would be to handle clocks via -runtime_suspend()/-runtime_resume() ?? Right, but there was a doubt actually if you can please clear that. In device probe, after enabling runtime_pm we would need to 'pm_runtime_get_sync' the device. Thereby, in runtime_resume the clocks will be enabled. Now as soon as the device probe finishes, the device will go in suspend state, calling runtime_suspend and the clocks would be disabled. Now would it be possible for the controller to detect any connect/disconnect. it depends on how you have configured your core in coreConsultant and how you're implementing the actual IP. If you have retention flip-flops then gating clocks (but not cutting Vcc) will not loose context and, if PHYs are still enabled, you will see new connect events. But that part of PM optimization has to be done as a last step, as it tends to break things apart. -- balbi signature.asc Description: Digital signature
Re: [PATCH 8/8] ARM: OMAP5: clock: No Freqsel on OMAP5 devices
On Wednesday 20 February 2013 08:57 PM, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
OMAP5 does not have freqsel either, so add the missing
checks for !soc_is_omap54xx()
Reported-by: Archit Taneja arc...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 0a02aab5..6e3811b 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -310,7 +310,8 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap
*clk, u16 freqsel)
* Set jitter correction. No jitter correction for OMAP4 and 3630
* since freqsel field is no longer present
*/
- if (!soc_is_am33xx() !cpu_is_omap44xx() !cpu_is_omap3630()) {
+ if (!soc_is_am33xx() !cpu_is_omap44xx() !cpu_is_omap3630()
+ !soc_is_omap54xx()) {
After re-looking at the freqsel patch, since the feature is available on
only OMAP343X devices, its is better to just check that device to
avoid future patching.
For the record, updated patch end of the email.
Regards,
Santosh
From c31041957873bc524fe5d4fcd96688dc0d02e2db Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Tue, 29 Jan 2013 18:33:49 +0530
Subject: [PATCH 8/8] ARM: OMAP5: clock: No Freqsel on OMAP5 devices too
OMAP5 does not have freqsel either, so checks needs to be extended.
Infact only OMAP343X devices has the freqsel support, so fix the check
accordingly so that future patching can be avoided.
Reported-by: Archit Taneja arc...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3aed4b0..ae84c9d 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -307,10 +307,10 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap
*clk, u16 freqsel)
_omap3_noncore_dpll_bypass(clk);
/*
-* Set jitter correction. No jitter correction for OMAP4 and 3630
-* since freqsel field is no longer present
+* Set jitter correction. Jitter correction applicable for OMAP343X
+* only since freqsel field is no longer present on other devices.
*/
- if (!soc_is_am33xx() !cpu_is_omap44xx() !cpu_is_omap3630()) {
+ if (cpu_is_omap343x()) {
v = __raw_readl(dd-control_reg);
v = ~dd-freqsel_mask;
v |= freqsel __ffs(dd-freqsel_mask);
@@ -500,9 +500,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned
long rate,
if (dd-last_rounded_rate == 0)
return -EINVAL;
- /* No freqsel on AM335x, OMAP4 and OMAP3630 */
- if (!soc_is_am33xx() !cpu_is_omap44xx()
- !cpu_is_omap3630()) {
+ /* Freqsel is available only on OMAP343X devices */
+ if (cpu_is_omap343x()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd-last_rounded_n);
WARN_ON(!freqsel);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe 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 v3] drivers: video: use module_platform_driver_probe()
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Howells dhowe...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
Notes:
v3:
- add missing drivers: amifb, atmel_lcdfb, vrfb
- split patch set to each maintainer to easy up respin
v2:
- rebased over linux-next and remove already converted drivers
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c| 13 +
drivers/video/omap2/vrfb.c | 13 +
drivers/video/sh_mipi_dsi.c| 12 +---
drivers/video/sh_mobile_hdmi.c | 12 +---
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 7fa1bf8..03e2de2 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
},
};
-static int __init amifb_init(void)
-{
- return platform_driver_probe(amifb_driver, amifb_probe);
-}
-
-module_init(amifb_init);
-
-static void __exit amifb_exit(void)
-{
- platform_driver_unregister(amifb_driver);
-}
-
-module_exit(amifb_exit);
+return module_platform_driver_probe(amifb_driver, amifb_probe);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:amiga-video);
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 12cf5f3..654e102 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1150,18 +1150,7 @@ static struct platform_driver atmel_lcdfb_driver = {
},
};
-static int __init atmel_lcdfb_init(void)
-{
- return platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
-}
-
-static void __exit atmel_lcdfb_exit(void)
-{
- platform_driver_unregister(atmel_lcdfb_driver);
-}
-
-module_init(atmel_lcdfb_init);
-module_exit(atmel_lcdfb_exit);
+module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
MODULE_DESCRIPTION(AT91/AT32 LCD Controller framebuffer driver);
MODULE_AUTHOR(Nicolas Ferre nicolas.fe...@atmel.com);
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 10560ef..5261229 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -397,18 +397,7 @@ static struct platform_driver vrfb_driver = {
.remove = __exit_p(vrfb_remove),
};
-static int __init vrfb_init(void)
-{
- return platform_driver_probe(vrfb_driver, vrfb_probe);
-}
-
-static void __exit vrfb_exit(void)
-{
- platform_driver_unregister(vrfb_driver);
-}
-
-module_init(vrfb_init);
-module_exit(vrfb_exit);
+module_platform_driver_probe(vrfb_driver, vrfb_probe);
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
MODULE_DESCRIPTION(OMAP VRFB);
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 701b461..6cad530 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -581,17 +581,7 @@ static struct platform_driver sh_mipi_driver = {
},
};
-static int __init sh_mipi_init(void)
-{
- return platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
-}
-module_init(sh_mipi_init);
-
-static void __exit sh_mipi_exit(void)
-{
- platform_driver_unregister(sh_mipi_driver);
-}
-module_exit(sh_mipi_exit);
+module_platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile MIPI DSI driver);
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 930e550..bfe4728 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1445,17 +1445,7 @@ static struct platform_driver sh_hdmi_driver = {
},
};
-static int __init sh_hdmi_init(void)
-{
- return platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
-}
-module_init(sh_hdmi_init);
-
-static void __exit sh_hdmi_exit(void)
-{
- platform_driver_unregister(sh_hdmi_driver);
-}
-module_exit(sh_hdmi_exit);
+module_platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile HDMI driver);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-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] omap2: twl-common: Add default power configuration
Hi Tony, On 03/12/2013 05:57 PM, Tony Lindgren wrote: Sorry looks like this got missed. I suggest Peter collects the twl patches and then provides me + mfd + asoc and whoever needs the pull requests. OK. Lets get things going forward. I have sent a pull request for you with this patch. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/14/2013 06:54 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130314 08:45]:
OK. Let me know how the below patch looks. After that, the board code
will look like.
static struct usbhs_phy_data phy_data[] = {
{
.reset_gpio = 147,
.vcc_gpio = 148
.vcc_polarity = 1,
.phy_id = nop_usb_xceiv.2,
},
{}, /* Terminator */
};
usbhs_init_phys(phy_data);
Great, looks good to me.
Patch to implement usbhs_init_phys();
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..b9d6bff 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,12 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/dma-mapping.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/string.h
#include asm/io.h
+#include asm/gpio.h
Please change these both to linux/io.h and linux/gpio.h.
OK.
#include soc.h
#include omap_device.h
@@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
}
}
+static const char *reset_supply = reset;
+static const char *vcc_supply = vcc;
+
+/* Template for PHY regulators */
+static struct regulator_consumer_supply hsusb_reg_supplies[] = {
+{ /* .supply .dev_name filled later */ },
+};
+
+static struct regulator_init_data hsusb_reg_data = {
+.constraints = {
+.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+},
+.consumer_supplies = hsusb_reg_supplies,
+.num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies),
+};
+
+static struct fixed_voltage_config hsusb_reg_config = {
+/* .supply_name filled later */
+.microvolts = 330,
+.gpio = -1, /* updated later */
+.startup_delay = 7, /* 70msec */
+.enable_high = 1, /* updated later */
+.enabled_at_boot = 0, /* keep in RESET */
+/* .init_data filled later */
+};
+
+static struct platform_device_info hsusb_reg_pdev_info = {
+.name = reg-fixed-voltage,
+.id = PLATFORM_DEVID_AUTO,
+};
+
+int __init usbhs_init_phys(struct usbhs_phy_data *phy)
+{
+struct regulator_consumer_supply *supplies;
+struct regulator_init_data *reg_data;
+struct fixed_voltage_config *config;
+char *supply_name;
+int i;
+
+
+for (i = 1; i = OMAP3_HS_USB_PORTS; i++) {
Maybe pass the number of ports to initialize too to the
function? Might be more future proof, although it will only
be needed until we have converted to DT.
OK. I'll add a port index parameter to the usbhs_phy_data structure
to indicate which port the data belongs to and a number of ports
to usbhs_init_phys()
board code can then do
static struct usbhs_phy_data phy_data[] = {
{
.port = 1, /* First USB port */
.reset_gpio = 147,
.vcc_gpio = 148
.vcc_polarity = 1,
.phy_id = nop_usb_xceiv.2,
},
};
usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
+
+if (!phy-phy_id) /* Terminator ? */
+break;
+
+if (!gpio_is_valid(phy-reset_gpio))
+goto check_vcc;
+
+supplies = kmemdup(hsusb_reg_supplies,
+ARRAY_SIZE(hsusb_reg_supplies) *
+sizeof(struct regulator_consumer_supply),
+GFP_KERNEL);
+if (!supplies)
+return -ENOMEM;
+
+supplies-supply = reset_supply;
+supplies-dev_name = phy-phy_id;
+
+reg_data = kmemdup(hsusb_reg_data, sizeof(hsusb_reg_data),
+GFP_KERNEL);
+if (!reg_data)
+return -ENOMEM;
+
+reg_data-consumer_supplies = supplies;
+
+config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
+GFP_KERNEL);
+if (!config)
+return -ENOMEM;
+
+supply_name = kmalloc(14, GFP_KERNEL);
+if (!supply_name)
+return -ENOMEM;
+
+scnprintf(supply_name, 13, hsusb%d_reset, i);
+config-supply_name = supply_name;
+config-gpio = phy-reset_gpio;
+config-init_data = reg_data;
+
+hsusb_reg_pdev_info.data = config;
+hsusb_reg_pdev_info.size_data = sizeof(hsusb_reg_config);
+platform_device_register_full(hsusb_reg_pdev_info);
+
+check_vcc:
+if (!gpio_is_valid(phy-vcc_gpio))
+goto next;
+
+supplies = kmemdup(hsusb_reg_supplies,
+ARRAY_SIZE(hsusb_reg_supplies) *
+sizeof(struct regulator_consumer_supply),
+
Re: [PATCH v3] drivers: video: use module_platform_driver_probe()
On 03/15/2013 10:00 AM, Fabio Porcedda :
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Nicolas Ferre nicolas.fe...@atmel.com
For atmel_lcdfb.c:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks Fabio.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Howells dhowe...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
Notes:
v3:
- add missing drivers: amifb, atmel_lcdfb, vrfb
- split patch set to each maintainer to easy up respin
v2:
- rebased over linux-next and remove already converted drivers
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c| 13 +
drivers/video/omap2/vrfb.c | 13 +
drivers/video/sh_mipi_dsi.c| 12 +---
drivers/video/sh_mobile_hdmi.c | 12 +---
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 7fa1bf8..03e2de2 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
},
};
-static int __init amifb_init(void)
-{
- return platform_driver_probe(amifb_driver, amifb_probe);
-}
-
-module_init(amifb_init);
-
-static void __exit amifb_exit(void)
-{
- platform_driver_unregister(amifb_driver);
-}
-
-module_exit(amifb_exit);
+return module_platform_driver_probe(amifb_driver, amifb_probe);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:amiga-video);
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 12cf5f3..654e102 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1150,18 +1150,7 @@ static struct platform_driver atmel_lcdfb_driver = {
},
};
-static int __init atmel_lcdfb_init(void)
-{
- return platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
-}
-
-static void __exit atmel_lcdfb_exit(void)
-{
- platform_driver_unregister(atmel_lcdfb_driver);
-}
-
-module_init(atmel_lcdfb_init);
-module_exit(atmel_lcdfb_exit);
+module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
MODULE_DESCRIPTION(AT91/AT32 LCD Controller framebuffer driver);
MODULE_AUTHOR(Nicolas Ferre nicolas.fe...@atmel.com);
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 10560ef..5261229 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -397,18 +397,7 @@ static struct platform_driver vrfb_driver = {
.remove = __exit_p(vrfb_remove),
};
-static int __init vrfb_init(void)
-{
- return platform_driver_probe(vrfb_driver, vrfb_probe);
-}
-
-static void __exit vrfb_exit(void)
-{
- platform_driver_unregister(vrfb_driver);
-}
-
-module_init(vrfb_init);
-module_exit(vrfb_exit);
+module_platform_driver_probe(vrfb_driver, vrfb_probe);
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
MODULE_DESCRIPTION(OMAP VRFB);
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 701b461..6cad530 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -581,17 +581,7 @@ static struct platform_driver sh_mipi_driver = {
},
};
-static int __init sh_mipi_init(void)
-{
- return platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
-}
-module_init(sh_mipi_init);
-
-static void __exit sh_mipi_exit(void)
-{
- platform_driver_unregister(sh_mipi_driver);
-}
-module_exit(sh_mipi_exit);
+module_platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile MIPI DSI driver);
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 930e550..bfe4728 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1445,17 +1445,7 @@ static struct platform_driver sh_hdmi_driver = {
},
};
-static int __init sh_hdmi_init(void)
-{
- return platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
-}
-module_init(sh_hdmi_init);
-
-static void __exit sh_hdmi_exit(void)
-{
- platform_driver_unregister(sh_hdmi_driver);
-}
-module_exit(sh_hdmi_exit);
+module_platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile HDMI driver);
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-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] drivers: video: use module_platform_driver_probe()
On Fri, Mar 15, 2013 at 10:28 AM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
On 03/15/2013 10:00 AM, Fabio Porcedda :
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Nicolas Ferre nicolas.fe...@atmel.com
For atmel_lcdfb.c:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks Fabio.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Howells dhowe...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
If you prefer a patch for each driver I will split the patch.
Best regards
Fabio Porcedda
Notes:
v3:
- add missing drivers: amifb, atmel_lcdfb, vrfb
- split patch set to each maintainer to easy up respin
v2:
- rebased over linux-next and remove already converted drivers
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c| 13 +
drivers/video/omap2/vrfb.c | 13 +
drivers/video/sh_mipi_dsi.c| 12 +---
drivers/video/sh_mobile_hdmi.c | 12 +---
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 7fa1bf8..03e2de2 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
},
};
-static int __init amifb_init(void)
-{
- return platform_driver_probe(amifb_driver, amifb_probe);
-}
-
-module_init(amifb_init);
-
-static void __exit amifb_exit(void)
-{
- platform_driver_unregister(amifb_driver);
-}
-
-module_exit(amifb_exit);
+return module_platform_driver_probe(amifb_driver, amifb_probe);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:amiga-video);
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 12cf5f3..654e102 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1150,18 +1150,7 @@ static struct platform_driver atmel_lcdfb_driver = {
},
};
-static int __init atmel_lcdfb_init(void)
-{
- return platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
-}
-
-static void __exit atmel_lcdfb_exit(void)
-{
- platform_driver_unregister(atmel_lcdfb_driver);
-}
-
-module_init(atmel_lcdfb_init);
-module_exit(atmel_lcdfb_exit);
+module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
MODULE_DESCRIPTION(AT91/AT32 LCD Controller framebuffer driver);
MODULE_AUTHOR(Nicolas Ferre nicolas.fe...@atmel.com);
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 10560ef..5261229 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -397,18 +397,7 @@ static struct platform_driver vrfb_driver = {
.remove = __exit_p(vrfb_remove),
};
-static int __init vrfb_init(void)
-{
- return platform_driver_probe(vrfb_driver, vrfb_probe);
-}
-
-static void __exit vrfb_exit(void)
-{
- platform_driver_unregister(vrfb_driver);
-}
-
-module_init(vrfb_init);
-module_exit(vrfb_exit);
+module_platform_driver_probe(vrfb_driver, vrfb_probe);
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
MODULE_DESCRIPTION(OMAP VRFB);
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 701b461..6cad530 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -581,17 +581,7 @@ static struct platform_driver sh_mipi_driver = {
},
};
-static int __init sh_mipi_init(void)
-{
- return platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
-}
-module_init(sh_mipi_init);
-
-static void __exit sh_mipi_exit(void)
-{
- platform_driver_unregister(sh_mipi_driver);
-}
-module_exit(sh_mipi_exit);
+module_platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile MIPI DSI driver);
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 930e550..bfe4728 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1445,17 +1445,7 @@ static struct platform_driver sh_hdmi_driver = {
},
};
-static int __init sh_hdmi_init(void)
-{
- return platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
-}
-module_init(sh_hdmi_init);
-
-static void __exit sh_hdmi_exit(void)
-{
- platform_driver_unregister(sh_hdmi_driver);
-}
-module_exit(sh_hdmi_exit);
+module_platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile HDMI driver);
--
Nicolas Ferre
--
Fabio Porcedda
--
To unsubscribe from this list: send the line
Re: [PATCH 0/8] ARM: dts: OMAP5: ocp address space and few updates
Benoit, On Wednesday 20 February 2013 09:08 PM, Santosh Shilimkar wrote: Few updates for OMAP5 found during testing OMAP5 DT builds. Couple of patches were already posted on the list. The series also contains a patch which adds DMA request, IRQ lines and IO address space DT extraction support to hwmod code so that we can get rid of such information from hwmod data files. It has been tested on OMAP5 and OMAP4 devices. [..] ARM: OMAP: hwmod: extract module address space from DT blob Above patch even though dt extraction code touches the hwmod file. Are you ok to keep this patch is the current series considering both the patches needs to go through your tree. If it needs to be in separate branch, then I can add that as part of the other generic patches with your ack. arch/arm/boot/dts/omap5-evm.dts |2 +- arch/arm/boot/dts/omap5.dtsi | 282 +++--- arch/arm/mach-omap2/omap_hwmod.c | 31 - 3 files changed, 293 insertions(+), 22 deletions(-) Let me know your preference. Either way is fine by me. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
Hi Kishon, On 03/13/2013 10:11 AM, kishon wrote: Benoit, Will you be queuing this patch series? I'm reviewing them right now. Regards, Benoit Thanks Kishon On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-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] rtc: omap: update to devm_* API
On 3/13/2013 12:21 PM, Vishwanathrao Badarkhe, Manish wrote: From: Vishwanathrao Badarkhe, Manish manish...@ti.com Update the code to use devm_* API so that driver core will manage resources. Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com Tested on DA850 EVM. Tested-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AM335x crc32 oops ?
Apologies for the long email ... Following on from another thread, I have encountered an issue with crc32 within the mtd system, seemingly only on my AM335x cpu board. In function ubi_eba_atomic_leb_change() in drivers/mtd/ubi/eba.c, there is a call to crc32. During a remount of my ubifs volume, ubi_eba_atomic_leb_change() is called several times, with crc32 happening at various points. Most of the time, the crc length is 2048 bytes, but when a large crc is required (in my case 122880 bytes), I get an oops. # mount -o remount,rw / [ 24.609350] UBIFS: start fixing up free space [ 24.627010] uealc crc32 : d08cb000 2048 [ 24.643019] uealc crc32 : d08cb000 2048 [ 24.661278] uealc crc32 : d08cb000 2048 [ 24.680505] uealc crc32 : d08cb000 2048 [ 24.743176] uealc crc32 : d08cb000 122880 [ 24.747581] Unable to handle kernel paging request at virtual address e7938204 [ 24.755199] pgd = cf408000 [ 24.758052] [e7938204] *pgd= [ 24.761833] Internal error: Oops: 5 [#1] ARM [ 24.766342] CPU: 0Not tainted (3.8.0-next-20130225-2-g678576f-dirty #45) [ 24.774248] PC is at crc32_le+0xf8/0x168 [ 24.778389] LR is at ubi_eba_atomic_leb_change+0x1d8/0x460 [ 24.784177] pc : [c01e734c]lr : [c026de20]psr: 2013 [ 24.784177] sp : cf359e10 ip : 3145 fp : c054f840 [ 24.796285] r10: e7938104 r9 : c054fc40 r8 : af5e2a9e [ 24.801796] r7 : e59f3038 r6 : e59f0040 r5 : 0040 r4 : 00e5 [ 24.808682] r3 : c054e040 r2 : r1 : d08d05d0 r0 : 3e5ed77d [ 24.815570] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 24.823097] Control: 10c5387d Table: 8f408019 DAC: 0015 [ 24.829160] Process mount (pid: 659, stack limit = 0xcf358238) [ 24.835313] Stack: (0xcf359e10 to 0xcf35a000) [ 24.839912] 9e00: d08cb000 d08caffc 3c00 [ 24.848543] 9e20: cf2f8000 cf2ec000 cf32da00 cf2f8554 000c d08cb000 [ 24.857173] 9e40: d08cb000 c059f1f6 cf32da00 0001e000 [ 24.865803] 9e60: cf32e000 000c d08cb000 0080 000c cf3c8f88 0020 [ 24.874435] 9e80: 8000 c026c47c 0001e000 cf359e9c cf32e000 d08cb000 0001e000 c0179b80 [ 24.883066] 9ea0: cf390c80 0001 0001e000 cf32e000 cf32eb20 000c c01796f0 [ 24.891698] 9ec0: cf32e000 cf32ea9c cf359f48 c0175170 0001 6013 [ 24.900329] 9ee0: cf326800 cf359f48 0020 c00c9e24 [ 24.908963] 9f00: 00100100 00200200 cf390c80 8000 cf358000 00208020 cf01a200 [ 24.917595] 9f20: cf326800 c00e3d6c 000c cf326840 c0013968 cf3c4680 [ 24.926227] 9f40: 000c cf01a210 ce828858 000c cf3a4000 000a18b4 [ 24.934859] 9f60: 00208020 c0013968 cf358000 0003 c00e3e40 c0071e24 [ 24.943491] 9f80: cf3c4680 cf314540 a010 be984b68 b6fbc48c [ 24.952124] 9fa0: 0015 c00137c0 be984b68 000a18b4 000a18c0 000a18c2 00208020 [ 24.960757] 9fc0: be984b68 b6fbc48c 0015 0003 [ 24.969391] 9fe0: b6f6ef48 be984a64 00042994 b6f6ef58 a010 000a18b4 ebfecd47 00095348 [ 24.978033] [c01e734c] (crc32_le+0xf8/0x168) from [d08cb000] (0xd08cb000) [ 24.985570] Code: 0a08 e59da008 e28a1003 e5f1c001 (e2522001) [ 24.992006] ---[ end trace 1496ae984fb21f1a ]--- I did some further testing, and, when the 122880 byte crc is about to run, I performed multiple crc's on the same buffer but with increasing sizes:- # mount -o remount,rw / [ 19.208302] UBIFS: start fixing up free space [ 19.230271] uealc crc32 : ** starting 122880 byte test ** [ 19.235881] uealc crc32 : d08cb000 2048 [ 19.240015] uealc crc32 : d08cb000 4096 [ 19.244091] uealc crc32 : d08cb000 8192 [ 19.248184] uealc crc32 : d08cb000 16384 [ 19.252448] uealc crc32 : d08cb000 32768 [ 19.256772] uealc crc32 : d08cb000 65536 [ 19.260133] uealc crc32 : d08cb000 122880 [ 19.261117] Unable to handle kernel paging request at virtual address e79381bc [ 19.268741] pgd = cf40c000 [ 19.271598] [e79381bc] *pgd= [ 19.275387] Internal error: Oops: 5 [#1] ARM [ 19.279902] CPU: 0Not tainted (3.8.0-next-20130225-2-g678576f-dirty #47) [ 19.287819] PC is at crc32_le+0xf8/0x168 [ 19.291965] LR is at ubi_eba_atomic_leb_change+0x3ac/0x4f8 [ 19.297760] pc : [c01e724c]lr : [c026def4]psr: 2013 [ 19.297760] sp : cf3bbe08 ip : 0e4e fp : c054f840 [ 19.309882] r10: e7938104 r9 : c054fc40 r8 : 65e95c1c [ 19.315396] r7 : 322e315f r6 : 352e332e r5 : 002e r4 : 0035 [ 19.322288] r3 : c054e040 r2 : 0033 r1 : d08d3d90 r0 : 63c3884e [ 19.329180] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 19.336713] Control: 10c5387d Table: 8f40c019 DAC: 0015 [ 19.342781] Process mount (pid:
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter jon-hun...@ti.com wrote:
On 03/02/2013 02:05 PM, Grant Likely wrote:
On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter jon-hun...@ti.com wrote:
On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
Are you requesting the gpio anywhere? If not then this is not going to
work as-is. This was discussed fairly recently [1] and the conclusion
was that the gpio needs to be requested before we can use as an interrupt.
That seems wrong; the GPIO/IRQ driver should handle this internally. The
Ethernet driver shouldn't know/care whether the interrupt it's given is
some form of dedicated interrupt or a GPIO-based interrupt, and even if
it somehow did, there's no irq_to_gpio() any more, so the driver can't
tell which GPIO ID it should request, unless it's given yet another
property to represent this.
I agree that ideally this should be handled internally. Did you read the
discussion on the thread that I referenced [1]? If you have any thoughts
we are open to ideas :-)
I'm on an airplane right now, but I agree 100% with Stephen. I'll try to
remember to go read that thread and respond, but this falls firmly in
the its-a-bug category for me. :-)
Grant, did you have chance to review the thread [1]?
I am trying to figure out if we should just take the original patch
proposed in the thread (although Linus had some objections) or look at
alternative solutions such as adding a irq_chip request as Stephen
suggested.
Cheers
Jon
[1] comments.gmane.org/gmane.linux.ports.arm.omap/92192
Hello Grant,
I was wondering if you have any opinions on this issue. As Jon said,
Stephen proposed [2] to add a request callback to irq_chip.
I hacked a very simple and naive patch (just to validate the idea) and
is working. The GPIO bank is requested before calling the gpio-omap
.irq_set_type function handler (gpio_irq_type) when using a GPIO as an
IRQ on a DT. So is not necessary to call it explicitly anymore.
But the patch is obviously wrong (to say the least) since the kernel
runtime locking validator complains that possible circular locking
dependency detected
I just wanted to know if I was on the right track or completely lost here.
Thanks a lot and best regards,
javier
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 159f5c5..f5feb43 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -807,6 +807,13 @@ static void gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
+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);
+}
+
static struct irq_chip gpio_irq_chip = {
.name = GPIO,
.irq_shutdown = gpio_irq_shutdown,
@@ -815,6 +822,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= gpio_irq_request,
};
/*-*/
diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..2aeaa24 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..07c20f7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1093,6 +1093,13 @@ __setup_irq(unsigned int irq, struct irq_desc
*desc, struct irqaction *new)
if (!shared) {
init_waitqueue_head(desc-wait_for_threads);
+ if (desc-irq_data.chip-irq_request) {
+ ret = desc-irq_data.chip-irq_request(desc-irq_data);
+
+ if (ret)
+ goto out_mask;
+ }
+
/* Setup the type (level, edge polarity) if configured: */
if (new-flags IRQF_TRIGGER_MASK) {
ret = __irq_set_trigger(desc, irq,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] usb: otg: twl4030: use devres API for regulator get and request irq
On Thu, Mar 14, 2013 at 5:48 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Mar 14, 2013 at 11:53:57AM +0530, Kishon Vijay Abraham I wrote: Used devres APIs devm_request_threaded_irq and devm_regulator_get for requesting irq and for getting regulator respectively. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com please refresh this on top of my testing branch, you should be patching drivers/usb/phy/phy-twl4030-usb.c Does that mean I need to rebase my series on your testing branch too? -- balbi -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] usb: otg: twl4030: use devres API for regulator get and request irq
On Fri, Mar 15, 2013 at 02:00:33PM +0200, Grazvydas Ignotas wrote: On Thu, Mar 14, 2013 at 5:48 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Mar 14, 2013 at 11:53:57AM +0530, Kishon Vijay Abraham I wrote: Used devres APIs devm_request_threaded_irq and devm_regulator_get for requesting irq and for getting regulator respectively. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com please refresh this on top of my testing branch, you should be patching drivers/usb/phy/phy-twl4030-usb.c Does that mean I need to rebase my series on your testing branch too? Oh yeah, sorry. Forgot to mention. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
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: [PATCH 2/2] ARM: OMAP2+: clocks: Pass static parent pointers to common clock core
On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130314 05:44]: OMAP clock inits happen quite early, even before the slab is available. As part of the clock init, the common clock core tries to cache parent pointers (if not passed by the caller registering the clock) which fails in case of OMAP since the slab isn't initied. Without CONFIG_DEBUG_SLAB enabled, this just results in the common clock core retrying the caching attempt at some point later. However with CONFIG_DEBUG_SLAB enabled this results in a BUG() as reported in the link below by Tony.. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html Fix this by passing static parent pointers to the common clock core while registering clocks. I wonder if we could easily fix this by initializing only some of the clocks that early? We actually don't need any clocks that early (I mean even before slab init) We only need them before timer init. This isn't something specific to OMAP so I started looking at what others in drivers/clk seem to do. I found imx, spear, mvebu all do their clk inits within .init_time callbacks. tegra seems to even do it within .init_irq callback. Either one would work for us too :) If we had a two stage initialization we could dynamically allocate the rest of the parent clocks without having to add all the static data. 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 v3] drivers: video: use module_platform_driver_probe()
Hi Fabio,
Thank you for the patch.
On Friday 15 March 2013 10:00:19 Fabio Porcedda wrote:
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Howells dhowe...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
Notes:
v3:
- add missing drivers: amifb, atmel_lcdfb, vrfb
- split patch set to each maintainer to easy up respin
v2:
- rebased over linux-next and remove already converted drivers
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c| 13 +
drivers/video/omap2/vrfb.c | 13 +
drivers/video/sh_mipi_dsi.c| 12 +---
drivers/video/sh_mobile_hdmi.c | 12 +---
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 7fa1bf8..03e2de2 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
},
};
-static int __init amifb_init(void)
-{
- return platform_driver_probe(amifb_driver, amifb_probe);
-}
-
-module_init(amifb_init);
-
-static void __exit amifb_exit(void)
-{
- platform_driver_unregister(amifb_driver);
-}
-
-module_exit(amifb_exit);
+return module_platform_driver_probe(amifb_driver, amifb_probe);
I think think you need a return here.
After fixing that,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:amiga-video);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
+ Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Jon, You might have to rebase your series on top of the new HEAD before reposting. Thanks, Benoit Kishon Vijay Abraham I (7): ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap and dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 +++ arch/arm/boot/dts/omap3-evm.dts|6 +++ arch/arm/boot/dts/omap3-overo.dtsi |6 +++ arch/arm/boot/dts/omap3.dtsi | 12 + arch/arm/boot/dts/omap4-panda.dts |6 +++ arch/arm/boot/dts/omap4-sdp.dts|6 +++ arch/arm/boot/dts/omap4.dtsi | 26 +++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- 10 files changed, 118 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: dts: OMAP5: ocp address space and few updates
Hi Santosh, On 03/15/2013 11:24 AM, Santosh Shilimkar wrote: Benoit, On Wednesday 20 February 2013 09:08 PM, Santosh Shilimkar wrote: Few updates for OMAP5 found during testing OMAP5 DT builds. Couple of patches were already posted on the list. The series also contains a patch which adds DMA request, IRQ lines and IO address space DT extraction support to hwmod code so that we can get rid of such information from hwmod data files. It has been tested on OMAP5 and OMAP4 devices. [..] ARM: OMAP: hwmod: extract module address space from DT blob Above patch even though dt extraction code touches the hwmod file. Are you ok to keep this patch is the current series considering both the patches needs to go through your tree. If it needs to be in separate branch, then I can add that as part of the other generic patches with your ack. arch/arm/boot/dts/omap5-evm.dts |2 +- arch/arm/boot/dts/omap5.dtsi | 282 +++--- arch/arm/mach-omap2/omap_hwmod.c | 31 - 3 files changed, 293 insertions(+), 22 deletions(-) Let me know your preference. Either way is fine by me. I can take both DTS and hwmod patches, so you can keep then in the same series. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-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] drivers: video: use module_platform_driver_probe()
On Fri, Mar 15, 2013 at 1:37 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Fabio,
Thank you for the patch.
On Friday 15 March 2013 10:00:19 Fabio Porcedda wrote:
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Howells dhowe...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
Notes:
v3:
- add missing drivers: amifb, atmel_lcdfb, vrfb
- split patch set to each maintainer to easy up respin
v2:
- rebased over linux-next and remove already converted drivers
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c| 13 +
drivers/video/omap2/vrfb.c | 13 +
drivers/video/sh_mipi_dsi.c| 12 +---
drivers/video/sh_mobile_hdmi.c | 12 +---
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 7fa1bf8..03e2de2 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
},
};
-static int __init amifb_init(void)
-{
- return platform_driver_probe(amifb_driver, amifb_probe);
-}
-
-module_init(amifb_init);
-
-static void __exit amifb_exit(void)
-{
- platform_driver_unregister(amifb_driver);
-}
-
-module_exit(amifb_exit);
+return module_platform_driver_probe(amifb_driver, amifb_probe);
I think think you need a return here.
After fixing that,
Thanks for reviewing.
I will send shortly the patch v4.
Regards
Fabio Porcedda
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:amiga-video);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: dts: OMAP5: ocp address space and few updates
On Friday 15 March 2013 06:15 PM, Benoit Cousson wrote: Hi Santosh, On 03/15/2013 11:24 AM, Santosh Shilimkar wrote: Benoit, On Wednesday 20 February 2013 09:08 PM, Santosh Shilimkar wrote: Few updates for OMAP5 found during testing OMAP5 DT builds. Couple of patches were already posted on the list. The series also contains a patch which adds DMA request, IRQ lines and IO address space DT extraction support to hwmod code so that we can get rid of such information from hwmod data files. It has been tested on OMAP5 and OMAP4 devices. [..] ARM: OMAP: hwmod: extract module address space from DT blob Above patch even though dt extraction code touches the hwmod file. Are you ok to keep this patch is the current series considering both the patches needs to go through your tree. If it needs to be in separate branch, then I can add that as part of the other generic patches with your ack. arch/arm/boot/dts/omap5-evm.dts |2 +- arch/arm/boot/dts/omap5.dtsi | 282 +++--- arch/arm/mach-omap2/omap_hwmod.c | 31 - 3 files changed, 293 insertions(+), 22 deletions(-) Let me know your preference. Either way is fine by me. I can take both DTS and hwmod patches, so you can keep then in the same series. Cool. I will wait for Jon to send you a branch and then post mine so that I have one less dependency for testing. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe 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 00/50] staging: omap-thermal: several code refactoring
Hello Greg, Here is a series of patches improving the way the omap-thermal driver is written. There is a mix of added documentation, with functions rewrites and cleanups regarding coding style. I am also adding myself as maintainer of this driver. Next I will be still improving the code in this way, but also working on the policy readiness and testing on other devices. I will probably rename the driver also to something that reflect the support to AMxx devices as well. Hopefully, it should be soon ready for moving to drivers/thermal/. All these are based on your staging/staging-next branch. For those interested in testing and trying the driver, these patches are also available, as usual, here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-optimizations https://git.gitorious.org/thermal-framework/thermal-framework.git thermal_work/omap/omap-thermal-optimizations For lo guys, I will appreciate your testing results on other devices. Cheers, Eduardo Valentin (50): staging: omap-thermal: use BIT() macro staging: omap-thermal: remove unused _SHIFT macros staging: omap-thermal: create header for register, bitfields and definitions staging: omap-thermal: update documentation of omap-bandgap.h staging: omap-thermal: style cleanup on omap-bandgap.c staging: omap-thermal: fix error checking staging: omap-thermal: introduce RMW_BITS macro staging: omap-thermal: add documentation for register access functions staging: omap-thermal: make a omap_bandgap_power with only one exit point staging: omap-thermal: add documentation for omap_bandgap_power staging: omap-thermal: add documentation for omap_bandgap_read_temp staging: omap-thermal: rename talert handler staging: omap-thermal: update documentation for talert irq handler staging: omap-thermal: update tshut IRQ handler documentation staging: omap-thermal: remove duplicated code staging: omap-thermal: read status only once inside alert IRQ staging: omap-thermal: add a section of register manipulation staging: omap-thermal: section of basic helpers staging: omap-thermal: IRQ handler section staging: omap-thermal: ADC section staging: omap-thermal: name adc_to_temp_conversion in a better way staging: omap-thermal: rewrite omap_bandgap_adc_to_mcelsius on kernel coding style staging: omap-thermal: add documentation for omap_bandgap_adc_to_mcelsius staging: omap-thermal: name temp_to_adc_conversion in a better way staging: omap-thermal: rewrite omap_bandgap_mcelsius_to_adc on kernel coding style staging: omap-thermal: move conv table limits out of sensor data staging: omap-thermal: add documentation for omap_bandgap_mcelsius_to_adc staging: omap-thermal: rename add_hyst to omap_bandgap_add_hyst staging: omap-thermal: document omap_bandgap_add_hyst function staging: omap-thermal: threshold manipulation section staging: omap-thermal: refactor temp_sensor_unmask_interrupts staging: omap-thermal: update omap_bandgap_unmask_interrupts documentation staging: omap-thermal: refactor APIs handling threshold values staging: omap-thermal: device initialization section staging: omap-thermal: section of device driver callbacks staging: omap-thermal: rename enable_continuous_mode staging: omap-thermal: update omap_bandgap_set_continous_mode documentation staging: omap-thermal: document omap_bandgap_force_single_read staging: omap-thermal: document omap_bandgap_update_alert_threshold function staging: omap-thermal: document _omap_bandgap_write_threshold function staging: omap-thermal: document _omap_bandgap_read_threshold function staging: omap-thermal: document omap_bandgap_tshut_init function staging: omap-thermal: document omap_bandgap_alert_init function staging: omap-thermal: document omap_bandgap_build function staging: omap-thermal: change Kconfig dependency method staging: Add a MAINTAINERS entry for TI bandgap and thermal driver staging: omap-thermal: switch mutex to spinlock inside omap-bandgap staging: omap-thermal: remove TODO entry suggesting regmap usage staging: omap-thermal: remove TODO entry for exposed APIs staging: omap-thermal: add documentation for omap_bandgap_validate MAINTAINERS|6 + drivers/staging/omap-thermal/Kconfig |2 +- drivers/staging/omap-thermal/TODO |4 - drivers/staging/omap-thermal/omap-bandgap.c| 793 +++- drivers/staging/omap-thermal/omap-bandgap.h| 498 + drivers/staging/omap-thermal/omap-thermal-common.c |4 +- drivers/staging/omap-thermal/omap4-thermal-data.c | 11 +- drivers/staging/omap-thermal/omap4xxx-bandgap.h| 175 + drivers/staging/omap-thermal/omap5-thermal-data.c |9 +- drivers/staging/omap-thermal/omap5xxx-bandgap.h| 199 + 10 files changed, 1030 insertions(+), 671 deletions(-)
[PATCH 01/50] staging: omap-thermal: use BIT() macro
For code readability, this patch changes the bit definition under omap-bandgap.h to use the BIT() macro. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.h | 96 +- 1 files changed, 48 insertions(+), 48 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.h b/drivers/staging/omap-thermal/omap-bandgap.h index 3e9072c..8d3ee2b 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.h +++ b/drivers/staging/omap-thermal/omap-bandgap.h @@ -29,17 +29,17 @@ /* TEMP_SENSOR OMAP4430 */ #define OMAP4430_BGAP_TSHUT_SHIFT 11 -#define OMAP4430_BGAP_TSHUT_MASK (1 11) +#define OMAP4430_BGAP_TSHUT_MASK BIT(11) /* TEMP_SENSOR OMAP4430 */ #define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 -#define OMAP4430_BGAP_TEMPSOFF_MASK(1 12) +#define OMAP4430_BGAP_TEMPSOFF_MASKBIT(12) #define OMAP4430_SINGLE_MODE_SHIFT 10 -#define OMAP4430_SINGLE_MODE_MASK (1 10) +#define OMAP4430_SINGLE_MODE_MASK BIT(10) #define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 -#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 9) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK BIT(9) #define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 -#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 8) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(8) #define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 #define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) @@ -53,21 +53,21 @@ /* TEMP_SENSOR OMAP4460 */ #define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 -#define OMAP4460_BGAP_TEMPSOFF_MASK(1 13) +#define OMAP4460_BGAP_TEMPSOFF_MASKBIT(13) #define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 -#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 11) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK BIT(11) #define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 -#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(10) #define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 #define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) /* BANDGAP_CTRL */ #define OMAP4460_SINGLE_MODE_SHIFT 31 -#define OMAP4460_SINGLE_MODE_MASK (1 31) +#define OMAP4460_SINGLE_MODE_MASK BIT(31) #define OMAP4460_MASK_HOT_SHIFT1 -#define OMAP4460_MASK_HOT_MASK (1 1) +#define OMAP4460_MASK_HOT_MASK BIT(1) #define OMAP4460_MASK_COLD_SHIFT 0 -#define OMAP4460_MASK_COLD_MASK(1 0) +#define OMAP4460_MASK_COLD_MASKBIT(0) /* BANDGAP_COUNTER */ #define OMAP4460_COUNTER_SHIFT 0 @@ -87,57 +87,57 @@ /* BANDGAP_STATUS */ #define OMAP4460_CLEAN_STOP_SHIFT 3 -#define OMAP4460_CLEAN_STOP_MASK (1 3) +#define OMAP4460_CLEAN_STOP_MASK BIT(3) #define OMAP4460_BGAP_ALERT_SHIFT 2 -#define OMAP4460_BGAP_ALERT_MASK (1 2) +#define OMAP4460_BGAP_ALERT_MASK BIT(2) #define OMAP4460_HOT_FLAG_SHIFT1 -#define OMAP4460_HOT_FLAG_MASK (1 1) +#define OMAP4460_HOT_FLAG_MASK BIT(1) #define OMAP4460_COLD_FLAG_SHIFT 0 -#define OMAP4460_COLD_FLAG_MASK(1 0) +#define OMAP4460_COLD_FLAG_MASKBIT(0) /* TEMP_SENSOR OMAP5430 */ #define OMAP5430_BGAP_TEMP_SENSOR_SOC_SHIFT12 -#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK (1 12) +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK BIT(12) #define OMAP5430_BGAP_TEMPSOFF_SHIFT 11 -#define OMAP5430_BGAP_TEMPSOFF_MASK(1 11) +#define OMAP5430_BGAP_TEMPSOFF_MASKBIT(11) #define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 -#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(10) #define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 #define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) /* BANDGAP_CTRL */ #define OMAP5430_MASK_HOT_CORE_SHIFT 5 -#define OMAP5430_MASK_HOT_CORE_MASK(1 5) +#define OMAP5430_MASK_HOT_CORE_MASKBIT(5) #define OMAP5430_MASK_COLD_CORE_SHIFT 4 -#define OMAP5430_MASK_COLD_CORE_MASK (1 4) +#define OMAP5430_MASK_COLD_CORE_MASK BIT(4)
[PATCH 03/50] staging: omap-thermal: create header for register, bitfields and definitions
In order to have a better code readability and organization, this patch splits omap-bandgap.h into three headers. . omap-bandgap.h will contain only the driver related data structures definitions and macros . omap4xxx-bandgap.h will contain only defines and bitfields related to OMAP4 based devices . omap5xxx-bandgap.h will contain only defines and bitfields related to OMAP5 based devices Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.h | 195 drivers/staging/omap-thermal/omap4-thermal-data.c |1 + drivers/staging/omap-thermal/omap4xxx-bandgap.h | 175 ++ drivers/staging/omap-thermal/omap5-thermal-data.c |1 + drivers/staging/omap-thermal/omap5xxx-bandgap.h | 199 + 5 files changed, 376 insertions(+), 195 deletions(-) create mode 100644 drivers/staging/omap-thermal/omap4xxx-bandgap.h create mode 100644 drivers/staging/omap-thermal/omap5xxx-bandgap.h diff --git a/drivers/staging/omap-thermal/omap-bandgap.h b/drivers/staging/omap-thermal/omap-bandgap.h index 5ce1659..7d5ac3f 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.h +++ b/drivers/staging/omap-thermal/omap-bandgap.h @@ -27,201 +27,6 @@ #include linux/types.h #include linux/err.h -/* TEMP_SENSOR OMAP4430 */ -#define OMAP4430_BGAP_TSHUT_MASK BIT(11) - -/* TEMP_SENSOR OMAP4430 */ -#define OMAP4430_BGAP_TEMPSOFF_MASKBIT(12) -#define OMAP4430_SINGLE_MODE_MASK BIT(10) -#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK BIT(9) -#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(8) -#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) - -#define OMAP4430_ADC_START_VALUE 0 -#define OMAP4430_ADC_END_VALUE 127 -#define OMAP4430_MAX_FREQ 32768 -#define OMAP4430_MIN_FREQ 32768 -#define OMAP4430_MIN_TEMP -4 -#define OMAP4430_MAX_TEMP 125000 -#define OMAP4430_HYST_VAL 5000 - -/* TEMP_SENSOR OMAP4460 */ -#define OMAP4460_BGAP_TEMPSOFF_MASKBIT(13) -#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK BIT(11) -#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(10) -#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) - -/* BANDGAP_CTRL */ -#define OMAP4460_SINGLE_MODE_MASK BIT(31) -#define OMAP4460_MASK_HOT_MASK BIT(1) -#define OMAP4460_MASK_COLD_MASKBIT(0) - -/* BANDGAP_COUNTER */ -#define OMAP4460_COUNTER_MASK (0xff 0) - -/* BANDGAP_THRESHOLD */ -#define OMAP4460_T_HOT_MASK(0x3ff 16) -#define OMAP4460_T_COLD_MASK (0x3ff 0) - -/* TSHUT_THRESHOLD */ -#define OMAP4460_TSHUT_HOT_MASK(0x3ff 16) -#define OMAP4460_TSHUT_COLD_MASK (0x3ff 0) - -/* BANDGAP_STATUS */ -#define OMAP4460_CLEAN_STOP_MASK BIT(3) -#define OMAP4460_BGAP_ALERT_MASK BIT(2) -#define OMAP4460_HOT_FLAG_MASK BIT(1) -#define OMAP4460_COLD_FLAG_MASKBIT(0) - -/* TEMP_SENSOR OMAP5430 */ -#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK BIT(12) -#define OMAP5430_BGAP_TEMPSOFF_MASKBIT(11) -#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASKBIT(10) -#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) - -/* BANDGAP_CTRL */ -#define OMAP5430_MASK_HOT_CORE_MASKBIT(5) -#define OMAP5430_MASK_COLD_CORE_MASK BIT(4) -#define OMAP5430_MASK_HOT_GPU_MASK BIT(3) -#define OMAP5430_MASK_COLD_GPU_MASKBIT(2) -#define OMAP5430_MASK_HOT_MPU_MASK BIT(1) -#define OMAP5430_MASK_COLD_MPU_MASKBIT(0) -#define OMAP5430_MASK_SIDLEMODE_MASK (0x3 30) -#define OMAP5430_MASK_FREEZE_CORE_MASK BIT(23) -#define OMAP5430_MASK_FREEZE_GPU_MASK BIT(22) -#define OMAP5430_MASK_FREEZE_MPU_MASK BIT(21) -#define OMAP5430_MASK_CLEAR_CORE_MASK BIT(20) -#define OMAP5430_MASK_CLEAR_GPU_MASK BIT(19) -#define OMAP5430_MASK_CLEAR_MPU_MASK BIT(18) -#define OMAP5430_MASK_CLEAR_ACCUM_CORE_MASKBIT(17) -#define OMAP5430_MASK_CLEAR_ACCUM_GPU_MASK BIT(16) -#define OMAP5430_MASK_CLEAR_ACCUM_MPU_MASK BIT(15) - -/* BANDGAP_COUNTER */ -#define OMAP5430_COUNTER_MASK (0xff 0) - -/* BANDGAP_THRESHOLD */ -#define OMAP5430_T_HOT_MASK(0x3ff 16) -#define OMAP5430_T_COLD_MASK (0x3ff 0) - -/*
[PATCH v4] drivers: video: use module_platform_driver_probe()
This patch converts the drivers to use the
module_platform_driver_probe() macro which makes the code smaller and
a bit simpler.
Signed-off-by: Fabio Porcedda fabio.porce...@gmail.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com # atmel_lcdfb.c
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: David Howells dhowe...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com # amifb.c
Cc: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
Notes:
v4:
- add acked-by Nicolas Laurent
- fix amifb.c
v3:
- add missing drivers: amifb, atmel_lcdfb, vrfb
- split patch set to each maintainer to easy up respin
v2:
- rebased over linux-next and remove already converted drivers
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c| 13 +
drivers/video/omap2/vrfb.c | 13 +
drivers/video/sh_mipi_dsi.c| 12 +---
drivers/video/sh_mobile_hdmi.c | 12 +---
5 files changed, 5 insertions(+), 59 deletions(-)
diff --git a/drivers/video/amifb.c b/drivers/video/amifb.c
index 7fa1bf8..77cb4ff 100644
--- a/drivers/video/amifb.c
+++ b/drivers/video/amifb.c
@@ -3788,19 +3788,7 @@ static struct platform_driver amifb_driver = {
},
};
-static int __init amifb_init(void)
-{
- return platform_driver_probe(amifb_driver, amifb_probe);
-}
-
-module_init(amifb_init);
-
-static void __exit amifb_exit(void)
-{
- platform_driver_unregister(amifb_driver);
-}
-
-module_exit(amifb_exit);
+module_platform_driver_probe(amifb_driver, amifb_probe);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:amiga-video);
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 12cf5f3..654e102 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -1150,18 +1150,7 @@ static struct platform_driver atmel_lcdfb_driver = {
},
};
-static int __init atmel_lcdfb_init(void)
-{
- return platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
-}
-
-static void __exit atmel_lcdfb_exit(void)
-{
- platform_driver_unregister(atmel_lcdfb_driver);
-}
-
-module_init(atmel_lcdfb_init);
-module_exit(atmel_lcdfb_exit);
+module_platform_driver_probe(atmel_lcdfb_driver, atmel_lcdfb_probe);
MODULE_DESCRIPTION(AT91/AT32 LCD Controller framebuffer driver);
MODULE_AUTHOR(Nicolas Ferre nicolas.fe...@atmel.com);
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 10560ef..5261229 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -397,18 +397,7 @@ static struct platform_driver vrfb_driver = {
.remove = __exit_p(vrfb_remove),
};
-static int __init vrfb_init(void)
-{
- return platform_driver_probe(vrfb_driver, vrfb_probe);
-}
-
-static void __exit vrfb_exit(void)
-{
- platform_driver_unregister(vrfb_driver);
-}
-
-module_init(vrfb_init);
-module_exit(vrfb_exit);
+module_platform_driver_probe(vrfb_driver, vrfb_probe);
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
MODULE_DESCRIPTION(OMAP VRFB);
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 701b461..6cad530 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -581,17 +581,7 @@ static struct platform_driver sh_mipi_driver = {
},
};
-static int __init sh_mipi_init(void)
-{
- return platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
-}
-module_init(sh_mipi_init);
-
-static void __exit sh_mipi_exit(void)
-{
- platform_driver_unregister(sh_mipi_driver);
-}
-module_exit(sh_mipi_exit);
+module_platform_driver_probe(sh_mipi_driver, sh_mipi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile MIPI DSI driver);
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 930e550..bfe4728 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1445,17 +1445,7 @@ static struct platform_driver sh_hdmi_driver = {
},
};
-static int __init sh_hdmi_init(void)
-{
- return platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
-}
-module_init(sh_hdmi_init);
-
-static void __exit sh_hdmi_exit(void)
-{
- platform_driver_unregister(sh_hdmi_driver);
-}
-module_exit(sh_hdmi_exit);
+module_platform_driver_probe(sh_hdmi_driver, sh_hdmi_probe);
MODULE_AUTHOR(Guennadi Liakhovetski g.liakhovet...@gmx.de);
MODULE_DESCRIPTION(SuperH / ARM-shmobile HDMI driver);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe 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 04/50] staging: omap-thermal: update documentation of omap-bandgap.h
This patch updates the existing data structures for omap bandgap,
inside omap-bandgap.h.
TODO: remove unused fields.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.h | 230 ++-
1 files changed, 189 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index 7d5ac3f..28d9104 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -28,24 +28,101 @@
#include linux/err.h
/**
- * The register offsets and bit fields might change across
- * OMAP versions hence populating them in this structure.
+ * DOC: bandgap driver data structure
+ * ==
+ * +-+ +-+
+ * | struct omap_bandgap |--| struct device * |
+ * +--+--+ +-+
+ * |
+ * |
+ * V
+ * +--+
+ * | struct omap_bandgap_data |
+ * +--+
+ * |
+ * |
+ * * (Array of)
+ * ++--+
+ * | +--+--+ +-+ |
+ * | | struct omap_temp_sensor |--| struct temp_sensor_data | |
+ * | +-+ +++ |
+ * || |
+ * |+--+ |
+ * |V V |
+ * | +--+- --+ ++-+ |
+ * | | struct temp_sensor_regval | | struct temp_sensor_registers | |
+ * | +---+ +--+ |
+ * | |
+ * +---+
+ *
+ * Above is a simple diagram describing how the data structure below
+ * are organized. For each bandgap device there should be a omap_bandgap_data
+ * containing the device instance configuration, as well as, an array of
+ * sensors, representing every sensor instance present in this bandgap.
+ */
+
+/**
+ * struct temp_sensor_registers - descriptor to access registers and bitfields
+ * @temp_sensor_ctrl: TEMP_SENSOR_CTRL register offset
+ * @bgap_tempsoff_mask: mask to temp_sensor_ctrl.tempsoff
+ * @bgap_soc_mask: mask to temp_sensor_ctrl.soc
+ * @bgap_eocz_mask: mask to temp_sensor_ctrl.eocz
+ * @bgap_dtemp_mask: mask to temp_sensor_ctrl.dtemp
+ * @bgap_mask_ctrl: BANDGAP_MASK_CTRL register offset
+ * @mask_hot_mask: mask to bandgap_mask_ctrl.mask_hot
+ * @mask_cold_mask: mask to bandgap_mask_ctrl.mask_cold
+ * @mask_sidlemode_mask: mask to bandgap_mask_ctrl.mask_sidlemode
+ * @mask_freeze_mask: mask to bandgap_mask_ctrl.mask_free
+ * @mask_clear_mask: mask to bandgap_mask_ctrl.mask_clear
+ * @mask_clear_accum_mask: mask to bandgap_mask_ctrl.mask_clear_accum
+ * @bgap_mode_ctrl: BANDGAP_MODE_CTRL register offset
+ * @mode_ctrl_mask: mask to bandgap_mode_ctrl.mode_ctrl
+ * @bgap_counter: BANDGAP_COUNTER register offset
+ * @counter_mask: mask to bandgap_counter.counter
+ * @bgap_threshold: BANDGAP_THRESHOLD register offset (TALERT thresholds)
+ * @threshold_thot_mask: mask to bandgap_threhold.thot
+ * @threshold_tcold_mask: mask to bandgap_threhold.tcold
+ * @tshut_threshold: TSHUT_THRESHOLD register offset (TSHUT thresholds)
+ * @tshut_efuse_mask: mask to tshut_threshold.tshut_efuse
+ * @tshut_efuse_shift: shift to tshut_threshold.tshut_efuse
+ * @tshut_hot_mask: mask to tshut_threhold.thot
+ * @tshut_cold_mask: mask to tshut_threhold.thot
+ * @bgap_status: BANDGAP_STATUS register offset
+ * @status_clean_stop_mask: mask to bandgap_status.clean_stop
+ * @status_bgap_alert_mask: mask to bandgap_status.bandgap_alert
+ * @status_hot_mask: mask to bandgap_status.hot
+ * @status_cold_mask: mask to bandgap_status.cold
+ * @bgap_cumul_dtemp: BANDGAP_CUMUL_DTEMP register offset
+ * @ctrl_dtemp_0: CTRL_DTEMP0 register offset
+ * @ctrl_dtemp_1: CTRL_DTEMP1 register offset
+ * @ctrl_dtemp_2: CTRL_DTEMP2 register offset
+ * @ctrl_dtemp_3: CTRL_DTEMP3 register offset
+ * @ctrl_dtemp_4: CTRL_DTEMP4 register offset
+ * @bgap_efuse: BANDGAP_EFUSE register offset
+ *
+ * The register offsets and bitfields might change across
+ * OMAP and variants versions. Hence this struct serves as a
+ * descriptor map on how to access the registers and the bitfields.
+ *
+ * This descriptor contains registers of all versions of bandgap chips.
+ * Not all versions will use all registers, depending on the available
+ * features. Please read TRMs for descriptive explanation on each bitfield.
*/
struct temp_sensor_registers {
u32 temp_sensor_ctrl;
u32 bgap_tempsoff_mask;
[PATCH 05/50] staging: omap-thermal: style cleanup on omap-bandgap.c
simple changes on alignments and white spaces
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 32 --
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index d4a3788..9f2d7cc 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -437,7 +437,7 @@ static inline int omap_bandgap_validate(struct omap_bandgap
*bg_ptr, int id)
* returns 0 on success or the proper error code
*/
int omap_bandgap_read_thot(struct omap_bandgap *bg_ptr, int id,
- int *thot)
+ int *thot)
{
struct temp_sensor_registers *tsr;
u32 temp;
@@ -512,7 +512,7 @@ int omap_bandgap_write_thot(struct omap_bandgap *bg_ptr,
int id, int val)
* returns 0 on success or the proper error code
*/
int omap_bandgap_read_tcold(struct omap_bandgap *bg_ptr, int id,
- int *tcold)
+ int *tcold)
{
struct temp_sensor_registers *tsr;
u32 temp;
@@ -617,7 +617,7 @@ int omap_bandgap_read_update_interval(struct omap_bandgap
*bg_ptr, int id,
* returns 0 on success or the proper error code
*/
int omap_bandgap_write_update_interval(struct omap_bandgap *bg_ptr,
- int id, u32 interval)
+ int id, u32 interval)
{
int ret = omap_bandgap_validate(bg_ptr, id);
if (ret)
@@ -643,7 +643,7 @@ int omap_bandgap_write_update_interval(struct omap_bandgap
*bg_ptr,
* returns 0 on success or the proper error code
*/
int omap_bandgap_read_temperature(struct omap_bandgap *bg_ptr, int id,
-int *temperature)
+ int *temperature)
{
struct temp_sensor_registers *tsr;
u32 temp;
@@ -677,7 +677,7 @@ int omap_bandgap_read_temperature(struct omap_bandgap
*bg_ptr, int id,
* returns 0 on success or the proper error code
*/
int omap_bandgap_set_sensor_data(struct omap_bandgap *bg_ptr, int id,
- void *data)
+void *data)
{
int ret = omap_bandgap_validate(bg_ptr, id);
if (ret)
@@ -762,7 +762,7 @@ static int enable_continuous_mode(struct omap_bandgap
*bg_ptr)
}
static int omap_bandgap_tshut_init(struct omap_bandgap *bg_ptr,
- struct platform_device *pdev)
+ struct platform_device *pdev)
{
int gpio_nr = bg_ptr-tshut_gpio;
int status;
@@ -795,7 +795,7 @@ static int omap_bandgap_tshut_init(struct omap_bandgap
*bg_ptr,
/* Initialization of Talert. Call it only if HAS(TALERT) is set */
static int omap_bandgap_talert_init(struct omap_bandgap *bg_ptr,
- struct platform_device *pdev)
+ struct platform_device *pdev)
{
int ret;
@@ -855,7 +855,7 @@ static struct omap_bandgap *omap_bandgap_build(struct
platform_device *pdev)
bg_ptr-base = chunk;
if (IS_ERR(chunk))
return ERR_CAST(chunk);
-
+
i++;
} while (res);
@@ -1108,9 +1108,8 @@ static int omap_bandgap_restore_ctxt(struct omap_bandgap
*bg_ptr)
val = omap_bandgap_readl(bg_ptr, tsr-bgap_counter);
if (OMAP_BANDGAP_HAS(bg_ptr, TSHUT_CONFIG))
- omap_bandgap_writel(bg_ptr,
- rval-tshut_threshold,
- tsr-tshut_threshold);
+ omap_bandgap_writel(bg_ptr, rval-tshut_threshold,
+ tsr-tshut_threshold);
/* Force immediate temperature measurement and update
* of the DTEMP field
*/
@@ -1118,16 +1117,15 @@ static int omap_bandgap_restore_ctxt(struct
omap_bandgap *bg_ptr)
if (OMAP_BANDGAP_HAS(bg_ptr, COUNTER))
omap_bandgap_writel(bg_ptr, rval-bg_counter,
- tsr-bgap_counter);
+ tsr-bgap_counter);
if (OMAP_BANDGAP_HAS(bg_ptr, MODE_CONFIG))
omap_bandgap_writel(bg_ptr, rval-bg_mode_ctrl,
- tsr-bgap_mode_ctrl);
+ tsr-bgap_mode_ctrl);
if (OMAP_BANDGAP_HAS(bg_ptr, TALERT)) {
- omap_bandgap_writel(bg_ptr,
- rval-bg_threshold,
- tsr-bgap_threshold);
+ omap_bandgap_writel(bg_ptr,
[PATCH 06/50] staging: omap-thermal: fix error checking
The omap_bandgap_get_sensor_data() function returns ERR_PTR(), but it can also return NULL, in case of initilization, so we need to use IS_ERR_OR_NULL() rather than only IS_ERR(). Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-thermal-common.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-thermal-common.c b/drivers/staging/omap-thermal/omap-thermal-common.c index 79a55aa..8aebc6a 100644 --- a/drivers/staging/omap-thermal/omap-thermal-common.c +++ b/drivers/staging/omap-thermal/omap-thermal-common.c @@ -260,7 +260,7 @@ int omap_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id, data = omap_bandgap_get_sensor_data(bg_ptr, id); - if (IS_ERR(data)) + if (IS_ERR_OR_NULL(data)) data = omap_thermal_build_data(bg_ptr, id); if (!data) @@ -309,7 +309,7 @@ int omap_thermal_register_cpu_cooling(struct omap_bandgap *bg_ptr, int id) struct omap_thermal_data *data; data = omap_bandgap_get_sensor_data(bg_ptr, id); - if (IS_ERR(data)) + if (IS_ERR_OR_NULL(data)) data = omap_thermal_build_data(bg_ptr, id); if (!data) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 07/50] staging: omap-thermal: introduce RMW_BITS macro
This patch introduce a macro to read, update, write bitfields.
It will be specific to bandgap data structures.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 178 +++
1 files changed, 46 insertions(+), 132 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 9f2d7cc..1c1b905 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -52,25 +52,29 @@ static void omap_bandgap_writel(struct omap_bandgap
*bg_ptr, u32 val, u32 reg)
writel(val, bg_ptr-base + reg);
}
+/* update bits, value will be shifted */
+#define RMW_BITS(bg_ptr, id, reg, mask, val) \
+do { \
+ struct temp_sensor_registers *t;\
+ u32 r; \
+ \
+ t = bg_ptr-conf-sensors[(id)].registers; \
+ r = omap_bandgap_readl(bg_ptr, t-reg); \
+ r = ~t-mask; \
+ r |= (val) __ffs(t-mask); \
+ omap_bandgap_writel(bg_ptr, r, t-reg); \
+} while (0)
+
static int omap_bandgap_power(struct omap_bandgap *bg_ptr, bool on)
{
- struct temp_sensor_registers *tsr;
int i;
- u32 ctrl;
if (!OMAP_BANDGAP_HAS(bg_ptr, POWER_SWITCH))
return 0;
- for (i = 0; i bg_ptr-conf-sensor_count; i++) {
- tsr = bg_ptr-conf-sensors[i].registers;
- ctrl = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
- ctrl = ~tsr-bgap_tempsoff_mask;
+ for (i = 0; i bg_ptr-conf-sensor_count; i++)
/* active on 0 */
- ctrl |= !on __ffs(tsr-bgap_tempsoff_mask);
-
- /* write BGAP_TEMPSOFF should be reset to 0 */
- omap_bandgap_writel(bg_ptr, ctrl, tsr-temp_sensor_ctrl);
- }
+ RMW_BITS(bg_ptr, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);
return 0;
}
@@ -78,15 +82,13 @@ static int omap_bandgap_power(struct omap_bandgap *bg_ptr,
bool on)
static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
{
struct temp_sensor_registers *tsr;
- u32 temp, ctrl, reg;
+ u32 temp, reg;
tsr = bg_ptr-conf-sensors[id].registers;
reg = tsr-temp_sensor_ctrl;
if (OMAP_BANDGAP_HAS(bg_ptr, FREEZE_BIT)) {
- ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_mask_ctrl);
- ctrl |= tsr-mask_freeze_mask;
- omap_bandgap_writel(bg_ptr, ctrl, tsr-bgap_mask_ctrl);
+ RMW_BITS(bg_ptr, id, bgap_mask_ctrl, mask_freeze_mask, 1);
/*
* In case we cannot read from cur_dtemp / dtemp_0,
* then we read from the last valid temp read
@@ -98,11 +100,8 @@ static u32 omap_bandgap_read_temp(struct omap_bandgap
*bg_ptr, int id)
temp = omap_bandgap_readl(bg_ptr, reg);
temp = tsr-bgap_dtemp_mask;
- if (OMAP_BANDGAP_HAS(bg_ptr, FREEZE_BIT)) {
- ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_mask_ctrl);
- ctrl = ~tsr-mask_freeze_mask;
- omap_bandgap_writel(bg_ptr, ctrl, tsr-bgap_mask_ctrl);
- }
+ if (OMAP_BANDGAP_HAS(bg_ptr, FREEZE_BIT))
+ RMW_BITS(bg_ptr, id, bgap_mask_ctrl, mask_freeze_mask, 0);
return temp;
}
@@ -290,37 +289,6 @@ int temp_sensor_configure_thot(struct omap_bandgap
*bg_ptr, int id, int t_hot)
return temp_sensor_unmask_interrupts(bg_ptr, id, t_hot, cold);
}
-/* Talert Thot and Tcold thresholds. Call it only if HAS(TALERT) is set */
-static
-int temp_sensor_init_talert_thresholds(struct omap_bandgap *bg_ptr, int id,
- int t_hot, int t_cold)
-{
- struct temp_sensor_registers *tsr;
- u32 reg_val, thresh_val;
-
- tsr = bg_ptr-conf-sensors[id].registers;
- thresh_val = omap_bandgap_readl(bg_ptr, tsr-bgap_threshold);
-
- /* write the new t_cold value */
- reg_val = thresh_val ~tsr-threshold_tcold_mask;
- reg_val |= (t_cold __ffs(tsr-threshold_tcold_mask));
- omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_threshold);
-
- thresh_val = omap_bandgap_readl(bg_ptr, tsr-bgap_threshold);
-
- /* write the new t_hot value */
- reg_val = thresh_val ~tsr-threshold_thot_mask;
- reg_val |= (t_hot __ffs(tsr-threshold_thot_mask));
- omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_threshold);
-
- reg_val = omap_bandgap_readl(bg_ptr, tsr-bgap_mask_ctrl);
- reg_val |= tsr-mask_hot_mask;
- reg_val |= tsr-mask_cold_mask;
- omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_mask_ctrl);
-
- return
[PATCH 08/50] staging: omap-thermal: add documentation for register access functions
Document the helper functions that manipulates registers and their
bitfields. All of them work based of the io mapped area.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 1c1b905..a8d63a2 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -42,17 +42,38 @@
#include omap-bandgap.h
+/**
+ * omap_bandgap_readl() - simple read helper function
+ * @bg_ptr: pointer to omap_bandgap structure
+ * @reg: desired register (offset) to be read
+ *
+ * Helper function to read bandgap registers. It uses the io remapped area.
+ * Returns the register value.
+ */
static u32 omap_bandgap_readl(struct omap_bandgap *bg_ptr, u32 reg)
{
return readl(bg_ptr-base + reg);
}
+/**
+ * omap_bandgap_writel() - simple write helper function
+ * @bg_ptr: pointer to omap_bandgap structure
+ * @val: desired register value to be written
+ * @reg: desired register (offset) to be written
+ *
+ * Helper function to write bandgap registers. It uses the io remapped area.
+ */
static void omap_bandgap_writel(struct omap_bandgap *bg_ptr, u32 val, u32 reg)
{
writel(val, bg_ptr-base + reg);
}
-/* update bits, value will be shifted */
+/**
+ * DOC: macro to update bits.
+ *
+ * RMW_BITS() - used to read, modify and update bandgap bitfields.
+ *The value passed will be shifted.
+ */
#define RMW_BITS(bg_ptr, id, reg, mask, val) \
do { \
struct temp_sensor_registers *t;\
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 09/50] staging: omap-thermal: make a omap_bandgap_power with only one exit point
Change the way the omap_bandgap_power is written so that it has only one exit entry (Documentation/CodingStyle). Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index a8d63a2..ec79ec1 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -91,12 +91,13 @@ static int omap_bandgap_power(struct omap_bandgap *bg_ptr, bool on) int i; if (!OMAP_BANDGAP_HAS(bg_ptr, POWER_SWITCH)) - return 0; + goto exit; for (i = 0; i bg_ptr-conf-sensor_count; i++) /* active on 0 */ RMW_BITS(bg_ptr, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on); +exit: return 0; } -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 10/50] staging: omap-thermal: add documentation for omap_bandgap_power
Document the helper function to turn a bandgap device on and off.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index ec79ec1..62a5fb9 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -86,6 +86,14 @@ do {
\
omap_bandgap_writel(bg_ptr, r, t-reg); \
} while (0)
+/**
+ * omap_bandgap_power() - controls the power state of a bandgap device
+ * @bg_ptr: pointer to omap_bandgap structure
+ * @on: desired power state (1 - on, 0 - off)
+ *
+ * Used to power on/off a bandgap device instance. Only used on those
+ * that features tempsoff bit.
+ */
static int omap_bandgap_power(struct omap_bandgap *bg_ptr, bool on)
{
int i;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/50] staging: omap-thermal: update documentation for talert irq handler
Document the Talert IRQ handler.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 1906ef1..aa60b7b 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -146,7 +146,17 @@ static u32 omap_bandgap_read_temp(struct omap_bandgap
*bg_ptr, int id)
return temp;
}
-/* This is the Talert handler. Call it only if HAS(TALERT) is set */
+/**
+ * omap_bandgap_talert_irq_handler() - handles Temperature alert IRQs
+ * @irq: IRQ number
+ * @data: private data (struct omap_bandgap *)
+ *
+ * This is the Talert handler. Use it only if bandgap device features
+ * HAS(TALERT). This handler goes over all sensors and checks their
+ * conditions and acts accordingly. In case there are events pending,
+ * it will reset the event mask to wait for the opposite event (next event).
+ * Every time there is a new event, it will be reported to thermal layer.
+ */
static irqreturn_t omap_bandgap_talert_irq_handler(int irq, void *data)
{
struct omap_bandgap *bg_ptr = data;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/50] staging: omap-thermal: remove duplicated code
There is no need to assign twice the same variable with the very same value.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index d0db361..531e853 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -164,7 +164,6 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int irq,
void *data)
u32 t_hot = 0, t_cold = 0, ctrl;
int i;
- bg_ptr = data;
/* Read the status of t_hot */
for (i = 0; i bg_ptr-conf-sensor_count; i++) {
tsr = bg_ptr-conf-sensors[i].registers;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/50] staging: omap-thermal: add a section of register manipulation
This is introduces a series of marks inside the code to better organize functions per group, aggregating their functionality. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index fce3942..77ff495 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -42,6 +42,8 @@ #include omap-bandgap.h +/*** Helper functions to access registers and their bitfields ***/ + /** * omap_bandgap_readl() - simple read helper function * @bg_ptr: pointer to omap_bandgap structure -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 21/50] staging: omap-thermal: name adc_to_temp_conversion in a better way
Rename adc_to_temp_conversion to omap_bandgap_adc_to_mcelsius. This name,
though longer, describes better the function.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 2acd30e..a7fd3e8 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -234,8 +234,8 @@ static irqreturn_t omap_bandgap_tshut_irq_handler(int irq,
void *data)
/*** Helper functions which manipulate conversion ADC - mi Celsius ***/
static
-int adc_to_temp_conversion(struct omap_bandgap *bg_ptr, int id, int adc_val,
- int *t)
+int omap_bandgap_adc_to_mcelsius(struct omap_bandgap *bg_ptr, int id,
+int adc_val, int *t)
{
struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[id].ts_data;
@@ -308,7 +308,7 @@ int add_hyst(int adc_val, int hyst_val, struct omap_bandgap
*bg_ptr, int i,
{
int temp, ret;
- ret = adc_to_temp_conversion(bg_ptr, i, adc_val, temp);
+ ret = omap_bandgap_adc_to_mcelsius(bg_ptr, i, adc_val, temp);
if (ret 0)
return ret;
@@ -439,7 +439,7 @@ int omap_bandgap_read_thot(struct omap_bandgap *bg_ptr, int
id,
temp = omap_bandgap_readl(bg_ptr, tsr-bgap_threshold);
temp = (temp tsr-threshold_thot_mask)
__ffs(tsr-threshold_thot_mask);
- ret |= adc_to_temp_conversion(bg_ptr, id, temp, temp);
+ ret |= omap_bandgap_adc_to_mcelsius(bg_ptr, id, temp, temp);
if (ret) {
dev_err(bg_ptr-dev, failed to read thot\n);
return -EIO;
@@ -514,7 +514,7 @@ int omap_bandgap_read_tcold(struct omap_bandgap *bg_ptr,
int id,
temp = omap_bandgap_readl(bg_ptr, tsr-bgap_threshold);
temp = (temp tsr-threshold_tcold_mask)
__ffs(tsr-threshold_tcold_mask);
- ret |= adc_to_temp_conversion(bg_ptr, id, temp, temp);
+ ret |= omap_bandgap_adc_to_mcelsius(bg_ptr, id, temp, temp);
if (ret)
return -EIO;
@@ -641,7 +641,7 @@ int omap_bandgap_read_temperature(struct omap_bandgap
*bg_ptr, int id,
temp = omap_bandgap_read_temp(bg_ptr, id);
mutex_unlock(bg_ptr-bg_mutex);
- ret |= adc_to_temp_conversion(bg_ptr, id, temp, temp);
+ ret |= omap_bandgap_adc_to_mcelsius(bg_ptr, id, temp, temp);
if (ret)
return -EIO;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 20/50] staging: omap-thermal: ADC section
Section of ADC helpers functions Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index ded2c8c..2acd30e 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -231,6 +231,8 @@ static irqreturn_t omap_bandgap_tshut_irq_handler(int irq, void *data) return IRQ_HANDLED; } +/*** Helper functions which manipulate conversion ADC - mi Celsius ***/ + static int adc_to_temp_conversion(struct omap_bandgap *bg_ptr, int id, int adc_val, int *t) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 22/50] staging: omap-thermal: rewrite omap_bandgap_adc_to_mcelsius on kernel coding style
Follow Documentation/CodingStyle while doing omap_bandgap_adc_to_mcelsius.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index a7fd3e8..0068c66 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -238,14 +238,19 @@ int omap_bandgap_adc_to_mcelsius(struct omap_bandgap
*bg_ptr, int id,
int adc_val, int *t)
{
struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[id].ts_data;
+ int ret = 0;
/* look up for temperature in the table and return the temperature */
- if (adc_val ts_data-adc_start_val || adc_val ts_data-adc_end_val)
- return -ERANGE;
+ if (adc_val ts_data-adc_start_val ||
+ adc_val ts_data-adc_end_val) {
+ ret = -ERANGE;
+ goto exit;
+ }
*t = bg_ptr-conf-conv_table[adc_val - ts_data-adc_start_val];
- return 0;
+exit:
+ return ret;
}
static int temp_to_adc_conversion(long temp, struct omap_bandgap *bg_ptr, int
i,
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 23/50] staging: omap-thermal: add documentation for omap_bandgap_adc_to_mcelsius
Document the conversion function. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 0068c66..8279cca 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -233,6 +233,17 @@ static irqreturn_t omap_bandgap_tshut_irq_handler(int irq, void *data) /*** Helper functions which manipulate conversion ADC - mi Celsius ***/ +/** + * omap_bandgap_adc_to_mcelsius() - converts an ADC value to mCelsius scale + * @bg_ptr: struct omap_bandgap pointer + * @id: sensor id + * @adc_val: value in ADC representation + * @t: address where to write the resulting temperature in mCelsius + * + * Simple conversion from ADC representation to mCelsius. In case the ADC value + * is out of the ADC conv table range, it returns -ERANGE, 0 on success. + * The conversion table is indexed by the ADC values. + */ static int omap_bandgap_adc_to_mcelsius(struct omap_bandgap *bg_ptr, int id, int adc_val, int *t) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 19/50] staging: omap-thermal: IRQ handler section
Section of IRQ handlers Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 7927c59..ded2c8c 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -150,6 +150,8 @@ static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id) return temp; } +/*** IRQ handlers ***/ + /** * omap_bandgap_talert_irq_handler() - handles Temperature alert IRQs * @irq: IRQ number -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 24/50] staging: omap-thermal: name temp_to_adc_conversion in a better way
Rename temp_to_adc_conversion to omap_bandgap_mcelsius_to_adc. This name,
though longer, describes better the function.
This patch also changes this function signature so the function follows
the style of this file.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 8279cca..d5359e3 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -264,8 +264,9 @@ exit:
return ret;
}
-static int temp_to_adc_conversion(long temp, struct omap_bandgap *bg_ptr, int
i,
- int *adc)
+static
+int omap_bandgap_mcelsius_to_adc(struct omap_bandgap *bg_ptr, int i, long temp,
+int *adc)
{
struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[i].ts_data;
const int *conv_table = bg_ptr-conf-conv_table;
@@ -330,7 +331,7 @@ int add_hyst(int adc_val, int hyst_val, struct omap_bandgap
*bg_ptr, int i,
temp += hyst_val;
- return temp_to_adc_conversion(temp, bg_ptr, i, sum);
+ return omap_bandgap_mcelsius_to_adc(bg_ptr, i, temp, sum);
}
/* Talert Thot threshold. Call it only if HAS(TALERT) is set */
@@ -493,7 +494,7 @@ int omap_bandgap_write_thot(struct omap_bandgap *bg_ptr,
int id, int val)
if (val ts_data-min_temp + ts_data-hyst_val)
return -EINVAL;
- ret = temp_to_adc_conversion(val, bg_ptr, id, t_hot);
+ ret = omap_bandgap_mcelsius_to_adc(bg_ptr, id, val, t_hot);
if (ret 0)
return ret;
@@ -566,7 +567,7 @@ int omap_bandgap_write_tcold(struct omap_bandgap *bg_ptr,
int id, int val)
if (val ts_data-max_temp + ts_data-hyst_val)
return -EINVAL;
- ret = temp_to_adc_conversion(val, bg_ptr, id, t_cold);
+ ret = omap_bandgap_mcelsius_to_adc(bg_ptr, id, val, t_cold);
if (ret 0)
return ret;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 25/50] staging: omap-thermal: rewrite omap_bandgap_mcelsius_to_adc on kernel coding style
Follow Documentation/CodingStyle while doing omap_bandgap_mcelsius_to_adc
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index d5359e3..e49a115 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -270,14 +270,16 @@ int omap_bandgap_mcelsius_to_adc(struct omap_bandgap
*bg_ptr, int i, long temp,
{
struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[i].ts_data;
const int *conv_table = bg_ptr-conf-conv_table;
- int high, low, mid;
+ int high, low, mid, ret = 0;
low = 0;
high = ts_data-adc_end_val - ts_data-adc_start_val;
mid = (high + low) / 2;
- if (temp conv_table[low] || temp conv_table[high])
- return -EINVAL;
+ if (temp conv_table[low] || temp conv_table[high]) {
+ ret = -ERANGE;
+ goto exit;
+ }
while (low high) {
if (temp conv_table[mid])
@@ -289,7 +291,8 @@ int omap_bandgap_mcelsius_to_adc(struct omap_bandgap
*bg_ptr, int i, long temp,
*adc = ts_data-adc_start_val + low;
- return 0;
+exit:
+ return ret;
}
/* Talert masks. Call it only if HAS(TALERT) is set */
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 26/50] staging: omap-thermal: move conv table limits out of sensor data
As we have one conv table per bandgap device and not per sensor,
this patch changes the data structures so that the conv table
min and max values are now part of bandgap_data and not sensor_data.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 39 +---
drivers/staging/omap-thermal/omap-bandgap.h |8 ++--
drivers/staging/omap-thermal/omap4-thermal-data.c | 10 +++--
drivers/staging/omap-thermal/omap5-thermal-data.c |8 +---
4 files changed, 30 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index e49a115..963fcaf 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -236,7 +236,6 @@ static irqreturn_t omap_bandgap_tshut_irq_handler(int irq,
void *data)
/**
* omap_bandgap_adc_to_mcelsius() - converts an ADC value to mCelsius scale
* @bg_ptr: struct omap_bandgap pointer
- * @id: sensor id
* @adc_val: value in ADC representation
* @t: address where to write the resulting temperature in mCelsius
*
@@ -245,35 +244,34 @@ static irqreturn_t omap_bandgap_tshut_irq_handler(int
irq, void *data)
* The conversion table is indexed by the ADC values.
*/
static
-int omap_bandgap_adc_to_mcelsius(struct omap_bandgap *bg_ptr, int id,
+int omap_bandgap_adc_to_mcelsius(struct omap_bandgap *bg_ptr,
int adc_val, int *t)
{
- struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[id].ts_data;
+ struct omap_bandgap_data *conf = bg_ptr-conf;
int ret = 0;
/* look up for temperature in the table and return the temperature */
- if (adc_val ts_data-adc_start_val ||
- adc_val ts_data-adc_end_val) {
+ if (adc_val conf-adc_start_val || adc_val conf-adc_end_val) {
ret = -ERANGE;
goto exit;
}
- *t = bg_ptr-conf-conv_table[adc_val - ts_data-adc_start_val];
+ *t = bg_ptr-conf-conv_table[adc_val - conf-adc_start_val];
exit:
return ret;
}
static
-int omap_bandgap_mcelsius_to_adc(struct omap_bandgap *bg_ptr, int i, long temp,
+int omap_bandgap_mcelsius_to_adc(struct omap_bandgap *bg_ptr, long temp,
int *adc)
{
- struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[i].ts_data;
+ struct omap_bandgap_data *conf = bg_ptr-conf;
const int *conv_table = bg_ptr-conf-conv_table;
int high, low, mid, ret = 0;
low = 0;
- high = ts_data-adc_end_val - ts_data-adc_start_val;
+ high = conf-adc_end_val - conf-adc_start_val;
mid = (high + low) / 2;
if (temp conv_table[low] || temp conv_table[high]) {
@@ -289,7 +287,7 @@ int omap_bandgap_mcelsius_to_adc(struct omap_bandgap
*bg_ptr, int i, long temp,
mid = (low + high) / 2;
}
- *adc = ts_data-adc_start_val + low;
+ *adc = conf-adc_start_val + low;
exit:
return ret;
@@ -323,18 +321,17 @@ static int temp_sensor_unmask_interrupts(struct
omap_bandgap *bg_ptr, int id,
}
static
-int add_hyst(int adc_val, int hyst_val, struct omap_bandgap *bg_ptr, int i,
-u32 *sum)
+int add_hyst(int adc_val, int hyst_val, struct omap_bandgap *bg_ptr, u32 *sum)
{
int temp, ret;
- ret = omap_bandgap_adc_to_mcelsius(bg_ptr, i, adc_val, temp);
+ ret = omap_bandgap_adc_to_mcelsius(bg_ptr, adc_val, temp);
if (ret 0)
return ret;
temp += hyst_val;
- return omap_bandgap_mcelsius_to_adc(bg_ptr, i, temp, sum);
+ return omap_bandgap_mcelsius_to_adc(bg_ptr, temp, sum);
}
/* Talert Thot threshold. Call it only if HAS(TALERT) is set */
@@ -354,7 +351,7 @@ int temp_sensor_configure_thot(struct omap_bandgap *bg_ptr,
int id, int t_hot)
__ffs(tsr-threshold_tcold_mask);
if (t_hot = cold) {
/* change the t_cold to t_hot - 5000 millidegrees */
- err |= add_hyst(t_hot, -ts_data-hyst_val, bg_ptr, id, cold);
+ err |= add_hyst(t_hot, -ts_data-hyst_val, bg_ptr, cold);
/* write the new t_cold value */
reg_val = thresh_val (~tsr-threshold_tcold_mask);
reg_val |= cold __ffs(tsr-threshold_tcold_mask);
@@ -392,7 +389,7 @@ int temp_sensor_configure_tcold(struct omap_bandgap
*bg_ptr, int id,
if (t_cold = hot) {
/* change the t_hot to t_cold + 5000 millidegrees */
- err |= add_hyst(t_cold, ts_data-hyst_val, bg_ptr, id, hot);
+ err |= add_hyst(t_cold, ts_data-hyst_val, bg_ptr, hot);
/* write the new t_hot value */
reg_val = thresh_val (~tsr-threshold_thot_mask);
reg_val |= hot __ffs(tsr-threshold_thot_mask);
@@ -459,7 +456,7 @@ int omap_bandgap_read_thot(struct omap_bandgap *bg_ptr, int
id,
[PATCH 27/50] staging: omap-thermal: add documentation for omap_bandgap_mcelsius_to_adc
Document the conversion function. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 963fcaf..39bfe8d 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -262,6 +262,16 @@ exit: return ret; } +/** + * omap_bandgap_mcelsius_to_adc() - converts a mCelsius value to ADC scale + * @bg_ptr: struct omap_bandgap pointer + * @temp: value in mCelsius + * @adc: address where to write the resulting temperature in ADC representation + * + * Simple conversion from mCelsius to ADC values. In case the temp value + * is out of the ADC conv table range, it returns -ERANGE, 0 on success. + * The conversion table is indexed by the ADC values. + */ static int omap_bandgap_mcelsius_to_adc(struct omap_bandgap *bg_ptr, long temp, int *adc) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 28/50] staging: omap-thermal: rename add_hyst to omap_bandgap_add_hyst
This patch improves the add_hyst function by:
. Renaming it to omap_bandgap_add_hyst
. Moving it to the ADC conversion functions section
. Changing its signature to follow the driver standard
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 42 --
1 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 39bfe8d..7b10d18 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -303,6 +303,28 @@ exit:
return ret;
}
+static
+int omap_bandgap_add_hyst(struct omap_bandgap *bg_ptr, int adc_val,
+ int hyst_val, u32 *sum)
+{
+ int temp, ret;
+
+ /*
+* Need to add in the mcelsius domain, so we have a temperature
+* the conv_table range
+*/
+ ret = omap_bandgap_adc_to_mcelsius(bg_ptr, adc_val, temp);
+ if (ret 0)
+ goto exit;
+
+ temp += hyst_val;
+
+ ret = omap_bandgap_mcelsius_to_adc(bg_ptr, temp, sum);
+
+exit:
+ return ret;
+}
+
/* Talert masks. Call it only if HAS(TALERT) is set */
static int temp_sensor_unmask_interrupts(struct omap_bandgap *bg_ptr, int id,
u32 t_hot, u32 t_cold)
@@ -330,20 +352,6 @@ static int temp_sensor_unmask_interrupts(struct
omap_bandgap *bg_ptr, int id,
return 0;
}
-static
-int add_hyst(int adc_val, int hyst_val, struct omap_bandgap *bg_ptr, u32 *sum)
-{
- int temp, ret;
-
- ret = omap_bandgap_adc_to_mcelsius(bg_ptr, adc_val, temp);
- if (ret 0)
- return ret;
-
- temp += hyst_val;
-
- return omap_bandgap_mcelsius_to_adc(bg_ptr, temp, sum);
-}
-
/* Talert Thot threshold. Call it only if HAS(TALERT) is set */
static
int temp_sensor_configure_thot(struct omap_bandgap *bg_ptr, int id, int t_hot)
@@ -361,7 +369,8 @@ int temp_sensor_configure_thot(struct omap_bandgap *bg_ptr,
int id, int t_hot)
__ffs(tsr-threshold_tcold_mask);
if (t_hot = cold) {
/* change the t_cold to t_hot - 5000 millidegrees */
- err |= add_hyst(t_hot, -ts_data-hyst_val, bg_ptr, cold);
+ err |= omap_bandgap_add_hyst(bg_ptr, t_hot,
+-ts_data-hyst_val, cold);
/* write the new t_cold value */
reg_val = thresh_val (~tsr-threshold_tcold_mask);
reg_val |= cold __ffs(tsr-threshold_tcold_mask);
@@ -399,7 +408,8 @@ int temp_sensor_configure_tcold(struct omap_bandgap
*bg_ptr, int id,
if (t_cold = hot) {
/* change the t_hot to t_cold + 5000 millidegrees */
- err |= add_hyst(t_cold, ts_data-hyst_val, bg_ptr, hot);
+ err |= omap_bandgap_add_hyst(bg_ptr, t_cold,
+ts_data-hyst_val, hot);
/* write the new t_hot value */
reg_val = thresh_val (~tsr-threshold_thot_mask);
reg_val |= hot __ffs(tsr-threshold_thot_mask);
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 29/50] staging: omap-thermal: document omap_bandgap_add_hyst function
Document function to handle hysteresis. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index 7b10d18..bff4b75 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -303,6 +303,16 @@ exit: return ret; } +/** + * omap_bandgap_add_hyst() - add hysteresis (in mCelsius) to an ADC value + * @bg_ptr: struct omap_bandgap pointer + * @adc_val: temperature value in ADC representation + * @hyst_val: hysteresis value in mCelsius + * @sum: address where to write the resulting temperature (in ADC scale) + * + * Adds an hysteresis value (in mCelsius) to a ADC temperature value. + * Returns 0 on success, -ERANGE otherwise. + */ static int omap_bandgap_add_hyst(struct omap_bandgap *bg_ptr, int adc_val, int hyst_val, u32 *sum) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 30/50] staging: omap-thermal: threshold manipulation section
Section of functions manipulating thresholds for Alert and Shutdown. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/omap-bandgap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omap-thermal/omap-bandgap.c b/drivers/staging/omap-thermal/omap-bandgap.c index bff4b75..f86c104 100644 --- a/drivers/staging/omap-thermal/omap-bandgap.c +++ b/drivers/staging/omap-thermal/omap-bandgap.c @@ -335,6 +335,8 @@ exit: return ret; } +/*** Helper functions handling device Alert/Shutdown signals ***/ + /* Talert masks. Call it only if HAS(TALERT) is set */ static int temp_sensor_unmask_interrupts(struct omap_bandgap *bg_ptr, int id, u32 t_hot, u32 t_cold) -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 31/50] staging: omap-thermal: refactor temp_sensor_unmask_interrupts
This change improves temp_sensor_unmask_interrupts by:
. renaming it to omap_bandgap_unmask_interrupts
. making it a void function, as there is nothing really to report an error.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index f86c104..26d36f3 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -338,8 +338,8 @@ exit:
/*** Helper functions handling device Alert/Shutdown signals ***/
/* Talert masks. Call it only if HAS(TALERT) is set */
-static int temp_sensor_unmask_interrupts(struct omap_bandgap *bg_ptr, int id,
-u32 t_hot, u32 t_cold)
+static void omap_bandgap_unmask_interrupts(struct omap_bandgap *bg_ptr, int id,
+ u32 t_hot, u32 t_cold)
{
struct temp_sensor_registers *tsr;
u32 temp, reg_val;
@@ -360,8 +360,6 @@ static int temp_sensor_unmask_interrupts(struct
omap_bandgap *bg_ptr, int id,
else
reg_val = ~tsr-mask_cold_mask;
omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_mask_ctrl);
-
- return 0;
}
/* Talert Thot threshold. Call it only if HAS(TALERT) is set */
@@ -399,7 +397,9 @@ int temp_sensor_configure_thot(struct omap_bandgap *bg_ptr,
int id, int t_hot)
return -EIO;
}
- return temp_sensor_unmask_interrupts(bg_ptr, id, t_hot, cold);
+ omap_bandgap_unmask_interrupts(bg_ptr, id, t_hot, cold);
+
+ return 0;
}
/* Talert Tcold threshold. Call it only if HAS(TALERT) is set */
@@ -438,7 +438,9 @@ int temp_sensor_configure_tcold(struct omap_bandgap
*bg_ptr, int id,
return -EIO;
}
- return temp_sensor_unmask_interrupts(bg_ptr, id, hot, t_cold);
+ omap_bandgap_unmask_interrupts(bg_ptr, id, hot, t_cold);
+
+ return 0;
}
#define bandgap_is_valid(b)\
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 33/50] staging: omap-thermal: refactor APIs handling threshold values
This patch improves the code that handles threshold values
by creating single functions that are usable for tcold and
thot. This way we won't have duplicated functionality just
because it is handling different bitfields. Now
the added functions are reused in several places where
it is needed to update any threshold.
This patch also removes macros that are used only inside
the _validate helper function.
In this patch there is also an addition of an extra function
section for Exposed APIs, used outside the omap-bandgap.c,
but inside the omap-thermal driver.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 278 +++
1 files changed, 117 insertions(+), 161 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index d001323..2a13bf0 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -370,145 +370,172 @@ static void omap_bandgap_unmask_interrupts(struct
omap_bandgap *bg_ptr, int id,
omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_mask_ctrl);
}
-/* Talert Thot threshold. Call it only if HAS(TALERT) is set */
static
-int temp_sensor_configure_thot(struct omap_bandgap *bg_ptr, int id, int t_hot)
+int omap_bandgap_update_alert_threshold(struct omap_bandgap *bg_ptr, int id,
+ int val, bool hot)
{
struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[id].ts_data;
struct temp_sensor_registers *tsr;
- u32 thresh_val, reg_val;
- int cold, err = 0;
+ u32 thresh_val, reg_val, t_hot, t_cold;
+ int err = 0;
tsr = bg_ptr-conf-sensors[id].registers;
- /* obtain the T cold value */
+ /* obtain the current value */
thresh_val = omap_bandgap_readl(bg_ptr, tsr-bgap_threshold);
- cold = (thresh_val tsr-threshold_tcold_mask)
- __ffs(tsr-threshold_tcold_mask);
- if (t_hot = cold) {
- /* change the t_cold to t_hot - 5000 millidegrees */
- err |= omap_bandgap_add_hyst(bg_ptr, t_hot,
--ts_data-hyst_val, cold);
- /* write the new t_cold value */
- reg_val = thresh_val (~tsr-threshold_tcold_mask);
- reg_val |= cold __ffs(tsr-threshold_tcold_mask);
- omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_threshold);
- thresh_val = reg_val;
+ t_cold = (thresh_val tsr-threshold_tcold_mask)
+ __ffs(tsr-threshold_tcold_mask);
+ t_hot = (thresh_val tsr-threshold_thot_mask)
+ __ffs(tsr-threshold_thot_mask);
+ if (hot)
+ t_hot = val;
+ else
+ t_cold = val;
+
+ if (t_cold t_hot) {
+ if (hot)
+ err = omap_bandgap_add_hyst(bg_ptr, t_hot,
+ -ts_data-hyst_val,
+ t_cold);
+ else
+ err = omap_bandgap_add_hyst(bg_ptr, t_cold,
+ ts_data-hyst_val,
+ t_hot);
}
- /* write the new t_hot value */
+ /* write the new threshold values */
reg_val = thresh_val ~tsr-threshold_thot_mask;
reg_val |= (t_hot __ffs(tsr-threshold_thot_mask));
+ reg_val |= thresh_val ~tsr-threshold_tcold_mask;
+ reg_val |= (t_cold __ffs(tsr-threshold_tcold_mask));
omap_bandgap_writel(bg_ptr, reg_val, tsr-bgap_threshold);
+
if (err) {
dev_err(bg_ptr-dev, failed to reprogram thot threshold\n);
- return -EIO;
+ err = -EIO;
+ goto exit;
}
- omap_bandgap_unmask_interrupts(bg_ptr, id, t_hot, cold);
-
- return 0;
+ omap_bandgap_unmask_interrupts(bg_ptr, id, t_hot, t_cold);
+exit:
+ return err;
}
-/* Talert Tcold threshold. Call it only if HAS(TALERT) is set */
-static
-int temp_sensor_configure_tcold(struct omap_bandgap *bg_ptr, int id,
- int t_cold)
+static inline int omap_bandgap_validate(struct omap_bandgap *bg_ptr, int id)
{
- struct temp_sensor_data *ts_data = bg_ptr-conf-sensors[id].ts_data;
- struct temp_sensor_registers *tsr;
- u32 thresh_val, reg_val;
- int hot, err = 0;
+ int ret = 0;
- tsr = bg_ptr-conf-sensors[id].registers;
- /* obtain the T cold value */
- thresh_val = omap_bandgap_readl(bg_ptr, tsr-bgap_threshold);
- hot = (thresh_val tsr-threshold_thot_mask)
- __ffs(tsr-threshold_thot_mask);
-
- if (t_cold = hot) {
- /* change the t_hot to t_cold + 5000 millidegrees */
- err |= omap_bandgap_add_hyst(bg_ptr, t_cold,
-
[PATCH 34/50] staging: omap-thermal: device initialization section
Section of helper functions to initilize the bandgap device
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 2a13bf0..8c7ac0e 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -703,6 +703,8 @@ void *omap_bandgap_get_sensor_data(struct omap_bandgap
*bg_ptr, int id)
return bg_ptr-conf-sensors[id].data;
}
+/*** Helper functions used during device initialization ***/
+
static int
omap_bandgap_force_single_read(struct omap_bandgap *bg_ptr, int id)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 35/50] staging: omap-thermal: section of device driver callbacks
Section with platform device callbacks
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 8c7ac0e..8746187 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -862,6 +862,8 @@ static struct omap_bandgap *omap_bandgap_build(struct
platform_device *pdev)
return bg_ptr;
}
+/*** Device driver call backs ***/
+
static
int omap_bandgap_probe(struct platform_device *pdev)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-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: omap: dts: Move interrupt-controller from #interrupt-cells description
On Fri, Mar 15, 2013 at 1:56 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the description
for the #interrupt-cells property after the interrupt-controller.
This is confusing so is better to move the interrupt-controller after
#interrupt-cells description.
Mmm, your are doing the opposite :-)
I guess what we do want is that:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
So we move #interrupt-cells after the interrupt-controller description.
Indeed!
I got confused I guess...
I'll send a v3 patch fixing the changelog
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/gpio/gpio.txt.
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
Hello,
Any comments on this patch?
I know is just a trivial documentation fix but I think it can be quite
helpful for people referring to gpio-omap binding.
I do agree. The patch is good, but the changelog is confusing.
Regards,
Benoit
Thanks a lot for your feedback and 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
[PATCH 36/50] staging: omap-thermal: rename enable_continuous_mode
This patch names 'enable_continuous_mode' accordingly to the file
standard naming.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 8746187..e325269 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -735,7 +735,7 @@ omap_bandgap_force_single_read(struct omap_bandgap *bg_ptr,
int id)
*
* Call this function only if HAS(MODE_CONFIG) is set
*/
-static int enable_continuous_mode(struct omap_bandgap *bg_ptr)
+static int omap_bandgap_set_continuous_mode(struct omap_bandgap *bg_ptr)
{
int i;
@@ -973,7 +973,7 @@ int omap_bandgap_probe(struct platform_device *pdev)
}
if (OMAP_BANDGAP_HAS(bg_ptr, MODE_CONFIG))
- enable_continuous_mode(bg_ptr);
+ omap_bandgap_set_continuous_mode(bg_ptr);
/* Set .250 seconds time as default counter */
if (OMAP_BANDGAP_HAS(bg_ptr, COUNTER))
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 37/50] staging: omap-thermal: update omap_bandgap_set_continous_mode documentation
Simple update on function documentation.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index e325269..d893931 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -730,10 +730,13 @@ omap_bandgap_force_single_read(struct omap_bandgap
*bg_ptr, int id)
}
/**
- * enable_continuous_mode() - One time enabling of continuous conversion mode
- * @bg_ptr - pointer to scm instance
+ * omap_bandgap_set_continous_mode() - One time enabling of continuous mode
+ * @bg_ptr: pointer to struct omap_bandgap
*
- * Call this function only if HAS(MODE_CONFIG) is set
+ * Call this function only if HAS(MODE_CONFIG) is set. As this driver may
+ * be used for junction temperature monitoring, it is desirable that the
+ * sensors are operational all the time, so that alerts are generated
+ * properly.
*/
static int omap_bandgap_set_continuous_mode(struct omap_bandgap *bg_ptr)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/50] staging: omap-thermal: update tshut IRQ handler documentation
Documents tshut handler better.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index aa60b7b..d0db361 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -207,7 +207,15 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int
irq, void *data)
return IRQ_HANDLED;
}
-/* This is the Tshut handler. Call it only if HAS(TSHUT) is set */
+/**
+ * omap_bandgap_tshut_irq_handler() - handles Temperature shutdown signal
+ * @irq: IRQ number
+ * @data: private data (unused)
+ *
+ * This is the Tshut handler. Use it only if bandgap device features
+ * HAS(TSHUT). If any sensor fires the Tshut signal, we simply shutdown
+ * the system.
+ */
static irqreturn_t omap_bandgap_tshut_irq_handler(int irq, void *data)
{
pr_emerg(%s: TSHUT temperature reached. Needs shut down...\n,
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 38/50] staging: omap-thermal: document omap_bandgap_force_single_read
Document function to initialize the conversion state machine.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index d893931..065f371 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -705,6 +705,14 @@ void *omap_bandgap_get_sensor_data(struct omap_bandgap
*bg_ptr, int id)
/*** Helper functions used during device initialization ***/
+/**
+ * omap_bandgap_force_single_read() - executes 1 single ADC conversion
+ * @bg_ptr: pointer to struct omap_bandgap
+ * @id: sensor id which it is desired to read 1 temperature
+ *
+ * Used to initialize the conversion state machine and set it to a valid
+ * state. Called during device initialization and context restore events.
+ */
static int
omap_bandgap_force_single_read(struct omap_bandgap *bg_ptr, int id)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 40/50] staging: omap-thermal: document _omap_bandgap_write_threshold function
Document function to update alert thresholds.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 0eb21b3..4cacfc1 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -455,6 +455,19 @@ exit:
return ret;
}
+/**
+ * _omap_bandgap_write_threshold() - helper to update TALERT t_cold or t_hot
+ * @bg_ptr: struct omap_bandgap pointer
+ * @id: bandgap sensor id
+ * @val: value (mCelsius) of a new threshold
+ * @hot: desired threshold to be updated. true if threshold hot, false if
+ * threshold cold
+ *
+ * It will update the required thresholds (hot and cold) for TALERT signal.
+ * This function can be used to update t_hot or t_cold, depending on @hot
value.
+ * Validates the mCelsius range and update the requested threshold.
+ * Call this function only if bandgap features HAS(TALERT).
+ */
int _omap_bandgap_write_threshold(struct omap_bandgap *bg_ptr, int id, int val,
bool hot)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 41/50] staging: omap-thermal: document _omap_bandgap_read_threshold function
Add documentation of the function for reading alert thresholds
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 4cacfc1..aa90539 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -510,6 +510,18 @@ exit:
return ret;
}
+/**
+ * _omap_bandgap_read_threshold() - helper to read TALERT t_cold or t_hot
+ * @bg_ptr: struct omap_bandgap pointer
+ * @id: bandgap sensor id
+ * @val: value (mCelsius) of a threshold
+ * @hot: desired threshold to be read. true if threshold hot, false if
+ * threshold cold
+ *
+ * It will fetch the required thresholds (hot and cold) for TALERT signal.
+ * This function can be used to read t_hot or t_cold, depending on @hot value.
+ * Call this function only if bandgap features HAS(TALERT).
+ */
int _omap_bandgap_read_threshold(struct omap_bandgap *bg_ptr, int id,
int *val, bool hot)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 42/50] staging: omap-thermal: document omap_bandgap_tshut_init function
Add documentation for the function to setup TSHUT handling
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index aa90539..f2ebbcf 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -798,6 +798,18 @@ static int omap_bandgap_set_continuous_mode(struct
omap_bandgap *bg_ptr)
return 0;
}
+/**
+ * omap_bandgap_tshut_init() - setup and initialize tshut handling
+ * @bg_ptr: pointer to struct omap_bandgap
+ * @pdev: pointer to device struct platform_device
+ *
+ * Call this function only in case the bandgap features HAS(TSHUT).
+ * In this case, the driver needs to handle the TSHUT signal as an IRQ.
+ * The IRQ is wired as a GPIO, and for this purpose, it is required
+ * to specify which GPIO line is used. TSHUT IRQ is fired anytime
+ * one of the bandgap sensors violates the TSHUT high/hot threshold.
+ * And in that case, the system must go off.
+ */
static int omap_bandgap_tshut_init(struct omap_bandgap *bg_ptr,
struct platform_device *pdev)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 44/50] staging: omap-thermal: document omap_bandgap_build function
Document function to build omap_bandgap structure
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 3150ec2..4b631fd 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -875,6 +875,15 @@ static int omap_bandgap_talert_init(struct omap_bandgap
*bg_ptr,
return 0;
}
+/**
+ * omap_bandgap_build() - parse DT and setup a struct omap_bandgap
+ * @bg_ptr: pointer to struct omap_bandgap
+ * @pdev: pointer to device struct platform_device
+ *
+ * Used to read the device tree properties accordingly to the bandgap
+ * matching version. Based on bandgap version and its capabilities it
+ * will build a struct omap_bandgap out of the required DT entries.
+ */
static const struct of_device_id of_omap_bandgap_match[];
static struct omap_bandgap *omap_bandgap_build(struct platform_device *pdev)
{
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 46/50] staging: Add a MAINTAINERS entry for TI bandgap and thermal driver
Add myself as maintainer of the TI bandgap and thermal driver. CC: Santosh Shilimkar santosh.shilim...@ti.com CC: Zhang Rui rui.zh...@intel.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- MAINTAINERS |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6672165..199bb4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7915,6 +7915,12 @@ T: git git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git S: Maintained F: drivers/platform/x86/thinkpad_acpi.c +TI BANDGAP AND THERMAL DRIVER +M: Eduardo Valentin eduardo.valen...@ti.com +L: linux...@vger.kernel.org +S: Maintained +F: drivers/staging/omap-thermal/ + TI FLASH MEDIA INTERFACE DRIVER M: Alex Dubov oa...@yahoo.com S: Maintained -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 47/50] staging: omap-thermal: switch mutex to spinlock inside omap-bandgap
Because there is a need to lock inside IRQ handler, this patch
changes the locking mechanism inside the omap-bandgap.[c,h] to
spinlocks. Now this lock is used to protect omap_bandgap struct
during APIs exposed (possibly used in sysfs handling functions)
and inside the ALERT IRQ handler.
Because there are registers shared among the sensors, this lock
is global, not per sensor.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/TODO |1 -
drivers/staging/omap-thermal/omap-bandgap.c | 18 ++
drivers/staging/omap-thermal/omap-bandgap.h |4 ++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omap-thermal/TODO
b/drivers/staging/omap-thermal/TODO
index 77b761b..0f24e9b 100644
--- a/drivers/staging/omap-thermal/TODO
+++ b/drivers/staging/omap-thermal/TODO
@@ -1,7 +1,6 @@
List of TODOs (by Eduardo Valentin)
on omap-bandgap.c:
-- Rework locking
- Improve driver code by adding usage of regmap-mmio
- Test every exposed API to userland
- Add support to hwmon
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 4b631fd..846ced6 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -33,7 +33,7 @@
#include linux/platform_device.h
#include linux/err.h
#include linux/types.h
-#include linux/mutex.h
+#include linux/spinlock.h
#include linux/reboot.h
#include linux/of_device.h
#include linux/of_platform.h
@@ -170,6 +170,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int irq,
void *data)
u32 t_hot = 0, t_cold = 0, ctrl;
int i;
+ spin_lock(bg_ptr-lock);
for (i = 0; i bg_ptr-conf-sensor_count; i++) {
tsr = bg_ptr-conf-sensors[i].registers;
ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_status);
@@ -208,6 +209,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int irq,
void *data)
if (bg_ptr-conf-report_temperature)
bg_ptr-conf-report_temperature(bg_ptr, i);
}
+ spin_unlock(bg_ptr-lock);
return IRQ_HANDLED;
}
@@ -502,9 +504,9 @@ int _omap_bandgap_write_threshold(struct omap_bandgap
*bg_ptr, int id, int val,
if (ret 0)
goto exit;
- mutex_lock(bg_ptr-bg_mutex);
+ spin_lock(bg_ptr-lock);
omap_bandgap_update_alert_threshold(bg_ptr, id, adc_val, hot);
- mutex_unlock(bg_ptr-bg_mutex);
+ spin_unlock(bg_ptr-lock);
exit:
return ret;
@@ -666,9 +668,9 @@ int omap_bandgap_write_update_interval(struct omap_bandgap
*bg_ptr,
return -ENOTSUPP;
interval = interval * bg_ptr-clk_rate / 1000;
- mutex_lock(bg_ptr-bg_mutex);
+ spin_lock(bg_ptr-lock);
RMW_BITS(bg_ptr, id, bgap_counter, counter_mask, interval);
- mutex_unlock(bg_ptr-bg_mutex);
+ spin_unlock(bg_ptr-lock);
return 0;
}
@@ -691,9 +693,9 @@ int omap_bandgap_read_temperature(struct omap_bandgap
*bg_ptr, int id,
if (ret)
return ret;
- mutex_lock(bg_ptr-bg_mutex);
+ spin_lock(bg_ptr-lock);
temp = omap_bandgap_read_temp(bg_ptr, id);
- mutex_unlock(bg_ptr-bg_mutex);
+ spin_unlock(bg_ptr-lock);
ret |= omap_bandgap_adc_to_mcelsius(bg_ptr, temp, temp);
if (ret)
@@ -1016,7 +1018,7 @@ int omap_bandgap_probe(struct platform_device *pdev)
clk_prepare_enable(bg_ptr-fclock);
- mutex_init(bg_ptr-bg_mutex);
+ spin_lock_init(bg_ptr-lock);
bg_ptr-dev = pdev-dev;
platform_set_drvdata(pdev, bg_ptr);
diff --git a/drivers/staging/omap-thermal/omap-bandgap.h
b/drivers/staging/omap-thermal/omap-bandgap.h
index edcc965..5700586 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.h
+++ b/drivers/staging/omap-thermal/omap-bandgap.h
@@ -23,7 +23,7 @@
#ifndef __OMAP_BANDGAP_H
#define __OMAP_BANDGAP_H
-#include linux/mutex.h
+#include linux/spinlock.h
#include linux/types.h
#include linux/err.h
@@ -211,7 +211,7 @@ struct omap_bandgap {
struct omap_bandgap_data*conf;
struct clk *fclock;
struct clk *div_clk;
- struct mutexbg_mutex; /* shields this struct */
+ spinlock_t lock; /* shields this struct */
int irq;
int tshut_gpio;
u32 clk_rate;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 48/50] staging: omap-thermal: remove TODO entry suggesting regmap usage
It is hard to use regmap because benefit of using regmap cache may not be applicable as there is a specific sequence to restore the bandgap context. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/TODO |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/staging/omap-thermal/TODO b/drivers/staging/omap-thermal/TODO index 0f24e9b..91e2070 100644 --- a/drivers/staging/omap-thermal/TODO +++ b/drivers/staging/omap-thermal/TODO @@ -1,7 +1,6 @@ List of TODOs (by Eduardo Valentin) on omap-bandgap.c: -- Improve driver code by adding usage of regmap-mmio - Test every exposed API to userland - Add support to hwmon - Review and revisit all API exposed -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 49/50] staging: omap-thermal: remove TODO entry for exposed APIs
Not all APIs exposed today are used. However all unused APIs will be required once the thermal layer allows IRQ based policies. Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- drivers/staging/omap-thermal/TODO |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/staging/omap-thermal/TODO b/drivers/staging/omap-thermal/TODO index 91e2070..d45f556 100644 --- a/drivers/staging/omap-thermal/TODO +++ b/drivers/staging/omap-thermal/TODO @@ -3,7 +3,6 @@ List of TODOs (by Eduardo Valentin) on omap-bandgap.c: - Test every exposed API to userland - Add support to hwmon -- Review and revisit all API exposed - Revisit PM support - Revisit data structures and simplify them - Once SCM-core api settles, update this driver accordingly -- 1.7.7.1.488.ge8e1c -- To unsubscribe from this list: send the line unsubscribe 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 50/50] staging: omap-thermal: add documentation for omap_bandgap_validate
Document the helper to validate a struct omap_bandgap and a sensor id.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/staging/omap-thermal/omap-bandgap.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 846ced6..33bfe3b 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -437,6 +437,14 @@ exit:
return err;
}
+/**
+ * omap_bandgap_validate() - helper to check the sanity of a struct
omap_bandgap
+ * @bg_ptr: struct omap_bandgap pointer
+ * @id: bandgap sensor id
+ *
+ * Checks if the bandgap pointer is valid and if the sensor id is also
+ * applicable.
+ */
static inline int omap_bandgap_validate(struct omap_bandgap *bg_ptr, int id)
{
int ret = 0;
--
1.7.7.1.488.ge8e1c
--
To unsubscribe from this list: send the line unsubscribe 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 4/4] usb: otg: twl4030: fix cold plug on OMAP3
Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is ready.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/phy/phy-twl4030-usb.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index e14b03e..1986c78 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -510,8 +510,9 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
return IRQ_HANDLED;
}
-static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+static int twl4030_usb_phy_init(struct usb_phy *phy)
{
+ struct twl4030_usb *twl = phy_to_twl(phy);
enum omap_musb_vbus_id_status status;
status = twl4030_usb_linkstat(twl);
@@ -528,6 +529,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
omap_musb_mailbox(twl-linkstat);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
+ return 0;
}
static int twl4030_set_suspend(struct usb_phy *x, int suspend)
@@ -604,6 +606,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.otg= otg;
twl-phy.type = USB_PHY_TYPE_USB2;
twl-phy.set_suspend= twl4030_set_suspend;
+ twl-phy.init = twl4030_usb_phy_init;
otg-phy= twl-phy;
otg-set_host = twl4030_set_host;
@@ -641,11 +644,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
- /* Power down phy or make it work according to
-* current link state.
-*/
- twl4030_usb_phy_init(twl);
-
dev_info(pdev-dev, Initialized TWL4030 USB module\n);
return 0;
}
--
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 v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move #interrupt-cells after the
interrupt-controller property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
Reported-by: Stephen Warren swar...@nvidia.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Jon Hunter jon-hun...@ti.com
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- ti,omap2-gpio for OMAP2 controllers
- ti,omap3-gpio for OMAP3 controllers
- ti,omap4-gpio for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio4;
-#gpio-cells = 2;
gpio-controller;
-#interrupt-cells = 2;
+#gpio-cells = 2;
interrupt-controller;
+#interrupt-cells = 2;
};
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB
On Friday 15 March 2013 06:11 PM, Benoit Cousson wrote: + Jon Hi Kishon, On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote: Hi Benoit, Here are the dt data patches to get usb device functional in OMAP platforms. All the patches deal with modifying arch/arm/boot except one which modifies Documentation/../usb/omap-usb.txt Changes from v2: * squashed the dt data for dwc3-omap with dwc3 core into a single patch. Changes from v1: Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with names that has _. It's replaced with a - here. This patch is developed on Linux 3.9-rc1. The patches looks really good. I've just had to rebase on top of my HEAD due to some conflict with GPMC patch already applied. I cleaned as well some subject and changelog for consistency. Ok. Thanks :-) Regards Kishon -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 16:42-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in migrating the cpufreq support only through device tree (part of the effort to migrate away from non-DT configurations for OMAP). Unfortunately, as already known, we have a bunch of legacy code and mutually dependent device tree conversion that is pending. Key features pending: A) clock framework transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series B) on processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Note: Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements there as well. OMAP has been converted to the common clock framework (CCF). Are you referring to clock framework transition to DT or something else? I should have been explicit here - we do not have DT entries for clock nodes for OMAP. For example, compare: git grep clocks arch/arm/boot/dts/omap*.dts* Vs git grep clocks arch/arm/boot/dts/imx*.dts* The specific comment above was intended to see the following series equivalent in upstream: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP36xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This overrides the default OMAP34xx CPU OPP table definition. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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 V2 0/8] ARM: dts: Various OMAP2+ device-tree updates
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon Benoit's for_3.10/dts branch [1]. Branch available here [2]. V2 changes: - Rebased on Benoit's for_3.10/dts branch - Squashed patches adding support for OMAP3430 SDP board and patch to add flash support for OMAP3430 SDP board. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 Jon Hunter (8): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio ARM: dts: OMAP3: Add support for OMAP3430 SDP board arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 arch/arm/boot/dts/omap2420.dtsi | 55 + arch/arm/boot/dts/omap2430.dtsi | 66 arch/arm/boot/dts/omap3.dtsi | 70 +++-- arch/arm/boot/dts/omap3430-sdp.dts | 141 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 +-- arch/arm/boot/dts/omap4460.dtsi | 18 + arch/arm/boot/dts/omap5.dtsi | 68 ++-- arch/arm/mach-omap2/pmu.c| 14 +++- 11 files changed, 493 insertions(+), 23 deletions(-) create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 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 V2 1/8] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 9debf82..9ace8ea 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include linux/of.h
+
#include asm/pmu.h
#include soc.h
@@ -63,6 +65,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -75,9 +86,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info(ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n);
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
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 V2 2/8] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = arm,arm1136-pmu;
+ interrupts = 3;
+ };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d9970de..0ec7d5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = arm,cortex-a8-pmu;
+ interrupts = 3;
+ ti,hwmods = debugss;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ omap4-panda.dts
+/include/ omap4460.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupts = 0 54 0x4,
+0 55 0x4;
+ ti,hwmods = debugss;
+ };
+};
--
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 V2 4/8] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/boot/dts/omap5.dtsi| 11 +++
4 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af65609..d4ce6c2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc;
+ reg = 0x6800a000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2420-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c392445..832f184 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap2430-gpmc;
+ reg = 0x6e00 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = ti,omap2430-mcbsp;
reg = 0x48074000 0xff;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6669311..bcd64f5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,17 @@
#interrupt-cells = 1;
};
+ gpmc: gpmc@5000 {
+ compatible = ti,omap4430-gpmc;
+ reg = 0x5000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 0 20 0x4;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
reg = 0x4806a000 0x100;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f840499..61cbd1c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -208,6 +208,17 @@
#interrupt-cells = 1;
};
+ gpmc: gpmc@5000 {
+ compatible = ti,omap4430-gpmc;
+ reg = 0x5000 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ interrupts = 0 20 0x4;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ ti,hwmods = gpmc;
+ };
+
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
reg = 0x4807 0x100;
--
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 V2 5/8] ARM: dts: Add OMAP2 gpio bindings
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++
arch/arm/boot/dts/omap2430.dtsi | 55 +++
2 files changed, 99 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index d4ce6c2..eee902f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,50 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpio1: gpio@48018000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x48018000 0x200;
+ interrupts = 29;
+ ti,hwmods = gpio1;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4801a000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4801a000 0x200;
+ interrupts = 30;
+ ti,hwmods = gpio2;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4801c000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4801c000 0x200;
+ interrupts = 31;
+ ti,hwmods = gpio3;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@4801e000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4801e000 0x200;
+ interrupts = 32;
+ ti,hwmods = gpio4;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6800a000 {
compatible = ti,omap2420-gpmc;
reg = 0x6800a000 0x1000;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 832f184..fb74382 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,61 @@
pinctrl-single,function-mask = 0x3f;
};
+ gpio1: gpio@4900c000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4900c000 0x200;
+ interrupts = 29;
+ ti,hwmods = gpio1;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4900e000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4900e000 0x200;
+ interrupts = 30;
+ ti,hwmods = gpio2;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4901 {
+ compatible = ti,omap2-gpio;
+ reg = 0x4901 0x200;
+ interrupts = 31;
+ ti,hwmods = gpio3;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@49012000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x49012000 0x200;
+ interrupts = 32;
+ ti,hwmods = gpio4;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
+ gpio5: gpio@480b6000 {
+ compatible = ti,omap2-gpio;
+ reg = 0x480b6000 0x200;
+ interrupts = 33;
+ ti,hwmods = gpio5;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6e00 {
compatible = ti,omap2430-gpmc;
reg = 0x6e00 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
[PATCH V2 7/8] ARM: dts: OMAP3: Add reg and interrupt properties for gpio
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index badedc8..0cc65b5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,6 +113,8 @@
gpio1: gpio@4831 {
compatible = ti,omap3-gpio;
+ reg = 0x4831 0x200;
+ interrupts = 29;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -122,6 +124,8 @@
gpio2: gpio@4905 {
compatible = ti,omap3-gpio;
+ reg = 0x4905 0x200;
+ interrupts = 30;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -131,6 +135,8 @@
gpio3: gpio@49052000 {
compatible = ti,omap3-gpio;
+ reg = 0x49052000 0x200;
+ interrupts = 31;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -140,6 +146,8 @@
gpio4: gpio@49054000 {
compatible = ti,omap3-gpio;
+ reg = 0x49054000 0x200;
+ interrupts = 32;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -149,6 +157,8 @@
gpio5: gpio@49056000 {
compatible = ti,omap3-gpio;
+ reg = 0x49056000 0x200;
+ interrupts = 33;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -158,6 +168,8 @@
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
+ reg = 0x49058000 0x200;
+ interrupts = 34;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
--
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 V2 6/8] ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and polarity (high or low) of the interrupt. The OMAP gpio
controllers support these options and so update the #interrupt-cells
property for OMAP3+ devices to 2.
[1] Documentation/devicetree/bindings/gpio/gpio-omap.txt
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
arch/arm/boot/dts/omap4.dtsi | 12 ++--
arch/arm/boot/dts/omap5.dtsi | 16
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1dc72ea..badedc8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -117,7 +117,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio2: gpio@4905 {
@@ -126,7 +126,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio3: gpio@49052000 {
@@ -135,7 +135,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio4: gpio@49054000 {
@@ -144,7 +144,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio5: gpio@49056000 {
@@ -153,7 +153,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio6: gpio@49058000 {
@@ -162,7 +162,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
uart1: serial@4806a000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bcd64f5..bed47c5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -138,7 +138,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio2: gpio@48055000 {
@@ -149,7 +149,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio3: gpio@48057000 {
@@ -160,7 +160,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio4: gpio@48059000 {
@@ -171,7 +171,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio5: gpio@4805b000 {
@@ -182,7 +182,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio6: gpio@4805d000 {
@@ -193,7 +193,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpmc: gpmc@5000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 61cbd1c..b4d2eb9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -128,7 +128,7 @@
gpio-controller;
#gpio-cells = 2;
[PATCH V2 8/8] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM, 128MB ONENAND flash, 256MB NAND flash and uses the TWL4030
power management IC.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 141
2 files changed, 142 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index de29da5..a38dcd4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
imx28-tx28.dtb
dtb-$(CONFIG_ARCH_NOMADIK) += ste-nomadik-s8815.dtb
dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
+ omap3430-sdp.dtb \
omap3-beagle.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 000..535a6f9
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.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.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI OMAP3430 SDP;
+ compatible = ti,omap3430-sdp, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ };
+};
+
+/include/ twl4030.dtsi
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+gpmc {
+ ranges = 1 0 0x2800 0x0800,
+2 0 0x2000 0x1000;
+
+ nand@1,0 {
+ linux,mtd-name= micron,mt29f1g08abb;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 1 0 0x0800;
+ nand-bus-width = 8;
+
+ ti,nand-ecc-opt = sw;
+ gpmc,device-nand;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 36;
+ gpmc,cs-wr-off = 36;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 24;
+ gpmc,adv-wr-off = 36;
+ gpmc,oe-on = 6;
+ gpmc,oe-off = 48;
+ gpmc,we-on = 6;
+ gpmc,we-off = 30;
+ gpmc,rd-cycle = 72;
+ gpmc,wr-cycle = 72;
+ gpmc,access = 54;
+ gpmc,wr-access = 30;
+
+ partition@0 {
+ label = xloader-nand;
+ reg = 0 0x8;
+ };
+ partition@0x8 {
+ label = bootloader-nand;
+ reg = 0x8 0x14;
+ };
+ partition@0x1c {
+ label = params-nand;
+ reg = 0x1c 0xc;
+ };
+ partition@0x28 {
+ label = kernel-nand;
+ reg = 0x28 0x50;
+ };
+ partition@0x78 {
+ label = filesystem-nand;
+ reg = 0x78 0x788;
+ };
+ };
+
+ onenand@2,0 {
+ linux,mtd-name= samsung,kfm2g16q2m-deb8;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 2 0 0x1000;
+
+ gpmc,device-width = 2;
+ gpmc,mux-add-data = 2;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 84;
+ gpmc,cs-wr-off = 72;
+ gpmc,adv-on = 0;
+ gpmc,adv-rd-off = 18;
+ gpmc,adv-wr-off = 18;
+ gpmc,oe-on = 30;
+ gpmc,oe-off = 84;
+ gpmc,we-on = 0;
+ gpmc,we-off = 42;
+ gpmc,rd-cycle = 108;
+ gpmc,wr-cycle = 96;
+ gpmc,access = 78;
+ gpmc,wr-data-mux-bus = 30;
+
+ partition@0 {
+ label = xloader-onenand;
+ reg = 0 0x8;
+ };
+ partition@0x8 {
+ label = bootloader-onenand;
+ reg = 0x8 0x4;
+ };
+ partition@0xc {
+ label = params-onenand;
+ reg = 0xc 0x2;
+ };
+ partition@0xe {
+ label = kernel-onenand;
+ reg = 0xe 0x20;
+ };
[PATCH V2 3/8] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC peripheral on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap2.dtsi | 12
arch/arm/boot/dts/omap3.dtsi | 40
arch/arm/boot/dts/omap4.dtsi | 41 +
arch/arm/boot/dts/omap5.dtsi | 41 +
4 files changed, 134 insertions(+)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 27f5ea1..84183f0 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -54,6 +54,18 @@
reg = 0x480FE000 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap2430-sdma, ti,omap2420-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 64;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 0ec7d5c..1dc72ea 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -81,6 +81,18 @@
reg = 0x4820 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap3630-sdma, ti,omap3430-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 96;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002030 0x05cc;
@@ -198,6 +210,16 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
+ dmas = sdma 35,
+ sdma 36,
+ sdma 37,
+ sdma 38,
+ sdma 39,
+ sdma 40,
+ sdma 41,
+ sdma 42;
+ dma-names = tx0, rx0, tx1, rx1,
+ tx2, rx2, tx3, rx3;
};
mcspi2: spi@4809a000 {
@@ -206,6 +228,11 @@
#size-cells = 0;
ti,hwmods = mcspi2;
ti,spi-num-cs = 2;
+ dmas = sdma 43,
+ sdma 44,
+ sdma 45,
+ sdma 46;
+ dma-names = tx0, rx0, tx1, rx1;
};
mcspi3: spi@480b8000 {
@@ -214,6 +241,11 @@
#size-cells = 0;
ti,hwmods = mcspi3;
ti,spi-num-cs = 2;
+ dmas = sdma 15,
+ sdma 16,
+ sdma 23,
+ sdma 24;
+ dma-names = tx0, rx0, tx1, rx1;
};
mcspi4: spi@480ba000 {
@@ -222,22 +254,30 @@
#size-cells = 0;
ti,hwmods = mcspi4;
ti,spi-num-cs = 1;
+ dmas = sdma 70, sdma 71;
+ dma-names = tx0, rx0;
};
mmc1: mmc@4809c000 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc1;
ti,dual-volt;
+ dmas = sdma 61, sdma 62;
+ dma-names = tx, rx;
};
mmc2: mmc@480b4000 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc2;
+ dmas = sdma 47, sdma 48;
+ dma-names = tx, rx;
};
mmc3: mmc@480ad000 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
+
Re: [PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree
On 16:49-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: OMAP4430 and 4460 have different OPP definitions. So, create an SoC variant dtsi file for 4460 and move the OPP definitions to it. FYI, I had to create a similar file for PMU [1]. However, I called it omap4460.dtsi and not omap446x.dtsi as there is only one omap446x Hmm, guess I was paranoid about marketing folks spinning off another omap446x variant out into the market. Since it is not yet done, nor known if they will ever do it, am OK with 4460 convention. device. That should go into to v3.10 and so may be worth basing this on top. I do like your omap4-panda-common.dtsi that is a nice clean-up. Thanks on the tip - Sounds good, since this series is based on DT, I will base my changes on top of for_3.10 branch. Cheers Jon [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dtsid=5e64b6b1137a54f353528d6da60071c1ef0043ba -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net PATCH 1/1] drivers: net: ethernet: ti: davinci_emac: fix usage of cpdma_check_free_tx_desc()
Fix which was done in the following commit in cpsw driver has to be taken forward to davinci emac driver as well. commit d35162f89b8f00537d7b240b76d2d0e8b8d29aa0 Author: Daniel Mack zon...@gmail.com Date: Tue Mar 12 06:31:19 2013 + net: ethernet: cpsw: fix usage of cpdma_check_free_tx_desc() Commit fae50823d0 (net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors) introduced a function to check the current allocation state of tx packets. The return value is taken into account to stop the netqork queue on the adapter in case there are no free slots. However, cpdma_check_free_tx_desc() returns 'true' if there is room in the bitmap, not 'false', so the usage of the function is wrong. Reported-by: Prabhakar Lad prabhakar.cse...@gmail.com Signed-off-by: Mugunthan V N mugunthan...@ti.com --- drivers/net/ethernet/ti/davinci_emac.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 52c0536..ae1b77a 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1102,7 +1102,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev) /* If there is no more tx desc left free then we need to * tell the kernel to stop sending us tx frames. */ - if (unlikely(cpdma_check_free_tx_desc(priv-txchan))) + if (unlikely(!cpdma_check_free_tx_desc(priv-txchan))) netif_stop_queue(ndev); return NETDEV_TX_OK; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 10:48-20130315, Santosh Shilimkar wrote: On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote: The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in migrating the cpufreq support only through device tree (part of the effort to migrate away from non-DT configurations for OMAP). Unfortunately, as already known, we have a bunch of legacy code and mutually dependent device tree conversion that is pending. Key features pending: A) clock framework transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series B) on processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Thanks for looking into it. Yes, this should be the next stage to solve. Note: Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements there as well. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to DT. As a result of this series, CPUFreq feature will not be available for non-DT boot systems. As commented by Jon on internal thread, I am also against the idea of dropping non-DT support now. Till we migrate to 100 % DT, it is best to keep support alive. Especial OMAP3 based devices. Why don't you take phased approach and have both supported for time being. Then once we move to DT only, we just drop the non-DT support as we plan to do for many more stuff. BTW, we are using only CPUFreq driver before this series as well. I guess you mean the common CPUFReq drivers used by other ARM SOCs. I had removed the entries for OPPs and clock nodes used by omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement CPUFreq wont work in non-DT configuration was accurate. My intent was as follows: - This series is driven mainly from maintenance angle - having to maintain two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c), ensuring the data is proper in both OPP tables in kernel and DT entries is sure to cause mayhem sometime. This is not just an pain for OMAP community, but for cpufreq community as well (since there is absolutely no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT world). - as long as non-DT supported boot provides all features, there is no real feature incentive to move to DT. But, that said, there is one path I see possible: - keep omap-cpufreq alive (BUT I will add a patch that will not let it init when in DT entries are present) - add DT entries for all relevant OMAPs - in DT mode, we will *only* support cpufreq-cpu0 - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the alignment I believe. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-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 8/8] cpufreq: omap: remove omap-cpufreq
On Thu, Mar 14, 2013 at 11:51 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon n...@ti.com wrote: We can now use cpufreq-cpu0 driver using DT entries. remove the redundant omap-cpufreq driver from the tree. Remove MAINTAINERS file entry for the same as well. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Benoīt Cousson b-cous...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Shawn Guo shawn@linaro.org Cc: Keerthy j-keer...@ti.com Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: cpuf...@vger.kernel.org Cc: linux...@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com --- MAINTAINERS|1 - drivers/cpufreq/Kconfig.arm|6 - drivers/cpufreq/Makefile |1 - drivers/cpufreq/omap-cpufreq.c | 291 4 files changed, 299 deletions(-) delete mode 100644 drivers/cpufreq/omap-cpufreq.c Acked-by: Viresh Kumar viresh.ku...@linaro.org Thanks Viresh, but based on the direction of the discussion going on (keeping this driver active for non-DT configuration), I will have to drop this patch in it's entirety. --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: Fix linker errors during build
On Fri, Mar 15, 2013 at 06:58:49PM +0530, Kishon Vijay Abraham I wrote: commit 63378a (usb: phy: remove CONFIG_USB_OTG_UTILS) removed CONFIG_USB_OTG_UTILS from Kconfig but failed to removed from Makefile. Fixed it here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I can fold it in original commit since that's not in mainline yet, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP36xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This overrides the default OMAP34xx CPU OPP table definition. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/2] ASoC: OMAP2+: Update Audio IP with sDMA binding for DT boot
Hi Seb, On 03/11/2013 08:50 AM, Sebastien Guiriec wrote: This patch serie is converting OMAP Audio IPs in order to use OMAP sDMA DT binding in case of DT boot on OMAP2+ platforms. It is depending on the next patches: [1] http://www.spinics.net/lists/arm-kernel/msg227836.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg84668.html I've just applied it in my for_3.10/dts branch on top of Jon's series that does add the SDMA binding. Regards, Benoit It has been tested on: - OMAP5 (sEVM/panda)in DT boot (McPDM/DMIC). - OMAP4 (SDP4430/Panda) in both DT/non DT boot (McPDM/DMIC) - OMAP3 (Beagle XM) in both DT/non DT boot (McBSP) Update since v1: - Put DTS patch in first. - Squash all OMAP IPs patch together. Sebastien Guiriec (2): ARM: dts: OMAP2+: Add SDMA Audio IPs bindings ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding arch/arm/boot/dts/omap2420.dtsi |6 ++ arch/arm/boot/dts/omap2430.dtsi | 15 +++ arch/arm/boot/dts/omap3.dtsi| 15 +++ arch/arm/boot/dts/omap4.dtsi| 17 + arch/arm/boot/dts/omap5.dtsi| 14 ++ sound/soc/omap/mcbsp.c | 26 -- sound/soc/omap/omap-dmic.c | 15 +-- sound/soc/omap/omap-mcpdm.c | 22 ++ sound/soc/omap/omap-pcm.c | 12 ++-- sound/soc/omap/omap-pcm.h |1 + 10 files changed, 117 insertions(+), 26 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-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] usb: musb: gadget: do *unmap_dma_buffer* only for valid DMA addr
On Fri, Mar 15, 2013 at 06:58:50PM +0530, Kishon Vijay Abraham I wrote: musb does not use DMA buffer for ep0 but it uses the same giveback function *musb_g_giveback* for all endpoints (*musb_g_ep0_giveback* calls *musb_g_giveback*). So for ep0 case request.dma will be '0' and will result in kernel OOPS if tried to *unmap_dma_buffer* for requests in ep0. Fixed it by doing *unmap_dma_buffer* only for valid DMA addr. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/musb/musb_gadget.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index c454375..ec3cf29 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -107,7 +107,10 @@ __acquires(ep-musb-lock) ep-busy = 1; spin_unlock(musb-lock); - unmap_dma_buffer(req, musb); + + if (request-dma) I have changed to if (!dma_mapping_error(request-dma)), is it alright ? -- balbi signature.asc Description: Digital signature
Re: [PATCH V2 0/8] ARM: dts: Various OMAP2+ device-tree updates
Hi Jon, On 03/15/2013 02:57 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon Benoit's for_3.10/dts branch [1]. Branch available here [2]. V2 changes: - Rebased on Benoit's for_3.10/dts branch - Squashed patches adding support for OMAP3430 SDP board and patch to add flash support for OMAP3430 SDP board. [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts [2] git://github.com/jonhunter/linux.git omap-dt-for-v3.10 Thanks for the repost. I've just applied your branch in my for_3.10/dts branch. Regards, Benoit Jon Hunter (8): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio ARM: dts: OMAP3: Add support for OMAP3430 SDP board arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 arch/arm/boot/dts/omap2420.dtsi | 55 + arch/arm/boot/dts/omap2430.dtsi | 66 arch/arm/boot/dts/omap3.dtsi | 70 +++-- arch/arm/boot/dts/omap3430-sdp.dts | 141 ++ arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 +-- arch/arm/boot/dts/omap4460.dtsi | 18 + arch/arm/boot/dts/omap5.dtsi | 68 ++-- arch/arm/mach-omap2/pmu.c| 14 +++- 11 files changed, 493 insertions(+), 23 deletions(-) create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 09:26-20130315, Jon Hunter wrote: On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP36xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This overrides the default OMAP34xx CPU OPP table definition. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. most of omap3630 is based off omap3430. I know from an readability point of view, it might have been good to split that to omap3-common.dtsi, omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this point in time to do that. Unless, ofcourse, we'd like to set that up as an standard for all OMAP SoCs... -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 03/15/2013 09:21 AM, Nishanth Menon wrote: On 10:48-20130315, Santosh Shilimkar wrote: On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote: The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in migrating the cpufreq support only through device tree (part of the effort to migrate away from non-DT configurations for OMAP). Unfortunately, as already known, we have a bunch of legacy code and mutually dependent device tree conversion that is pending. Key features pending: A) clock framework transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series B) on processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Thanks for looking into it. Yes, this should be the next stage to solve. Note: Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements there as well. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to DT. As a result of this series, CPUFreq feature will not be available for non-DT boot systems. As commented by Jon on internal thread, I am also against the idea of dropping non-DT support now. Till we migrate to 100 % DT, it is best to keep support alive. Especial OMAP3 based devices. Why don't you take phased approach and have both supported for time being. Then once we move to DT only, we just drop the non-DT support as we plan to do for many more stuff. BTW, we are using only CPUFreq driver before this series as well. I guess you mean the common CPUFReq drivers used by other ARM SOCs. I had removed the entries for OPPs and clock nodes used by omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement CPUFreq wont work in non-DT configuration was accurate. My intent was as follows: - This series is driven mainly from maintenance angle - having to maintain two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c), ensuring the data is proper in both OPP tables in kernel and DT entries is sure to cause mayhem sometime. This is not just an pain for OMAP community, but for cpufreq community as well (since there is absolutely no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT world). - as long as non-DT supported boot provides all features, there is no real feature incentive to move to DT. You are missing the point. Before you can migrate people over to DT, you need to be ready. IMO OMAP is still not quite ready unfortunately. But, that said, there is one path I see possible: - keep omap-cpufreq alive (BUT I will add a patch that will not let it init when in DT entries are present) - add DT entries for all relevant OMAPs - in DT mode, we will *only* support cpufreq-cpu0 - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the alignment I believe. Yes that is what we are doing for other drivers and should be done here. Jon -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 03/15/2013 09:38 AM, Nishanth Menon wrote: On 09:26-20130315, Jon Hunter wrote: On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP36xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This overrides the default OMAP34xx CPU OPP table definition. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. most of omap3630 is based off omap3430. I know from an readability point of view, it might have been good to split that to omap3-common.dtsi, omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this point in time to do that. Unless, ofcourse, we'd like to set that up as an standard for all OMAP SoCs... How would omap3-common.dtsi be any different from omap3.dtsi? I don't wish us to go nuts with creating dtsi files either, but having an omap3430.dtsi does not seem unreasonable to me, but that is just my opinion. Jon -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 09:56-20130315, Jon Hunter wrote: [..] But, that said, there is one path I see possible: - keep omap-cpufreq alive (BUT I will add a patch that will not let it init when in DT entries are present) - add DT entries for all relevant OMAPs - in DT mode, we will *only* support cpufreq-cpu0 - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the alignment I believe. Yes that is what we are doing for other drivers and should be done here. OK. I guess we have not much of a choice with the legacy baggage we carry around :(. Will redo the series for the same. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-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/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 09:58-20130315, Jon Hunter wrote: On 03/15/2013 09:38 AM, Nishanth Menon wrote: On 09:26-20130315, Jon Hunter wrote: On 03/15/2013 08:56 AM, Nishanth Menon wrote: On 16:44-20130314, Jon Hunter wrote: On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP36xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This overrides the default OMAP34xx CPU OPP table definition. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx). The opp tables introduced by this patch in omap36xx.dtsi will override the ones defined on omap3.dtsi. Will the following rephrase help clarify this? Original: This overrides the default OMAP34xx CPU OPP table definition. Suggested; This overrides the default OMAP34xx CPU OPP table definition in omap3.dtsi. Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not omap34xx.dtsi. I guess I am not familiar with how the DTC overrides nodes, however, at least from a readability standpoint it would seem nice to have the omap3430 opps in a omap3430 specific dtsi and not omap3.dtsi. However, thats just my opinion. most of omap3630 is based off omap3430. I know from an readability point of view, it might have been good to split that to omap3-common.dtsi, omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this point in time to do that. Unless, ofcourse, we'd like to set that up as an standard for all OMAP SoCs... How would omap3-common.dtsi be any different from omap3.dtsi? I don't wish us to go nuts with creating dtsi files either, but having an omap3430.dtsi does not seem unreasonable to me, but that is just my opinion. considering omap34xx variants, omap343x.dtsi ;). Will do in v2. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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 v2 22/23] ARM: dts: OMAP3: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..a14f74b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,36 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usbhstll: usbhstll@48062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x48062000 0x1000;
+ interrupts = 78;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@48064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x48064000 0x400;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@48064400 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x48064400 0x400;
+ interrupt-parent = intc;
+ interrupts = 76;
+ };
+
+ usbhsehci: ehci@48064800 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x48064800 0x400;
+ interrupt-parent = intc;
+ interrupts = 77;
+ };
+ };
+
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe 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 v2 23/23] ARM: dts: omap3-beagle: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..02d23f1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -38,6 +38,57 @@
};
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -65,3 +116,23 @@
mmc3 {
status = disabled;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
+
+twl_gpio {
+ ti,use-leds;
+ /* pullups: BIT(1) */
+ ti,pullups = 0x02;
+ /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+ ti,pulldowns = 0x03a1c4;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe 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 v2 15/23] ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 31 +
1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 2bba362..82a4fe3 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -23,6 +23,7 @@
#include linux/spi/spi.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include linux/wl12xx.h
#include linux/mtd/partitions.h
@@ -346,7 +347,7 @@ static struct regulator_consumer_supply
pandora_vcc_lcd_supply[] = {
};
static struct regulator_consumer_supply pandora_usb_phy_supply[] = {
- REGULATOR_SUPPLY(hsusb1, ehci-omap.0),
+ REGULATOR_SUPPLY(vcc, nop_usb_xceiv.2), /* hsusb port 2 */
};
/* ads7846 on SPI and 2 nub controllers on I2C */
@@ -561,23 +562,31 @@ fail:
printk(KERN_ERR wl1251 board initialisation failed\n);
}
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 16,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct platform_device *omap3pandora_devices[] __initdata = {
pandora_leds_gpio,
pandora_keys_gpio,
pandora_vwlan_device,
pandora_backlight,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 16,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -601,7 +610,11 @@ static void __init omap3pandora_init(void)
spi_register_board_info(omap3pandora_spi_board_info,
ARRAY_SIZE(omap3pandora_spi_board_info));
omap_ads7846_init(1, OMAP3_PANDORA_TS_GPIO, 0, NULL);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
+
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
gpmc_nand_init(pandora_nand_data, NULL);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe 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 v2 17/23] ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3touchbook.c | 38 ++-
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index bcd44fb..e8fa884 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -36,6 +36,7 @@
#include linux/spi/ads7846.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include asm/mach-types.h
@@ -305,21 +306,37 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 147,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct platform_device *omap3_touchbook_devices[] __initdata = {
leds_gpio,
keys_gpio,
+ hsusb1_phy_device,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
static void omap3_touchbook_poweroff(void)
@@ -368,6 +385,13 @@ static void __init omap3_touchbook_init(void)
omap_ads7846_init(4, OMAP3_TS_GPIO, 310, ads7846_pdata);
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
board_nand_init(omap3touchbook_nand_partitions,
ARRAY_SIZE(omap3touchbook_nand_partitions), NAND_CS,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe 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 v2 16/23] ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3stalker.c | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 95c10b3..bf6a108 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -26,6 +26,7 @@
#include linux/regulator/fixed.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/i2c/twl.h
#include linux/mmc/host.h
#include linux/input/matrix_keypad.h
@@ -358,19 +359,28 @@ static int __init omap3_stalker_i2c_init(void)
#define OMAP3_STALKER_TS_GPIO 175
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 2,
+ .reset_gpio = 21,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
+
static struct platform_device *omap3_stalker_devices[] __initdata = {
keys_gpio,
+ hsusb2_phy_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 21,
- .reset_gpio_port[2] = -EINVAL,
};
#ifdef CONFIG_OMAP_MUX
@@ -407,6 +417,11 @@ static void __init omap3_stalker_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
+
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
omap_ads7846_init(1, OMAP3_STALKER_TS_GPIO, 310, NULL);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe 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 v2 20/23] ARM: dts: OMAP4: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..b7db1a2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = 0 78 0x4;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 76 0x4;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x4a064c00 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 77 0x4;
+ };
+ };
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe 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 v2 21/23] ARM: dts: omap4-panda: Add USB Host support
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 56 +
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..cfc7683 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,36 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ clock-frequency = 1920;
+ };
};
omap4_pmx_core {
@@ -67,6 +97,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +141,23 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
;
};
+
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 0x10C /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+ 0x84 0x4/*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x86 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x88 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x8a 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x8c 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x8e 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x90 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x92 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x94 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x96 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x98 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -206,3 +254,11 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
