RE: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
Hi Tony, On Fri, Jun 15, 2012 at 11:12:46, Mohammed, Afzal wrote: But I am unable to find reason for failure upon using gpmc_ticks_to_ns(1), which seems to me right thing to be used. Let me try to invoke tusb6010 functions in beagle board, observe timings so that at least I will get an idea what is going on here (even though it is guaranteed to crash) Checked simulating on beagle board, I am at total loss to understand why using gpmc_ticks_to_ns(1) has failed for n8x0 clk_activation timings with both values as follows, [1] With t.clk_activation = gpmc_ticks_to_ns(1); GPMC CS4: clk_activation: 1 ticks, 6 ns (was 0 ticks) 6 ns [2] With t.clk_activation = 1; GPMC CS4: clk_activation: 1 ticks, 6 ns (was 0 ticks) 1 ns Last field show in ns the time we are trying to set, and for both cases, 1 ticks are being programmed in register. Regards Afzal -- 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/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
Hi Jon, On Thu, Jun 14, 2012 at 23:23:48, Hunter, Jon wrote: On 06/14/2012 12:40 AM, Mohammed, Afzal wrote: During gpmc driver probe, it will configure all the connected peripherals, if configuration details are not present at that point of time, gpmc driver will cry out saying that configuration timings has not been configured, (please see holler if no configuration patch). Sorry, I am not sure if I am missing something here, but isn't the chip-select requested during the gpmc probe? If so then we should not be programming the gpmc registers at all until the chip-select has been allocated. Hence, after the probe seems more appropriate. This patch by itself has no much meaning other than preparing for driver conversion so that driver conversion series would be simpler, if you read it with gpmc driver conversion series and adapting peripherals to gpmc driver series, hopefully you can make out what I am trying to express with gpmc driver, first chip select request happens, then programming gpmc registers happen, but note that both happen in probe I am not convinced we need to. Furthermore with your change you do not actually set async mode in the onenand until _set_sync() is called. Yes, setting async mode in onenand is done in set_sync function, and it is always called by onenand driver indirectly. Seems if setting async mode in onenand is taken out of set_sync placed it before set_sync invocation in gpmc_onenand_setup, intention will be clear, right ? (even though sequence wise same thing is happening now) Exactly. Ok, v2 will have this change Yes but as far as I can see, it seems that this is the intent of the onenand_setup() function to perform the necessary initialisation. I believe doing it in gpmc_onenand_init is better, due to the reasons mentioned above as well as because function name will correspond to what it is doing, i.e. initialization If the chip-select is allocating during the probe, then I don't agree. I believe you were referring to gpmc driver probe, not onenand probe, the changes has been done such that both old and new driver interface can make use of most of existing code. And only old interface will call gpmc_onenand_init, and with that gpmc driver interface is not coming into picture, while with new gpmc driver interface, function used would be different one as in [1] Yes, on omap3evm, with help of local patches (as mainline doesn't have those). It was mentioned in cover letter of gpmc driver conversion series Great. Sorry but with 20+ patch spread across 3 series it is not always easy to find the details. So ideally it should be mentioned in this cover letter too. I am sorry for that Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69919.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 v3 4/4] memory: emif: add device tree support to emif driver
On Thu, Jun 14, 2012 at 9:18 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jun 14, 2012 at 03:59:24PM +0530, Santosh Shilimkar wrote: From: Aneesh V ane...@ti.com Device tree support for the EMIF driver. Reviewed-by: Benoit Cousson b-cous...@ti.com Reviewed-by: Grant Likely grant.lik...@secretlab.ca Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Aneesh V ane...@ti.com [santosh.shilim...@ti.com: Rebased against 3.5-rc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Am I the memory maintainer now taking these patches? I assumed that. With your ack, $subject patch should go along with other 3 OMAP platform patches because of dependency. @@ -1267,7 +1534,13 @@ static int __init_or_module emif_probe(struct platform_device *pdev) struct resource *res; int irq; - emif = get_device_details(pdev); +#if defined(CONFIG_OF) + if (pdev-dev.of_node) + emif = of_get_device_details(pdev-dev.of_node, pdev-dev); + else +#endif + emif = get_device_details(pdev); + Can't you do this without the #ifdef? Can be done. Just need to have empty of_get_device_details() for the !CONFIG_OF build to avoid build break. Will fix that. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Thu, 14 Jun 2012, Jon Hunter wrote: On 06/14/2012 10:17 AM, Guennadi Liakhovetski wrote: Hi all Sorry for jumping in so late in the game. But I think, the model, to which this discussion is slowly converging, is not very well suitable for the shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and the model is indeed suitable, in which case I'd be grateful, if someone could explain, how this model could be used for shdma. Below I'll try to describe main properties of shdma served DMACs, I've done this a couple of times before during various dmaengine related discussions. Let's see how we can use this model for these SoCs. On Sat, 9 Jun 2012, Arnd Bergmann wrote: On Friday 08 June 2012, Jon Hunter wrote: [snip] It seems to me we were pretty close on alignment. In fact, I was quite happy with Steven's 2nd to last proposal of ... simple 1 req: dmas = 0 dmac1 xxx; simple 2 req: dmas = 0 dmac1 xxx 1 dmac1 yyy; multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; A typical sh-mobile SoC contains several DMAC instances of several sub-types, all served by the same driver. Let's take sh7372 to be specific (see arch/arm/mach-shmobile/setup-sh7372.c for details). On sh7372 we've got 3 generic DMAC instances and 2 dedicated USB DMACs. Generic DMACs have 6 physical channels each, USB DMACs 2. For OMAP we also have dedicated DMAC for the USB controllers. However, these DMAC are very much integrated into the USB controller itself. Hence, in the of OMAP we would only be using the binding really to handle the generic DMAC. However, I would not like to think that this is limited to only generic DMAC. Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot. Generic DMACs can serve any slave (peripheral) request line on any their physical channel, USB DMACs only serve fixed USB controller instances. To configure (connect) a certain physical DMA channel to s specific peripheral request line, a certain value has to be written to a configuration register of that physical DMA channel. Do you still need to specify a request line for the USB DMACs or are these fixed? I personally haven't worked with the renesas_usbhs USB driver or with the respective DMA driver part, but from what I can see, no slave-select values are required, i.e., request lines seem to be fixed. In other words, what purpose would the DMA binding serve for the USB DMACs? The USB driver has to tell the dmaengine which DMAC instances are suitable for it, and which are not. To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic DMACs (DMAC0) have external DMA request pins, others don't. OMAP also has this. To me an request line going to an external pin can be handled in the same way as one going to a internal peripheral. However, what happens to that pin externally is a different story. As has been discussed before, the presence of external DMA request lines makes specifying fixed DMA channel maps in SoC dtsi files impossible. I'm sure there's more to that, but that's about the scope, that's currently supported or wants to be supported by the driver. Currently we do the slave-switching in the following way: platform data for each DMAC instance references a table of supported peripherals with their IDs and configuration register values. Each peripheral, that wishes to use DMA, provides its slave ID to the DMAC driver, by which it checks, whether this peripheral is supported and, if so, finds its configuration, picks up the next free channel and configures it. So, with the above in mind, IIUC, the above DT binding proposal would require us to reference all 3 generic DMAC instances in each slave dmas property? You could if you wanted to have the ability to select 1 out of the 3. However, I would not say it is a hard requirement. You could just provide one. Or you could list all 3, but use some form of match variable to indicate a default DMAC for a given peripheral. Sorry, I don't think artificially limiting the flexibility to just 1 controller is a good option. The option of listing all 3 in each device doesn't seem too good to me either. What if a future SoC version has 5 of them? I really would prefer to have a list of generic DMAC instances somewhere and be able to omit any explicit references to specific DMACs in device DMA bindings. I can also imagine a possibility, that in the future we won't have just one generic DMAC type, but, say, 2 DMAC groups, serving different, but possibly intersecting, sets of devices. In that case I'd just like to be able to specify use group A in the binding. Do I understand correctly, that with the proposed scheme this is impossible? Even if we assume, that for this specific case we don't have to map each physical channel, because so far they are mostly all equal on each DMAC
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Thursday 14 June 2012, Jon Hunter wrote: On 06/14/2012 06:48 AM, Arnd Bergmann wrote: On Wednesday 13 June 2012, Jon Hunter wrote: So in that case, I don't see why the first cell after the phandle could not be an index which could be either a direction or request-id and then the next cell after that be a secondary match variable. So simple case with just a index (either req-id or direction) ... dmas = dmac0 index More complex case ... dmas = dmac0 index match For example, for OMAP index = req-id and match = direction ... dmas = dmac0 req-id direction Or am I way off the page? The intention was instead to remove the need for the /index/ in those cases, because having a client-specific index in here makes it inconsistent with other similar bindings (reg, interrupts, gpios, ...) that people are familiar with. They use an implicit index by counting the fields in the respective properties. So maybe index was not the right term to use here. What I meant was that this is really the req/chan-id associated with this device. It is not an arbitrary index that in turn gets resolved into the req-id. So in other words, just like gpio where you have the gpio number, here you have the dma req-id. Ok, we're on the same page then. I got confused because you were quoting Stephen's example of multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; which used an aribitrary slave-side index (0, 1), the dmaengine phandle and the dmaengine specific request id (xxx,yyy,zzz). Leaving out the index means that we require at least one of dma-names strings or adding the direction. The existing method we have for avoiding index numbers is to use named fields, like dmas = dmac0 matchA, dmac1 matchB, dmac2 matchC; dma-names = rx, rx, tx; This is similar to how we use named interrupt and mmio resources, but it requires that we always request the dma lines by name, which is slightly more complex than we might want it to be. Ok, but how do you get the req-id from the above binding? Doesn't it need to be stored there somewhere even for the most simplest case? Or are you saying that in this case you are just returning a name and the dma driver resolves that into a req-id? the req-id is what I called matchA, matchB, matchC here, it could be a set of multiple cells, the number of which gets determined by the dmaengine's #dma-cells property. Because the vast majority of cases just use a single channel, or one channel per direction, my idea was to encode the direction in the dmas property, which lets us request a dma channel by direction from the driver side, without explicitly encoding the name. Yes, thats fine and so the direction is really the match criteria in this case. No, it's not :( This would let us handle the following cases very easily: 1. one read-write channel dmas = dmac 0x3 match; Where 0x3 is the req-id? Just to confirm ;-) Why not have match after the phandle to be consistent with the simple example using name fields above? The 0x3 is the direction, 1 for read, 2 for write, and 3 for read-write in this example. Sorry for being unclear. The direction has to come before the dma-engine specific request ID data so that the common code can interpret it, while the variable-length data after it is only interpreted by the dmaengine driver. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Thursday 14 June 2012, Jon Hunter wrote: Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot. Generic DMACs can serve any slave (peripheral) request line on any their physical channel, USB DMACs only serve fixed USB controller instances. To configure (connect) a certain physical DMA channel to s specific peripheral request line, a certain value has to be written to a configuration register of that physical DMA channel. Do you still need to specify a request line for the USB DMACs or are these fixed? In other words, what purpose would the DMA binding serve for the USB DMACs? If I understood Guennadi right, the DMA engines are the same kind as the other ones, so we really want to use the same bindings for each instance. To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic DMACs (DMAC0) have external DMA request pins, others don't. OMAP also has this. To me an request line going to an external pin can be handled in the same way as one going to a internal peripheral. However, what happens to that pin externally is a different story. Right, I don't see a problem here with any of the proposed binding. I'm sure there's more to that, but that's about the scope, that's currently supported or wants to be supported by the driver. Currently we do the slave-switching in the following way: platform data for each DMAC instance references a table of supported peripherals with their IDs and configuration register values. Each peripheral, that wishes to use DMA, provides its slave ID to the DMAC driver, by which it checks, whether this peripheral is supported and, if so, finds its configuration, picks up the next free channel and configures it. So, with the above in mind, IIUC, the above DT binding proposal would require us to reference all 3 generic DMAC instances in each slave dmas property? You could if you wanted to have the ability to select 1 out of the 3. However, I would not say it is a hard requirement. You could just provide one. Or you could list all 3, but use some form of match variable to indicate a default DMAC for a given peripheral. Right. From the description above, it seems that shmobile is actually simpler than some of the others because the slave ID is always the same for each of the controllers. In the common case, you could have one device connected to the third slave ID of the first controller but the fifth slave ID of the second controller. In this case, you really have to specify each controller with its slave ID separately, even if that means a lot of duplicate data for shmobile. I'm not sure I understand what the configuration register values above are. Most likely, those should all be part of the slave ID, which would then span multiple 32-bit values in the dmas property. Conveniently, that also takes care of removing the DMAC platform data. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 08/12] ARM: OMAP4: hwmod data: add SL2IF hardreset line
On 6/15/2012 1:02 AM, Paul Walmsley wrote:
On Thu, 14 Jun 2012, Cousson, Benoit wrote:
Yep, but for that I'd rather add a flag than a information that is a
duplication of the parent data.
Great, send a patch.
Cool.
Well, in fact the HWMOD_EXT_OPT_MAIN_CLK patch is already good enough assuming
we make it a little bit more generic.
Here is your patch sightly updated manually to make it more generic.
The data will have to add some relevant comment on top of the flag to cleary
indicate the reason of that dependency.
Regards,
Benoit
---
ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block
during init
Add HWMOD_HAS_EXT_DEP flag to indicate that this IP block is
dependent on an external resource that is not guaranteed to be
present during initialization. Typical resources are: External
clock from a off-chip device (Audio codec), clocks from a parent
subsystem or another IP, reset line from a parent subsystem.
IP blocks marked with this flag are left in the INITIALIZED state
during kernel init.
Signed-off-by: Paul Walmsley p...@pwsan.com
[b-cous...@ti.com: Change the changelog and the flag name
to make it more generic]
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |3 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d27bf48..e0b8131 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2140,6 +2140,9 @@ static int __init _setup_reset(struct omap_hwmod *oh)
if (oh-_state != _HWMOD_STATE_INITIALIZED)
return -EINVAL;
+ if (oh-flags HWMOD_HAS_EXT_DEP)
+ return -EPERM;
+
if (oh-rst_lines_cnt == 0) {
r = _enable(oh);
if (r) {
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 2c53648..b5f3efc 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -417,6 +417,11 @@ struct omap_hwmod_omap4_prcm {
* running on the chip (e.g., the MPU is in idle). For such modules,
* fine-grained PM runtime-based idle control is simply a waste of
* CPU cycles.
+ * HWMOD_HAS_EXT_DEP: This IP block is dependent on an external
+ * resource that is not guaranteed to be present during initialization.
+ * Typical resources are: External clock from a off-chip device
+ * (Audio codec), clocks from a parent subsystem, reset line from a
+ * parent subsystem.
+ * This prevents the hwmod code from being able to enable
+ * and reset the IP block early.
*/
#define HWMOD_SWSUP_SIDLE (1 0)
#define HWMOD_SWSUP_MSTANDBY (1 1)
@@ -428,6 +433,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 7)
#define HWMOD_16BIT_REG(1 8)
#define HWMOD_ALWAYS_FORCE_SIDLE (1 9)
+#define HWMOD_HAS_EXT_DEP (1 10)
/*
* omap_hwmod._int_flags definitions
--
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/2] of: Add generic device tree DMA helpers
Hi Arnd On Fri, 15 Jun 2012, Arnd Bergmann wrote: On Thursday 14 June 2012, Jon Hunter wrote: Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot. Generic DMACs can serve any slave (peripheral) request line on any their physical channel, USB DMACs only serve fixed USB controller instances. To configure (connect) a certain physical DMA channel to s specific peripheral request line, a certain value has to be written to a configuration register of that physical DMA channel. Do you still need to specify a request line for the USB DMACs or are these fixed? In other words, what purpose would the DMA binding serve for the USB DMACs? If I understood Guennadi right, the DMA engines are the same kind as the other ones, so we really want to use the same bindings for each instance. Exactly, at least they are compatible and are presently handles by the same dma-engine driver. There are some differences in the register layout, I think, which we might need to handle at some point, maybe by specifying different compatible identifiers or by some other means. To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic DMACs (DMAC0) have external DMA request pins, others don't. OMAP also has this. To me an request line going to an external pin can be handled in the same way as one going to a internal peripheral. However, what happens to that pin externally is a different story. Right, I don't see a problem here with any of the proposed binding. I'm sure there's more to that, but that's about the scope, that's currently supported or wants to be supported by the driver. Currently we do the slave-switching in the following way: platform data for each DMAC instance references a table of supported peripherals with their IDs and configuration register values. Each peripheral, that wishes to use DMA, provides its slave ID to the DMAC driver, by which it checks, whether this peripheral is supported and, if so, finds its configuration, picks up the next free channel and configures it. So, with the above in mind, IIUC, the above DT binding proposal would require us to reference all 3 generic DMAC instances in each slave dmas property? You could if you wanted to have the ability to select 1 out of the 3. However, I would not say it is a hard requirement. You could just provide one. Or you could list all 3, but use some form of match variable to indicate a default DMAC for a given peripheral. Right. From the description above, it seems that shmobile is actually simpler than some of the others because the slave ID is always the same for each of the controllers. Exactly. In the common case, you could have one device connected to the third slave ID of the first controller but the fifth slave ID of the second controller. In this case, you really have to specify each controller with its slave ID separately, even if that means a lot of duplicate data for shmobile. So, you don't think it's worth making a short-cut possible to specify a DMAC type instead of each instance phandle? It really would mean __a lot__ of duplication - with 3 generic controllers on (some) current chips and possibly more on those, that I'm not aware about. I'm not sure I understand what the configuration register values above are. As I explained in an earlier mail, those include transfer size and other parameters, but cannot be completely calculated in device drivers, because they also vary between SoCs. Most likely, those should all be part of the slave ID, which would then span multiple 32-bit values in the dmas property. Yes, we could do that. Conveniently, that also takes care of removing the DMAC platform data. Right, my only concern so far is a huge redundancy, that accepting and using the proposed scheme would incur. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm: omap: device: create a device for system control module
Hello Konstantin,
Sorry for the delayed reply.
On Thu, Jun 14, 2012 at 4:50 PM, Konstantin Baydarov
kbaida...@dev.rtsoft.ru wrote:
Hi.
On 05/29/2012 01:44 PM, Eduardo Valentin wrote:
On Fri, May 25, 2012 at 02:30:44PM +0200, Cousson Benoit wrote:
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
From: Kishon Vijay Abraham Ikis...@ti.com
Extracts the device data from hwmod database and create a platform device
using omap device build.
The device build is done during postcore_initcall.
Do you still need that since you are supporting only DT?
The device will be built automatically in the DT case.
In fact this is not needed for DT only probing. Dropping this one.
Yes, platform device(struct platform_device) will be built automatically, but
omap device(struct omap_device) will not be built.
The platform_device will be built as well as the omap_device. There
are hooks at the platform_device creation that will proceed with the
omap_device deployment. Please check:
arch/arm/plat-omap/omap_device.c: _omap_device_notifier_call and
omap_device_build_from_dt
Also when omap device is allocated(omap_device_alloc) hwmod_clocks are
registered, but in case of ctrl_module_core device - no new clock are
registered.
So, is it fine to drop omap device and skip omap_device_build() call?
As explained above, when booting with DT, you will get both, pdev and omap_dev.
BR,
Konstantin Baydarov.
All best,
Eduardo
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/mach-omap2/devices.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 152c266..9332673 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -40,6 +40,32 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+static int omap_init_control(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ const char *oh_name, *name;
+
+ oh_name = ctrl_module_core;
+ name = omap-control-core;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not lookup hwmod for %s\n, oh_name);
+ return PTR_ERR(oh);
+ }
+
+ pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s %s\n,
+ name, oh_name);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
+postcore_initcall(omap_init_control);
+
static int __init omap3_l3_init(void)
{
struct omap_hwmod *oh;
--
Eduardo Valentin
--
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] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
Hi, * Stephen Warren swar...@wwwdotorg.org [120614 16:16]: On 06/11/2012 07:58 AM, Tony Lindgren wrote: Add one-register-per-pin type device tree based pinctrl driver. Currently this driver only works on omap2+ series of processors, where there is either an 8 or 16-bit padconf register for each pin. Support for other similar pinmux controllers can be added. diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt I'm not sure why you'd need an explicit OMAP2 binding document or compatible values if it just uses the plain pinctrl-single binding unmodified. Hmm I thought that's what you wanted with your earlier comments at [1]: * Stephen Warren swar...@wwwdotorg.org [120504 12:27]: If this is truly intended to be generic, I would not document any of the ti compatible values here. Instead, I'd create a binding document for the TI controllers that basically just says this uses the bindings in pinctrl-simple.txt, with the following additions, and list the compatible values as an addition. Care to clarify a bit what you had in mind there? diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +- pinctrl-single,function-off : function off mode for disabled state Might that not vary per register? Admittedly, Tegra isn't something that could be covered by pinctrl-single, but the safe/off/non-conflicting mux selection values for Tegra certainly are not all the same value. Yeah it might be best to remove function-off, and just rely on alternative pin modes for setting this up in a register specific way. For example, omaps don't have clearly defined off mode, there is safe mode for most registers, but not all of them. +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits + +This driver uses the common pinctrl bindings as specified in the +pinctrl-bindings.txt document in this directory. + +The pinctrl register offsets and default values are specified as pairs Why default values not just values; they can only be default if you're talking about something that can be changed by some other optional mechanism, which I don't believe is the case here. Sure let's do that. +using pinctrl-single,pins. For example, setting uart2_rx pin on omap2plus +can be done with: + + pinctrl-single,pins = 0xdc 0x118; + +Where 0xdc is the offset from the pinctrl ioremapped area for the ioremapped area is a Linux-specific term. register base address would be more generic. OK +uart2_rx register, and 0x118 contains the desired default value for +for the pin setting it to INPUT_PULLUP | MODE0. See the uart example and Any mention of uart2_rx or setting it to INPUT_PULLUP | MODE0 is OMAP-specific; I'd say 0xdc and just delete setting it Alright, I'll make it anonymous. +static board pins example below for more information. + +If you are concerned about the boot time, set up the static pins in +the bootloader, and only set up selected pins as device tree entries. I'm not sure if it's really appropriate to state that kind of thing in a DT binding document. Sure, I can move that to comments in the driver. +This driver assumes that there is only one register for each pin. If you +have some pins with more complicated configuration, OK ... you can set up a separate +hardware specific driver for those pins. But for that, it seems more correct to say that pinctrl-single simply isn't an appropriate model for your HW. It is possible to create a wrapper pinctrl driver that requests pins from pinctrl-single and adds functionality to handle the extra registers. Let's say you have 200 similar registers, and only few have additional configuration registers. You may still want to handle the basic configuration using this driver. But I can move that to the driver comments too. +Note that this driver tries to avoid understanding pin and function +names because of the extra bloat they would cause especially in the +omap2plus case. This driver just sets what is specified for the board Again, I'd remove reference to any specific SoC from a generic binding. OK +in the .dts file. Further user space debugging tools can be developed +to decipher the pin and function names using debugfs. + +Example: + +/* SoC common file, such as omap4.dtsi */ But just to be clear, having an example for a specific SoC seems fine to me; just not the generic descriptive text. Sure. I don't see anywhere that describes how the function-mask and pinconf-mask properties interact with the values in pinctrl-single,pins property; are both masks OR'd together, then AND'd with the pins values, then written to the registers? If so, why have 2 masks? I'll add some more documentation. The reason why I set two masks is if the driver wants to modify
RE: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Fri, Jun 15, 2012 at 00:28:44, Hunter, Jon wrote: On 06/14/2012 08:32 AM, Mohammed, Afzal wrote: On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote: Why? You currently have a global variable storing the clock handle. It can be quite common for drivers to know the clock frequencies of their functional clocks. How else can drivers calculate timings? Please see Russell King's comments, [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/27634 [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg05365.html Thanks. So I still think you need to get rid of the global variable for storing the gpmc fclk, that is really my point. So if you look at commit [1] mentioned by Russell in the above thread, the appropriate thing to do would be to create a gpmc clock alias for all OMAP2+ devices and then you could simply call the following from the gpmc probe ... gpmc_fck = clk_get(pdev-dev, fck); You could then store somewhere in one of the gpmc structures. Here clock is required even before driver is probed, i.e for platform to calculate timings, that has to be passed through platform data. I understand the necessity for clk rate information in driver, but seems unless we have a generic way to scale timings for all the kinds of peripheral, having it may not be of much help. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Fri, Jun 15, 2012 at 02:21:50, Hunter, Jon wrote: On 06/14/2012 01:17 AM, Mohammed, Afzal wrote: gpmc_cs_set_timings() does currently convert time to clock cycles required, and this gpmc driver have the capability to do it. What I was saying is a different issue, input to gpmc_cs_set_timings, which is time sometimes in turn is a function of time or to be exact depends on gpmc clock period also. So timings provided to gpmc_cs_set_timings for a particular frequency may not hold good for another frequency, unless we change the input time to gpmc_cs_set_timings based on gpmc clock. Absolutely! No argument there. If you see gpmc-* files, many a times, they need to know value of gpmc fclk, to calculate the input time to be fed for gpmc_cs_set_timings I understand, but that is not my point. My point is that timings should be provided in nanoseconds for all devices. Then the gpmc driver can query the gpmc fclk and convert to gpmc cycles. This way the gpmc driver will not care what device is connected in terms of the timings and can convert them. But the way gpmc clock period has its effect on timings required for different peripherals is different, i.e. input timing to be provided for gpmc_cs_set_timings depends on gpmc clk it's effect varies with the peripheral Even for the same peripheral, directly scaling timings for a different frequency may not work Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
* Mohammed, Afzal af...@ti.com [120614 23:20]: Hi Tony, On Fri, Jun 15, 2012 at 11:12:46, Mohammed, Afzal wrote: But I am unable to find reason for failure upon using gpmc_ticks_to_ns(1), which seems to me right thing to be used. Let me try to invoke tusb6010 functions in beagle board, observe timings so that at least I will get an idea what is going on here (even though it is guaranteed to crash) Checked simulating on beagle board, I am at total loss to understand why using gpmc_ticks_to_ns(1) has failed for n8x0 clk_activation timings with both values as follows, [1] With t.clk_activation = gpmc_ticks_to_ns(1); GPMC CS4: clk_activation: 1 ticks, 6 ns (was 0 ticks) 6 ns [2] With t.clk_activation = 1; GPMC CS4: clk_activation: 1 ticks, 6 ns (was 0 ticks) 1 ns Last field show in ns the time we are trying to set, and for both cases, 1 ticks are being programmed in register. Yes tired it again it is working correctly. I must have messed up something yesterday when manually patching the clk_activation, maybe I put the clk_activation value into async timings instead as I was seeing the tick value set to 0 for the sync mode. So looks OK to me, n800 tusb6010 and onenand behave as earlier, also onenand on n900 seems to get detected as earlier. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
Hi Tony, On Fri, Jun 15, 2012 at 16:15:43, Tony Lindgren wrote: something yesterday when manually patching the clk_activation, maybe I put the clk_activation value into async timings instead as I was seeing the tick value set to 0 for the sync mode. I too thought like that initially, but when you told that putting value of 1 tick made it work, I thought it is some different issue Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 10/14] ARM: OMAP2+: gpmc: waitpin helper
Hi Jon, On Fri, Jun 15, 2012 at 02:36:26, Hunter, Jon wrote: On 06/14/2012 03:48 AM, Mohammed, Afzal wrote: What I meant is we are not dependent on absolute value of flag to find waitpin, and I disagree in depending on its absolute value, which can change, while flag would be the same. As long as we can avoid having multiple #defines for the same thing, I don't mind how it is done. I feel such a dependency is fragile Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 00/14] GPMC driver conversion
Hi Tony, On Wed, Jun 13, 2012 at 18:03:05, Tony Lindgren wrote: Cool, yeah looks like the old interface almost works. I had to undo the new additions for tusb6010 DMA to work as below. Then Jon has some good comments. I also made few comments to the GPMC using driver changes. Thanks and sorry for the trouble it caused you I will post next version based on the comments In general, please keep in mind that eventually we want this to be a regular device driver that also works as a loadable module. Yes, that is my intention, at the end of driver conversion, it should be able to work as a module. And we need the device tree bindings for GPMC so we can start dropping board-*.c files as the GPMC seems to be last remaining blocker for making rarely used legacy boards DT only. So it might be worth playing with that so we don't again have to redo some parts. We would prefer to do it one step at a time, have driver conversion changes first in, and then work on DT migration. Once these changes are in we have a base to work on for further DT migration. Please let me know your opinion Regards Afzal -- 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: usage of sparse or other trick for improved type safety
Hi! Added Paul in Cc:. On Thu, Jun 14, 2012 at 10:05 AM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Richard, all, On Tue, Jun 12, 2012 at 6:34 PM, Woodruff, Richard r-woodru...@ti.com wrote: Hi Tony, From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, May 25, 2012 2:53 AM Thanks for quick input. Apologies on slow ack of it. Before we had these frameworks in place it was often hard to debug when something did not work for some omaps. Things would just not work or would stop working for some drivers with no ideas what was going on. So yeah, having these kind of frameworks in place has helped a lot to avoid breakage like you're describing above. Trees which had to hit the lowest power states for full customer boards all employed some form of abstraction of clock, power, voltage. The one today in mainline today is the most clean. Aspects around auto-generation are very good even if a bit big in size. Perhaps main grump I hear is the number of abstraction layers sometimes makes debugging difficult. It would be nice to find smart tricks for compile to prune away some. Still one can experience some of the mystery issues, as the PRCM connection to IP-device utilizes a protocol which the device side can mess up. If the device does not shut down its local function and associated clocks cleanly it will show 'stuck in transition' and this gates final global changes. In one of the closed implementation we would bug() drivers who did not shut down their internal clocks properly before allowing global clock release. Most of the issues seen in field are at drivers/peripheral-ip. For some external subsystems it might be possible to let the omap kernel manage powerdomains and other resource via remote proc interface, assuming these registers are ioremapped in the omap kernel side and not owned by the external subsystem. The messaging to do this would add some undesired latencies though, but maybe those would not be so critical for the external subsystems as they tend to be full on or completely off type accelerators. Humm. Maybe for some. Guess walking what is used and sorting might tell. The way some subsystems 'ideal' operation is described from designers implies tight control of timing and sequence for things like power state. A RPC doesn't feel like it fits with intent. However... practically speaking from 'full system view' RPC may fit sometimes. A subsystem exporting hooks to save 100uW using its optimal state set against other components running in 500mW range minimizes usefulness. The other alternative of course is to implement similar frameworks for the external subsystems. Some of this might be possible to implement as simple macros with some type checks if it's subsystem specific. For doing it for all omap devices, macros were soon found not to be enough as the various bits all over need to be linked together for managing various resources. Agree. I don't know insides of all subsystems. Though what I know or hear is kind of a mixed picture. OMAP has an ultra high level of integration. As such you might find something like DSP-Bios may provide a good hook but quick integration of a previously standalone single purpose piece does not have time to be readapted. The type checking question kind of grows out of this. Linux might today offer a clean run-time api which is place where high wall should be built with type check. But... the driver might not be able to function yet with the API alone given state of evolution of both ends. Regarding the API and type checking I think the following must be enforced: 1. proper type checking in the API, possibly by the compiler, 2. clean separation of an API into an internal part (used only by the framework implementation) and an external part (used by the callers of the API). About 1: using enum for the parameters did not help much AFACIT. The compiler cannot tell if the parameter from a variable is in the allowed range. Any thought? About 2: while introducing the functional power states I came across this problem. Ideally the current states macros (PWRDM_POWER_* and PWRSTS_*) shall be used by the internal code only in powerdomain*.[ch] while the callers (pm.c etc) shall use the new macros (PWRDM_FUNC_PWRST_*) and API (mainly pwrdm_*_func_* and omap_set_pwrdm_state). Here below is a patch extract (trimmed for brevity) to illustrate the problem. FYI the full patch is at http://marc.info/?l=linux-omapm=133968581305050w=2 From here is see a few possible options: 1. clearly separate the internal and external parts of the API in the header file using comments (as done in the patch below) or with a new #ifdef POWERDOMAIN_INTERNAL_API (ugly I know), Some more details about that option: the internal values could be prefixed by '__' or similar which kinds of highlights a bad API usage. 2. create a new internal only header file
Re: [PATCH 2/8] ARM: OMAP2+: PM: introduce power domains functional states
Hi,
Here are some remarks I got after an internal review. I think those
points need to be discussed with a broader audience.
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings and to convert
between the functional (i.e. logical) and the internal (or registers)
values.
OMAP2, OMAP3 and OMAP4 platforms are defining a conversion routine.
In the new API only the function omap_set_pwrdm_state shall be used
to change a power domain target state, along with the associated
PWRDM_FUNC_* macros as the state parameters.
While at it the function is moved to the power domains code.
The power domain API in powerdomain.h is split in the external and the
internal parts; only the external API functions and defines shall be used
by external code, the internal API is only to be used in powerdomain*.[ch]
files.
The memory and logic states are not using the functional states, this
comes as a subsequent patch.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm.c | 66 ---
arch/arm/mach-omap2/pm.h | 1 -
arch/arm/mach-omap2/powerdomain-common.c | 71 +++
arch/arm/mach-omap2/powerdomain.c | 174
arch/arm/mach-omap2/powerdomain.h | 77 +
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 5 +
arch/arm/mach-omap2/powerdomain44xx.c | 2 +
7 files changed, 306 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index a05f00c..dfe702b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -74,10 +74,6 @@ static void __init omap2_init_processor_devices(void)
}
}
-/* Types of sleep_switch used in omap_set_pwrdm_state */
-#define FORCEWAKEUP_SWITCH 0
-#define LOWPOWERSTATE_SWITCH 1
-
int __init omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
{
if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
@@ -89,68 +85,6 @@ int __init omap_pm_clkdms_setup(struct clockdomain *clkdm,
void *unused)
}
/*
- * This sets pwrdm state (other than mpu core. Currently only ON
- * RET are supported.
- */
-int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst)
-{
- u8 curr_pwrst, next_pwrst;
- int sleep_switch = -1, ret = 0, hwsup = 0;
-
- if (!pwrdm || IS_ERR(pwrdm))
- return -EINVAL;
-
- mutex_lock(pwrdm-lock);
-
- while (!(pwrdm-pwrsts (1 pwrst))) {
- if (pwrst == PWRDM_POWER_OFF)
- goto out;
- pwrst--;
- }
-
- next_pwrst = pwrdm_read_next_pwrst(pwrdm);
- if (next_pwrst == pwrst)
- goto out;
-
- curr_pwrst = pwrdm_read_pwrst(pwrdm);
- if (curr_pwrst PWRDM_POWER_ON) {
- if ((curr_pwrst pwrst)
- (pwrdm-flags PWRDM_HAS_LOWPOWERSTATECHANGE)) {
- sleep_switch = LOWPOWERSTATE_SWITCH;
- } else {
- hwsup = clkdm_in_hwsup(pwrdm-pwrdm_clkdms[0]);
- clkdm_wakeup(pwrdm-pwrdm_clkdms[0]);
- sleep_switch = FORCEWAKEUP_SWITCH;
- }
- }
-
- ret = pwrdm_set_next_pwrst(pwrdm, pwrst);
- if (ret)
- pr_err(%s: unable to set power state of powerdomain: %s\n,
- __func__, pwrdm-name);
-
- switch (sleep_switch) {
- case FORCEWAKEUP_SWITCH:
- if (hwsup)
- clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
- else
- clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
- break;
- case LOWPOWERSTATE_SWITCH:
- pwrdm_set_lowpwrstchange(pwrdm);
- pwrdm_wait_transition(pwrdm);
- pwrdm_state_switch(pwrdm);
- break;
- }
-
-out:
- mutex_unlock(pwrdm-lock);
- return ret;
-}
-
-
-
-/*
* This API is to be called during init to set the various voltage
* domains to the voltage as per the opp table. Typically we boot up
* at the nominal voltage. So this function finds out the rate of
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..5bc0848 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -18,7 +18,6 @@
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
-extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
diff --git a/arch/arm/mach-omap2/powerdomain-common.c
b/arch/arm/mach-omap2/powerdomain-common.c
index
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
controller with its slave ID separately, even if that means a lot
of duplicate data for shmobile.
So, you don't think it's worth making a short-cut possible to specify a
DMAC type instead of each instance phandle? It really would mean __a lot__
of duplication - with 3 generic controllers on (some) current chips and
possibly more on those, that I'm not aware about.
It's certainly possible to make that short-cut, but I'm not convinced
if it's worth it. One thing you can do is create a meta-device for
all of the identical DMA controllers, and refer to that one from the
devices, but make it a separate device node from the actual controllers,
of which you can have more than one. This makes the binding for your
dma controller more complex but reduces the amount of data required
in the other device nodes.
In case of sh7372, this could look something like
dma: dmac-mux {
compatible = renesas,sh-dma-mux;
#dma-cells = 4; /* slave-id, addr, chcr, mid-rid */
#address-cells = 1;
#size-cells = 1;
ranges;
dmae@0xfe008020{
compatible = renesas,sh-dma;
reg = 0xfe008020 0xfe00828f
0xfe009000 0xfe00900b
interrupts = 0x20c0 0x2000 0x2020 0x2040 0x2060 0x2080
0x20a0;
};
dmae@0xfe018020{
compatible = renesas,sh-dma;
reg = 0xfe018020 0xfe01828f
0xfe019000 0xfe01900b
interrupts = 0x21c0 0x2100 0x2120 0x2140 0x2160 0x2180
0x21a0;
};
dmae@0xfe028020{
compatible = renesas,sh-dma;
reg = 0xfe028020 0xfe02828f
0xfe029000 0xfe02900b
interrupts = 0x22c0 0x2200 0x2220 0x2240 0x2260 0x2280
0x22a0;
};
};
This way, a slave would refer to the dmac-mux node and while
the device driver binds to the child nodes.
I'm not sure I understand what the configuration register values
above are.
As I explained in an earlier mail, those include transfer size and other
parameters, but cannot be completely calculated in device drivers, because
they also vary between SoCs.
Yes, but they can be part of the device tree source, because when writing
that, you know both the requirements of the device and the capabilities
of the controller.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] ARM: OMAP2+: PM: introduce power domains achievable functional states
Hi,
Here are some remarks I got after an internal review. I think those
points need to be discussed with a broader audience.
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Note: the patch is in RFC state because the state machine for setting
the next power domain states needs more discussion. Validated on OMAP34
with cpuidle and suspend/resume, though.
Power domains have varied capabilities. When attempting a low power
state such as OFF/RET, a specific min requested state may not be
supported on the power domain. This is because a combination
of system power states where the parent PD's state is not in line
with expectation can result in system instabilities.
This patch provides a function that returns the achievable functional
power state for a power domain and its use by omap_set_pwrdm_state.
The achievable power state is first looked for in the lower power
states in order to maximize the power savings, then if not found
in the higher power states.
Inspired from Tero's work on OMAP4 device OFF support and generalized
to the functional power states.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 156
+++--
arch/arm/mach-omap2/powerdomain.h | 1 +
2 files changed, 134 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index ce2685a..f94174b 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -554,6 +554,108 @@ int pwrdm_pwrst_to_func(struct powerdomain *pwrdm, u8
pwrst, u8 logic)
return ret;
}
+/**
+ * pwrdm_get_achievable_func_pwrst() - Provide achievable functional state
+ * @pwrdm: struct powerdomain * to set
+ * @func_pwrst: minimum functional state we would like to hit
+ * (one of the PWRDM_FUNC_* macros)
+ *
+ * Power domains have varied capabilities. When attempting a low power
+ * state such as OFF/RET, a specific min requested state may not be
+ * supported on the power domain. This is because a combination
+ * of system power states where the parent PD's state is not in line
+ * with expectation can result in system instabilities.
+ *
+ * The achievable power state is first looked for in the lower power
+ * states in order to maximize the power savings, then if not found
+ * in the higher power states.
+ *
+ * Returns the achievable functional power state, or -EINVAL in case of
+ * invalid parameters.
+ */
+int pwrdm_get_achievable_func_pwrst(struct powerdomain *pwrdm, u8 func_pwrst)
+{
+ int pwrst = pwrdm_func_to_pwrst(pwrdm, func_pwrst);
+ int logic = pwrdm_func_to_logic_pwrst(pwrdm, func_pwrst);
+ int new_func_pwrst, new_pwrst, new_logic;
+ int found;
+
+ if (!pwrdm || IS_ERR(pwrdm)) {
+ pr_debug(%s: invalid params: pwrdm=%p, func_pwrst=%0x\n,
+ __func__, pwrdm, func_pwrst);
+ return -EINVAL;
+ }
+
+ if ((pwrst 0) || (logic 0)) {
+ pr_debug(%s: invalid params for pwrdm %s, func_pwrst=%0x\n,
+ __func__, pwrdm-name, func_pwrst);
+ return PWRDM_FUNC_PWRST_ON;
+ }
+
+ /*
+ * Power state: if the requested state is not supported,
+ * try the lower power states.
+ */
+ found = 1;
+ new_pwrst = pwrst;
+ while (!(pwrdm-pwrsts (1 new_pwrst))) {
+ if (new_pwrst == PWRDM_POWER_OFF) {
+ found = 0;
+ break;
+ }
+ new_pwrst--;
+ }
+
+ /*
+ * If no lower power state found, fallback to the higher
+ * power states.
+ * PWRDM_POWER_ON is always valid.
+ */
+ if (!found) {
+ new_pwrst = pwrst;
+ while (!(pwrdm-pwrsts (1 new_pwrst))) {
+ if (new_pwrst == PWRDM_POWER_ON)
+ break;
+ new_pwrst++;
+ }
+ }
+
+ /*
+ * Logic RET state: if the requested state is not supported,
+ * try the lower logic states.
+ */
+ found = 1;
+ new_logic = logic;
+ while (!(pwrdm-pwrsts_logic_ret (1 new_logic))) {
+ if (new_logic == PWRDM_LOGIC_MEM_PWRST_OFF) {
+ found = 0;
+ break;
+ }
+ new_logic--;
+ }
+
+ /*
+ * If no lower logic state found, fallback to the higher
+ * logic states.
+ * PWRDM_LOGIC_MEM_PWRST_RET is always valid.
+ */
+ if (!found) {
+ new_logic = logic;
+ while (!(pwrdm-pwrsts_logic_ret (1 new_logic))) {
+ if (new_logic == PWRDM_LOGIC_MEM_PWRST_RET)
+
Re: [PATCH 01/10] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints
Hi,
Here are some remarks I got after an internal review. I think those
points need to be discussed with a broader audience.
On Thu, Jun 14, 2012 at 5:05 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
When a PM QoS device latency constraint is requested or removed the
constraint is stored in the constraints list of the corresponding power
domain, then the aggregated constraint value is applied by programming
the next functional power state using omap_set_pwrdm_state.
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/powerdomain.c | 215
+
arch/arm/mach-omap2/powerdomain.h | 18 +++
2 files changed, 233 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index f6885f9..82797c2 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -17,8 +17,10 @@
#include linux/kernel.h
#include linux/types.h
#include linux/list.h
+#include linux/slab.h
#include linux/errno.h
#include linux/string.h
+#include linux/pm_qos.h
#include trace/events/power.h
#include cm2xxx_3xxx.h
@@ -113,6 +115,12 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
for (i = 0; i pwrdm-banks; i++)
pwrdm-ret_mem_off_counter[i] = 0;
+ /* Initialize the per-device wake-up constraints framework data */
+ mutex_init(pwrdm-wkup_lat_plist_lock);
+ plist_head_init(pwrdm-wkup_lat_plist_head);
+ pwrdm-wkup_lat_next_state = PWRDM_FUNC_PWRST_OFF;
+
+ /* Initialize the pwrdm state */
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_func_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
@@ -200,6 +208,58 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
return 0;
}
+/**
+ * _pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
+ * @pwrdm: struct powerdomain * to which requesting device belongs to.
+ * @min_latency: the allowed wake-up latency for the given power domain. A
+ * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm.
+ *
+ * Finds the power domain next power state that fulfills the constraint.
+ * Programs a new target state if it is different from current power state.
+ * The power domains get the next power state programmed directly in the
+ * registers.
+ *
+ * Returns 0 in case of success, -EINVAL in case of invalid parameters,
+ * or the return value from omap_set_pwrdm_state.
+ */
+static int _pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+ long min_latency)
+{
+ int ret = 0, state, new_state = PWRDM_FUNC_PWRST_ON;
+
+ if (!pwrdm) {
+ WARN(1, powerdomain: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
+
+ /*
+ * Find the next supported power state with
+ * wakeup latency = min_latency.
+ * Pick the lower state if no constraint on the pwrdm
+ * (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE).
+ * Skip the states marked as unsupported (UNSUP_STATE).
+ * If no power state found, fall back to PWRDM_FUNC_PWRST_ON.
+ */
+ for (state = 0x0; state PWRDM_MAX_FUNC_PWRSTS; state++) {
+ if ((min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE) ||
+ ((pwrdm-wakeup_lat[state] != UNSUP_STATE)
+ (pwrdm-wakeup_lat[state] = min_latency))) {
+ new_state = state;
+ break;
+ }
+ }
+
+ pwrdm-wkup_lat_next_state = new_state;
+ ret = omap_set_pwrdm_state(pwrdm, new_state);
+
+ pr_debug(%s: func pwrst for %s: curr=%d, next=%d, min_latency=%ld,
new_state=%d\n,
+ __func__, pwrdm-name, pwrdm_read_func_pwrst(pwrdm),
+ pwrdm_read_next_func_pwrst(pwrdm), min_latency, new_state);
+
+ return ret;
+}
+
+
/* Public functions */
/**
@@ -1317,6 +1377,161 @@ int pwrdm_post_transition(void)
}
/**
+ * pwrdm_wakeuplat_update_constraint - Set or update a powerdomain wakeup
+ * latency constraint and apply it
+ * @pwrdm: struct powerdomain * which the constraint applies to
+ * @cookie: constraint identifier, used for tracking
+ * @min_latency: minimum wakeup latency constraint (in microseconds) for
+ * the given pwrdm
+ *
+ * Tracks the constraints by @cookie.
+ * Constraint set/update: Adds a new entry to powerdomain's wake-up latency
+ * constraint list. If the constraint identifier already exists in the list,
+ * the old value is overwritten.
+ *
+ * Applies the aggregated constraint value for the given pwrdm by calling
+ * _pwrdm_wakeuplat_update_pwrst.
+ *
+ * Returns 0 upon success,
Re: MFD USB host: prevents CORE retention in idle
On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 [ 36.367126] pc : [c003c150] lr : [c02d75e4] psr: a013 [ 36.367126] sp : c5ebfe80 ip : c0a72fc0 fp : 0006 [ 36.379150] r10: c78af4b8 r9 : c0a3607c r8 : c003c13c [ 36.384643] r7 : r6 : r5 : c78af408 r4 : c78af408 [ 36.391479] r3 : r2 : r1 : c78af408 r0 : c78af400 [ 36.398315] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 36.405792] Control: 10c5387d Table: 86280019 DAC: 0015 [ 36.411834] Process sh (pid: 1254, stack limit = 0xc5ebe2f8) [ 36.417785] Stack: (0xc5ebfe80 to 0xc5ec) [ 36.422363] fe80: c78af408 c02d75e4 c0a36020 c0a36040 c78af408 c0f9e4a8 [ 36.430938] fea0: 0010 c0a36014 c0a36074 c02d8178 58566b0d 0008 58566b0d 0008 [ 36.439514] fec0: c0a1df38 0010 0003 c0a4d11c c09da45c [ 36.448089] fee0: 000ed008 c02d8a14 c0a62c28 c0080360 0003 c05b9ce8 0004 [ 36.456665] ff00: c04c9704 c78012c0 c00806a4 c5c8e000 0003 c05b9ce8 c007f8a8 [ 36.465240] ff20: c5c8d4c0 c5c8d4d8 c5ebff80 c7863e00 c02674a8 c02674c0 0004 c016d7fc [ 36.473815] ff40: c5d94a80 0004 b6ff6000 c5ebff80 c010c244 [ 36.482421] ff60: c0014400 c5c92280 c5d94a80 b6ff6000 0004 0004 c010c398 [ 36.490997] ff80: b6f235e8 0004 b6ff6000 b6f235e8 c00144a8 [ 36.499572] ffa0: c5ebe000 c00142e0 0004 b6ff6000 0001 b6ff6000 0004 [ 36.508148] ffc0: 0004 b6ff6000 b6f235e8 0004 0004 0964 000a 000ed008 [ 36.516723] ffe0: b6ff6000 bee815d0 b6e61c70 b6eb1abc 6010 0001 [ 36.525360] [c003c150] (_od_resume_noirq+0x14/0x58) from [c02d75e4] (dpm_run_callback+0x2c/0x74) [ 36.534973] [c02d75e4] (dpm_run_callback+0x2c/0x74) from [c02d8178] (dpm_resume_noirq+0xdc/0x2f4) [ 36.544677] [c02d8178] (dpm_resume_noirq+0xdc/0x2f4) from [c02d8a14] (dpm_resume_start+0xc/0x18) [ 36.554290] [c02d8a14] (dpm_resume_start+0xc/0x18) from [c0080360] (suspend_devices_and_enter+0x114/0x2d8) [ 36.564819] [c0080360] (suspend_devices_and_enter+0x114/0x2d8) from [c00806a4] (pm_suspend+0x180/0x1fc) [ 36.575042] [c00806a4] (pm_suspend+0x180/0x1fc) from [c007f8a8] (state_store+0x90/0x124) [ 36.583953] [c007f8a8] (state_store+0x90/0x124) from [c02674c0] (kobj_attr_store+0x18/0x1c) [ 36.593109] [c02674c0] (kobj_attr_store+0x18/0x1c) from [c016d7fc] (sysfs_write_file+0xfc/0x180) [ 36.602722] [c016d7fc] (sysfs_write_file+0xfc/0x180) from [c010c244] (vfs_write+0xb0/0x134) [ 36.611877] [c010c244] (vfs_write+0xb0/0x134) from [c010c398] (sys_write+0x40/0x70) [ 36.620300] [c010c398] (sys_write+0x40/0x70) from [c00142e0] (ret_fast_syscall+0x0/0x3c) [ 36.629180] Code: e1a04000 e258 01a02000 15902248 (e5d23018) [ 36.635833] ---[ end trace b3b167c1e86e5512 ]--- which kernel version are you using? do you have any good commit on which retention works because of usb host? regards keshava On Fri, Jun 8, 2012 at 7:55 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: yes! I am using the ramfs. regards keshava On Fri, Jun 8, 2012 at 7:31 PM, Kevin Hilman
Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
* Mohammed, Afzal af...@ti.com [120615 03:26]: Hi Jon, On Fri, Jun 15, 2012 at 00:28:44, Hunter, Jon wrote: On 06/14/2012 08:32 AM, Mohammed, Afzal wrote: On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote: Why? You currently have a global variable storing the clock handle. It can be quite common for drivers to know the clock frequencies of their functional clocks. How else can drivers calculate timings? Please see Russell King's comments, [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/27634 [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg05365.html Thanks. So I still think you need to get rid of the global variable for storing the gpmc fclk, that is really my point. So if you look at commit [1] mentioned by Russell in the above thread, the appropriate thing to do would be to create a gpmc clock alias for all OMAP2+ devices and then you could simply call the following from the gpmc probe ... gpmc_fck = clk_get(pdev-dev, fck); You could then store somewhere in one of the gpmc structures. Here clock is required even before driver is probed, i.e for platform to calculate timings, that has to be passed through platform data. Eventually we should be able to move the gpmc registration to the driver probe, especially with device tree. There's no need to set up gpmc before the driver probe runs for the device using gpmc. Just how the gpmc init gets called from the driver probe is still a bit open though.. It may require some bus level hooks, or wrapper drivers for the generic device drivers like smsc911x. I understand the necessity for clk rate information in driver, but seems unless we have a generic way to scale timings for all the kinds of peripheral, having it may not be of much help. We should not need to pass clock handles around. It's better to export some helper functions in the gpmc code for the calculation. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
board_onenand_init() build error in linux-next
Someone may have spotted this already... But if you build todays linux-next (next-20120615) without CONFIG_MTD_ONENAND_OMAP2 or CONFIG_MTD_ONENAND_OMAP2_MODULE then board_onenand_init() is defined in two places (in board-flash.c:102 as an empty function, and board-flash.h:56 as a static inline). This causes the build to fail as board-flash.c includes board-flash.h: CC arch/arm/mach-omap2/board-flash.o arch/arm/mach-omap2/board-flash.c:102:8: error: redefinition of 'board_onenand_init' arch/arm/mach-omap2/board-flash.h:56:20: note: previous definition of 'board_onenand_init' was here make[1]: *** [arch/arm/mach-omap2/board-flash.o] Error 1 I'm fairly sure this isn't right!? Cheers, Joe -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/14] GPMC driver conversion
* Mohammed, Afzal af...@ti.com [120615 04:00]: On Wed, Jun 13, 2012 at 18:03:05, Tony Lindgren wrote: And we need the device tree bindings for GPMC so we can start dropping board-*.c files as the GPMC seems to be last remaining blocker for making rarely used legacy boards DT only. So it might be worth playing with that so we don't again have to redo some parts. We would prefer to do it one step at a time, have driver conversion changes first in, and then work on DT migration. Once these changes are in we have a base to work on for further DT migration. Please let me know your opinion Sounds good to me. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Paul, On 6/15/2012 2:18 AM, Paul Walmsley wrote: On Thu, 14 Jun 2012, Cousson, Benoit wrote: On 6/14/2012 8:04 PM, Paul Walmsley wrote: On Thu, 14 Jun 2012, Cousson, Benoit wrote: (attribution lost) Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-no-idle mode, even while we continue to access it. Do you mean force-idle? Because accessing a module in no-idle is always possible. Thanks, that's indeed a description bug. I'm not sure to follow you? My point was it should be: So we can safely leave the 32k sync timer in force-idle mode, even while we continue to access it. This is what the WA is doing. I am expressing appreciation to you for pointing out something incorrect in the patch description, which has been fixed in the current version of the patch. OK, thanks for the clarification, I was confused by the sentence :-(. SIDLE_NO is the option that makes more sense to me. Consider an IP block with SIDLE_NO and SIDLE_FORCE but without SIDLE_SMART. When an initiator will access it, the default setting should be SIDLE_NO, for the reason that you identified above: because accessing a module in no-idle is always possible. On the other hand, we don't know when it's safe to access a module in SIDLE_FORCE unless we have additional information as to how the IP block handles the SIdleReq signal internally, and the characteristics of the clock domain in which it's integrated. ... This is the modulemode and clkdm static dependency / dynamic on OMAP3/4 that will guaranty that the OCP clock will be enabled upon any access to this L4_WKUP clock domain IPs. This has nothing to do with the SIDLE mode. I want to implement a behavior that does not implicitly assume that an IP block without smart-idle will only exist inside clockdomains which are guaranteed to be active when the kernel is running. That might be true for current WBU chips, but it seems unwise to make that assumption in general. 1- The fact that the IP does not support smart-idle does not change anything regarding the clock domain behavior. 2- So far the assumption is true for all the existing OMAP devices. Let's not anticipate something that will potentially never ever happen. It might be reasonable to remove the HWMOD_SWSUP_SIDLE flag from the 32k counter and just test again for HWMOD_ALWAYS_FORCE_SIDLE in the module disable. I'll take a look at this. Both should be removed as explained before. There is clearly no need for HWMOD_ALWAYS_FORCE_SIDLE. We are already explicitly listing the limitation through the idlemodes attribute. Only SIDLE_FORCE and SIDLE_NO are supported, so we already know that SIDLE_FORCE is the proper way to fix that limitation for the current OMAPs. Since there is no other IP with such limitation, we know as well that there will be no side effect. If, in the future, some more IPs will have that limitation and will not work as expected, it will mean that some other HW bugs will be there, and only these ones will have to be flagged. But my point is let's keep it simple and not try to anticipate future bugs. This flag is not require today, let's not add it. Which of these two behaviors do you feel is more future-proof, in general: 1. Implementing a target idle policy that could break if a hardware designer were to skip adding a target smart-idle mode to a module in a clockdomain that might go idle while the kernel was active? That's not fully accurate. Even with smart-idle implemented in this module, it will still go to idle automatically without any clock domain dependency properly handled. The goal of this fix is to adapt the SIDLE management for such module, it will not solve the overall idle management that is anyway handled at clock domain level whatever the SIDLE implementation. 2. Implementing a target idle policy that is guaranteed to allow initiator accesses to succeed by definition? It will not, as explained before. This is the clock domain settings that will make the whole thing working properly. considering that the implementation cost of either approach is identical? My point is simple, we should not add any new custom flag when all the information to detect such exception are already there in the current data and represent accurately what the HW is doing. So far every IPs that do not support SIDLE_SMART can/should use SIDLE_FORCE instead. 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
[PATCH] ARM: OMAP2: twl-common: Fix compiler warning
If the kernel is built only for OMAP2 the following warning will show up:
arch/arm/mach-omap2/twl-common.c:52: warning: ‘twl_set_voltage’ defined but not
used
arch/arm/mach-omap2/twl-common.c:58: warning: ‘twl_get_voltage’ defined but not
used
The twl_set/get_voltage callbacks only used when OMAP3/4 is selected.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 119d5a9..5447c13 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,6 +48,7 @@ static struct i2c_board_info __initdata
omap4_i2c1_board_info[] = {
},
};
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
struct voltagedomain *voltdm = (struct voltagedomain *)data;
@@ -59,6 +60,7 @@ static int twl_get_voltage(void *data)
struct voltagedomain *voltdm = (struct voltagedomain *)data;
return voltdm_get_voltage(voltdm);
}
+#endif
void __init omap_pmic_init(int bus, u32 clkrate,
const char *pmic_type, int pmic_irq,
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MFD USB host: prevents CORE retention in idle
Hi Keshava, On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: hi kevin now I am using initramfs with kernel linux3.5.rc1, but the retention is not working in 3430 sdp. I am seeing the following error followed by a crash echo mem /sys/power/state [ 35.609252] PM: Syncing filesystems ... done. [ 35.614654] PM: Preparing system for mem sleep [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 35.697692] PM: Entering mem sleep [ 35.722442] usb usb1: usb auto-resume [ 35.726409] ehci-omap ehci-omap.0: resume root hub [ 35.775451] hub 1-0:1.0: hub_resume [ 35.779846] hub 1-0:1.0: hub_suspend [ 35.784240] usb usb1: bus suspend, wakeup 0 [ 35.788665] ehci-omap ehci-omap.0: suspend root hub [ 35.805786] PM: suspend of devices complete after 99.304 msecs [ 35.816497] PM: late suspend of devices complete after 4.364 msecs [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs [ 35.838500] Disabling non-boot CPUs ... [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 [ 36.318481] Could not enter target state in pm_suspend [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual address 0018 [ 36.333557] pgd = c628 [ 36.336639] [0018] *pgd=85c8f831, *pte=, *ppte= [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM [ 36.348388] Modules linked in: [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 You need the fix from https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb Hope this helps! Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 12/12] ARM: OMAP2+: Simplify dmtimer clock aliases
Hi Paul,
On 06/14/2012 03:31 PM, Paul Walmsley wrote:
Hi Jon
On Tue, 5 Jun 2012, Jon Hunter wrote:
The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name
and
a con-id string to search for the appropriate functional clock.
Currently, we define a clock alias for each functional clock source each
timer
supports. Some functional clock sources are common to all of the timers on a
device and so for these clock sources we can use a single alias with a unique
con-id string.
The possible functional clock sources for an OMAP device are a 32kHz clock,
a system (MHz range) clock and (for OMAP2 only) an external clock. By
defining
a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
reduces code, speeds-up searches and clock initialisation time.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Sorry to make you change this, but how about adding the optional clock
aliases to the hwmod data instead?
Yes, we can do. However, technically these are not optional clocks but
parents clocks. So if you are ok with that we can.
So rather than:
+CLK(NULL, timer_32k_ck, func_32k_ck, CK_243X),
+CLK(NULL, timer_sys_ck, sys_ck,CK_243X),
+CLK(NULL, timer_ext_ck, alt_ck,CK_243X),
add something like (rough example):
static struct omap_hwmod_opt_clk timer_opt_clks[] = {
{ .role = 32k, .clk = func_32k_ck },
{ .role = sys, .clk = sys_ck },
{ .role = alt, .clk = alt_ck },
};
and then add the .opt_clks and .opt_clks_cnt fields to the struct
omap_hwmod records; see for example omap44xx_dss_hwmod.
Doing it this way will remove the clkdev entries, which we're trying to
get rid of. I hope also that these should be auto-generatable from the
hardware data at some point. And adding the opt_clk data should result in
a faster search time for these aliases, since only the omap_hwmod_opt_clk
records would need to be iterated over, rather than the clkdev data which
is quite a bit larger.
Ok, but what it not clear to me is how I retrieve the clock handle from
the driver. Is there an API I can use to retrieve the optional clocks
using the device structure? In other words, similar to clk_get()?
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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Paul, On 06/14/2012 07:20 PM, Paul Walmsley wrote: On Thu, 14 Jun 2012, Jon Hunter wrote: What does make this a bit more difficult is the function gpmc_round_ns_to_ticks(). It appears to convert nanoseconds to ticks and back to nanoseconds. I am guessing to account for some rounding error. I am curious what impact this function is having on the timing. Ideally this should be handle in gpmc_cs_set_timings(). I don't have the code in front of me at the moment, nor my old GPMC timing spreadsheet, so this comment may be superfluous. But since kernel arithmetic needs to be in integers, it might be necessary to do some of the timing calculations in picosecond units to avoid roundoff issues. A lot of the GPMC timing functions are converting to pico-seconds and then rounding up to nano-seconds. So I think that the calculations are ok. The real problem is, that as Afzal has highlighted, is that there is no common method between GPMC peripherals (onenand, smsc, etc) for populating the gpmc timings structure. This is going to cause a bit of a headache for migrating them over to DT. So what we need to do and maybe this is another series, separate from Afzal's series, is really clean-up the populating of the timings. 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] pinctrl: Add one-register-per-pin type device tree based pinctrl driver
On 06/15/2012 03:49 AM, Tony Lindgren wrote:
(Arnd, Grant, Rob, CC'ing you mainly re: the very last set of comments
in this email; can you take a look at Tony's patch and comment on the
binding)
* Stephen Warren swar...@wwwdotorg.org [120614 16:16]:
On 06/11/2012 07:58 AM, Tony Lindgren wrote:
Add one-register-per-pin type device tree based pinctrl driver.
Currently this driver only works on omap2+ series of processors,
where there is either an 8 or 16-bit padconf register for each pin.
Support for other similar pinmux controllers can be added.
diff --git
a/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
I'm not sure why you'd need an explicit OMAP2 binding document or
compatible values if it just uses the plain pinctrl-single binding
unmodified.
Hmm I thought that's what you wanted with your earlier comments at [1]:
* Stephen Warren swar...@wwwdotorg.org [120504 12:27]:
If this is truly intended to be generic, I would not document any of the
ti compatible values here. Instead, I'd create a binding document for
the TI controllers that basically just says this uses the bindings in
pinctrl-simple.txt, with the following additions, and list the
compatible values as an addition.
Care to clarify a bit what you had in mind there?
Basically I meant:
1) Remove anything TI-/OMAP-specific from the generic binding document
2) For any TI-/OMAP-specific additions, create a binding document that
describes those separately to the generic binding documentation.
However, given that there are no TI-/OMAP-specific additions; OMAP2 just
uses the base generic bindings exactly as defined, I don't think you
actually need to create an TI-/OMAP-specific document, since there's
nothing for it to document.
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
+static struct of_device_id pcs_of_match[] __devinitdata = {
+ { .compatible = DRIVER_NAME, },
+ { .compatible = ti,omap2420-padconf, },
+ { .compatible = ti,omap2430-padconf, },
+ { .compatible = ti,omap3-padconf, },
+ { .compatible = ti,omap4-padconf, },
+ { },
+};
Shouldn't that contain just one entry for pinctrl-single, and no others?
It's best to describe the hardware in case we need to set up some hardware
specific things in the driver.
There's a difference between the (set of) compatible value(s) that
appears in the .dts file, and the compatible value(s) that the driver
binds to.
Since this driver is purely implementing the pinctrl-single binding, I
believe only that should be listed in the driver's of_match table.
However, since the .dts file is describing HW that is both a specific
OMAP instance, and compatible with pinctrl-single, the .dts file can
certainly list both. If in the future, the driver ever needs to
specifically know the difference between the specific OMAP versions, or
OMAP-vs-something-else, the compatible value will be there already in
the .dts file, so this will all work. However, I'd argue that if the
driver has to ever know that, it's probably not appropriate to say it's
compatible with pinctrl-single any more...
One final comment: A little while before Linaro Connect in San
Francisco, we were all having difficulty coming up with any kind of DT
binding for pinctrl. I had suggested the possibility of creating a
binding which just said write value X to register Y, write value P to
register Q, This was rejected at connect, because a raw list of
register writes didn't document anything or describe semantics - it was
too much of a binary blob. This driver seems to be doing almost the
exact same thing. In order to avoid that assertion, it'd need to truly
have individual representations of which pins exist, which pingroups
exist, which functions exist, and which functions can be selected onto
which pins/pingroups. That would be a radically different binding. I
wonder what's changed such that this kind of driver wasn't acceptable
then, but is now?
Well that's why I had two bindings earlier: The current binding for the
bulk pins that's faster to parse, and a more verbose binding for drivers that
allows naming the functions.
In your previous comments at [1] you seemed to prefer this current binding
based on the Why not only allow (1)? comment. Maybe you had something else
in mind, care to clarify that a bit too?
Well, first I thought about semantics vs. just banging a register list a
tiny bit more, and remembered the previous discussion.
But my comment at [1] wasn't so much about why not just have a raw
register list, but more regarding why support two different
representations within the same binding; it wasn't really clear to me
from reading the original email what the difference between the two
representations; why have two representations, why/when-to use one vs.
the other, that the difference was about providing a semantic list of
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 6/15/2012 1:27 AM, Arnd Bergmann wrote:
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
controller with its slave ID separately, even if that means a lot
of duplicate data for shmobile.
So, you don't think it's worth making a short-cut possible to specify a
DMAC type instead of each instance phandle? It really would mean __a lot__
of duplication - with 3 generic controllers on (some) current chips and
possibly more on those, that I'm not aware about.
It's certainly possible to make that short-cut, but I'm not convinced
if it's worth it. One thing you can do is create a meta-device for
all of the identical DMA controllers, and refer to that one from the
devices, but make it a separate device node from the actual controllers,
of which you can have more than one. This makes the binding for your
dma controller more complex but reduces the amount of data required
in the other device nodes.
In case of sh7372, this could look something like
dma: dmac-mux {
compatible = renesas,sh-dma-mux;
#dma-cells =4; /* slave-id, addr, chcr, mid-rid */
#address-cells =1;
#size-cells =1;
ranges;
In light of the reg entries below, perhaps #size-cells=0 ?
dmae@0xfe008020{
compatible = renesas,sh-dma;
reg =0xfe008020 0xfe00828f
0xfe009000 0xfe00900b
interrupts =0x20c0 0x2000 0x2020 0x2040 0x2060 0x2080
0x20a0;
};
dmae@0xfe018020{
compatible = renesas,sh-dma;
reg =0xfe018020 0xfe01828f
0xfe019000 0xfe01900b
interrupts =0x21c0 0x2100 0x2120 0x2140 0x2160 0x2180
0x21a0;
};
dmae@0xfe028020{
compatible = renesas,sh-dma;
reg =0xfe028020 0xfe02828f
0xfe029000 0xfe02900b
interrupts =0x22c0 0x2200 0x2220 0x2240 0x2260 0x2280
0x22a0;
};
};
This way, a slave would refer to the dmac-mux node and while
the device driver binds to the child nodes.
I'm not sure I understand what the configuration register values
above are.
As I explained in an earlier mail, those include transfer size and other
parameters, but cannot be completely calculated in device drivers, because
they also vary between SoCs.
Yes, but they can be part of the device tree source, because when writing
that, you know both the requirements of the device and the capabilities
of the controller.
Arnd
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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: Problems in the DaVinci EMAC driver AM35xx?
We continue to try to sort this out. Ignoring the errors for a moment, has
anyone else experienced the performance slowdown quoted below between two EMACs?
If not, could anyone with two AM3517-baed platforms with the EMACs exposed
please test this for us? We've run several tests between all the hardware we
have available, and all perform like this. Connecting an EMAC to another EMAC
and testing with iperf (iperf -s on one side, iperf -c IP on the other)
shows the performance drop vs. connecting the same EMAC to nearly any other
non-EMAC NIC and running the same test, even through the same infrastructure.
Our theory is that this could be a driver issue that when only 1 side has it,
performance is fine. However, if both sides have the same issue, as in the
case of EMAC to EMAC, the performance degrades significantly.
Thanks again for looking.
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
{{ DaVinci EMAC server, PC client }}
[ 4] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44452
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44459
[ 5] 0.0-10.1 sec 114 MBytes 94.0 Mbits/sec
[ 4] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44467
[ 4] 0.0-10.1 sec 113 MBytes 94.1 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44474
[ 5] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec
[ 4] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44481
[ 4] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44488
[ 5] 0.0- 9.8 sec 110 MBytes 94.1 Mbits/sec
{{ same DaVinci EMAC server, still running, just changed to DaVinci EMAC client
}}
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37325
[ 5] 0.0-10.4 sec 73.9 MBytes 59.6 Mbits/sec
[ 6] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37326
[ 6] 0.0-10.8 sec 61.5 MBytes 47.8 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37327
[ 5] 0.0-10.3 sec 64.6 MBytes 52.6 Mbits/sec
[ 6] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37328
[ 6] 0.0-10.0 sec 78.2 MBytes 65.5 Mbits/sec
--
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] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar jaswinder.si...@linaro.org
Explicitly maintaining HDMI phy power state using a flag is prone to
race and un-necessary when we have a zero-cost alternative of checking
the state before trying to set it.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/ti_hdmi.h |1 -
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 11 ---
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index e734cb4..d174ca1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -177,7 +177,6 @@ struct hdmi_ip_data {
/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
int hpd_gpio;
- bool phy_tx_enabled;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4dae1b2..3fa3d98 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -157,6 +157,10 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data)
/* PHY_PWR_CMD */
static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr
val)
{
+ /* Return if already the state */
+ if (REG_GET(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, 5, 4) == val)
+ return 0;
+
/* Command for power control of HDMI PHY */
REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
@@ -241,11 +245,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd == ip_data-phy_tx_enabled) {
- spin_unlock_irqrestore(phy_tx_lock, flags);
- return 0;
- }
-
if (hpd)
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
else
@@ -257,7 +256,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
goto err;
}
- ip_data-phy_tx_enabled = hpd;
err:
spin_unlock_irqrestore(phy_tx_lock, flags);
return r;
@@ -327,7 +325,6 @@ void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data)
free_irq(gpio_to_irq(ip_data-hpd_gpio), ip_data);
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
- ip_data-phy_tx_enabled = false;
}
static int hdmi_core_ddc_init(struct hdmi_ip_data *ip_data)
--
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 V2 5/5] Input: ads7846: set proper debounce time in driver level
On 2012年06月14日 14:59, Zumeng Chen wrote: 于 2012年06月14日 14:31, Hiremath, Vaibhav 写道: On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote: 于 2012年06月13日 20:18, Hiremath, Vaibhav 写道: On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote: From: Zumeng Chenzumeng.c...@windriver.com If we don't set proper debouce time for ads7846, then there are flooded interrupt counters of ads7846 responding to one time touch on screen, so the driver couldn't work well. And since most OMAP3 series boards pass NULL pointer of board_pdata to omap_ads7846_init, so it's more proper to set it in driver level after having gpio_request done. This patch has been validated on 3530evm. Signed-off-by: Zumeng Chenzumeng.c...@windriver.com Signed-off-by: Syed Mohammed Khasimkha...@ti.com --- drivers/input/touchscreen/ads7846.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index f02028e..459ff29 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct ads784 } ts-gpio_pendown = pdata-gpio_pendown; +#ifdef CONFIG_ARCH_OMAP3 + /* 310 means about 10 microsecond for omap3 */ + gpio_set_debounce(pdata-gpio_pendown, 310); +#endif Zumeng, With my sign-off you are changing the original code, that too without my sign-off and ack. I wouldn't mind you to submit patches from my tree, but the expectation is if you are changing the original code, it should be under your sign-off. Thanks, good to learn. I'll remove in next time. Coming to the patch, #ifdef in driver is not recommended, and this 10msec delay is specific to OMAP GPIO and driver should not be aware of this, that's where you will find the original patch handling it in board file. According to the git blame of the board-omap3evm.c I think 96974a24 did a good thing to all the related codes for omap3 boards. So I think we can call board and driver as BSP level :-) If #ifdef in driver can save many codes, I guess it's deserved. No, not really. In the same commit, the debounce time is already handled as an argument to the function omap_ads7846_init(), and that’s the way it should be. That means you'd like to implement the same get_pendown_state for every omap3 board? Currently, board_pdata is NULL. And actually, the reason why I agree 96974a24 is that get_pendown_state for all omap3 boards is the common chip level gpio operations. so I think we should set debounce for them in one common point. But since Igor and you don't like them, I have created and tested the attachment patch, and I'd like Mike to check if convenience too But obviously there are more codes than mine before :-) Tony Mike, How about your comments on this issue? Do you think the following is acceptable VS my last email _attachment_. +#ifdef CONFIG_ARCH_OMAP3 + /* 310 means about 10 microsecond for omap3 */ + gpio_set_debounce(pdata-gpio_pendown, 310); +#endif Regards, Zumeng Regards, Zumeng So no need for #ifdefs in driver... Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 12/12] ARM: OMAP2+: Simplify dmtimer clock aliases
On Tue, 5 Jun 2012, Jon Hunter wrote: The OMAP dmtimer driver allows you to dynamically configure the functional clock that drives the timer logic. The dmtimer driver uses the device name and a con-id string to search for the appropriate functional clock. Currently, we define a clock alias for each functional clock source each timer supports. Some functional clock sources are common to all of the timers on a device and so for these clock sources we can use a single alias with a unique con-id string. The possible functional clock sources for an OMAP device are a 32kHz clock, a system (MHz range) clock and (for OMAP2 only) an external clock. By defining a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This reduces code, speeds-up searches and clock initialisation time. Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Paul Walmsley p...@pwsan.com At some point we should probably investigate moving these aliases into the hwmod optional clocks, but this requires more thought. - 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
[PATCH 0/3] OMAP: hwmod: reset API proposal
Recent changes in omap_hwmod framework have reworked the behaviour towards hardreset handling, commit 747834a (ARM: OMAP2+: hwmod: revise hardreset behavior) recommends for drivers to implement their own reset sequences until code out-of-tree hits mainline and then their needs and code can be reviewed. Since it is not clear when this will occur for all drivers and hwmod code was not deleted (presumably because at some point it will handle the resets once again), this series exports functions to handle hardreset lines in an attempt to reduce code duplication for those who have a common reset sequence. These APIs are intended to be used by iommu for now, but were tested with IPU and remoteproc on Pandaboard. Omar Ramirez Luna (3): ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled ARM: OMAP: hwmod: revise deassert sequence ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices arch/arm/mach-omap2/omap_hwmod.c | 70 +++-- arch/arm/plat-omap/include/plat/omap_device.h |4 ++ arch/arm/plat-omap/omap_device.c | 45 3 files changed, 103 insertions(+), 16 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- cpu1 might not be used and hence (with previous check)
won't be fully enabled by hwmod code.
While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bf86f7e..5f0811a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1537,25 +1537,28 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
}
/**
- * _are_any_hardreset_lines_asserted - return true if part of @oh is hard-reset
+ * _are_all_hardreset_lines_asserted - return true if the @oh is hard-reset
* @oh: struct omap_hwmod *
*
- * If any hardreset line associated with @oh is asserted, then return true.
- * Otherwise, if @oh has no hardreset lines associated with it, or if
- * no hardreset lines associated with @oh are asserted, then return false.
+ * If all hardreset lines associated with @oh are asserted, then return true.
+ * Otherwise, if part of @oh is out hardreset or if no hardreset lines
+ * associated with @oh are asserted, then return false.
* This function is used to avoid executing some parts of the IP block
- * enable/disable sequence if a hardreset line is set.
+ * enable/disable sequence if its hardreset line is set.
*/
-static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+static bool _are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
{
- int i;
+ int i, rst_cnt = 0;
if (oh-rst_lines_cnt == 0)
return false;
for (i = 0; i oh-rst_lines_cnt; i++)
if (_read_hardreset(oh, oh-rst_lines[i].name) 0)
- return true;
+ rst_cnt++;
+
+ if (oh-rst_lines_cnt == rst_cnt)
+ return true;
return false;
}
@@ -1578,6 +1581,13 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
return -EINVAL;
+ /*
+* Since integration code might still be doing something, only
+* disable if all lines are under hardreset.
+*/
+ if (!_are_all_hardreset_lines_asserted(oh))
+ return 0;
+
pr_debug(omap_hwmod: %s: %s\n, oh-name, __func__);
omap4_cminst_module_disable(oh-clkdm-prcm_partition,
@@ -1585,9 +1595,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
oh-clkdm-clkdm_offs,
oh-prcm.omap4.clkctrl_offs);
- if (_are_any_hardreset_lines_asserted(oh))
- return 0;
-
v = _omap4_wait_target_disable(oh);
if (v)
pr_warn(omap_hwmod: %s: _wait_target_disable failed\n,
@@ -1779,7 +1786,7 @@ static int _enable(struct omap_hwmod *oh)
}
/*
-* If an IP block contains HW reset lines and any of them are
+* If an IP block contains HW reset lines and all of them are
* asserted, we let integration code associated with that
* block handle the enable. We've received very little
* information on what those driver authors need, and until
@@ -1787,7 +1794,7 @@ static int _enable(struct omap_hwmod *oh)
* posted to the public lists, this is probably the best we
* can do.
*/
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
/* Mux pins for device runtime if populated */
@@ -1863,7 +1870,7 @@ static int _idle(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
if (oh-class-sysc)
@@ -1948,7 +1955,7 @@ static int _shutdown(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
pr_debug(omap_hwmod: %s: disabling\n, oh-name);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence
For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5f0811a..8a7e5bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1472,7 +1472,7 @@ static int _assert_hardreset(struct omap_hwmod *oh, const
char *name)
static int _deassert_hardreset(struct omap_hwmod *oh, const char *name)
{
struct omap_hwmod_rst_info ohri;
- int ret;
+ int ret, hwsup = 0;
if (!oh)
return -EINVAL;
@@ -1481,6 +1481,23 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
+ if (oh-clkdm) {
+ /*
+* A clockdomain must be in SW_SUP otherwise reset
+* might not be completed. The clockdomain can be set
+* in HW_AUTO only when the module become ready.
+*/
+ hwsup = clkdm_in_hwsup(oh-clkdm);
+ ret = clkdm_hwmod_enable(oh-clkdm, oh);
+ if (ret) {
+ WARN(1, omap_hwmod: %s: could not enable clockdomain
%s: %d\n,
+oh-name, oh-clkdm-name, ret);
+ return ret;
+ }
+ }
+
+ _enable_clocks(oh);
+
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift,
@@ -1497,9 +1514,23 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
return -EINVAL;
}
+ _disable_clocks(oh);
+
if (ret == -EBUSY)
pr_warning(omap_hwmod: %s: failed to hardreset\n, oh-name);
+ if (!ret) {
+ /*
+* Set the clockdomain to HW_AUTO, assuming that the
+* previous state was HW_AUTO.
+*/
+ if (oh-clkdm hwsup)
+ clkdm_allow_idle(oh-clkdm);
+ } else {
+ if (oh-clkdm)
+ clkdm_hwmod_disable(oh-clkdm, oh);
+ }
+
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices
This APIs are meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data
to control their reset lines, they are expected to know the name
of the reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++
arch/arm/plat-omap/omap_device.c | 45 +
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 4327b2c..27bcc24 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -118,6 +118,10 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev);
/* Other */
+int omap_device_assert_hardreset(struct platform_device *pdev,
+const char *name);
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+const char *name);
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..8883074 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -925,6 +925,51 @@ int omap_device_shutdown(struct platform_device *pdev)
}
/**
+ * omap_device_assert_hardreset - set a device's reset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * with the name of the reset line
+ *
+ * According to @name, set the reset line of the hwmods associated
+ * with this @pdev deivce.
+ */
+int omap_device_assert_hardreset(struct platform_device *pdev, const char
*name)
+{
+ int i, ret = 0;
+ struct omap_device *od = to_omap_device(pdev);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ ret = omap_hwmod_assert_hardreset(od-hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
+ * omap_device_deassert_hardreset - lift a device's reset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * with the name of the reset line
+ *
+ * According to @name, lift the reset line of the hwmods associated
+ * with this @pdev deivce.
+ */
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+ const char *name)
+{
+ int i, ret = 0;
+ struct omap_device *od = to_omap_device(pdev);
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+ ret = omap_hwmod_deassert_hardreset(od-hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
* omap_device_align_pm_lat - activate/deactivate device to match wakeup lat
lim
* @od: struct omap_device *
*
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
Introduced hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Due to compatibility an ifdef needs to be propagated (previously on iommu resource info) to hwmod data in OMAP3, so users of iommu and tidspbridge can avoid issues of two modules managing mmu data/irqs/resets; this until tidspbridge can be safely migrated to iommu framework. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling, based on a series that needs to be accepted first. - Fix for compile break if IOMMU_API is not selected. Previous work can be found at: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60133.html Omar Ramirez Luna (6): ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected ARM: OMAP3: hwmod data: add mmu data for iva and isp ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP2+: iommu: add reset handling ARM: OMAP3/4: iommu: adapt to runtime pm arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/iommu2.c | 36 -- arch/arm/mach-omap2/omap-iommu.c | 166 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 115 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 ++- arch/arm/plat-omap/include/plat/iommu.h| 25 - arch/arm/plat-omap/include/plat/iommu2.h |2 - drivers/iommu/omap-iommu.c | 68 ++- 8 files changed, 346 insertions(+), 204 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen, when hwmod includes iommu.h to get the
structure for attributes.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/include/plat/iommu.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 88be3e6..e58d571 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -126,6 +126,7 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
+#ifdef CONFIG_IOMMU_API
/**
* dev_to_omap_iommu() - retrieves an omap iommu object from a user device
* @dev: iommu client device
@@ -136,6 +137,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
return arch_data-iommu_dev;
}
+#endif
/* IOMMU errors */
#define OMAP_IOMMU_ERR_TLB_MISS(1 0)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: OMAP3: hwmod data: add mmu data for iva and isp
Add mmu hwmod data for iva and isp.
Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be migrated
to iommu framework.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 117
arch/arm/plat-omap/include/plat/iommu.h| 13 +++
2 files changed, 130 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 0ea53bc..89df566 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -27,6 +27,7 @@
#include plat/mcbsp.h
#include plat/mcspi.h
#include plat/dmtimer.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
@@ -2777,6 +2778,118 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* isp mmu */
+
+static struct omap_mmu_dev_attr isp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 8,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_isp_mmu_irqs[] = {
+ { .irq = 24 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap3xxx_isp_mmu_addrs[] = {
+ {
+ .pa_start = 0x480bd400,
+ .pa_end = 0x480bd47f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_core - isp mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__isp_mmu = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_isp_mmu_hwmod,
+ .addr = omap3xxx_isp_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_isp_mmu_hwmod = {
+ .name = isp_mmu,
+ .class = omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_isp_mmu_irqs,
+ .main_clk = cam_ick,
+ .dev_attr = isp_mmu_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+/* iva mmu */
+
+static struct omap_mmu_dev_attr iva_mmu_dev_attr = {
+ .da_start = 0x1100,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_iva_mmu_irqs[] = {
+ { .irq = 28 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap3xxx_iva_mmu_resets[] = {
+ { .name = mmu, .rst_shift = 1, .st_shift = 9 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_iva_mmu_addrs[] = {
+ {
+ .pa_start = 0x5d00,
+ .pa_end = 0x5d7f,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main - iva mmu */
+static struct omap_hwmod_ocp_if omap3xxx_l3_main__iva_mmu = {
+ .master = omap3xxx_l3_main_hwmod,
+ .slave = omap3xxx_iva_mmu_hwmod,
+ .addr = omap3xxx_iva_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap3xxx_iva_mmu_hwmod = {
+ .name = iva_mmu,
+ .class = omap3xxx_mmu_hwmod_class,
+ .mpu_irqs = omap3xxx_iva_mmu_irqs,
+ .rst_lines = omap3xxx_iva_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_iva_mmu_resets),
+ .main_clk = iva2_ck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430_IVA2_MOD,
+ },
+ },
+ .dev_attr = iva_mmu_dev_attr,
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* l4_per - gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3174,6 +3287,10 @@ static struct omap_hwmod_ocp_if
*omap3xxx_hwmod_ocp_ifs[] __initdata = {
omap34xx_l4_core__mcspi2,
omap34xx_l4_core__mcspi3,
omap34xx_l4_core__mcspi4,
+ omap3xxx_l4_core__isp_mmu,
+#ifdef CONFIG_OMAP_IOMMU_IVA2
+ omap3xxx_l3_main__iva_mmu,
+#endif
omap3xxx_l4_wkup__counter_32k,
NULL,
};
diff --git
[PATCH 3/6] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Add mmu hwmod data for ipu and dsp.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ebf9657..3879e9c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
#include plat/mmc.h
#include plat/dmtimer.h
#include plat/common.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
@@ -614,7 +615,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = dsp, .rst_shift = 0 },
- { .name = mmu_cache, .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1629,7 +1629,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = cpu0, .rst_shift = 0 },
{ .name = cpu1, .rst_shift = 1 },
- { .name = mmu_cache, .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2436,6 +2435,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* ipu mmu */
+
+static struct omap_mmu_dev_attr ipu_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_ipu_mmu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_ipu_mmu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_ipu_mmu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 - ipu_mmu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__ipu_mmu = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_ipu_mmu_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_ipu_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_ipu_mmu_hwmod = {
+ .name = ipu_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_ipu_mmu_irqs,
+ .rst_lines = omap44xx_ipu_mmu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_mmu_resets),
+ .main_clk = ipu_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = ipu_mmu_dev_attr,
+};
+
+/* dsp mmu */
+
+static struct omap_mmu_dev_attr dsp_mmu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_dsp_mmu_irqs[] = {
+ { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_dsp_mmu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dsp_mmu_addrs[] = {
+ {
+ .pa_start = 0x4a066000,
+ .pa_end = 0x4a0660ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_cfg - dsp */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dsp_mmu = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_dsp_mmu_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_dsp_mmu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_dsp_mmu_hwmod = {
+ .name = dsp_mmu,
+ .class = omap44xx_mmu_hwmod_class,
+
[PATCH 4/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 159 ++-
arch/arm/plat-omap/include/plat/iommu.h |2 +-
drivers/iommu/omap-iommu.c |3 -
5 files changed, 33 insertions(+), 152 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2a4fc0d..5b66efa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -216,7 +216,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = isp_mmu,
};
struct isp_platform_data {
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index ac49384..02d98ce 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,56 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include plat/iommu.h
#include plat/irqs.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = OMAP44XX_IRQ_DUCATI_MMU,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_MPU_TESLA_IOMMU)
- {
-
[PATCH 5/6] ARM: OMAP2+: iommu: add reset handling
Recent changes in hwmod now require for drivers to handle reset
lines. Otherwise iommu initialization will fail.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap-iommu.c|6 ++
arch/arm/plat-omap/include/plat/iommu.h |6 ++
drivers/iommu/omap-iommu.c | 20 ++--
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02d98ce..96eecd8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -37,6 +37,12 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
+ if (oh-rst_lines_cnt == 1) {
+ pdata-reset_name = oh-rst_lines-name;
+ pdata-assert_reset = omap_device_assert_hardreset;
+ pdata-deassert_reset = omap_device_deassert_hardreset;
+ }
+
pdev = omap_device_build(omap-iommu, i, oh, pdata, sizeof(*pdata),
NULL, 0, 0);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index ed56424..bb15b85 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,8 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include linux/platform_device.h
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -119,9 +121,13 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
const char *clk_name;
+ const char *reset_name;
int nr_tlb_entries;
u32 da_start;
u32 da_end;
+
+ int (*assert_reset)(struct platform_device *pdev, const char *name);
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
};
/**
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 93d7d84..f0d6865 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -125,13 +125,23 @@ EXPORT_SYMBOL_GPL(omap_iommu_arch_version);
static int iommu_enable(struct omap_iommu *obj)
{
int err;
+ struct platform_device *pdev = to_platform_device(obj-dev);
+ struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!obj)
+ if (!obj || !pdata)
return -EINVAL;
if (!arch_iommu)
return -ENODEV;
+ if (pdata-deassert_reset) {
+ err = pdata-deassert_reset(pdev, pdata-reset_name);
+ if (err) {
+ dev_err(obj-dev, deassert_reset failed: %d\n, err);
+ return err;
+ }
+ }
+
clk_enable(obj-clk);
err = arch_iommu-enable(obj);
@@ -142,7 +152,10 @@ static int iommu_enable(struct omap_iommu *obj)
static void iommu_disable(struct omap_iommu *obj)
{
- if (!obj)
+ struct platform_device *pdev = to_platform_device(obj-dev);
+ struct iommu_platform_data *pdata = pdev-dev.platform_data;
+
+ if (!obj || !pdata)
return;
clk_enable(obj-clk);
@@ -150,6 +163,9 @@ static void iommu_disable(struct omap_iommu *obj)
arch_iommu-disable(obj);
clk_disable(obj-clk);
+
+ if (pdata-assert_reset)
+ pdata-assert_reset(pdev, pdata-reset_name);
}
/*
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Due to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 17 ---
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 -
arch/arm/plat-omap/include/plat/iommu2.h |2 -
drivers/iommu/omap-iommu.c | 45 -
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 96eecd8..e8f88dc 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -32,7 +32,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index bb15b85..004cb9e 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -30,7 +30,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -120,7 +119,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f0d6865..5daf4fd 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/mutex.h
#include linux/spinlock.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -158,11 +157,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset)
