Re: [PATCH 4/7] omap: iommu: PREFETCH_IOTLB cleanup
Hi Hiroshi, On Thu, Aug 18, 2011 at 8:27 AM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: While we're at it, rename load_iotlb_entry to prefetch_iotlb_entry to better reflect the purpose of that function. Considering that, originally this function is the counterpart of flush_iotlb_page() among load_iotlb_/flush_iotlb_*() family and OMAP1 doesn't use H/W page table but only uses TLB(only prefetch/load_tlb), what about keeping the original function load_iotlb_entry(), and make inline function prefetch_iotlb_entry() has it? Sure, np (I have considered doing that, but decided to drop it for now since there's no other user of load_iotlb_entry currently. Now that you mention it too, I'll do that). Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv2 0/5] OMAP DSS HWMOD fixes
Hi Paul, Did you get a chance to look at this series? These fixes will allow us to remove the temporary hacks from the DSS driver. Tomi On Mon, 2011-08-08 at 12:15 +0300, Tomi Valkeinen wrote: Second try with the DSS HWMODs This set fixes the DSS clocks in HWMOD data, and implements a new reset mechanism for dss_core. The new dss_reset function doesn't actually do a reset, it just enables all DSS clocks and waits for the reset to complete. This should be better approach than actually doing a reset, because: OMAP4 - dss_core HW doesn't contain a SW reset bit so doing a reset is impossible. But after power-on we need to enable all DSS clocks and wait for the power-on reset to complete. OMAP2/3 - dss_core does have a SW reset bit, but resetting dss_core also resets all the other DSS modules. This means that the other modules could be left uninitialized, as the hwmod code handles all modules independently, and in this case initializes only dss_core's registers. Thus dss_core's reset shouldn't be used, and we should only verify that the power-on reset has completed. Tested on OMAP4 and OMAP3. The first two HWMOD patches (for OMAP2/3) are not changed since v1. Tomi Tomi Valkeinen (5): OMAP2xxx: HWMOD: fix DSS opt clocks OMAP3: HWMOD: fix DSS opt clocks OMAP4: HWMOD: fix DSS opt clocks OMAP2/3: HWMOD: Add SYSS_HAS_RESET_STATUS for dss OMAP: HWMOD: Unify DSS resets for all OMAPs arch/arm/mach-omap2/common-board-devices.h |4 ++ arch/arm/mach-omap2/display.c | 35 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 15 +++- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 15 +++- .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |5 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 35 +-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 +++--- 7 files changed, 106 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/7] PM QoS: add a per-device latency constraints framework
Hi, On Wednesday, August 17, 2011, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com High level implementation: 1. Preparation of the PM QoS for the addition of a device PM QoS constraints framework: . rename and move of the PM QoS implementation files to kernel/power/qos.c and include/linux/pm_qos.h . rename of API parameters and internal fields names . Move around the PM QoS misc devices management code for better readability . re-organize the internal data structs . generalize and export the constraints management core code 2. Implementation of the per-device PM QoS constraints: . create drivers/base/power/qos.c for the implementation . create a device PM QoS API, which calls the PM QoS constraints management core code . the per-device latency constraints data strctures are stored in the device dev_pm_info struct . the device PM code calls the init and destroy of the per-device constraints data struct in order to support the dynamic insertion and removal of the devices in the system. . to minimize the data usage by the per-device constraints, the data struct is only allocated at the first call to dev_pm_qos_add_request. The data is later free'd when the device is removed from the system . per-device notification callbacks can be registered and called upon a change to the aggregated constraint value . a global mutex protects the constraints users from the data being allocated and free'd. 3. add a global notification mechanism for the device constraints . add a global notification chain that gets called upon changes to the aggregated constraint value for any device. . the notification callbacks are passing the full constraint request data in order for the callees to have access to it. The current use is for the platform low-level code to access the target device of the constraint Questions: 1. the user space API is still under discussions on linux-omap and linux-pm MLs, cf. [1]. The idea is to add a user-space API for the devices constratins PM QoS, using a sysfs entry per device [1] http://marc.info/?l=linux-omapm=131232344503327w=2 ToDo: 1. write Documentation for the new PM QoS class, once the code is agreed on 2. submit patches for the OMAP low level code to control the power domains states from the device constraints, using a global notification callback Based on the master branch of the linux-omap git tree (3.1.0-rc1). Compile tested using OMAP and x86 generic defconfigs. Tested on OMAP3 Beagleboard (ES2.x). Need testing on platforms other than OMAP, because of the impact on the device insertion/removal in device_pm_add/remove OK If that were my code, I'd probably change a couple of things more, but it looks good enough to me to take as is. I'm going to push this patchset for 3.2. Thanks a lot for your hard work on it, 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: [PATCH 1/7] omap: iommu: migrate to the generic IOMMU API
Hi Ohad,
Thanks for the patch.
Just one small comment in case you resubmit the whole series for another
reason.
On Thursday 18 August 2011 01:10:02 Ohad Ben-Cohen wrote:
Migrate OMAP's iommu driver to the generic IOMMU API, so users can stay
generic, and any generic IOMMU functionality can be developed once
in the generic framework.
Migrate omap's iovmm (virtual memory manager) to the generic IOMMU API,
and adapt omap3isp as needed, so the latter won't break.
The plan is to eventually remove iovmm completely by replacing it
with the (upcoming) IOMMU-based DMA-API.
Tested on OMAP3 (with omap3isp) and OMAP4 (with rpmsg/remoteproc).
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
[snip]
+static void omap_iommu_detach_dev(struct iommu_domain *domain,
+ struct device *dev)
+{
+ struct omap_iommu_domain *omap_domain = domain-priv;
+ struct iommu *oiommu = to_iommu(dev);
+
+ mutex_lock(omap_domain-lock);
+
+ /* only a single device is supported per domain for now */
+ if (omap_domain-iommu_dev != oiommu) {
+ dev_err(dev, invalid iommu device\n);
+ goto out;
+ }
+
+ iopgtable_clear_entry_all(oiommu);
+
+ omap_iommu_detach(oiommu);
+
+ omap_domain-iommu_dev = NULL;
+
+out:
+ mutex_unlock(omap_domain-lock);
+}
+
+static int omap_iommu_domain_init(struct iommu_domain *domain)
+{
+ struct omap_iommu_domain *omap_domain;
+
+ omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL);
+ if (!omap_domain) {
+ pr_err(kzalloc failed\n);
+ goto out;
You can directly return -ENOMEM here, and remove the out: label.
+ }
+
+ omap_domain-pgtable = kzalloc(IOPGD_TABLE_SIZE, GFP_KERNEL);
+ if (!omap_domain-pgtable) {
+ pr_err(kzalloc failed\n);
+ goto fail_nomem;
+ }
+
+ /*
+ * should never fail, but please keep this around to ensure
+ * we keep the hardware happy
+ */
+ BUG_ON(!IS_ALIGNED((long)omap_domain-pgtable, IOPGD_TABLE_SIZE));
+
+ clean_dcache_area(omap_domain-pgtable, IOPGD_TABLE_SIZE);
+ mutex_init(omap_domain-lock);
+
+ domain-priv = omap_domain;
+
+ return 0;
+
+fail_nomem:
+ kfree(omap_domain);
+out:
+ return -ENOMEM;
+}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Media controller: Define media_entity_init() and media_entity_cleanup() conditionally
On Wednesday 17 August 2011 12:53:46 Andy Shevchenko wrote: On Wed, 2011-08-17 at 16:04 +0530, Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Defines the two functions only when CONFIG_MEDIA_CONTROLLER is enabled. Is it not a driver's option to be dependent on MEDIA_CONTROLLER? Yes it is. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] omap: iommu: migrate to the generic IOMMU API
Hi Laurent, On Thu, Aug 18, 2011 at 12:01 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Just one small comment in case you resubmit the whole series for another reason. .. You can directly return -ENOMEM here, and remove the out: label. Sure thing, Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: musb: remove unneeded init code
The .power and .mode parameter of 'musb_plat' is also now set dynamically
in usb_musb_init() so remove them.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/usb-musb.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..de48106 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -41,21 +41,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_MUSB_OTG
- .mode = MUSB_OTG,
-#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
- .mode = MUSB_HOST,
-#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
- .mode = MUSB_PERIPHERAL,
-#endif
- /* .clock is set dynamically */
+ /* .clock, .mode and .power is set dynamically */
.config = musb_config,
-
- /* REVISIT charge pump on TWL4030 can supply up to
-* 100 mA ... but this value is board-specific, like
-* mode, and should be passed to usb_musb_init().
-*/
- .power = 50, /* up to 100 mA */
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] omap: iommu migration, relocation and cleanups
Hi Ohad, On Thursday 18 August 2011 01:10:01 Ohad Ben-Cohen wrote: 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. Changes: 1. Migrate iommu, iovmm and omap3isp in a single patch for bisectibility sake. 2. Apply Laurent Pinchart's comments (thanks Laurent!) You're welcome. 3. Rebase to 3.1-rc2 For the OMAP3 ISP driver changes, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Media controller: Define media_entity_init() and media_entity_cleanup() conditionally
Thanks,
Deepthy Ravi.
From: Hiremath, Vaibhav
Sent: Wednesday, August 17, 2011 9:00 PM
To: Ravi, Deepthy; mche...@infradead.org; linux-me...@vger.kernel.org;
linux-ker...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH] Media controller: Define media_entity_init() and
media_entity_cleanup() conditionally
-Original Message-
From: Ravi, Deepthy
Sent: Wednesday, August 17, 2011 4:05 PM
To: mche...@infradead.org; linux-me...@vger.kernel.org; linux-
ker...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; Hiremath, Vaibhav; Ravi, Deepthy
Subject: [PATCH] Media controller: Define media_entity_init() and
media_entity_cleanup() conditionally
From: Vaibhav Hiremath hvaib...@ti.com
Defines the two functions only when CONFIG_MEDIA_CONTROLLER
is enabled.
[Hiremath, Vaibhav] Deepthy,
You may want to mention about build failure without MEDIA_CONTROLLER option
being enabled, especially if any sensor driver is being used between MC and
non-MC framework compatible devices.
For example, OMAP3 and AM3517, where TVP5146 is being used but OMAP3 is based
on MC framework and AM3517 is based on simple sub-dev based interface.
[Deepthy Ravi] Ok. I will change description to include that.
Thanks,
Vaibhav
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
include/media/media-entity.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index cd8bca6..c90916e 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -121,9 +121,18 @@ struct media_entity_graph {
int top;
};
+#ifdef CONFIG_MEDIA_CONTROLLER
int media_entity_init(struct media_entity *entity, u16 num_pads,
struct media_pad *pads, u16 extra_links);
void media_entity_cleanup(struct media_entity *entity);
+#else
+static inline int media_entity_init(struct media_entity *entity, u16
num_pads,
+ struct media_pad *pads, u16 extra_links)
+{
+ return 0;
+}
+static inline void media_entity_cleanup(struct media_entity *entity) {}
+#endif
int media_entity_create_link(struct media_entity *source, u16 source_pad,
struct media_entity *sink, u16 sink_pad, u32 flags);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] omap: iovmm: remove unused functionality
Hi Ohad, From: ext Ohad Ben-Cohen o...@wizery.com Subject: [PATCH 5/7] omap: iovmm: remove unused functionality Date: Thu, 18 Aug 2011 02:10:06 +0300 Remove unused functionality from OMAP's iovmm module. The intention is to eventually completely replace iovmm with the generic DMA-API, so new code that'd need this iovmm functionality will have to extend the DMA-API instead. Maybe it's better to remove the comments explaining unnecessary functions too. Now the function comparison table doesn't make sense From c42c675f62241099a10e4610640e6a60fb111f1f Mon Sep 17 00:00:00 2001 From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Thu, 18 Aug 2011 13:13:53 +0300 Subject: [PATCH 1/1] omap: iommu: remove obsolete comments Remove ones referring to non-existing functions. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- drivers/iommu/omap-iovmm.c | 36 +--- 1 files changed, 1 insertions(+), 35 deletions(-) diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c index 81b713a..2db655c 100644 --- a/drivers/iommu/omap-iovmm.c +++ b/drivers/iommu/omap-iovmm.c @@ -1,7 +1,7 @@ /* * omap iommu: simple virtual address space management * - * Copyright (C) 2008-2009 Nokia Corporation + * Copyright (C) 2008-2009, 2011 Nokia Corporation * * Written by Hiroshi DOYU hiroshi.d...@nokia.com * @@ -25,40 +25,6 @@ #include plat/iopgtable.h -/* - * A device driver needs to create address mappings between: - * - * - iommu/device address - * - physical address - * - mpu virtual address - * - * There are 4 possible patterns for them: - * - *|iova/ mapping iommu_ page - *| da pa va (d)-(p)-(v) functiontype - * --- - * 1 | c c c1 - 1 - 1_kmap() / _kunmap() s - * 2 | c c,a c1 - 1 - 1 _kmalloc()/ _kfree()s - * 3 | c d c1 - n - 1_vmap() / _vunmap() s - * 4 | c d,a c1 - n - 1 _vmalloc()/ _vfree()n* - * - * - * 'iova': device iommu virtual address - * 'da': alias of 'iova' - * 'pa': physical address - * 'va': mpu virtual address - * - * 'c':contiguous memory area - * 'd':discontiguous memory area - * 'a':anonymous memory allocation - * '()': optional feature - * - * 'n':a normal page(4KB) size is used. - * 's':multiple iommu superpage(16MB, 1MB, 64KB, 4KB) size is used. - * - * '*':not yet, but feasible. - */ - static struct kmem_cache *iovm_area_cachep; /* return total bytes of sg buffers */ -- 1.7.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: [PATCH 5/7] omap: iovmm: remove unused functionality
On Thu, Aug 18, 2011 at 1:19 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Maybe it's better to remove the comments explaining unnecessary functions too. Now the function comparison table doesn't make sense Sure, will do. From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Thu, 18 Aug 2011 13:13:53 +0300 Subject: [PATCH 1/1] omap: iommu: remove obsolete comments Remove ones referring to non-existing functions. I think it might be better to squash it with the original patch though - are you ok with it ? Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe 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] mfd: omap-usb-host: Make TLL mode work again
This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- Against v3.1-rc2; tested against linux-next as of 20110817 as well. This probably needs to go to -stable as well. The original code by me worked fine but this was broken during the code reorganization Keshava did. drivers/mfd/omap-usb-host.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6/drivers/mfd/omap-usb-host.c === --- linux-2.6.orig/drivers/mfd/omap-usb-host.c +++ linux-2.6/drivers/mfd/omap-usb-host.c @@ -676,7 +676,6 @@ static void usbhs_omap_tll_init(struct d | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF | OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE); - reg |= (1 (i + 1)); } else continue; -- To unsubscribe from this list: send the line unsubscribe 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] MAINTAINERS: add myself as co-maintainer for OMAP USB
I'd like to help co-maintain OMAP USB support. I've helped out in the past when Felipe was away and would like make it official. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Greg Kroah-Hartman gre...@suse.de --- MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/MAINTAINERS === --- linux-2.6.orig/MAINTAINERS +++ linux-2.6/MAINTAINERS @@ -4326,6 +4326,7 @@ F:include/linux/isicom.h MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER M: Felipe Balbi ba...@ti.com +M: Anand Gadiyar gadi...@ti.com L: linux-...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git S: Maintained @@ -4656,6 +4657,7 @@ F:drivers/media/video/omap3isp/* OMAP USB SUPPORT M: Felipe Balbi ba...@ti.com +M: Anand Gadiyar gadi...@ti.com L: linux-...@vger.kernel.org L: linux-omap@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git -- To unsubscribe from this list: send the line unsubscribe 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/7] omap: iommu: remove unused exported API
Hi Ohad,
Just small question inlined
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: [PATCH 6/7] omap: iommu: remove unused exported API
Date: Thu, 18 Aug 2011 02:10:07 +0300
Remove unused public APIs from OMAP's iommu driver.
IOMMU functionality should be exposed only via the generic IOMMU API;
this way drivers stay generic, and different IOMMU drivers
don't need to duplicate similar functionalities.
The rest of the API still exposed by OMAP's iommu will be evaluated
and eventually either added to the generic IOMMU API (if relevant),
or completely removed.
The intention is that OMAP's iommu driver will eventually not expose
any public API.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h |3 --
drivers/iommu/omap-iommu.c | 59
---
2 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 961b64f..eed5bdc 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -153,12 +153,9 @@ struct iommu_platform_data {
extern u32 iommu_arch_version(void);
extern void iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
-extern void iommu_set_twl(struct iommu *obj, bool on);
This function was introduced by Hari Kanigeri for some OMAP4 case,
which is only using TLB, not H/W table walk.
-extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end);
-extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
This function was introduced by David Cohen to specify the available
ISP virtual address range.
Both requirements were quite reasonable at that time. Not necessary anymore?
extern int iommu_set_isr(const char *name,
int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
void *priv),
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 7280e5b..d6b77c4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -357,26 +357,6 @@ static void flush_iotlb_page(struct iommu *obj, u32 da)
}
/**
- * flush_iotlb_range - Clear an iommu tlb entries
- * @obj: target iommu
- * @start: iommu device virtual address(start)
- * @end: iommu device virtual address(end)
- *
- * Clear an iommu tlb entry which includes 'da' address.
- **/
-void flush_iotlb_range(struct iommu *obj, u32 start, u32 end)
-{
- u32 da = start;
-
- while (da end) {
- flush_iotlb_page(obj, da);
- /* FIXME: Optimize for multiple page size */
- da += IOPTE_SIZE;
- }
-}
-EXPORT_SYMBOL_GPL(flush_iotlb_range);
-
-/**
* flush_iotlb_all - Clear all iommu tlb entries
* @obj: target iommu
**/
@@ -395,23 +375,6 @@ static void flush_iotlb_all(struct iommu *obj)
clk_disable(obj-clk);
}
-/**
- * iommu_set_twl - enable/disable table walking logic
- * @obj: target iommu
- * @on: enable/disable
- *
- * Function used to enable/disable TWL. If one wants to work
- * exclusively with locked TLB entries and receive notifications
- * for TLB miss then call this function to disable TWL.
- */
-void iommu_set_twl(struct iommu *obj, bool on)
-{
- clk_enable(obj-clk);
- arch_iommu-set_twl(obj, on);
- clk_disable(obj-clk);
-}
-EXPORT_SYMBOL_GPL(iommu_set_twl);
-
#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
@@ -848,28 +811,6 @@ static int device_match_by_alias(struct device *dev,
void *data)
}
/**
- * iommu_set_da_range - Set a valid device address range
- * @obj: target iommu
- * @startStart of valid range
- * @end End of valid range
- **/
-int iommu_set_da_range(struct iommu *obj, u32 start, u32 end)
-{
-
- if (!obj)
- return -EFAULT;
-
- if (end start || !PAGE_ALIGN(start | end))
- return -EINVAL;
-
- obj-da_start = start;
- obj-da_end = end;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(iommu_set_da_range);
-
-/**
* omap_find_iommu_device() - find an omap iommu device by name
* @name:name of the iommu device
*
--
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: [PATCH 0/7] omap: iommu migration, relocation and cleanups
Hi Ohad, From: ext Laurent Pinchart laurent.pinch...@ideasonboard.com Subject: Re: [PATCH 0/7] omap: iommu migration, relocation and cleanups Date: Thu, 18 Aug 2011 11:12:55 +0200 Hi Ohad, On Thursday 18 August 2011 01:10:01 Ohad Ben-Cohen wrote: 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. Good migration path! Changes: 1. Migrate iommu, iovmm and omap3isp in a single patch for bisectibility sake. 2. Apply Laurent Pinchart's comments (thanks Laurent!) You're welcome. 3. Rebase to 3.1-rc2 For the OMAP3 ISP driver changes, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com For the rest of omap iommu/iovmm patches, they look good: Acked-by: Hiroshi DOYU hiroshi.d...@nokia.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
[RFC PATCH 0/6 V2] OMAP4: Temperature sensor driver
Hello, The rfc patch series for the on die temperature sensor driver. I need feedback on the overall structure of the driver. The rfc patch set has the device file, omap4 on die temperature sensor hwmon driver. hwmod, clk support. The patch set compiles on top of LO tree Master branch. This patch series is tested for boot-up on OMAP4460. The temperature reading and the interrupts generation on crossing the temperature thresholds also tested. V2: (1) Fixed comments on return values in the driver. (2) Moved the TEMPSOFF setting code to the activate/deactivate hooks. (3) Used idr to pass for the device id. Benoit Cousson (1): OMAP4: Hwmod: OMAP temperature sensor Keerthy (5): OMAP4: Clock: Associate clocks for OMAP temperature sensor OMAP4: Adding the temperature sensor register set bit fields OMAP4460: Temperature sensor data OMAP4: Temperature sensor device support hwmon: OMAP4: On die temperature sensor driver Documentation/hwmon/omap_temp_sensor | 27 + arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/clock44xx_data.c |2 +- .../include/mach/ctrl_module_core_44xx.h | 70 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61 ++ arch/arm/mach-omap2/temp_sensor4460_data.c | 63 ++ arch/arm/mach-omap2/temp_sensor_device.c | 178 arch/arm/plat-omap/Kconfig | 12 + .../plat-omap/include/plat/temperature_sensor.h| 89 ++ drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile |1 + drivers/hwmon/omap_temp_sensor.c | 918 12 files changed, 1420 insertions(+), 15 deletions(-) create mode 100644 Documentation/hwmon/omap_temp_sensor create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h create mode 100644 drivers/hwmon/omap_temp_sensor.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/6 V2] OMAP4: Clock: Associate clocks for OMAP temperature sensor
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as the functional clock for the temperature sensor in clkdev table,
so a clk_set_rate() in the driver would have the effect of changing the
temperature sensor clock rate indirectly.
Reviewd-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
Cc: rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..4a788f4 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3187,7 +3187,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, bandgap_fclk, bandgap_fclk,
CK_443X),
CLK(NULL, bandgap_ts_fclk, bandgap_ts_fclk,
CK_446X),
CLK(NULL, des3des_fck, des3des_fck,
CK_443X),
- CLK(NULL, div_ts_ck,div_ts_ck,
CK_446X),
+ CLK(omap_temp_sensor.0, fck, div_ts_ck,
CK_446X),
CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck,
CK_443X),
CLK(NULL, dmic_fck, dmic_fck,
CK_443X),
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/6 V2] OMAP4: Adding the temperature sensor register set bit fields
OMAP4460 specific temperature sensor register bit fields are added. Signed-off-by: Keerthy j-keer...@ti.com Cc: t...@atomide.com --- .../include/mach/ctrl_module_core_44xx.h | 70 1 files changed, 57 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h index 2f7ac70..725c1e1 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h @@ -256,19 +256,63 @@ #define OMAP4_LDOSRAMCORE_ACTMODE_VSET_OUT_SHIFT 0 #define OMAP4_LDOSRAMCORE_ACTMODE_VSET_OUT_MASK(0x1f 0) -/* TEMP_SENSOR */ -#define OMAP4_BGAP_TEMPSOFF_SHIFT 12 -#define OMAP4_BGAP_TEMPSOFF_MASK (1 12) -#define OMAP4_BGAP_TSHUT_SHIFT 11 -#define OMAP4_BGAP_TSHUT_MASK (1 11) -#define OMAP4_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 -#define OMAP4_BGAP_TEMP_SENSOR_CONTCONV_MASK (1 10) -#define OMAP4_BGAP_TEMP_SENSOR_SOC_SHIFT 9 -#define OMAP4_BGAP_TEMP_SENSOR_SOC_MASK(1 9) -#define OMAP4_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 -#define OMAP4_BGAP_TEMP_SENSOR_EOCZ_MASK (1 8) -#define OMAP4_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 -#define OMAP4_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1 0) /* DPLL_NWELL_TRIM_0 */ #define OMAP4_DPLL_ABE_NWELL_TRIM_MUX_CTRL_SHIFT 29 -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/6 V2] OMAP4460: Temperature sensor data
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit fields corresponding to OMAP4460 on die sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/temp_sensor4460_data.c | 63 ++
.../plat-omap/include/plat/temperature_sensor.h| 89
3 files changed, 153 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fb02937..2d5d981 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -86,7 +86,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o
prm2xxx_3xxx.o \
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
prminst44xx.o vc44xx_data.o \
- vp44xx_data.o
+ vp44xx_data.o temp_sensor4460_data.o
# OMAP voltage domains
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
b/arch/arm/mach-omap2/temp_sensor4460_data.c
new file mode 100644
index 000..294963d
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
@@ -0,0 +1,63 @@
+/*
+ * OMAP4460 on die Temperature sensor data file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/slab.h
+#include control.h
+#include plat/temperature_sensor.h
+
+/*
+ * OMAP4460 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4460_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4460_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask= OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP4460_MASK_HOT_MASK,
+ .mask_cold_mask = OMAP4460_MASK_COLD_MASK,
+
+ .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+
+ .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
+ .counter_mask = OMAP4460_COUNTER_MASK,
+
+ .bgap_threshold = OMAP4460_BGAP_THRESHOLD_OFFSET,
+ .threshold_thot_mask= OMAP4460_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP4460_T_COLD_MASK,
+
+ .thsut_threshold= OMAP4460_BGAP_TSHUT_OFFSET,
+ .tshut_hot_mask = OMAP4460_TSHUT_HOT_MASK,
+ .tshut_cold_mask= OMAP4460_TSHUT_COLD_MASK,
+
+ .bgap_status= OMAP4460_BGAP_STATUS_OFFSET,
+ .status_clean_stop_mask = OMAP4460_CLEAN_STOP_MASK,
+ .status_bgap_alert_mask = OMAP4460_BGAP_ALERT_MASK,
+ .status_hot_mask= OMAP4460_HOT_FLAG_MASK,
+ .status_cold_mask = OMAP4460_COLD_FLAG_MASK,
+
+ .bgap_efuse = OMAP4460_FUSE_OPP_BGAP,
+};
diff --git a/arch/arm/plat-omap/include/plat/temperature_sensor.h
b/arch/arm/plat-omap/include/plat/temperature_sensor.h
new file mode 100644
index 000..a3186f9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/temperature_sensor.h
@@ -0,0 +1,89 @@
+/*
+ * OMAP Temperature sensor header file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ *
+ * This program is free software; you can
[RFC PATCH 5/6 V2] OMAP4: Temperature sensor device support
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/temp_sensor_device.c | 178 ++
arch/arm/plat-omap/Kconfig | 12 ++
3 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2d5d981..5812fb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
+obj-$(CONFIG_OMAP_TEMP_SENSOR) += temp_sensor_device.o
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
# SMP support ONLY available for OMAP4
diff --git a/arch/arm/mach-omap2/temp_sensor_device.c
b/arch/arm/mach-omap2/temp_sensor_device.c
new file mode 100644
index 000..083f267
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor_device.c
@@ -0,0 +1,178 @@
+/*
+ * OMAP on die Temperature sensor device file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/delay.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/mutex.h
+#include linux/idr.h
+#include plat/omap_device.h
+#include pm.h
+#include plat/temperature_sensor.h
+
+
+int omap_temp_sensor_device_idle(struct omap_device *od)
+{
+ struct omap_temp_sensor_registers *registers;
+ struct resource*mem;
+ void__iomem *phy_base;
+ unsigned long timeout;
+ u32 ret = 0, temp;
+
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, no mem resource\n);
+ ret = -EINVAL;
+ goto plat_res_err;
+ }
+
+ phy_base = ioremap(mem-start, resource_size(mem));
+
+ if (!strcmp(od-hwmods[0]-dev_attr, mpu))
+ registers = omap_mpu_temp_sensor_registers;
+
+ temp = __raw_readl(phy_base + registers-temp_sensor_ctrl);
+ temp |= registers-bgap_tempsoff_mask;
+
+ /* BGAP_TEMPSOFF should be set to 1 before gating clock */
+ __raw_writel(temp, phy_base + registers-temp_sensor_ctrl);
+ temp = __raw_readl(phy_base + registers-bgap_status);
+ timeout = jiffies + msecs_to_jiffies(5);
+
+ /* wait till the clean stop bit is set or till the timeout expires */
+ while (!(temp | registers-status_clean_stop_mask)
+ !(time_after(jiffies, timeout))) {
+ temp = __raw_readl(phy_base + registers-bgap_status);
+ usleep_range(500, 2000);
+ }
+
+ if (time_after(jiffies, timeout))
+ dev_err(od-pdev.dev, Clean stop bit not set\n);
+
+ ret = omap_device_idle_hwmods(od);
+
+plat_res_err:
+ return ret;
+}
+
+int omap_temp_sensor_device_activate(struct omap_device *od)
+{
+ struct omap_temp_sensor_registers *registers;
+ struct resource*mem;
+ void__iomem *phy_base;
+ u32 ret = 0, temp;
+
+ ret = omap_device_enable_hwmods(od);
+ if (ret 0)
+ return ret;
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, no mem resource\n);
+ return -EINVAL;
+ }
+
+ phy_base = ioremap(mem-start, resource_size(mem));
+
+ if (!strcmp(od-hwmods[0]-dev_attr, mpu))
+ registers = omap_mpu_temp_sensor_registers;
+
+ temp = __raw_readl(phy_base + registers-temp_sensor_ctrl);
+ temp = ~(registers-bgap_tempsoff_mask);
+ /* BGAP_TEMPSOFF should be reset to 0 */
+ __raw_writel(temp,
+ phy_base + registers-temp_sensor_ctrl);
+
+ return 0;
+}
+
+static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
+ {
+ .deactivate_func = omap_temp_sensor_device_idle,
+ .activate_func =
[RFC PATCH 4/6 V2] OMAP4: Hwmod: OMAP temperature sensor
From: Benoit Cousson b-cous...@ti.com
OMAP4460 temperature sensor hwmod cannot be auto generated
since it is part of ctrl module. Hence populating the
necessary hwmod info manually.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
Cc: b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61
1 files changed, 61 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..28bf6d3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -29,6 +29,7 @@
#include plat/mcbsp.h
#include plat/mmc.h
#include plat/i2c.h
+#include plat/temperature_sensor.h
#include omap_hwmod_common_data.h
@@ -832,6 +833,63 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
};
/*
+ * 'temperature_sensor' class
+ * temperature sensor module inside the bandgap / control module
+ */
+
+static struct omap_hwmod_class omap44xx_temperature_sensor_hwmod_class = {
+ .name = temperature_sensor,
+};
+
+static struct omap_hwmod_irq_info omap44xx_temperature_sensor_irqs[] = {
+ { .name = thermal_alert, .irq = 126 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_temperature_sensor_addrs[] = {
+ {
+ .pa_start = 0x4a00232c,
+ .pa_end = 0x4a00238b,
+ },
+};
+
+static struct omap_hwmod omap44xx_temperature_sensor_hwmod;
+/* l4_cfg - ctrl_module_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__temperature_sensor = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_temperature_sensor_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_temperature_sensor_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* ctrl_module_core slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_temperature_sensor_slaves[] = {
+ omap44xx_l4_cfg__temperature_sensor,
+};
+
+/* temperature sensor dev_attr */
+static struct omap_temp_sensor_dev_attr temp_sensor_dev_attr = {
+ .name = mpu,
+};
+
+static struct omap_hwmod omap44xx_temperature_sensor_hwmod = {
+ .name = temperature_sensor_mpu,
+ .class = omap44xx_temperature_sensor_hwmod_class,
+ .mpu_irqs = omap44xx_temperature_sensor_irqs,
+ .main_clk = bandgap_ts_fclk,
+ .slaves = omap44xx_temperature_sensor_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_temperature_sensor_slaves),
+ .clkdm_name = l4_wkup_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_WKUP_BANDGAP_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = temp_sensor_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
* 'bandgap' class
* bangap reference for ldo regulators
*/
@@ -5469,6 +5527,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_timer10_hwmod,
omap44xx_timer11_hwmod,
+ /* temperature sensor hwmod */
+ omap44xx_temperature_sensor_hwmod,
+
/* uart class */
omap44xx_uart1_hwmod,
omap44xx_uart2_hwmod,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6 V2] hwmon: OMAP4: On die temperature sensor driver
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 --- Documentation/hwmon/omap_temp_sensor | 27 + drivers/hwmon/Kconfig| 11 + drivers/hwmon/Makefile |1 + drivers/hwmon/omap_temp_sensor.c | 918 ++ 4 files changed, 957 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 + +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). + +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..586a361 --- /dev/null +++ b/drivers/hwmon/omap_temp_sensor.c @@ -0,0 +1,918 @@ +/* + * 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., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/interrupt.h +#include linux/clk.h +#include linux/io.h +#include linux/slab.h +#include linux/init.h +#include plat/omap_device.h +#include linux/kernel.h +#include linux/device.h +#include linux/jiffies.h +#include linux/hwmon.h +#include linux/hwmon-sysfs.h +#include linux/stddef.h +#include linux/sysfs.h +#include linux/err.h +#include linux/types.h +#include linux/mutex.h +#include linux/pm_runtime.h +#include linux/delay.h
Re: [PATCH] MAINTAINERS: add myself as co-maintainer for OMAP USB
Hi, On Thu, Aug 18, 2011 at 04:18:24PM +0530, Anand Gadiyar wrote: I'd like to help co-maintain OMAP USB support. I've helped out in the past when Felipe was away and would like make it official. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Greg Kroah-Hartman gre...@suse.de --- MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/MAINTAINERS === --- linux-2.6.orig/MAINTAINERS +++ linux-2.6/MAINTAINERS @@ -4326,6 +4326,7 @@ F: include/linux/isicom.h MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER M: Felipe Balbi ba...@ti.com +M: Anand Gadiyar gadi...@ti.com L: linux-...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git S: Maintained @@ -4656,6 +4657,7 @@ F: drivers/media/video/omap3isp/* OMAP USB SUPPORT M: Felipe Balbi ba...@ti.com +M: Anand Gadiyar gadi...@ti.com L: linux-...@vger.kernel.org L: linux-omap@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git I'm concerned you will just vanish again. Last time we tried, I even dropped a mail to Greg explaining how we would work and you just vanished. I'm not confortable accepting this patch now. Let's first see how this will play off, so start helping reviewing the patches that are pending. -- balbi signature.asc Description: Digital signature
Re: [PATCH 6/7] omap: iommu: remove unused exported API
Hi Hiroshi, On Thu, Aug 18, 2011 at 1:49 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: -extern void iommu_set_twl(struct iommu *obj, bool on); This function was introduced by Hari Kanigeri for some OMAP4 case, which is only using TLB, not H/W table walk. We discussed that internally, and concluded it's not needed anymore. I still kept the underlying plumbing mechanism, just in case it'd still be needed for some hw quirks in the future, but removed the interface (in case a future hw revision will seem to need it, it would probably make more sense to invoke the relevant mechanism from the underlying layers rather than from a higher layer). -extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end); This function was introduced by David Cohen to specify the available ISP virtual address range. Not sure if David or anyone is using this, but if someone is, it must be out-of-tree. In that case, even if it is needed, adding a mainline user for this function at this point will most likely not be accepted anymore, and instead, one will be suggested to use (and extend as necessary) the DMA-API. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe 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] MAINTAINERS: add myself as co-maintainer for OMAP USB
Balbi, Felipe wrote: Hi, On Thu, Aug 18, 2011 at 04:18:24PM +0530, Anand Gadiyar wrote: I'd like to help co-maintain OMAP USB support. I've helped out in the past when Felipe was away and would like make it official. ... I'm concerned you will just vanish again. Last time we tried, I even dropped a mail to Greg explaining how we would work and you just vanished. I'm not confortable accepting this patch now. Let's first see how this will play off, so start helping reviewing the patches that are pending. It's happened with you too - and I've had to step in for you when you disappeared due to product pressures. I'm back now and for sure I'll help with reviews. But it would be nice if you'd ack this one. Okay with me if you'd like to wait and see some actual work, but I think I've been active enough in the past - that ought to count for something. - Anand -- To unsubscribe from this list: send the line unsubscribe 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] MAINTAINERS: add myself as co-maintainer for OMAP USB
Hi, On Thu, Aug 18, 2011 at 04:31:34PM +0530, Gadiyar, Anand wrote: Balbi, Felipe wrote: Hi, On Thu, Aug 18, 2011 at 04:18:24PM +0530, Anand Gadiyar wrote: I'd like to help co-maintain OMAP USB support. I've helped out in the past when Felipe was away and would like make it official. ... I'm concerned you will just vanish again. Last time we tried, I even dropped a mail to Greg explaining how we would work and you just vanished. I'm not confortable accepting this patch now. Let's first see how this will play off, so start helping reviewing the patches that are pending. It's happened with you too - and I've had to step in for you when you disappeared due to product pressures. I'm back now and for sure I'll help with reviews. But it would be nice if you'd ack this one. Okay with me if you'd like to wait and see some actual work, but I think I've been active enough in the past - that ought to count for something. you sure have been active in the past, but the fact that when we discussed with Greg you just vanished with no reason was a bit worrying to me. So, let's clean up the pending patches and by the merge window we'll decide. This patch will probably be there. -- balbi signature.asc Description: Digital signature
Re: [PATCH] mfd: omap-usb-host: Make TLL mode work again
On Thu, Aug 18, 2011 at 4:14 PM, Anand Gadiyar gadi...@ti.com wrote: This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- Against v3.1-rc2; tested against linux-next as of 20110817 as well. This probably needs to go to -stable as well. The original code by me worked fine but this was broken during the code reorganization Keshava did. drivers/mfd/omap-usb-host.c | 1 - 1 file changed, 1 deletion(-) Index: linux-2.6/drivers/mfd/omap-usb-host.c === --- linux-2.6.orig/drivers/mfd/omap-usb-host.c +++ linux-2.6/drivers/mfd/omap-usb-host.c @@ -676,7 +676,6 @@ static void usbhs_omap_tll_init(struct d | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF | OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE); - reg |= (1 (i + 1)); } else continue; Samuel Ortiz and balbi please ack this patch I am going to re-base runtime pm patches on top of this patch. Regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: omap-usb-host: Make TLL mode work again
HI, On Thu, Aug 18, 2011 at 04:52:22PM +0530, Munegowda, Keshava wrote: On Thu, Aug 18, 2011 at 4:14 PM, Anand Gadiyar gadi...@ti.com wrote: This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Sam, you can apply this one: Acked-by: Felipe Balbi ba...@ti.com But I think it needs to be resent with Cc: sta...@kernel.org -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 3/6 V2] OMAP4460: Temperature sensor data
Hi,
On Thu, Aug 18, 2011 at 04:22:12PM +0530, Keerthy wrote:
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit fields corresponding to OMAP4460 on die sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/temp_sensor4460_data.c | 63 ++
.../plat-omap/include/plat/temperature_sensor.h| 89
3 files changed, 153 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fb02937..2d5d981 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -86,7 +86,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= prcm.o cm2xxx_3xxx.o
prm2xxx_3xxx.o \
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
prminst44xx.o vc44xx_data.o \
-vp44xx_data.o
+vp44xx_data.o temp_sensor4460_data.o
# OMAP voltage domains
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
b/arch/arm/mach-omap2/temp_sensor4460_data.c
new file mode 100644
index 000..294963d
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
@@ -0,0 +1,63 @@
+/*
+ * OMAP4460 on die Temperature sensor data file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/slab.h
+#include control.h
+#include plat/temperature_sensor.h
+
+/*
+ * OMAP4460 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4460_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4460_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask= OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP4460_MASK_HOT_MASK,
+ .mask_cold_mask = OMAP4460_MASK_COLD_MASK,
+
+ .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+
+ .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
+ .counter_mask = OMAP4460_COUNTER_MASK,
+
+ .bgap_threshold = OMAP4460_BGAP_THRESHOLD_OFFSET,
+ .threshold_thot_mask= OMAP4460_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP4460_T_COLD_MASK,
+
+ .thsut_threshold= OMAP4460_BGAP_TSHUT_OFFSET,
+ .tshut_hot_mask = OMAP4460_TSHUT_HOT_MASK,
+ .tshut_cold_mask= OMAP4460_TSHUT_COLD_MASK,
+
+ .bgap_status= OMAP4460_BGAP_STATUS_OFFSET,
+ .status_clean_stop_mask = OMAP4460_CLEAN_STOP_MASK,
+ .status_bgap_alert_mask = OMAP4460_BGAP_ALERT_MASK,
+ .status_hot_mask= OMAP4460_HOT_FLAG_MASK,
+ .status_cold_mask = OMAP4460_COLD_FLAG_MASK,
+
+ .bgap_efuse = OMAP4460_FUSE_OPP_BGAP,
+};
diff --git a/arch/arm/plat-omap/include/plat/temperature_sensor.h
b/arch/arm/plat-omap/include/plat/temperature_sensor.h
new file mode 100644
index 000..a3186f9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/temperature_sensor.h
@@ -0,0 +1,89 @@
+/*
+ * OMAP Temperature sensor header file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated
Re: [RFC PATCH 6/6 V2] hwmon: OMAP4: On die temperature sensor driver
Hi, On Thu, Aug 18, 2011 at 04:22:15PM +0530, 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 --- Documentation/hwmon/omap_temp_sensor | 27 + drivers/hwmon/Kconfig| 11 + drivers/hwmon/Makefile |1 + drivers/hwmon/omap_temp_sensor.c | 918 ++ 4 files changed, 957 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 + +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). + +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..586a361 --- /dev/null +++ b/drivers/hwmon/omap_temp_sensor.c @@ -0,0 +1,918 @@ +/* + * 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., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/interrupt.h +#include linux/clk.h +#include linux/io.h +#include linux/slab.h +#include linux/init.h +#include plat/omap_device.h +#include linux/kernel.h +#include linux/device.h +#include linux/jiffies.h +#include
RE: [PATCH] mfd: omap-usb-host: Make TLL mode work again
Balbi, Felipe wrote: HI, On Thu, Aug 18, 2011 at 04:52:22PM +0530, Munegowda, Keshava wrote: On Thu, Aug 18, 2011 at 4:14 PM, Anand Gadiyar gadi...@ti.com wrote: This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Sam, you can apply this one: Acked-by: Felipe Balbi ba...@ti.com But I think it needs to be resent with Cc: sta...@kernel.org I'm trying to avoid Cc: sta...@kernel.org since RMK complained about this on the Linux ARM kernel list. [1] - Anand [1] http://marc.info/?l=linux-arm-kernelm=131107297012093w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: musb: remove unneeded init code
Hi,
On Thu, Aug 18, 2011 at 02:42:44PM +0530, Ajay Kumar Gupta wrote:
The .power and .mode parameter of 'musb_plat' is also now set dynamically
in usb_musb_init() so remove them.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tony, can you pick this up for next ?
---
arch/arm/mach-omap2/usb-musb.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..de48106 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -41,21 +41,8 @@ static struct musb_hdrc_config musb_config = {
};
static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_MUSB_OTG
- .mode = MUSB_OTG,
-#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
- .mode = MUSB_HOST,
-#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
- .mode = MUSB_PERIPHERAL,
-#endif
- /* .clock is set dynamically */
+ /* .clock, .mode and .power is set dynamically */
.config = musb_config,
-
- /* REVISIT charge pump on TWL4030 can supply up to
- * 100 mA ... but this value is board-specific, like
- * mode, and should be passed to usb_musb_init().
- */
- .power = 50, /* up to 100 mA */
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
--
1.6.2.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/7] omap: iovmm: remove unused functionality
From: ext Ohad Ben-Cohen o...@wizery.com Subject: Re: [PATCH 5/7] omap: iovmm: remove unused functionality Date: Thu, 18 Aug 2011 13:23:44 +0300 On Thu, Aug 18, 2011 at 1:19 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: Maybe it's better to remove the comments explaining unnecessary functions too. Now the function comparison table doesn't make sense Sure, will do. From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Thu, 18 Aug 2011 13:13:53 +0300 Subject: [PATCH 1/1] omap: iommu: remove obsolete comments Remove ones referring to non-existing functions. I think it might be better to squash it with the original patch though - are you ok with it ? Sure. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] omap: iommu: migrate to the generic IOMMU API
On Thursday 18 August 2011, Laurent Pinchart wrote:
+static int omap_iommu_domain_init(struct iommu_domain *domain)
+{
+ struct omap_iommu_domain *omap_domain;
+
+ omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL);
+ if (!omap_domain) {
+ pr_err(kzalloc failed\n);
+ goto out;
You can directly return -ENOMEM here, and remove the out: label.
Risking to get into bike-shedding here, I would comment that the current
code is actually better. I would not mix the two methods of error handling
in one function. If you use goto labels, better use them consistenly and
have only one 'return' statement.
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 2/7] omap: iommu/iovmm: move to dedicated iommu folder
On Thursday 18 August 2011, Ohad Ben-Cohen wrote:
arch/arm/plat-omap/Kconfig | 14 --
arch/arm/plat-omap/Makefile|2 --
arch/arm/plat-omap/{ = include/plat}/iopgtable.h |0
drivers/iommu/Kconfig | 18 ++
drivers/iommu/Makefile |3 +++
.../iommu/omap-iommu-debug.c |2 +-
.../iommu.c = drivers/iommu/omap-iommu.c |2 +-
.../iovmm.c = drivers/iommu/omap-iovmm.c |2 +-
drivers/media/video/Kconfig|2 +-
Do you need the header file to be globally visible?
If not, I think it would be better to move it to the iommu directory along with
the
files using it.
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/7] omap: iommu: remove unused exported API
Hi Ohad, On Thu, Aug 18, 2011 at 2:01 PM, Ohad Ben-Cohen o...@wizery.com wrote: Hi Hiroshi, On Thu, Aug 18, 2011 at 1:49 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote: -extern void iommu_set_twl(struct iommu *obj, bool on); This function was introduced by Hari Kanigeri for some OMAP4 case, which is only using TLB, not H/W table walk. We discussed that internally, and concluded it's not needed anymore. I still kept the underlying plumbing mechanism, just in case it'd still be needed for some hw quirks in the future, but removed the interface (in case a future hw revision will seem to need it, it would probably make more sense to invoke the relevant mechanism from the underlying layers rather than from a higher layer). -extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end); This function was introduced by David Cohen to specify the available ISP virtual address range. This function wasn't actually introduced by me, but I remember to refer it when I was discussing to not define address 0x0 as valid in da range by default (unless intentionally specified by client). Not sure if David or anyone is using this, but if someone is, it must be out-of-tree. I am fine to remove it. Br, David In that case, even if it is needed, adding a mainline user for this function at this point will most likely not be accepted anymore, and instead, one will be suggested to use (and extend as necessary) the DMA-API. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe 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 6/7] omap: iommu: remove unused exported API
Hi David, On Thu, Aug 18, 2011 at 4:40 PM, David Cohen daco...@gmail.com wrote: Not sure if David or anyone is using this, but if someone is, it must be out-of-tree. I am fine to remove it. OK, thanks for confirming! Ohad. -- To unsubscribe from this list: send the line unsubscribe 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/7] omap: iommu/iovmm: move to dedicated iommu folder
On Thu, Aug 18, 2011 at 4:38 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 18 August 2011, Ohad Ben-Cohen wrote:
arch/arm/plat-omap/Kconfig | 14 --
arch/arm/plat-omap/Makefile | 2 --
arch/arm/plat-omap/{ = include/plat}/iopgtable.h | 0
drivers/iommu/Kconfig | 18 ++
drivers/iommu/Makefile | 3 +++
.../iommu/omap-iommu-debug.c | 2 +-
.../iommu.c = drivers/iommu/omap-iommu.c | 2 +-
.../iovmm.c = drivers/iommu/omap-iovmm.c | 2 +-
drivers/media/video/Kconfig | 2 +-
Do you need the header file to be globally visible?
Yeah; Unfortunately omap3isp is not yet completely decoupled from
omap's iommu, so it needs it.
Once the generic DMA-API will settle in, we will completely decouple
omap3isp and then will be able to move this header file into
drivers/iommu/, and remove omap-iovmm.c.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
DSS : DSI checksum error
Hi, Working DSS Panel driver. Sometime I am getting checksum error from DSI when framebuffers are sent to panel via DSI. omapdss DSI error: ACK with ERROR (0x400): Wanted to know if some one has encounter similar error. When / what can cause this error? Regards, Sudipta -- To unsubscribe from this list: send the line unsubscribe 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] MAINTAINERS: add myself as co-maintainer for OMAP USB
On Thu, Aug 18, 2011 at 04:18:24PM +0530, Anand Gadiyar wrote: I'd like to help co-maintain OMAP USB support. I've helped out in the past when Felipe was away and would like make it official. Traditionally people are asked to be a maintainer, or they volunteer to take over unmaintained projects. The only time I've see co-maintainers, is for larger projects, and then, it was a group decision. For something as small as musb, what is the benefit to anyone to have more than one maintainer? It seems to me that things are finally settling down with the recent musb mess, and I've been extremely happy with how Felipe has been handling things, and I honestly don't want to see that change at the moment. So I'd stick with what we have now, unless you feel there are issues with how Felipe is handling things, and if so, you should take that up directly with him and only if that doesn't work out, me. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe 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] MAINTAINERS: add myself as co-maintainer for OMAP USB
Greg KH wrote: On Thu, Aug 18, 2011 at 04:18:24PM +0530, Anand Gadiyar wrote: I'd like to help co-maintain OMAP USB support. I've helped out in the past when Felipe was away and would like make it official. Traditionally people are asked to be a maintainer, or they volunteer to take over unmaintained projects. The only time I've see co-maintainers, is for larger projects, and then, it was a group decision. I was asked, by Felipe among others, to help maintain OMAP USB support. The reason was to take some load off Felipe - I did not take this up at that time due to other product pressures. I do have more time on my hands now and would like to get back to being more active in the community - I felt helping maintain a driver was a good start. Within TI, I've worked on debugging the EHCI, OHCI and MUSB hardware for close to three years now and know more about the controllers on OMAP than anyone else. I've acquired boards which stress the several possible combinations of configurations possible and usually help out with testing those corner cases. For something as small as musb, what is the benefit to anyone to have more than one maintainer? It seems to me that things are finally settling down with the recent musb mess, and I've been extremely happy with how Felipe has been handling things, and I honestly don't want to see that change at the moment. It's less of MUSB, and more of the EHCI/OHCI - I don't believe Felipe's familiar enough with the hardware to look after that. Most contributions to the wrappers for those controllers have come from Ajay Gupta, Keshava and me. So I'd stick with what we have now, unless you feel there are issues with how Felipe is handling things, and if so, you should take that up directly with him and only if that doesn't work out, me. Nope - I'm happy with the way things are currently. So if Felipe no longer feels the need to offload some of his maintainership work, that's okay with me. - Anand -- To unsubscribe from this list: send the line unsubscribe 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/7] twl4030: finish threaded IRQ conversion
Hi, On Sat, Jul 09, 2011 at 05:09:00AM +0100, Mark Brown wrote: On Thu, Jun 30, 2011 at 12:51:03PM +0300, Felipe Balbi wrote: the following patches where boot-tested on beagle xM and everything seems fine. MMC root filesystem still mounts, /proc/interrupts looks like ps aux | grep irq shows our threads, etc. Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com It has been a long time and nobody complained. Samuel, can you take these patches in for 3.2 merge window ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] twl4030: finish threaded IRQ conversion
Hi, On Fri, Aug 19, 2011 at 12:36:15AM +0300, Felipe Balbi wrote: Hi, On Sat, Jul 09, 2011 at 05:09:00AM +0100, Mark Brown wrote: On Thu, Jun 30, 2011 at 12:51:03PM +0300, Felipe Balbi wrote: the following patches where boot-tested on beagle xM and everything seems fine. MMC root filesystem still mounts, /proc/interrupts looks like ps aux | grep irq shows our threads, etc. Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com It has been a long time and nobody complained. Samuel, can you take these patches in for 3.2 merge window ? if you want in pull request form, here it is: The following changes since commit 93ee7a9340d64f20295aacc3fb6a22b759323280: Linux 3.1-rc2 (2011-08-14 15:09:08 -0700) are available in the git repository at: master.kernel.org:/pub/scm/linux/kernel/git/balbi/usb.git irq Felipe Balbi (7): mfd: twl4030-irq: remove trailing whitespaces mfd: twl4030-irq: implement bus_lock/bus_sync_unlock methods mfd: twl4030-irq: drop the kthread mfd: twl4030-irq: drop mask_work mfd: twl4030-irq: drop edge_work mfd: twl4030-irq: set irq nested flag rtc: twl: move to threaded irq drivers/mfd/twl4030-irq.c | 342 + drivers/rtc/rtc-twl.c | 10 +-- 2 files changed, 132 insertions(+), 220 deletions(-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] mfd: omap-usb-host: Make TLL mode work again
On Thu, Aug 18, 2011 at 05:14:17PM +0530, Gadiyar, Anand wrote: Balbi, Felipe wrote: HI, On Thu, Aug 18, 2011 at 04:52:22PM +0530, Munegowda, Keshava wrote: On Thu, Aug 18, 2011 at 4:14 PM, Anand Gadiyar gadi...@ti.com wrote: This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Sam, you can apply this one: Acked-by: Felipe Balbi ba...@ti.com But I think it needs to be resent with Cc: sta...@kernel.org I'm trying to avoid Cc: sta...@kernel.org since RMK complained about this on the Linux ARM kernel list. [1] Why would he do that? You need to put the Cc: in the signed off by area, and all will be fine. If you just put it in your email, you will get an automated email from me telling you to go read Documentation/stable_kernel_rules.txt which tells you exactly how to do this properly. greg k-h -- To unsubscribe from this list: send the line unsubscribe 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/3] Add support for TI814X processor series
linux-arm-kernel-boun...@lists.infradead.org wrote on : Hello, Pedanekar, Hemant wrote on Thursday, August 04, 2011 11:14 PM: This patch set adds support for DM814x, C6A814x and AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM [...] Any comments on this patch set? Thanks. Hemant ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Hello, Can you please provide comments on these patches? 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: [RFC PATCH 6/6 V2] hwmon: OMAP4: On die temperature sensor driver
On Thu, Aug 18, 2011 at 06:52:15AM -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 High level review: - too much and too broad mutex locking. show functions should not need locks at all, set functions only while data is written into registers and into platform data. - driver is quite noisy. There should definitely not be any log messages if a set parameter is wrong. Show functions already return an error value to the user; a log message indicating the error again just creates noise. For one boolean set during probe (is_efuse_valid), each subsequent show results in a log message if it is false. Some errors result in multiple log messages. - Wrong use of EINVAL throughout the driver (EINVAL is Invalid Argument) - excessive ( ) - linear search through a sorted array is very expensive. Consider using a binary search. - temp_to_adc_conversion return code (error if negative) is not checked properly. I am sure there are other problems, but those are difficult to find with all the noise above. Guenter --- Documentation/hwmon/omap_temp_sensor | 27 + drivers/hwmon/Kconfig| 11 + drivers/hwmon/Makefile |1 + drivers/hwmon/omap_temp_sensor.c | 918 ++ 4 files changed, 957 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 + +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). + +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..586a361 --- /dev/null +++ b/drivers/hwmon/omap_temp_sensor.c @@ -0,0 +1,918 @@ +/* + * 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 + * + *
RE: [PATCH 2/3] TI814X: Add cpu type macros and detection support
Tony Lindgren wrote on Monday, August 15, 2011 8:47 PM: * Hemant Pedanekar hema...@ti.com [110804 20:39]: This patch adds cpu type, macros for identification of TI814X device. Note that following updates to common OMAP data structures are made: 1) struct omap_chip_id member 'oc' is updated to u32 from u16 as omap chip bitfield has exhausted 16 bits for CHIP_IS_XXX. 2) cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. We'll be getting rid of CHIP_IS usage and replace them with SoC specific lists. So we need to wait few days and then this patch will need to get updated a bit. Tony, Is there a branch which I can have a look at for changes being done? 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: [PATCH 3/3] TI814X: Create board support and enable build for TI8148 EVM
Tony Lindgren wrote on Monday, August 15, 2011 8:45 PM: * Hemant Pedanekar hema...@ti.com [110804 20:39]: This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. ... +MACHINE_START(TI8148EVM, ti8148evm) +/* Maintainer: Texas Instruments */ +.boot_params= 0x8100, +.map_io = ti8148_evm_map_io, +.init_early = ti8148_init_early, +.init_irq = ti81xx_init_irq, +.timer = omap3_timer, +.init_machine = ti8148_evm_init, +MACHINE_END Please just combine this with board-ti8168evm.c by adding the MACHINE_START there. It seems the files are identical otherwise? Tony, There will be more additions in respective board files such as I2C I/O expander data, mux handling depending upon the EVM (8168/8148), on board peripherals etc When these board files would deviate. What do you suggest to handle such? 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: [PATCH 0/3] Add support for TI814X processor series
linux-arm-kernel-boun...@lists.infradead.org wrote on : linux-arm-kernel-boun...@lists.infradead.org wrote on : Hello, Pedanekar, Hemant wrote on Thursday, August 04, 2011 11:14 PM: This patch set adds support for DM814x, C6A814x and AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM [...] Hello, Can you please provide comments on these patches? Thanks. Hemant Please disregard, I had missed Tony's comments. 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: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints
On Mon, 2011-08-08 at 23:31 +0200, Rafael J. Wysocki wrote: On Sunday, August 07, 2011, Mark Brown wrote: OK, so this does sound like there's probably a genuine issue on PCs due to limitations in the environment. Is it possible to expose these things to userspace in a way that's limited to the affected platforms? Well, in principle we could make it depend in CONFIG_ACPI or something like this, but I'm not sure that will be well-received. :-) Or the drivers for the particular buses in use? That does sound like a fair characterization for PCs. For embedded systems where we have a *much* better knowledge of the hardware we're running on you're just working with the basics of what the hardware needs to run - the hardware needs whatever it needs and no matter what you think of the quality of the hardware there's an expectation that the kernel is ging to be able to work. In the particular case in question, though, there's some freedom. Namely, the hardware will work for many different QoS constraints and it's not precisely known in principle and upfront which one would be optimal for a given workload. But are these tunings things that we can usefully represent in a generic API or are they specific parameters of the subsystem in question? I don't think anyone has suggested that having tuning for things where there are genuine choices is a good thing. As I've said it's not the fine tuning that I'm worried about, it's the specific mechanism that's being suggested. Being able to tune things in a way that's relevant to the device being tuned seems entirely sensible. Do you know any better mechanism consistent accross all devices? Please be specific. :-) Well, I'm suggesting that we shouldn't have a standard userspace API for this in the first place but should instead be doing things on the subsystem or driver level. I'm not sure we can sensibly do anything that works usefully for all devices. Realistically if you're in a position where you need to work at this very low level on an embedded device you can replace the entire firmware on the device. We don't want to end up in the situation where we've got kernel support for a device and the only way to get it to actually run sensibly is to install the silicon vendor's proprietary userspace, and we especially don't want to end up in the situation where that userspace is using standard and supported kernel interfaces to do its thing. Well, the wakelocks example shows clearly that preventing certain interfaces from being merged into mainline doesn't actually prevent people from using them in actual products. I claim it's way better if a vendor uses its proprietary user space with the mainline kernel than if that vendor patches the kernel and _then_ uses its proprietary user space with it. Your argumentation seems to suggest that we encourage the latter. We can't stop people doing questionable things out of tree but that doesn't mean lowering standards in mainline is a good idea. Keeping things out of tree creates a range of costs - the effort required to write the code and update for new kernel releases, support issues when the out of tree code causes problems and so on - and makes it clear to people using the code where the costs came from. If the code looks like it's standard code using standard interfaces much of that pressure goes away. This is similar to all the stuff that's going on in the ARM tree at the minute - there's nothing we can do to prevent vendors shipping random code of any quality in out of tree BSPs but we can set high standards for the quality of code we accept into mainline and let the resulting pressures push people towards mainline solutions. -- To unsubscribe from this list: send the line unsubscribe 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 resend] mfd: omap-usb-host: Make TLL mode work again
This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Acked-by: Felipe Balbi ba...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: sta...@kernel.org --- Resent with Felipe's ack and sta...@kernel.org in CC drivers/mfd/omap-usb-host.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6/drivers/mfd/omap-usb-host.c === --- linux-2.6.orig/drivers/mfd/omap-usb-host.c +++ linux-2.6/drivers/mfd/omap-usb-host.c @@ -676,7 +676,6 @@ static void usbhs_omap_tll_init(struct d | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF | OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE); - reg |= (1 (i + 1)); } else continue; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mfd: omap-usb-host: Make TLL mode work again
Greg KH wrote: On Thu, Aug 18, 2011 at 05:14:17PM +0530, Gadiyar, Anand wrote: Balbi, Felipe wrote: HI, On Thu, Aug 18, 2011 at 04:52:22PM +0530, Munegowda, Keshava wrote: On Thu, Aug 18, 2011 at 4:14 PM, Anand Gadiyar gadi...@ti.com wrote: This code section seems to have been accidentally copy pasted. It causes incorrect bits to be set up in the TLL_CHANNEL_CONF register and prevents the TLL mode from working correctly. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Sam, you can apply this one: Acked-by: Felipe Balbi ba...@ti.com But I think it needs to be resent with Cc: sta...@kernel.org I'm trying to avoid Cc: sta...@kernel.org since RMK complained about this on the Linux ARM kernel list. [1] Why would he do that? You need to put the Cc: in the signed off by area, and all will be fine. If you just put it in your email, you will get an automated email from me telling you to go read Documentation/stable_kernel_rules.txt which tells you exactly how to do this properly. Thanks for clearing that up. I'm resending with Felipe's ack and CCing sta...@kernel.org. - Anand -- To unsubscribe from this list: send the line unsubscribe 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 6/6 V2] hwmon: OMAP4: On die temperature sensor driver
On Thu, Aug 18, 2011 at 04:22:15PM +0530, Keerthy wrote:
...
+static int omap_temp_sensor_clk_enable(struct omap_temp_sensor *temp_sensor)
+{
+ u32 ret = 0;
+
+ if (temp_sensor-clk_on) {
+ dev_err(temp_sensor-hwmon_dev, clock already on\n);
+ goto out;
+ }
+
+ ret = pm_runtime_get_sync(temp_sensor-hwmon_dev);
+ if (ret 0) {
+ dev_err(temp_sensor-hwmon_dev, get sync failed\n);
+ goto out;
+ }
+
+ temp_sensor-clk_on = 1;
Probably should hold the mutex around this to keep clk_on consistent
with runtime PM state (and in disable method).
...
+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;
+
+ 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;
+
+ 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;
+ }
+
+ 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;
+
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_irq_safe(pdev-dev);
+
+ /*
+ * check if the efuse has a non-zero value if not
+ * it is an untrimmed sample and the temperatures
+ * may not be accurate
+ */
+
+ if (omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-bgap_efuse))
+ temp_sensor-is_efuse_valid = 1;
+
+ platform_set_drvdata(pdev, temp_sensor);
+ dev_set_drvdata(pdev-dev, temp_sensor);
+ temp_sensor-clock = clk_get(temp_sensor-hwmon_dev, fck);
+ if (IS_ERR(temp_sensor-clock)) {
+ ret = PTR_ERR(temp_sensor-clock);
+ dev_err(temp_sensor-hwmon_dev,
+ unable to get fclk: %d\n, ret);
+ ret = -EINVAL;
+ goto plat_res_err;
+ }
+
+ ret = omap_temp_sensor_clk_enable(temp_sensor);
+ if (ret) {
+ dev_err(pdev-dev, Cannot enable temp sensor\n);
+ goto clken_err;
+ }
+
+ clk_rate = clk_round_rate(temp_sensor-clock, 200);
+ if (clk_rate 100 || clk_rate == 0x) {
+ dev_err(pdev-dev, Error round rate\n);
+ ret = -EINVAL;
+ goto clken_err;
+ }
+
+ ret = clk_set_rate(temp_sensor-clock, clk_rate);
+ if (ret) {
+ dev_err(pdev-dev, Cannot set clock rate\n);
+ goto clken_err;
+ }
+
+ temp_sensor-clk_rate = clk_rate;
+ omap_enable_continuous_mode(temp_sensor, 1);
+ omap_configure_temp_sensor_thresholds(temp_sensor);
+ /* 1 ms */
+ omap_configure_temp_sensor_counter(temp_sensor, 1);
+
+ /* Wait till the first conversion is done wait for at least 1ms */
+ usleep_range(1000, 2000);
+
+ /* Read the temperature once due to hw issue*/
+ omap_temp_sensor_readl(temp_sensor,
+ temp_sensor-registers-temp_sensor_ctrl);
+
+ /* Set 2 seconds time as default counter */
+ omap_configure_temp_sensor_counter(temp_sensor,
+ temp_sensor-clk_rate * 2);
+
+ temp_sensor-hwmon_dev = hwmon_device_register(pdev-dev);
+ if (IS_ERR(temp_sensor-hwmon_dev)) {
+ dev_err(pdev-dev, hwmon_device_register failed.\n);
+ ret = PTR_ERR(temp_sensor-hwmon_dev);
+ goto hwmon_reg_err;
+ }
+
+ ret = sysfs_create_group(pdev-dev.kobj,
+ omap_temp_sensor_group);
+ if (ret) {
+ dev_err(pdev-dev, could not create sysfs files\n);
+ goto sysfs_create_err;
+ }
+
+ kobject_uevent(temp_sensor-hwmon_dev-kobj, KOBJ_ADD);
+
+ ret = request_threaded_irq(temp_sensor-irq, NULL,
+ omap_talert_irq_handler, IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ temp_sensor, temp_sensor);
+ if (ret) {
+ dev_err(pdev-dev, Request threaded irq failed.\n);
+ goto req_irq_err;
+ }
+
+ /* unmask the T_COLD and unmask T_HOT at init
Re: [RFC PATCH 5/6 V2] OMAP4: Temperature sensor device support
On Thu, Aug 18, 2011 at 04:22:14PM +0530, Keerthy wrote:
...
+int omap_temp_sensor_device_idle(struct omap_device *od)
+{
+ struct omap_temp_sensor_registers *registers;
+ struct resource*mem;
+ void__iomem *phy_base;
+ unsigned long timeout;
+ u32 ret = 0, temp;
+
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, no mem resource\n);
+ ret = -EINVAL;
+ goto plat_res_err;
+ }
+
+ phy_base = ioremap(mem-start, resource_size(mem));
Check NULL return.
+
+ if (!strcmp(od-hwmods[0]-dev_attr, mpu))
+ registers = omap_mpu_temp_sensor_registers;
+
+ temp = __raw_readl(phy_base + registers-temp_sensor_ctrl);
Compile warning on possible use of uninitialized value?
Suggest return error if string comparison (ugh) does not match.
+ temp |= registers-bgap_tempsoff_mask;
+
+ /* BGAP_TEMPSOFF should be set to 1 before gating clock */
+ __raw_writel(temp, phy_base + registers-temp_sensor_ctrl);
+ temp = __raw_readl(phy_base + registers-bgap_status);
+ timeout = jiffies + msecs_to_jiffies(5);
+
+ /* wait till the clean stop bit is set or till the timeout expires */
+ while (!(temp | registers-status_clean_stop_mask)
+ !(time_after(jiffies, timeout))) {
+ temp = __raw_readl(phy_base + registers-bgap_status);
+ usleep_range(500, 2000);
+ }
+
+ if (time_after(jiffies, timeout))
+ dev_err(od-pdev.dev, Clean stop bit not set\n);
+
+ ret = omap_device_idle_hwmods(od);
+
+plat_res_err:
+ return ret;
phy_base not saved anywhere, VM leak. Need iounmap(phy_base).
+}
+
+int omap_temp_sensor_device_activate(struct omap_device *od)
+{
+ struct omap_temp_sensor_registers *registers;
+ struct resource*mem;
+ void__iomem *phy_base;
+ u32 ret = 0, temp;
+
+ ret = omap_device_enable_hwmods(od);
+ if (ret 0)
+ return ret;
+ mem = platform_get_resource(od-pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(od-pdev.dev, no mem resource\n);
+ return -EINVAL;
+ }
+
+ phy_base = ioremap(mem-start, resource_size(mem));
Check NULL return.
+
+ if (!strcmp(od-hwmods[0]-dev_attr, mpu))
+ registers = omap_mpu_temp_sensor_registers;
+
+ temp = __raw_readl(phy_base + registers-temp_sensor_ctrl);
Error out if not mpu.
+ temp = ~(registers-bgap_tempsoff_mask);
+ /* BGAP_TEMPSOFF should be reset to 0 */
+ __raw_writel(temp,
+ phy_base + registers-temp_sensor_ctrl);
+
+ return 0;
iounmap(phy_base)
+}
+
+static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
+ {
+ .deactivate_func = omap_temp_sensor_device_idle,
+ .activate_func = omap_temp_sensor_device_activate,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+static DEFINE_IDR(temp_sensor_device_idr);
+
+static int temp_sensor_dev_init(struct omap_hwmod *oh, void *user)
+{
+ struct omap_temp_sensor_pdata *temp_sensor_pdata;
+ struct omap_device *od;
+ struct omap_temp_sensor_dev_attr *temp_sensor_dev_attr;
+ int ret = 0;
+ int num;
+ struct mutex sensor_mutex; /* sensor mutex */
+
+ mutex_init(sensor_mutex);
+
+ temp_sensor_pdata =
+ kzalloc(sizeof(*temp_sensor_pdata), GFP_KERNEL);
+ if (!temp_sensor_pdata) {
+ dev_err(oh-od-pdev.dev,
+ Unable to allocate memory for temp sensor pdata\n);
+ return -ENOMEM;
+ }
+
+ mutex_lock(sensor_mutex);
Mutex just init'ed above, this code can't run concurrent with any
other accessors.
+ ret = idr_pre_get(temp_sensor_device_idr, GFP_KERNEL);
+ if (ret 0) {
+ mutex_unlock(sensor_mutex);
+ goto fail_id;
+ }
+ ret = idr_get_new(temp_sensor_device_idr, temp_sensor_pdata, num);
+ if (ret 0) {
+ mutex_unlock(sensor_mutex);
+ goto fail_id;
+ }
+ mutex_unlock(sensor_mutex);
+
+ temp_sensor_dev_attr = oh-dev_attr;
+ if (!strcmp(temp_sensor_dev_attr-name, mpu))
+ temp_sensor_pdata-registers = omap_mpu_temp_sensor_registers;
+
+ od = omap_device_build(omap_temp_sensor, num,
+ oh, temp_sensor_pdata, sizeof(*temp_sensor_pdata),
+omap_temp_sensor_latency,
+ ARRAY_SIZE(omap_temp_sensor_latency), 0);
Inconsistent tabbing.
+ if (IS_ERR(od)) {
