Re: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]: On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote: Hi, * Paul Walmsley p...@pwsan.com [120726 13:07]: On Wed, 25 Jul 2012, Paul Walmsley wrote: These IP blocks and the ECAP IP blocks have periods in their names. The rest of the IP block named in the file don't use periods -- which is also the style used by the rest of the OMAP SoCs. Is there some reason that these have periods in their names? I've changed those to match the rest of the names, and queued the following for 3.7. Thanks again for all the hard work you all put into this. I realize that with all the upstream changes, this was probably a little painful for you. But from my perspective you've been a pleasure to work with through the process. As am33xx and omap5 are DT only, we should start moving towards getting rid of grep -E irq|pa_start|pa_end|dma in this patch and get the standard data from .dtsi files instead. It may not be so straight, given the fact that hwmod layer requires these resources, as hwmod is responsible to configure SYSCONF register of the device (happens very early at core_init level). Somehow we have to have some mechanism to initialize _mpu_rt_va before core_init call, which will take DT resources and initialize accordingly. That's for the device reset/idle? We should not do that in hwmod code except in late_initcall for unclaimed devices as discussed earlier. We discussed setting up the reset function in the device specific headers so both device and hwmod code can call them as needed. Another dependency we will have is on system timers, Jon has already done some initial work on this, but I believe we did not concluded on the it. I will re-start the thread again, since in any case DT support in timer is required. Right.. The timers are a pain right now as they need to be initialized early. Everything else can and should be initialized at the device probe time, or from a late_initcall for the unclaimed devices. Alternatively we could get rid of the names and match the module based on pa_start and pa_end. Just FYI, from resource perspective, I have changed omap_device layer for DT resources only (still need hwmod resources as explained above) and patch looks something like (and it works) - Cool yeah few more dependencies remain still. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP: omap_device: idle devices with no driver bound
* Paul Walmsley p...@pwsan.com [120810 15:59]: On Fri, 10 Aug 2012, Kevin Hilman wrote: Under some circumstances, drivers may leave an omap_device enabled due to driver programming errors, or due to a failure in the drivers probe method. Using the recently added omap_device driver_status field, we can detect conditions where an omap_device is enabled but has no driver bound and then ensure that the device is properly idled until it can be probed again. The goal of this feature is not only to detect and warn on these error conditions, but also to ensure that devices are properly put in low-power states so they do not prevent SoC-wide low-power states. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kevin Hilman khil...@ti.com Here's the queued version of this one. Nice to see this happening :) Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]: On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote: Hi, * Paul Walmsley p...@pwsan.com [120726 13:07]: On Wed, 25 Jul 2012, Paul Walmsley wrote: These IP blocks and the ECAP IP blocks have periods in their names. The rest of the IP block named in the file don't use periods -- which is also the style used by the rest of the OMAP SoCs. Is there some reason that these have periods in their names? I've changed those to match the rest of the names, and queued the following for 3.7. Thanks again for all the hard work you all put into this. I realize that with all the upstream changes, this was probably a little painful for you. But from my perspective you've been a pleasure to work with through the process. As am33xx and omap5 are DT only, we should start moving towards getting rid of grep -E irq|pa_start|pa_end|dma in this patch and get the standard data from .dtsi files instead. It may not be so straight, given the fact that hwmod layer requires these resources, as hwmod is responsible to configure SYSCONF register of the device (happens very early at core_init level). Somehow we have to have some mechanism to initialize _mpu_rt_va before core_init call, which will take DT resources and initialize accordingly. That's for the device reset/idle? We should not do that in hwmod code except in late_initcall for unclaimed devices as discussed earlier. We discussed setting up the reset function in the device specific headers so both device and hwmod code can call them as needed. Tony, May be I didn't understand your above statement, can you please elaborate more on device specific header file? Just to highlight, its not only during late_initcall, the _enable and _idle functions are getting executed as part of every runtime_pm_get\put_sync from the driver. Are you saying as part of late_initcall, we should initialize _mpu_rt_va of struct omap_hwmod??? Also, as far unclaimed resources is concerned, somewhere you should have base addr of the device maintained, right? Currently, hwmod is maintaining this data and the execution goes something like, Core_initcall() - _setup() - _setup_reset() - _idle() Another biggest worry is, if I play here, it may break existing omap3/4 Functionality, especially may impact from PM perspective. So I believe, we need to have something which adds/cleans-up things in stages. May be get rid of resource overwriting for AM33xx and OMAP5 alone as of now?? Any thoughts?? Thanks, Vaibhav Another dependency we will have is on system timers, Jon has already done some initial work on this, but I believe we did not concluded on the it. I will re-start the thread again, since in any case DT support in timer is required. Right.. The timers are a pain right now as they need to be initialized early. Everything else can and should be initialized at the device probe time, or from a late_initcall for the unclaimed devices. Alternatively we could get rid of the names and match the module based on pa_start and pa_end. Just FYI, from resource perspective, I have changed omap_device layer for DT resources only (still need hwmod resources as explained above) and patch looks something like (and it works) - Cool yeah few more dependencies remain still. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] memory: emif: add device tree support to emif driver
From: Aneesh V ane...@ti.com
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
v5:
Updated the patch as per Greg's comment for moving
the lpddr2 dt timings generic functions to separate
file(of_memory.c) and building it only for CONFIG_OF.
drivers/memory/Makefile|1 +
drivers/memory/emif.c | 182 +++-
drivers/memory/of_memory.c | 153 +
drivers/memory/of_memory.h | 36 +
4 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/of_memory.c
create mode 100644 drivers/memory/of_memory.h
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..cd8486b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -2,6 +2,7 @@
# Makefile for memory devices
#
+obj-$(CONFIG_OF) += of_memory.o
obj-$(CONFIG_TI_EMIF) += emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..1424ae3 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -25,6 +26,7 @@
#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
+#include of_memory.h
/**
* struct emif_data - Per device static data for driver's use
@@ -49,6 +51,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root: dentry to the root folder for EMIF in debugfs
+ * @np_ddr:Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +66,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node *np_emif,
+ struct emif_data *emif)
+{
+ struct emif_custom_configs *cust_cfgs = NULL;
+ int len;
+ const int *lpmode, *poll_intvl;
+
+ lpmode = of_get_property(np_emif, low-power-mode, len);
+ poll_intvl = of_get_property(np_emif, temp-alert-poll-interval, len);
+
+ if (lpmode || poll_intvl)
+ cust_cfgs = devm_kzalloc(emif-dev, sizeof(*cust_cfgs),
+ GFP_KERNEL);
+
+ if (!cust_cfgs)
+ return;
+
+ if (lpmode) {
+ cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_LPMODE;
+ cust_cfgs-lpmode = *lpmode;
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-performance,
+ cust_cfgs-lpmode_timeout_performance);
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-power,
+ cust_cfgs-lpmode_timeout_power);
+ of_property_read_u32(np_emif,
+ low-power-mode-freq-threshold,
+ cust_cfgs-lpmode_freq_threshold);
+ }
+
+ if (poll_intvl) {
+ cust_cfgs-mask |=
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL;
+ cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
+ }
+
+ if (!is_custom_config_valid(cust_cfgs, emif-dev)) {
+ devm_kfree(emif-dev, cust_cfgs);
+ return;
+ }
+
+ emif-plat_data-custom_configs = cust_cfgs;
+}
+
+static void __init_or_module of_get_ddr_info(struct device_node *np_emif,
+ struct device_node *np_ddr,
+ struct ddr_device_info *dev_info)
+{
+ u32 density = 0, io_width = 0;
+ int len;
+
+ if (of_find_property(np_emif, cs1-used, len))
+ dev_info-cs1_used = true;
+
+ if (of_find_property(np_emif, cal-resistor-per-cs, len))
+ dev_info-cal_resistors_per_cs = true;
+
+ if (of_device_is_compatible(np_ddr ,
Re: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]: On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]: Somehow we have to have some mechanism to initialize _mpu_rt_va before core_init call, which will take DT resources and initialize accordingly. That's for the device reset/idle? We should not do that in hwmod code except in late_initcall for unclaimed devices as discussed earlier. We discussed setting up the reset function in the device specific headers so both device and hwmod code can call them as needed. May be I didn't understand your above statement, can you please elaborate more on device specific header file? We should have the device drivers idle and reset the devices. But also hwmod may need to do that for the unclaimed devices for PM to work. As the driver may not be even compiled in, the driver specific reset and idle functions should be static inline functions in the device specific header file so hwmod code can still call those. Just to highlight, its not only during late_initcall, the _enable and _idle functions are getting executed as part of every runtime_pm_get\put_sync from the driver. Right, so no need to initialize those until at driver probe time. Are you saying as part of late_initcall, we should initialize _mpu_rt_va of struct omap_hwmod??? I guess either at driver probe for the claimed devices, or at late_initcall for the unclaimeded devices. Also, as far unclaimed resources is concerned, somewhere you should have base addr of the device maintained, right? Currently, hwmod is maintaining this data and the execution goes something like, Core_initcall() - _setup() - _setup_reset() - _idle() For the DT only case also the unclaimed devices can from DT with status = disabled. Another biggest worry is, if I play here, it may break existing omap3/4 Functionality, especially may impact from PM perspective. So I believe, we need to have something which adds/cleans-up things in stages. It seems that we need three stages: Something early for the timers only, initialize most things during driver probe, then late_initcall for the unclaimed devices. May be get rid of resource overwriting for AM33xx and OMAP5 alone as of now?? Sorry I don't follow this part, care to explain a little more? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Add initialisation for the real-time counter.
On Tue, Aug 14, 2012 at 11:52 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Tue, Aug 14, 2012 at 11:46:35, Shilimkar, Santosh wrote:
On Mon, Aug 13, 2012 at 11:05 PM, Vaibhav Hiremath hvaib...@ti.com
wrote:
[...]
Also, does it make sense to get rid of hardcoded values above?
Actually not. Because the values are fixed since the counter
clock-rate is hardwired to be 6.144 MHz and hence all the
other numbers becomes constant. All these numbers are
coming from TRM and not from any formula. I don't wanted
to go on mathematical equation path since all the values
are well documented.
Yes, I looked at the TRM and they are well documented there.
I would atleast suggest you to state that, these values are coming
directly
from TRM and possibly give reference to the TRM section here.
Added the TRM chapter information and iounmap() change.
Updated patch at end of the email.
Regards
Santosh
From aae85431b1a0e985bbc5611972642e96a1501368 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 13 Aug 2012 14:24:24 +0530
Subject: [PATCH 1/2] ARM: OMAP: Add initialisation for the real-time counter.
The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.
The ratio registers needs to be configured based on system clock
only onetime. After initialisation, hardware takes care of adjusting
the clock in different low power modes to keep counter rate constant.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/timer.c | 90 ++-
2 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..2120f90 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -24,6 +24,9 @@ config ARCH_OMAP2PLUS_TYPICAL
config SOC_HAS_OMAP2_SDRC
bool OMAP2 SDRAM Controller support
+config SOC_HAS_REALTIME_COUNTER
+ bool Real time free running counter
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
@@ -69,6 +72,7 @@ config SOC_OMAP5
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select SOC_HAS_REALTIME_COUNTER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..fd5c048 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,6 +69,11 @@
#define OMAP3_SECURE_TIMER 1
#endif
+#define REALTIME_COUNTER_BASE 0x48243200
+#define INCREMENTER_NUMERATOR_OFFSET 0x10
+#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
+#define NUMERATOR_DENUMERATOR_MASK 0xf000
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -339,6 +344,84 @@ static void __init omap2_clocksource_init(int gptimer_id,
omap2_gptimer_clocksource_init(gptimer_id, fck_source);
}
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+/*
+ * The realtime counter also called master counter, is a free-running
+ * counter, which is related to real time. It produces the count used
+ * by the CPU local timer peripherals in the MPU cluster. The timer counts
+ * at a rate of 6.144 MHz. Because the device operates on different clocks
+ * in different power modes, the master counter shifts operation between
+ * clocks, adjusting the increment per clock in hardware accordingly to
+ * maintain a constant count rate.
+ */
+static void __init realtime_counter_init(void)
+{
+ void __iomem *base;
+ static struct clk *sys_clk;
+ unsigned long rate;
+ unsigned int reg, num, den;
+
+ base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
+ if (!base) {
+ pr_err(%s: ioremap failed\n, __func__);
+ return;
+ }
+ sys_clk = clk_get(NULL, sys_clkin_ck);
+ if (!sys_clk) {
+ pr_err(%s: failed to get system clock handle\n, __func__);
+ iounmap(base);
+ return;
+ }
+
+ rate = clk_get_rate(sys_clk);
+ /* Numerator/denumerator values refer TRM Realtime Counter section */
+ switch (rate) {
+ case 120:
+ num = 64;
+ den = 125;
+ break;
+ case 130:
+ num = 768;
+ den = 1625;
+ break;
+ case 1920:
+ num = 8;
+ den = 25;
+ break;
+ case 260:
+ num = 384;
+ den = 1625;
+ break;
+ case 270:
+ num = 256;
+ den = 1125;
+ break;
+ case 3840:
+ default:
+ /* Program it for 38.4 MHz */
+ num = 4;
+
Re: [PATCH v4 4/4] memory: emif: add device tree support to emif driver
On Fri, Aug 17, 2012 at 12:15 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Aug 13, 2012 at 10:57:06AM +0530, Shilimkar, Santosh wrote:
Greg,
On Wed, Jul 18, 2012 at 12:14 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 17, 2012 at 11:28 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Jul 17, 2012 at 10:37:45PM +0530, Shilimkar, Santosh wrote:
On Tue, Jul 17, 2012 at 10:06 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Mon, Jul 09, 2012 at 07:02:36PM +0530, Shilimkar, Santosh wrote:
Greg,
[..]
From 74688a87fd490909e9122bf757c0096480e9fc11 Mon Sep 17 00:00:00 2001
From: Aneesh V ane...@ti.com
Date: Mon, 30 Jan 2012 20:06:30 +0530
Subject: [PATCH 4/4] memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/memory/Makefile|1 +
drivers/memory/emif.c | 182
+++-
drivers/memory/of_memory.c | 153 +
drivers/memory/of_memory.h | 36 +
4 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/of_memory.c
create mode 100644 drivers/memory/of_memory.h
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..cd8486b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -2,6 +2,7 @@
# Makefile for memory devices
#
+obj-$(CONFIG_OF) += of_memory.o
obj-$(CONFIG_TI_EMIF)+= emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..06b4eb7 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -25,6 +26,7 @@
#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
+#include of_memory.h
/**
* struct emif_data - Per device static data for driver's use
@@ -49,6 +51,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root:dentry to the root folder for EMIF in
debugfs
+ * @np_ddr: Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +66,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node
*np_emif,
+ struct emif_data *emif)
Why can't all of this code be in the of_memory.c file?
Primarily because the parameters are very much specific to EMIF
memory controller and won't be of much use for other memory controllers.
Currently the information extracted from DT with these function is like:
- EMIF controller IP version : EMIF_4D or EMIF_4D5
- Which analog phy is integrated : EMIF_ATTILAPHY or EMIF_ATTILAPHY
- IP hardware interface: EMIF Low latency port or sys port interface.
- EMIF connections - Whether EMIF1 only, EMIF2 only or EMIF1 EMIF2
- Memory connections to EMIF - Same type and size memories or asymmetric
- Chip select usage per controller: Whether CS0, CS1, CS0 CS1
- ZQ calibration - Per chip select or enable EMIF dual calibration feature.
- Enable/disable EMIF Low power mode and temperature alerts.
- EMIF low power mode configuration:
- Clock stop, self refresh, Deep power down.
- Low power time out values for performance and power mode.
- DDR frequency threshold to switch between power and
performance settings.
- EMIF temperature polling cycle configuration.
As you can see these are very specific to the EMIF memory controller and
hence
I didn't move them to of_memory.c
Do you have any more comment on this patch? If not, I can go ahead and
post the refreshed version of the patch.
Please always
RE: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
Somehow we have to have some mechanism to initialize _mpu_rt_va
before
core_init call, which will take DT resources and initialize accordingly.
That's for the device reset/idle? We should not do that in hwmod code
except in late_initcall for unclaimed devices as discussed earlier. We
discussed setting up the reset function in the device specific headers
so both device and hwmod code can call them as needed.
May be I didn't understand your above statement, can you please elaborate
more on device specific header file?
We should have the device drivers idle and reset the devices. But also
hwmod may need to do that for the unclaimed devices for PM to work.
As the driver may not be even compiled in, the driver specific reset and
idle functions should be static inline functions in the device specific
header file so hwmod code can still call those.
How about mapping the address of the devices?
Some more thoughts on the similar line on unclaimed devices -
As par of late_initcall(), traverse all the DTB nodes and for each node with
state = disabled, we can do something like,
Late_initcall()
- Traverse DTB nodes and check for state = disabled
- Read the ti,hwmod entry and get offsets like, sys_config
and reset.
- Map the base address
- Enable the module/clock
- Reset the device
- Write to sysc register offset
- Disable the module/clock
Just to highlight, its not only during late_initcall, the _enable and _idle
functions are getting executed as part of every runtime_pm_get\put_sync
from
the driver.
Right, so no need to initialize those until at driver probe time.
Agreed.
Are you saying as part of late_initcall, we should initialize _mpu_rt_va
of struct omap_hwmod???
I guess either at driver probe for the claimed devices, or at late_initcall
for the unclaimeded devices.
Also, as far unclaimed resources is concerned, somewhere you should have
base addr of the device maintained, right? Currently, hwmod is maintaining
this data and the execution goes something like,
Core_initcall()
- _setup()
- _setup_reset()
- _idle()
For the DT only case also the unclaimed devices can from DT with
status = disabled.
Another biggest worry is, if I play here, it may break existing omap3/4
Functionality, especially may impact from PM perspective. So I believe, we
need to have something which adds/cleans-up things in stages.
It seems that we need three stages: Something early for the timers only,
initialize most things during driver probe, then late_initcall for the
unclaimed devices.
Most likely yes, or it may even get into more stages.
At the current stage, I really think it would be really nice and beneficial
for driver developers from the community if they get Linux Boot from
linux-next/master branch. I have seen lot of community folks are struggling
with it and they are blocked because we do not have booting kernel on
BeagleBone.
They always end up patching kernel with HWMOD patch and submit the driver
patches. So request to consider this cleanup as sequential patch on top of
original HWMOD patch?
May be get rid of resource overwriting for AM33xx and OMAP5 alone as of
now??
Sorry I don't follow this part, care to explain a little more?
As per current implementation, we are using HWMOD information to fill the
platform_device-resources. Even if you pass reg and interrupt property
from DT, omap_device layer overwrites it with HWMOD data information.
So what I am trying to propose here is, avoid this overwrite and resources
(address and interrupt) should strictly gets used from DT blob. Since AM33xx
and OMAP5 devices are the new devices and supports DT boot only, we can
implement it easily for them.
Only issue her is, DMA resources, I was going through some of the old email
archives today, submitted by Benoit and later Jon, but I am still not sure
how to pass dma_channel to driver as a resource.
Below logic works for me, I have tested it on both BeagleBone and AM37xEVM -
omap_device_alloc ()
{
...
res_count = omap_device_count_resources(od);
if (res_count pdev-num_resources) {
res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
if (!res)
goto oda_exit3;
if (pdev-num_resources pdev-resource) {
omap_device_fill_dma_resources(od, res);
memcpy(res[pdev-num_resources], pdev-resource,
sizeof(struct resource) * pdev-num_resources);
Re: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
* Hiremath, Vaibhav hvaib...@ti.com [120817 02:51]: On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]: On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]: Somehow we have to have some mechanism to initialize _mpu_rt_va before core_init call, which will take DT resources and initialize accordingly. That's for the device reset/idle? We should not do that in hwmod code except in late_initcall for unclaimed devices as discussed earlier. We discussed setting up the reset function in the device specific headers so both device and hwmod code can call them as needed. May be I didn't understand your above statement, can you please elaborate more on device specific header file? We should have the device drivers idle and reset the devices. But also hwmod may need to do that for the unclaimed devices for PM to work. As the driver may not be even compiled in, the driver specific reset and idle functions should be static inline functions in the device specific header file so hwmod code can still call those. How about mapping the address of the devices? That should be done based on the iorange coming from DT during the driver probe. The range in hwmod can be populated at that point too if needed. Some more thoughts on the similar line on unclaimed devices - As par of late_initcall(), traverse all the DTB nodes and for each node with state = disabled, we can do something like, Late_initcall() - Traverse DTB nodes and check for state = disabled - Read the ti,hwmod entry and get offsets like, sys_config and reset. - Map the base address - Enable the module/clock - Reset the device - Write to sysc register offset - Disable the module/clock Just to highlight, its not only during late_initcall, the _enable and _idle functions are getting executed as part of every runtime_pm_get\put_sync from the driver. Heh, but the unclaimed devices do not have a driver :) So there's no runtime_pm calls for the unclaimed devicdes. At the current stage, I really think it would be really nice and beneficial for driver developers from the community if they get Linux Boot from linux-next/master branch. I have seen lot of community folks are struggling with it and they are blocked because we do not have booting kernel on BeagleBone. They always end up patching kernel with HWMOD patch and submit the driver patches. So request to consider this cleanup as sequential patch on top of original HWMOD patch? Yes I'm fine merging the data as is, just trying to figure out how to sort out the issues for future. May be get rid of resource overwriting for AM33xx and OMAP5 alone as of now?? Sorry I don't follow this part, care to explain a little more? As per current implementation, we are using HWMOD information to fill the platform_device-resources. Even if you pass reg and interrupt property from DT, omap_device layer overwrites it with HWMOD data information. So what I am trying to propose here is, avoid this overwrite and resources (address and interrupt) should strictly gets used from DT blob. Since AM33xx and OMAP5 devices are the new devices and supports DT boot only, we can implement it easily for them. Yes I agree. And then we should also drop the data from hwmod when it's no longer needed. Only issue her is, DMA resources, I was going through some of the old email archives today, submitted by Benoit and later Jon, but I am still not sure how to pass dma_channel to driver as a resource. Hmm I thought that got merged already? Anyways, the iorange and interrupts are standard resources that should exist in every device entry in .dts files. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
On Fri, Aug 17, 2012 at 15:28:51, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120817 02:51]: On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]: On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]: Somehow we have to have some mechanism to initialize _mpu_rt_va before core_init call, which will take DT resources and initialize accordingly. That's for the device reset/idle? We should not do that in hwmod code except in late_initcall for unclaimed devices as discussed earlier. We discussed setting up the reset function in the device specific headers so both device and hwmod code can call them as needed. May be I didn't understand your above statement, can you please elaborate more on device specific header file? We should have the device drivers idle and reset the devices. But also hwmod may need to do that for the unclaimed devices for PM to work. As the driver may not be even compiled in, the driver specific reset and idle functions should be static inline functions in the device specific header file so hwmod code can still call those. How about mapping the address of the devices? That should be done based on the iorange coming from DT during the driver probe. The range in hwmod can be populated at that point too if needed. There will not be any driver probe for unclaimed devices, right? Some more thoughts on the similar line on unclaimed devices - As par of late_initcall(), traverse all the DTB nodes and for each node with state = disabled, we can do something like, Late_initcall() - Traverse DTB nodes and check for state = disabled - Read the ti,hwmod entry and get offsets like, sys_config and reset. - Map the base address - Enable the module/clock - Reset the device - Write to sysc register offset - Disable the module/clock Just to highlight, its not only during late_initcall, the _enable and _idle functions are getting executed as part of every runtime_pm_get\put_sync from the driver. Heh, but the unclaimed devices do not have a driver :) So there's no runtime_pm calls for the unclaimed devicdes. I think you mixed two responses here, this was not part of my last response. Just only read above code execution steps, I think they still make sense and we may end up doing something similar. At the current stage, I really think it would be really nice and beneficial for driver developers from the community if they get Linux Boot from linux-next/master branch. I have seen lot of community folks are struggling with it and they are blocked because we do not have booting kernel on BeagleBone. They always end up patching kernel with HWMOD patch and submit the driver patches. So request to consider this cleanup as sequential patch on top of original HWMOD patch? Yes I'm fine merging the data as is, just trying to figure out how to sort out the issues for future. Thanks a lot Tony. Paul, Care to add it in your next pull request. May be get rid of resource overwriting for AM33xx and OMAP5 alone as of now?? Sorry I don't follow this part, care to explain a little more? As per current implementation, we are using HWMOD information to fill the platform_device-resources. Even if you pass reg and interrupt property from DT, omap_device layer overwrites it with HWMOD data information. So what I am trying to propose here is, avoid this overwrite and resources (address and interrupt) should strictly gets used from DT blob. Since AM33xx and OMAP5 devices are the new devices and supports DT boot only, we can implement it easily for them. Yes I agree. And then we should also drop the data from hwmod when it's no longer needed. Exactly, I will submit RFC for this. Only issue her is, DMA resources, I was going through some of the old email archives today, submitted by Benoit and later Jon, but I am still not sure how to pass dma_channel to driver as a resource. Hmm I thought that got merged already? No, atleast didn't find in 3.6-rc1. Anyways, the iorange and interrupts are standard resources that should exist in every device entry in .dts files. Agreed, I am submitting patch for this as well. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP HWMOD: Query regarding parent-child support
On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote: Hi All, Paul, From last couple of days I am almost spending my whole time trying to get to somewhere on below issue and based on my understanding and learning so far I started feeling that, probably we might have made wrong decision to remove all leaf-nodes from the clock-tree. Instead we should have it removed from hwmod. :) Let's take a example of PWM Module (which is the context of my debugging) - As I mentioned before, PWM module present in AM33XX looks something like - -- | | | | PWMSS | | | | | --- - | | | eCAP | | ePWM | | eQEP | | | --- - | -- PWMSS: This actually controls all PM related signals like idle, standby, etc... eCAP/ePWM/eQEP: Technically it is independent module, reused from Davinci devices and is implemented as independent drivers in kernel. In case of AM33xx, the basic resources like, clock, idle signal and standby signal are abstracted at PWMSS level. This means the core IP (eCAP/ePWM/eQEP) have not changed from their original implementation. These core IP's (eCAP/ePWM/eQEP) are being used in Davinci family of devices, but without encapsulation of PWMSS, unlike AM33XX. This means, each module has its own clock enable/disable control mechanism and there is no dependency between them, unlike AM33XX. Options to support: 1. Use existing Clock Framework infrastructure to handle, which basically supports clock enable/disable function based on usecount and parent-child relation. Driver will simply work, without knowing anything about underneath platform, which is what expected. So create a dummy-clocks for submodules, making PWMSS clock as a parent will solve the issue here. And nothing wrong here, we are just treating, clock-enable = module-enable The only issue here is sysconf register access at hwmod level, if you leave sysconf idle and standby configuration at smart state, it works properly. I have validated it at my end. 2. MFD Driver: I think it will be miss-use of MFD driver and should be explored at all. I certainly vote for option-1. Paul, if you agree with me, I will submit the patch for option-1. NOTE: Same thing is applicable for CPSW driver, where two independent drivers (MDIO and CPSW) share common clock and needs similar fix. Thanks, Vaibhav During migration to run-time PM we came across unique (I believe) issue with respect to CPSW driver and eHRPWM. I am looking for pointers to handle these use-cases, as I am still going through the code and trying to understand myself on how can we handle this. CPSW: = CPSW Subsystem is built with 5 sub-modules, - CPSW SS (BaseAddr@0x4A10, rst@0x8) - MDIO (BaseAddr@0x4A101000) - CPSW WR (0x4A101200, rst@0x4) - CPSW SL1 (0x4A100D80, rst@0xc) - CPSW SL2 (0x4A100DC0, rst@0xc) - CPSW CPDMA (0x4A100800, rst@0x1c) Issue1: --- IP's are reused from legacy devices, for example, we have 2 separate platform driver for MDIO and cpsw, used between Davinci and AM335x. Everything is controlled through one MODULEMODE register in PRCM. So now we have 2 different modules accessing same resources (CLKCTRL.MODULEMODE), it is tricky to handle this usecase. Earlier with clock api's, it was easy, since clock framework used to handle ref_count for this and was sufficient here but with migration to runtime PM, we no longer use clk api's. Option1: It must be handled at driver level, and there will be handshaking between both the drivers. Which might impact legacy devices. Option2: It must be handled at SoC level, and parent and child creation is required here. parent-child creation is possible with platform device, but not sure about how it can be integrated with omap_device and hwmod. I am reading code and trying to understand how can this be handled? what is right place to create this parent-child relation? Issue2: --- Due to one of the HW bug, we have assert ocp-reset 4 sub-modules of CPSW before disabling clock/module (MODULEMODE=0) everytime. So for example, in every suspend-resume code before disabling the module, we have to assert ocp-reset and then disable the module. Also, please note that, the MDIO driver is separate and independent and requires clock to access sysconf register. We can have hwmod_class-reset function here, but the reset offset is different for every module, which makes it even difficult to handle. So if we have parent-child relation at some level, Where, we can register custom reset function to handle this scenario is
Re: [PATCH v3 0/9] ARM/ASoC: OMAP McBSP device tree support
On Thu, Aug 16, 2012 at 04:40:59PM +0300, Peter Ujfalusi wrote: in order to be able to add DT support for the McBSP driver which is used on all OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack: Tony, are you OK with these changes going via ASoC? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAPDSS: Miscellaneous cleanup patches
These are minor cleanup patches which will be useful for the future series on outputs. It's harder to add output entities in DSS when there are more omap_dss_device references in the driver. The first 2 reduces that a bit. The third patch just removes some left over fields from omap_dss_device Refenence Tree: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 1-misc-clean-for-outputs Archit Taneja (3): OMAPDSS: DSI: Pass dsi platform device wherever possible OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions OMAPDSS: Remove unnecessary acb/acbi pin fields from omap_dss_device drivers/video/omap2/dss/apply.c | 32 +- drivers/video/omap2/dss/dsi.c | 89 +-- include/video/omapdss.h |4 -- 3 files changed, 60 insertions(+), 65 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAPDSS: DSI: Pass dsi platform device wherever possible
Many of the DSI functions receive the connected panel's omap_dss_device pointer
as an argument. The platform device pointer is then derived via omap_dss_device
pointers.
Most of these functions don't really require omap_dss_device pointer anymore
since we now keep copies of parameters in the driver data which were previously
available only via omap_dss_device. Replace the arguments with platform device
pointers for such functions.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 89 ++---
1 file changed, 39 insertions(+), 50 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 96d0024..659b6cd 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2014,9 +2014,8 @@ static unsigned dsi_get_line_buf_size(struct
platform_device *dsidev)
}
}
-static int dsi_set_lane_config(struct omap_dss_device *dssdev)
+static int dsi_set_lane_config(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
static const u8 offsets[] = { 0, 4, 8, 12, 16 };
static const enum dsi_lane_function functions[] = {
@@ -2151,10 +2150,9 @@ static void dsi_cio_timings(struct platform_device
*dsidev)
}
/* lane masks have lane 0 at lsb. mask_p for positive lines, n for negative */
-static void dsi_cio_enable_lane_override(struct omap_dss_device *dssdev,
+static void dsi_cio_enable_lane_override(struct platform_device *dsidev,
unsigned mask_p, unsigned mask_n)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int i;
u32 l;
@@ -2201,9 +2199,8 @@ static void dsi_cio_disable_lane_override(struct
platform_device *dsidev)
REG_FLD_MOD(dsidev, DSI_DSIPHY_CFG10, 0, 22, 17);
}
-static int dsi_cio_wait_tx_clk_esc_reset(struct omap_dss_device *dssdev)
+static int dsi_cio_wait_tx_clk_esc_reset(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int t, i;
bool in_use[DSI_MAX_NR_LANES];
@@ -2251,9 +2248,8 @@ static int dsi_cio_wait_tx_clk_esc_reset(struct
omap_dss_device *dssdev)
}
/* return bitmask of enabled lanes, lane0 being the lsb */
-static unsigned dsi_get_lane_mask(struct omap_dss_device *dssdev)
+static unsigned dsi_get_lane_mask(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
unsigned mask = 0;
int i;
@@ -2266,16 +2262,15 @@ static unsigned dsi_get_lane_mask(struct
omap_dss_device *dssdev)
return mask;
}
-static int dsi_cio_init(struct omap_dss_device *dssdev)
+static int dsi_cio_init(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int r;
u32 l;
DSSDBGF();
- r = dss_dsi_enable_pads(dsi-module_id, dsi_get_lane_mask(dssdev));
+ r = dss_dsi_enable_pads(dsi-module_id, dsi_get_lane_mask(dsidev));
if (r)
return r;
@@ -2292,7 +2287,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
goto err_scp_clk_dom;
}
- r = dsi_set_lane_config(dssdev);
+ r = dsi_set_lane_config(dsidev);
if (r)
goto err_scp_clk_dom;
@@ -2327,7 +2322,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
mask_p |= 1 i;
}
- dsi_cio_enable_lane_override(dssdev, mask_p, 0);
+ dsi_cio_enable_lane_override(dsidev, mask_p, 0);
}
r = dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_ON);
@@ -2344,7 +2339,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_if_enable(dsidev, false);
REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 1, 20, 20); /* LP_CLK_ENABLE */
- r = dsi_cio_wait_tx_clk_esc_reset(dssdev);
+ r = dsi_cio_wait_tx_clk_esc_reset(dsidev);
if (r)
goto err_tx_clk_esc_rst;
@@ -2385,13 +2380,12 @@ err_cio_pwr:
dsi_cio_disable_lane_override(dsidev);
err_scp_clk_dom:
dsi_disable_scp_clk(dsidev);
- dss_dsi_disable_pads(dsi-module_id, dsi_get_lane_mask(dssdev));
+ dss_dsi_disable_pads(dsi-module_id, dsi_get_lane_mask(dsidev));
return r;
}
-static void dsi_cio_uninit(struct omap_dss_device *dssdev)
+static void dsi_cio_uninit(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
/* DDR_CLK_ALWAYS_ON */
@@ -2399,7
[PATCH 2/3] OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
is an enabled display connected to the manager before trying to see the state of
the GO bit.
The checks related to the display can be replaced by checking the state of the
manager, i.e, whether the manager is enabled or not. This makes more sense than
checking with the connected display as the GO bit behaviour is more connected
with the manager state rather than the display state. A GO bit can only be set
if the manager is enabled. If a manager isn't enabled, we can safely assume that
the GO bit is not set.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 52a5940..74f1a58 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -424,17 +424,23 @@ static void wait_pending_extra_info_updates(void)
int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
{
unsigned long timeout = msecs_to_jiffies(500);
- struct mgr_priv_data *mp;
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
u32 irq;
+ unsigned long flags;
int r;
int i;
- struct omap_dss_device *dssdev = mgr-device;
- if (!dssdev || dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ if (mgr_manual_update(mgr))
return 0;
- if (mgr_manual_update(mgr))
+ spin_lock_irqsave(data_lock, flags);
+
+ if (!mp-enabled) {
+ spin_unlock_irqrestore(data_lock, flags);
return 0;
+ }
+
+ spin_unlock_irqrestore(data_lock, flags);
r = dispc_runtime_get();
if (r)
@@ -442,10 +448,8 @@ int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
irq = dispc_mgr_get_vsync_irq(mgr-id);
- mp = get_mgr_priv(mgr);
i = 0;
while (1) {
- unsigned long flags;
bool shadow_dirty, dirty;
spin_lock_irqsave(data_lock, flags);
@@ -489,21 +493,28 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
{
unsigned long timeout = msecs_to_jiffies(500);
struct ovl_priv_data *op;
- struct omap_dss_device *dssdev;
+ struct mgr_priv_data *mp;
u32 irq;
+ unsigned long flags;
int r;
int i;
if (!ovl-manager)
return 0;
- dssdev = ovl-manager-device;
+ mp = get_mgr_priv(ovl-manager);
- if (!dssdev || dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ if (ovl_manual_update(ovl))
return 0;
- if (ovl_manual_update(ovl))
+ spin_lock_irqsave(data_lock, flags);
+
+ if (!mp-enabled) {
+ spin_unlock_irqrestore(data_lock, flags);
return 0;
+ }
+
+ spin_unlock_irqrestore(data_lock, flags);
r = dispc_runtime_get();
if (r)
@@ -514,7 +525,6 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
op = get_ovl_priv(ovl);
i = 0;
while (1) {
- unsigned long flags;
bool shadow_dirty, dirty;
spin_lock_irqsave(data_lock, flags);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAPDSS: Remove unnecessary acb/acbi pin fields from omap_dss_device
Passive matrix support was removed recently. The acb and acbi pin declarations
in omap_dss_device struct weren't removed by accident. Remove these fields
from omap_dss_device.
Signed-off-by: Archit Taneja arc...@ti.com
---
include/video/omapdss.h |4
1 file changed, 4 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index b868123..bc686f4 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -558,10 +558,6 @@ struct omap_dss_device {
struct {
struct omap_video_timings timings;
- int acbi; /* ac-bias pin transitions per interrupt */
- /* Unit: line clocks */
- int acb;/* ac-bias pin frequency */
-
enum omap_dss_dsi_pixel_format dsi_pix_fmt;
enum omap_dss_dsi_mode dsi_mode;
struct omap_dss_dsi_videomode_timings dsi_vm_timings;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
Hi Guys, On 08/17/2012 11:58 AM, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120817 02:51]: On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]: On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]: Somehow we have to have some mechanism to initialize _mpu_rt_va before core_init call, which will take DT resources and initialize accordingly. That's for the device reset/idle? We should not do that in hwmod code except in late_initcall for unclaimed devices as discussed earlier. We discussed setting up the reset function in the device specific headers so both device and hwmod code can call them as needed. May be I didn't understand your above statement, can you please elaborate more on device specific header file? We should have the device drivers idle and reset the devices. But also hwmod may need to do that for the unclaimed devices for PM to work. As the driver may not be even compiled in, the driver specific reset and idle functions should be static inline functions in the device specific header file so hwmod code can still call those. How about mapping the address of the devices? That should be done based on the iorange coming from DT during the driver probe. The range in hwmod can be populated at that point too if needed. Some more thoughts on the similar line on unclaimed devices - As par of late_initcall(), traverse all the DTB nodes and for each node with state = disabled, we can do something like, Late_initcall() - Traverse DTB nodes and check for state = disabled - Read the ti,hwmod entry and get offsets like, sys_config and reset. - Map the base address - Enable the module/clock - Reset the device - Write to sysc register offset - Disable the module/clock Just to highlight, its not only during late_initcall, the _enable and _idle functions are getting executed as part of every runtime_pm_get\put_sync from the driver. Heh, but the unclaimed devices do not have a driver :) So there's no runtime_pm calls for the unclaimed devicdes. At the current stage, I really think it would be really nice and beneficial for driver developers from the community if they get Linux Boot from linux-next/master branch. I have seen lot of community folks are struggling with it and they are blocked because we do not have booting kernel on BeagleBone. They always end up patching kernel with HWMOD patch and submit the driver patches. So request to consider this cleanup as sequential patch on top of original HWMOD patch? Yes I'm fine merging the data as is, just trying to figure out how to sort out the issues for future. May be get rid of resource overwriting for AM33xx and OMAP5 alone as of now?? Sorry I don't follow this part, care to explain a little more? As per current implementation, we are using HWMOD information to fill the platform_device-resources. Even if you pass reg and interrupt property from DT, omap_device layer overwrites it with HWMOD data information. So what I am trying to propose here is, avoid this overwrite and resources (address and interrupt) should strictly gets used from DT blob. Since AM33xx and OMAP5 devices are the new devices and supports DT boot only, we can implement it easily for them. Yes I agree. And then we should also drop the data from hwmod when it's no longer needed. Only issue her is, DMA resources, I was going through some of the old email archives today, submitted by Benoit and later Jon, but I am still not sure how to pass dma_channel to driver as a resource. Hmm I thought that got merged already? No, it is still under discussion. I don't even know why they are still arguing, but there are still a lot of discussion on that thread. Anyways, the iorange and interrupts are standard resources that should exist in every device entry in .dts files. Yeah, I wanted to avoid that to make things simpler. As soon as we have the DMA we can switch easily to DT resource. My other concern is that so far we still have to duplicate the io space address with the way the hwmod is initializing the syscofig today. So it will require some change in that part to make an effective use of DT. So point is that if we start using that mechanism for DT boot, we will still have to keep the legacy one for non DT boot. Nothing is impossible, but that's still a lot of work before having something useful. The idea was to stop iterating the hwmods early and init the hwmod only during device probe or late_initcall for the one that will not probe. Again, easy with DT, less straighforward for non-DT boot. 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
Re: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
Hi Vaibhav,
On 08/17/2012 11:51 AM, Hiremath, Vaibhav wrote:
On Fri, Aug 17, 2012 at 14:10:47, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120817 01:22]:
On Fri, Aug 17, 2012 at 13:19:34, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120815 02:11]:
Somehow we have to have some mechanism to initialize _mpu_rt_va before
core_init call, which will take DT resources and initialize accordingly.
That's for the device reset/idle? We should not do that in hwmod code
except in late_initcall for unclaimed devices as discussed earlier. We
discussed setting up the reset function in the device specific headers
so both device and hwmod code can call them as needed.
May be I didn't understand your above statement, can you please elaborate
more on device specific header file?
We should have the device drivers idle and reset the devices. But also
hwmod may need to do that for the unclaimed devices for PM to work.
As the driver may not be even compiled in, the driver specific reset and
idle functions should be static inline functions in the device specific
header file so hwmod code can still call those.
How about mapping the address of the devices?
Some more thoughts on the similar line on unclaimed devices -
As par of late_initcall(), traverse all the DTB nodes and for each node with
state = disabled, we can do something like,
Yes, in fact we should duplicate the same mechanism that will be used to
init a regular device during probe.
Late_initcall()
- Traverse DTB nodes and check for state = disabled
- Read the ti,hwmod entry and get offsets like, sys_config
and reset.
- Map the base address
- Enable the module/clock
- Reset the device
- Write to sysc register offset
- Disable the module/clock
Just to highlight, its not only during late_initcall, the _enable and _idle
functions are getting executed as part of every runtime_pm_get\put_sync
from
the driver.
Right, so no need to initialize those until at driver probe time.
Agreed.
Are you saying as part of late_initcall, we should initialize _mpu_rt_va
of struct omap_hwmod???
I guess either at driver probe for the claimed devices, or at late_initcall
for the unclaimeded devices.
Also, as far unclaimed resources is concerned, somewhere you should have
base addr of the device maintained, right? Currently, hwmod is maintaining
this data and the execution goes something like,
Core_initcall()
- _setup()
- _setup_reset()
- _idle()
For the DT only case also the unclaimed devices can from DT with
status = disabled.
Another biggest worry is, if I play here, it may break existing omap3/4
Functionality, especially may impact from PM perspective. So I believe, we
need to have something which adds/cleans-up things in stages.
It seems that we need three stages: Something early for the timers only,
initialize most things during driver probe, then late_initcall for the
unclaimed devices.
Most likely yes, or it may even get into more stages.
At the current stage, I really think it would be really nice and beneficial
for driver developers from the community if they get Linux Boot from
linux-next/master branch. I have seen lot of community folks are struggling
with it and they are blocked because we do not have booting kernel on
BeagleBone.
They always end up patching kernel with HWMOD patch and submit the driver
patches. So request to consider this cleanup as sequential patch on top of
original HWMOD patch?
May be get rid of resource overwriting for AM33xx and OMAP5 alone as of
now??
Sorry I don't follow this part, care to explain a little more?
As per current implementation, we are using HWMOD information to fill the
platform_device-resources. Even if you pass reg and interrupt property
from DT, omap_device layer overwrites it with HWMOD data information.
So what I am trying to propose here is, avoid this overwrite and resources
(address and interrupt) should strictly gets used from DT blob. Since AM33xx
and OMAP5 devices are the new devices and supports DT boot only, we can
implement it easily for them.
Well, the point is that that mechanism is still common to OMAP2+
devices, so the tricky part is that a legacy mode will still be needed.
Only issue her is, DMA resources, I was going through some of the old email
archives today, submitted by Benoit and later Jon, but I am still not sure
how to pass dma_channel to driver as a resource.
There is no way currently :-(.
Below logic works for me, I have tested it on both BeagleBone and AM37xEVM -
omap_device_alloc ()
{
...
res_count = omap_device_count_resources(od);
if (res_count pdev-num_resources) {
res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
if (!res)
Re: [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On 08/17/2012 12:32 AM, Hiremath, Vaibhav wrote:
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
On 7/14/2012 3:56 AM, Jon Hunter wrote:
OMAP3 devices may or may not have security features enabled. Security
enabled
devices are known as high-secure (HS) and devices without security are
known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for secure usage and so cannot be used
by
the kernel, where as for a GP device it is available. We can detect the
OMAP
device type, secure or GP, at runtime via an on-chip register. Today, when
not
using DT, we do not register the 12th timer as a linux device if the
device is
secure.
When using device tree, device tree is going to register all the timer
devices
it finds in the device tree blob. To prevent device tree from registering
12th
timer on a secure OMAP3 device we can add a status property to the timer
binding with the value disabled at boot time. Note that timer 12 on a
OMAP3
device has a property ti,timer-secure to indicate that it will not be
available on a secure device and so for secure OMAP3 devices, we search for
timers with this property and then disable them. Using the
prom_add_property()
function to dynamically add a property was a recommended approach
suggested by
Rob Herring [1].
I have tested this on an OMAP3 GP device and faking it to pretend to be a
secure device to ensure that any timers marked with ti,timer-secure are
not
registered on boot. I have also made sure that all timers are registered as
expected on a GP device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 36
+++
3 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..20124d7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
+ omap_dmtimer_init();
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 1f65b18..d6a4875 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 13d20c8..e3b9931 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include linux/clocksource.h
#include linux/clockchips.h
#include linux/slab.h
+#include linux/of.h
#include asm/mach/time.h
#include plat/dmtimer.h
@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
}
arch_initcall(omap2_dm_timer_init);
+static struct property timer_disabled = {
+ .name = status,
+ .length = sizeof(disabled),
+ .value = disabled,
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+ { .compatible = ti,omap3-timer, },
+ { }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type timer-secure cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the
device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+ struct device_node *np;
+
+ if (!cpu_is_omap34xx())
+ return;
+
Sorry for responding so late, but why only omap34xx check here?
Isn't this applicable to all omap non-omap devices?
It is only applicable to omap3 devices as far as omap is concerned.
By non-omap, you are referring to the AMxxx stuff?
Do AMxxx devices even support security (ie. secure boot and have secure
peripherals)? If not then this will work for AMxxx devices too.
Yes it does.
AM33xx has 8 timers and Timer-0 is a secure timer. As in case of OMAP3, we
do not even register timer-0 to kernel.
Ok, however, please note that the omap3 timer 12 is a special case,
because on a non-secure device it is available for general purpose use
and only reserved for secure use on a secure device.
For omap4/5 timer 12 is always a secure
Re: OMAP HWMOD: Query regarding parent-child support
Hi Vaibhav, On 08/17/2012 12:12 PM, Vaibhav Hiremath wrote: On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote: Hi All, Paul, From last couple of days I am almost spending my whole time trying to get to somewhere on below issue and based on my understanding and learning so far I started feeling that, probably we might have made wrong decision to remove all leaf-nodes from the clock-tree. Instead we should have it removed from hwmod. :) Let's take a example of PWM Module (which is the context of my debugging) - As I mentioned before, PWM module present in AM33XX looks something like - -- | | | | PWMSS | | | | | --- - | | | eCAP | | ePWM | | eQEP | | | --- - | -- PWMSS: This actually controls all PM related signals like idle, standby, etc... eCAP/ePWM/eQEP: Technically it is independent module, reused from Davinci devices and is implemented as independent drivers in kernel. In case of AM33xx, the basic resources like, clock, idle signal and standby signal are abstracted at PWMSS level. This means the core IP (eCAP/ePWM/eQEP) have not changed from their original implementation. These core IP's (eCAP/ePWM/eQEP) are being used in Davinci family of devices, but without encapsulation of PWMSS, unlike AM33XX. This means, each module has its own clock enable/disable control mechanism and there is no dependency between them, unlike AM33XX. Options to support: 1. Use existing Clock Framework infrastructure to handle, which basically supports clock enable/disable function based on usecount and parent-child relation. Driver will simply work, without knowing anything about underneath platform, which is what expected. So create a dummy-clocks for submodules, making PWMSS clock as a parent will solve the issue here. And nothing wrong here, we are just treating, clock-enable = module-enable Yeah, but that looks like a hack to me. That clock hierarchy does not exist for real and the pm_runtime infrastructure can handle that properly. In that case you do have a PM dependency and not necessarily a clock dependency. The only issue here is sysconf register access at hwmod level, if you leave sysconf idle and standby configuration at smart state, it works properly. I have validated it at my end. 2. MFD Driver: I think it will be miss-use of MFD driver and should be explored at all. I do think this is the proper use of MFD. In fact with DT, you don't even need an MFD. The DT nodes hierarchy will create the parent-child link automatically. pm_runtime events are taking care of the parent state. It means that if you are enabling a child, the parent will be enabled first automatically by the PM fmwk. This is how the DSS will/was be modified to handle the similar issue you are facing today. I'm not sure that code is upstream yet, but was tested on OMAP5. The only drawback in your case is that the Davinci drivers must be pm_runtime adapted, which might not be the case already :-(. Regards, Benoit I certainly vote for option-1. Paul, if you agree with me, I will submit the patch for option-1. NOTE: Same thing is applicable for CPSW driver, where two independent drivers (MDIO and CPSW) share common clock and needs similar fix. Thanks, Vaibhav During migration to run-time PM we came across unique (I believe) issue with respect to CPSW driver and eHRPWM. I am looking for pointers to handle these use-cases, as I am still going through the code and trying to understand myself on how can we handle this. CPSW: = CPSW Subsystem is built with 5 sub-modules, - CPSW SS (BaseAddr@0x4A10, rst@0x8) - MDIO (BaseAddr@0x4A101000) - CPSW WR (0x4A101200, rst@0x4) - CPSW SL1 (0x4A100D80, rst@0xc) - CPSW SL2 (0x4A100DC0, rst@0xc) - CPSW CPDMA (0x4A100800, rst@0x1c) Issue1: --- IP's are reused from legacy devices, for example, we have 2 separate platform driver for MDIO and cpsw, used between Davinci and AM335x. Everything is controlled through one MODULEMODE register in PRCM. So now we have 2 different modules accessing same resources (CLKCTRL.MODULEMODE), it is tricky to handle this usecase. Earlier with clock api's, it was easy, since clock framework used to handle ref_count for this and was sufficient here but with migration to runtime PM, we no longer use clk api's. Option1: It must be handled at driver level, and there will be handshaking between both the drivers. Which might impact legacy devices. Option2: It must be handled at SoC level, and parent and child creation is required here. parent-child creation is possible with platform
Re: [PATCH 2/3] OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions
On Fri, 2012-08-17 at 16:19 +0530, Archit Taneja wrote:
The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if
there
is an enabled display connected to the manager before trying to see the state
of
the GO bit.
The checks related to the display can be replaced by checking the state of the
manager, i.e, whether the manager is enabled or not. This makes more sense
than
checking with the connected display as the GO bit behaviour is more connected
with the manager state rather than the display state. A GO bit can only be set
if the manager is enabled. If a manager isn't enabled, we can safely assume
that
the GO bit is not set.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 52a5940..74f1a58 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -424,17 +424,23 @@ static void wait_pending_extra_info_updates(void)
int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
{
unsigned long timeout = msecs_to_jiffies(500);
- struct mgr_priv_data *mp;
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
u32 irq;
+ unsigned long flags;
int r;
int i;
- struct omap_dss_device *dssdev = mgr-device;
- if (!dssdev || dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ if (mgr_manual_update(mgr))
This needs to be inside the spinlock also.
return 0;
- if (mgr_manual_update(mgr))
+ spin_lock_irqsave(data_lock, flags);
+
+ if (!mp-enabled) {
+ spin_unlock_irqrestore(data_lock, flags);
return 0;
+ }
+
+ spin_unlock_irqrestore(data_lock, flags);
r = dispc_runtime_get();
if (r)
@@ -442,10 +448,8 @@ int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
irq = dispc_mgr_get_vsync_irq(mgr-id);
- mp = get_mgr_priv(mgr);
i = 0;
while (1) {
- unsigned long flags;
bool shadow_dirty, dirty;
spin_lock_irqsave(data_lock, flags);
@@ -489,21 +493,28 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
{
unsigned long timeout = msecs_to_jiffies(500);
struct ovl_priv_data *op;
- struct omap_dss_device *dssdev;
+ struct mgr_priv_data *mp;
u32 irq;
+ unsigned long flags;
int r;
int i;
if (!ovl-manager)
return 0;
And this should be inside spinlock (yes, you didn't change that, but now
that you're changing these... =)
- dssdev = ovl-manager-device;
+ mp = get_mgr_priv(ovl-manager);
- if (!dssdev || dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ if (ovl_manual_update(ovl))
Inside spinlock here too.
Actually, shouldn't the whole wait_for functions be locked with the
apply mutex? Otherwise the output can be disabled/changed while waiting.
On the other hand, that could be quite a long lock, and I don't see
anything in the code that could really break if the output is disabled
or similar. Perhaps it's fine to just hit the timeout in case something
has been changed. If we add a mutex, we risk breaking something that
currently works =).
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v3 1/9] ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: Move the McBSP CLKS re-parenting code to ASoC driver from arch/arm/mach-omap2. The call fort the re-parenting has been already limited to OMAP2+ SoC in the ASoC driver. There is no longer need to have callback function for it. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]:
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/mcbsp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index ebc801e..6e046e1 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -151,7 +151,10 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
if (id == 4 oh-class-rev == MCBSP_CONFIG_TYPE4)
pdata-mux_signal = omap4_mcbsp4_mux_rx_clk;
- if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
+ if (oh-class-rev == MCBSP_CONFIG_TYPE2) {
+ /* The FIFO has 128 locations */
+ pdata-buffer_size = 0x80;
+ } else if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
/* The FIFO has 1024 + 256 locations */
pdata-buffer_size = 0x500;
Is this the case also for 2420? I thought some only had a FIFO at
one port?
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] ARM: OMAP: board-am3517evm: Configure McBSP1 CLKR/FSR signal source
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: am3517evm board uses McBSP1 for audio with 4pin configuration. The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in this case. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/9] ASoC: am3517evm: Do not configure McBSP1 CLKR/FSR signal muxing
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: The muxing is done at board level, no need to do it in the ASoC machine driver. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/9] ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin configuration. When moving to devicetree these callback can no longer be used in a clean way anymore. If a board require to change the 6pin port to work in 4pin setup it needs to set up the mux in the board file. For OMAP2/3: u32 devconf0; /* McBSP1 CLKR/FSR signal to be connected to CLKX/FSX pin */ devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0); devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK; omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0); For OMAP4: u32 mcbsp_pad; /* McBSP4 CLKR/FSR signal to be connected to CLKX/FSX pin */ mcbsp_pad = omap4_ctrl_pad_readl(OMAP2_CONTROL_DEVCONF0); mcbsp_pad |= ((1 31) | (1 30)); omap4_ctrl_pad_writel(mcbsp_pad, OMAP2_CONTROL_DEVCONF0); In case when the kernel is booted with DT blob the pinctrl-single will be provided as soon as it is enabled on the platform. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 8/9] ARM: OMAP2+: McBSP: Do not create legacy devices when booting with DT data
* Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: Only create the devices in a legacy way if we do not have the DT data. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] ARM/ASoC: OMAP McBSP device tree support
* Mark Brown broo...@opensource.wolfsonmicro.com [120817 03:18]: On Thu, Aug 16, 2012 at 04:40:59PM +0300, Peter Ujfalusi wrote: in order to be able to add DT support for the McBSP driver which is used on all OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack: Tony, are you OK with these changes going via ASoC? Yes, had one 2420 related question about the FIFO, other than that I've acked the omap related patches. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430
On 08/17/2012 04:07 PM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of the FIFO for the audio stack. Is this the case also for 2420? I thought some only had a FIFO at one port? IRCC (I don't have specs), nope. Only 2430 (as noted by Peter) and onwards have FIFO. But that's true that FIFO sizes differ between the ports. E.g. only ports 2 and 3 have 1024+128 deep FIFOs in OMAP3. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
On Thu, 2012-08-16 at 16:48 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dss_init_features function providing
a
much more generic and cleaner interface. The OMAP version and revision
specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
+static int __init dss_init_features(struct device *dev)
+{
+ dss.feat = devm_kzalloc(dev, sizeof(*dss.feat), GFP_KERNEL);
+ if (!dss.feat) {
+ dev_err(dev, Failed to allocate local DSS Features\n);
+ return -ENOMEM;
+ }
+
+ if (cpu_is_omap24xx())
+ dss.feat = omap24xx_dss_features;
+ else if (cpu_is_omap34xx())
+ dss.feat = omap34xx_dss_features;
+ else if (cpu_is_omap3630())
+ dss.feat = omap3630_dss_features;
+ else if (cpu_is_omap44xx())
+ dss.feat = omap44xx_dss_features;
+ else
+ return -ENODEV;
+
+ return 0;
+}
This is not correct (and same problem in dispc). You allocate the feat
struct and assign the pointer to dss.feat, but then overwrite dss.feat
pointer with the pointer to omap24xx_dss_features (which is freed
later). You need to memcpy it.
I also get a crash on omap3 overo board when loading omapdss:
loading nfs/work/linux/drivers/video/omap2/dss/omapdss.ko debug=y def_disp=lcd43
[ 20.411224] Unable to handle kernel NULL pointer dereference at virtual
address 0008
[ 20.419921] pgd = ce8a8000
[ 20.422790] [0008] *pgd=8e8c5831, *pte=, *ppte=
[ 20.429473] Internal error: Oops: 17 [#1] SMP ARM
[ 20.434448] Modules linked in: omapdss(+)
[ 20.438690] CPU: 0Tainted: GW (3.5.0-rc2-00058-g1c1e55c #93)
[ 20.446350] PC is at omap_dsshw_probe+0xa4/0x290 [omapdss]
[ 20.452148] LR is at 0x2e39
[ 20.455108] pc : [bf043288]lr : [2e39]psr: 8013
[ 20.455108] sp : ce89ddd0 ip : c0b797e0 fp : 6133
[ 20.467224] r10: 0028 r9 : c0c5c07c r8 : bf02eadc
[ 20.472717] r7 : r6 : c06e9644 r5 : cf0cf808 r4 : bf02f430
[ 20.479614] r3 : cf0cf808 r2 : r1 : r0 :
[ 20.486511] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 20.494049] Control: 10c5387d Table: 8e8a8019 DAC: 0015
[ 20.500091] Process insmod (pid: 664, stack limit = 0xce89c2f8)
[ 20.506347] Stack: (0xce89ddd0 to 0xce89e000)
[ 20.510955] ddc0: cf0cf808 c0c96ed8
c0c96ee8 c02c22e4
[ 20.519592] dde0: c02c22cc c02c0f28 cf0cf808 bf02eadc cf0cf83c
0001
[ 20.528198] de00: 0028 c02c113c bf02eadc c02c10a8 c02bf6c8
cf0192a8 cf0cec10
[ 20.536834] de20: bf02eadc c072fab8 cf3e7440 c02c05dc bf0249e0
cf04ce40 bf02eadc
[ 20.545471] de40: c0748880 ce89c000 0001 c0c5c07c 0028
6133 c02c1670
[ 20.554107] de60: bf02eac8 c0748880 ce89c000 0001
0028 c02c26e0
[ 20.562744] de80: 0003 c0748880 bf043124 c0748880
ce89c000
[ 20.571380] dea0: 0001 c0008730 bf02f29c 0001 0001 bf0430cc
c071bcd0
[ 20.580017] dec0: bf02f29c c006823c ce827ec0 cf0001c0
bf02f29c 0001
[ 20.588623] dee0: ce851480 0001 c0c5c07c 0028 6133 c0099d20
bf02f2a8 7fff
[ 20.597259] df00: c0098aa4 c012480c c0098890 bf02f3f0 ce89c000
c06d32d8 d08fe09c
[ 20.605895] df20: d0a19624 000a7008 d08ce000 001f2ab7 d0a18bd4 d0a18948
d0aba984 00030ed0
[ 20.614532] df40: 0003b0e0 0042 0043 0026
002a 0014
[ 20.623138] df60: bf022024 0043
c0623b14
[ 20.631774] df80: 001f2ab7 001f2ab7 0004 beb48e7c 0080 c0013f28
ce89c000
[ 20.640411] dfa0: c0013d60 001f2ab7 0004 b6c49008 001f2ab7
000a7008 beb48e7c
[ 20.649047] dfc0: 001f2ab7 0004 beb48e7c 0080 000a47f8
b6f8
[ 20.657684] dfe0: beb48bb8 beb48ba8 00019dfc b6f10020 6010 b6c49008
[ 20.666442] [bf043288] (omap_dsshw_probe+0xa4/0x290 [omapdss]) from
[c02c22e4] (platform_drv_
probe+0x18/0x1c)
[ 20.677276] [c02c22e4] (platform_drv_probe+0x18/0x1c) from [c02c0f28]
(driver_probe_device+0x
9c/0x21c)
[ 20.687499] [c02c0f28] (driver_probe_device+0x9c/0x21c) from [c02c113c]
(__driver_attach+0x94
/0x98)
[ 20.697418] [c02c113c] (__driver_attach+0x94/0x98) from [c02bf6c8]
(bus_for_each_dev+0x50/0x7
c)
[ 20.706970] [c02bf6c8] (bus_for_each_dev+0x50/0x7c) from [c02c05dc]
(bus_add_driver+0xa0/0x2a
8)
[ 20.716522] [c02c05dc] (bus_add_driver+0xa0/0x2a8) from [c02c1670]
(driver_register+0x78/0x17
4)
[ 20.726074] [c02c1670] (driver_register+0x78/0x174) from [c02c26e0]
(platform_driver_probe+0x
18/0x9c)
[ 20.736267] [c02c26e0]
Re: [PATCH v3 2/9] ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430
On 08/17/2012 04:14 PM, Jarkko Nikula wrote: On 08/17/2012 04:07 PM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [120816 06:41]: On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of the FIFO for the audio stack. Is this the case also for 2420? I thought some only had a FIFO at one port? IRCC (I don't have specs), nope. Only 2430 (as noted by Peter) and onwards have FIFO. But that's true that FIFO sizes differ between the ports. E.g. only ports 2 and 3 have 1024+128 deep FIFOs in OMAP3. OMAP2420 McBSP does not have FIFO (the IP is closer to OMAP1 McBSP). OMAP2430, OMAP4, OMAP5 has 128 word long FIFO on all McBSP ports. On OMAP3: McBSP2 have 1024+256 (1280) word FIFO the rest of the ports have 128 long FIFO. -- Péter -- 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: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Afzal,
Sorry for the delay, I have been out of the office.
On 08/06/2012 08:38 AM, Mohammed, Afzal wrote:
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required by the retime
function or gpmc timings themselves if available. In the case of OneNAND
These can be stored in the DT and then translated to gpmc timings at
runtime. DT should only store static timing or clock information known
Yup. And the format of the timing data in DT should be standardized so
the only differences for each connected peripheral is the retime function.
If we are able to achieve a generic retime function applicable to all
peripherals then we don't need wrapper layer for retime handling or two
linux devices and drivers (one the existing and the other to handle retime)
to represent a single physical gpmc peripheral device (for DT conversion).
Then handling core frequency scaling and DT conversion would be easier.
We were trying to create such a retime function that would be generic so
as to handle different types of gpmc peripherals.
Sounds like a much better approach!
And we have been able to create such a function. Below is an implementation
that has been made for handling asynchronous timings. It has been tested for
OneNAND SMSC on OMAP3EVM (rev G C) with [1-4]. OneNAND was tested using
[5] (OMAP3EVM OneNAND works in async mode) SMSC using [6] (mainline does
not have a timing calculation for smsc911x)
Are you able to verify that the timing calculated by this function are
identical? May be some more details on exactly how you tested this would
be good.
It was difficult to squeeze tusb6010 timing calculation into generic timing
calculation, hence a boolean tusb has been used. This is what I could
achieve based on existing retime for tusb6010 and for lack of tusb6010
timing specifications.
8---
/* Device timings in picoseconds */
struct gpmc_device_timings {
u32 cs_setup; /* CS setup time */
u32 adv_setup; /* ADV setup time */
u32 adv_rd_off; /* ADV read off time */
u32 adv_add_hold; /* address hold time */
u32 oe_setup; /* OE setup time */
u32 adv_access; /* access time from ADV assertion */
u32 rd_access; /* read access time */
u32 oe_access; /* access time from OE assertion */
u32 cs_access; /* access time from CS asertion */
u32 rd_cycle; /* read cycle time */
u32 cs_highz; /* CS deassertion to high Z */
u32 oe_highz; /* OE deassertion to high Z */
u32 adv_wr_off; /* ADV write off time */
u32 we_setup; /* WE setup time */
u32 wr_pulse; /* write assertion time */
u32 wr_data_setup; /* data setup time from write assertion */
u32 wr_high;/* write deassertion time */
u32 we_highz; /* WE deassertion to high Z */
u32 wr_cycle; /* write cycle time */
boolmux;/* address data muxed */
booltusb; /* peripheral is tusb6010 */
Do you think that there is any value in making the tusb member a u32
dev_type and then set it too GPMC_DEVICE_TUSB then this could be used
for other devices in the future too if needed?
};
struct gpmc_timings gpmc_calc_timings(struct gpmc_device_timings *dev_t)
{
struct gpmc_timings gpmc_t;
bool mux = dev_t-mux;
bool tusb = dev_t-tusb;
u32 temp;
memset(gpmc_t, 0, sizeof(gpmc_t));
/* cs_on */
gpmc_t.cs_on = gpmc_round_ns_to_ticks(dev_t-cs_setup / 1000);
/* adv_on */
temp = dev_t-adv_setup;
if (tusb)
temp = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000, temp);
gpmc_t.adv_on = gpmc_round_ns_to_ticks(temp / 1000);
Would it be possible to create a sub-function called
gpmc_calc_timings_tusb() and put all these if (tusb) statements in
there? Or maybe a generic function called gpmc_calc_timings_prepare().
For the above case could have ...
void gpmc_calc_timings_prepare(struct gpmc_device_timings *dev_t)
{
if (dev_t-tusb) {
dev_t-adv_on = max_t(u32,
(gpmc_t.cs_on + gpmc_ticks_to_ns(1)) * 1000,
dev_t-adv_setup);
...
} else {
dev_t-adv_on = dev_t-adv_setup;
...
}
}
And then in the gpmc_calc_timings() you would just have ...
gpmc_t.adv_on = gpmc_round_ns_to_ticks(dev_t-adv_on / 1000);
/* adv_rd_off */
temp = dev_t-adv_rd_off;
if (tusb)
temp = max_t(u32,
[PATCH 1/1] Config fix for omap3-touchbook board
Fix inconsistency between mach-types and CONFIG_ name that prevents touchbook board from booting. Signed-off-by: Radek Pilar mr...@mrkva.eu diff -ur linux-3.5.1/arch/arm/mach-omap2/Kconfig linux-3.5.1-mrkva/arch/arm/mach-omap2/Kconfig --- linux-3.5.1/arch/arm/mach-omap2/Kconfig 2012-08-09 17:23:56.0 +0200 +++ linux-3.5.1-mrkva/arch/arm/mach-omap2/Kconfig 2012-08-14 13:48:27.0 +0200 @@ -215,10 +215,11 @@ select OMAP_PACKAGE_CBB select REGULATOR_FIXED_VOLTAGE if REGULATOR -config MACH_OMAP3_TOUCHBOOK +config MACH_TOUCHBOOK bool OMAP3 Touch Book depends on ARCH_OMAP3 default y + select OMAP_PACKAGE_CBB config MACH_OMAP_3430SDP bool OMAP 3430 SDP board diff -ur linux-3.5.1/arch/arm/mach-omap2/Makefile linux-3.5.1-mrkva/arch/arm/mach-omap2/Makefile --- linux-3.5.1/arch/arm/mach-omap2/Makefile2012-08-09 17:23:56.0 +0200 +++ linux-3.5.1-mrkva/arch/arm/mach-omap2/Makefile 2012-08-14 13:48:13.0 +0200 @@ -221,7 +221,7 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o -obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o +obj-$(CONFIG_MACH_TOUCHBOOK) += board-omap3touchbook.o obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o 0xE60DBF0D.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[PATCH] omap-hsmmc: Implementation of i761 errata
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.
Workaround:
After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at
the same position in the response MMCHS_RSP10[i] is set to 1, the host
controller indicates a card error and software should proceed in the same way
as if a CERR interrupt would have been detected in the MMCHS_STAT register.
Note:
This errata is applicable for omap44xx.
Signed-off-by: Semen Protsenko semen.protse...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 3a09f93..17803de 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -34,6 +34,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/card.h
#include linux/io.h
#include linux/semaphore.h
#include linux/gpio.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
+#define OMAP_HSMMC_CSRE0x0024
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -117,6 +119,9 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+/* Errata definitions */
+#define OMAP_HSMMC_ERRATA_I761 BIT(0)
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -177,6 +182,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned interrata;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -857,6 +863,23 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
omap_hsmmc_start_command(host, data-stop, NULL);
}
+static int
+omap_hsmmc_errata_i761(struct omap_hsmmc_host *host, struct mmc_command *cmd)
+{
+ u32 rsp10, csre;
+
+ if ((cmd-flags MMC_RSP_R1) == MMC_RSP_R1
+ || (host-mmc-card (mmc_card_sd(host-mmc-card)
+ || mmc_card_sdio(host-mmc-card))
+(cmd-flags MMC_RSP_R5))) {
+ rsp10 = OMAP_HSMMC_READ(host-base, RSP10);
+ csre = OMAP_HSMMC_READ(host-base, CSRE);
+ return rsp10 csre;
+ }
+
+ return 0;
+}
+
/*
* Notify the core about command completion
*/
@@ -1046,6 +1069,17 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
+ /* Errata i761 */
+ if ((host-errata OMAP_HSMMC_ERRATA_I761) host-cmd
+omap_hsmmc_errata_i761(host, host-cmd)) {
+ /* Do the same as for CARD_ERR case */
+ dev_dbg(mmc_dev(host-mmc), Ignoring card err CMD%d\n,
+ host-cmd-opcode);
+ end_cmd = 1;
+ if (host-data)
+ end_trans = 1;
+ }
+
OMAP_HSMMC_WRITE(host-base, STAT, status);
if (end_cmd || ((status CC) host-cmd))
@@ -1829,6 +1863,10 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
host-power_mode = MMC_POWER_OFF;
host-next_data.cookie = 1;
+ host-errata = 0;
+ if (cpu_is_omap44xx())
+ host-errata |= OMAP_HSMMC_ERRATA_I761;
+
platform_set_drvdata(pdev, host);
mmc-ops= omap_hsmmc_ops;
--
1.7.10.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] omap-hsmmc: Implementation of i761 errata
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com wrote:
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.
Workaround:
After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at
the same position in the response MMCHS_RSP10[i] is set to 1, the host
controller indicates a card error and software should proceed in the same way
as if a CERR interrupt would have been detected in the MMCHS_STAT register.
Note:
This errata is applicable for omap44xx.
Signed-off-by: Semen Protsenko semen.protse...@ti.com
The implementation looks fine, but can we simply not set the errata
flag and make this as default
behaviour ? I suppose the documented behaviour with CSRE and RSP10 is
independent of the
errata..
Also, please send it to the linux-mmc list as well.
---
drivers/mmc/host/omap_hsmmc.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 3a09f93..17803de 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -34,6 +34,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/card.h
#include linux/io.h
#include linux/semaphore.h
#include linux/gpio.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
+#define OMAP_HSMMC_CSRE0x0024
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -117,6 +119,9 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+/* Errata definitions */
+#define OMAP_HSMMC_ERRATA_I761 BIT(0)
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -177,6 +182,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned interrata;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -857,6 +863,23 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
omap_hsmmc_start_command(host, data-stop, NULL);
}
+static int
+omap_hsmmc_errata_i761(struct omap_hsmmc_host *host, struct mmc_command *cmd)
+{
+ u32 rsp10, csre;
+
+ if ((cmd-flags MMC_RSP_R1) == MMC_RSP_R1
+ || (host-mmc-card (mmc_card_sd(host-mmc-card)
+ || mmc_card_sdio(host-mmc-card))
+(cmd-flags MMC_RSP_R5))) {
+ rsp10 = OMAP_HSMMC_READ(host-base, RSP10);
+ csre = OMAP_HSMMC_READ(host-base, CSRE);
+ return rsp10 csre;
+ }
+
+ return 0;
+}
+
/*
* Notify the core about command completion
*/
@@ -1046,6 +1069,17 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
+ /* Errata i761 */
+ if ((host-errata OMAP_HSMMC_ERRATA_I761) host-cmd
+omap_hsmmc_errata_i761(host, host-cmd)) {
+ /* Do the same as for CARD_ERR case */
+ dev_dbg(mmc_dev(host-mmc), Ignoring card err CMD%d\n,
+ host-cmd-opcode);
+ end_cmd = 1;
+ if (host-data)
+ end_trans = 1;
+ }
+
OMAP_HSMMC_WRITE(host-base, STAT, status);
if (end_cmd || ((status CC) host-cmd))
@@ -1829,6 +1863,10 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
host-power_mode = MMC_POWER_OFF;
host-next_data.cookie = 1;
+ host-errata = 0;
+ if (cpu_is_omap44xx())
+ host-errata |= OMAP_HSMMC_ERRATA_I761;
+
platform_set_drvdata(pdev, host);
mmc-ops= omap_hsmmc_ops;
--
1.7.10.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] omap-hsmmc: Implementation of i761 errata
On Fri, Aug 17, 2012 at 12:28 PM, S, Venkatraman svenk...@ti.com wrote:
On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com
wrote:
Errata description:
Due to a bad behavior of an internal signal, the Card Error interrupt bit
MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the
card response.
Workaround:
After responses of type R1/R1b for all cards and responses of type R5/R5b/R6
for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and
MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at
the same position in the response MMCHS_RSP10[i] is set to 1, the host
controller indicates a card error and software should proceed in the same way
as if a CERR interrupt would have been detected in the MMCHS_STAT register.
Note:
This errata is applicable for omap44xx.
Signed-off-by: Semen Protsenko semen.protse...@ti.com
The implementation looks fine, but can we simply not set the errata
flag and make this as default
behaviour ? I suppose the documented behaviour with CSRE and RSP10 is
independent of the
errata..
Also, please send it to the linux-mmc list as well.
Vish We don't know if this errata effects OMAP5 as well. So, I think
we should only do this if we are OMAP4.
---
drivers/mmc/host/omap_hsmmc.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 3a09f93..17803de 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -34,6 +34,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/card.h
#include linux/io.h
#include linux/semaphore.h
#include linux/gpio.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
+#define OMAP_HSMMC_CSRE0x0024
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -117,6 +119,9 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+/* Errata definitions */
+#define OMAP_HSMMC_ERRATA_I761 BIT(0)
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -177,6 +182,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned interrata;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -857,6 +863,23 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
omap_hsmmc_start_command(host, data-stop, NULL);
}
+static int
+omap_hsmmc_errata_i761(struct omap_hsmmc_host *host, struct mmc_command
*cmd)
+{
+ u32 rsp10, csre;
+
+ if ((cmd-flags MMC_RSP_R1) == MMC_RSP_R1
+ || (host-mmc-card (mmc_card_sd(host-mmc-card)
+ || mmc_card_sdio(host-mmc-card))
+(cmd-flags MMC_RSP_R5))) {
+ rsp10 = OMAP_HSMMC_READ(host-base, RSP10);
+ csre = OMAP_HSMMC_READ(host-base, CSRE);
+ return rsp10 csre;
+ }
+
+ return 0;
+}
+
/*
* Notify the core about command completion
*/
@@ -1046,6 +1069,17 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
+ /* Errata i761 */
+ if ((host-errata OMAP_HSMMC_ERRATA_I761) host-cmd
+omap_hsmmc_errata_i761(host, host-cmd)) {
+ /* Do the same as for CARD_ERR case */
+ dev_dbg(mmc_dev(host-mmc), Ignoring card err CMD%d\n,
+ host-cmd-opcode);
+ end_cmd = 1;
+ if (host-data)
+ end_trans = 1;
+ }
+
OMAP_HSMMC_WRITE(host-base, STAT, status);
if (end_cmd || ((status CC) host-cmd))
@@ -1829,6 +1863,10 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
host-power_mode = MMC_POWER_OFF;
host-next_data.cookie = 1;
+ host-errata = 0;
+ if (cpu_is_omap44xx())
+ host-errata |= OMAP_HSMMC_ERRATA_I761;
+
platform_set_drvdata(pdev, host);
mmc-ops= omap_hsmmc_ops;
--
1.7.10.4
--
Regards,
Viswanath Puttagunta (Vish)
Android Kernel Software Engineer,
Texas Instruments
214-567-0838
vi...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] Assorted MMC / OMAP HSMMC patches
Essentially, a lot of cleanups leading up to adding a new feature for OMAP HSMMC. The idea is to convert to the use of software timer instead of IP timer for timekeeping, due to the limitations of the counting range of the IP timer. Also added myself as OMAP HSMMC maintainer. Patch 9/10 is in draft state and needs more testing. These patches are also available at git://github.com/svenkatr/linux.git my/mmc/3.6/hrtimer_updates Venkatraman S (10): mmc: core: Add TRANsfer state to non-HPI state mmc: debugfs: Print ext_csd in ascending order mmc: omap: remove unused variables and includes mmc: omap: fix mmc_omap_report_irq to use dev_dbg macros mmc: omap_hsmmc: remove unused vars and includes mmc: omap_hsmmc: remove access to SYSCONFIG register mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ mmc: omap_hsmmc: convert from IP timer to hrtimer mmc: omap_hsmmc: Move to Maintained state in MAINTAINERS MAINTAINERS | 4 +- drivers/mmc/core/core.c | 3 +- drivers/mmc/core/debugfs.c| 2 +- drivers/mmc/host/omap.c | 39 drivers/mmc/host/omap_hsmmc.c | 212 -- 5 files changed, 103 insertions(+), 157 deletions(-) -- 1.7.11.1.25.g0e18bef -- 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 01/10] mmc: core: Add TRANsfer state to non-HPI state
HPI can be issued only in programming state to bring the card to transfer state. If the card is already in transfer state, doing a HPI is redundant. Fix this by adding transfer state to the list of exceptions to doing HPI and return without error. Signed-off-by: Venkatraman S svenk...@ti.com --- drivers/mmc/core/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 8ac5246..835c9f0 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -424,8 +424,9 @@ int mmc_interrupt_hpi(struct mmc_card *card) case R1_STATE_IDLE: case R1_STATE_READY: case R1_STATE_STBY: + case R1_STATE_TRAN: /* -* In idle states, HPI is not needed and the caller +* In idle and transfer states, HPI is not needed and the caller * can issue the next intended command immediately */ goto out; -- 1.7.11.1.25.g0e18bef -- 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 02/10] mmc: debugfs: Print ext_csd in ascending order
ext_csd exported through debugfs is printed in reverse order (from byte 511 to 0), which causes confusion. Fix the for loop to print ext_csd in natural order. Signed-off-by: Venkatraman S svenk...@ti.com --- drivers/mmc/core/debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c index 9ab5b17..d96c643 100644 --- a/drivers/mmc/core/debugfs.c +++ b/drivers/mmc/core/debugfs.c @@ -281,7 +281,7 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp) if (err) goto out_free; - for (i = 511; i = 0; i--) + for (i = 0; i 512; i++) n += sprintf(buf + n, %02x, ext_csd[i]); n += sprintf(buf + n, \n); BUG_ON(n != EXT_CSD_STR_LEN); -- 1.7.11.1.25.g0e18bef -- 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 03/10] mmc: omap: remove unused variables and includes
Get rid of some unnecessary includes in the driver and
a few unused variables.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 50e08f0..0ec4e55 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -27,18 +27,10 @@
#include linux/mmc/card.h
#include linux/clk.h
#include linux/scatterlist.h
-#include linux/i2c/tps65010.h
#include linux/slab.h
-#include asm/io.h
-#include asm/irq.h
-
-#include plat/board.h
#include plat/mmc.h
-#include asm/gpio.h
#include plat/dma.h
-#include plat/mux.h
-#include plat/fpga.h
#defineOMAP_MMC_REG_CMD0x00
#defineOMAP_MMC_REG_ARGL 0x01
@@ -107,7 +99,6 @@ struct mmc_omap_slot {
u16 saved_con;
u16 bus_mode;
unsigned intfclk_freq;
- unsignedpowered:1;
struct tasklet_struct cover_tasklet;
struct timer_list cover_timer;
@@ -139,7 +130,6 @@ struct mmc_omap_host {
unsigned intphys_base;
int irq;
unsigned char bus_mode;
- unsigned char hw_bus_mode;
unsigned intreg_shift;
struct work_struct cmd_abort_work;
--
1.7.11.1.25.g0e18bef
--
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 04/10] mmc: omap: fix mmc_omap_report_irq to use dev_dbg macros
The function mmc_omap_report_irq uses raw printks and the
actual output was disabled by a static variable. Make
the function use dev_vdbg macro and use it under the
standard CONFIG_MMC_DEBUG flag.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 0ec4e55..614f63c 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -679,22 +679,29 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
}
}
-static inline void mmc_omap_report_irq(u16 status)
+#ifdef CONFIG_MMC_DEBUG
+static void mmc_omap_report_irq(struct mmc_omap_host *host, u16 status)
{
static const char *mmc_omap_status_bits[] = {
EOC, CD, CB, BRS, EOFB, DTO, DCRC, CTO,
CCRC, CRW, AF, AE, OCRB, CIRQ, CERR
};
- int i, c = 0;
+ int i;
+ char res[64], *buf = res;
+
+ buf += sprintf(buf, MMC IRQ 0x%x:, status);
for (i = 0; i ARRAY_SIZE(mmc_omap_status_bits); i++)
- if (status (1 i)) {
- if (c)
- printk( );
- printk(%s, mmc_omap_status_bits[i]);
- c++;
- }
+ if (status (1 i))
+ buf += sprintf(buf, %s, mmc_omap_status_bits[i]);
+ dev_vdbg(mmc_dev(host-mmc), %s\n, res);
+}
+#else
+static void mmc_omap_report_irq(struct mmc_omap_host *host, u16 status)
+{
}
+#endif
+
static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
{
@@ -728,12 +735,10 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
cmd = host-cmd-opcode;
else
cmd = -1;
-#ifdef CONFIG_MMC_DEBUG
dev_dbg(mmc_dev(host-mmc), MMC IRQ %04x (CMD %d): ,
status, cmd);
- mmc_omap_report_irq(status);
- printk(\n);
-#endif
+ mmc_omap_report_irq(host, status);
+
if (host-total_bytes_left) {
if ((status OMAP_MMC_STAT_A_FULL) ||
(status OMAP_MMC_STAT_END_OF_DATA))
--
1.7.11.1.25.g0e18bef
--
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 05/10] mmc: omap_hsmmc: remove unused vars and includes
Some straight forward cleanup of unnecessary #include's
and host variables. Some of the verbose and redundant
debug messages are converted to use dev_vdbg.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e180735..da4f5a7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -35,7 +35,6 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
-#include linux/semaphore.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pm_runtime.h
@@ -162,8 +161,6 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
- u32 *buffer;
- u32 bytesleft;
int suspended;
int irq;
int use_dma, dma_ch;
@@ -172,7 +169,6 @@ struct omap_hsmmc_host {
int slot_id;
int response_busy;
int context_loss;
- int vdd;
int protect_card;
int reqs_blocked;
int use_reg;
@@ -496,7 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
unsigned long regval;
unsigned long timeout;
- dev_dbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
+ dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
omap_hsmmc_stop_clock(host);
@@ -746,7 +742,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
{
int cmdreg = 0, resptype = 0, cmdtype = 0;
- dev_dbg(mmc_dev(host-mmc), %s: CMD%d, argument 0x%08x\n,
+ dev_vdbg(mmc_dev(host-mmc), %s: CMD%d, argument 0x%08x\n,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
@@ -935,7 +931,7 @@ static void omap_hsmmc_dbg_report_irq(struct
omap_hsmmc_host *host, u32 status)
buf += len;
}
- dev_dbg(mmc_dev(host-mmc), %s\n, res);
+ dev_vdbg(mmc_dev(host-mmc), %s\n, res);
}
#else
static inline void omap_hsmmc_dbg_report_irq(struct omap_hsmmc_host *host,
@@ -997,7 +993,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host,
int status)
}
data = host-data;
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+ dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
if (status ERR) {
omap_hsmmc_dbg_report_irq(host, status);
@@ -1502,12 +1498,10 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
case MMC_POWER_OFF:
mmc_slot(host).set_power(host-dev, host-slot_id,
0, 0);
- host-vdd = 0;
break;
case MMC_POWER_UP:
mmc_slot(host).set_power(host-dev, host-slot_id,
1, ios-vdd);
- host-vdd = ios-vdd;
break;
case MMC_POWER_ON:
do_send_init_stream = 1;
--
1.7.11.1.25.g0e18bef
--
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 06/10] mmc: omap_hsmmc: remove access to SYSCONFIG register
SYSCONFIG register of HSMMC IP is managed by the omap hwmod
abstraction layer. Resetting the IP and configuring the correct
SYSCONFIG mode is centrally managed by hwmod.
Remove code which manipulates IP reset and SYSCONFIG directly in the
driver.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index da4f5a7..4bc55ac 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -44,7 +44,6 @@
#include plat/cpu.h
/* OMAP HSMMC Host Controller Registers */
-#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
@@ -576,21 +575,8 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
if (host-context_loss == context_loss)
return 1;
- /* Wait for hardware reset */
- timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) != RESETDONE
-time_before(jiffies, timeout))
- ;
-
- /* Do software reset */
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
- timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) != RESETDONE
-time_before(jiffies, timeout))
- ;
-
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ if (!OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE)
+ return 1;
if (host-pdata-controller_flags OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
if (host-power_mode != MMC_POWER_OFF
@@ -1593,10 +1579,6 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
value = OMAP_HSMMC_READ(host-base, CAPA);
OMAP_HSMMC_WRITE(host-base, CAPA, value | capa);
- /* Set the controller to AUTO IDLE mode */
- value = OMAP_HSMMC_READ(host-base, SYSCONFIG);
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG, value | AUTOIDLE);
-
/* Set SD bus power bit */
set_sd_bus_power(host);
}
@@ -1654,8 +1636,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void
*data)
pm_runtime_get_sync(host-dev);
- seq_printf(s, SYSCONFIG:\t0x%08x\n,
- OMAP_HSMMC_READ(host-base, SYSCONFIG));
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
seq_printf(s, HCTL:\t\t0x%08x\n,
--
1.7.11.1.25.g0e18bef
--
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 07/10] mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs
Flushing spurious IRQs from HSMMC IP is done twice in
omap_hsmmc_irq and omap_hsmmc_do_irq.
Consolidate them to one location.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4bc55ac..20453c8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -969,15 +969,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0;
- if (!host-req_in_progress) {
- do {
- OMAP_HSMMC_WRITE(host-base, STAT, status);
- /* Flush posted write */
- status = OMAP_HSMMC_READ(host-base, STAT);
- } while (status INT_EN_MASK);
- return;
- }
-
data = host-data;
dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
@@ -1028,8 +1019,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
- OMAP_HSMMC_WRITE(host-base, STAT, status);
-
if (end_cmd || ((status CC) host-cmd))
omap_hsmmc_cmd_done(host, host-cmd);
if ((end_trans || (status TC)) host-mrq)
@@ -1045,11 +1034,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- do {
+ while (status INT_EN_MASK host-req_in_progress) {
omap_hsmmc_do_irq(host, status);
+
/* Flush posted write */
+ OMAP_HSMMC_WRITE(host-base, STAT, status);
status = OMAP_HSMMC_READ(host-base, STAT);
- } while (status INT_EN_MASK);
+ }
return IRQ_HANDLED;
}
--
1.7.11.1.25.g0e18bef
--
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 08/10] mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ
Consolidate the duplicated code around the handling of CMD_TIMEOUT,
CMD_CRC, DATA_TIMEOUT, DATA_CRC and CARD_ERR handling into a
single function.
This generally shrinks code bloat, but is also required for implementing
software based guard timers.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 63 +++
1 file changed, 21 insertions(+), 42 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 20453c8..9afdd20 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -964,6 +964,18 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
__func__);
}
+static void hsmmc_command_incomplete(struct omap_hsmmc_host *host, int err)
+{
+ omap_hsmmc_reset_controller_fsm(host, SRC);
+ host-cmd-error = err;
+
+ if (host-data) {
+ omap_hsmmc_reset_controller_fsm(host, SRD);
+ omap_hsmmc_dma_cleanup(host, err);
+ }
+
+}
+
static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host, int status)
{
struct mmc_data *data;
@@ -974,48 +986,15 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
if (status ERR) {
omap_hsmmc_dbg_report_irq(host, status);
- if ((status CMD_TIMEOUT) ||
- (status CMD_CRC)) {
- if (host-cmd) {
- if (status CMD_TIMEOUT) {
- omap_hsmmc_reset_controller_fsm(host,
- SRC);
- host-cmd-error = -ETIMEDOUT;
- } else {
- host-cmd-error = -EILSEQ;
- }
- end_cmd = 1;
- }
- if (host-data || host-response_busy) {
- if (host-data)
- omap_hsmmc_dma_cleanup(host,
- -ETIMEDOUT);
- host-response_busy = 0;
- omap_hsmmc_reset_controller_fsm(host, SRD);
- }
- }
- if ((status DATA_TIMEOUT) ||
- (status DATA_CRC)) {
- if (host-data || host-response_busy) {
- int err = (status DATA_TIMEOUT) ?
- -ETIMEDOUT : -EILSEQ;
-
- if (host-data)
- omap_hsmmc_dma_cleanup(host, err);
- else
- host-mrq-cmd-error = err;
- host-response_busy = 0;
- omap_hsmmc_reset_controller_fsm(host, SRD);
- end_trans = 1;
- }
- }
- if (status CARD_ERR) {
- dev_dbg(mmc_dev(host-mmc),
- Ignoring card err CMD%d\n, host-cmd-opcode);
- if (host-cmd)
- end_cmd = 1;
- if (host-data)
- end_trans = 1;
+ if (status (CMD_TIMEOUT | DATA_TIMEOUT))
+ hsmmc_command_incomplete(host, -ETIMEDOUT);
+ else if (status (CMD_CRC | DATA_CRC))
+ hsmmc_command_incomplete(host, -EILSEQ);
+
+ end_cmd = 1;
+ if (host-data || host-response_busy) {
+ end_trans = 1;
+ host-response_busy = 0;
}
}
--
1.7.11.1.25.g0e18bef
--
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 10/10] mmc: omap_hsmmc: Move to Maintained state in MAINTAINERS
I can continue to look after this driver. Signed-off-by: Venkatraman S svenk...@ti.com --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 72c2681..75e3c3e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4933,8 +4933,10 @@ S: Maintained F: drivers/mmc/host/omap.c OMAP HS MMC SUPPORT +M: Venkatraman S svenk...@ti.com +L: linux-...@vger.kernel.org L: linux-omap@vger.kernel.org -S: Orphan +S: Maintained F: drivers/mmc/host/omap_hsmmc.c OMAP RANDOM NUMBER GENERATOR SUPPORT -- 1.7.11.1.25.g0e18bef -- 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 09/10] mmc: omap_hsmmc: convert from IP timer to hrtimer
omap hsmmc controller IP has an inbuilt timer that can be programmed to
guard against unresponsive operations. But it's range is very narrow,
and it's maximum countable time is a few seconds.
Card maintenance operations like BKOPS and SECURE DISCARD and long
stream writes like packed command require timers of order of
several minutes.
So get rid of using the IP timer entirely and use kernel's hrtimer
functionality for guarding the device operations.
As part of this change, a workaround that disabled timeouts for
MMC_ERASE commands is removed, and the arbitary timing of 100ms
is used only when the timeout is not explicitly specified by core.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 96 ++-
1 file changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9afdd20..8f7cebc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -79,7 +79,7 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
-#define INT_EN_MASK0x307F0033
+#define INT_EN_MASK0x306E0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
#define DTO_ENABLE (1 20)
@@ -160,6 +160,7 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char bus_mode;
unsigned char power_mode;
+ unsigned intns_per_clk_cycle;
int suspended;
int irq;
int use_dma, dma_ch;
@@ -172,6 +173,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ struct hrtimer guard_timer;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -455,10 +457,6 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
else
irq_mask = INT_EN_MASK;
- /* Disable timeout for erases */
- if (cmd-opcode == MMC_ERASE)
- irq_mask = ~DTO_ENABLE;
-
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
@@ -508,6 +506,9 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ if (ios-clock)
+ host-ns_per_clk_cycle = DIV_ROUND_UP(NSEC_PER_SEC, ios-clock);
+
omap_hsmmc_start_clock(host);
}
@@ -824,7 +825,7 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
omap_hsmmc_request_done(host, mrq);
return;
}
-
+ hrtimer_cancel(host-guard_timer);
host-data = NULL;
if (!data-error)
@@ -859,8 +860,11 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, struct
mmc_command *cmd)
cmd-resp[0] = OMAP_HSMMC_READ(host-base, RSP10);
}
}
- if ((host-data == NULL !host-response_busy) || cmd-error)
+ if ((host-data == NULL !host-response_busy) || cmd-error) {
+ if (cmd-error != -ETIMEDOUT)
+ hrtimer_cancel(host-guard_timer);
omap_hsmmc_request_done(host, cmd-mrq);
+ }
}
/*
@@ -992,7 +996,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host,
int status)
hsmmc_command_incomplete(host, -EILSEQ);
end_cmd = 1;
- if (host-data || host-response_busy) {
+ if (data || host-response_busy) {
end_trans = 1;
host-response_busy = 0;
}
@@ -1292,41 +1296,35 @@ static int omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host,
return 0;
}
-static void set_data_timeout(struct omap_hsmmc_host *host,
-unsigned int timeout_ns,
-unsigned int timeout_clks)
+static void set_guard_timer(struct omap_hsmmc_host *host,
+ unsigned long timeout_ms, unsigned long timeout_ns,
+ unsigned int timeout_clks)
{
- unsigned int timeout, cycle_ns;
- uint32_t reg, clkd, dto = 0;
+ ktime_t gtime;
+ unsigned int sec, nsec;
- reg = OMAP_HSMMC_READ(host-base, SYSCTL);
- clkd = (reg CLKD_MASK) CLKD_SHIFT;
- if (clkd == 0)
- clkd = 1;
+ sec = timeout_ms / MSEC_PER_SEC;
+ nsec = (timeout_ms % MSEC_PER_SEC) * NSEC_PER_MSEC + timeout_ns;
- cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
- timeout = timeout_ns / cycle_ns;
- timeout += timeout_clks;
- if (timeout) {
- while ((timeout 0x8000) == 0) {
Re: [PATCH] spi: omap2-mcspi: Remove the call to platform_set_drvdata(pdev, NULL)
On Thu, Aug 16, 2012 at 08:49:30PM +0530, Shubhrajyoti D wrote: Remove the call of platform_set_drvdata(pdev, NULL) as they are not needed anymore. Applied, thanks. These calls were never *needed* people just like to put them in. -- 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
