Re: [PATCH 5/5 v7] mfd: omap: usb: Runtime PM support
Hi Keshav,
Some minor comments
On Wednesday 24 August 2011 08:01 PM, Keshava Munegowda wrote:
From: Keshava Munegowdakeshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the usbhs core.
Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
---
arch/arm/plat-omap/include/plat/usb.h |3 -
drivers/mfd/omap-usb-host.c | 731 +
drivers/usb/host/ehci-omap.c | 17 +-
drivers/usb/host/ohci-omap3.c | 18 +-
4 files changed, 295 insertions(+), 474 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..e6f3b01 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#includelinux/spinlock.h
#includelinux/gpio.h
#includeplat/usb.h
+#includelinux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,6 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +164,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +313,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev =pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev,
Re: [PATCH 5/5 v7] mfd: omap: usb: Runtime PM support
On Thu, Aug 25, 2011 at 12:03 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
Hi Keshav,
Some minor comments
On Wednesday 24 August 2011 08:01 PM, Keshava Munegowda wrote:
From: Keshava Munegowdakeshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the usbhs core.
Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
---
arch/arm/plat-omap/include/plat/usb.h | 3 -
drivers/mfd/omap-usb-host.c | 731
+
drivers/usb/host/ehci-omap.c | 17 +-
drivers/usb/host/ohci-omap3.c | 18 +-
4 files changed, 295 insertions(+), 474 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..e6f3b01 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#includelinux/spinlock.h
#includelinux/gpio.h
#includeplat/usb.h
+#includelinux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,6 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
void __iomem *uhh_base;
void __iomem *tll_base;
@@ -168,7 +164,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +313,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev =pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
-
Re: [PATCH 1/5 v5] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Wed, Aug 24, 2011 at 4:30 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Wed, Aug 24, 2011 at 12:27 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 08/17/2011 02:43 PM, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244
1 files changed, 244 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..d8f08fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,242 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod =
{
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk = l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
what about SYSC_HAS_SOFTRESET?
Yes, I will add this for omap3 , for omap4 this flag is causing
enumeration issue.
for now , I will not add this for 4430.
Roger,
I can not add this SYSC_HAS_SOFTRESET for omap3 too;
its blocks the port status change interrupts after the global suspend/resume;
so v7 I add this for omap3, I will remove this and send it as v8 now.
regards
keshava
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
Did you intentionally miss out SIDLE_SMART_WKUP ?
it is not there for omap3 but I will add this for omap4.
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
+ .sysc_fields = omap_hwmod_sysc_type2,
+};
+
...
snip
...
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_usb_tll_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE),
what about SYSC_HAS_SOFTRESET, SYSC_HAS_ENAWAKEUP and
SYSC_HAS_CLOCKACTIVITY?
yes, I will add these flags ;
I will send the v7 soon.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: fix pm_runtime calls while atomic
Felipe On Fri, Aug 12, 2011 at 10:21 AM, Pandita, Vikram vikram.pand...@ti.com wrote: On Fri, Aug 12, 2011 at 10:04 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Pandita, Vikram wrote: On Fri, Aug 12, 2011 at 8:50 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com musb pm_runtime_get_sync call happens in intrrupt context on cable attach case That can result in re-enabling the interrupts and cause side affects. So move the code to a work queue. Any chance you go to line this up for the merge window? Instead of creating your own, new work queue, just use the pre-existing PM work queue. In other words, replace pm_runtime_get_sync() with pm_runtime_get(). In this case it may not work, because immediately after a pm_runtime_get_sync(), we are going to access MUSB registers and xxx_sync() call ensures we will not abort. I don't understand. Why not just access those registers from within the runtime_resume callback? I am not the runtime_pm expert, but as i understand, in this case: USB cable attach Get Interrupt from Power IC (twl6030) Interrupt handler calls notifier_call_chain - cable attach/detach notification handler in MUSB code Notification_handler does: * enable clocks for musb register access ** setup musb registers to start getting control ep0 interrupts for usb enumeration * is the part were we need to do the clock enabling synchronously. The runtime_resume() call-back today for musb does not have to do anything with USB enumeration. Alan Stern -- To unsubscribe from this list: send the line unsubscribe 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 1/5 v8] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247
1 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..0bc01dd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,245 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE |
+ MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters= omap44xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_class omap44xx_usbhs_ohci_hwmod_class = {
+ .name = usbhs_ohci,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usbhs_ohci_irqs[] = {
+ { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 } /* Terminating IRQ */
+};
+
+static struct omap_hwmod_addr_space omap44xx_usbhs_ohci_addrs[] = {
+ {
+ .name = ohci,
+ .pa_start = 0x4A064800,
+ .pa_end = 0x4A064BFF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usbhs_ohci = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usbhs_ohci_hwmod,
+ .clk= l4_div_ck,
+
[PATCH 2/5 v8] arm: omap: usb: ehci and ohci hwmod structures for omap3
Following 4 hwmod structure are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 281
1 files changed, 281 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..8a5600f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,278 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_ocp_if omap34xx_usbhs_ohci__l3_main_2 = {
+ .master = omap34xx_usbhs_ohci_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class omap34xx_usbhs_ohci_hwmod_class = {
+ .name = usbhs_ohci,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usbhs_ohci_masters[] = {
+
[PATCH 0/5 v8] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. these patches are rebased to kevin's pm branch and usbhs latest mainline kernel patches TODO: - Adding pad configurations to Hwmods - Aggressive clock cutting in usb bus suspends - Remote Wakeup implementation using irq-chaining Benoit Cousson (1): arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs mfd: omap: usb: Runtime PM support arch/arm/mach-omap2/clock3xxx_data.c | 26 +- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 281 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247 ++ arch/arm/mach-omap2/usb-host.c | 114 ++--- arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c| 733 +++- drivers/usb/host/ehci-omap.c | 17 +- drivers/usb/host/ohci-omap3.c | 18 +- 9 files changed, 891 insertions(+), 558 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
[PATCH 5/5 v8] mfd: omap: usb: Runtime PM support
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the usbhs core.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/plat-omap/include/plat/usb.h |3 -
drivers/mfd/omap-usb-host.c | 731 +
drivers/usb/host/ehci-omap.c | 17 +-
drivers/usb/host/ohci-omap3.c | 18 +-
4 files changed, 295 insertions(+), 474 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c2da29..e6f3b01 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#include linux/spinlock.h
#include linux/gpio.h
#include plat/usb.h
+#include linux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,6 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +164,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +313,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev, usbtll_fck failed error:%d\n, ret);
- goto err_usbhost_fs_fck;
- }
-
-
[PATCH 3/5 v8] arm: omap: usb: register hwmods of usbhs
The hwmod structure of uhh, ohci, ehci and tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 114 +--
1 files changed, 50 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..9c37db9 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,30 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICE usbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICE usbhs_omap
+#defineUSBHS_UHH_HWMODNAME usbhs_uhh
+#defineUSBHS_OHCI_HWMODNAMEusbhs_ohci
+#define USBHS_EHCI_HWMODNAME usbhs_ehci
+#define USBHS_TLL_HWMODNAMEusbhs_tll
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +487,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[4];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +505,48 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto init_end;
+ oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!oh[0]) {
+ pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
+
[PATCH 4/5 v8] arm: omap: usb: device name change for the clk names of usbhs
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 26 --
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
drivers/mfd/omap-usb-host.c |2 +-
3 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index ffd55b1..63a822f 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,7 +3285,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3321,7 +3321,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3367,20 +3367,18 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..088977a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3281,7 +3281,7 @@ static
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Wed, Aug 24, 2011 at 08:07:12PM +0530, Keerthy wrote:
...
+ temp_sensor-phy_base = ioremap(mem-start, resource_size(mem));
Check NULL return.
temp_sensor-phy_base is never iounmapped in error paths or _remove
function.
...
+static int __devexit omap_temp_sensor_remove(struct platform_device *pdev)
+{
+ struct omap_temp_sensor *temp_sensor = platform_get_drvdata(pdev);
+
+ hwmon_device_unregister(pdev-dev);
+ kobject_uevent(temp_sensor-hwmon_dev-kobj, KOBJ_REMOVE);
+ sysfs_remove_group(temp_sensor-hwmon_dev-kobj,
+ omap_temp_sensor_group);
+ omap_temp_sensor_clk_disable(temp_sensor);
+ free_irq(temp_sensor-irq, temp_sensor);
free_irq before omap_temp_sensor_clk_disable, to avoid ISR attempting
to access hardware while unclocked.
+ clk_put(temp_sensor-clock);
+ dev_set_drvdata(pdev-dev, NULL);
+ mutex_destroy(temp_sensor-sensor_mutex);
+ kfree(temp_sensor);
+
+ return 0;
+}
Todd
--
To unsubscribe from this list: send the line unsubscribe 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 RFC] OMAP2PLUS: Enable HIGHMEM
Tony, On Thursday 02 June 2011 05:36 PM, Santosh Shilimkar wrote: HIGMEM support is kernel is quite mature now and we have boards like ZOOM, PANDA, SDP where 1 GB memories are installed. Enable HIGMEM to make use of the additional memory. Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com --- This won't boards which doesn't have excess memory. Tested on OMAP4430 SDP arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Any comments. I almost forgot about the post. Thanks to imx patch on LAKML, i looked at it again. If you are ok, I can repost it with LAKML in CC. 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 v4] OMAP3EVM: ehci: Fix EHCI support
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Tps65950 GPIO2 has to be set to zero in order to enable the EHCI select line.
Signed-off-by: Bryan DE FARIA bdefa...@adeneo-embedded.com
---
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index c452b3f..d9e0f10 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -377,6 +377,10 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
if (r)
printk(KERN_ERR failed to get/set lcd_bkl gpio\n);
+ /* gpio + 2 == EHCI, camera and audio lines on motherboard Enable*/
+ if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
+ gpio_request_one(gpio + 2, GPIOF_OUT_INIT_LOW, EN_MB_LINES);
+
/* gpio + 7 == DVI Enable */
gpio_request_one(gpio + 7, GPIOF_OUT_INIT_LOW, EN_DVI);
@@ -450,6 +454,25 @@ static struct regulator_init_data omap3evm_vio = {
.consumer_supplies = omap3evm_vio_supply,
};
+/* VAUX2 for EHCI */
+static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(hsusb1, ehci-omap.0),
+};
+
+static struct regulator_init_data omap3evm_vaux2 = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3evm_vaux2_supplies),
+ .consumer_supplies = omap3evm_vaux2_supplies,
+};
+
#ifdef CONFIG_WL12XX_PLATFORM_DATA
#define OMAP3EVM_WLAN_PMENA_GPIO (150)
@@ -510,6 +533,8 @@ static int __init omap3_evm_i2c_init(void)
omap3evm_twldata.vdac-constraints.apply_uV = true;
omap3evm_twldata.vpll2-constraints.apply_uV = true;
+ if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
+ omap3evm_twldata.vaux2 = omap3evm_vaux2;
omap3_pmic_init(twl4030, omap3evm_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
--
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
Re: Question on virtual memory layout: lowmem with memory hole
On Thu, Aug 25, 2011 at 09:35:07AM +0530, Pedanekar, Hemant wrote: E.g., on OMAP3 with mem=32M@0x8000 mem=8M@0x8780 (CASE 1) Memory: 32MB 8MB = 40MB total Memory: 28408k/28408k available, 12552k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc05ac2c8 (5777 kB) .init : 0xc05ad000 - 0xc05f8780 ( 302 kB) .data : 0xc05fa000 - 0xc06838d0 ( 551 kB) .bss : 0xc06838f4 - 0xc0bd8a14 (5461 kB) Is this expected? 88MB space between two 'mem's seems to have lost. Yes. The memory layout lines gives an overview of the virtual memory address space _regions_. What it's saying is that the virtual addresses from 0xc000 - 0xc800 are used for lowmem. That may not be fully populated, but that's what the address range is reserved for. This also means vmalloc space is lower compared to when a single mem=40M is passed. Huh. Either your maths is wrong or... Here's case 1: vmalloc : 0xc880 - 0xf800 ( 760 MB) And case 2: vmalloc : 0xc300 - 0xf800 ( 848 MB) Looks to me like case 1, vmalloc space is _higher_ not _lower_. That's expected because you told the kernel it had more memory in case 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
Re: How to handle named resources with DT?
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote: on top of all that, for IPs which are used on many SoCs (such as MUSB) it's quite silly to force all users to provide resources in a certain order. It sounds to me that this will be prone to error in many ways until everything is synced up and on the correct order. Ditching _byname is a very bad idea. I continue to disagree. The current _byname is an abonimation and hack to try to fix this problem. _byname should have been implemented differently - rather than overriding the resources name field (which is _normally_ specified to be the device or driver name), a new field should have been introduced in struct resource to carry the resource sub-name (which is really what it is.) That would have avoided making /proc/iomem completely illegible with multiple devices using this feature. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck guenter.ro...@ericsson.com wrote: On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote: On chip temperature sensor driver. The driver monitors the temperature of the MPU subsystem of the OMAP4. It sends notifications to the user space if the temperature crosses user defined thresholds via kobject_uevent interface. The user is allowed to configure the temperature thresholds vis sysfs nodes exposed using hwmon interface. Signed-off-by: Keerthy j-keer...@ti.com Cc: Jean Delvare kh...@linux-fr.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: lm-sens...@lm-sensors.org Partial review only. Too many concerns, and after a while I tend to loose track. --- Documentation/hwmon/omap_temp_sensor | 27 + drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile | 1 + drivers/hwmon/omap_temp_sensor.c | 933 ++ 4 files changed, 972 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwmon/omap_temp_sensor create mode 100644 drivers/hwmon/omap_temp_sensor.c diff --git a/Documentation/hwmon/omap_temp_sensor b/Documentation/hwmon/omap_temp_sensor new file mode 100644 index 000..e01a6d6 --- /dev/null +++ b/Documentation/hwmon/omap_temp_sensor @@ -0,0 +1,27 @@ +Kernel driver omap_temp_sensor +== + +Supported chips: + * Texas Instruments OMAP4460 + Prefix: 'omap_temp_sensor' + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp102.html + I am a bit lost here. What does the TMP102 have to do with the OMAP4460 ? My mistake. I will point to the correct data sheet. +Author: + J Keerthy j-keer...@ti.com + +Description +--- + +The Texas Instruments OMAP4 family of chips have a bandgap temperature sensor. +The temperature sensor feature is used to convert the temperature of the device +into a decimal value coded on 10 bits. An internal ADC is used for conversion. +The recommended operating temperatures must be in the range -40 degree Celsius +to 123 degree celsius for standard conversion. +The thresholds are programmable and upon crossing the thresholds an interrupt +is generated. The OMAP temperature sensor has a programmable update rate in +milli seconds. +(Currently the driver programs a default of 2000 milli seconds). + s/milli seconds/milliseconds/ Ok +The driver provides the common sysfs-interface for temperatures (see +Documentation/hwmon/sysfs-interface under Temperatures). + diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 5f888f7..9c9cd8b 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -323,6 +323,17 @@ config SENSORS_F71805F This driver can also be built as a module. If so, the module will be called f71805f. +config SENSORS_OMAP_BANDGAP_TEMP_SENSOR + bool OMAP on-die temperature sensor hwmon driver + depends on HWMON ARCH_OMAP OMAP_TEMP_SENSOR + help + If you say yes here you get support for hardware + monitoring features of the OMAP on die temperature + sensor. + + Continuous conversion programmable delay + mode is used for temperature conversion. + config SENSORS_F71882FG tristate Fintek F71882FG and compatibles help diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 28061cf..d0f89f5 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -91,6 +91,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o obj-$(CONFIG_SENSORS_MAX6642) += max6642.o obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o +obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap_temp_sensor.o obj-$(CONFIG_SENSORS_PC87360) += pc87360.o obj-$(CONFIG_SENSORS_PC87427) += pc87427.o obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o diff --git a/drivers/hwmon/omap_temp_sensor.c b/drivers/hwmon/omap_temp_sensor.c new file mode 100644 index 000..66fb3a9 --- /dev/null +++ b/drivers/hwmon/omap_temp_sensor.c @@ -0,0 +1,933 @@ +/* + * OMAP4 Temperature sensor driver file + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * Author: Moiz Sonasath m-sonas...@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. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc.,
Re: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote: Perhaps. Still, that requires some policy to be put into drivers, which I don't think is entirely correct. So, I don't really have the bandwidth to discuss this properly for at least the next week or so - is it possible to find some time in the power track at LPC for this? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.1-rc3 fails to boot on my pandaboard
Hi, There seems to be a problem with 3.1-rc3, which prevents it from booting on my PandaBoard (ARM OMAP4). 3.1-rc2 works fine, so I have bisected the problem and it turns out to be caused by this: commit f3637a5f2e2eb391ff5757bc83fb5de8f9726464 Author: Sebastian Andrzej Siewior bige...@linutronix.de Date: Thu Jul 7 22:32:17 2011 +0200 irq: Always set IRQF_ONESHOT if no primary handler is specified After reverting this commit, -rc3 boots fine. I'm not sure where exactly the problem is. Maybe it's something in the omap code which is broken and this patch causes the bug to show up? What happens is that the booting process hangs after printing out this: [...] [7.408477] EXT3-fs: barriers not enabled [7.415008] kjournald starting. Commit interval 5 seconds [7.446228] EXT3-fs (mmcblk0p5): using internal journal [7.452087] EXT3-fs (mmcblk0p5): mounted filesystem with ordered data mode [7.459625] VFS: Mounted root (ext3 filesystem) on device 179:5. [7.466094] Freeing init memory: 312K [7.471710] Failed to execute /init. Attempting defaults... [ 10.254333] EXT3-fs (mmcblk0p5): using internal journal The full boot logs can be found here: http://pastebin.pandaboard.org/index.php/view/88995306 Any ideas what may be going wrong? -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe 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: 3.1-rc3 fails to boot on my pandaboard
* Luciano Coelho | 2011-08-25 13:39:29 [+0300]:
Hi,
Hi,
Any ideas what may be going wrong?
I think my commit was identified as bogus and tglx is going to revert
it. The problem is that I force ONESHOT mode for all threaded IRQs but
there are also others without the flag which is not allowed.
I was trying to check something but I don't get my board to boot. Could
you please try to boot with the patch reverted and paste me the
the output of
cat /proc/interrupts | grep 74 ?
I *think* that the flow handler is level (I can't find evidence of it
beeing edge, and omap_alloc_gc() is the place installing it).
So could you please gather additional debug info with this patch?
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 2e94258..eda25a0 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1327,6 +1327,9 @@ int request_threaded_irq(unsigned int irq, irq_handler_t
handler,
if (!irq_settings_can_request(desc))
return -EINVAL;
+ if (irq == 74)
+ printk(KERN_ERR %s() h %pS th %pS f %lx dev %s flow %pS\n,
__func__,
+ handler, thread_fn, irqflags, devname,
desc-handle_irq);
if (!handler) {
if (!thread_fn)
return -EINVAL;
%pS should resolve the function names.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe 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/5 v5] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Wed, Aug 17, 2011 at 5:13 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279
1 files changed, 279 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d7316b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,276 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk = core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
why do we need this terminating entry?
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk = l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk = usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters = omap34xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_ocp_if omap34xx_usbhs_ohci__l3_main_2 = {
+ .master = omap34xx_usbhs_ohci_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk =
Re: 3.1-rc3 fails to boot on my pandaboard
On Thu, 2011-08-25 at 13:04 +0200, Sebastian Andrzej Siewior wrote:
* Luciano Coelho | 2011-08-25 13:39:29 [+0300]:
Any ideas what may be going wrong?
I think my commit was identified as bogus and tglx is going to revert
it. The problem is that I force ONESHOT mode for all threaded IRQs but
there are also others without the flag which is not allowed.
I was trying to check something but I don't get my board to boot. Could
you please try to boot with the patch reverted and paste me the
the output of
cat /proc/interrupts | grep 74 ?
Hmmm... There doesn't seem to be an irq 74. The only thing I get is
this:
root@xiru:~# cat /proc/interrupts | grep 74
IPI1: 2667 3743 Rescheduling interrupts
Which is probably not what you wanted. ;)
I *think* that the flow handler is level (I can't find evidence of it
beeing edge, and omap_alloc_gc() is the place installing it).
So could you please gather additional debug info with this patch?
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 2e94258..eda25a0 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1327,6 +1327,9 @@ int request_threaded_irq(unsigned int irq,
irq_handler_t handler,
if (!irq_settings_can_request(desc))
return -EINVAL;
+ if (irq == 74)
+ printk(KERN_ERR %s() h %pS th %pS f %lx dev %s flow %pS\n,
__func__,
+ handler, thread_fn, irqflags, devname,
desc-handle_irq);
if (!handler) {
if (!thread_fn)
return -EINVAL;
%pS should resolve the function names.
As I mentioned above, there doesn't seem to be irq 74, so this code
doesn't hit.
These are the interrupts reported in /proc/interrupts on my board:
root@xiru:~# cat /proc/interrupts
CPU0 CPU1
39: 0 0 GIC TWL6030-PIH
41: 0 0 GIC l3-dbg-irq
42: 0 0 GIC l3-app-irq
44: 5397 0 GIC DMA
52: 0 0 GIC gpmc
69: 16 0 GIC gp timer
88:270 0 GIC omap_i2c
89: 0 0 GIC omap_i2c
91:183 0 GIC mmc1
93: 0 0 GIC omap_i2c
94: 0 0 GIC omap_i2c
102: 0 0 GIC serial idle
104: 0 0 GIC serial idle
105: 0 0 GIC serial idle
106:290 0 GIC serial idle, OMAP UART2
108: 1 0 GIC ohci_hcd:usb3
109:493 0 GIC ehci_hcd:usb1
115: 6260 0 GIC mmc0
124: 1 0 GIC musb-hdrc
125: 0 0 GIC musb-hdrc
213: 0 0 GPIO wl1271
372: 0 0 twl6030 twl6030_usb
378: 0 0 twl6030 twl6030_usb
379: 0 0 twl6030 rtc0
IPI0: 0 0 Timer broadcast interrupts
IPI1: 2995 3606 Rescheduling interrupts
IPI2: 0 0 Function call interrupts
IPI3: 57 61 Single function call interrupts
IPI4: 0 0 CPU stop interrupts
LOC: 8879 5844 Local timer interrupts
Err: 0
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line unsubscribe 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: 3.1-rc3 fails to boot on my pandaboard
On Thu, Aug 25, 2011 at 4:09 PM, Luciano Coelho coe...@ti.com wrote: Hi, There seems to be a problem with 3.1-rc3, which prevents it from booting on my PandaBoard (ARM OMAP4). 3.1-rc2 works fine, so I have bisected the problem and it turns out to be caused by this: commit f3637a5f2e2eb391ff5757bc83fb5de8f9726464 Author: Sebastian Andrzej Siewior bige...@linutronix.de Date: Thu Jul 7 22:32:17 2011 +0200 irq: Always set IRQF_ONESHOT if no primary handler is specified After reverting this commit, -rc3 boots fine. I'm not sure where exactly the problem is. Maybe it's something in the omap code which is broken and this patch causes the bug to show up? What happens is that the booting process hangs after printing out this: fyi, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69dd3d8e29e294caaf63eb5e8a72d250279f9e5f;hp=fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c -- Thanks, Govindraj.R [...] [ 7.408477] EXT3-fs: barriers not enabled [ 7.415008] kjournald starting. Commit interval 5 seconds [ 7.446228] EXT3-fs (mmcblk0p5): using internal journal [ 7.452087] EXT3-fs (mmcblk0p5): mounted filesystem with ordered data mode [ 7.459625] VFS: Mounted root (ext3 filesystem) on device 179:5. [ 7.466094] Freeing init memory: 312K [ 7.471710] Failed to execute /init. Attempting defaults... [ 10.254333] EXT3-fs (mmcblk0p5): using internal journal The full boot logs can be found here: http://pastebin.pandaboard.org/index.php/view/88995306 Any ideas what may be going wrong? -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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/5 v5] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Thu, Aug 25, 2011 at 4:47 PM, ABRAHAM, KISHON VIJAY kis...@ti.com wrote:
On Wed, Aug 17, 2011 at 5:13 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279
1 files changed, 279 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d7316b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,276 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk = core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
why do we need this terminating entry?
This is how the hwmod implemented now,
while filling resources it checks for pa_start and pa_end set to equal.
this was one the latest changes by benoit.
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk = l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk = usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters = omap34xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
Re: 3.1-rc3 fails to boot on my pandaboard
On Thu, 2011-08-25 at 17:05 +0530, Govindraj wrote: On Thu, Aug 25, 2011 at 4:09 PM, Luciano Coelho coe...@ti.com wrote: Hi, There seems to be a problem with 3.1-rc3, which prevents it from booting on my PandaBoard (ARM OMAP4). 3.1-rc2 works fine, so I have bisected the problem and it turns out to be caused by this: commit f3637a5f2e2eb391ff5757bc83fb5de8f9726464 Author: Sebastian Andrzej Siewior bige...@linutronix.de Date: Thu Jul 7 22:32:17 2011 +0200 irq: Always set IRQF_ONESHOT if no primary handler is specified After reverting this commit, -rc3 boots fine. I'm not sure where exactly the problem is. Maybe it's something in the omap code which is broken and this patch causes the bug to show up? What happens is that the booting process hangs after printing out this: fyi, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69dd3d8e29e294caaf63eb5e8a72d250279f9e5f;hp=fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c Ah, thanks. Now I see where the irq == 74 comes from. :) Still, I don't see that on my system. -- Cheers, Luca. -- To unsubscribe from this list: send the line unsubscribe 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: 3.1-rc3 fails to boot on my pandaboard
* Luciano Coelho | 2011-08-25 14:24:34 [+0300]: These are the interrupts reported in /proc/interrupts on my board: Thank you, this is enough information. Sebastian -- To unsubscribe from this list: send the line unsubscribe 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: 3.1-rc3 fails to boot on my pandaboard
On Thu, Aug 25, 2011 at 5:09 PM, Luciano Coelho coe...@ti.com wrote: On Thu, 2011-08-25 at 17:05 +0530, Govindraj wrote: On Thu, Aug 25, 2011 at 4:09 PM, Luciano Coelho coe...@ti.com wrote: Hi, There seems to be a problem with 3.1-rc3, which prevents it from booting on my PandaBoard (ARM OMAP4). 3.1-rc2 works fine, so I have bisected the problem and it turns out to be caused by this: commit f3637a5f2e2eb391ff5757bc83fb5de8f9726464 Author: Sebastian Andrzej Siewior bige...@linutronix.de Date: Thu Jul 7 22:32:17 2011 +0200 irq: Always set IRQF_ONESHOT if no primary handler is specified After reverting this commit, -rc3 boots fine. I'm not sure where exactly the problem is. Maybe it's something in the omap code which is broken and this patch causes the bug to show up? What happens is that the booting process hangs after printing out this: fyi, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69dd3d8e29e294caaf63eb5e8a72d250279f9e5f;hp=fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c Ah, thanks. Now I see where the irq == 74 comes from. :) Still, I don't see that on my system. 69dd3d8 Revert irq: Always set IRQF_ONESHOT if no primary handler is specified f2b6071 drm/radeon: Extended DDC Probing for Toshiba L300D Radeon Mobility X1100 HDMI-A Connector c87019e HID: wiimote: Add status and return request handlers 2cb5e4b HID: wiimote: Add drm request 23a5a4a HID: wiimote: Register led class devices 26af174 HID: wiimote: Correctly call HID open/close callbacks 3989ef6 HID: wiimote: Simplify synchronization 8d3bb23 drm/ttm: ensure ttm for new node is bound before calling move_notify() eac2095 drm/ttm: unbind ttm before destroying node in accel move cleanup 7c4c396 drm/ttm: fix ttm_bo_add_ttm(user) failure path f5e4282 HID: usbhid: Add support for SiGma Micro chip 11f3a6b bridge: fix a possible net_device leak b6bede3 xfs: fix tracing builds inside the source tree 832d80a Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless fcb8ce5 Linux 3.1-rc3 -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe 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/2] OMAP: Update nr_irqs field in machine descriptors
Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? 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 v4] OMAP4: hwmod data: I2C: add flag for context restore
On Wednesday 24 August 2011 08:14 PM, Kevin Hilman wrote:
Shubhrajyotishubhrajy...@ti.com writes:
On Sunday 17 July 2011 06:13 PM, Shubhrajyoti D wrote:
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.
Could this patch be queued as well?
Paul is the maintainer for the hwmod data. It is usually helpful to
ensure the maintainer is specifically added to the To line.
yes thanks will take care henceforth . For now adding him for comments.
Kevin
Reviewed-by: Kevin Hilmankhil...@ti.com
Signed-off-by: Shubhrajyoti Dshubhrajy...@ti.com
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+ OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
};
/* i2c1 */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/7] arm/dts: Add initial device tree support for OMAP4 SoC
Benoit,
On 08/24/2011 05:17 AM, Benoit Cousson wrote:
Add initial device-tree support for OMAP4 SoC.
This is based on the original panda board patch done by Manju:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60393
Add the generic GIC interrupt-controller from ARM.
Add an empty soc node to contain non memory mapped IPs
(DSP, MPU, IPU...).
Note: Since reg, irq and dma are provided by hwmod for the
moment, these attributes will not be present at all in DTS
to highlight the gap. They will be added as soon as dma bindings
will be there and drivers will be adapted.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 80
++
1 files changed, 80 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4.dtsi
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
new file mode 100644
index 000..97a3ea7
--- /dev/null
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) 2011 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.
+ */
+
+/*
+ * Carveout for multimedia usecases
+ * It should be the last 48MB of the first 512MB memory part
+ * In theory, it should not even exist. That zone should be reserved
+ * dynamically during the .reserve callback.
+ */
+/memreserve/ 0x9d00 0x0300;
+
+/include/ skeleton.dtsi
+
+/ {
+ model = TI OMAP4430;
+ compatible = ti,omap4430, ti,omap4;
+ interrupt-parent = gic;
+
+ aliases {
+ };
+
+ /*
+ * 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.
+ */
+ soc {
+ compatible = ti,omap-infra;
+ };
+
+ /*
+ * XXX: Use a flat representation of the OMAP4 interconnect.
+ * The real OMAP interconnect network is quite complex.
+ *
+ * MPU -+-- MPU_PRIVATE - GIC, L2
+ * |
+ * ++--+
+ * || |
+ * ++- EMIF - DDR |
+ * || |
+ * |+ ++
+ * || |
+ * |+- L4_ABE - AESS, MCBSP, TIMERs...
+ * ||
+ * +- L3_MAIN --+- L4_CORE - IPs...
+ * |
+ * +- L4_PER - IPs...
+ * |
+ * +- L4_CFG -+- L4_WKUP - IPs...
+ * | |
+ * | +- IPs...
+ * +- IPU +
+ * | |
+ * +- DSP +
+ * | |
+ * +- DSS +
+ *
+ * Since that will not bring real advantage to represent that in DT for
+ * the moment, just use a fake OCP bus entry to represent the whole bus
+ * hierarchy.
+ */
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ gic: interrupt-controller@48241000 {
+ compatible = ti,omap4-gic, arm,gic;
The gic binding is still being hashed out. This needs binding
documentation and handling of PPIs. I'm planning on posting an updated
series today with this.
arm,gic should be dropped or replaced with arm,cortex-a9-gic.
Non-specific DT bindings are not well received. Is OMAP4 gic different
from standard Cortex-A9?
+ interrupt-controller;
+ #interrupt-cells = 1;
+ reg = 0x48241000 0x1000,
+ 0x48240100 0x0200;
Isn't the cpu interface register space 0x100 bytes long?
Rob
+ };
+ };
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/7] arm/dts: Add initial device tree support for OMAP4 SoC
Hi Rob,
On 8/25/2011 3:37 PM, Rob Herring wrote:
Benoit,
[...]
+ gic: interrupt-controller@48241000 {
+ compatible = ti,omap4-gic, arm,gic;
The gic binding is still being hashed out. This needs binding
documentation and handling of PPIs. I'm planning on posting an updated
series today with this.
arm,gic should be dropped or replaced with arm,cortex-a9-gic.
Non-specific DT bindings are not well received. Is OMAP4 gic different
from standard Cortex-A9?
Not at all. We named it like that based on Grant's comment:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60393
I'll update it with the new binding.
+ interrupt-controller;
+ #interrupt-cells =1;
+ reg =0x48241000 0x1000,
+ 0x48240100 0x0200;
Isn't the cpu interface register space 0x100 bytes long?
I've just checked the spec, and this is indeed 256 bytes. I'll fix that.
Thanks for the comments.
Regards,
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 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis sysfs nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
Partial review only. Too many concerns, and after a while I tend to loose
track.
---
Documentation/hwmon/omap_temp_sensor | 27 +
drivers/hwmon/Kconfig| 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/omap_temp_sensor.c | 933
++
4 files changed, 972 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hwmon/omap_temp_sensor
create mode 100644 drivers/hwmon/omap_temp_sensor.c
[ ... ]
+/* Sysfs hook functions */
+
+static ssize_t show_temp_max(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ int temp;
+
+ temp = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ temp = (temp temp_sensor-registers-threshold_thot_mask)
+
__ffs(temp_sensor-registers-threshold_thot_mask);
+
+ if (temp OMAP_ADC_START_VALUE || temp OMAP_ADC_END_VALUE) {
+ dev_err(dev, invalid value\n);
+ return -EDOM;
Please don't use EDOM, and drop the error message.
The temperature is out of range. Should i use EIO?
It is out of range, but not due to a math error, but due to a bad reading from
the chip
or due to a chip failure. EIO is ok.
+ }
+
+ temp = adc_to_temp_conversion(temp);
+
+ return snprintf(buf, 16, %d\n, temp);
+}
+
+static ssize_t set_temp_max(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ longval;
+ u32 reg_val, t_cold, t_hot, temp;
+
+ if (strict_strtol(buf, 10, val)) {
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ t_hot = temp_to_adc_conversion(val);
Bad error return check. Negative on error. Should be
if (t_hot 0)
return t_hot;
Ok.
+ if ((t_hot OMAP_ADC_START_VALUE || t_hot OMAP_ADC_END_VALUE)) {
Unnecessary (( ))
This check is unnecessary with the negative check. I will remove.
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since it
assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the application
making the change, nor is a
change order order well defined or even possible. Applications should not
have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot interrupt
in the interrupt handler and enable the t_cold interrupts. So we get a t_cold
interrupt only when the temperature drops below the t_cold value. Hence
setting the t_cold higher than t_hot will mess up the state machine.
t_hot value should be greater than t_cold value.
One option would be to update t_cold (max_hyst) automatically in that case.
Problem here is that you expect the aplication to know, depending on the
current
values of (max, max_hyst), how to update both limits in order. That is not a
reasonable
expectation.
+ }
+
+ /* write the new t_hot value */
+ reg_val =
Re: [PATCH 1/1] OMAP: omap_device: only override _noirq methods, not normal suspend/resume
On Thursday, August 25, 2011, Kevin Hilman wrote:
commit c03f007a8bf0e092caeb6856a5c8a850df10b974 (OMAP: PM:
omap_device: add system PM methods for PM domain handling) mistakenly
used SET_SYSTEM_SLEEP_PM_OPS() when trying to configure custom methods
for the PM domains noirq methods. Fix that by setting only the
suspend_noirq and resume_noirq methods with custom versions.
Note that all other PM domain methods (including the normal
suspend/resume methods) are populated using USE_PLATFORM_PM_SLEEP_OPS,
which configures them all to the default subsystem (platform_bus)
methods.
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
Applied to linux-pm/pm-fixes, will be pushed for 3.1, thanks!
Rafael
---
arch/arm/plat-omap/omap_device.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index b6b4097..9a6a538 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -622,7 +622,8 @@ static struct dev_pm_domain omap_device_pm_domain = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
_od_runtime_idle)
USE_PLATFORM_PM_SLEEP_OPS
- SET_SYSTEM_SLEEP_PM_OPS(_od_suspend_noirq, _od_resume_noirq)
+ .suspend_noirq = _od_suspend_noirq,
+ .resume_noirq = _od_resume_noirq,
}
};
--
To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
On Thursday, August 25, 2011, Mark Brown wrote: On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote: Perhaps. Still, that requires some policy to be put into drivers, which I don't think is entirely correct. So, I don't really have the bandwidth to discuss this properly for at least the next week or so - is it possible to find some time in the power track at LPC for this? I think so, I'm going to add PM QoS to the agenda anyway. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
On Thu, Aug 25, 2011 at 4:17 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, August 25, 2011, Mark Brown wrote: On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote: Perhaps. Still, that requires some policy to be put into drivers, which I don't think is entirely correct. So, I don't really have the bandwidth to discuss this properly for at least the next week or so - is it possible to find some time in the power track at LPC for this? I think so, I'm going to add PM QoS to the agenda anyway. Unfortunately I cannot attend the conference this time. Can you please keep me in the loop of the discussions? I am glad to help implementing the code for the user space API. Thanks, Rafael Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
On Thursday, August 25, 2011, Jean Pihet wrote: On Thu, Aug 25, 2011 at 4:17 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Thursday, August 25, 2011, Mark Brown wrote: On Tue, Aug 23, 2011 at 11:31:54PM +0200, Rafael J. Wysocki wrote: Perhaps. Still, that requires some policy to be put into drivers, which I don't think is entirely correct. So, I don't really have the bandwidth to discuss this properly for at least the next week or so - is it possible to find some time in the power track at LPC for this? I think so, I'm going to add PM QoS to the agenda anyway. Unfortunately I cannot attend the conference this time. Sorry to hear that. Can you please keep me in the loop of the discussions? Sure, we will. I am glad to help implementing the code for the user space API. Great, thanks! -- To unsubscribe from this list: send the line unsubscribe 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/2] OMAP: Update nr_irqs field in machine descriptors
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? Currently, the goal is to get rid of the singleton nature of NR_IRQS. Then it just becomes a property of the platform, and the arm common code should not see this define. This cleanup has to be done across multiple SoCs, not just OMAP. After I get to complete some meaningful cleanup of NR_IRQS, I can look into the static defines that you mention. Best regards, Venkat. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] omap_twl: Prevent SR to enable for am3517/am3505 devices
Abhilash K V a écrit :
From: Vaibhav Hiremath hvaib...@ti.com
In case of AM3517 AM3505, Smart Reflex is not applicable so
we must not enable it. So add check for absence of SR feature
in omap3_twl_init() and return -ENODEV if absence, else continue.
I believe another check should be done :
you have the same problem if you run a omap3630 with TPS65023.
The check should take in account the pmu that is used and if it support SR.
Matthieu
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/omap_twl.c|8
arch/arm/plat-omap/include/plat/cpu.h |2 ++
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..da71098 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -202,7 +202,7 @@ static void __init omap3_check_features(void)
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
if (!cpu_is_omap3505() !cpu_is_omap3517())
- omap_features |= OMAP3_HAS_IO_WAKEUP;
+ omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 07d6140..47e27b5 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -269,6 +269,14 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ /*
+ * In case of AM3517/AM3505 we should not be going down
+ * further, since SR is not applicable there.
+ */
+ if (!omap3_has_sr()) {
+ return -ENODEV;
+ }
+
if (cpu_is_omap3630()) {
omap3_mpu_volt_info.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
omap3_mpu_volt_info.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 67b3d75..294e015 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -491,6 +491,7 @@ extern u32 omap_features;
#define OMAP4_HAS_MPU_1GHZ BIT(8)
#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_SR BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -507,6 +508,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(sr, SR)
/*
* Runtime detection of OMAP4 features
--
To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Thursday 25 August 2011, Russell King - ARM Linux wrote:
On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in a certain
order. It sounds to me that this will be prone to error in many ways
until everything is synced up and on the correct order.
Ditching _byname is a very bad idea.
I continue to disagree. The current _byname is an abonimation and hack
to try to fix this problem.
_byname should have been implemented differently - rather than overriding
the resources name field (which is normally specified to be the device
or driver name), a new field should have been introduced in struct resource
to carry the resource sub-name (which is really what it is.)
That would have avoided making /proc/iomem completely illegible with
multiple devices using this feature.
I agree 100%.
I'm also sure that the danger of breaking something by removing the
_byname resource resolution for each driver that we convert to DT
based probing is very small: We already need to change all static
platform_device definitions along with changing the driver, and
identifying them by index is no more ambiguous than accessing an
individual MMIO register by its index. You can even use an enum
or macro to name the indexes like:
enum {
FOO_RESOURCE_SETUP,
FOO_RESOURCE_POWER,
FOO_RESOURCE_BUFFER,
};
static struct resource foo_res[] = {
[FOO_RESOURCE_SETUP] = {
.start = FOO_SETUP_BASE,
.end = FOO_SETUP_BASE + FOO_SETUP_LEN -1,
.flags = IORESOURCE_MEM,
},
[FOO_RESOURCE_POWER] = {
.start = FOO_POWER_BASE,
.end = FOO_POWER_BASE + FOO_POWER_LEN -1,
.flags = IORESOURCE_MEM,
},
[FOO_RESOURCE_BUFFER] = {
.start = FOO_BUFFER_BASE,
.end = FOO_BUFFER_BASE + FOO_BUFFER_LEN -1,
.flags = IORESOURCE_MEM,
},
};
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, 2011-08-25 at 03:24 -0400, Todd Poynor wrote:
On Wed, Aug 24, 2011 at 08:07:12PM +0530, Keerthy wrote:
...
+ temp_sensor-phy_base = ioremap(mem-start, resource_size(mem));
Check NULL return.
temp_sensor-phy_base is never iounmapped in error paths or _remove
function.
...
+static int __devexit omap_temp_sensor_remove(struct platform_device *pdev)
+{
+ struct omap_temp_sensor *temp_sensor = platform_get_drvdata(pdev);
+
+ hwmon_device_unregister(pdev-dev);
Should be
hwmon_device_unregister(temp_sensor-hwmon_dev);
since that is what was registered, but then the following accesses using
temp_sensor-hwmon_dev won't work anymore and should probably use
pdev-dev.kobj as parameter instead. Overall the use of
temp_sensor-hwmon_dev vs. pdev-dev looks questionable to me.
+ kobject_uevent(temp_sensor-hwmon_dev-kobj, KOBJ_REMOVE);
+ sysfs_remove_group(temp_sensor-hwmon_dev-kobj,
+ omap_temp_sensor_group);
+ omap_temp_sensor_clk_disable(temp_sensor);
+ free_irq(temp_sensor-irq, temp_sensor);
free_irq before omap_temp_sensor_clk_disable, to avoid ISR attempting
to access hardware while unclocked.
Also, t_cold and t_hot interrupts should be disabled before calling
free_irq (and actually before anything is unregistered).
+ clk_put(temp_sensor-clock);
+ dev_set_drvdata(pdev-dev, NULL);
+ mutex_destroy(temp_sensor-sensor_mutex);
+ kfree(temp_sensor);
+
+ return 0;
+}
Todd
--
To unsubscribe from this list: send the line unsubscribe 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: [lm-sensors] [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, 2011-08-25 at 10:06 -0400, Guenter Roeck wrote:
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space
if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis sysfs
nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
[ ... ]
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since it
assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the application
making the change, nor is a
change order order well defined or even possible. Applications should not
have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot interrupt
in the interrupt handler and enable the t_cold interrupts. So we get a
t_cold
interrupt only when the temperature drops below the t_cold value. Hence
setting the t_cold higher than t_hot will mess up the state machine.
t_hot value should be greater than t_cold value.
One option would be to update t_cold (max_hyst) automatically in that case.
Problem here is that you expect the application to know, depending on the
current
values of (max, max_hyst), how to update both limits in order. That is not a
reasonable
expectation.
One possible solution would be to have a single function to set both
t_cold and t_hot, and call it from both initialization code and from the
set functions. That would unify all the register setting and interrupt
enable code.
Regarding the actual values to set, you can (as an example) use the
following approach:
- If max is set, and t_hot t_cold, adjust t_cold to the new value of
t_hot.
- if max_hyst is set, and t_cold t_hot, set t_cold to the new value of
t_hot.
So, in other words, your new unified function would only need the
following simple validation:
if (t_cold t_hot)
t_cold = t_hot;
[ ... ]
+
+static int __devinit omap_temp_sensor_probe(struct platform_device
*pdev)
+{
+ struct omap_temp_sensor_pdata *pdata =
pdev-dev.platform_data;
+ struct omap_temp_sensor *temp_sensor;
+ struct resource *mem;
+ int ret = 0;
+ int val, clk_rate;
+ u32 max_freq, min_freq;
+
+ if (!pdata) {
+ dev_err(pdev-dev, platform data missing\n);
+ return -EINVAL;
+ }
+
+ temp_sensor = kzalloc(sizeof(*temp_sensor), GFP_KERNEL);
+ if (!temp_sensor)
+ return -ENOMEM;
+
You have error messages all over the place, Why not here ?
Ok. I will add an error message here.
+ mutex_init(temp_sensor-sensor_mutex);
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(pdev-dev, no mem resource\n);
+ ret = -ENOMEM;
+ goto plat_res_err;
+ }
+
If you try to get the resource before allocating the memory, you don't
have to release
the memory if the platform resource is missing.
Ok. Here if i fail i am releasing temp_sensor memory which
has been allocated.
+ temp_sensor-irq = platform_get_irq_byname(pdev,
thermal_alert);
+ if (temp_sensor-irq 0) {
+ dev_err(pdev-dev, get_irq_byname failed\n);
+ ret = temp_sensor-irq;
+ goto plat_res_err;
+ }
+
+ temp_sensor-phy_base = ioremap(mem-start, resource_size(mem));
+ temp_sensor-clock = NULL;
+ temp_sensor-registers = pdata-registers;
+ temp_sensor-hwmon_dev = pdev-dev;
+
+ if (pdata-max_freq pdata-min_freq) {
+
Re: [PATCH v2 0/7] omap: iommu migration, relocation and cleanups
* Ohad Ben-Cohen o...@wizery.com [110824 19:36]: 1. Migrate OMAP's iommu driver to the generic IOMMU API, and move it to the dedicated iommu folder. 2. Fix omap3isp appropriately so it doesn't break. 3. Adapt OMAP's iovmm appropriately as well, because omap3isp still relies on it. The plan is eventually to remove iovmm and replace it with the upcoming IOMMU-based generic DMA-API. Move iovmm to the iommu folder too; it belongs there more than it belongs in the OMAP folders. 4. Start cleaning up OMAP's iommu components towards the end goal, where 1) omap-iommu no longer exports public API (and instead provides its entire functionality via the generic IOMMU API). 2) omap-iovmm is removed. Tested on OMAP3 (with omap3isp) and OMAP4 (with rpmsg/remoteproc). Glad to see this, thanks for doing this! For all the patches: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, Aug 25, 2011 at 7:36 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space
if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis sysfs
nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
Partial review only. Too many concerns, and after a while I tend to loose
track.
---
Documentation/hwmon/omap_temp_sensor | 27 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/omap_temp_sensor.c | 933
++
4 files changed, 972 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hwmon/omap_temp_sensor
create mode 100644 drivers/hwmon/omap_temp_sensor.c
[ ... ]
+/* Sysfs hook functions */
+
+static ssize_t show_temp_max(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ int temp;
+
+ temp = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ temp = (temp temp_sensor-registers-threshold_thot_mask)
+
__ffs(temp_sensor-registers-threshold_thot_mask);
+
+ if (temp OMAP_ADC_START_VALUE || temp OMAP_ADC_END_VALUE) {
+ dev_err(dev, invalid value\n);
+ return -EDOM;
Please don't use EDOM, and drop the error message.
The temperature is out of range. Should i use EIO?
It is out of range, but not due to a math error, but due to a bad reading
from the chip
or due to a chip failure. EIO is ok.
Ok
+ }
+
+ temp = adc_to_temp_conversion(temp);
+
+ return snprintf(buf, 16, %d\n, temp);
+}
+
+static ssize_t set_temp_max(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ long val;
+ u32 reg_val, t_cold, t_hot, temp;
+
+ if (strict_strtol(buf, 10, val)) {
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ t_hot = temp_to_adc_conversion(val);
Bad error return check. Negative on error. Should be
if (t_hot 0)
return t_hot;
Ok.
+ if ((t_hot OMAP_ADC_START_VALUE || t_hot OMAP_ADC_END_VALUE))
{
Unnecessary (( ))
This check is unnecessary with the negative check. I will remove.
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since it
assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the application
making the change, nor is a
change order order well defined or even possible. Applications should not
have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot interrupt
in the interrupt handler and enable the t_cold interrupts. So we get a t_cold
interrupt only when the temperature drops below the t_cold value. Hence
setting the t_cold higher than t_hot will mess up the state machine.
t_hot value should be greater than t_cold value.
One option would be to update t_cold (max_hyst) automatically in that case.
updating the t_cold without application's knowledge?
Problem here is that you expect the aplication to know, depending on the
current
values of (max, max_hyst), how to update both limits in order.
Re: [lm-sensors] [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, Aug 25, 2011 at 9:26 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, 2011-08-25 at 10:06 -0400, Guenter Roeck wrote:
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature
of
the MPU subsystem of the OMAP4. It sends notifications to the user
space if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis sysfs
nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
[ ... ]
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold
temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since it
assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the
application making the change, nor is a
change order order well defined or even possible. Applications should
not have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot
interrupt
in the interrupt handler and enable the t_cold interrupts. So we get a
t_cold
interrupt only when the temperature drops below the t_cold value. Hence
setting the t_cold higher than t_hot will mess up the state machine.
t_hot value should be greater than t_cold value.
One option would be to update t_cold (max_hyst) automatically in that case.
Problem here is that you expect the application to know, depending on the
current
values of (max, max_hyst), how to update both limits in order. That is not a
reasonable
expectation.
One possible solution would be to have a single function to set both
t_cold and t_hot, and call it from both initialization code and from the
set functions. That would unify all the register setting and interrupt
enable code.
Regarding the actual values to set, you can (as an example) use the
following approach:
- If max is set, and t_hot t_cold, adjust t_cold to the new value of
t_hot.
- if max_hyst is set, and t_cold t_hot, set t_cold to the new value of
t_hot.
So, in other words, your new unified function would only need the
following simple validation:
if (t_cold t_hot)
t_cold = t_hot;
[ ... ]
+
+static int __devinit omap_temp_sensor_probe(struct platform_device
*pdev)
+{
+ struct omap_temp_sensor_pdata *pdata =
pdev-dev.platform_data;
+ struct omap_temp_sensor *temp_sensor;
+ struct resource *mem;
+ int ret = 0;
+ int val, clk_rate;
+ u32 max_freq, min_freq;
+
+ if (!pdata) {
+ dev_err(pdev-dev, platform data missing\n);
+ return -EINVAL;
+ }
+
+ temp_sensor = kzalloc(sizeof(*temp_sensor), GFP_KERNEL);
+ if (!temp_sensor)
+ return -ENOMEM;
+
You have error messages all over the place, Why not here ?
Ok. I will add an error message here.
+ mutex_init(temp_sensor-sensor_mutex);
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(pdev-dev, no mem resource\n);
+ ret = -ENOMEM;
+ goto plat_res_err;
+ }
+
If you try to get the resource before allocating the memory, you don't
have to release
the memory if the platform resource is missing.
Ok. Here if i fail i am releasing temp_sensor memory which
has been allocated.
+ temp_sensor-irq = platform_get_irq_byname(pdev,
thermal_alert);
+ if (temp_sensor-irq 0) {
+ dev_err(pdev-dev, get_irq_byname failed\n);
+ ret = temp_sensor-irq;
+ goto plat_res_err;
+ }
+
+ temp_sensor-phy_base = ioremap(mem-start, resource_size(mem));
+ temp_sensor-clock = NULL;
+ temp_sensor-registers = pdata-registers;
+
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, 2011-08-25 at 12:04 -0400, J, KEERTHY wrote:
On Thu, Aug 25, 2011 at 7:36 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature
of
the MPU subsystem of the OMAP4. It sends notifications to the user
space if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis sysfs
nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
Partial review only. Too many concerns, and after a while I tend to
loose track.
---
Documentation/hwmon/omap_temp_sensor | 27 +
drivers/hwmon/Kconfig| 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/omap_temp_sensor.c | 933
++
4 files changed, 972 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hwmon/omap_temp_sensor
create mode 100644 drivers/hwmon/omap_temp_sensor.c
[ ... ]
+/* Sysfs hook functions */
+
+static ssize_t show_temp_max(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ int temp;
+
+ temp = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ temp = (temp temp_sensor-registers-threshold_thot_mask)
+
__ffs(temp_sensor-registers-threshold_thot_mask);
+
+ if (temp OMAP_ADC_START_VALUE || temp OMAP_ADC_END_VALUE) {
+ dev_err(dev, invalid value\n);
+ return -EDOM;
Please don't use EDOM, and drop the error message.
The temperature is out of range. Should i use EIO?
It is out of range, but not due to a math error, but due to a bad reading
from the chip
or due to a chip failure. EIO is ok.
Ok
+ }
+
+ temp = adc_to_temp_conversion(temp);
+
+ return snprintf(buf, 16, %d\n, temp);
+}
+
+static ssize_t set_temp_max(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ longval;
+ u32 reg_val, t_cold, t_hot, temp;
+
+ if (strict_strtol(buf, 10, val)) {
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ t_hot = temp_to_adc_conversion(val);
Bad error return check. Negative on error. Should be
if (t_hot 0)
return t_hot;
Ok.
+ if ((t_hot OMAP_ADC_START_VALUE || t_hot
OMAP_ADC_END_VALUE)) {
Unnecessary (( ))
This check is unnecessary with the negative check. I will remove.
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold
temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since it
assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the
application making the change, nor is a
change order order well defined or even possible. Applications should
not have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot
interrupt
in the interrupt handler and enable the t_cold interrupts. So we get a
t_cold
interrupt only when the temperature drops below the t_cold value. Hence
setting the t_cold higher than t_hot will mess up the state machine.
t_hot value should be greater than t_cold value.
One option would be to update t_cold (max_hyst) automatically in that
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, Aug 25, 2011 at 9:49 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, 2011-08-25 at 12:04 -0400, J, KEERTHY wrote:
On Thu, Aug 25, 2011 at 7:36 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature
of
the MPU subsystem of the OMAP4. It sends notifications to the user
space if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis sysfs
nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
Partial review only. Too many concerns, and after a while I tend to
loose track.
---
Documentation/hwmon/omap_temp_sensor | 27 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/omap_temp_sensor.c | 933
++
4 files changed, 972 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hwmon/omap_temp_sensor
create mode 100644 drivers/hwmon/omap_temp_sensor.c
[ ... ]
+/* Sysfs hook functions */
+
+static ssize_t show_temp_max(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ int temp;
+
+ temp = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ temp = (temp temp_sensor-registers-threshold_thot_mask)
+
__ffs(temp_sensor-registers-threshold_thot_mask);
+
+ if (temp OMAP_ADC_START_VALUE || temp OMAP_ADC_END_VALUE) {
+ dev_err(dev, invalid value\n);
+ return -EDOM;
Please don't use EDOM, and drop the error message.
The temperature is out of range. Should i use EIO?
It is out of range, but not due to a math error, but due to a bad reading
from the chip
or due to a chip failure. EIO is ok.
Ok
+ }
+
+ temp = adc_to_temp_conversion(temp);
+
+ return snprintf(buf, 16, %d\n, temp);
+}
+
+static ssize_t set_temp_max(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ long val;
+ u32 reg_val, t_cold, t_hot, temp;
+
+ if (strict_strtol(buf, 10, val)) {
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ t_hot = temp_to_adc_conversion(val);
Bad error return check. Negative on error. Should be
if (t_hot 0)
return t_hot;
Ok.
+ if ((t_hot OMAP_ADC_START_VALUE || t_hot
OMAP_ADC_END_VALUE)) {
Unnecessary (( ))
This check is unnecessary with the negative check. I will remove.
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold
temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since
it assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the
application making the change, nor is a
change order order well defined or even possible. Applications should
not have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot
interrupt
in the interrupt handler and enable the t_cold interrupts. So we get a
t_cold
interrupt only when the temperature drops below the t_cold value. Hence
setting the t_cold higher than t_hot will mess up the state machine.
t_hot value should be greater than t_cold
Re: [PATCH 6/6 V3] hwmon: OMAP4: On die temperature sensor driver
On Thu, 2011-08-25 at 12:39 -0400, J, KEERTHY wrote:
On Thu, Aug 25, 2011 at 9:49 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, 2011-08-25 at 12:04 -0400, J, KEERTHY wrote:
On Thu, Aug 25, 2011 at 7:36 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
On Wed, Aug 24, 2011 at 10:46 PM, Guenter Roeck
guenter.ro...@ericsson.com wrote:
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the
temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user
space if
the temperature crosses user defined thresholds via kobject_uevent
interface.
The user is allowed to configure the temperature thresholds vis
sysfs nodes
exposed using hwmon interface.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Guenter Roeck guenter.ro...@ericsson.com
Cc: lm-sens...@lm-sensors.org
Partial review only. Too many concerns, and after a while I tend to
loose track.
---
Documentation/hwmon/omap_temp_sensor | 27 +
drivers/hwmon/Kconfig| 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/omap_temp_sensor.c | 933
++
4 files changed, 972 insertions(+), 0 deletions(-)
create mode 100644 Documentation/hwmon/omap_temp_sensor
create mode 100644 drivers/hwmon/omap_temp_sensor.c
[ ... ]
+/* Sysfs hook functions */
+
+static ssize_t show_temp_max(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ int temp;
+
+ temp = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ temp = (temp temp_sensor-registers-threshold_thot_mask)
+
__ffs(temp_sensor-registers-threshold_thot_mask);
+
+ if (temp OMAP_ADC_START_VALUE || temp
OMAP_ADC_END_VALUE) {
+ dev_err(dev, invalid value\n);
+ return -EDOM;
Please don't use EDOM, and drop the error message.
The temperature is out of range. Should i use EIO?
It is out of range, but not due to a math error, but due to a bad
reading from the chip
or due to a chip failure. EIO is ok.
Ok
+ }
+
+ temp = adc_to_temp_conversion(temp);
+
+ return snprintf(buf, 16, %d\n, temp);
+}
+
+static ssize_t set_temp_max(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct omap_temp_sensor *temp_sensor = dev_get_drvdata(dev);
+ longval;
+ u32 reg_val, t_cold, t_hot, temp;
+
+ if (strict_strtol(buf, 10, val)) {
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ t_hot = temp_to_adc_conversion(val);
Bad error return check. Negative on error. Should be
if (t_hot 0)
return t_hot;
Ok.
+ if ((t_hot OMAP_ADC_START_VALUE || t_hot
OMAP_ADC_END_VALUE)) {
Unnecessary (( ))
This check is unnecessary with the negative check. I will remove.
+ count = -EINVAL;
+ goto out;
This will try to release the not-acquired lock.
I will correct this.
+ }
+
+ mutex_lock(temp_sensor-sensor_mutex);
+ /* obtain the T cold value */
+ t_cold = omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_threshold);
+ t_cold = (t_cold
temp_sensor-registers-threshold_tcold_mask)
+
__ffs(temp_sensor-registers-threshold_tcold_mask);
+
+ if (t_hot t_cold) {
+ count = -EINVAL;
+ goto out;
Context specific limitations like this one are not a good idea, since
it assumes an order of changing max
and max_hysteresis which is not necessarily guaranteed by the
application making the change, nor is a
change order order well defined or even possible. Applications should
not have to bother about this.
The hardware behavior is like this. As long as the temperature is below
t_hot no interrupts are fired. Once the temperature increases above
t_hot we get an
interrupt. In order to avoid repeated interrupts we mask the t_hot
interrupt
in the interrupt handler and enable the t_cold interrupts. So we
Re: How to handle named resources with DT?
On 8/25/2011 12:28 PM, Russell King - ARM Linux wrote: On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote: on top of all that, for IPs which are used on many SoCs (such as MUSB) it's quite silly to force all users to provide resources in a certain order. It sounds to me that this will be prone to error in many ways until everything is synced up and on the correct order. Ditching _byname is a very bad idea. I continue to disagree. The current _byname is an abonimation and hack to try to fix this problem. What problem are you considering here? _byname should have been implemented differently - rather than overriding the resources name field (which is _normally_ specified to be the device or driver name), a new field should have been introduced in struct resource to carry the resource sub-name (which is really what it is.) I guess we agree on that, but that just means that the implementation is bad, not that the function is useless or evil. That would have avoided making /proc/iomem completely illegible with multiple devices using this feature. resources are used as well for irq and dma, so that aspect is irrelevant in that case. Assuming that a new field is added to keep the original semantic ot the name, will you be happy with the _byname API? 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: How to handle named resources with DT?
Arnd Bergmann a...@arndb.de writes: On Thursday 25 August 2011, Russell King - ARM Linux wrote: On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote: on top of all that, for IPs which are used on many SoCs (such as MUSB) it's quite silly to force all users to provide resources in a certain order. It sounds to me that this will be prone to error in many ways until everything is synced up and on the correct order. Ditching _byname is a very bad idea. I continue to disagree. The current _byname is an abonimation and hack to try to fix this problem. _byname should have been implemented differently - rather than overriding the resources name field (which is normally specified to be the device or driver name), a new field should have been introduced in struct resource to carry the resource sub-name (which is really what it is.) That would have avoided making /proc/iomem completely illegible with multiple devices using this feature. I agree 100%. Please clarify. What I hear Russell saying is a problem with the *implementation* of the _byname API. What I hear you sating is that since DT doesn't support this, we need to remove it's usage completely from platform_devices also. These are two very different approaches. Fixing the implementation as Russell suggested seems relatively easy, and conceptually similar to adding it to the DT. Removing _byname all together seems like significant work just to avoid adding a feature to the DT core. Kevin -- To unsubscribe from this list: send the line unsubscribe 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: Question on virtual memory layout: lowmem with memory hole
Russell King - ARM Linux wrote on Thursday, August 25, 2011 3:53 PM: On Thu, Aug 25, 2011 at 09:35:07AM +0530, Pedanekar, Hemant wrote: E.g., on OMAP3 with mem=32M@0x8000 mem=8M@0x8780 (CASE 1) Memory: 32MB 8MB = 40MB total Memory: 28408k/28408k available, 12552k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc05ac2c8 (5777 kB) .init : 0xc05ad000 - 0xc05f8780 ( 302 kB) .data : 0xc05fa000 - 0xc06838d0 ( 551 kB) .bss : 0xc06838f4 - 0xc0bd8a14 (5461 kB) Is this expected? 88MB space between two 'mem's seems to have lost. Yes. The memory layout lines gives an overview of the virtual memory address space _regions_. What it's saying is that the virtual addresses from 0xc000 - 0xc800 are used for lowmem. That may not be fully populated, but that's what the address range is reserved for. So, larger the hole, more address space will be unusable - is that correct? This also means vmalloc space is lower compared to when a single mem=40M is passed. Huh. Either your maths is wrong or... Here's case 1: vmalloc : 0xc880 - 0xf800 ( 760 MB) And case 2: vmalloc : 0xc300 - 0xf800 ( 848 MB) Looks to me like case 1, vmalloc space is _higher_ not _lower_. That's expected because you told the kernel it had more memory in case 1. Sorry, my mistake - I actually meant vmalloc space is _smaller_ compared to when a single mem=40M is passed though the actual physical RAM available is same in both the cases. Thanks. Hemant-- To unsubscribe from this list: send the line unsubscribe 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: Question on virtual memory layout: lowmem with memory hole
On Fri, Aug 26, 2011 at 12:06:20AM +0530, Pedanekar, Hemant wrote: Russell King - ARM Linux wrote on Thursday, August 25, 2011 3:53 PM: On Thu, Aug 25, 2011 at 09:35:07AM +0530, Pedanekar, Hemant wrote: E.g., on OMAP3 with mem=32M@0x8000 mem=8M@0x8780 (CASE 1) Memory: 32MB 8MB = 40MB total Memory: 28408k/28408k available, 12552k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc05ac2c8 (5777 kB) .init : 0xc05ad000 - 0xc05f8780 ( 302 kB) .data : 0xc05fa000 - 0xc06838d0 ( 551 kB) .bss : 0xc06838f4 - 0xc0bd8a14 (5461 kB) Is this expected? 88MB space between two 'mem's seems to have lost. Yes. The memory layout lines gives an overview of the virtual memory address space _regions_. What it's saying is that the virtual addresses from 0xc000 - 0xc800 are used for lowmem. That may not be fully populated, but that's what the address range is reserved for. So, larger the hole, more address space will be unusable - is that correct? Correct. This also means vmalloc space is lower compared to when a single mem=40M is passed. Huh. Either your maths is wrong or... Here's case 1: vmalloc : 0xc880 - 0xf800 ( 760 MB) And case 2: vmalloc : 0xc300 - 0xf800 ( 848 MB) Looks to me like case 1, vmalloc space is _higher_ not _lower_. That's expected because you told the kernel it had more memory in case 1. Sorry, my mistake - I actually meant vmalloc space is _smaller_ compared to when a single mem=40M is passed though the actual physical RAM available is same in both the cases. Again, that's expected. We require a 1:1 relationship between virtual and physical addresses for efficiency - having non-linear translation means we'd need a lookup table, and as these translations are heavily used, that will impact performance. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] usb: Introduce DesignWare USB3 DRD Driver
On Fri, Aug 19, 2011 at 06:10:58PM +0300, Felipe Balbi wrote:
+enum dwc3_link_state {
+ /* In SuperSpeed */
+ DWC3_LINK_STATE_U0 = 0x00, /* in HS, means ON */
+ DWC3_LINK_STATE_U1 = 0x01,
+ DWC3_LINK_STATE_U2 = 0x02, /* in HS, means SLEEP */
+ DWC3_LINK_STATE_U3 = 0x03, /* in HS, means SUSPEND */
+ DWC3_LINK_STATE_SS_DIS = 0x04,
+ DWC3_LINK_STATE_RX_DET = 0x05, /* in HS, means Early Suspend */
+ DWC3_LINK_STATE_SS_INACT= 0x06,
+ DWC3_LINK_STATE_POLL= 0x07,
+ DWC3_LINK_STATE_RECOV = 0x08,
+ DWC3_LINK_STATE_HRESET = 0x09,
+ DWC3_LINK_STATE_CMPLY = 0x0a,
+ DWC3_LINK_STATE_LPBK= 0x0b,
+ DWC3_LINK_STATE_MASK= 0x0f,
+};
AFAICT, the link state values are exactly the same as the xHCI link
state values in the Port Link State field in the PORTSC register. Is
the gadget side (xDCI side) meant to be somewhat compatible with the
xHCI host controller spec?
Would it make sense to share these link state macros (and any other
similar #defines) with the xHCI driver? We could move them into
include/linux/ch11.h.
Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4 tiler memory issue
Hi, I have 2 questions related to tiler memory space 2D buffers. I am working on a project that utilizes video encoder on OMAP4 (H.264) using OpenMax API. In general, the encoder works as expected except that I am seeing a very slow memcpy operation that copies input frame data to encoder’s buffers (takes almost 100ms to copy 720p frame). I am relying on OpenMax to allocate the input buffers (using OMX_AllocateBuffer). The same memcpy routine works much faster when copying the same data into regular user-space allocated buffers (malloc based). Considering that the encoder is supposed to work at the rate of 30fps, spending 100ms on each frame is too much. I understand that OpenMax allocates tiler 2D buffers using memory manager and it appears that those buffers are non-cachable. I have tried to map user-space allocated buffer into tiler memory space (using MemMgr_Map) and then to copy frame data into the user-space memory pointer. In this case memcpy works indeed faster (although still not as fast as I would have hoped for), but I am seeing lots of artifacts in the encoder’s output. I am assuming this could be related to caching issues with the mapping. My first question is: is there a way to be able to copy encoder input data in a fast way – maybe there are specific requirements for allocating/mapping encoder input buffers? My second question is about tiler image rotation: what is the correct way (if any) to be able to utilize tiler-based rotation on encoder’s input buffers from user-space (only interested in right-angle rotations). I understand that I need to calculate the correct tiler memory space offset for the specific rotation degree that is required. Would I be able to access the address from user-space and maybe even somehow ask the encoder to use the rotated image instead of the original one? Any information/hints will be greatly appreciated (or a sample test source code). Thank you, Leo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 03/22] gpio/omap: make gpio_context part of gpio_bank structure
Santosh santosh.shilim...@ti.com writes:
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
From: Charulatha Vch...@ti.com
Currently gpio_context array used to save gpio bank's context, is used only
for
OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that
it
can be specific to each gpio bank and can be used for any OMAP architecture
Signed-off-by: Charulatha Vch...@ti.com
---
Few comments.
[...]
@@ -1494,33 +1490,31 @@ void omap2_gpio_resume_after_idle(void)
void omap_gpio_save_context(void)
{
struct gpio_bank *bank;
-int i = 0;
list_for_each_entry(bank,omap_gpio_list, node) {
-i++;
if (!bank-loses_context)
continue;
-gpio_context[i].irqenable1 =
+bank-context.irqenable1 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE1);
-gpio_context[i].irqenable2 =
+bank-context.irqenable2 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE2);
The context restore procedure should be done carefully. For instance
IRQ enabled register should be restored last to avoid any spurious
interrupts.
For the sake of clean, easy-to-review patches, this kind of functional
change should be a separate patch.
The goal of $SUBJECT patch is simply to move the context struct into the
bank struct, not change the order of the save restore.
Any changing of the order of save/restore should be in a dedicated patch
with a descriptive changelog since that is changing behavior of the code.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] usb: Introduce DesignWare USB3 DRD Driver
Hi,
On Thu, Aug 25, 2011 at 12:15:09PM -0700, Sarah Sharp wrote:
On Fri, Aug 19, 2011 at 06:10:58PM +0300, Felipe Balbi wrote:
+enum dwc3_link_state {
+ /* In SuperSpeed */
+ DWC3_LINK_STATE_U0 = 0x00, /* in HS, means ON */
+ DWC3_LINK_STATE_U1 = 0x01,
+ DWC3_LINK_STATE_U2 = 0x02, /* in HS, means SLEEP */
+ DWC3_LINK_STATE_U3 = 0x03, /* in HS, means SUSPEND */
+ DWC3_LINK_STATE_SS_DIS = 0x04,
+ DWC3_LINK_STATE_RX_DET = 0x05, /* in HS, means Early Suspend */
+ DWC3_LINK_STATE_SS_INACT= 0x06,
+ DWC3_LINK_STATE_POLL= 0x07,
+ DWC3_LINK_STATE_RECOV = 0x08,
+ DWC3_LINK_STATE_HRESET = 0x09,
+ DWC3_LINK_STATE_CMPLY = 0x0a,
+ DWC3_LINK_STATE_LPBK= 0x0b,
+ DWC3_LINK_STATE_MASK= 0x0f,
+};
AFAICT, the link state values are exactly the same as the xHCI link
state values in the Port Link State field in the PORTSC register. Is
the gadget side (xDCI side) meant to be somewhat compatible with the
xHCI host controller spec?
I guess Synopsys would be best to answer this question. Paul, do you
happen to know the answer ?
Would it make sense to share these link state macros (and any other
similar #defines) with the xHCI driver? We could move them into
include/linux/ch11.h.
I'm not sure it makes sense to make gadget side use ch11 definitions,
but we could move them to some other common header, maybe ?
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 3/4] usb: Introduce DesignWare USB3 DRD Driver
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, August 25, 2011 1:36 PM
To: Sarah Sharp
Cc: Felipe Balbi; Greg KH; Linux USB Mailing List; Linux OMAP Mailing List;
Paul Zimmerman
Subject: Re: [PATCH 3/4] usb: Introduce DesignWare USB3 DRD Driver
Hi,
On Thu, Aug 25, 2011 at 12:15:09PM -0700, Sarah Sharp wrote:
On Fri, Aug 19, 2011 at 06:10:58PM +0300, Felipe Balbi wrote:
+enum dwc3_link_state {
+ /* In SuperSpeed */
+ DWC3_LINK_STATE_U0 = 0x00, /* in HS, means ON */
+ DWC3_LINK_STATE_U1 = 0x01,
+ DWC3_LINK_STATE_U2 = 0x02, /* in HS, means SLEEP */
+ DWC3_LINK_STATE_U3 = 0x03, /* in HS, means SUSPEND */
+ DWC3_LINK_STATE_SS_DIS = 0x04,
+ DWC3_LINK_STATE_RX_DET = 0x05, /* in HS, means Early Suspend */
+ DWC3_LINK_STATE_SS_INACT= 0x06,
+ DWC3_LINK_STATE_POLL= 0x07,
+ DWC3_LINK_STATE_RECOV = 0x08,
+ DWC3_LINK_STATE_HRESET = 0x09,
+ DWC3_LINK_STATE_CMPLY = 0x0a,
+ DWC3_LINK_STATE_LPBK= 0x0b,
+ DWC3_LINK_STATE_MASK= 0x0f,
+};
AFAICT, the link state values are exactly the same as the xHCI link
state values in the Port Link State field in the PORTSC register. Is
the gadget side (xDCI side) meant to be somewhat compatible with the
xHCI host controller spec?
I guess Synopsys would be best to answer this question. Paul, do you
happen to know the answer ?
Would it make sense to share these link state macros (and any other
similar #defines) with the xHCI driver? We could move them into
include/linux/ch11.h.
I'm not sure it makes sense to make gadget side use ch11 definitions,
but we could move them to some other common header, maybe ?
Our USB3 core is a dual-role device, and some of the logic is shared
between xHCI mode and Device mode. So it's not a coincidence that the
link state values are the same.
However, in future the device mode will have additional states beyond
those defined for xHCI. So a completely common header file is not
possible, unless people don't mind having Synopsys-specific defines
inside it.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: How to handle named resources with DT?
On Thursday 25 August 2011 11:16:25 Kevin Hilman wrote: Please clarify. What I hear Russell saying is a problem with the implementation of the _byname API. What I hear you sating is that since DT doesn't support this, we need to remove it's usage completely from platform_devices also. These are two very different approaches. Fixing the implementation as Russell suggested seems relatively easy, and conceptually similar to adding it to the DT. Removing _byname all together seems like significant work just to avoid adding a feature to the DT core. It's not at all about whether the Linux codein drivers/of supports this or not, adding it would be trivial. The point is that it would be *wrong* to add it because there already exists a way to identify every resource in the device tree and we should not extend that interface to have multiple ways to do the same thing just for convenience of a few device drivers! One of the important advantages of using the IEEE device tree bindings is that we can define device trees that are to a large degree compatible with how AIX, Solaris, MacOS, FreeBSD and probably many more (lesser known) operating systems probe their systems. Changing the resource interface in Linux to have two 'name' fields would also be terribly confusing and is not a good interface, it would just solve another problem (silly entries in /proc/iomem) that we don't need to have in the first place when we do the obvious conversion of the drivers to the IEEE standard way of doing this. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] usb: Introduce DesignWare USB3 DRD Driver
Hi,
On Thu, Aug 25, 2011 at 01:48:09PM -0700, Paul Zimmerman wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, August 25, 2011 1:36 PM
To: Sarah Sharp
Cc: Felipe Balbi; Greg KH; Linux USB Mailing List; Linux OMAP Mailing List;
Paul Zimmerman
Subject: Re: [PATCH 3/4] usb: Introduce DesignWare USB3 DRD Driver
Hi,
On Thu, Aug 25, 2011 at 12:15:09PM -0700, Sarah Sharp wrote:
On Fri, Aug 19, 2011 at 06:10:58PM +0300, Felipe Balbi wrote:
+enum dwc3_link_state {
+ /* In SuperSpeed */
+ DWC3_LINK_STATE_U0 = 0x00, /* in HS, means ON */
+ DWC3_LINK_STATE_U1 = 0x01,
+ DWC3_LINK_STATE_U2 = 0x02, /* in HS, means SLEEP */
+ DWC3_LINK_STATE_U3 = 0x03, /* in HS, means SUSPEND
*/
+ DWC3_LINK_STATE_SS_DIS = 0x04,
+ DWC3_LINK_STATE_RX_DET = 0x05, /* in HS, means Early
Suspend */
+ DWC3_LINK_STATE_SS_INACT= 0x06,
+ DWC3_LINK_STATE_POLL= 0x07,
+ DWC3_LINK_STATE_RECOV = 0x08,
+ DWC3_LINK_STATE_HRESET = 0x09,
+ DWC3_LINK_STATE_CMPLY = 0x0a,
+ DWC3_LINK_STATE_LPBK= 0x0b,
+ DWC3_LINK_STATE_MASK= 0x0f,
+};
AFAICT, the link state values are exactly the same as the xHCI link
state values in the Port Link State field in the PORTSC register. Is
the gadget side (xDCI side) meant to be somewhat compatible with the
xHCI host controller spec?
I guess Synopsys would be best to answer this question. Paul, do you
happen to know the answer ?
Would it make sense to share these link state macros (and any other
similar #defines) with the xHCI driver? We could move them into
include/linux/ch11.h.
I'm not sure it makes sense to make gadget side use ch11 definitions,
but we could move them to some other common header, maybe ?
Our USB3 core is a dual-role device, and some of the logic is shared
between xHCI mode and Device mode. So it's not a coincidence that the
link state values are the same.
However, in future the device mode will have additional states beyond
those defined for xHCI. So a completely common header file is not
possible, unless people don't mind having Synopsys-specific defines
inside it.
Thanks for the reply Paul :-) I believe this is strong enough argument
to keep things as they are.
--
balbi
signature.asc
Description: Digital signature
Re: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
On Fri, Jul 1, 2011 at 12:11 AM, jean.pi...@newoldbits.com wrote:
@@ -129,19 +146,19 @@ static const struct file_operations pm_qos_power_fops =
{
/* unlocked internal variant */
static inline int pm_qos_get_value(struct pm_qos_object *o)
{
- if (plist_head_empty(o-requests))
+ if (plist_head_empty(o-requests))
return o-default_value;
switch (o-type) {
- case PM_QOS_MIN:
- return plist_first(o-requests)-prio;
+ case PM_QOS_MIN:
+ return plist_first(o-requests)-prio;
- case PM_QOS_MAX:
- return plist_last(o-requests)-prio;
+ case PM_QOS_MAX:
+ return plist_last(o-requests)-prio;
- default:
- /* runtime check for not using enum */
- BUG();
+ default:
+ /* runtime check for not using enum */
+ BUG();
}
}
Hello,
Sorry to jump in this late, but, I've got a question in choosing QoS
value from the list with pm_qos_get_value function and pm_qos_type.
For QoS objects such as network throughput, wouldn't PM_QOS_ADD be
more appropriate than PM_QOS_MAX?
If A is requesting 10MB/s on NIC-X and B is requesting 5MB/s on NIC-X,
I guess PM QOS should say NIC-X that it needs to provide 15MB/s, not
10MB/s. Or, are we assuming that A and B will never put streams at the
same time?
Thanks,
MyungJoo
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 03/22] gpio/omap: make gpio_context part of gpio_bank structure
[...]
@@ -1494,33 +1490,31 @@ void omap2_gpio_resume_after_idle(void)
void omap_gpio_save_context(void)
{
struct gpio_bank *bank;
- int i = 0;
list_for_each_entry(bank,omap_gpio_list, node) {
- i++;
if (!bank-loses_context)
continue;
- gpio_context[i].irqenable1 =
+ bank-context.irqenable1 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE1);
- gpio_context[i].irqenable2 =
+ bank-context.irqenable2 =
__raw_readl(bank-base + OMAP24XX_GPIO_IRQENABLE2);
The context restore procedure should be done carefully. For instance
IRQ enabled register should be restored last to avoid any spurious
interrupts.
For the sake of clean, easy-to-review patches, this kind of functional
change should be a separate patch.
The goal of $SUBJECT patch is simply to move the context struct into the
bank struct, not change the order of the save restore.
Any changing of the order of save/restore should be in a dedicated patch
with a descriptive changelog since that is changing behavior of the code.
Ok.
Kevin
--
To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Thu, Aug 25, 2011 at 11:16:25AM -0700, Kevin Hilman wrote: Arnd Bergmann a...@arndb.de writes: On Thursday 25 August 2011, Russell King - ARM Linux wrote: On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote: on top of all that, for IPs which are used on many SoCs (such as MUSB) it's quite silly to force all users to provide resources in a certain order. It sounds to me that this will be prone to error in many ways until everything is synced up and on the correct order. Ditching _byname is a very bad idea. I continue to disagree. The current _byname is an abonimation and hack to try to fix this problem. _byname should have been implemented differently - rather than overriding the resources name field (which is normally specified to be the device or driver name), a new field should have been introduced in struct resource to carry the resource sub-name (which is really what it is.) That would have avoided making /proc/iomem completely illegible with multiple devices using this feature. I agree 100%. Please clarify. What I hear Russell saying is a problem with the *implementation* of the _byname API. What I hear you sating is that since DT doesn't support this, we need to remove it's usage completely from platform_devices also. These are two very different approaches. Fixing the implementation as Russell suggested seems relatively easy, and conceptually similar to adding it to the DT. Removing _byname all together seems like significant work just to avoid adding a feature to the DT core. Seriously, how many times do I have to say it? Using _byname in drivers DOES NOT require adding names to the DT. All it needs is some glue logic to attach names as the device tree is read. This is properly thought of as part of the code which translates the device tree into struct platform_device, not as part of drivers proper. FURTHERMORE, even if there were names in the DT, you'd *still* need this glue logic, so that drivers converted to _byname could still use old device trees. Insisting that the names come from the DT is to mistakenly think of the DT as an extension of the kernel's internal interfaces, instead of as the external and OS neutral data structure it actually is. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
