Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
Hello, After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got some err infos with latest Linus's tree, does somebody also has the same issue? sound/soc/omap/omap-hdmi.c:45:24: error: field 'dss_audio' has incomplete type sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_startup': sound/soc/omap/omap-hdmi.c:67:27: error: 'struct omap_dss_driver' has no member named 'audio_supported' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:79:29: error: 'struct omap_dss_driver' has no member named 'audio_enable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_hw_params': sound/soc/omap/omap-hdmi.c:208:28: error: 'struct omap_dss_driver' has no member named 'audio_config' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_trigger': sound/soc/omap/omap-hdmi.c:224:29: error: 'struct omap_dss_driver' has no member named 'audio_start' sound/soc/omap/omap-hdmi.c:229:23: error: 'struct omap_dss_driver' has no member named 'audio_stop' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_shutdown': sound/soc/omap/omap-hdmi.c:242:22: error: 'struct omap_dss_driver' has no member named 'audio_disable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:80:1: warning: control reaches end of non-void function Regards, Xiao -- To unsubscribe from this list: send the line unsubscribe 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] mmc: omap: Fix broken reg_shift initialization
Commit fa550189 (mmc: core: Prevent eMMC VCC supply to be cut from late init) slightly affected timings for how things are done for the omap MMC driver causing the MMC cards not getting detected any longer. Turns out this was caused by buggy reg_shift initialization in the omap MMC driver that was happening after mmc_add_host() was being called. Fix this by initializing reg_shift before mmc_add_host() is called. Signed-off-by: Tony Lindgren t...@atomide.com --- Heh found it! Chris, maybe Cc stable on this one? --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1485,6 +1485,7 @@ static int __devinit mmc_omap_probe(struct platform_device *pdev) } host-nr_slots = pdata-nr_slots; + host-reg_shift = (cpu_is_omap7xx() ? 1 : 2); host-mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0); if (!host-mmc_omap_wq) @@ -1500,8 +1501,6 @@ static int __devinit mmc_omap_probe(struct platform_device *pdev) } } - host-reg_shift = (cpu_is_omap7xx() ? 1 : 2); - return 0; err_destroy_wq: -- To unsubscribe from this list: send the line unsubscribe 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] watchdog: omap_wdt: add device tree support
On 5/30/2012 5:18 AM, Xiao Jiang wrote:
Jon Hunter wrote:
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
From: Xiao Jiang jgq...@gmail.com
Add device table for omap_wdt to support dt.
Signed-off-by: Xiao Jiang jgq...@gmail.com
---
drivers/watchdog/omap_wdt.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..d98c615 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -430,6 +430,13 @@ static int omap_wdt_resume(struct
platform_device *pdev)
#define omap_wdt_resume NULL
#endif
+static const struct of_device_id omap_wdt_of_match[] = {
+ { .compatible = ti,omap3-wdt, },
+ { .compatible = ti,omap4-wdt, },
If there is no difference between the OMAP3 and the OMAP4 WDT IP, just
add one entry ti,omap3-wdt. And then in the OMAP4 DTS you will just
put : compatible = ti,omap3-wdt; or compatible = ti,omap4-wdt,
ti,omap3-wdt;
I'm still a little bit confused about the real need for the
ti,omap4-wdt: entry, but it seems to be the way to do it in PPC.
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
+
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
.remove = __devexit_p(omap_wdt_remove),
@@ -439,6 +446,7 @@ static struct platform_driver omap_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = omap_wdt,
+ .of_match_table = omap_wdt_of_match,
},
};
I think we need to add some code to the probe function that calls
of_match_device() and ensures we find a match. For example ...
if (of_have_populated_dt())
if (!of_match_device(omap_wdt_of_match, pdev-dev))
return -EINVAL;
Will add it in v2, thanks for suggestion.
No, in fact this is not needed. We need that mainly when several
instances can match the same driver and thus we select the proper one
using the of_match_device. Otherwise, just check is the device_node is
there.
In that case, the driver does not even care about any DT node so there
is no need to add extra code for that. Keep it simple.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Tue, 2012-05-29 at 14:32 -0500, Menon, Nishanth wrote:
On Mon, May 14, 2012 at 5:03 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1599,6 +1629,8 @@ static int _enable(struct omap_hwmod *oh)
_enable_clocks(oh);
_enable_module(oh);
+ _omap4_update_context_lost(oh);
+
r = _wait_target_ready(oh);
if (!r) {
/*
Dumb q: Since we monitor the count around _enable, how do we ensure
that context loss counter is accurate
around OFF and idle transitions for domains that could have been
hwauto? it might be good to have limitations
in the $commit_message if it is not targeted to do so.
True, I can add a comment to the commit msg about this.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP4: add support for TPS62361 PMIC
On Tue, 2012-05-29 at 14:29 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Hi, This set adds support for TPS62361 PMIC, which is used to power MPU voltagedomain on OMAP4460 boards. These patches apply on top of 3.4 + my voltagedomain fixes set to avoid adding redundant code. Hmm... do you have an updated version of your voltagedomain fixes? Or are you waiting for me to review something? I thought I had been through them already, but if I have not, they slipped throught the cracks. I'm sorry. Can you please update/repost? There have been some updates to the patches as per Nishanth's comments, but I need to double check those before re-posting here. I can re-post this series also once that is done. -Tero Thanks. Kevin Working tree available here for interested parties: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-voltdm-tps-v1 Tree has been tested with: - omap3beagle board - omap4panda es board (OMAP4460) - omap4blaze board (OMAP4430) Tested modifying the voltage levels on all core regulators (vdd1...vdd3) and measuring that the voltages do actually change. Patch #1 was needed before the voltages could be modified on a panda board es device, otherwise the timing for the I2C channel was so bogus it usually failed. The values used were taken from an android tree and are based on TI analysis. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/19] ARM: OMAP4: PM: Add device-off support
On Tue, 2012-05-29 at 11:31 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: On Wed, 2012-05-16 at 15:36 -0700, Kevin Hilman wrote: +Jean for functional power states Tero Kristo t-kri...@ti.com writes: This patch adds device off support to OMAP4 device type. Description is rather thin for a patch that is doing so much. OFF mode is disabled by default, why? Good question. For historical reference I guess. The device off works pretty nicely with the current kernel already, so it should be possible to enable it by default and blame the people who break it. however, there are two ways to enable OFF mode: a) In the board file, call omap4_pm_off_mode_enable(1) b) Enable OFF mode using the debugfs entry echo 1/sys/kernel/debug/pm_debug/enable_off_mode (conversely echo '0' will disable it as well). This part needs to be a separate patch. But, as stated in the core retention series, I'd like to move away from these global flags all together. The way we manage the disabling of certain states (like off) is already clumsy for OMAP3, and it's getting worse with OMAP4. Basically, I think this feature needs to be supported by using constraints on functional power states. Having checks all over the place is getting unwieldy and not attractive to maintain. The combination of constraints and functional power states should make this much more manageable. Until we have that, I'd prefer to keep the debugfs enable/disable stuff as separate patches at the end of the series used only for testing. Okay, this sounds like a good plan. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [t-kri...@ti.com: largely re-structured the code] then the sign-off above from Santosh probably doesn't apply anymore. You should change that to a Cc and just mention tht this is based upon some original work from Santosh. Yeah... I am not quite sure where the line goes here as I am modifying the patches quite heavily but try to keep credits to the original authors... will change this like so. I guess it's up to you whether you keep Santosh as author. It all depends how much you've changed the original. But you can use the changlog to give credits to Santosh, or state it was a collaboration, whatever you like. You can say stuff like based on an origianl patch by..., and/or briefly summarize the changes you made from the original verions, etc. First, some general comments: There is a lot going on in this patch, so it is hard to follow what all is related, and why. Just a quick glance suggests it needs to be broken up into at least a few parts: What is the merge plan for the func power state stuff? I don't want to create new dependencies if unnecessary. Otherwise the split should be okay. - low-level PRM support: new APIs for various off-mode features) (should probably be done on top of functional power states) - powerdomain core support or achievable states (should probably be done on top of functional power states) - IRQ/GIC context save/restore - secure RAM save/restore (this has been tightly coupled to the GIC but it's not obvious why) This is tightly coupled to GIC because the ROM code has following API calls: - save gic - save secure RAM - save secure all (gic + RAM + some other mysterious stuff) It is difficult/impossible to separate these without adding redundant code execution (e.g. doing a GIC save from the GIC code + then doing a second GIC save with save secure all from core PM code.) Ok, thanks for clarifying. That should be explained in the changelog for this patch when it's broken up. Ok will add some comment about this. - PM debug support to enable/disable off-mode (for testing only, not for merge) Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 10 - arch/arm/mach-omap2/omap-wakeupgen.c | 47 +++- arch/arm/mach-omap2/pm-debug.c| 17 +-- arch/arm/mach-omap2/pm.h | 20 + arch/arm/mach-omap2/pm44xx.c | 45 +++ arch/arm/mach-omap2/prm44xx.c | 66 + 6 files changed, 197 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c index e02c082..7418e7c 100644 --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c @@ -60,6 +60,7 @@ #include prcm44xx.h #include prm44xx.h #include prm-regbits-44xx.h +#include cm44xx.h #ifdef CONFIG_SMP @@ -263,9 +264,13 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state) * In MPUSS OSWR or device OFF, interrupt controller contest is lost.
Re: [PATCHv2 09/19] ARM: OMAP4: PM: add errata support
On Tue, 2012-05-29 at 15:10 -0500, Menon, Nishanth wrote:
On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote:
Added similar PM errata flag support as omap3 has. A few errata flags
will be added in subsequent patches.
Considering that we might have erratas for future SoCs as well,
should'nt we just
set up a common errata flag for all SoCs and since we have i123 numbers, would
it help being able to reuse errata flags cross SoC generations (if we need
to)?
Not sure... how quickly do we run out of bits that way? :) Also, at
least pm34xx / pm44xx erratas don't have anything in common. We can
probably re-use pm44xx erratas for omap5 though.
One annoyance is that, the OMAP4 erratas are going to have a number of
ROM code erratas on them, which don't really have any public i123
numbers available. .
-Tero
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h |7 +++
arch/arm/mach-omap2/pm44xx.c |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ce1e27f..e53ee3c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -130,6 +130,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
+#else
+#define IS_PM44XX_ERRATUM(id) 0
+#endif
+
#ifdef CONFIG_OMAP_SMARTREFLEX
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8f0ec56..8238097 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -35,6 +35,7 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.7.4.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 14/19] ARM: OMAP4: wakeupgen: enable clocks for save_secure_all
On Tue, 2012-05-29 at 13:15 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: On Wed, 2012-05-16 at 17:06 -0700, Kevin Hilman wrote: +Benoit Tero Kristo t-kri...@ti.com writes: save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled, otherwise the secure ROM code will crash. Signed-off-by: Tero Kristo t-kri...@ti.com I think I mentioned this already (I'm already lost in what I've said for thisseries), but I don't think the secure RAM stuff belongs in the wakeupgen driver. As mentioned, save_secure_all saves: - secure RAM - GIC registers - some other mysterious stuff Attempting to do separate saves for secure RAM + GIC hang the device during wakeup, in addition to being really inefficient (secure API calls are expensive.) I guess my comment wasn't that this isn't needed, but that it doesn't seem to belong in the wakeupgen base (which should probably converted into a real driver.) Seems better to have this stuff in the secure code, maybe omap-secure.c? That might be an option yes. I'll see if I can move these calls over there. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remoteproc: maintain a generic child device for each rproc
On 5/26/2012 12:36 AM, Ohad Ben-Cohen wrote:
For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).
With this in hand, the resulting device hierarchy might then look like:
omap-rproc.0
|
- remoteproc.0
It looks like remoteproc0, remoteproc1, etc. is what's used.
|
- virtio0
|
- virtio1
|
- rpmsg0
|
- rpmsg1
|
- rpmsg2
Where:
- omap-rproc.0 is the low level device that's bound to the
driver which invokes rproc_register()
- remoteproc.0 is the result of this patch, and will be added by the
remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
when it realizes that they are supported by the firmware
of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
channels, and are registerd by the rpmsg bus when it gets notified
about their existence
Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new remoteproc class, to which this new generic remoteproc.x
device belong to.
- adds a super simple enumeration method for the indices of the
remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
instead of the low level platform-specific device
One complaint I've gotten is that the error messages are essentially
useless now. I believe there are some ongoing discussions on lkml to fix
this by traversing the device hierarchy to find the real device but
the hard part is finding the real device.
- updates all dma_* allocations to use the parent of remoteproc.x (where
the platform-specific memory pools, most commonly CMA, are to be found)
Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
new remoteproc class
- all remoteproc log messages will now carry a common name prefix
instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
refcounting (see subsequent patch)
Thanks to Stephen Boyd sb...@codeaurora.org for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo fernando.l...@ti.com for trying them out
with the (upcoming) runtime PM support for remoteproc.
[snip]
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 464ea4f..9e3d4cf 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -66,6 +66,9 @@ typedef int (*rproc_handle_resources_t)(struct rproc *rproc,
struct resource_table *table, int len);
typedef int (*rproc_handle_resource_t)(struct rproc *rproc, void *, int
avail);
+/* Unique numbering for remoteproc devices */
+static unsigned int dev_index;
+
Hm... perhaps use that ida stuff instead of a raw integer?
+static struct class rproc_class = {
+ .name = remoteproc,
+ .owner = THIS_MODULE,
+ .dev_release= rproc_class_release,
+};
I'm not clear on busses versus classes. I recall seeing a thread where
someone said classes were on the way out and shouldn't be used but I
can't find it anymore. Should we use classes for devices that will never
have a matching driver?
+
/**
* rproc_alloc() - allocate a remote processor handle
* @dev: the underlying device
@@ -1492,12 +1516,19 @@ struct rproc *rproc_alloc(struct device *dev, const
char *name,
return NULL;
}
- rproc-dev = dev;
rproc-name = name;
rproc-ops = ops;
rproc-firmware = firmware;
rproc-priv = rproc[1];
+ device_initialize(rproc-dev);
+ rproc-dev.parent = dev;
+ rproc-dev.class = rproc_class;
+
+ /* Assign a unique device index and name */
+ rproc-index = dev_index++;
+ dev_set_name(rproc-dev, remoteproc%d, rproc-index);
+
This doesn't look thread safe. ida would fix this (ida_simple_get/remove
looks like what you want).
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index f1ffabb..0b835d3 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -383,6 +383,7 @@ enum rproc_state {
* @bootaddr: address of first instruction to boot rproc with (optional)
* @rvdevs: list of remote virtio devices
* @notifyids: idr for dynamically assigning rproc-wide unique notify ids
+ * @index: index of this rproc device
*/
struct rproc {
struct klist_node node;
@@ -391,7 +392,7 @@ struct rproc {
const char *firmware;
void *priv;
const struct rproc_ops *ops;
- struct device *dev;
+ struct device dev;
I'm not sure if the
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ ti,hwmods = ctrl_module_core;
+ bandgap {
+ compatible = ti,omap4460-bandgap;
+ interrupts =0 126 4; /* talert */
+ ti,tshut-gpio =86; /* tshut */
+ };
I believe that CPU-specific bandgap definition should be moved to bard specific
dts.
Mmm, why, since it is CPU specific and not board specific. I has to be
in the SoC file.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] remoteproc: remove the now-redundant kref
On 5/26/2012 12:36 AM, Ohad Ben-Cohen wrote:
/* will be called when an rproc is added to the rprocs klist */
static void klist_rproc_get(struct klist_node *n)
{
struct rproc *rproc = container_of(n, struct rproc, node);
- kref_get(rproc-refcount);
+ get_device(rproc-dev);
}
/* will be called when an rproc is removed from the rprocs klist */
@@ -1312,7 +1282,7 @@ static void klist_rproc_put(struct klist_node *n)
{
struct rproc *rproc = container_of(n, struct rproc, node);
- kref_put(rproc-refcount, rproc_release);
+ put_device(rproc-dev);
}
static struct rproc *next_rproc(struct klist_iter *i)
@@ -1354,7 +1324,7 @@ struct rproc *rproc_get_by_name(const char *name)
klist_iter_init(rprocs, i);
while ((rproc = next_rproc(i)) != NULL)
if (!strcmp(rproc-name, name)) {
- kref_get(rproc-refcount);
+ get_device(rproc-dev);
break;
}
klist_iter_exit(i);
@@ -1367,7 +1337,7 @@ struct rproc *rproc_get_by_name(const char *name)
ret = rproc_boot(rproc);
if (ret 0) {
- kref_put(rproc-refcount, rproc_release);
+ put_device(rproc-dev);
return NULL;
}
I was hoping we could use class_for_each_device() and
class_find_device() to replace all this code. Then we wouldn't need all
this klist stuff that the class is taking care of already.
@@ -1462,10 +1432,23 @@ int rproc_register(struct rproc *rproc)
}
EXPORT_SYMBOL(rproc_register);
+/**
+ * rproc_class_release() - release a remote processor instance
+ * @dev: the rproc's device
+ *
+ * This function should _never_ be called directly.
+ *
+ * It will be called by the driver core when no one holds a valid pointer
+ * to @dev anymore.
+ */
Why is this added now and not in the previous patch?
static void rproc_class_release(struct device *dev)
{
struct rproc *rproc = container_of(dev, struct rproc, dev);
+ dev_info(rproc-dev, releasing %s\n, rproc-name);
+
+ rproc_delete_debug_dir(rproc);
+
idr_remove_all(rproc-notifyids);
idr_destroy(rproc-notifyids);
[snip]
@@ -1603,8 +1584,8 @@ int rproc_unregister(struct rproc *rproc)
device_del(rproc-dev);
- /* the rproc will only be released after its refcount drops to zero */
- kref_put(rproc-refcount, rproc_release);
+ /* unroll rproc_alloc. TODO: we may want to let the users do that */
+ put_device(rproc-dev);
Yes I think we want rproc_free() to actually call put_device() the last
time and free the resources.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe 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 14/19] ARM: OMAP4: wakeupgen: enable clocks for save_secure_all
On Tue, 2012-05-29 at 15:48 -0500, Menon, Nishanth wrote: On Tue, May 29, 2012 at 3:15 PM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: On Wed, 2012-05-16 at 17:06 -0700, Kevin Hilman wrote: +Benoit Tero Kristo t-kri...@ti.com writes: save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled, otherwise the secure ROM code will crash. Signed-off-by: Tero Kristo t-kri...@ti.com I think I mentioned this already (I'm already lost in what I've said for thisseries), but I don't think the secure RAM stuff belongs in the wakeupgen driver. As mentioned, save_secure_all saves: - secure RAM - GIC registers - some other mysterious stuff Attempting to do separate saves for secure RAM + GIC hang the device during wakeup, in addition to being really inefficient (secure API calls are expensive.) I guess my comment wasn't that this isn't needed, but that it doesn't seem to belong in the wakeupgen base (which should probably converted into a real driver.) Seems better to have this stuff in the secure code, maybe omap-secure.c? Perhaps OFF mode notifier might help best here. In addition - it might be safer to protect all calls with clkdm_wakeup around secure_dispatcher instead of just the save_secure_all.. ROM code is not smart enough around it. an completely safe version used by security driver can be found here: http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=security/smc/tf_comm_mshield.c;h=b5279fef0fa400438a57b3941af13d965e983bf0;hb=p-android-omap-3.0#l253 Thats true... the secure driver in mainline kernel is rather a stub. Previous version of this patch actually had clkdm_wakeup around every call to dispatcher, I just optimized it away. I can add it back in the next version if you think that is better. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP4: VC: fix I2C timing
On Tue, 2012-05-29 at 14:30 -0700, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: Current I2C timing parameters do not work with Panda board at least. Parameters updated based on TI recommendation. Signed-off-by: Tero Kristo t-kri...@ti.com Let's fix this correctly by deriving/calculating them from the proper source clocks. Hmm, I'll double check if these can actually be calculated or not. -Tero Otherwise, this is going to work for Panda and break for something else. Kevin --- arch/arm/mach-omap2/vc.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c index 1fd976e..a731400 100644 --- a/arch/arm/mach-omap2/vc.c +++ b/arch/arm/mach-omap2/vc.c @@ -585,7 +585,9 @@ static void __init omap4_vc_init_channel(struct voltagedomain *voltdm) omap4_set_timings(voltdm, true); /* XXX These are magic numbers and do not belong! */ - vc_val = (0x60 OMAP4430_SCLL_SHIFT | 0x26 OMAP4430_SCLH_SHIFT); + vc_val = (0x28 OMAP4430_SCLL_SHIFT | 0x2c OMAP4430_SCLH_SHIFT); + vc_val |= (0x0b OMAP4430_HSSCLL_SHIFT); + vc_val |= (0x0 OMAP4430_HSSCLH_SHIFT); voltdm-write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET); } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
latest kernel for am35xx
Hi! I need to use the latest kernel at a am3517 based board where Craneboard schematic was used as a reference. In addition to Cranboard scheme I have wl1271 chip added and therefore I need a kernel - one of the latests to support wireless feature. The job I did: 1) used kernel from Craneboard (Mistral repository) - 2.6.32, no wl1271 support 2) OMAPPSP_04.02.00.07 - 2.6.37, tps65910 driver is broken 3) AM335x PSP 04.06.00.07 - does not compile for am3517evm Can anybody suggest some alive kernel tree where tps65910 and wl1271 chips are supported? Having am3517evm or am3517crane board files would be a great help! Thanks in advance! Max -- To unsubscribe from this list: send the line unsubscribe 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 11/11] ARM: DT: Add support to system control module for OMAP4
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+compatible = ti,omap4-control;
+ti,hwmods = ctrl_module_core;
+bandgap {
+compatible = ti,omap4460-bandgap;
+interrupts =0 126 4; /* talert */
+ti,tshut-gpio =86; /* tshut */
+};
I believe that CPU-specific bandgap definition should be moved to bard
specific dts.
Mmm, why, since it is CPU specific and not board specific. I has to be in the
SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if
omap4430 bandgap support will be added to omap-bandgap driver the version of
bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards,
that is why I'm suggesting to move bandgap description to probably board
specific file.
Another solution is to determine bandgap type in driver probe function, but in
that case ti,omap4460-bandgap in omap4.dtsi should be replaced to
ti,omap4-bandgap.
BR,
Konstantin Baydarov.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] watchdog: omap_wdt: add device tree support
If there is no difference between the OMAP3 and the OMAP4 WDT IP, just add one entry ti,omap3-wdt. And then in the OMAP4 DTS you will just put : compatible = ti,omap3-wdt; or compatible = ti,omap4-wdt, ti,omap3-wdt; I'm still a little bit confused about the real need for the ti,omap4-wdt: entry, but it seems to be the way to do it in PPC. I believe OMAP2, OMAP3 and OMAP4 share the same IP, so how about use ti, omap2-wdt? and other dts files put compatible like ti,omap4-wdt, ti,omap2-wdt and ti,omap4-wdt, ti,omap2-wdt. Typo, should be ti,omap3-wdt, ti,omap2-wdt and ti,omap4-wdt, ti,omap2-wdt. Regards, Xiao -- To unsubscribe from this list: send the line unsubscribe 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 11/11] ARM: DT: Add support to system control module for OMAP4
Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c BR, Konstantin Baydarov. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/30/2012 12:17 PM, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): No, we cannot, we are in the process of getting rid of that. A driver should only focus on the IP version in theory. The CPU version is not the proper way of getting that. It will make the driver not scalable at all for future OMAP revision. drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c Yeah, these are the ones that still need to be fixed... Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ftrace Timer on OMAP3
Am 28.05.2012 10:24, schrieb Ming Lei: On Mon, May 28, 2012 at 2:56 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, May 25, 2012 at 20:49:07, Thomas Klute wrote: Hi everyone, we're having some trouble getting useful results from Ftrace on OMAP3 (Gumstix Overo). As you can see in the example output below, function duration can't be displayed with a precision higher than about 30.5 us, which matches the frequency of the 32 kHz platform timer. For OMAP1, using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide better results [1], but I couldn't find anything similar for OMAP3. Just setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss anything, or isn't there any more precise timer? I believe you are using mainline kernel here, if yes, you should be enabling the dmtimer using commandline argument, clocksource=gp_timer. Also you need to pass 'nohlt' to kernel since gp_timer can't be kept when cpu is idled in deep state. I use the linux-omap tree, but adding clocksource=gp_timer nohlt to the kernel command line did the trick anyways. :-) Thanks to both of you! Thomas -- To unsubscribe from this list: send the line unsubscribe 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 11/11] ARM: DT: Add support to system control module for OMAP4
Hello, On Wed, May 30, 2012 at 12:22:49PM +0200, Cousson Benoit wrote: On 5/30/2012 12:17 PM, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 I have the weird deja vu feeling... The DT entry I sent, I already knew it would cause troubles :-) Having it per board it would be really a PITA. Image that every body doing a 4430 board needs to define a BG entry... That would work, but still do we want this? Benoit, I guess you should know my option by now. Ideally we should rely on revision register to decide what to do in the driver. And as we discussed, looks like for BG this is somewhat non-existing. If we go with the SCM revision register, what do we do if the BG goes away from SCM? If we go with ti,omap4-bandgap, we still need a way to say if it is 4430, 4460 or 4470. There are configuration / settings specific for each. Not only on bandgap, but also wrt to sensor location and hotspot extrapolation rules. Because we lack a revision register for bandgap, one way to go is to have still the revisioning on the same way: ti,omap-bandgap, but having a omap.dtsi per omap revision. But do we want to this only due to bandgap? BTW, is it only BG which is suffering of this issue? Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): No please! Let's not use that stuff... No, we cannot, we are in the process of getting rid of that. A driver should only focus on the IP version in theory. The CPU version is not the proper way of getting that. It will make the driver not scalable at all for future OMAP revision. drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c Yeah, these are the ones that still need to be fixed... agreed with Benoit here. 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
[RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
Since this ocp2scp module does not have any fck but does have a
single opt_clock, it is added as the main_clk for ocp2scp.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..249ff76 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2508,6 +2508,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
.name = ocp2scp_usb_phy,
.class = omap44xx_ocp2scp_hwmod_class,
.clkdm_name = l3_init_clkdm,
+ .main_clk = ocp2scp_usb_phy_phy_48m,
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/5] omap: add ocp2scp as a misc driver
This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp to which phy drivers are connected. I'm planning to send phy drivers asap. Meanwhile I'd like to get some review comments for this series. I have also plans to send device tree adaptation of the ocp2scp driver. Developed on http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next If it has to be based on some other tree, please let me know. Kishon Vijay Abraham I (5): arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp arm: omap: remove ocp2scp_usb_phy_ick clock node drivers: misc: omap: add a new driver for ocp2scp ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy arm: omap: ocp2scp: create omap device for ocp2scp arch/arm/mach-omap2/clock44xx_data.c | 11 --- arch/arm/mach-omap2/devices.c | 72 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 + drivers/misc/Kconfig |8 ++ drivers/misc/Makefile |1 + drivers/misc/omap-ocp2scp.c| 135 include/linux/platform_data/omap_ocp2scp.h | 31 +++ 7 files changed, 269 insertions(+), 11 deletions(-) create mode 100644 drivers/misc/omap-ocp2scp.c create mode 100644 include/linux/platform_data/omap_ocp2scp.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/5] arm: omap: ocp2scp: create omap device for ocp2scp
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 72 +
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index ae62ece..d87cf40 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -18,6 +18,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/platform_data/omap4-keypad.h
+#include linux/platform_data/omap_ocp2scp.h
#include mach/hardware.h
#include mach/irqs.h
@@ -659,6 +660,76 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
+#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
+static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
+{
+ int cnt = 0;
+
+ while (ocp2scp_dev-drv_name != NULL) {
+ cnt++;
+ ocp2scp_dev++;
+ }
+
+ return cnt;
+}
+
+static void omap_init_ocp2scp(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ int bus_id = -1, dev_cnt = 0, i;
+ struct omap_ocp2scp_dev *ocp2scp_dev;
+ const char *oh_name, *name;
+ struct omap_ocp2scp_platform_data *pdata;
+
+ oh_name = ocp2scp_usb_phy;
+ name= omap-ocp2scp;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(%s: could not find omap_hwmod for %s\n, __func__,
+ oh_name);
+ return;
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err(%s: No memory for ocp2scp pdata\n, __func__);
+ return;
+ }
+
+ ocp2scp_dev = oh-dev_attr;
+ dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+ if (!dev_cnt) {
+ pr_err(%s: No devices connected to ocp2scp\n, __func__);
+ return;
+ }
+
+ pdata-devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+ * dev_cnt, GFP_KERNEL);
+ if (!pdata-devices) {
+ pr_err(%s: No memory for ocp2scp pdata devices\n, __func__);
+ return;
+ }
+
+ for (i = 0; i dev_cnt; i++, ocp2scp_dev++)
+ pdata-devices[i] = ocp2scp_dev;
+
+ pdata-dev_cnt = dev_cnt;
+
+ pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata), NULL,
+ 0, false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build omap_device for %s %s\n,
+ name, oh_name);
+ return;
+ }
+}
+#else
+static inline void omap_init_ocp2scp(void) { }
+#endif
+
/*-*/
#if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
@@ -745,6 +816,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_ocp2scp();
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/5] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 249ff76..b5a91e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -19,6 +19,7 @@
*/
#include linux/io.h
+#include linux/platform_data/omap_ocp2scp.h
#include plat/omap_hwmod.h
#include plat/cpu.h
@@ -2499,6 +2500,25 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
.name = ocp2scp,
};
+/* ocp2scp dev_attr */
+static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
+ {
+ .name = usb_phy,
+ .start = 0x4a0ad080,
+ .end= 0x4a0ae000,
+ .flags = IORESOURCE_MEM,
+ },
+ { }
+};
+
+static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
+ {
+ .drv_name = omap-usb2,
+ .res= omap44xx_usb_phy_and_pll_addrs,
+ },
+ { }
+};
+
/* ocp2scp_usb_phy */
static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
{ .role = phy_48m, .clk = ocp2scp_usb_phy_phy_48m },
@@ -2516,6 +2536,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
.modulemode = MODULEMODE_HWCTRL,
},
},
+ .dev_attr = ocp2scp_dev_attr,
.opt_clks = ocp2scp_usb_phy_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/5] drivers: misc: omap: add a new driver for ocp2scp
Adds a new driver _ocp2scp_. This driver takes the responsibility of creating
all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
is connected to ocp2scp.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile |1 +
drivers/misc/omap-ocp2scp.c| 135
include/linux/platform_data/omap_ocp2scp.h | 31 +++
4 files changed, 175 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/omap-ocp2scp.c
create mode 100644 include/linux/platform_data/omap_ocp2scp.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2661f6e..c70aa15 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -508,6 +508,14 @@ config USB_SWITCH_FSA9480
stereo and mono audio, video, microphone and UART data to use
a common connector port.
+config OMAP_OCP2SCP
+ tristate OMAP OCP2SCP DRIVER
+ help
+ Driver to enable ocp2scp module which transforms ocp interface
+ protocol to scp protocol. In OMAP4, USB PHY is connected via
+ OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
+ OCP2SCP.
+
source drivers/misc/c2port/Kconfig
source drivers/misc/eeprom/Kconfig
source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 456972f..4d7c8ce 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -50,4 +50,5 @@ obj-y += lis3lv02d/
obj-y += carma/
obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
+obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
obj-$(CONFIG_INTEL_MEI)+= mei/
diff --git a/drivers/misc/omap-ocp2scp.c b/drivers/misc/omap-ocp2scp.c
new file mode 100644
index 000..c53b9f4
--- /dev/null
+++ b/drivers/misc/omap-ocp2scp.c
@@ -0,0 +1,135 @@
+/*
+ * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/platform_data/omap_ocp2scp.h
+
+/**
+ * _count_resources - count for the number of resources
+ * @res: struct resource *
+ *
+ * Count and return the number of resources populated for the device that is
+ * connected to ocp2scp.
+ */
+static unsigned _count_resources(struct resource *res)
+{
+ int cnt = 0;
+
+ while (res-start != res-end) {
+ cnt++;
+ res++;
+ }
+
+ return cnt;
+}
+
+static int ocp2scp_remove_devices(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
+static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
+{
+ int ret;
+ unsignedres_cnt, i;
+ struct platform_device *pdev_child;
+ struct omap_ocp2scp_platform_data *pdata;
+ struct omap_ocp2scp_dev *dev;
+
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ dev_err(pdev-dev, OCP2SCP initialized without plat data\n);
+ return -EINVAL;
+ }
+
+ for (i = 0, dev = *pdata-devices; i pdata-dev_cnt; i++, dev++) {
+ res_cnt = _count_resources(dev-res);
+
+ pdev_child = platform_device_alloc(dev-drv_name, -1);
+ if (!pdev_child) {
+ dev_err(pdev-dev, failed to allocate memory for
ocp2scp child\n);
+ return -ENOMEM;
+ }
+
+ ret = platform_device_add_resources(pdev_child, dev-res,
+ res_cnt);
+ if (ret) {
+ dev_err(pdev-dev, failed to add resources for
ocp2scp child\n);
+ goto err0;
+ }
+
+ pdev_child-dev.parent = pdev-dev;
+
+ ret = platform_device_add(pdev_child);
+ if (ret) {
+ dev_err(pdev-dev, failed to register ocp2scp child
device\n);
+ goto err0;
+ }
+
[RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
ocp2scp_usb_phy_ick clock node was a fake clock node created
to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added
(which can be used to control MODULEMODE) this clock node is removed.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..3e2cccf 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2132,16 +2132,6 @@ static struct clk ocp2scp_usb_phy_phy_48m = {
.recalc = followparent_recalc,
};
-static struct clk ocp2scp_usb_phy_ick = {
- .name = ocp2scp_usb_phy_ick,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = l3_init_clkdm,
- .parent = l4_div_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk ocp_wp_noc_ick = {
.name = ocp_wp_noc_ick,
.ops= clkops_omap2_dflt,
@@ -3277,7 +3267,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, mmc4_fck, mmc4_fck,
CK_443X),
CLK(NULL, mmc5_fck, mmc5_fck,
CK_443X),
CLK(NULL, ocp2scp_usb_phy_phy_48m,
ocp2scp_usb_phy_phy_48m, CK_443X),
- CLK(NULL, ocp2scp_usb_phy_ick, ocp2scp_usb_phy_ick,
CK_443X),
CLK(NULL, ocp_wp_noc_ick, ocp_wp_noc_ick,
CK_443X),
CLK(omap_rng, ick, rng_ick,
CK_443X),
CLK(NULL, sha2md5_fck, sha2md5_fck,
CK_443X),
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remoteproc: maintain a generic child device for each rproc
Hi Stephen,
As always - thanks for your review!
On Wed, May 30, 2012 at 11:36 AM, Stephen Boyd sb...@codeaurora.org wrote:
It looks like remoteproc0, remoteproc1, etc. is what's used.
Thanks, I'll update the commit log.
One complaint I've gotten is that the error messages are essentially
useless now. I believe there are some ongoing discussions on lkml to fix
this by traversing the device hierarchy to find the real device but
the hard part is finding the real device.
You probably refer to the discussions around the input subsystem's pull request.
I was thinking about that too when creating this patch, and it looks
like whatever Greg will come up with on that matter will benefit us
too. So taking that into account, it might make more sense to do stick
with the virtual device rather than use the real one here (we'll end
up having more information in the long run).
+/* Unique numbering for remoteproc devices */
+static unsigned int dev_index;
+
Hm... perhaps use that ida stuff instead of a raw integer?
That one got me thinking.
The immediate instinct is to do want to have a fully dynamic and
recyclable enumeration method, like ida provides.
But if you think of it, a mere integer have a strong advantage here:
the fact that the indices it provides don't recycle so fast is a plus,
because if a device was removed and recreated (or just removed and
another one then shows up), you get different indices. So a quick
glimpse at the logs is enough to tell that a new device was created.
But adding a spin lock to make this thread safe takes the simplicity
charm away. So in that respect, using an ida is much more attractive.
I'm not clear on busses versus classes.
I think that busses is a whole lot more complex beast. Probably the
main indication we want one is when we need to match drivers to
devices.
In this case, I was more wondering between using a class to a device type.
I recall seeing a thread where
someone said classes were on the way out and shouldn't be used but I
can't find it anymore.
I also remembered a similar discussion at a plumbers mini-conf about
2-3 years ago too, so I looked at device_type as an alternative to
class. The former looks somewhat simpler, but I couldn't find any
major advantage for using one over the other, and both seem to be in
use by many subsystems.
Should we use classes for devices that will never
have a matching driver?
It's not strictly required, but in case we want to provide these
devices some common behavior (and in our case we want them all to have
the same release handler, and very soon, the same PM handlers, too),
then a class (or a type) is helpful.
It looks like moving from a class to a type is quite trivial, in case
classes do eventually go away (or an advantage of using the latter
shows up), but I'm not aware of any other viable alternative for us
other than class/type.
+ /* Assign a unique device index and name */
+ rproc-index = dev_index++;
+ dev_set_name(rproc-dev, remoteproc%d, rproc-index);
+
This doesn't look thread safe. ida would fix this (ida_simple_get/remove
looks like what you want).
Yes, that's a good point, and will probably win this integer vs. ida case.
@@ -391,7 +392,7 @@ struct rproc {
const char *firmware;
void *priv;
const struct rproc_ops *ops;
- struct device *dev;
+ struct device dev;
I'm not sure if the kernel-doc for this field is accurate anymore. Is it
an 'underlying device' still?
It's not, thanks for pointing it out!
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 5/30/2012 12:42 PM, Eduardo Valentin wrote: Hello, On Wed, May 30, 2012 at 12:22:49PM +0200, Cousson Benoit wrote: On 5/30/2012 12:17 PM, Konstantin Baydarov wrote: Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 I have the weird deja vu feeling... I know :-) The DT entry I sent, I already knew it would cause troubles :-) Having it per board it would be really a PITA. Image that every body doing a 4430 board needs to define a BG entry... That would work, but still do we want this? No, in fact I do not want to do that if we can avoid it. Benoit, I guess you should know my option by now. Ideally we should rely on revision register to decide what to do in the driver. And as we discussed, looks like for BG this is somewhat non-existing. Oops, sorry I was thinking about the SCM revision :-( The register seems to be there with the layout detailed before. I just do not have a clue about the value we should expect. That's why we have to read it on both 4430 and 4460 to check if some bits are different. If we go with the SCM revision register, what do we do if the BG goes away from SCM? Yeah, good point. But, if at some point the BG becomes a real IP with an OCP port, then we will have a TI wrapper on top of it with the proper revision register... at least in theory :-) If we go with ti,omap4-bandgap, we still need a way to say if it is 4430, 4460 or 4470. Yeah, so we should check if at least that SCM revision field is meaningful. There are configuration / settings specific for each. Not only on bandgap, but also wrt to sensor location and hotspot extrapolation rules. Assuming the SCM version is usable we can extract from that some SW revision for each sub IP. But it is still not clear how the children will be aware of the parent revision :-( Exported a get_scm_revision is doable potentially. Because we lack a revision register for bandgap, one way to go is to have still the revisioning on the same way: ti,omap-bandgap, but having a omap.dtsi per omap revision. But do we want to this only due to bandgap? BTW, is it only BG which is suffering of this issue? Mmm, probably not, that being said, SCM is probably the worst IP we have on OMAP :-) Regards, Benoit Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): No please! Let's not use that stuff... No, we cannot, we are in the process of getting rid of that. A driver should only focus on the IP version in theory. The CPU version is not the proper way of getting that. It will make the driver not scalable at all for future OMAP revision. drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c Yeah, these are the ones that still need to be fixed... agreed with Benoit here. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] remoteproc: remove the now-redundant kref
On Wed, May 30, 2012 at 11:42 AM, Stephen Boyd sb...@codeaurora.org wrote: I was hoping we could use class_for_each_device() and class_find_device() to replace all this code. Then we wouldn't need all this klist stuff that the class is taking care of already. Awesome! This really is worth a shot. +/** + * rproc_class_release() - release a remote processor instance + * @dev: the rproc's device + * + * This function should _never_ be called directly. + * + * It will be called by the driver core when no one holds a valid pointer + * to @dev anymore. + */ Why is this added now and not in the previous patch? Hmm, probably because it was copied from rproc_release, which was killed in this patch. I can probably shift it to the first patch since I'm anyway doing some changes. - /* the rproc will only be released after its refcount drops to zero */ - kref_put(rproc-refcount, rproc_release); + /* unroll rproc_alloc. TODO: we may want to let the users do that */ + put_device(rproc-dev); Yes I think we want rproc_free() to actually call put_device() the last time and free the resources. Yeah that was one of the options I considered. In general, we have three options here: 1. Remove this last put_device invocation, and require users to call rproc_free() even after they call rproc_unregister(). 2. Let rproc_unregister() still do this, by calling rproc_free(). 3. Let rproc_unregister() still do this, by invoking put_device(). I think that (1) looks better since it makes the interface symmetric and straight forward. (2) and (3) may be simper because users only need to call rproc_unregister and that's it. I eventually decided against (1) because I was concerned it will only confuse users at this point. But if you think that (1) is nicer too then maybe we should go ahead and do that change. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/3] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 -
2 files changed, 0 insertions(+), 143 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index b2c9253..9a9e960 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include plat/usb.h
#include mach/control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
- if (IS_ERR(phyclk)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
- if (IS_ERR(clk48m)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, usb_phy_cm_clk32k);
- if (IS_ERR(clk32k)) {
- dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
- iounmap(ctrl_base);
- if (phyclk)
- clk_put(phyclk);
- if
[RFC PATCH 1/3] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/Kconfig | 17 ++-
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c | 232 +
include/linux/usb/omap_usb.h | 47
include/linux/usb/phy_companion.h | 34 ++
5 files changed, 327 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index e2840f1..3264c0d 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -73,10 +73,8 @@ config TWL6030_USB
help
Enable this to support the USB OTG transceiver on TWL6030
family chips. This TWL6030 transceiver has the VBUS and ID GND
- and OTG SRP events capabilities. For all other transceiver
functionality
- UTMI PHY is embedded in OMAP4430. The internal PHY configurations APIs
- are hooked to this driver through platform_data structure.
- The definition of internal PHY APIs are in the mach-omap2 layer.
+ and OTG SRP events capabilities. For all other transceiver
+ functionality UTMI PHY is embedded in OMAP4430.
config OMAP4_USB_PHY
tristate Texas Instruments OMAP4+ USB pin control driver
@@ -91,6 +89,17 @@ config OMAP4_USB_PHY
performing the above mentioned configuration, API's are added in
by this children of the control module driver.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ depends on OMAP4_USB_PHY
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 60c8c83..2f02912 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
obj-$(CONFIG_OMAP4_USB_PHY)+= omap4-usb-phy.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..ccd74b6
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,232 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/mfd/omap_control.h
+#include linux/usb/omap4_usb_phy.h
+
+/**
+ * omap_usb2_set_comparator - links the comparator present in the sytem with
+ * this phy
+ * @comparator - the companion phy(comparator) for this phy
+ *
+ * The phy companion driver should call this API passing the phy_companion
+ * filled with set_vbus and start_srp to be used by usb phy.
+ *
+ * For use by phy companion driver
+ */
+void omap_usb2_set_comparator(struct phy_companion *comparator)
+{
+ struct usb_phy *x = usb_get_phy(USB_PHY_TYPE_USB2);
+ struct omap_usb *phy = phy_to_omapusb(x);
+
+ phy-comparator = comparator;
+}
+EXPORT_SYMBOL_GPL(omap_usb2_set_comparator);
+
+static int omap_usb_set_vbus(struct usb_otg *otg, bool enabled)
+{
+
[RFC PATCH 0/3] usb: musb: add new phy driver
This series adds a new usb2 phy driver. The device for which is created by the ocp2scp driver. This also uses control module driver. This series converts twl6030 as a comparator driver (previously it was also the phy driver) and makes use of omap-usb2 as the phy driver. Instead of notification mechanism by power chip to omap glue to pass detection of any events, an export API has been added in omap glue. Both twl4030 and twl6030 will call to this API to pass any event. (twl6030 is used in omap4 and twl4030 is used in omap3). This series depends on: *[RFC PATCH 00/11] OMAP System Control Module* patch series However System Control Module driver has only dt support, so wouldn't be able to test this patch series. However I'll adapt omap usb2 phy driver and musb driver for dt and send it asap to the list. This series also depends on: *[PATCH v3 0/3] usb: multi-phy support* patch series *[RFC PATCH 0/5] omap: add ocp2scp as a misc driver* patch series Compile tested only. Kishon Vijay Abraham I (3): drivers: usb: otg: add a new driver for omap usb2 phy usb: musb: omap glue: use omap-usb2 as the phy driver arm: omap: phy: remove unused functions from omap-phy-internal.c arch/arm/mach-omap2/omap_phy_internal.c | 138 -- arch/arm/mach-omap2/twl-common.c|5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/musb_core.h|1 - drivers/usb/musb/omap2430.c | 150 ++-- drivers/usb/otg/Kconfig | 17 ++- drivers/usb/otg/Makefile|1 + drivers/usb/otg/omap-usb2.c | 232 +++ drivers/usb/otg/twl4030-usb.c | 40 ++ drivers/usb/otg/twl6030-usb.c | 172 +-- include/linux/usb/musb-omap.h | 31 include/linux/usb/omap_usb.h| 47 ++ include/linux/usb/phy_companion.h | 34 + 13 files changed, 514 insertions(+), 357 deletions(-) create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/musb-omap.h create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm/dts: add wdt node for omap3 and omap4
On 05/29/2012 10:19 PM, Xiao Jiang wrote:
Jon Hunter wrote:
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
From: Xiao Jiang jgq...@gmail.com
Add wdt node to support dt.
Signed-off-by: Xiao Jiang jgq...@gmail.com
---
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..039df5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,10 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+wdt: wdt@48314000{
Minor comment, may be call this wdt2 as this is watchdog timer 2. Also
ass a space between the address and the {.
Ok, will change it to wdt2: wdt@48314000 {.
+compatible = ti,omap3-wdt;
+ti,hwmods = wd_timer2;
+};
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d01403d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,10 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+wdt: wdt@4a314000{
Same as above.
Ditto.
+compatible = ti,omap4-wdt;
+ti,hwmods = wd_timer2;
+};
};
};
Also we should add some documentation to describe the binding. Here it
is very simple, but nonetheless we should have something as we have for
gpio [1].
Thanks for reminding, how about below patch?
diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
new file mode 100644
index 000..4272d06
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
@@ -0,0 +1,15 @@
+TI Watchdog Timer (WDT) Controller for OMAP
+
+Required properties:
+- compatible:
+ - ti,omap2-wdt for OMAP2
+ - ti,omap3-wdt for OMAP3
+ - ti,omap4-wdt for OMAP4
+- ti,hwmods: Name of the hwmod associated to the WDT
+
+Examples:
+
+wdt2: wdt@73f98000 {
+ compatible = ti,omap4-wdt;
+ ti,hwmods = wd_timer2;
+};
Yes looks good. Thanks! Minor nit-pick in the example I would just copy
the omap4 node completely with the actual omap4 address :-)
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: [PATCHv2 09/19] ARM: OMAP4: PM: add errata support
On Wed, May 30, 2012 at 3:32 AM, Tero Kristo t-kri...@ti.com wrote: On Tue, 2012-05-29 at 15:10 -0500, Menon, Nishanth wrote: On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote: Added similar PM errata flag support as omap3 has. A few errata flags will be added in subsequent patches. Considering that we might have erratas for future SoCs as well, should'nt we just set up a common errata flag for all SoCs and since we have i123 numbers, would it help being able to reuse errata flags cross SoC generations (if we need to)? Not sure... how quickly do we run out of bits that way? :) Also, at least pm34xx / pm44xx erratas don't have anything in common. We can probably re-use pm44xx erratas for omap5 though. One annoyance is that, the OMAP4 erratas are going to have a number of ROM code erratas on them, which don't really have any public i123 numbers available. . Sounds good to me. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp
On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
Since this ocp2scp module does not have any fck but does have a
single opt_clock, it is added as the main_clk for ocp2scp.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..249ff76 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2508,6 +2508,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod
= {
.name = ocp2scp_usb_phy,
.class = omap44xx_ocp2scp_hwmod_class,
.clkdm_name = l3_init_clkdm,
+ .main_clk = ocp2scp_usb_phy_phy_48m,
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Minor ..
$subject
s/arm: omap: / ARM: OMAP
An maintain this naming consistency since one of
the patch in the series uses capital where as others
not
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham I kis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? 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: [RFC PATCH 3/5] drivers: misc: omap: add a new driver for ocp2scp
On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Adds a new driver _ocp2scp_. This driver takes the responsibility of creating all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY is connected to ocp2scp. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- [...] +++ b/drivers/misc/omap-ocp2scp.c @@ -0,0 +1,135 @@ +/* + * omap-ocp2scp.c - transform ocp interface protocol to scp protocol + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com s/2011/2012 [...] diff --git a/include/linux/platform_data/omap_ocp2scp.h b/include/linux/platform_data/omap_ocp2scp.h new file mode 100644 index 000..dcbbf2a --- /dev/null +++ b/include/linux/platform_data/omap_ocp2scp.h @@ -0,0 +1,31 @@ +/* + * omap_ocp2scp.h -- ocp2scp header file + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com Dito. -- To unsubscribe from this list: send the line unsubscribe 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] watchdog: omap_wdt: add device tree support
Hi Benoit,
On 05/30/2012 02:54 AM, Cousson, Benoit wrote:
On 5/30/2012 5:18 AM, Xiao Jiang wrote:
Jon Hunter wrote:
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
From: Xiao Jiang jgq...@gmail.com
Add device table for omap_wdt to support dt.
Signed-off-by: Xiao Jiang jgq...@gmail.com
---
drivers/watchdog/omap_wdt.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..d98c615 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -430,6 +430,13 @@ static int omap_wdt_resume(struct
platform_device *pdev)
#define omap_wdt_resume NULL
#endif
+static const struct of_device_id omap_wdt_of_match[] = {
+ { .compatible = ti,omap3-wdt, },
+ { .compatible = ti,omap4-wdt, },
If there is no difference between the OMAP3 and the OMAP4 WDT IP, just
add one entry ti,omap3-wdt. And then in the OMAP4 DTS you will just
put : compatible = ti,omap3-wdt; or compatible = ti,omap4-wdt,
ti,omap3-wdt;
Hmmm ... comparing the omap3 and omap4 wdt registers there are some
differences. omap4 seems to have more registers than omap3. May be we
are not using these right now, but from a register perspective the wdt
in omap2, omap3 and omap4 appear to be slightly different. The revision
ID register on omap3 and omap4 have different values too.
I guess from a driver perspective there is no difference, but it seemed
to me that the IP is not completely the same.
I'm still a little bit confused about the real need for the
ti,omap4-wdt: entry, but it seems to be the way to do it in PPC.
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
+
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
.remove = __devexit_p(omap_wdt_remove),
@@ -439,6 +446,7 @@ static struct platform_driver omap_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = omap_wdt,
+ .of_match_table = omap_wdt_of_match,
},
};
I think we need to add some code to the probe function that calls
of_match_device() and ensures we find a match. For example ...
if (of_have_populated_dt())
if (!of_match_device(omap_wdt_of_match, pdev-dev))
return -EINVAL;
Will add it in v2, thanks for suggestion.
No, in fact this is not needed. We need that mainly when several
instances can match the same driver and thus we select the proper one
using the of_match_device. Otherwise, just check is the device_node is
there.
In that case, the driver does not even care about any DT node so there
is no need to add extra code for that. Keep it simple.
Ok. So are you saying get rid of the match table altogether? In other
words, drop this patch?
I agree that it does not really do anything today, but I did not know if
in the future you were planning to pass things like, register addresses,
via DT.
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: [RFC PATCH 1/3] drivers: usb: otg: add a new driver for omap usb2 phy
On Wed, May 30, 2012 at 8:04 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/Kconfig | 17 ++-
drivers/usb/otg/Makefile | 1 +
drivers/usb/otg/omap-usb2.c | 232
+
include/linux/usb/omap_usb.h | 47
include/linux/usb/phy_companion.h | 34 ++
5 files changed, 327 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
[...]
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..ccd74b6
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,232 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
s/2011/2012
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
Do you need it ?
+#include linux/mfd/omap_control.h
+#include linux/usb/omap4_usb_phy.h
+
+/**
+ * omap_usb2_set_comparator - links the comparator present in the sytem with
+ * this phy
+ * @comparator - the companion phy(comparator) for this phy
+ *
+ * The phy companion driver should call this API passing the phy_companion
+ * filled with set_vbus and start_srp to be used by usb phy.
+ *
+ * For use by phy companion driver
+ */
+void omap_usb2_set_comparator(struct phy_companion *comparator)
+{
+ struct usb_phy *x = usb_get_phy(USB_PHY_TYPE_USB2);
+ struct omap_usb *phy = phy_to_omapusb(x);
+
+ phy-comparator = comparator;
+}
+EXPORT_SYMBOL_GPL(omap_usb2_set_comparator);
+
+static int omap_usb_set_vbus(struct usb_otg *otg, bool enabled)
+{
+ struct omap_usb *phy = phy_to_omapusb(otg-phy);
+
+ if (!phy-comparator)
+ return -ENODEV;
+
+ return phy-comparator-set_vbus(phy-comparator, enabled);
+}
+
+static int omap_usb_start_srp(struct usb_otg *otg)
+{
+ struct omap_usb *phy = phy_to_omapusb(otg-phy);
+
+ if (!phy-comparator)
+ return -ENODEV;
+
+ return phy-comparator-start_srp(phy-comparator);
+}
+
+static int omap_usb_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+ struct usb_phy *phy = otg-phy;
+
+ otg-host = host;
+ if (!host)
+ phy-state = OTG_STATE_UNDEFINED;
+
+ return 0;
+}
+
+static int omap_usb_set_peripheral(struct usb_otg *otg,
+ struct usb_gadget *gadget)
+{
+ struct usb_phy *phy = otg-phy;
+
+ otg-gadget = gadget;
+ if (!gadget)
+ phy-state = OTG_STATE_UNDEFINED;
+
+ return 0;
+}
+
+static int omap_usb2_suspend(struct usb_phy *x, int suspend)
+{
+ struct omap_usb *phy = phy_to_omapusb(x);
+
+ if (suspend !phy-is_suspended) {
+ pm_runtime_put_sync(phy-dev);
+ phy-is_suspended = 1;
+ } else if (!suspend phy-is_suspended) {
+ pm_runtime_get_sync(phy-dev);
+ phy-is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static int __devinit omap_usb2_probe(struct platform_device *pdev)
+{
+ struct omap_usb *phy;
+ struct usb_otg *otg;
+
+ phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ dev_err(pdev-dev, unable to allocate memory for USB2
PHY\n);
+ return -ENOMEM;
+ }
+
+ otg = devm_kzalloc(pdev-dev, sizeof(*otg), GFP_KERNEL);
+ if (!otg) {
+ dev_err(pdev-dev, unable to allocate memory for USB
Re: [RFC PATCH 3/3] arm: omap: phy: remove unused functions from omap-phy-internal.c
On Wed, May 30, 2012 at 8:04 PM, Kishon Vijay Abraham I kis...@ti.com wrote: All the unnessary functions in omap-phy-internal is removed. These functionality are now handled by omap-usb2 phy driver. Cool. One less item in platform code. -- To unsubscribe from this list: send the line unsubscribe 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 17/19] ARM: OMAP4: put cpu1 back to sleep if no wake request
On Mon, May 21, 2012 at 5:40 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Not sure what you mean wakeup issue on GP device. IIUC, the issue is: Wakeup from device OFF, hardware releases the reset for both CPUs, This is special case and applicable only for device OFF. The reason CPU1 needs to be hold back, because the security SW is affined with CPU0 which needs to be up and running for any of the ROM code APIs to work. Like setting up SMP bit, AUX control etc. Without CPU0 booted, CPU1 won't be able to execute those ROM functions and hence won't be able to boot properly. I think the limitation is applicable to all OMAP4 devices as well as OMAP5 devices. yes, the stagger of CPU1 behind CPU0 has a few factors: HS devices with an older PPA release has a bug where caches can be messed up and GP devices need slightly different WA. with the older PPA, we put CPU1 back to OFF when we detect that CPU0 is not ready for action you can find the details and documentation in the link below: http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/sleep44xx.S;h=0c28def8f644e9803564bb66c8cfe8c580898978;hb=p-android-omap-3.0#l342 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] arm: omap: remove ocp2scp_usb_phy_ick clock node
On 5/30/2012 4:51 PM, Shilimkar, Santosh wrote: On Wed, May 30, 2012 at 4:26 PM, Kishon Vijay Abraham Ikis...@ti.com wrote: ocp2scp_usb_phy_ick clock node was a fake clock node created to control MODULEMODE of ocp2scp. Since the hwmod for ocp2scp is now added (which can be used to control MODULEMODE) this clock node is removed. Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 11 --- Have you patched clock44xx_data.c manually or you have a patch for the clock_data autogen script to generate it ? I have a series that will remove all these clock nodes. I should be able to post that soon. Potentially at that time, Kishon might be able to drop that patch. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] watchdog: omap_wdt: add device tree support
Hi Jon,
On 5/30/2012 5:03 PM, Jon Hunter wrote:
Hi Benoit,
On 05/30/2012 02:54 AM, Cousson, Benoit wrote:
On 5/30/2012 5:18 AM, Xiao Jiang wrote:
Jon Hunter wrote:
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
From: Xiao Jiangjgq...@gmail.com
Add device table for omap_wdt to support dt.
Signed-off-by: Xiao Jiangjgq...@gmail.com
---
drivers/watchdog/omap_wdt.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..d98c615 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -430,6 +430,13 @@ static int omap_wdt_resume(struct
platform_device *pdev)
#define omap_wdt_resume NULL
#endif
+static const struct of_device_id omap_wdt_of_match[] = {
+ { .compatible = ti,omap3-wdt, },
+ { .compatible = ti,omap4-wdt, },
If there is no difference between the OMAP3 and the OMAP4 WDT IP, just
add one entry ti,omap3-wdt. And then in the OMAP4 DTS you will just
put : compatible = ti,omap3-wdt; or compatible = ti,omap4-wdt,
ti,omap3-wdt;
Hmmm ... comparing the omap3 and omap4 wdt registers there are some
differences. omap4 seems to have more registers than omap3. May be we
are not using these right now, but from a register perspective the wdt
in omap2, omap3 and omap4 appear to be slightly different. The revision
ID register on omap3 and omap4 have different values too.
I guess from a driver perspective there is no difference, but it seemed
to me that the IP is not completely the same.
Well, in that case, and assuming that there is no proper HW_REVISION
information to detect the IP difference, the proper compatible entries
will indeed have to be used.
I'm still a little bit confused about the real need for the
ti,omap4-wdt: entry, but it seems to be the way to do it in PPC.
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
+
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
.remove = __devexit_p(omap_wdt_remove),
@@ -439,6 +446,7 @@ static struct platform_driver omap_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = omap_wdt,
+ .of_match_table = omap_wdt_of_match,
},
};
I think we need to add some code to the probe function that calls
of_match_device() and ensures we find a match. For example ...
if (of_have_populated_dt())
if (!of_match_device(omap_wdt_of_match,pdev-dev))
return -EINVAL;
Will add it in v2, thanks for suggestion.
No, in fact this is not needed. We need that mainly when several
instances can match the same driver and thus we select the proper one
using the of_match_device. Otherwise, just check is the device_node is
there.
In that case, the driver does not even care about any DT node so there
is no need to add extra code for that. Keep it simple.
Ok. So are you saying get rid of the match table altogether? In other
words, drop this patch?
No, the match table is used by the LDM to find the proper driver to be
bound to a device. So we do need it. But we do not have to use the
of_match_device if we do not want to get the entry in the device table.
I agree that it does not really do anything today, but I did not know if
in the future you were planning to pass things like, register addresses,
via DT.
Well, yes we will have to, otherwise people will keep complaining that
our DTS sucks and are not compliant with the DTS standards :-)
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] watchdog: omap_wdt: add device tree support
Hi Benoit,
On 05/30/2012 10:30 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/30/2012 5:03 PM, Jon Hunter wrote:
Hi Benoit,
On 05/30/2012 02:54 AM, Cousson, Benoit wrote:
On 5/30/2012 5:18 AM, Xiao Jiang wrote:
Jon Hunter wrote:
On 05/25/2012 05:42 AM, jgq...@gmail.com wrote:
From: Xiao Jiangjgq...@gmail.com
Add device table for omap_wdt to support dt.
Signed-off-by: Xiao Jiangjgq...@gmail.com
---
drivers/watchdog/omap_wdt.c | 8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c
b/drivers/watchdog/omap_wdt.c
index 8285d65..d98c615 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -430,6 +430,13 @@ static int omap_wdt_resume(struct
platform_device *pdev)
#define omap_wdt_resume NULL
#endif
+static const struct of_device_id omap_wdt_of_match[] = {
+ { .compatible = ti,omap3-wdt, },
+ { .compatible = ti,omap4-wdt, },
If there is no difference between the OMAP3 and the OMAP4 WDT IP, just
add one entry ti,omap3-wdt. And then in the OMAP4 DTS you will just
put : compatible = ti,omap3-wdt; or compatible = ti,omap4-wdt,
ti,omap3-wdt;
Hmmm ... comparing the omap3 and omap4 wdt registers there are some
differences. omap4 seems to have more registers than omap3. May be we
are not using these right now, but from a register perspective the wdt
in omap2, omap3 and omap4 appear to be slightly different. The revision
ID register on omap3 and omap4 have different values too.
I guess from a driver perspective there is no difference, but it seemed
to me that the IP is not completely the same.
Well, in that case, and assuming that there is no proper HW_REVISION
information to detect the IP difference, the proper compatible entries
will indeed have to be used.
So looking at a 4460 and 3430, the WIDR register (IP revision) can be
used to distinguish between IP revisions. So it appears that we do have
proper HW REV info.
So may be I am not completely up to speed of the intent of the
compatible field. In other words, should this be used to indicate if the
IP is same/compatible or the driver is compatible or both. Technically
right now we could just have ti-omap2-wdt for all omap2+ devices as
the driver is compatible for all devices. However, technically, the IP
is not completely the same but it is compatible :-)
I'm still a little bit confused about the real need for the
ti,omap4-wdt: entry, but it seems to be the way to do it in PPC.
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
+
static struct platform_driver omap_wdt_driver = {
.probe = omap_wdt_probe,
.remove = __devexit_p(omap_wdt_remove),
@@ -439,6 +446,7 @@ static struct platform_driver omap_wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = omap_wdt,
+ .of_match_table = omap_wdt_of_match,
},
};
I think we need to add some code to the probe function that calls
of_match_device() and ensures we find a match. For example ...
if (of_have_populated_dt())
if (!of_match_device(omap_wdt_of_match,pdev-dev))
return -EINVAL;
Will add it in v2, thanks for suggestion.
No, in fact this is not needed. We need that mainly when several
instances can match the same driver and thus we select the proper one
using the of_match_device. Otherwise, just check is the device_node is
there.
In that case, the driver does not even care about any DT node so there
is no need to add extra code for that. Keep it simple.
Ok. So are you saying get rid of the match table altogether? In other
words, drop this patch?
No, the match table is used by the LDM to find the proper driver to be
bound to a device. So we do need it. But we do not have to use the
of_match_device if we do not want to get the entry in the device table.
Ok, thanks.
I agree that it does not really do anything today, but I did not know if
in the future you were planning to pass things like, register addresses,
via DT.
Well, yes we will have to, otherwise people will keep complaining that
our DTS sucks and are not compliant with the DTS standards :-)
Ok.
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: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Menon, Nishanth n...@ti.com writes: On Thu, May 17, 2012 at 3:52 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: [...] - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. This is again specific to device OFF only and not related to CPU cluster state as such. So I don't think notifiers should be used here. O.w even when we attempt just MPU OSWR C-state, all these functions will get called in notifier chain. Just a thought, we can have a separate notifier chain for device OFF. It can allow use to get rid of 'enable_off_mode kind of flags and can be used by many drivers too. Like the overall idea, but one minor dumb concern might be sequencing of notifiers - OFF entry and restore needs things to be executed in a specific sequence. How do we plan to ensure the sequence is maintained in a notifier call chain? one possible option might be a priority based scheme? Or just combine the events that need a specific sequence into single notifier callback function. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3/4: consolidate cpuidle Makefile
Daniel Lezcano daniel.lezc...@linaro.org writes: On 05/14/2012 06:42 AM, Rajendra Nayak wrote: On Thursday 10 May 2012 03:32 PM, Daniel Lezcano wrote: The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files even if the cpuidle option is not set in the kernel. This patch fixes this by creating a section in the Makefile where these files are compiled only if the CONFIG_CPU_IDLE option is set. This modification breaks an implicit dependency between CPU_IDLE and PM as they belong to the same block in the Makefile. This is fixed in the Kconfig by selecting explicitely PM is CPU_IDLE is set. The linux coding style recommend to use no-op functions in the headers when the subsystem is disabled instead of adding big section in C files. Looks good to me. Reviewed-by: Rajendra Nayak rna...@ti.com Hi Kevin, I think I addressed all the points. Is it possible to consider this patch for inclusion ? Yes. I'll queue up as a cleanup for v3.6 with the reviewed-by from Rajendra. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 30, 2012 at 12:59 PM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Thu, May 17, 2012 at 3:52 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: [...] - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. This is again specific to device OFF only and not related to CPU cluster state as such. So I don't think notifiers should be used here. O.w even when we attempt just MPU OSWR C-state, all these functions will get called in notifier chain. Just a thought, we can have a separate notifier chain for device OFF. It can allow use to get rid of 'enable_off_mode kind of flags and can be used by many drivers too. Like the overall idea, but one minor dumb concern might be sequencing of notifiers - OFF entry and restore needs things to be executed in a specific sequence. How do we plan to ensure the sequence is maintained in a notifier call chain? one possible option might be a priority based scheme? Or just combine the events that need a specific sequence into single notifier callback function. There is other issues in case of failure cases - abort of OFF sequence due to pending interrupt detected as part of a notifier - error handling needs to be sane in proper sequence. I understand and appreciate the intent of replacing the single mega enter_sleep with a chain of notifiers but any such option will need to be scalable enough to handle weird erratum handling (HSI CAWAKE as an example) which potentially break the logic flow and be either be equal or better than what we have today interms of error handling. since these notifiers will be triggered for CPUIDLE(performance sensitive) and suspend, the intricacies might be better understood by seeing how this proposed notifiers look like. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] omap: add ocp2scp as a misc driver
On Wednesday 30 May 2012, Kishon Vijay Abraham I wrote: This patch series is done as a preparatory step for adding phy drivers for dwc3 and musb. This series adds a new driver for ocp2scp to which phy drivers are connected. I'm planning to send phy drivers asap. Meanwhile I'd like to get some review comments for this series. I have also plans to send device tree adaptation of the ocp2scp driver. Developed on http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next If it has to be based on some other tree, please let me know. This must be the most pointless driver I've seen in a long time. It doesn't actually do anything at all, it just creates child devices from a static lookup table. Just put the devices you actually want into the device tree instead and have them automatically created. 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] ARM: OMAP3/4: consolidate cpuidle Makefile
On 05/30/2012 08:07 PM, Kevin Hilman wrote: Daniel Lezcano daniel.lezc...@linaro.org writes: On 05/14/2012 06:42 AM, Rajendra Nayak wrote: On Thursday 10 May 2012 03:32 PM, Daniel Lezcano wrote: The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files even if the cpuidle option is not set in the kernel. This patch fixes this by creating a section in the Makefile where these files are compiled only if the CONFIG_CPU_IDLE option is set. This modification breaks an implicit dependency between CPU_IDLE and PM as they belong to the same block in the Makefile. This is fixed in the Kconfig by selecting explicitely PM is CPU_IDLE is set. The linux coding style recommend to use no-op functions in the headers when the subsystem is disabled instead of adding big section in C files. Looks good to me. Reviewed-by: Rajendra Nayak rna...@ti.com Hi Kevin, I think I addressed all the points. Is it possible to consider this patch for inclusion ? Yes. I'll queue up as a cleanup for v3.6 with the reviewed-by from Rajendra. Cool ! Thanks -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP: mailbox initial device tree support
Hi, On 24 May 2012 10:44, Cousson, Benoit b-cous...@ti.com wrote: On 5/2/2012 7:42 AM, Bedia, Vaibhav wrote: Hi Omar, On Tue, May 01, 2012 at 23:17:38, Omar Ramirez Luna wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. I think the mailbox code needs a cleanup similar to what you had proposed earlier [1] before the device tree support is added. We probably need to decide whether the number of mailbox sub-modules should be part of hwmod attribute or come from device tree. IMO the static allocation of the mailboxes is better suited in the device-tree data. Ideally yes, but that assumes we are supporting only DT boot method, which is still not the case today. That being said, the driver might still be able to leverage DT if available already. This can be done later as well. Omar, That's up to you. Thanks for the ack on the 2nd patch. Yes, I think these changes doesn't depend on the cleanup of the driver, they could be included prior to them. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe 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 19/19] ARM: OMAP4: powerdomain: update mpu / core off counters during device off
On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote:
Currently device off does not have any counters / timers of its own
and it is impossible to track the time spent in this state. In device
off, MPU / CORE powerdomains enter OSWR, so normally the RETENTION
state times / counts are increased during device off.
This patch adds a new field to the powerdomain struct for context loss
register, which is checked during pwrdm_post_transition to see if
a device off type context loss has happened. If this is the case,
the counters + timers for OFF state are touched instead of RETENTION.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 1 -
arch/arm/mach-omap2/powerdomain.c | 9 +
arch/arm/mach-omap2/powerdomain.h | 2 ++
arch/arm/mach-omap2/powerdomains44xx_data.c | 2 ++
arch/arm/mach-omap2/prm44xx.c | 15 +++
arch/arm/mach-omap2/prm44xx.h | 2 ++
6 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 1f06f97..f187025 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -404,7 +404,6 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
omap4_cm_resume_off();
- omap4_device_clear_prev_off_state();
We should probably delete the function in it's entirety - not just the
call - the original implementation just clears L3 and this
implementation seems superior.
}
sar_save_failed:
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..f13bb2c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -156,6 +156,15 @@ static int _pwrdm_state_switch(struct powerdomain
*pwrdm, int flag)
break;
case PWRDM_STATE_PREV:
prev = pwrdm_read_prev_pwrst(pwrdm);
+
+ /*
+ * If powerdomain has context offset defined, check if
+ * the domain has lost context (i.e. entered off)
+ */
+ if (pwrdm-context_offs)
+ if (omap4_pwrdm_lost_context_rff(pwrdm-prcm_offs,
+ pwrdm-context_offs))
We should wrap this under pwrdm_lost_context(pwrdm)
pwrdm_lost_context should call the arch_pwrdm-lost_context_rff as
needed? the rest of the powerdomain.c does not use OMAP4 specific
APIs.
+ prev = PWRDM_POWER_OFF;
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..a427645 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -82,6 +82,7 @@ struct powerdomain;
* @name: Powerdomain name
* @voltdm: voltagedomain containing this powerdomain
* @prcm_offs: the address offset from CM_BASE/PRM_BASE
+ * @context_offs: the address offset for the CONTEXT register
* @prcm_partition: (OMAP4 only) the PRCM partition ID containing @prcm_offs
* @pwrsts: Possible powerdomain power states
* @pwrsts_logic_ret: Possible logic power states when pwrdm in RETENTION
@@ -106,6 +107,7 @@ struct powerdomain {
struct voltagedomain *ptr;
} voltdm;
const s16 prcm_offs;
+ const s16 context_offs;
const u8 pwrsts;
const u8 pwrsts_logic_ret;
const u8 flags;
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index d8701ce..c4de02f 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,6 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs = OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_L3_1_L3_1_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 5,
@@ -205,6 +206,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs = OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 3,
Why are we not populating the rest of the CONTEXT_OFFSET registers?
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
Jon Hunter jon-hun...@ti.com writes:
Hi Kevin,
On 05/29/2012 05:07 PM, Jon Hunter wrote:
Hi Kevin,
On 05/29/2012 04:17 PM, Kevin Hilman wrote:
Jon Hunter jon-hun...@ti.com writes:
From: Jon Hunter jon-hun...@ti.com
This patch is based upon Ming Lei's patch to add runtime PM support for
OMAP4
[1]. In Ming's original patch the CTI interrupts were being enabled during
runtime when the PMU was used but they were only configured once during
init.
Therefore move the configuration of the CTI interrupts to the runtime PM
functions.
Lovely. This is exactly the workaround I was hoping to see. Thanks!
Some comments below...
Thanks! Great timing, I am getting ready to post V2 :-)
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/devices.c | 50
++--
1 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 636533d..b02aa81 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -18,6 +18,7 @@
#include linux/slab.h
#include linux/of.h
#incluhttp://marc.info/?l=linux-arm-kernelm=132227620816504w=2de
linux/platform_data/omap4-keypad.h
+#include linux/pm_runtime.h
#include mach/hardware.h
#include mach/irqs.h
@@ -434,13 +435,22 @@ static struct omap_device_pm_latency
omap_pmu_latency[] = {
};
static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
static void omap4_enable_cti(int irq)
{
- if (irq == OMAP44XX_IRQ_CTI0)
+ pm_runtime_get_sync(pmu_dev-dev);
+ if (irq == OMAP44XX_IRQ_CTI0) {
+ /* configure CTI0 for pmu irq routing */
+ cti_unlock(omap4_cti[0]);
+ cti_map_trigger(omap4_cti[0], 1, 6, 2);
cti_enablook at thisle(omap4_cti[0]);
- else if (irq == OMAP44XX_IRQ_CTI1)
+ } else if (irq == OMAP44XX_IRQ_CTI1) {
+ /* configure CTI1 for pmu irq routing */
+ cti_unlolook at thisck(omap4_cti[1]);
+ cti_map_trigger(omap4_cti[1], 1, 6, 2);
cti_enable(omap4_cti[1]);
+ }
}
The cti_* functions really belong in the -runtime_resume() callback.
In the case of multiple users, I don't think the current implementation
will do what is intended. IOW, you only want to (re)init for the first
user (when runtime PM usecount goes from zero to one.) That is when
the -runtime_resume() is called. For a 2nd user, the
-runtime_resume() callback will not be called, but the cti_* functions
will still be called. I don't think that is what you want.
Ah, yes that would not work. Ok, let me make that change.
Actually, looking at this some more, the above omap4_enable_cti()
function is getting called from armpmu_reserve_hardware() function in
the pmu driver. In armpmu_reserve_hardware(), it calls reserve_pmu() to
see if the PMU is in-use and if not acquires it. So I believe that this
code should be atomic already. May be Will or Ming can confirm. However,
if this is the case, then do you agree we should be ok?
I can see that ideally, we should use -runtime_resume/suspend, but the
arm-pmu does not currently have support for these functions and hence
there is no easy way to specify such platform functions. Obviously it
could be done but would be a bigger change.
Let me know your thoughts.
I'm guessing you probably know my thoughts since you've already thought
through how this should probably look.
Basically, I don't like the result when we have to hack around missing
runtime PM support for a driver, so IMO, the driver should be updated.
IOW, it looks to me like the armpmu driver should grow runtime PM
support. The current armpmu_release|reserve should probably be replaced
with runtime PM get/put, and the functionality in those functions would
be the runtime PM callbacks instead.
Will, any objections to armpmu growing runtime PM support?
Kevin
P.S. Jon, for readability sake, any objections to moving the PMU device init
out of devices.c into pmu.c? devices.c is awful crowded.
--
To unsubscribe from this list: send the line unsubscribe 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 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Menon, Nishanth n...@ti.com writes: On Wed, May 30, 2012 at 12:59 PM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Thu, May 17, 2012 at 3:52 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: [...] - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. This is again specific to device OFF only and not related to CPU cluster state as such. So I don't think notifiers should be used here. O.w even when we attempt just MPU OSWR C-state, all these functions will get called in notifier chain. Just a thought, we can have a separate notifier chain for device OFF. It can allow use to get rid of 'enable_off_mode kind of flags and can be used by many drivers too. Like the overall idea, but one minor dumb concern might be sequencing of notifiers - OFF entry and restore needs things to be executed in a specific sequence. How do we plan to ensure the sequence is maintained in a notifier call chain? one possible option might be a priority based scheme? Or just combine the events that need a specific sequence into single notifier callback function. There is other issues in case of failure cases - abort of OFF sequence due to pending interrupt detected as part of a notifier - error handling needs to be sane in proper sequence. I understand and appreciate the intent of replacing the single mega enter_sleep with a chain of notifiers but any such option will need to be scalable enough to handle weird erratum handling (HSI CAWAKE as an example) which potentially break the logic flow and be either be equal or better than what we have today interms of error handling. since these notifiers will be triggered for CPUIDLE(performance sensitive) and suspend, the intricacies might be better understood by seeing how this proposed notifiers look like. Makes sense. Thanks for clarifying. What $SUBJECT series proposed was indeed a mega function, but one that was just a list of function calls with no error checking or recovery, and no documentation/description about dependencies/sequencing etc. etc. Based on the patches at hadn (which is all reviewers have to go on), notifiers seemed to be a good fit. If there are good reasons that all of the device-off events need to be coordinated/synchronized/sequenced (and it sounds like there are, thanks for pointing them out), I am not opposed to that approach. It simply needs to be well described in the changlog. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3/4: consolidate cpuidle Makefile
Daniel Lezcano daniel.lezc...@linaro.org writes: On 05/30/2012 08:07 PM, Kevin Hilman wrote: Daniel Lezcano daniel.lezc...@linaro.org writes: On 05/14/2012 06:42 AM, Rajendra Nayak wrote: On Thursday 10 May 2012 03:32 PM, Daniel Lezcano wrote: The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files even if the cpuidle option is not set in the kernel. This patch fixes this by creating a section in the Makefile where these files are compiled only if the CONFIG_CPU_IDLE option is set. This modification breaks an implicit dependency between CPU_IDLE and PM as they belong to the same block in the Makefile. This is fixed in the Kconfig by selecting explicitely PM is CPU_IDLE is set. The linux coding style recommend to use no-op functions in the headers when the subsystem is disabled instead of adding big section in C files. Looks good to me. Reviewed-by: Rajendra Nayak rna...@ti.com Hi Kevin, I think I addressed all the points. Is it possible to consider this patch for inclusion ? Yes. I'll queue up as a cleanup for v3.6 with the reviewed-by from Rajendra. Cool ! Sorry for the lag. Since this one patch was a bit late for 3.5, I had it on my to look at later pile while tracking down various regressions introduced in 3.5. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP PM fixes for v3.5-rc
Tony, Here's a couple PM related fixes for v3.5-rc, based on your cleanup branch. Kevin The following changes since commit 2c65e7440d56b3b285d1c95563b4dcce8e40dea3: GPMC: add ECC control definitions (2012-05-10 09:39:47 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/fixes/pm for you to fetch changes up to 1ce029968718477149e7f1fb245a8e82c690cc4a: arm: omap3: am35x: Don't mark missing features as present (2012-05-11 16:47:19 -0700) Kevin Hilman (1): ARM: OMAP3: PM: fix shared PRCM interrupts: leave disabled at boot Mark A. Greer (1): arm: omap3: am35x: Don't mark missing features as present NeilBrown (1): ARM: OMAP2+: INTC: fix suspend abort, set IRQCHIP_SKIP_SET_WAKE arch/arm/mach-omap2/id.c | 11 +++ arch/arm/mach-omap2/irq.c |1 + arch/arm/mach-omap2/pm34xx.c |1 + arch/arm/mach-omap2/prm2xxx_3xxx.c | 14 +++--- 4 files changed, 24 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
+Tomi Hi Xiao, On 05/30/2012 02:14 AM, Xiao Jiang wrote: Hello, After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got some err infos with latest Linus's tree, does somebody also has the same issue? sound/soc/omap/omap-hdmi.c:45:24: error: field 'dss_audio' has incomplete type sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_startup': sound/soc/omap/omap-hdmi.c:67:27: error: 'struct omap_dss_driver' has no member named 'audio_supported' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:79:29: error: 'struct omap_dss_driver' has no member named 'audio_enable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_hw_params': sound/soc/omap/omap-hdmi.c:208:28: error: 'struct omap_dss_driver' has no member named 'audio_config' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_trigger': sound/soc/omap/omap-hdmi.c:224:29: error: 'struct omap_dss_driver' has no member named 'audio_start' sound/soc/omap/omap-hdmi.c:229:23: error: 'struct omap_dss_driver' has no member named 'audio_stop' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_shutdown': sound/soc/omap/omap-hdmi.c:242:22: error: 'struct omap_dss_driver' has no member named 'audio_disable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:80:1: warning: control reaches end of non-void function Build breaks because there some patches [1] that are still missing in Linus' tree. ASoC HDMI audio driver for OMAP[2] now uses the new DSS audio functionality in [1], but ASoC patches were merged first. DSS patches have been accepted and they are part of Tomi's pull request for DSS for K3.5. Hopefully this will be fixed when v3.5-rc1 is out. BR, Ricardo [1].http://www.spinics.net/lists/linux-omap/msg69466.html [2].http://www.spinics.net/lists/linux-omap/msg70561.html Regards, Xiao -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] OMAP: AM3xxx: cpu_is dead code removal
Tony, These couple patches didn't make it for v3.5 because of some cross-tree dependencies. All the dependencies are now merged (after Linus merged arm-soc/next/pm), so here's the remaining patches. Not sure if you want to get them in for 3.5-rc or queue them in your cleanup branch for v3.6. Up to you. Kevin The following changes since commit cdd3a354a05b0c33fe33ab11a0fb0838396cad19: Merge tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-05-22 09:41:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.5/cleanup/am3xxx-cpu-is-leftovers for you to fetch changes up to 96f3994929c05a21d757a83613d2710b780ea2b4: ARM: OMAP: SoC detection: remove unused cpu_is macros (2012-05-25 15:48:48 -0700) Kevin Hilman (2): ARM: OMAP3: clock data: cleanup AM3[35]x SoC detection ARM: OMAP: SoC detection: remove unused cpu_is macros arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/plat-omap/include/plat/cpu.h | 33 - 2 files changed, 1 insertion(+), 34 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP4: PMU: Add runtime PM support
Hi Kevin, On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote: Basically, I don't like the result when we have to hack around missing runtime PM support for a driver, so IMO, the driver should be updated. IOW, it looks to me like the armpmu driver should grow runtime PM support. The current armpmu_release|reserve should probably be replaced with runtime PM get/put, and the functionality in those functions would be the runtime PM callbacks instead. Will, any objections to armpmu growing runtime PM support? My plan for the armpmu reservation is to kill the global reservation scheme that we currently have and push those function pointers into the arm_pmu, so that fits with what you'd like. The only concern I have is that we need the mutual exclusion even when we don't have support for runtime PM. If we can solve that then I'm fine with the approach. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe 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 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Thu, May 31, 2012 at 3:39 AM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Wed, May 30, 2012 at 12:59 PM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Thu, May 17, 2012 at 3:52 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: [...] - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. This is again specific to device OFF only and not related to CPU cluster state as such. So I don't think notifiers should be used here. O.w even when we attempt just MPU OSWR C-state, all these functions will get called in notifier chain. Just a thought, we can have a separate notifier chain for device OFF. It can allow use to get rid of 'enable_off_mode kind of flags and can be used by many drivers too. Like the overall idea, but one minor dumb concern might be sequencing of notifiers - OFF entry and restore needs things to be executed in a specific sequence. How do we plan to ensure the sequence is maintained in a notifier call chain? one possible option might be a priority based scheme? Or just combine the events that need a specific sequence into single notifier callback function. There is other issues in case of failure cases - abort of OFF sequence due to pending interrupt detected as part of a notifier - error handling needs to be sane in proper sequence. I understand and appreciate the intent of replacing the single mega enter_sleep with a chain of notifiers but any such option will need to be scalable enough to handle weird erratum handling (HSI CAWAKE as an example) which potentially break the logic flow and be either be equal or better than what we have today interms of error handling. since these notifiers will be triggered for CPUIDLE(performance sensitive) and suspend, the intricacies might be better understood by seeing how this proposed notifiers look like. Makes sense. Thanks for clarifying. What $SUBJECT series proposed was indeed a mega function, but one that was just a list of function calls with no error checking or recovery, and no documentation/description about dependencies/sequencing etc. etc. Based on the patches at hadn (which is all reviewers have to go on), notifiers seemed to be a good fit. If there are good reasons that all of the device-off events need to be coordinated/synchronized/sequenced (and it sounds like there are, thanks for pointing them out), I am not opposed to that approach. It simply needs to be well described in the changlog. There are sequence dependencies but lot of code can be extracted and put into smaller blocks that is independent. I agree for the error handling part notifier chain could be an issue. 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: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
Ricardo Neri wrote: +Tomi Hi Xiao, On 05/30/2012 02:14 AM, Xiao Jiang wrote: Hello, After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got some err infos with latest Linus's tree, does somebody also has the same issue? sound/soc/omap/omap-hdmi.c:45:24: error: field 'dss_audio' has incomplete type sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_startup': sound/soc/omap/omap-hdmi.c:67:27: error: 'struct omap_dss_driver' has no member named 'audio_supported' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:79:29: error: 'struct omap_dss_driver' has no member named 'audio_enable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_hw_params': sound/soc/omap/omap-hdmi.c:208:28: error: 'struct omap_dss_driver' has no member named 'audio_config' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_trigger': sound/soc/omap/omap-hdmi.c:224:29: error: 'struct omap_dss_driver' has no member named 'audio_start' sound/soc/omap/omap-hdmi.c:229:23: error: 'struct omap_dss_driver' has no member named 'audio_stop' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_shutdown': sound/soc/omap/omap-hdmi.c:242:22: error: 'struct omap_dss_driver' has no member named 'audio_disable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:80:1: warning: control reaches end of non-void function Build breaks because there some patches [1] that are still missing in Linus' tree. ASoC HDMI audio driver for OMAP[2] now uses the new DSS audio functionality in [1], but ASoC patches were merged first. DSS patches have been accepted and they are part of Tomi's pull request for DSS for K3.5. Hopefully this will be fixed when v3.5-rc1 is out. Ricardo, thanks for your detail infos :). Regards, Xiao BR, Ricardo [1].http://www.spinics.net/lists/linux-omap/msg69466.html [2].http://www.spinics.net/lists/linux-omap/msg70561.html Regards, Xiao -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm/dts: add wdt node for omap3 and omap4
Hi Jon and Benoit,
Thanks for reminding, how about below patch?
diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
new file mode 100644
index 000..4272d06
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt
@@ -0,0 +1,15 @@
+TI Watchdog Timer (WDT) Controller for OMAP
+
+Required properties:
+- compatible:
+ - ti,omap2-wdt for OMAP2
+ - ti,omap3-wdt for OMAP3
+ - ti,omap4-wdt for OMAP4
+- ti,hwmods: Name of the hwmod associated to the WDT
+
+Examples:
+
+wdt2: wdt@73f98000 {
+ compatible = ti,omap4-wdt;
+ ti,hwmods = wd_timer2;
+};
Yes looks good. Thanks! Minor nit-pick in the example I would just copy
the omap4 node completely with the actual omap4 address :-)
Oops, wrong addr, :). Perhaps we can drop address as you said, since the
right addresses are defined
in wd_timer2 hwmod (see [1]), and wdt also works without the address as
follows.
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index f2ab4ea..0017bd8 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -63,5 +63,10 @@
ti,hwmods = uart3;
clock-frequency = 4800;
};
+
+ wdt2: wdt {
+ compatible = ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..dbf8a5b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,10 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ wdt2: wdt {
+ compatible = ti,omap3-wdt, ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..ce74e87 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,10 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ wdt2: wdt {
+ compatible = ti,omap4-wdt, ti,omap2-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
Infos for omap3:
# dmesg|grep Machine
6[0.00] Machine: Generic OMAP3 (Flattened Device Tree), model:
TI OMAP3 EVM (OMAP3530, AM/DM37x)
# dmesg|grep omap_wdt_probe
4[2.552825] in omap_wdt_probe: 299, res-start = 0x48314000
Infos for omap4:
root@localhost:/root dmesg|grep Machine
[0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI
OMAP4 SDP board
root@localhost:/root dmesg|grep omap_wdt_probe
[1.687896] in omap_wdt_probe: 299, res-start = 0x4a314000
So can I drop the wdt addr from dts file? otherwise it is not feasible
to add omap2 wdt node in omap2.dtsi
due to different addrs for omap2420 and omap2430.
Regards,
Xiao
[1] http://marc.info/?l=linux-omapm=133836995026565w=2
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: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
On 05/31/2012 02:35 AM, Ricardo Neri wrote: Build breaks because there some patches [1] that are still missing in Linus' tree. ASoC HDMI audio driver for OMAP[2] now uses the new DSS audio functionality in [1], but ASoC patches were merged first. DSS patches have been accepted and they are part of Tomi's pull request for DSS for K3.5. Hopefully this will be fixed when v3.5-rc1 is out. Then there was an error already in the process if dependent sets didn't go together via the same merge or in next merge window. Remember each commit must compile alone. It's quite boring to try to bisect over multiple kernel versions and where most of the time goes solving random unrelated build breakages. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
