Re: [v2 1/2] usb: musb: omap2+: fix context api's
On Wed, Sep 07, 2011 at 09:19:23AM -0700, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com RxFifoSz, TxFifoSz, RxFifoAddr, TxFifoAddr are all indexed registers. So before doing a context save or restore, INDEX register should be set, then only one gets to the right register offset. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com applied, thanks (sorry for the long delay) -- balbi signature.asc Description: Digital signature
Re: [v2 2/2] usb: musb: omap2+: save and restore OTG_INTERFSEL
On Wed, Sep 07, 2011 at 09:19:24AM -0700, Vikram Pandita wrote: From: Hema HK hem...@ti.com we need to save and restore OTG_INTERFSEL register else we will be unable to function on resume after OFF mode. Reported-by: Devaraj Rangasamy d...@ti.com Signed-off-by: Hema HK hem...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com applied thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: The logic to allow only one DMA driver in MUSB is currently flawed, because it also allows picking no DMA driver at all and also not selecting PIO mode. Using a choice statement makes this foolproof for now and also simplifies the Makefile. Unfortunately, we will have to revisit this when we start supporting multiple ARM platforms in a single kernel binary, because at that point we will actually need to select multiple DMA drivers and pick the right one at run-time. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 17/30] usb/musb: allow building USB_MUSB_TUSB6010 as a module
On Sun, Oct 02, 2011 at 04:45:47PM +0200, Arnd Bergmann wrote: Commit 1376d92f9 usb: musb: allow musb and glue layers to be modules made the USB_MUSB_TUSB6010 option modular, but actually building the driver as a module does not work, so various randconfig builds actually fail. This changes all code that depends on the option to also check for modular builds, and exports the necessary symbols. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Felipe Balbi ba...@ti.com applied, thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] omap: sound: fix ambiguous else warning
Hi On 10/10/2011 08:07 AM, Michael Opdenacker wrote: This patch applies against Tony Lindgren's linux-omap tree It fixes ambiguous else warnings at compile time. Signed-off-by: Michael Opdenackermichael.opdenac...@linaro.org --- sound/soc/omap/omap-mcbsp.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) This is already fixed in ASoC tree by following commit commit 141947e6ceb8f82fe8382b26f093bb379af9af15 Author: Peter Ujfalusi peter.ujfal...@ti.com Date: Mon Sep 26 10:56:42 2011 +0300 ASoC: omap-mcbsp: Fix compile time warning about ambiguous ‘else’ -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: sound: fix checkpatch.pl error
On 10/10/2011 08:07 AM, Michael Opdenacker wrote:
Signed-off-by: Michael Opdenackermichael.opdenac...@linaro.org
---
sound/soc/omap/omap-mcbsp.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 1391ea0..30325fb 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -606,8 +606,7 @@ static int mcbsp_dai_probe(struct snd_soc_dai *dai)
return 0;
}
-static struct snd_soc_dai_driver omap_mcbsp_dai =
-{
+static struct snd_soc_dai_driver omap_mcbsp_dai = {
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: omap_device: Add omap_device_{alloc, delete, register}_ss
Hi Kevin, On Wed, Oct 5, 2011 at 6:54 PM, Ohad Ben-Cohen o...@wizery.com wrote: Split omap_device_build_ss() into two smaller functions: ... This patch is considered an interim solution until DT fully materializes for omap; at that point, this functionality will be removed. Good news: we might not need this after all. I need the remoteproc devices to exists at -reserve() time, so I can assign them a private CMA pool, which means I can't wait for omap_device_build_ss() and must create the devices beforehand. ... which makes Benoit's alloc/delete methods perfect for me. So please hold this one off for now. I'd just need a s/static// patch that will allow me to use Benoit's methods outside of omap_device.c, but I'll wait for things to settle down a bit before sending it, to minimize this kind of churn. Thanks and sorry for the noise, 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/2] omap: sound: fix ambiguous else warning
On 10/10/2011 08:54 AM, Jarkko Nikula wrote: Hi On 10/10/2011 08:07 AM, Michael Opdenacker wrote: This patch applies against Tony Lindgren's linux-omap tree It fixes ambiguous else warnings at compile time. Signed-off-by: Michael Opdenackermichael.opdenac...@linaro.org --- sound/soc/omap/omap-mcbsp.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) This is already fixed in ASoC tree by following commit commit 141947e6ceb8f82fe8382b26f093bb379af9af15 Author: Peter Ujfalusi peter.ujfal...@ti.com Date: Mon Sep 26 10:56:42 2011 +0300 ASoC: omap-mcbsp: Fix compile time warning about ambiguous ‘else’ Perfect, thanks. I'll keep an eye on the ASoC tree next time. Michael. -- Michael Opdenacker, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com + 33 621 604 642 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Sun, Oct 2, 2011 at 5:58 PM, Ohad Ben-Cohen o...@wizery.com wrote: Ok, fair enough. I've revised the patches and attached the main one below; please tell me if it looks ok, and then I'll resubmit the entire patch set. Ping ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] OMAP2+: omap_hwmod: manage the wake-up latency constraints
Hi Paull, On Fri, Oct 7, 2011 at 4:53 AM, Paul Walmsley p...@pwsan.com wrote: Hi a comment: On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Hwmod is queried from the OMAP_PM layer to manage the power domains wake-up latency constraints. Hwmod retrieves the correct power domain and if it exists it calls the corresponding power domain function. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 26 +- arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 ++ 2 files changed, 27 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 84cc0bd..c6b1cc9 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2618,11 +2619,34 @@ ohsps_unlock: return ret; } +/* + * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint + * + * @oh: struct omap_hwmod* to which the target device belongs to. + * @cookie: identifier of the constraints list for @oh. + * @min_latency: the minimum allowed wake-up latency for @oh. + * + * Returns 0 upon success. + */ It's good that there is some documentation here, but it would be better if it were kerneldoc-style documentation. Please see Documentation/kernel-doc-nano-HOWTO.txt. Also it would be good to have a bit more documentation here beyond simply Returns 0 upon success. For example, how should a caller remove a wakeup latency constraint? Also, this function can return -EINVAL, not counting whatever pwrdm_set_wkup_lat_constraint() can return, so that should be documented above also. This applies to the function comments in the rest of the patches too. Some of them have quite good kerneldoc comments, such as pwrdm_wakeuplat_update_pwrst(); others need some work, like pwrdm_set_wkup_lat_constraint(). Not all functions have kernel doc comments, i.e. this one does not (no /** at the start of the header). The intention is to document the functions from the API and the ones that implement the core service (pwrdm_set_wkup_lat_constraint()), and not the pure pass-through functions (omap_hwmod_set_wkup_constraint). In any case I will review the comments and resubmit. Thanks, Jean - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
Hi Paul, On Fri, Oct 7, 2011 at 6:17 AM, Paul Walmsley p...@pwsan.com wrote: Hi Jean On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Figures are added to the power domains structs for RET and OFF modes. Note: the latency figures for MPU, PER, CORE, NEON have been obtained from actual measurements. The latency figures for the other power domains are preliminary and shall be added. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Do the CSWR measurements include the time for the PMIC to scale the voltage, or do they just represent the time to enter and exit clock stop (presumably with DPLL idling)? As described at [1] the measurements have not been performed with sys_offmode and sys_clkreq signals toggling correctly, because of the lack of support for it in the kernel. However the results are including a correction for the sys_offmode transition time (11.5ms), but no correction for the sys_clkreq signal (which should be 1ms for sysclk on, 2.5ms for sysclk off). [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results Regards, Jean - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
Paul, On Fri, Oct 7, 2011 at 5:26 PM, Paul Walmsley p...@pwsan.com wrote: Hi Jean On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote: Figures are added to the power domains structs for RET and OFF modes. Note: the latency figures for MPU, PER, CORE, NEON have been obtained from actual measurements. The latency figures for the other power domains are preliminary and shall be added. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. A few more question about these numbers. - Are these numbers the ones right off the hardware, or rounded, or worst-case plus a certain percentage? All measurements results are the worst case values right from the hardware (HW and SW measurements on the target). - What frequency/voltage were these measured at? OPP50 - Also, you mention OMAP3 Beagleboard. Is that 34xx or 36xx Beagleboard? 34xx Beagleboard Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results for the details. Regards, Jean - Paul -- To unsubscribe from this list: send the line unsubscribe 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Fri, Oct 7, 2011 at 4:03 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 7 Oct 2011, Munegowda, Keshava wrote: Thanks Paul; yes, I can your changes in the patches. so, you don't need v14 from me right? please confirm. I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed. Thanks for guiding me and helping on the finalizing the hwmod configurations. The first two patches of the series -- the OMAP3/4 hwmod data patches -- have been queued for 3.2 in the 'hwmod_devel_3.2' branch of git://git.pwsan.com/linux-2.6 So we don't need new versions of those two. But we need to figure out what to do about the remaining three patches. I still think that the TLL and UHH hwmods should have separate drivers. Looks like Felipe has a question pending about that but it's unlikely that I'll have time to dig into it for at least a few days. So I'd encourage you to try splitting those UHH and TLL drivers in the meantime. some time last week; I had a discussion with Felipe and he is ok to have current design as it is for now; But, he wants to redesign this driver with UHH and TLL as two platform drivers. I will have discussion with Felipe and Partha to redesign it soon. Hi paul and Felipe Here is the highlights of the change in the design of USB Host which we can do after kernel 3.2 release; 1. separate the TLL changes from UHH 2. The TLL is be a new platform driver in ./drivers/mfd 3. the TLL platform driver will export apis for enable/disable clocks and settings. 3. the UHH drivers uses these APIS of TLL based on the port configurations from board files you don't need the TLL clocks to be on while all the ports are in phy mode. please let me know your thoughts about it. 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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi, On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote: Hi paul and Felipe Here is the highlights of the change in the design of USB Host which we can do after kernel 3.2 release; 1. separate the TLL changes from UHH 2. The TLL is be a new platform driver in ./drivers/mfd 3. the TLL platform driver will export apis for enable/disable clocks and settings. TLL should control its clocks through pm_runtime APIs like anything else. If you really must export APIs to be used by UHH, you need to have an API so that you can claim/release a TLL channel and get/put for increasing/decreasing PM counters. I still think though, you should try to avoid exporting OMAP-specific APIs all over the place. Ideally, we would be able to have some way of saying that UHH and TLL are closely related... something like having the ability to say e.g. two devices are sibblings of each other, so that we could ask for a sibbling to wakeup/sleep depending if we need it or not. Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific APIs is wise. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote: Hi paul and Felipe Here is the highlights of the change in the design of USB Host which we can do after kernel 3.2 release; 1. separate the TLL changes from UHH 2. The TLL is be a new platform driver in ./drivers/mfd 3. the TLL platform driver will export apis for enable/disable clocks and settings. TLL should control its clocks through pm_runtime APIs like anything else. If you really must export APIs to be used by UHH, you need to have an API so that you can claim/release a TLL channel and get/put for increasing/decreasing PM counters. I still think though, you should try to avoid exporting OMAP-specific APIs all over the place. Ideally, we would be able to have some way of saying that UHH and TLL are closely related... something like having the ability to say e.g. two devices are sibblings of each other, so that we could ask for a sibbling to wakeup/sleep depending if we need it or not. do we have sibling structures today? I dont think so. Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific APIs is wise. so, it means , if we can have sibling structure, then we can conditionally enable it right? -- To unsubscribe from this list: send the line unsubscribe 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote: On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote: Hi paul and Felipe Here is the highlights of the change in the design of USB Host which we can do after kernel 3.2 release; 1. separate the TLL changes from UHH 2. The TLL is be a new platform driver in ./drivers/mfd 3. the TLL platform driver will export apis for enable/disable clocks and settings. TLL should control its clocks through pm_runtime APIs like anything else. If you really must export APIs to be used by UHH, you need to have an API so that you can claim/release a TLL channel and get/put for increasing/decreasing PM counters. I still think though, you should try to avoid exporting OMAP-specific APIs all over the place. Ideally, we would be able to have some way of saying that UHH and TLL are closely related... something like having the ability to say e.g. two devices are sibblings of each other, so that we could ask for a sibbling to wakeup/sleep depending if we need it or not. do we have sibling structures today? I dont think so. no we don't. Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific APIs is wise. so, it means , if we can have sibling structure, then we can conditionally enable it right? the conditional would still lie in UHH driver, but at least it would be made into a generic API. I mean, you could create a generic way of defining sibbling devices, and a generic way to make them talk to each other. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] omap: sound: fix checkpatch.pl error
On Mon, Oct 10, 2011 at 07:07:08AM +0200, Michael Opdenacker wrote: Signed-off-by: Michael Opdenacker michael.opdenac...@linaro.org Applied, but please do try to make sure your changelogs resemble those for the rest of the subsystem. Especially for trivial patches it's not good to increase the effort required to apply them. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
Hi Ohad,
sorry, I was on vacation last week and had no time to look into this.
On Sun, Oct 02, 2011 at 11:58:12AM -0400, Ohad Ben-Cohen wrote:
drivers/iommu/iommu.c | 138 ---
drivers/iommu/omap-iovmm.c | 12 +---
include/linux/iommu.h |6 +-
virt/kvm/iommu.c |4 +-
4 files changed, 137 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a7b0862..f23563f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -16,6 +16,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#define pr_fmt(fmt)%s: fmt, __func__
+
#include linux/kernel.h
#include linux/bug.h
#include linux/types.h
@@ -23,15 +25,54 @@
#include linux/slab.h
#include linux/errno.h
#include linux/iommu.h
+#include linux/bitmap.h
Is this still required?
static struct iommu_ops *iommu_ops;
+/* bitmap of supported page sizes */
+static unsigned long iommu_pgsize_bitmap;
+
+/* size of the smallest supported page (in bytes) */
+static unsigned int iommu_min_pagesz;
+
+/**
+ * register_iommu() - register an IOMMU hardware
+ * @ops: iommu handlers
+ * @pgsize_bitmap: bitmap of page sizes supported by the hardware
+ *
+ * Note: this is a temporary function, which will be removed once
+ * all IOMMU drivers are converted. The only reason it exists is to
+ * allow splitting the pgsizes changes to several patches in order to ease
+ * the review.
+ */
+void register_iommu_pgsize(struct iommu_ops *ops, unsigned long
pgsize_bitmap)
+{
+ if (iommu_ops || iommu_pgsize_bitmap || !pgsize_bitmap)
+ BUG();
+
+ iommu_ops = ops;
+ iommu_pgsize_bitmap = pgsize_bitmap;
+
+ /* find out the minimum page size only once */
+ iommu_min_pagesz = 1 __ffs(pgsize_bitmap);
+}
Hmm, I thought a little bit about that and came to the conculusion it
might be best to just keep the page-sizes as a part of the iommu_ops
structure. So there is no need to extend the register_iommu interface.
Also, the bus_set_iommu interface is now in the -next branch. Would be
good if you rebase the patches to that interface.
You can find the current iommu tree with these changes at
git://git.8bytes.org/scm/iommu.git
@@ -115,26 +156,103 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot)
+ phys_addr_t paddr, size_t size, int prot)
{
- size_t size;
+ int ret = 0;
+
+ /*
+* both the virtual address and the physical one, as well as
+* the size of the mapping, must be aligned (at least) to the
+* size of the smallest page supported by the hardware
+*/
+ if (!IS_ALIGNED(iova | paddr | size, iommu_min_pagesz)) {
+ pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%lx min_pagesz
+ 0x%x\n, iova, (unsigned long)paddr,
+ (unsigned long)size, iommu_min_pagesz);
+ return -EINVAL;
+ }
- size = 0x1000UL gfp_order;
+ pr_debug(map: iova 0x%lx pa 0x%lx size 0x%lx\n, iova,
+ (unsigned long)paddr, (unsigned long)size);
- BUG_ON(!IS_ALIGNED(iova | paddr, size));
+ while (size) {
+ unsigned long pgsize, addr_merge = iova | paddr;
+ unsigned int pgsize_idx;
- return iommu_ops-map(domain, iova, paddr, gfp_order, prot);
+ /* Max page size that still fits into 'size' */
+ pgsize_idx = __fls(size);
+
+ /* need to consider alignment requirements ? */
+ if (likely(addr_merge)) {
+ /* Max page size allowed by both iova and paddr */
+ unsigned int align_pgsize_idx = __ffs(addr_merge);
+
+ pgsize_idx = min(pgsize_idx, align_pgsize_idx);
+ }
+
+ /* build a mask of acceptable page sizes */
+ pgsize = (1UL (pgsize_idx + 1)) - 1;
+
+ /* throw away page sizes not supported by the hardware */
+ pgsize = iommu_pgsize_bitmap;
I think we need some care here and check pgsize for 0. A BUG_ON should
do.
+
+ /* pick the biggest page */
+ pgsize_idx = __fls(pgsize);
+ pgsize = 1UL pgsize_idx;
+
+ /* convert index to page order */
+ pgsize_idx -= PAGE_SHIFT;
+
+ pr_debug(mapping: iova 0x%lx pa 0x%lx order %u\n, iova,
+ (unsigned long)paddr, pgsize_idx);
+
+ ret = iommu_ops-map(domain, iova, paddr, pgsize_idx, prot);
+ if (ret)
+ break;
Re: [PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
Hi Jon,
On 10/8/2011 12:46 AM, Hunter, Jon wrote:
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunterjon-hun...@ti.com
This one, I don't quite understand. We should probably be removing these
MODULEMODE-only clocks from the OMAP4 tree, and using their parent clock
as the main_clk. That would be a good cleanup for 3.3...
Yes, but in order to remove that from the clock data we must ensure that
the hwmod entry is there.
I kept a lot of legacy MODULEMODE clocks just because of missing hwmod /
runtime_pm adaptation on some drivers.
In the case of slimbus, there is no main_clk but a bunch of optional
clocks. It looks similar to the DSS case. So we should not use the
parent clock as a main_clk.
We should probably promote one of the opt_clk as the main_clk. The
slimbus_clk seems to be the good candidate for both instances.
static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus1_fclk_1 },
{ .role = fclk_0, .clk = slimbus1_fclk_0 },
{ .role = fclk_2, .clk = slimbus1_fclk_2 },
{ .role = slimbus_clk, .clk = slimbus1_slimbus_clk },
};
static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus2_fclk_1 },
{ .role = fclk_0, .clk = slimbus2_fclk_0 },
{ .role = slimbus_clk, .clk = slimbus2_slimbus_clk },
};
Jon,
Do you know if that one is indeed mandatory to use the slimbus IP?
Sorry, are you asking about the clocks I was re-naming or the
slimbus_clk you are referring to above?
The clocks you are renaming should not exist at all, so I was referring
to the real clocks that are all listed as optional clocks.
Usually we do need to have a main_clk in order to access the IP
registers (at least the sysconfig). But for some IPs, the iclk can be
enough.
If the interface clock is enough, then potentially that main clock is
not mandatory. But if one functional clock is mandatory, then we have to
figured out which one from the various optional functional clocks can be
used as the main_clk.
Looking at the clock tree tool, the slimbus_clk is the actual external
slimbus clock that can be generated by OMAP or by an external device.
The TRM states ...
Most of the SLIMbus module runs off two main clocks: the L4 interface
clock for the data input and output registers, and the control and
status control registers; and the SLIMbus clock, taken from the serial
interface (CLK line) for the SLIMbus-side logic.
The SLIMbus controller operates as clock source component (active
framer), which drives the SLIMbus clock line CLK, or as clock receiver
component, which gets its clock from the same CLK line.
So, if you are operating as the clock source component on the bus then
one of the optional clocks to drive the peripheral logic and if you are
the clock receiver then you use slimbus_clk.
OK, so clearly, the slimbus_clk cannot be a main_clk. We have to check
if the registers can be accessed only with the iclk.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, Oct 10, 2011 at 12:26:15PM +0300, Felipe Balbi wrote:
On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
Hi paul and Felipe
Here is the highlights of the change in the design of USB Host which
we can do after kernel 3.2 release;
1. separate the TLL changes from UHH
2. The TLL is be a new platform driver in ./drivers/mfd
3. the TLL platform driver will export apis for enable/disable clocks
and settings.
TLL should control its clocks through pm_runtime APIs like anything
else. If you really must export APIs to be used by UHH, you need to have
an API so that you can claim/release a TLL channel and get/put for
increasing/decreasing PM counters.
I still think though, you should try to avoid exporting OMAP-specific
APIs all over the place. Ideally, we would be able to have some way of
saying that UHH and TLL are closely related... something like having the
ability to say e.g. two devices are sibblings of each other, so that we
could ask for a sibbling to wakeup/sleep depending if we need it or not.
do we have sibling structures today? I dont think so.
no we don't.
Ok, here's a first shot at it:
From 600ae62f4b4a832d90a83d43227deb6f84b9def1 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Mon, 10 Oct 2011 12:56:34 +0300
Subject: [RFC/NOT-FOR-MERGING/PATCH] base: add the idea of sibling devices
Organization: Texas Instruments\n
It's possible that some devices, which share a
common parent, need to talk to each due to a
very close relationship between them.
Generally, one device will provide some sort of
resources to the other (e.g. clocks) while still
both sharing another common parent.
In such cases, it seems necessary to define those
two devices as siblings, rather than a virtual
parent relationship, and have means for one device
to ask the sibling device to e.g. turn on its clocks.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/base/core.c| 41 +
include/linux/device.h |7 +++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bc8729d..3b7f2e5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -589,6 +589,7 @@ void device_initialize(struct device *dev)
dev-kobj.kset = devices_kset;
kobject_init(dev-kobj, device_ktype);
INIT_LIST_HEAD(dev-dma_pools);
+ INIT_LIST_HEAD(dev-siblings);
mutex_init(dev-mutex);
lockdep_set_novalidate_class(dev-mutex);
spin_lock_init(dev-devres_lock);
@@ -889,6 +890,7 @@ int device_private_init(struct device *dev)
*/
int device_add(struct device *dev)
{
+ struct device *sibling, *n;
struct device *parent = NULL;
struct class_interface *class_intf;
int error = -EINVAL;
@@ -923,6 +925,10 @@ int device_add(struct device *dev)
parent = get_device(dev-parent);
setup_parent(dev, parent);
+ /* setup siblings */
+ list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node)
+ get_device(sibling);
+
/* use parent numa_node */
if (parent)
set_dev_node(dev, dev_to_node(parent));
@@ -1071,6 +1077,31 @@ void put_device(struct device *dev)
}
/**
+ * get_sibling_device_byname - finds a sibling device by its name
+ * @dev: device.
+ * @name: name for the sibling to find.
+ *
+ * This is here to help drivers which need to ask their siblings
+ * for something in particular (like ask sibling to turn clocks on)
+ * achieve that by first finding the correct device pointer for
+ * that sibling.
+ */
+struct device *get_sibling_device_byname(struct device *dev, const char *name)
+{
+ struct device *sibling, *n;
+ struct device *found = NULL;
+
+ list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node) {
+ if (!strcmp(dev_name(sibling), name))
+ found = sibling;
+ goto found;
+ }
+
+found:
+ return found;
+}
+
+/**
* device_del - delete device from system.
* @dev: device.
*
@@ -1085,6 +1116,7 @@ void put_device(struct device *dev)
*/
void device_del(struct device *dev)
{
+ struct device *sibling, *n;
struct device *parent = dev-parent;
struct class_interface *class_intf;
@@ -1120,6 +1152,15 @@ void device_del(struct device *dev)
device_remove_attrs(dev);
bus_remove_device(dev);
+ /* teardown siblings */
+ list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node) {
+ /* siblings must have the same parent */
+ WARN(sibling-parent != parent,
+ siblings must have a common parent\n);
+
+ get_device(sibling);
+
Re: [PATCH 0/2] ARM: OMAP2+: timer fixes / cleanup
On Mon, Oct 10, 2011 at 11:10 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Wed, Oct 5, 2011 at 3:06 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Tarun, On 10/4/2011 11:20 PM, Cousson, Benoit wrote: Hi Tony, Here is the series to fix the warning and remove the redundant latency structure that be removed since the timer runtime PM adaptation was just pulled. I was just able to test that on OMAP4. It will be nice if you can test that on the other platforms. In theory, if they are properly using hwmod that should work fine. Yes, I will test in other platforms. I have tested on OMAP2420, OMAP2430 and OMAP3430. -- Tarun Thanks, Benoit Patches are based on Kevin's for_3.2/omap_device-2 branch and are available here: git://gitorious.org/omap-pm/linux.git for_3.2/timer_fixes Regards, Benoit Benoit Cousson (2): ARM: OMAP2+: clock data: Remove redundant timer clkdev ARM: OMAP2+: timer: Remove omap_device_pm_latency arch/arm/mach-omap2/clock2420_data.c | 12 arch/arm/mach-omap2/clock2430_data.c | 12 arch/arm/mach-omap2/clock3xxx_data.c | 12 arch/arm/mach-omap2/clock44xx_data.c | 11 --- arch/arm/mach-omap2/timer.c | 12 +--- 5 files changed, 1 insertions(+), 58 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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, Oct 10, 2011 at 3:35 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Oct 10, 2011 at 12:26:15PM +0300, Felipe Balbi wrote:
On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
Hi paul and Felipe
Here is the highlights of the change in the design of USB Host which
we can do after kernel 3.2 release;
1. separate the TLL changes from UHH
2. The TLL is be a new platform driver in ./drivers/mfd
3. the TLL platform driver will export apis for enable/disable clocks
and settings.
TLL should control its clocks through pm_runtime APIs like anything
else. If you really must export APIs to be used by UHH, you need to have
an API so that you can claim/release a TLL channel and get/put for
increasing/decreasing PM counters.
I still think though, you should try to avoid exporting OMAP-specific
APIs all over the place. Ideally, we would be able to have some way of
saying that UHH and TLL are closely related... something like having the
ability to say e.g. two devices are sibblings of each other, so that we
could ask for a sibbling to wakeup/sleep depending if we need it or not.
do we have sibling structures today? I dont think so.
no we don't.
Ok, here's a first shot at it:
From 600ae62f4b4a832d90a83d43227deb6f84b9def1 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Mon, 10 Oct 2011 12:56:34 +0300
Subject: [RFC/NOT-FOR-MERGING/PATCH] base: add the idea of sibling devices
Organization: Texas Instruments\n
It's possible that some devices, which share a
common parent, need to talk to each due to a
very close relationship between them.
Generally, one device will provide some sort of
resources to the other (e.g. clocks) while still
both sharing another common parent.
In such cases, it seems necessary to define those
two devices as siblings, rather than a virtual
parent relationship, and have means for one device
to ask the sibling device to e.g. turn on its clocks.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/base/core.c | 41 +
include/linux/device.h | 7 +++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bc8729d..3b7f2e5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -589,6 +589,7 @@ void device_initialize(struct device *dev)
dev-kobj.kset = devices_kset;
kobject_init(dev-kobj, device_ktype);
INIT_LIST_HEAD(dev-dma_pools);
+ INIT_LIST_HEAD(dev-siblings);
mutex_init(dev-mutex);
lockdep_set_novalidate_class(dev-mutex);
spin_lock_init(dev-devres_lock);
@@ -889,6 +890,7 @@ int device_private_init(struct device *dev)
*/
int device_add(struct device *dev)
{
+ struct device *sibling, *n;
struct device *parent = NULL;
struct class_interface *class_intf;
int error = -EINVAL;
@@ -923,6 +925,10 @@ int device_add(struct device *dev)
parent = get_device(dev-parent);
setup_parent(dev, parent);
+ /* setup siblings */
+ list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node)
+ get_device(sibling);
+
/* use parent numa_node */
if (parent)
set_dev_node(dev, dev_to_node(parent));
@@ -1071,6 +1077,31 @@ void put_device(struct device *dev)
}
/**
+ * get_sibling_device_byname - finds a sibling device by its name
+ * @dev: device.
+ * @name: name for the sibling to find.
+ *
+ * This is here to help drivers which need to ask their siblings
+ * for something in particular (like ask sibling to turn clocks on)
+ * achieve that by first finding the correct device pointer for
+ * that sibling.
+ */
+struct device *get_sibling_device_byname(struct device *dev, const char
*name)
+{
+ struct device *sibling, *n;
+ struct device *found = NULL;
+
+ list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node) {
+ if (!strcmp(dev_name(sibling), name))
+ found = sibling;
+ goto found;
+ }
+
+found:
+ return found;
+}
+
+/**
* device_del - delete device from system.
* @dev: device.
*
@@ -1085,6 +1116,7 @@ void put_device(struct device *dev)
*/
void device_del(struct device *dev)
{
+ struct device *sibling, *n;
struct device *parent = dev-parent;
struct class_interface *class_intf;
@@ -1120,6 +1152,15 @@ void device_del(struct device *dev)
device_remove_attrs(dev);
bus_remove_device(dev);
+ /* teardown siblings */
+ list_for_each_entry_safe(sibling, n, dev-siblings, sibling_node) {
+ /* siblings must have the same parent */
+
Re: [PATCH 0/2] ARM: OMAP2+: timer fixes / cleanup
On 10/10/2011 12:05 PM, DebBarma, Tarun Kanti wrote: On Mon, Oct 10, 2011 at 11:10 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Wed, Oct 5, 2011 at 3:06 AM, Cousson, Benoitb-cous...@ti.com wrote: Hi Tarun, On 10/4/2011 11:20 PM, Cousson, Benoit wrote: Hi Tony, Here is the series to fix the warning and remove the redundant latency structure that be removed since the timer runtime PM adaptation was just pulled. I was just able to test that on OMAP4. It will be nice if you can test that on the other platforms. In theory, if they are properly using hwmod that should work fine. Yes, I will test in other platforms. I have tested on OMAP2420, OMAP2430 and OMAP3430. Thanks Tarun, Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT/PATCH 1/7] OMAP3+: PM: SR: add suspend/resume handlers
From: Nishanth Menon n...@ti.com
SmartReflex should be disabled while entering low power mode due to
the following reasons:
a) SmartReflex values are not defined for retention voltage.
b) With SmartReflex enabled, if the CPU enters low power state, FSM
will try to bump the voltage to current OPP's voltage for which
it has entered low power state, causing power loss and potential
unknown states for the SoC.
Since we are sure to attempt entering the lowest possible power state
during suspend operation, SmartReflex needs to be disabled for the
voltage domains in suspend path before achieving auto retention voltage
on the device.
Traditionally, this has been done with interrupts disabled as part of
the common code which handles the idle sequence. Instead, by using the
fact that we have to disable SmartReflex for sure during suspend
operations, we can opportunistically disable SmartReflex in device
standard pm ops, instead of disabling it as part of the code which
executes with interrupts disabled and slave CPU{s} shutdown. This
allows the system to do other parallel activities(such as suspending
other devices in the system using slave CPU{s}) and save the time
required to achieve suspend and resume from suspended state as a
sequential activity.
However, by being opportunistic as described above, we also increase
the likelihood of SmartReflex library access functions being invoked in
parallel contexts *after* SmartReflex driver's suspend handler (during
suspend operation) or *before* resume handler (during resume operation)
have been invoked (Example: DVFS for dependent devices, cpufreq for
MPU etc.). We prevent this by using a flag to reject the callers in
the duration where SmartReflex has been disabled.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 96 ++--
1 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 34c01a7..af158c0 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -23,6 +23,7 @@
#include linux/debugfs.h
#include linux/delay.h
#include linux/slab.h
+#include linux/pm.h
#include linux/pm_runtime.h
#include plat/common.h
@@ -39,6 +40,7 @@ struct omap_sr {
int ip_type;
int nvalue_count;
boolautocomp_active;
+ boolis_suspended;
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -683,6 +685,11 @@ void omap_sr_enable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -716,6 +723,11 @@ void omap_sr_disable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -749,6 +761,11 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -807,14 +824,16 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return -EINVAL;
}
- /* control enable/disable only if there is a delta in value */
- if (sr_info-autocomp_active != val) {
- if (!val)
- sr_stop_vddautocomp(sr_info);
- else
- sr_start_vddautocomp(sr_info);
+ if (sr_info-is_suspended) {
+ pr_warning(%s: in suspended state\n, __func__);
+ return -EBUSY;
}
+ if (!val)
+ sr_stop_vddautocomp(sr_info);
+ else
+ sr_start_vddautocomp(sr_info);
+
return 0;
}
@@ -1001,10 +1020,75 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_sr_suspend(struct device *dev)
+{
+ struct omap_sr_data *pdata;
+ struct omap_sr *sr_info;
+
+ pdata =
[RFT/PATCH 2/7] arm: omap: smartreflex: add missing platform_set_drvdata()
that's very useful to fetch the correct struct sr_info
from PM handlers.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index af158c0..55e297e 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -855,6 +855,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
return -ENOMEM;
}
+ platform_set_drvdata(pdev, sr_info);
+
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
ret = -EINVAL;
--
1.7.6.396.ge0613
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT/PATCH 3/7] arm: omap: smartreflex: use dev_get_drvdata()
When we need to fetch struct omap_sr on PM
handlers, there's no need to access platform_data.
Instead, we can use dev_get_drvdata(dev) like
other drivers do.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 51 ++--
1 files changed, 9 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 55e297e..357363b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -992,22 +992,9 @@ err_free_devinfo:
static int __devexit omap_sr_remove(struct platform_device *pdev)
{
- struct omap_sr_data *pdata = pdev-dev.platform_data;
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info = platform_get_drvdata(pdev);
struct resource *mem;
- if (!pdata) {
- dev_err(pdev-dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(pdev-dev, %s: omap_sr struct not found\n,
- __func__);
- return -EINVAL;
- }
-
if (sr_info-autocomp_active)
sr_stop_vddautocomp(sr_info);
if (sr_info-dbg_dir)
@@ -1024,20 +1011,10 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
static int omap_sr_suspend(struct device *dev)
{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info = dev_get_drvdata(dev);
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
+ if (!sr_info)
+ return 0;
if (!sr_info-autocomp_active)
return 0;
@@ -1045,7 +1022,7 @@ static int omap_sr_suspend(struct device *dev)
if (sr_info-is_suspended)
return 0;
- omap_sr_disable_reset_volt(pdata-voltdm);
+ omap_sr_disable_reset_volt(sr_info-voltdm);
sr_info-is_suspended = true;
/* Flag the same info to the other CPUs */
smp_wmb();
@@ -1055,20 +1032,10 @@ static int omap_sr_suspend(struct device *dev)
static int omap_sr_resume(struct device *dev)
{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info = dev_get_drvdata(dev);
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
+ if (!sr_info)
+ return 0;
if (!sr_info-autocomp_active)
return 0;
@@ -1079,7 +1046,7 @@ static int omap_sr_resume(struct device *dev)
sr_info-is_suspended = false;
/* Flag the same info to the other CPUs */
smp_wmb();
- omap_sr_enable(pdata-voltdm);
+ omap_sr_enable(sr_info-voltdm);
return 0;
}
--
1.7.6.396.ge0613
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT/PATCH 4/7] arm: omap: smartreflex: move late_initcall() closer to its argument
no functional changes, trivial patch.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 357363b..28a24fd 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1085,12 +1085,12 @@ static int __init sr_init(void)
return 0;
}
+late_initcall(sr_init);
static void __exit sr_exit(void)
{
platform_driver_unregister(smartreflex_driver);
}
-late_initcall(sr_init);
module_exit(sr_exit);
MODULE_DESCRIPTION(OMAP Smartreflex Driver);
--
1.7.6.396.ge0613
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT/PATCH 5/7] arm: omap: smartreflex: clean ups all over
There are no functional changes here, only
misc cleanups in general: tabifying variable
declarations, converting if {} else if {} else {}
into switch statements, etc.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 217 +++--
1 files changed, 134 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 28a24fd..6e9eb46 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -36,26 +36,32 @@
#define SR_DISABLE_TIMEOUT 200
struct omap_sr {
- int srid;
- int ip_type;
+ struct list_headnode;
+ struct platform_device *pdev;
+ struct omap_sr_nvalue_table *nvalue_table;
+ struct voltagedomain*voltdm;
+
+ unsigned intirq;
+
int nvalue_count;
- boolautocomp_active;
- boolis_suspended;
- u32 clk_length;
- u32 err_weight;
+ int ip_type;
+ int srid;
+
+ u32 senn_avgweight;
+ u32 senp_avgweight;
u32 err_minlimit;
u32 err_maxlimit;
+ u32 clk_length;
+ u32 err_weight;
u32 accum_data;
- u32 senn_avgweight;
- u32 senp_avgweight;
u32 senp_mod;
u32 senn_mod;
- unsigned intirq;
+
+ boolautocomp_active;
+ boolis_suspended;
+
void __iomem*base;
- struct platform_device *pdev;
- struct list_headnode;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain*voltdm;
+
struct dentry *dbg_dir;
};
@@ -73,11 +79,9 @@ static inline void sr_write_reg(struct omap_sr *sr, unsigned
offset, u32 value)
static inline void sr_modify_reg(struct omap_sr *sr, unsigned offset, u32 mask,
u32 value)
{
- u32 reg_val;
- u32 errconfig_offs = 0, errconfig_mask = 0;
-
- reg_val = __raw_readl(sr-base + offset);
- reg_val = ~mask;
+ u32 reg_val;
+ u32 errconfig_offs = 0;
+ u32 errconfig_mask = 0;
/*
* Smartreflex error config register is special as it contains
@@ -88,14 +92,23 @@ static inline void sr_modify_reg(struct omap_sr *sr,
unsigned offset, u32 mask,
* if they are currently set, but does allow the caller to write
* those bits.
*/
- if (sr-ip_type == SR_TYPE_V1) {
+ switch (sr-ip_type) {
+ case SR_TYPE_V1:
errconfig_offs = ERRCONFIG_V1;
errconfig_mask = ERRCONFIG_STATUS_V1_MASK;
- } else if (sr-ip_type == SR_TYPE_V2) {
+ break;
+ case SR_TYPE_V2:
errconfig_offs = ERRCONFIG_V2;
errconfig_mask = ERRCONFIG_VPBOUNDINTST_V2;
+ break;
+ default: /* should never happen */
+ dev_err(sr-pdev-dev, UNKNOWN IP type %d\n, sr-ip_type);
+ return;
}
+ reg_val = __raw_readl(sr-base + offset);
+ reg_val = ~mask;
+
if (offset == errconfig_offs)
reg_val = ~errconfig_mask;
@@ -111,7 +124,7 @@ static inline u32 sr_read_reg(struct omap_sr *sr, unsigned
offset)
static struct omap_sr *_sr_lookup(struct voltagedomain *voltdm)
{
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info;
if (!voltdm) {
pr_err(%s: Null voltage domain passed!\n, __func__);
@@ -128,33 +141,39 @@ static struct omap_sr *_sr_lookup(struct voltagedomain
*voltdm)
static irqreturn_t sr_interrupt(int irq, void *data)
{
- struct omap_sr *sr_info = (struct omap_sr *)data;
- u32 status = 0;
+ struct omap_sr *sr_info = data;
+ u32 status = 0;
- if (sr_info-ip_type == SR_TYPE_V1) {
+ switch (sr_info-ip_type) {
+ case SR_TYPE_V1:
/* Read the status bits */
status = sr_read_reg(sr_info, ERRCONFIG_V1);
/* Clear them by writing back */
sr_write_reg(sr_info, ERRCONFIG_V1, status);
- } else if (sr_info-ip_type == SR_TYPE_V2) {
+ break;
+ case SR_TYPE_V2:
/* Read the status bits */
[RFT/PATCH 6/7] arm: omap: smartreflex: fix IRQ handling bug
fix a bug which has been on this driver since it was added by the original commit 984aa6db which would never clear IRQSTATUS bits. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/smartreflex.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 6e9eb46..7bdabfa 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -154,7 +154,7 @@ static irqreturn_t sr_interrupt(int irq, void *data) break; case SR_TYPE_V2: /* Read the status bits */ - sr_read_reg(sr_info, IRQSTATUS); + status = sr_read_reg(sr_info, IRQSTATUS); /* Clear them by writing back */ sr_write_reg(sr_info, IRQSTATUS, status); -- 1.7.6.396.ge0613 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT/PATCH 7/7] arm: omap: smartreflex: micro-optimization for sanity check
val (val != 1) == val 1
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7bdabfa..4b0d6a8 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -866,7 +866,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
/* Sanity check */
- if (val (val != 1)) {
+ if (val 1) {
pr_warning(%s: Invalid argument %lld\n, __func__, val);
return -EINVAL;
}
--
1.7.6.396.ge0613
--
To unsubscribe from this list: send the line unsubscribe 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 01/13] hwspinlock: OMAP4: Add spinlock support in DT
Hi Benoit,
On Mon, Sep 26, 2011 at 7:50 PM, Benoit Cousson b-cous...@ti.com wrote:
+++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
@@ -0,0 +1,5 @@
+* HW spinlock on OMAP4 platform:
+
+Required properties:
+- compatible : Must be ti,omap4-spinlock;
+- ti,hwmods : spinlock
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..7a7f31e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -99,5 +99,10 @@
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
+
+ spinlock {
+ compatible = ti,omap4-spinlock;
+ ti,hwmods = spinlock;
+ };
I think it'd be nice to add the 'baseid' property as we discussed for
dynamic allocation of hwspinlocks.
The patch that adds the hwspinlock groundwork for this is in
linux-next and will hopefully get into 3.2 if everything works out
well:
https://lkml.org/lkml/2011/9/12/194
Of course, as we discussed with Arnd, we will use phandles to the
hwspinlock controller when we'll get to static allocations of
hwspinlock instances.
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 v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Mon, Oct 3, 2011 at 12:58 AM, Ohad Ben-Cohen o...@wizery.com wrote:
int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot)
+ phys_addr_t paddr, size_t size, int prot)
{
- size_t size;
+ int ret = 0;
+
+ /*
+ * both the virtual address and the physical one, as well as
+ * the size of the mapping, must be aligned (at least) to the
+ * size of the smallest page supported by the hardware
+ */
+ if (!IS_ALIGNED(iova | paddr | size, iommu_min_pagesz)) {
+ pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%lx min_pagesz
+ 0x%x\n, iova, (unsigned long)paddr,
+ (unsigned long)size, iommu_min_pagesz);
+ return -EINVAL;
+ }
- size = 0x1000UL gfp_order;
+ pr_debug(map: iova 0x%lx pa 0x%lx size 0x%lx\n, iova,
+ (unsigned long)paddr, (unsigned long)size);
- BUG_ON(!IS_ALIGNED(iova | paddr, size));
+ while (size) {
+ unsigned long pgsize, addr_merge = iova | paddr;
+ unsigned int pgsize_idx;
- return iommu_ops-map(domain, iova, paddr, gfp_order, prot);
+ /* Max page size that still fits into 'size' */
+ pgsize_idx = __fls(size);
+
+ /* need to consider alignment requirements ? */
+ if (likely(addr_merge)) {
+ /* Max page size allowed by both iova and paddr */
+ unsigned int align_pgsize_idx = __ffs(addr_merge);
+
+ pgsize_idx = min(pgsize_idx, align_pgsize_idx);
+ }
+
+ /* build a mask of acceptable page sizes */
+ pgsize = (1UL (pgsize_idx + 1)) - 1;
+
+ /* throw away page sizes not supported by the hardware */
+ pgsize = iommu_pgsize_bitmap;
+
+ /* pick the biggest page */
+ pgsize_idx = __fls(pgsize);
+ pgsize = 1UL pgsize_idx;
+
+ /* convert index to page order */
+ pgsize_idx -= PAGE_SHIFT;
+
+ pr_debug(mapping: iova 0x%lx pa 0x%lx order %u\n, iova,
+ (unsigned long)paddr, pgsize_idx);
+
+ ret = iommu_ops-map(domain, iova, paddr, pgsize_idx, prot);
+ if (ret)
+ break;
+
+ iova += pgsize;
+ paddr += pgsize;
+ size -= pgsize;
+ }
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_map);
Do not we need to unmap all intermediate mappings if iommu_map() is failed?
I think iommu_map() must map the entire given area if it successes.
Otherwise, it should map nothing.
I think it can be simply done with calling iommu_unmap()
with Joerg's previous suggestion about iommu_unmap().
Regards,
KyongHo.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: sound: fix checkpatch.pl error
Hi Mark, On 10/10/2011 11:32 AM, Mark Brown wrote: Applied, but please do try to make sure your changelogs resemble those for the rest of the subsystem. Especially for trivial patches it's not good to increase the effort required to apply them. Thanks! I will use ASoC in my commit messages if I understand correctly. I must confess I didn't pay enough attention to the list of recipients, which I just got from scripts/get_maintainer.pl. I will be more careful next time. Thanks again, Michael. -- Michael Opdenacker - Community Manager Linaro, http://linaro.org Cell: +33 621 604 642 IRC: 'opm' in #linaro on irc.freenode.net -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
[ -bouncing hiroshi.d...@nokia.com, +not-bouncing hd...@nvidia.com : hi Hiroshi :) ] Hi Joerg, On Mon, Oct 10, 2011 at 11:47 AM, Roedel, Joerg joerg.roe...@amd.com wrote: sorry, I was on vacation last week and had no time to look into this. Sure thing, thanks for replying! +#include linux/bitmap.h Is this still required? Nope, removed, thanks. Hmm, I thought a little bit about that and came to the conculusion it might be best to just keep the page-sizes as a part of the iommu_ops structure. So there is no need to extend the register_iommu interface. Sure. That was one of my initial alternatives, but I decided against it at that time. I'll bring it back - it will help with the bus_set_iommu rebasing. Also, the bus_set_iommu interface is now in the -next branch. Would be good if you rebase the patches to that interface. Sure. It's a little tricky though: which branch do I base this on ? Are you ok with me basing this on your 'next' branch ? My current stack depends at least on three branches of yours, so that would be helpful for me (and less merging conflicts for you I guess :). I think we need some care here and check pgsize for 0. A BUG_ON should do. I can add it if you prefer, but I don't think it can really happen: basically, it means that we chose a too small and unsupported page bit, which can't happen as long as we check for IS_ALIGNED(iova | paddr | size, iommu_min_pagesz) in the beginning of iommu_map. + unmapped_order = iommu_ops-unmap(domain, iova, order); I think we should make sure that we call iommu_ops-unmap with the same parameters as iommu_ops-map. Otherwise we still need some page-size complexity in the iommu-drivers. Ok, let's discuss the semantics of -unmap(). There isn't a clear documentation of that API (we should probably add some kernel docs after we nail it down now), but judging from the existing users (mainly kvm) and drivers, it seems that iommu_map() and iommu_unmap() aren't symmetric: users rely on unmap() to return the actual size that was unmapped. IOMMU drivers, in turn, should check which page is mapped on 'iova', unmap it, and return its size. This way iommu_unmap() becomes very simple: it just iterates through the region, relying on iommu_ops-unmap() to return the sizes that were actually unmapped (very similar to how amd's iommu_unmap_page works today). This also means that iommu_ops-unmap() doesn't really need a size/order argument and we can remove it (after all drivers fully migrate..). The other approach which you suggest means symmetric iommu_map() and iommu_unmap(). It means adding a 'paddr' parameter to iommu_unmap(), which is easy, but maybe more concerning is the limitation that it incurs: users will now have to call iommu_unmap() exactly as they called iommu_map() beforehand. Note sure how well this will fly with the existing users (kvm ?) and whether we really want to enforce this (it doesn't mean drivers need to deal with page-size complexity. they are required to unmap a single page at a time, and iommu_unmap() will do the work for them). Another discussion: I think we better change iommu_ops-map() to directly take a 'size' (in bytes) instead of an 'order' (of pages). Most (all?) drivers just immediately do 'size = 0x1000UL gfp_order', so this whole size - order - size back and forth seems redundant. When we pass the size now it makes sense to also return the unmapped-size instead of the order. Sure. Thanks for your review, 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 v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Mon, Oct 10, 2011 at 2:52 PM, KyongHo Cho pullip@samsung.com wrote: Do not we need to unmap all intermediate mappings if iommu_map() is failed? Good idea, I'll add 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
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, 10 Oct 2011, Felipe Balbi wrote: do we have sibling structures today? I dont think so. no we don't. Ok, here's a first shot at it: In fact we do already have sibling lists. They are maintained as part of the device_private structure. What we are missing is a device_for_each_sibling() routine. It could be added pretty easily; it would be similar to device_for_each_child(). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
Hi Ohad, On Mon, Oct 10, 2011 at 09:59:22AM -0400, Ohad Ben-Cohen wrote: Also, the bus_set_iommu interface is now in the -next branch. Would be good if you rebase the patches to that interface. Sure. It's a little tricky though: which branch do I base this on ? Are you ok with me basing this on your 'next' branch ? My current stack depends at least on three branches of yours, so that would be helpful for me (and less merging conflicts for you I guess :). The master branch is best to base your patches on for generic work. For more specific things like omap-only changes you can use the topic branches. I think we need some care here and check pgsize for 0. A BUG_ON should do. I can add it if you prefer, but I don't think it can really happen: basically, it means that we chose a too small and unsupported page bit, which can't happen as long as we check for IS_ALIGNED(iova | paddr | size, iommu_min_pagesz) in the beginning of iommu_map. It can happen when there is a bug somewhere :) So a BUG_ON will yell then and makes debugging easier. An alternative is to use a WARN_ON and let the map-call fail in this case. Ok, let's discuss the semantics of -unmap(). There isn't a clear documentation of that API (we should probably add some kernel docs after we nail it down now), but judging from the existing users (mainly kvm) and drivers, it seems that iommu_map() and iommu_unmap() aren't symmetric: users rely on unmap() to return the actual size that was unmapped. IOMMU drivers, in turn, should check which page is mapped on 'iova', unmap it, and return its size. Right, currently the map/unmap calls are not symetric. But I think they should be to get a clean semantic. Without this requirement and multiple page-sizes in use the iommu-code may has to unmap more address space then requested. The user doesn't know what will be unmapped so it has to make sure that no DMA is happening while unmap runs. When we require the calls to be symetric we can give a guarantee that only the requested region is unmapped and allow DMA to the untouched part of the address-space while unmap() is running. So when the call-places to not follow this restriction we should convert them mid-term. This way iommu_unmap() becomes very simple: it just iterates through the region, relying on iommu_ops-unmap() to return the sizes that were actually unmapped (very similar to how amd's iommu_unmap_page works today). This also means that iommu_ops-unmap() doesn't really need a size/order argument and we can remove it (after all drivers fully migrate..). Yes, somthing like that. Probably the iommu_ops-unmap function should be turned into a unmap_page function call which only takes an iova and no size parameter. The iommu-driver unmaps the page pointing to that iova and returns the size of the page unmapped. This still allows the simple implementation for the unmap-call. This change is no requirement for this patch-set, but if we agree on it this patch-set should keep that direction in mind. The other approach which you suggest means symmetric iommu_map() and iommu_unmap(). It means adding a 'paddr' parameter to iommu_unmap(), which is easy, but maybe more concerning is the limitation that it incurs: users will now have to call iommu_unmap() exactly as they called iommu_map() beforehand. Note sure how well this will fly with the existing users (kvm ?) and whether we really want to enforce this (it doesn't mean drivers need to deal with page-size complexity. they are required to unmap a single page at a time, and iommu_unmap() will do the work for them). It will work with KVM, that is no problem. We don't need to really enforce the calls to be symetric. But we can define that we only give the guarantee about what will be unmapped when the calls are symetric. For example: iommu_map( 0, 0x10); iommu_unmap(0, 0x10); /* Guarantee that it will only unmap the range 0-0x10 */ whereas: iommu_map( 0, 0x10); iommu_unmap(0, 0x1000); /* Guarantees that 0-0x1000 is unmapped, but other undefined parts of the address space may be unmapped too, up to the whole address space */ The alternative is that we implement page-splitting in the iommu_unmap function. But that introduces complexity I am not sure we really need. KVM for example just unmaps the whole address-space on destruction. For the generic dma_ops this is also not required because the dma_map* functions already have the requirement to be symetric. Another discussion: I think we better change iommu_ops-map() to directly take a 'size' (in bytes) instead of an 'order' (of pages). Most (all?) drivers just immediately do 'size = 0x1000UL gfp_order', so this whole size - order - size back and forth seems redundant.
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
On Mon, 10 Oct 2011, Felipe Balbi wrote:
do we have sibling structures today? I dont think so.
no we don't.
Ok, here's a first shot at it:
In fact we do already have sibling lists. They are maintained as part
of the device_private structure. What we are missing is a
device_for_each_sibling() routine. It could be added pretty easily; it
would be similar to device_for_each_child().
care to point out where is ?
68 struct device_private {
69 struct klist klist_children;
70 struct klist_node knode_parent;
71 struct klist_node knode_driver;
72 struct klist_node knode_bus;
73 void *driver_data;
74 struct device *device;
75 };
--
balbi
signature.asc
Description: Digital signature
[PATCH v2 0/5] Device tree support for regulators
Hi Mark, Grant, I have reworked the regulator-dt-suppport series based on your reviews and also split it so I remove any dependency with the omap specific dt conversion for i2c/twl. So this latest series is based on mainline 3.1-rc9. I will post the twl-regulator driver adaptation to dt and the omap-panda/omap-sdp board regulator data being passed from dt as a seperate series. changes in v2: -1- removed the int to u32 convertions as -ve voltages do exist -2- merged patches to support fixed voltage regulator dt adaptation -3- added support for regulator_get() without a device associated (ex: cpufreq) -4- used same binding for regulator-consumer and regulator-parent mapping regards, Rajendra Rajendra Nayak (5): regulator: twl: Remove hardcoded board constraints from driver dt: add empty dt helpers for non-dt build regulator: helper routine to extract regulator_init_data regulator: adapt fixed regulator driver to dt regulator: map consumer regulator based on device tree .../bindings/regulator/fixed-regulator.txt | 24 + .../devicetree/bindings/regulator/regulator.txt| 44 + drivers/regulator/Kconfig |8 ++ drivers/regulator/Makefile |1 + drivers/regulator/core.c | 91 --- drivers/regulator/fixed.c | 58 drivers/regulator/of_regulator.c | 93 drivers/regulator/twl-regulator.c |8 -- include/linux/of.h | 19 include/linux/regulator/driver.h |2 + include/linux/regulator/of_regulator.h | 21 + 11 files changed, 346 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt create mode 100644 drivers/regulator/of_regulator.c create mode 100644 include/linux/regulator/of_regulator.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
[PATCH v2 2/5] dt: add empty dt helpers for non-dt build
Add empty of_device_is_compatible(), of_find_property()
and of_parse_phandle() for non-dt builds to work.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
include/linux/of.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 9180dc5..47ce461 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -263,6 +263,25 @@ static inline const void *of_get_property(const struct
device_node *node,
return NULL;
}
+static inline int of_device_is_compatible(const struct device_node *device,
+ const char *name)
+{
+ return 0;
+}
+
+static inline struct property *of_find_property(const struct device_node *np,
+const char *name,
+int *lenp)
+{
+ return NULL;
+}
+
+static inline struct device_node *of_parse_phandle(struct device_node *np,
+ const char *phandle_name,
+ int index)
+{
+ return NULL;
+}
#endif /* CONFIG_OF */
static inline int of_property_read_u32(const struct device_node *np,
--
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
[PATCH v2 1/5] regulator: twl: Remove hardcoded board constraints from driver
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/regulator/twl-regulator.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index ee8747f..f696287 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1027,14 +1027,6 @@ static int __devinit twlreg_probe(struct platform_device
*pdev)
/* copy the features into regulator data */
info-features = (unsigned long)initdata-driver_data;
- /* Constrain board-specific capabilities according to what
-* this driver and the chip itself can actually do.
-*/
- c = initdata-constraints;
- c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
- c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS;
switch (pdev-id) {
case TWL4030_REG_VIO:
case TWL4030_REG_VDD1:
--
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
[PATCH v2 5/5] regulator: map consumer regulator based on device tree
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = regulator1;
vpll-supply = regulator1;
};
The driver would then do a regulator_get(dev, vmmc); to get
regulator1 and do a regulator_get(dev, vpll); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Use it to look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
drivers/regulator/core.c | 91 +++--
include/linux/regulator/driver.h |2 +
2 files changed, 78 insertions(+), 15 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..9a5ebbe 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,9 +25,11 @@
#include linux/mutex.h
#include linux/suspend.h
#include linux/delay.h
+#include linux/of.h
#include linux/regulator/consumer.h
#include linux/regulator/driver.h
#include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
#define CREATE_TRACE_POINTS
#include trace/events/regulator.h
@@ -131,6 +133,33 @@ static struct regulator *get_device_regulator(struct
device *dev)
return NULL;
}
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
+ struct device_node *regnode = NULL;
+ char prop_name[32]; /* 32 is max size of property name */
+
+ dev_dbg(dev, Looking up %s-supply from device tree\n, supply);
+
+ snprintf(prop_name, 32, %s-supply, supply);
+ regnode = of_parse_phandle(dev-of_node, prop_name, 0);
+
+ if (!regnode) {
+ pr_warn(%s: %s property in node %s references invalid phandle,
+ __func__, prop_name, dev-of_node-full_name);
+ return NULL;
+ }
+ return regnode;
+}
+
/* Platform voltage constraint check */
static int regulator_check_voltage(struct regulator_dev *rdev,
int *min_uV, int *max_uV)
@@ -1155,6 +1184,7 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
struct regulator_map *map;
struct regulator *regulator = ERR_PTR(-ENODEV);
const char *devname = NULL;
+ struct device_node *node;
int ret;
if (id == NULL) {
@@ -1167,6 +1197,23 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
mutex_lock(regulator_list_mutex);
+ /*
+* Lookup happens in 3 ways
+* 1. If a dev and dev-of_node exist, look for a
+* regulator mapping in dt node.
+* 2. Check if a match can be found in regulator_map_list
+* if regulator info is still passed in non-dt way
+* 3. if !dev, then just look for a matching regulator name.
+* Useful for dt builds using regulator_get() without specifying
+* a device.
+*/
+ if (dev dev-of_node) {
+ node = of_get_regulator(dev, id);
+ if (node)
+ list_for_each_entry(rdev, regulator_list, list)
+ if (node == rdev-dev.parent-of_node)
+ goto found;
+ }
list_for_each_entry(map, regulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map-dev_name
@@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+ if (!dev)
+ list_for_each_entry(rdev, regulator_list, list)
+ if (strcmp(rdev_get_name(rdev), id))
+ goto found;
if (board_wants_dummy_regulator) {
rdev = dummy_regulator_rdev;
@@ -2579,6 +2630,7 @@ struct regulator_dev *regulator_register(struct
regulator_desc *regulator_desc,
static atomic_t regulator_no = ATOMIC_INIT(0);
struct regulator_dev *rdev;
int ret, i;
+ const char *supply;
if (regulator_desc ==
[PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Similarly the regulator--parent/supply mapping is handled in
subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt| 44 +
drivers/regulator/Kconfig |8 ++
drivers/regulator/Makefile |1 +
drivers/regulator/of_regulator.c | 93
include/linux/regulator/of_regulator.h | 21 +
5 files changed, 167 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/regulator/of_regulator.c
create mode 100644 include/linux/regulator/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..a623fdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,44 @@
+Voltage/Current Regulators
+
+Optional properties:
+- regulator-min-uV: smallest voltage consumers may set
+- regulator-max-uV: largest voltage consumers may set
+- regulator-uV-offset: Offset applied to voltages to compensate for voltage
drops
+- regulator-min-uA: smallest current consumers may set
+- regulator-max-uA: largest current consumers may set
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator-change-mode: boolean, Operating mode can be changed by software
+- regulator-change-status: boolean, Enable/Disable control for regulator exists
+- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled
+- regulator-mode-fast: boolean, allow/set fast mode for the regulator
+- regulator-mode-normal: boolean, allow/set normal mode for the regulator
+- regulator-mode-idle: boolean, allow/set idle mode for the regulator
+- regulator-mode-standby: boolean, allow/set standby mode for the regulator
+- regulator-input-uV: Input voltage for regulator when supplied by another
regulator
+- regulator-always-on: boolean, regulator should never be disabled
+- regulator-boot-on: bootloader/firmware enabled regulator
+- name-supply: phandle to the parent supply/regulator node
+
+Example:
+
+ xyzreg: regulator@0 {
+ regulator-min-uV = 100;
+ regulator-max-uV = 250;
+ regulator-mode-fast;
+ regulator-change-voltage;
+ regulator-always-on;
+ vin-supply = vin;
+ };
+
+The same binding used by a regulator to reference its
+supply can be used by any consumer to reference its
+regulator/supply
+
+Example of a device node referencing a regulator node,
+
+ devicenode: node@0x0 {
+ ...
+ ...
+ name-supply = xyzreg;
+ };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c7fd2c0..981c92e 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -64,6 +64,14 @@ config REGULATOR_USERSPACE_CONSUMER
If unsure, say no.
+config OF_REGULATOR
+ tristate OF regulator helpers
+ depends on OF
+ default y if OF
+ help
+ OpenFirmware regulator framework helper routines that can
+ used by regulator drivers to extract data from device tree.
+
config REGULATOR_BQ24022
tristate TI bq24022 Dual Input 1-Cell Li-Ion Charger IC
help
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 040d5aa..e6bc009 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_REGULATOR) += core.o dummy.o
obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
obj-$(CONFIG_REGULATOR_BQ24022) += bq24022.o
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
new file mode 100644
index 000..9262d06
--- /dev/null
+++ b/drivers/regulator/of_regulator.c
@@ -0,0 +1,93 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software
[PATCH v2 4/5] regulator: adapt fixed regulator driver to dt
The fixed regulator driver uses of_get_fixed_voltage_config()
to extract fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../bindings/regulator/fixed-regulator.txt | 25 +
drivers/regulator/fixed.c | 58
2 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
new file mode 100644
index 000..049df3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -0,0 +1,25 @@
+Fixed Voltage regulators
+
+Required properties:
+- compatible: Must be regulator-fixed;
+
+Optional properties:
+- regulator-fixed-supply: Name of the regulator supply
+- regulator-fixed-microvolts: Output voltage of regulator
+- regulator-fixed-gpio: gpio to use for enable control
+- regulator-fixed-startup-delay: startup time in microseconds
+- regulator-fixed-enable-high: Polarity of enable GPIO,
+ 1 = Active High, 0 = Active low
+- regulator-fixed-enabled-at-boot: 1 = yes, 0 = no
+
+Example:
+
+ abc: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-fixed-supply = fixed-supply;
+ regulator-fixed-microvolts = 180;
+ regulator-fixed-gpio = 43;
+ regulator-fixed-startup-delay = 7;
+ regulator-fixed-enable-high;
+ regulator-fixed-enabled-at-boot;
+ };
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 2fe9d99..eb37eb6 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -23,9 +23,12 @@
#include linux/platform_device.h
#include linux/regulator/driver.h
#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include linux/gpio.h
#include linux/delay.h
#include linux/slab.h
+#include linux/of.h
+#include linux/regulator/of_regulator.h
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -37,6 +40,47 @@ struct fixed_voltage_data {
bool is_enabled;
};
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
+{
+ struct fixed_voltage_config *config;
+ struct device_node *np = dev-of_node;
+ const __be32 *microvolts, *gpio, *delay;
+
+ config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config),
GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config-supply_name = (char *)of_get_property(np,
+ regulator-fixed-supply, NULL);
+ microvolts = of_get_property(np, regulator-fixed-microvolts, NULL);
+ if (microvolts)
+ config-microvolts = be32_to_cpu(*microvolts);
+ gpio = of_get_property(np, regulator-fixed-gpio, NULL);
+ if (gpio)
+ config-gpio = be32_to_cpu(*gpio);
+ delay = of_get_property(np, regulator-fixed-startup-delay, NULL);
+ if (delay)
+ config-startup_delay = be32_to_cpu(*delay);
+
+ if (of_find_property(np, regulator-fixed-enable-high, NULL))
+ config-enable_high = true;
+ if (of_find_property(np, regulator-fixed-enabled-at-boot, NULL))
+ config-enabled_at_boot = true;
+
+ config-init_data = of_get_regulator_init_data(dev);
+
+ return config;
+}
+
static int fixed_voltage_is_enabled(struct regulator_dev *dev)
{
struct fixed_voltage_data *data = rdev_get_drvdata(dev);
@@ -108,6 +152,9 @@ static int __devinit reg_fixed_voltage_probe(struct
platform_device *pdev)
struct fixed_voltage_data *drvdata;
int ret;
+ if (pdev-dev.of_node)
+ config = of_get_fixed_voltage_config(pdev-dev);
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(pdev-dev, Failed to allocate device data\n);
@@ -216,12 +263,23 @@ static int __devexit reg_fixed_voltage_remove(struct
platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+ { .compatible = regulator-fixed, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_of_match NULL
+#endif
+
static struct platform_driver regulator_fixed_voltage_driver = {
.probe = reg_fixed_voltage_probe,
.remove =
Re: [PATCH v2 1/5] regulator: twl: Remove hardcoded board constraints from driver
On Mon, Oct 10, 2011 at 09:49:34PM +0530, Rajendra Nayak wrote: Remove the hardcoded .valid_modes_mask and .valid_ops_mask for each regulator from the twl driver and let the boards pass it. Signed-off-by: Rajendra Nayak rna...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Please update this changelog - as I said in reply to your previous posting this isn't actually hardcoding anything, it's dropping things from the constraints which the hardware doesn't support. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] regulator: twl: Remove hardcoded board constraints from driver
On Monday 10 October 2011 09:55 PM, Mark Brown wrote: On Mon, Oct 10, 2011 at 09:49:34PM +0530, Rajendra Nayak wrote: Remove the hardcoded .valid_modes_mask and .valid_ops_mask for each regulator from the twl driver and let the boards pass it. Signed-off-by: Rajendra Nayakrna...@ti.com Acked-by: Mark Brownbroo...@opensource.wolfsonmicro.com Please update this changelog - as I said in reply to your previous posting this isn't actually hardcoding anything, it's dropping things from the constraints which the hardware doesn't support. Looks like I completely missed the = and your comment on the previous posting. Looking at it now, seems to me this patch is just un-necessary and what the driver seems to be doing (preventing users from setting flags which the hardware does not support) seems perfectly fine. I will just go ahead and drop this patch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
Hi Joerg, On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg joerg.roe...@amd.com wrote: The master branch is best to base your patches on for generic work. Oh, great. thanks. It can happen when there is a bug somewhere :) Hmm, bug ? ;) Ok, I'll add a BUG_ON :) Yes, somthing like that. Probably the iommu_ops-unmap function should be turned into a unmap_page function call which only takes an iova and no size parameter. The iommu-driver unmaps the page pointing to that iova and returns the size of the page unmapped. This still allows the simple implementation for the unmap-call. Yes, exactly. It will take some time to migrate all drivers (today we have 4 drivers, each of which is implementing a slightly different -unmap() semantics), but at least let's not accept any new driver that doesn't adhere to this, otherwise it's going to be even harder for the API to evolve. This change is no requirement for this patch-set, but if we agree on it this patch-set should keep that direction in mind. Definitely, thanks. We don't need to really enforce the calls to be symetric. But we can define that we only give the guarantee about what will be unmapped when the calls are symetric. Sounds good to me. I'll add this to the kernel doc patch (which I'll submit after this patch set materializes), and when/if we move to symmetric only, we will update it. The alternative is that we implement page-splitting in the iommu_unmap function. But that introduces complexity I am not sure we really need. Yeah, me neither. Yes, this get_order thing should be changes to size long-term. Good. That should be a simple change, I'll do it after this patch set. 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 v2 3/5] regulator: helper routine to extract regulator_init_data
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote: +- regulator-change-voltage: boolean, Output voltage can be changed by software +- regulator-change-current: boolean, Output current can be chnaged by software +- regulator-change-mode: boolean, Operating mode can be changed by software +- regulator-change-status: boolean, Enable/Disable control for regulator exists +- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled +- regulator-mode-fast: boolean, allow/set fast mode for the regulator +- regulator-mode-normal: boolean, allow/set normal mode for the regulator +- regulator-mode-idle: boolean, allow/set idle mode for the regulator +- regulator-mode-standby: boolean, allow/set standby mode for the regulator +- regulator-input-uV: Input voltage for regulator when supplied by another regulator +- regulator-always-on: boolean, regulator should never be disabled Thinking about this I'm not sure that these should go in the device tree, they're as much talking about what Linux is able to cope with as they are talking about what the hardware is able to do. Sometimes they'll be fixed by the design but they are sometimes also restricted by what the software is currently capable of. DRMS is a prime example here, it depends on how good we are at telling the API about how much current we're using. -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP: omap_device: Add omap_device_{alloc, delete, register}_ss
Ohad Ben-Cohen o...@wizery.com writes: Hi Kevin, On Wed, Oct 5, 2011 at 6:54 PM, Ohad Ben-Cohen o...@wizery.com wrote: Split omap_device_build_ss() into two smaller functions: ... This patch is considered an interim solution until DT fully materializes for omap; at that point, this functionality will be removed. Good news: we might not need this after all. Great. I need the remoteproc devices to exists at -reserve() time, so I can assign them a private CMA pool, which means I can't wait for omap_device_build_ss() and must create the devices beforehand. ... which makes Benoit's alloc/delete methods perfect for me. So please hold this one off for now. I'd just need a s/static// patch that will allow me to use Benoit's methods outside of omap_device.c, but I'll wait for things to settle down a bit before sending it, to minimize this kind of churn. OK. Sounds good. Thanks, Kevin Thanks and sorry for the noise, 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 v2 5/5] regulator: map consumer regulator based on device tree
On Mon, Oct 10, 2011 at 09:49:38PM +0530, Rajendra Nayak wrote:
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
Mostly looks good.
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
Should be static.
@@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+ if (!dev)
+ list_for_each_entry(rdev, regulator_list, list)
+ if (strcmp(rdev_get_name(rdev), id))
+ goto found;
This looks really strange, we didn't remove any old lookup code and the
DT lookup jumps to found by iself so why are we adding code here?
+ if (supply) {
+ struct regulator_dev *r;
+ struct device_node *node;
+
+ /* first do a dt based lookup */
+ if (dev) {
+ node = of_get_regulator(dev, supply);
+ if (node)
+ list_for_each_entry(r, regulator_list, list)
+ if (node == r-dev.parent-of_node)
+ goto found;
}
- if (!found) {
- dev_err(dev, Failed to find supply %s\n,
- init_data-supply_regulator);
- ret = -ENODEV;
- goto scrub;
- }
+ /* next try doing it non-dt way */
+ list_for_each_entry(r, regulator_list, list)
+ if (strcmp(rdev_get_name(r), supply) == 0)
+ goto found;
+ dev_err(dev, Failed to find supply %s\n, supply);
+ ret = -ENODEV;
+ goto scrub;
+
+found:
This is all getting *really* complicated and illegible. I'm not sure
what the best way to structure is but erroring out early looks useful.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
Hi, - Original Message - From: Greg KH g...@kroah.com To: Josh Triplett j...@joshtriplett.org Cc: G, Manjunath Kondaiah manj...@ti.com, linux-arm-ker...@lists.infradead.org, Grant Likely grant.lik...@secretlab.ca, linux-omap@vger.kernel.org, linux-...@vger.kernel.org, linux-ker...@vger.kernel.org, Dilan Lee di...@nvidia.com, Mark Brown broo...@opensource.wolfsonmicro.com, manjun...@jasper.es Sent: Saturday, October 8, 2011 11:55:02 AM Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume. device_initialize-device_pm_init are called from device_register, so certainly this patch doesn't also ensure that the PM ordering matches probe ordering, which is bound to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the PM change be also part of this patch set? I don't see why you would want to have this in without the PM changes. Maybe I have it all wrong though :-). A -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds OMAP4 MPUSS (MPU SubSystem) power management support for suspend (S2R), CPU hotplug and CPUidle. There are a few more compile errors when doing OMAP1-only builds. You'll need a way to eliminate the secure calls for OMAP1. This series causes a couple build errors when doing OMAP1-only builds (I used omap1_defconfig): First: /work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error: mach/omap-secure.h: No such file or directory And trying creating a dummy header to see if it would continue to build gives: /work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve': /work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit declaration of function 'omap_secure_ram_reserve_memblock' make[2]: *** [arch/arm/plat-omap/common.o] Error 1 make[1]: *** [arch/arm/plat-omap] Error 2 Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2+: stub out omap*_volt_data
Arnd Bergmann a...@arndb.de writes: When CONFIG_PM_OPP is not set, the definitions for these variables are not available, so we should conditionally define them to NULL. arch/arm/mach-omap2/built-in.o: In function `omap3xxx_voltagedomains_init': voltagedomains3xxx_data.c:100: undefined reference to `omap36xx_vddmpu_volt_data' voltagedomains3xxx_data.c:100: undefined reference to `omap34xx_vddmpu_volt_data' voltagedomains3xxx_data.c:100: undefined reference to `omap36xx_vddcore_volt_data' voltagedomains3xxx_data.c:100: undefined reference to `omap34xx_vddcore_volt_data' arch/arm/mach-omap2/built-in.o: In function `omap44xx_voltagedomains_init': voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_mpu_volt_data' voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_iva_volt_data' voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_core_volt_data' Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Kevin Hilman khil...@ti.com --- I got this build error only now after pulling in the latest omap series, but I cannot tell what caused it. It's also not clear to me if this is the correct solution. Please ack or provide a better fix. This code was merged for v2.6.39, so not sure why this error is only showing up for you now. I just tried a !CONFIG_PM_OPP build on v2.6.39 and get the same errors, so it's been lingering. Maybe you haven't had a randconfig that disabled CONFIG_PM_OPP before? Anyways, the fix is fine with me. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] leds-class: change back LEDS_CLASS to tristate instead of bool
On Tue, Sep 27, 2011 at 04:50:32PM +0800, Bryan Wu wrote: LEDS_CLASS is required by leds and trigger drivers, but we can build it as module. So change this option back as tristate and treak the help message as well. LEDS_TRIGGERS depends on LEDS_CLASSS, which should be tristate. So set it as tristate too and update header files as well. Change those ifdefs to take care of module configuration. Signed-off-by: Bryan Wu bryan...@canonical.com Won't this break linking if POWER_SUPPLY=y and LEDS_TRIGGERS=m? Thanks, -- Anton Vorontsov Email: cbouatmai...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
Hi Tero
On Fri, 23 Sep 2011, Tero Kristo wrote:
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristo t-kri...@ti.com
Here's an updated version of this one. The one change is that the hwmod's
name is now prm3xxx to reflect that the register layout of this IP block
is quite different from its OMAP2 predecessors and OMAP4 successors.
This should avoid some of the special-purpose driver probing code.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Mon, 10 Oct 2011 13:11:11 -0600
Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod
Add a hwmod for the Power Reset Management (PRM) IP block that is
present on OMAP3xxx SoCs.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..382fad9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -160,6 +160,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
static struct omap_hwmod omap3xxx_uart1_hwmod;
static struct omap_hwmod omap3xxx_uart2_hwmod;
static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -475,6 +476,29 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+ {
+ .pa_start = 0x48306000,
+ .pa_end = 0x48306000 + SZ_8K + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* L4_WKUP - PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+ .master = omap3xxx_l4_wkup_hwmod,
+ .slave = omap3xxx_prm_hwmod,
+ .clk= wkup_l4_ick,
+ .addr = omap3xxx_prm_addrs,
+ .user = OCP_USER_MPU,
+};
+
+/* Master interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
+ omap3xxx_l4_wkup__prm,
+};
+
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
omap3xxx_l4_core__l4_wkup,
@@ -484,11 +508,46 @@ static struct omap_hwmod_ocp_if
*omap3xxx_l4_wkup_slaves[] = {
static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
.name = l4_wkup,
.class = l4_hwmod_class,
+ .masters= omap3xxx_l4_wkup_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
.slaves = omap3xxx_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
.flags = HWMOD_NO_IDLEST,
};
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+ omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+ .rev_offs = 0x0804,
+ .sysc_offs = 0x0814,
+ .sysc_flags = SYSC_HAS_AUTOIDLE,
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+ .name = prm,
+ .sysc = omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+ { .irq = 11 },
+ { .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+ .name = prm3xxx,
+ .mpu_irqs = omap3xxx_prm_irqs,
+ .class = omap3xxx_prm_hwmod_class,
+ .main_clk = wkup_32k_fck,
+ .slaves = omap3xxx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_prm_slaves),
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* Master interfaces on the MPU device */
static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
omap3xxx_mpu__l3_main,
@@ -3128,6 +3187,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_core_hwmod,
omap3xxx_l4_per_hwmod,
omap3xxx_l4_wkup_hwmod,
+
+ omap3xxx_prm_hwmod,
+
omap3xxx_mmc1_hwmod,
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
--
1.7.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: new miscellaneous clock/hwmod data for 3.2
Hi Tony, The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 clock_hwmod_devel_3.2 Benoit Cousson (1): ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4 Keshava Munegowda (1): ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3 Paul Walmsley (1): ARM: OMAP3xxx: hwmod data: add PRM hwmod Santosh Shilimkar (1): ARM: OMAP4: clock: Add CPU local timer clock node. arch/arm/mach-omap2/clock44xx_data.c |9 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206 - 3 files changed, 493 insertions(+), 1 deletions(-) - Paul -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
Hi Paul,
On 10/10/2011 9:24 PM, Paul Walmsley wrote:
Hi Tero
On Fri, 23 Sep 2011, Tero Kristo wrote:
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristot-kri...@ti.com
Here's an updated version of this one. The one change is that the hwmod's
name is now prm3xxx to reflect that the register layout of this IP block
is quite different from its OMAP2 predecessors and OMAP4 successors.
This should avoid some of the special-purpose driver probing code.
This is not really aligned with the naming convention we've been using
so far.
In both cases, the hwmod should just be named prm. If a version
information is needed, then it should be added in the revision class field.
It will make the device creation even simpler and not dependent of the
SoC version.
I did not check the whole series, but I'm not sure we need a special
treatment in the case of the prm.
Regards,
Benoit
- Paul
From: Paul Walmsleyp...@pwsan.com
Date: Mon, 10 Oct 2011 13:11:11 -0600
Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod
Add a hwmod for the Power Reset Management (PRM) IP block that is
present on OMAP3xxx SoCs.
Signed-off-by: Paul Walmsleyp...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..382fad9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -160,6 +160,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
static struct omap_hwmod omap3xxx_uart1_hwmod;
static struct omap_hwmod omap3xxx_uart2_hwmod;
static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -475,6 +476,29 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+ {
+ .pa_start = 0x48306000,
+ .pa_end = 0x48306000 + SZ_8K + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* L4_WKUP - PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+ .master =omap3xxx_l4_wkup_hwmod,
+ .slave =omap3xxx_prm_hwmod,
+ .clk= wkup_l4_ick,
+ .addr = omap3xxx_prm_addrs,
+ .user = OCP_USER_MPU,
+};
+
+/* Master interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
+ omap3xxx_l4_wkup__prm,
+};
+
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
omap3xxx_l4_core__l4_wkup,
@@ -484,11 +508,46 @@ static struct omap_hwmod_ocp_if
*omap3xxx_l4_wkup_slaves[] = {
static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
.name = l4_wkup,
.class =l4_hwmod_class,
+ .masters= omap3xxx_l4_wkup_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
.slaves = omap3xxx_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
.flags = HWMOD_NO_IDLEST,
};
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+ omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+ .rev_offs = 0x0804,
+ .sysc_offs = 0x0814,
+ .sysc_flags = SYSC_HAS_AUTOIDLE,
+ .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+ .name = prm,
+ .sysc =omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+ { .irq = 11 },
+ { .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+ .name = prm3xxx,
+ .mpu_irqs = omap3xxx_prm_irqs,
+ .class =omap3xxx_prm_hwmod_class,
+ .main_clk = wkup_32k_fck,
+ .slaves = omap3xxx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_prm_slaves),
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* Master interfaces on the MPU device */
static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
omap3xxx_mpu__l3_main,
@@ -3128,6 +3187,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_core_hwmod,
omap3xxx_l4_per_hwmod,
omap3xxx_l4_wkup_hwmod,
+
+ omap3xxx_prm_hwmod,
+
omap3xxx_mmc1_hwmod,
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, 10 Oct 2011, Felipe Balbi wrote:
On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
On Mon, 10 Oct 2011, Felipe Balbi wrote:
do we have sibling structures today? I dont think so.
no we don't.
Ok, here's a first shot at it:
In fact we do already have sibling lists. They are maintained as part
of the device_private structure. What we are missing is a
device_for_each_sibling() routine. It could be added pretty easily; it
would be similar to device_for_each_child().
care to point out where is ?
68 struct device_private {
69 struct klist klist_children;
70 struct klist_node knode_parent;
-^ Here. The parent in the name refers to where the
head of the list is stored.
71 struct klist_node knode_driver;
72 struct klist_node knode_bus;
73 void *driver_data;
74 struct device *device;
75 };
From device_add():
if (parent)
klist_add_tail(dev-p-knode_parent,
parent-p-klist_children);
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi,
On Mon, Oct 10, 2011 at 03:55:30PM -0400, Alan Stern wrote:
On Mon, 10 Oct 2011, Felipe Balbi wrote:
On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
On Mon, 10 Oct 2011, Felipe Balbi wrote:
do we have sibling structures today? I dont think so.
no we don't.
Ok, here's a first shot at it:
In fact we do already have sibling lists. They are maintained as part
of the device_private structure. What we are missing is a
device_for_each_sibling() routine. It could be added pretty easily; it
would be similar to device_for_each_child().
care to point out where is ?
68 struct device_private {
69 struct klist klist_children;
70 struct klist_node knode_parent;
-^ Here. The parent in the name refers to where the
head of the list is stored.
71 struct klist_node knode_driver;
72 struct klist_node knode_bus;
73 void *driver_data;
74 struct device *device;
75 };
From device_add():
if (parent)
klist_add_tail(dev-p-knode_parent,
parent-p-klist_children);
that's a parent - child relationship. What we have on this case is:
-----
| | | | |\
| UHH| clocks, etc |USBTLL | | |
| | == | | == | | ports
| --- | | (Transceiver- | | |
|| EHCI | | | less Link)| |/
| --- | | | Port MUX
| | | |
| --- | | |
|| OHCI | | | |
| --- | | |
| | | |
-----
It doesn't shown here, but the TLL link is completely optional. It's
mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
and OHCI will depend on a clock provided by the USBTLL block.
Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
blocks. We can, from a code perspective, make USBTLL into a parent of
UHH to make things simpler, but this will mean that calling
pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
That's why I decided for making TLL and UHH siblings, because that's a
closer relationship than parent-child.
Can you see the problem now ?
ps: the best picture is on TI's OMAP4430 TRM (it's publicly available
from TI's website). So, if you want a better rendering of the
integration model, take a look at chapter 23.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
On Mon, 10 Oct 2011, Cousson, Benoit wrote: Hi Paul, On 10/10/2011 9:24 PM, Paul Walmsley wrote: Hi Tero On Fri, 23 Sep 2011, Tero Kristo wrote: This patch is temporary until Paul can provide a final version. Signed-off-by: Tero Kristot-kri...@ti.com Here's an updated version of this one. The one change is that the hwmod's name is now prm3xxx to reflect that the register layout of this IP block is quite different from its OMAP2 predecessors and OMAP4 successors. This should avoid some of the special-purpose driver probing code. This is not really aligned with the naming convention we've been using so far. In both cases, the hwmod should just be named prm. If a version information is needed, then it should be added in the revision class field. It will make the device creation even simpler and not dependent of the SoC version. I did not check the whole series, but I'm not sure we need a special treatment in the case of the prm. OK, sounds like this needs more discussion, so will drop this patch from the pull request. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL v2] ARM: OMAP: new miscellaneous clock/hwmod data for 3.2
Hi, The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 clock_hwmod_devel_3.2 This second version drops the PRM hwmod since it needs more discussion. Benoit Cousson (1): ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4 Keshava Munegowda (1): ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3 Santosh Shilimkar (1): ARM: OMAP4: clock: Add CPU local timer clock node. arch/arm/mach-omap2/clock44xx_data.c |9 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 217 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206 ++- 3 files changed, 431 insertions(+), 1 deletions(-) - Paul -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
Hi Benoît On Mon, 10 Oct 2011, Cousson, Benoit wrote: On 10/10/2011 9:24 PM, Paul Walmsley wrote: On Fri, 23 Sep 2011, Tero Kristo wrote: This patch is temporary until Paul can provide a final version. Signed-off-by: Tero Kristot-kri...@ti.com Here's an updated version of this one. The one change is that the hwmod's name is now prm3xxx to reflect that the register layout of this IP block is quite different from its OMAP2 predecessors and OMAP4 successors. This should avoid some of the special-purpose driver probing code. This is not really aligned with the naming convention we've been using so far. In both cases, the hwmod should just be named prm. If a version information is needed, then it should be added in the revision class field. It will make the device creation even simpler and not dependent of the SoC version. The problem in this case is that we should be using a completely different device driver for the PRM that's in the OMAP3 chips, from the driver used for OMAP2 or OMAP4 PRM blocks, due to the completely different register layout. As far as I know, we haven't yet used the hwmod IP version to probe a different device driver when the version number changes. There's no support for that in the current Linux platform* code, so we'd need special-purpose code for that. In an ideal world, we'd have an omap_bus, etc., which would include an additional interface version number as part of its driver matching criteria. Device drivers would then specify which interface version numbers they supported. The device data would specify that interface version number should be matched. But as it is right now in the current platform_device/platform_driver based system, we have only the name to match. We could implement something where we concatenate the existing IP version number onto the hwmod name, and modify the device drivers to use that name. But that seems like a lot of potential churn in light of a future DT and/or omap_bus migration. So I'm proposing to use the IP version number field that's in the hwmod data to indicate evolutionary revisions of an IP block -- rather than revolutionary revisions that would require a new driver. Then, since we use the hwmod name for driver matching, we'd use a different name for radically different IPs. If it's the 3xxx that you're objecting to in the name, we could call it prm2 or prmxyz - the '3xxx' just seemed like the most logical approach. The name of the hwmod class in the patch is still prm, of course. Thoughts? ... N.B., it's true that by waiting, this problem will presumably go away, with DT, in which the driver matching data would go into the compatible string in the DT. But I guess it would be good to figure out a clean approach in the meantime. - Paul
Re: [PATCH 3.1-rc3] gpio/omap: fix build error with certain OMAP1 configs
Hi, On Fri, 7 Oct 2011, Janusz Krzysztofik wrote: Dnia wtorek, 23 sierpnia 2011 o 19:11:47 Kevin Hilman napisał(a): Janusz Krzysztofik jkrzy...@tis.icnet.pl writes: With commit f64ad1a0e21a, gpio/omap: cleanup _set_gpio_wakeup(), remove ifdefs, access to build time conditionally omitted 'suspend_wakeup' member of the 'gpio_bank' structure has been placed unconditionally in function _set_gpio_wakeup(), which is always built. This resulted in the driver compilation broken for certain OMAP1, i.e., non-OMAP16xx, configurations. Really required or not in previously excluded cases, define this structure member unconditionally as a fix. Tested with a custom OMAP1510 only configuration. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Verified that this fixes a build problem when building for OMAP1 (730/850 only) Acked-by: Kevin Hilman khil...@ti.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Grant, can you queue this as a fix for 3.1-rc? Sorry for being so late with checking this, but it looks like this patch never got into 3.1-rc, as it should, leaving the issue not fixed. Any chance for it still being pushed into 3.1? This patch is one-liner, and still needed to get 3.1-rc9 compiled and running on e.g. Amstrad E3, so I think it should get into 3.1. A.
Re: [PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
Hi Benoit,
On 10/10/2011 4:54, Cousson, Benoit wrote:
Hi Jon,
On 10/8/2011 12:46 AM, Hunter, Jon wrote:
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunterjon-hun...@ti.com
This one, I don't quite understand. We should probably be removing
these
MODULEMODE-only clocks from the OMAP4 tree, and using their parent
clock
as the main_clk. That would be a good cleanup for 3.3...
Yes, but in order to remove that from the clock data we must ensure that
the hwmod entry is there.
I kept a lot of legacy MODULEMODE clocks just because of missing hwmod /
runtime_pm adaptation on some drivers.
In the case of slimbus, there is no main_clk but a bunch of optional
clocks. It looks similar to the DSS case. So we should not use the
parent clock as a main_clk.
We should probably promote one of the opt_clk as the main_clk. The
slimbus_clk seems to be the good candidate for both instances.
static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus1_fclk_1 },
{ .role = fclk_0, .clk = slimbus1_fclk_0 },
{ .role = fclk_2, .clk = slimbus1_fclk_2 },
{ .role = slimbus_clk, .clk = slimbus1_slimbus_clk },
};
static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus2_fclk_1 },
{ .role = fclk_0, .clk = slimbus2_fclk_0 },
{ .role = slimbus_clk, .clk = slimbus2_slimbus_clk },
};
Jon,
Do you know if that one is indeed mandatory to use the slimbus IP?
Sorry, are you asking about the clocks I was re-naming or the
slimbus_clk you are referring to above?
The clocks you are renaming should not exist at all, so I was referring
to the real clocks that are all listed as optional clocks.
These clocks are the interface clocks enabled via the module-mode. So
you are saying you want to remove the interface clocks from the list of
clocks?
Usually we do need to have a main_clk in order to access the IP
registers (at least the sysconfig). But for some IPs, the iclk can be
enough.
If the interface clock is enough, then potentially that main clock is
not mandatory. But if one functional clock is mandatory, then we have to
figured out which one from the various optional functional clocks can be
used as the main_clk.
Looking at the clock tree tool, the slimbus_clk is the actual external
slimbus clock that can be generated by OMAP or by an external device.
The TRM states ...
Most of the SLIMbus module runs off two main clocks: the L4 interface
clock for the data input and output registers, and the control and
status control registers; and the SLIMbus clock, taken from the serial
interface (CLK line) for the SLIMbus-side logic.
The SLIMbus controller operates as clock source component (active
framer), which drives the SLIMbus clock line CLK, or as clock receiver
component, which gets its clock from the same CLK line.
So, if you are operating as the clock source component on the bus then
one of the optional clocks to drive the peripheral logic and if you are
the clock receiver then you use slimbus_clk.
OK, so clearly, the slimbus_clk cannot be a main_clk. We have to check
if the registers can be accessed only with the iclk.
I ran a quick test. If I just set the module mode to 0x2 (enabled), then
I can access the registers. So no need to turn on any of the
optional/functional clocks just the iclk.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
The master branch is best to base your patches on for generic work.
It looks like the master branch is missing something like this:
From acb316aa4bcaf383e8cb1580e30c8635e0a34369 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Mon, 10 Oct 2011 23:55:51 +0200
Subject: [PATCH] iommu/core: fix build issue
Fix this:
drivers/iommu/iommu.c: In function 'iommu_commit':
drivers/iommu/iommu.c:291: error: 'iommu_ops' undeclared (first use in
this function)
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/iommu/iommu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 909b0d2..a5131f1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -288,7 +288,7 @@ EXPORT_SYMBOL_GPL(iommu_unmap);
void iommu_commit(struct iommu_domain *domain)
{
- if (iommu_ops-commit)
- iommu_ops-commit(domain);
+ if (domain-ops-commit)
+ domain-ops-commit(domain);
}
EXPORT_SYMBOL_GPL(iommu_commit);
--
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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Mon, 10 Oct 2011, Paul Walmsley wrote: So then you'd just create a TLL driver with something like these two symbols exported: omap_usbhost_tll_enable_port(); omap_usbhost_tll_disable_port(); N.B., since I don't think Linux has any formal support to map USB ports to TLL ports, you'll probably need to create a couple of functions in your drivers/mfd/omap-usb-host.c that your EHCI/OHCI drivers could call during init/exit to get and put the TLL struct device, to pass to those above functions. Since the MFD driver is what creates the TLL struct devices, the MFD driver will have the TLL struct device pointers. Something like omap_usbhost_get_tll_device() and omap_usbhost_put_tll_device(). One other thing. Not sure what the correct generic name prefix for these functions should be, since I don't know the provenance of the USBHOST IP block; but maybe the function prefix should be something like 'ti_usbhost' instead, to indicate that it isn't OMAP-specific? You would know better than I. - Paul -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
On 10/10/2011 10:42 PM, Paul Walmsley wrote:
Hi Benoît
On Mon, 10 Oct 2011, Cousson, Benoit wrote:
On 10/10/2011 9:24 PM, Paul Walmsley wrote:
On Fri, 23 Sep 2011, Tero Kristo wrote:
This patch is temporary until Paul can provide a final version.
Signed-off-by: Tero Kristot-kri...@ti.com
Here's an updated version of this one. The one change is that the hwmod's
name is now prm3xxx to reflect that the register layout of this IP block
is quite different from its OMAP2 predecessors and OMAP4 successors.
This should avoid some of the special-purpose driver probing code.
This is not really aligned with the naming convention we've been using so far.
In both cases, the hwmod should just be named prm. If a version information
is needed, then it should be added in the revision class field.
It will make the device creation even simpler and not dependent of the SoC
version.
The problem in this case is that we should be using a completely different
device driver for the PRM that's in the OMAP3 chips, from the driver used
for OMAP2 or OMAP4 PRM blocks, due to the completely different register
layout. As far as I know, we haven't yet used the hwmod IP version to
probe a different device driver when the version number changes. There's
no support for that in the current Linux platform* code, so we'd need
special-purpose code for that.
In an ideal world, we'd have an omap_bus, etc., which would include an
additional interface version number as part of its driver matching
criteria. Device drivers would then specify which interface version
numbers they supported. The device data would specify that interface
version number should be matched.
But as it is right now in the current platform_device/platform_driver
based system, we have only the name to match. We could implement
something where we concatenate the existing IP version number onto the
hwmod name, and modify the device drivers to use that name. But that
seems like a lot of potential churn in light of a future DT and/or
omap_bus migration.
So I'm proposing to use the IP version number field that's in the hwmod
data to indicate evolutionary revisions of an IP block -- rather than
revolutionary revisions that would require a new driver. Then, since we
use the hwmod name for driver matching, we'd use a different name for
radically different IPs.
If it's the 3xxx that you're objecting to in the name, we could call it
prm2 or prmxyz - the '3xxx' just seemed like the most logical
approach. The name of the hwmod class in the patch is still prm, of
course.
Yes, but that's different, the number is supposed to represent the
instance number in the IP naming convention. So prm2 != prmv2.
Thoughts?
In fact the device name does not have to match the hwmod name. So we can
just create an omap2_prm omap_device for OMAP2, omap3_prm
omap_device for OMAP3...
That will allow the relevant PRM driver to be bound to the proper device.
N.B., it's true that by waiting, this problem will presumably go away,
with DT, in which the driver matching data would go into the
compatible string in the DT.
Yes, this will become indeed straightforward with DT.
We will just have something like:
prm {
compatible = prm-omap2;
ti,hwmods = prm;
}
But I guess it would be good to figure out a clean approach in the
meantime.
I guess the different device names should make that work in the meantime.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
Govindraj govindraj...@gmail.com writes: On Mon, Oct 3, 2011 at 10:53 AM, Rajendra Nayak rna...@ti.com wrote: On Monday 03 October 2011 10:30 AM, Govindraj wrote: On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayakrna...@ti.com wrote: On Friday 30 September 2011 04:31 PM, Govindraj.R wrote: Add API to determine IO-PAD wakeup event status for a given hwmod dynamic_mux pad. Wake up event set will be cleared on pad mux_read. Are these api's even getting used in this series? Used in Tero's irq_chaining patches. So shouldn't this patch be part of his series instead? Yes it is. Part of his v9-series. Then please drop from this series and state the introductory patch (PATCH 0/n) that this series has a dependency on Tero's series. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 05/16] OMAP2+: UART: Cleanup part of clock gating mechanism for uart
Govindraj.R govindraj.r...@ti.com writes: Currently we use a shared irq handler to identify uart activity and then trigger a timer. OK. Based the timeout value set from sysfs the timer used to expire. Please re-phrase as I'm not sure what is being said here. If no uart-activity was detected timer-expiry func sets can_sleep flag. Based on this we will disable the uart clocks in idle path. Since the clock gating mechanism is outside the uart driver, we currently use this mechanism. In preparation to runtime implementation for omap-serial driver we can cleanup this mechanism and use runtime API's to gate uart clocks. Also remove timer related info from local uart_state struct and remove the code used to set timeout value from sysfs. Remove un-used function omap_uart_check_wakeup. Signed-off-by: Govindraj.R govindraj.r...@ti.com The patch itself fine, and is a well-neede cleanup, but changelog (especially the first part) does not read well. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
On Tue, 11 Oct 2011, Cousson, Benoit wrote: On 10/10/2011 10:42 PM, Paul Walmsley wrote: If it's the 3xxx that you're objecting to in the name, we could call it prm2 or prmxyz - the '3xxx' just seemed like the most logical approach. The name of the hwmod class in the patch is still prm, of course. Yes, but that's different, the number is supposed to represent the instance number in the IP naming convention. So prm2 != prmv2. Heh, that works as long as there's no prmv IP block ;-) Thoughts? In fact the device name does not have to match the hwmod name. So we can just create an omap2_prm omap_device for OMAP2, omap3_prm omap_device for OMAP3... That will allow the relevant PRM driver to be bound to the proper device. We can, we'd just need to add this extra mapping layer, so it doesn't become a nasty special-case hack for each IP block that this applies to. Sounds like something for 3.3 (if ever...) - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
On Mon, 10 Oct 2011, Jean Pihet wrote: On Fri, Oct 7, 2011 at 6:17 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Figures are added to the power domains structs for RET and OFF modes. Note: the latency figures for MPU, PER, CORE, NEON have been obtained from actual measurements. The latency figures for the other power domains are preliminary and shall be added. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Do the CSWR measurements include the time for the PMIC to scale the voltage, or do they just represent the time to enter and exit clock stop (presumably with DPLL idling)? As described at [1] the measurements have not been performed with sys_offmode and sys_clkreq signals toggling correctly, because of the lack of support for it in the kernel. However the results are including a correction for the sys_offmode transition time (11.5ms), but no correction for the sys_clkreq signal (which should be 1ms for sysclk on, 2.5ms for sysclk off). [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results OK. sys_offmode only applies to OFF mode. Voltage scaling can also occur during RETENTION and INACTIVE (sleep). So were these results with retention and voltage scaling disabled? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
Hi Joerg,
On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
The master branch is best to base your patches on for generic work.
Done. I've revised the patches and attached the main one
below; please tell me if it looks ok, and then I'll resubmit the
entire patch set.
Thanks,
Ohad.
commit bf1d730b5f4f7631becfcd4be52693d85bfea36b
Author: Ohad Ben-Cohen o...@wizery.com
Date: Mon Oct 10 23:50:55 2011 +0200
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches, and after all the drivers
are converted, register_iommu will be changed (and the temporary
default settings will be removed).
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to send the mapping size in bytes instead of in page order.
Many thanks to Joerg Roedel joerg.roe...@amd.com for significant review!
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: David Brown dav...@codeaurora.org
Cc: David Woodhouse dw...@infradead.org
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Stepan Moskovchenko step...@codeaurora.org
Cc: KyongHo Cho pullip@samsung.com
Cc: Hiroshi DOYU hd...@nvidia.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: k...@vger.kernel.org
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 73778b7..909b0d2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -16,6 +16,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#define pr_fmt(fmt)%s: fmt, __func__
+
#include linux/device.h
#include linux/kernel.h
#include linux/bug.h
@@ -47,6 +49,19 @@ int bus_set_iommu(struct bus_type *bus, struct
iommu_ops *ops)
if (bus-iommu_ops != NULL)
return -EBUSY;
+ /*
+* Set the default pgsize values, which retain the existing
+* IOMMU API behavior: drivers will be called to map
+* regions that are sized/aligned to order of 4KiB pages.
+*
+* This will be removed once all drivers are migrated.
+*/
+ if (!ops-pgsize_bitmap)
+ ops-pgsize_bitmap = ~0xFFFUL;
+
+ /* find out the minimum page size only once */
+ ops-min_pagesz = 1 __ffs(ops-pgsize_bitmap);
+
bus-iommu_ops = ops;
/* Do IOMMU specific setup for this bus-type */
@@ -157,33 +172,117 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot)
+ phys_addr_t paddr, int size, int prot)
{
- size_t size;
+ unsigned long orig_iova = iova;
+ int ret = 0, orig_size = size;
if (unlikely(domain-ops-map == NULL))
return -ENODEV;
- size = PAGE_SIZE gfp_order;
+ /*
+* both the virtual address and the physical one, as well as
+* the size of the mapping, must be aligned (at least) to the
+* size of the smallest page supported by the hardware
+*/
+ if (!IS_ALIGNED(iova | paddr | size, domain-ops-min_pagesz)) {
+ pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%x min_pagesz
+ 0x%x\n, iova, (unsigned long)paddr,
+ size, domain-ops-min_pagesz);
+ return -EINVAL;
+ }
+
+ pr_debug(map: iova 0x%lx pa 0x%lx size 0x%x\n, iova,
+ (unsigned long)paddr, size);
+
+ while (size) {
+ unsigned long pgsize, addr_merge = iova | paddr;
+ unsigned int pgsize_idx;
+
+ /* Max page size that still fits into 'size' */
+ pgsize_idx = __fls(size);
+
+ /* need to consider alignment requirements ? */
+ if
Re: [PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
On Mon, 10 Oct 2011, Paul Walmsley wrote: OK. sys_offmode only applies to OFF mode. Voltage scaling can also occur during RETENTION and INACTIVE (sleep). So were these results with retention and voltage scaling disabled? This last sentence should have read: So were these results with retention and sleep voltage scaling disabled? - Paul -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
On Tue, 11 Oct 2011, Cousson, Benoit wrote: In fact the device name does not have to match the hwmod name. So we can just create an omap2_prm omap_device for OMAP2, omap3_prm omap_device for OMAP3... That will allow the relevant PRM driver to be bound to the proper device. Incidentally, given that we would be using the hwmod name and the version number to determine the appropriate omap_device name, what IP version numbers should we assign to these PRM IP blocks for different SoCs? - Paul -- To unsubscribe from this list: send the line unsubscribe 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 06/16] OMAP2+: UART: Remove certain feilds from omap_uart_state struct
Govindraj.R govindraj.r...@ti.com writes:
Removing some of the uart info that is maintained in omap_uart_state struct
used for UART PM in serial.c.
Remove omap_uart_state struct dependency from omap_serial_init,
omap_serial_init_port, omap_serial_early_init and omap_uart_idle_init
functions. And populate the same info in omap_uart_port_info struct
used as pdata struct.
IMO, this change doesn't belong in this patch and leads to clutter. The
rest of the series slowly removes/replaces all the fields from this
struct, so the right place to remove it's usage all together is at the
end of the series when (if) all the fields are no longer needed (or have
been moved.)
Stated differently, IMO, this patch should leave the uart-num and
uart-oh and the list_head (uart-node) alone (probably uart-pdev too)
and just cleanup the fields that are no longer used. Removing num, oh,
node here causes churn because you're force to change things here that
are then removed in later patches.
Added omap_uart_hwmod_lookup function to look up oh by name used in
serial_port_init and omap_serial_early_init functions.
Because of the above change, you now are doing a hwmod lookup 2 times
for every UART. Leaving the uart_list and uart-num in place will avoid
the need for that change.
A list of omap_uart_state was maintained one for each uart, the same
is removed. Number of uarts available is maintained in num_uarts
field, re-use the same in omap_serial_init func to register each uart.
Remove omap_info which used details from omap_uart_state and use a
pdata pointer to pass platform specific info to driver.
There is no omap_info. Did you mean omap_up_info?
The mapbase (start_address), membase(io_remap cookie) maintained as
part of uart_state struct and pdata struct are removed as this is
handled within driver.
This part makes sense.
Errata field is also moved to pdata.
Why in this patch instead of the subsequent Move errata handling from
serial.c to omap-serial patch?
These changes are done to cleanup serial.c file and prepare for
runtime changes.
There are a lot of changes in this patch with very little description as
to why, and many appear to be unrelated. They should probably be
separate patches, or have a better description as to how all the changes
are related so they belong in the same patch.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 132 +---
arch/arm/plat-omap/include/plat/omap-serial.h |4 +-
drivers/tty/serial/omap-serial.c | 12 ++-
3 files changed, 61 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c98b9b4..8c43d1c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -68,14 +68,6 @@ struct omap_uart_state {
int clocked;
int regshift;
- void __iomem *membase;
- resource_size_t mapbase;
-
- struct list_head node;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- u32 errata;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
int context_valid;
@@ -90,7 +82,6 @@ struct omap_uart_state {
#endif
};
-static LIST_HEAD(uart_list);
static u8 num_uarts;
static int uart_idle_hwmod(struct omap_device *od)
@@ -143,7 +134,19 @@ static inline void serial_write_reg(struct
omap_uart_state *uart, int offset,
__raw_writeb(value, uart-membase + offset);
}
-#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
+struct omap_hwmod *omap_uart_hwmod_lookup(int num)
+{
+ struct omap_hwmod *oh;
+ char oh_name[MAX_UART_HWMOD_NAME_LEN];
+
+ snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN, uart%d, num + 1);
+ oh = omap_hwmod_lookup(oh_name);
+ WARN(IS_ERR(oh), Could not lookup hmwod info for %s\n,
+ oh_name);
+ return oh;
+}
+
+#if defined(CONFIG_PM)
The CONFIG_ARCH_OMAP3 part of this #if was dropped with this change with
no mention as to why. (I understand why it was done, but it's not
releveant to $SUBJECT patch so should be a separate patch.)
/*
* Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
@@ -357,22 +360,17 @@ int omap_uart_can_sleep(void)
return can_sleep;
}
-static void omap_uart_idle_init(struct omap_uart_state *uart)
+static void omap_uart_idle_init(struct omap_uart_port_info *uart,
+ unsigned short num)
{
- int ret;
-
- uart-can_sleep = 0;
- omap_uart_smart_idle_enable(uart, 0);
-
if (cpu_is_omap34xx() !cpu_is_ti816x()) {
- u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD;
+ u32 mod = (num 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
- /* XXX These PRM accesses do not belong here */
why?
uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
Re: [PATCH v6 09/16] OMAP2+: UART: Add runtime pm support for omap-serial driver
Govindraj.R govindraj.r...@ti.com writes:
Adapts omap-serial driver to use pm_runtime API's.
[...]
@@ -1065,19 +1123,18 @@ static struct uart_driver serial_omap_reg = {
.cons = OMAP_CONSOLE,
};
-static int
-serial_omap_suspend(struct platform_device *pdev, pm_message_t state)
+static int serial_omap_suspend(struct device *dev)
{
- struct uart_omap_port *up = platform_get_drvdata(pdev);
+ struct uart_omap_port *up = dev_get_drvdata(dev);
if (up)
uart_suspend_port(serial_omap_reg, up-port);
return 0;
}
-static int serial_omap_resume(struct platform_device *dev)
+static int serial_omap_resume(struct device *dev)
{
- struct uart_omap_port *up = platform_get_drvdata(dev);
+ struct uart_omap_port *up = dev_get_drvdata(dev);
if (up)
uart_resume_port(serial_omap_reg, up-port);
These functions need to be wrapped in #ifdef CONFIG_SUSPEND, otherwise,
when building with !CONFIG_SUSPEND you'll get :
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:1134:12: warning:
'serial_omap_suspend' defined but not used
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:1150:12: warning:
'serial_omap_resume' defined but not used
[...]
+static int serial_omap_runtime_suspend(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev-platform_data;
+
+ if (!up)
+ return -EINVAL;
+
+ if (!pdata-enable_wakeup || !pdata-get_context_loss_count)
+ return 0;
+
+ if (pdata-get_context_loss_count)
+ up-context_loss_cnt = pdata-get_context_loss_count(dev);
+
+ if (device_may_wakeup(dev)) {
+ if (!up-wakeups_enabled) {
+ pdata-enable_wakeup(up-pdev, true);
+ up-wakeups_enabled = true;
+ }
+ } else {
+ if (up-wakeups_enabled) {
+ pdata-enable_wakeup(up-pdev, false);
+ up-wakeups_enabled = false;
+ }
+ }
+
+ return 0;
+}
+
+static int serial_omap_runtime_resume(struct device *dev)
+{
+ struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev-platform_data;
+
+ if (up) {
+ if (pdata-get_context_loss_count) {
+ u32 loss_cnt = pdata-get_context_loss_count(dev);
+
+ if (up-context_loss_cnt != loss_cnt)
+ serial_omap_restore_context(up);
+ }
+ }
+
return 0;
}
Similarily, thse need to be wrapped with #ifdef CONFIG_PM_RUNTIME,
otherwise, when !CONFIG_PM_RUNTIME:
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:1498:12: warning:
'serial_omap_runtime_suspend' defined but not used
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:1531:12: warning:
'serial_omap_runtime_resume' defined but not used
+static const struct dev_pm_ops serial_omap_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
+ SET_RUNTIME_PM_OPS(serial_omap_runtime_suspend,
+ serial_omap_runtime_resume, NULL)
+};
+
Note that you don't need #else parts to the above #ifdefs since
the SET_*_OPS() macros used here take care of that.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 09/16] OMAP2+: UART: Add runtime pm support for omap-serial driver
Govindraj.R govindraj.r...@ti.com writes: Adapts omap-serial driver to use pm_runtime API's. Use runtime runtime API's to handle uart clocks and obtain device_usage statics. Set runtime API's usage to irq_safe so that we can use get_sync from irq context. Auto-suspend for port specific activities and put for reg access. Use device_may_wakeup to check whether uart has wakeup capabilities and then enable uart runtime usage for the uart. OK. Current patch should do only this part. The rest should be separate patches with their own descriptive changelogs. Removing save_context/restore_context functions from serial.c Adding context restore to .runtime_suspend and using reg values from port structure to restore the uart port context based on context_loss_count. Maintain internal state machine using wakeups_enabled field for avoiding repeated enable/disable of uart port wakeup mechanism. This part should be a separate patch that follows. Remove omap_uart_disable_wakeup and modify omap_uart_enable_wakeup to accept pdev and bool value to enable/disable the uart wakeup mechanism after uart clock's are cut. omap_hwmod_enable_wakeup is used to set pad wakeup for the uarts. PM_WKEN reg values are left to default. Removed omap_uart_enable/disable_clocks in serial.c now clock handling done with runtime API's. As stated in previous reviews, this wakeup enable/disable needs more description as the functionality is changing compared to current code. Current version modifies wakeup enable/disable at both power-domain level (PM_WKEN) and at the IO ring. Updated version modifies wakeups at module-level (SYSCONFIG) and at IO ring using omap_hwmod_enable_wakeup() IMO, the updated version makes more sense, but needs a description as to why that change in functionality will have equivalent results compared to the existing one. By default uart autosuspend delay is set to -1 to avoid character loss if uart's are autoidled and woken up on rx pin. OK, good. After boot up UART's can be autoidled by setting autosuspendi delay from sysfs. echo 3000 /sys/devices/platform/omap/omap_uart.X/power/autosuspend_delay_ms X=0,1,2,3 for UART1/2/3/4. Number of uarts available may vary across omap_soc. Acked-by: Alan Cox a...@linux.intel.com Signed-off-by: Govindraj.R govindraj.r...@ti.com Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 08/16] OMAP2+: UART: Store certain reg values to port structure
Govindraj.R govindraj.r...@ti.com writes: In preparation to runtime conversion add missing uart regs to port structure which can be used in context restore. Also ensuring all uart reg info's are part of port structure. Signed-off-by: Govindraj.R govindraj.r...@ti.com IMO, this should come later in the series to avoid adding bunch of code that gets moved in a subsequent patch. First, convert to runtime PM (current patch 9/16) Then, add a patch to move context save/restore into driver. Then, add this patch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Mon, 10 Oct 2011, Felipe Balbi wrote:
In fact we do already have sibling lists. They are maintained as part
of the device_private structure. What we are missing is a
device_for_each_sibling() routine. It could be added pretty easily; it
would be similar to device_for_each_child().
care to point out where is ?
68 struct device_private {
69 struct klist klist_children;
70 struct klist_node knode_parent;
-^ Here. The parent in the name refers to where the
head of the list is stored.
71 struct klist_node knode_driver;
72 struct klist_node knode_bus;
73 void *driver_data;
74 struct device *device;
75 };
From device_add():
if (parent)
klist_add_tail(dev-p-knode_parent,
parent-p-klist_children);
that's a parent - child relationship. What we have on this case is:
-----
| | | | |\
| UHH| clocks, etc |USBTLL | | |
| | == | | == | | ports
| --- | | (Transceiver- | | |
|| EHCI | | | less Link)| |/
| --- | | | Port MUX
| | | |
| --- | | |
|| OHCI | | | |
| --- | | |
| | | |
-----
It doesn't shown here, but the TLL link is completely optional. It's
mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
and OHCI will depend on a clock provided by the USBTLL block.
Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
blocks. We can, from a code perspective, make USBTLL into a parent of
UHH to make things simpler, but this will mean that calling
pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
That's why I decided for making TLL and UHH siblings, because that's a
closer relationship than parent-child.
Can you see the problem now ?
Okay, now I understand better. The word sibling implies that the two
objects have the same parent, so a different word would describe this
relationship better. Something like friend or associate.
Or maybe, following Paul's suggestion, the driver core doesn't have to
be changed at all.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi
so I just noticed another problem with these hwmods:
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 227
1 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..b8ca690 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
...
+static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {
This interface is missing a .master and .slave. It must have both. So,
dropping this patch until it's fixed.
Clearly we also need to modify the hwmod code needs to reject any
instances where either .master or .slave is NULL.
- Paul
--
To unsubscribe from this list: send the line unsubscribe 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi
and some comments on this one ...
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- rebased to kernel version 3.0
- Workarounds for hardware issues
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206
+++-
1 files changed, 205 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..e404fd6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
...
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_tll_hs_hwmod,
+ .addr = omap44xx_usb_tll_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
This one has the .master pointing to something reasonable, but is missing
a .clk entry.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL v3] ARM: OMAP: Cortex-A9 PERIPHCLK node for 3.2
Hi Tony The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 clock_hwmod_devel_3.2 This pull request drops the EHCI/OHCI hwmod data due to some inconsistencies that were just found in the data. Santosh Shilimkar (1): ARM: OMAP4: clock: Add CPU local timer clock node. arch/arm/mach-omap2/clock44xx_data.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) - Paul -- To unsubscribe from this list: send the line unsubscribe 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi On Mon, 10 Oct 2011, Paul Walmsley wrote: Basically, the existing OMAP USB subsystem MFD driver should create a TLL device. Then the existing Linux driver probing system can associate the TLL driver with the TLL device. This part isn't right. After staring at the OMAP34xx TRM, it looks like the TLL modules have a separate interconnect port. See for example the OMAP34xx TRM Rev. ZR Table 2-3 L4-Core Memory Space Mapping. So then the TLL device should be created by the code in arch/arm/mach-omap2/usb-host.c, as one of Keshava's patches does. And indeed we have separate hwmods for the TLL IP blocks -- although both the OMAP3 and OMAP4 hwmod data that was posted are missing important fields. So drivers/omap-usb-host.c shouldn't create a new TLL device. You just need to pull all of the TLL code and data out of that MFD driver into a new TLL driver under drivers/usb somewhere. Then you'll need some way for the EHCI/OHCI code to figure out which USBTLL device handles each port. I'd suggest that, unless there is some explicit Linux USB core support for associating a TLL port with a host controller port, that the code in arch/arm/mach-omap2/usb-host.c register the USBTLL device first (the opposite of what it does now), then pass the pointer to the USBTLL's struct device via platform_data to drivers/mfd/omap-usb-host.c. Then that can either be passed via platform_data to the EHCI/OHCI drivers, or the EHCI/OHCI drivers can call a drivers/mfd/omap-usb-host.c function to retrieve that struct device pointer. - Paul -- To unsubscribe from this list: send the line unsubscribe 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/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hello Ming, On Wed, 28 Sep 2011, Ming Lei wrote: On Fri, Sep 23, 2011 at 7:31 AM, Paul Walmsley p...@pwsan.com wrote: The idea of the main_clk was not intended to be PRCM or OCP or even OMAP-specific. It's just intended to represent a clock that is used to drive the register logic inside the IP block. Therefore it must be enabled before any register access may occur. Even if clock gating is handled by some higher-level interface (e.g., at the IP block level), the main_clk has a rate, so it also implies an upper limit on how quickly register operations can occur. I suppose that all of the IP block's clocks could be optional clocks, but we know that every IP block with registers requires at least one clock to work, and that should be the main_clk. I am a bit confused about you comment on main_clk. From hwmod related source code, main_clk is the function clock of one module(hwmod), such as: on omap4, for uart3, main_clk is uart3_fck. But from[1] and [2] of omap4 PRM, we can find that interface clock is required to provide register access instead of function clock. As far as I know, the two cases that you cite are basically documentation bugs in the TRM. In my experience, for IP blocks on OMAPs, a functional clock has to be enabled in order for register accesses to succeed. It's possible there may be a few odd IP blocks that behave differently, but I can't think of any off the top of my head. There are three cases that I've come across that might be interesting to you. The first involves IP blocks that use their interface clock as their functional clock, such as the MAILBOXES IP block. In this case, there is no separate functional clock that is needed for register accesses to complete, and therefore the main_clk should be the interface clock. The second case involves IP blocks that can receive functional clocks from an off-chip source (i.e., not via a PRCM-controlled clock), such as the McBSP IP block. For these IP blocks, it could be that register accesses might still succeed even if the module's PRCM-provided functional clock is off. I haven't tested this personally. The third case involves IP blocks with multiple functional clocks, such as the OMAP3 USBHOST subsystem. What we found on OMAP3 was that only one of these two clocks needs to be enabled for register accesses to succeed. Some functional clocks might control parts of an IP block that have nothing to do with register access. This is a bit conflictive with what you description, so could you give a further comments about main_clk, function clock and interface clock? I don't know why there are these documentation discrepancies. I can guess, but probably I'd better not :-) Hope the above helped. [1], 23.3.4.2 Clock Configuration Each UART uses a 48-MHz functional clock for its logic and to generate external interface signals. Each UART uses an interface clock for register accesses. [2], 3.1.1.1.1 Module Interface and Functional Clocks The interface clocks have the following characteristics: • They ensure proper communication between any module/subsystem and the interconnect. • In most cases, they supply the system interconnect interface and registers of the module. regards, - Paul
Removing hwmod reset support for initiator IP blocks?
Hi, so from talking with a few people, it sounds like we can't reset initiator IP blocks cleanly at the integration layer. As I understand the problem, if the initiator is in the middle of an OCP transaction, the reset could cause system instability, since the OCP transaction would never finish and potentially time out. I have also heard that some processor drivers require some fine-grained reset control that can't be handled by the hwmod code for some reason. So this thread is for public discussion of the issue. It would be good if driver authors whose IP blocks may be affected by this could comment and perhaps provide more details... regards - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Tue, Oct 11, 2011 at 6:08 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
so I just noticed another problem with these hwmods:
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 227
1 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..b8ca690 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
...
+static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {
This interface is missing a .master and .slave. It must have both. So,
dropping this patch until it's fixed.
Clearly we also need to modify the hwmod code needs to reject any
instances where either .master or .slave is NULL.
- Paul
Hi Paul
I will fix it today only and I will send the updated
patches in couple of hours.
please help me to make it in this merge window.
Thanks and 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 v2 5/5] regulator: map consumer regulator based on device tree
@@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+ if (!dev)
+ list_for_each_entry(rdev,regulator_list, list)
+ if (strcmp(rdev_get_name(rdev), id))
+ goto found;
This looks really strange, we didn't remove any old lookup code and the
DT lookup jumps to found by iself so why are we adding code here?
The old lookup code looks up using the regulator_map_list, and the dt
lookup depends on a dev pointer to extract the of_node.
This above code was needed for cases when a regulator_get() would be
called on dt builds without specifying a device pointer, like the
cpufreq implementations you mentioned.
This is what I tried putting in the comments above the lookup code.
/*
* Lookup happens in 3 ways
* 1. If a dev and dev-of_node exist, look for a
* regulator mapping in dt node.
* 2. Check if a match can be found in regulator_map_list
* if regulator info is still passed in non-dt way
* 3. if !dev, then just look for a matching regulator name.
* Useful for dt builds using regulator_get() without specifying
* a device.
*/
I know its quite complicated but thats because we need to support both
the legacy and the dt based lookups.
+ if (supply) {
+ struct regulator_dev *r;
+ struct device_node *node;
+
+ /* first do a dt based lookup */
+ if (dev) {
+ node = of_get_regulator(dev, supply);
+ if (node)
+ list_for_each_entry(r,regulator_list, list)
+ if (node == r-dev.parent-of_node)
+ goto found;
}
- if (!found) {
- dev_err(dev, Failed to find supply %s\n,
- init_data-supply_regulator);
- ret = -ENODEV;
- goto scrub;
- }
+ /* next try doing it non-dt way */
+ list_for_each_entry(r,regulator_list, list)
+ if (strcmp(rdev_get_name(r), supply) == 0)
+ goto found;
+ dev_err(dev, Failed to find supply %s\n, supply);
+ ret = -ENODEV;
+ goto scrub;
+
+found:
This is all getting *really* complicated and illegible. I'm not sure
what the best way to structure is but erroring out early looks useful.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
On Monday 10 October 2011 10:52 PM, Mark Brown wrote: On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote: +- regulator-change-voltage: boolean, Output voltage can be changed by software +- regulator-change-current: boolean, Output current can be chnaged by software +- regulator-change-mode: boolean, Operating mode can be changed by software +- regulator-change-status: boolean, Enable/Disable control for regulator exists +- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled +- regulator-mode-fast: boolean, allow/set fast mode for the regulator +- regulator-mode-normal: boolean, allow/set normal mode for the regulator +- regulator-mode-idle: boolean, allow/set idle mode for the regulator +- regulator-mode-standby: boolean, allow/set standby mode for the regulator +- regulator-input-uV: Input voltage for regulator when supplied by another regulator +- regulator-always-on: boolean, regulator should never be disabled Thinking about this I'm not sure that these should go in the device tree, they're as much talking about what Linux is able to cope with as they are talking about what the hardware is able to do. Sometimes they'll be fixed by the design but they are sometimes also restricted by what the software is currently capable of. DRMS is a prime example here, it depends on how good we are at telling the API about how much current we're using. So is there another way of passing these, if not through device tree? There are other linux specific things that need to be passed to the framework as well, like the state of the regulator in the various linux specific suspend states, like standby/mem/disk. So if these can't be passed through device tree, should they still be passed in some way through platform_data? Or is it best to identify the bindings as being linux specific and not generic by appending a linux, to the bindings. Grant, need some help and advice. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
