[PATCH/RESEND #3 0/7] SmartReflex Patches
Hi Tony, here's a bunch of patches to smartreflex which have been pending for months. Compile tested with omap2plus_defconfig + CONFIG_OMAP_SMARTREFLEX + CONFIG_OMAP_SMARTREFLEX_CLASS3. Felipe Balbi (6): arm: omap: smartreflex: add missing platform_set_drvdata() arm: omap: smartreflex: use dev_get_drvdata() arm: omap: smartreflex: move late_initcall() closer to its argument arm: omap: smartreflex: clean ups all over arm: omap: smartreflex: fix IRQ handling bug arm: omap: smartreflex: micro-optimization for sanity check Nishanth Menon (1): OMAP3+: PM: SR: add suspend/resume handlers arch/arm/mach-omap2/smartreflex.c | 309 1 files changed, 206 insertions(+), 103 deletions(-) -- 1.7.8.rc0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RESEND #3 1/7] OMAP3+: PM: SR: add suspend/resume handlers
From: Nishanth Menon n...@ti.com
SmartReflex should be disabled while entering low power mode due to
the following reasons:
a) SmartReflex values are not defined for retention voltage.
b) With SmartReflex enabled, if the CPU enters low power state, FSM
will try to bump the voltage to current OPP's voltage for which
it has entered low power state, causing power loss and potential
unknown states for the SoC.
Since we are sure to attempt entering the lowest possible power state
during suspend operation, SmartReflex needs to be disabled for the
voltage domains in suspend path before achieving auto retention voltage
on the device.
Traditionally, this has been done with interrupts disabled as part of
the common code which handles the idle sequence. Instead, by using the
fact that we have to disable SmartReflex for sure during suspend
operations, we can opportunistically disable SmartReflex in device
standard pm ops, instead of disabling it as part of the code which
executes with interrupts disabled and slave CPU{s} shutdown. This
allows the system to do other parallel activities(such as suspending
other devices in the system using slave CPU{s}) and save the time
required to achieve suspend and resume from suspended state as a
sequential activity.
However, by being opportunistic as described above, we also increase
the likelihood of SmartReflex library access functions being invoked in
parallel contexts *after* SmartReflex driver's suspend handler (during
suspend operation) or *before* resume handler (during resume operation)
have been invoked (Example: DVFS for dependent devices, cpufreq for
MPU etc.). We prevent this by using a flag to reject the callers in
the duration where SmartReflex has been disabled.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 96 ++--
1 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 6a4f683..5763a71 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -24,6 +24,7 @@
#include linux/debugfs.h
#include linux/delay.h
#include linux/slab.h
+#include linux/pm.h
#include linux/pm_runtime.h
#include plat/common.h
@@ -40,6 +41,7 @@ struct omap_sr {
int ip_type;
int nvalue_count;
boolautocomp_active;
+ boolis_suspended;
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -685,6 +687,11 @@ void omap_sr_enable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -718,6 +725,11 @@ void omap_sr_disable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -751,6 +763,11 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -809,14 +826,16 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return -EINVAL;
}
- /* control enable/disable only if there is a delta in value */
- if (sr_info-autocomp_active != val) {
- if (!val)
- sr_stop_vddautocomp(sr_info);
- else
- sr_start_vddautocomp(sr_info);
+ if (sr_info-is_suspended) {
+ pr_warning(%s: in suspended state\n, __func__);
+ return -EBUSY;
}
+ if (!val)
+ sr_stop_vddautocomp(sr_info);
+ else
+ sr_start_vddautocomp(sr_info);
+
return 0;
}
@@ -1011,10 +1030,75 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_sr_suspend(struct device *dev)
+{
+ struct omap_sr_data *pdata;
+ struct omap_sr *sr_info;
+
+ pdata =
[PATCH/RESEND #3 2/7] arm: omap: smartreflex: add missing platform_set_drvdata()
that's very useful to fetch the correct struct sr_info
from PM handlers.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 5763a71..443591b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -858,6 +858,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
return -ENOMEM;
}
+ platform_set_drvdata(pdev, sr_info);
+
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
ret = -EINVAL;
--
1.7.8.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RESEND #3 4/7] arm: omap: smartreflex: move late_initcall() closer to its argument
no functional changes, trivial patch.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index bb3bfc0..97375d2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1095,12 +1095,12 @@ static int __init sr_init(void)
return 0;
}
+late_initcall(sr_init);
static void __exit sr_exit(void)
{
platform_driver_unregister(smartreflex_driver);
}
-late_initcall(sr_init);
module_exit(sr_exit);
MODULE_DESCRIPTION(OMAP Smartreflex Driver);
--
1.7.8.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RESEND #3 6/7] arm: omap: smartreflex: fix IRQ handling bug
fix a bug which has been on this driver since it was added by the original commit 984aa6db which would never clear IRQSTATUS bits. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/smartreflex.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index eb88b36..a5399df 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -156,7 +156,7 @@ static irqreturn_t sr_interrupt(int irq, void *data) break; case SR_TYPE_V2: /* Read the status bits */ - sr_read_reg(sr_info, IRQSTATUS); + status = sr_read_reg(sr_info, IRQSTATUS); /* Clear them by writing back */ sr_write_reg(sr_info, IRQSTATUS, status); -- 1.7.8.rc0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RESEND #3 7/7] arm: omap: smartreflex: micro-optimization for sanity check
val (val != 1) == val 1
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index a5399df..9fee277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -868,7 +868,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
/* Sanity check */
- if (val (val != 1)) {
+ if (val 1) {
pr_warning(%s: Invalid argument %lld\n, __func__, val);
return -EINVAL;
}
--
1.7.8.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RESEND #3 5/7] arm: omap: smartreflex: clean ups all over
There are no functional changes here, only
misc cleanups in general: tabifying variable
declarations, converting if {} else if {} else {}
into switch statements, etc.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 218 +++--
1 files changed, 134 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 97375d2..eb88b36 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -37,26 +37,32 @@
#define SR_DISABLE_TIMEOUT 200
struct omap_sr {
- int srid;
- int ip_type;
+ struct list_headnode;
+ struct platform_device *pdev;
+ struct omap_sr_nvalue_table *nvalue_table;
+ struct voltagedomain*voltdm;
+
+ unsigned intirq;
+
int nvalue_count;
- boolautocomp_active;
- boolis_suspended;
- u32 clk_length;
- u32 err_weight;
+ int ip_type;
+ int srid;
+
+ u32 senn_avgweight;
+ u32 senp_avgweight;
u32 err_minlimit;
u32 err_maxlimit;
+ u32 clk_length;
+ u32 err_weight;
u32 accum_data;
- u32 senn_avgweight;
- u32 senp_avgweight;
u32 senp_mod;
u32 senn_mod;
- unsigned intirq;
+
+ boolautocomp_active;
+ boolis_suspended;
+
void __iomem*base;
- struct platform_device *pdev;
- struct list_headnode;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain*voltdm;
+
struct dentry *dbg_dir;
};
@@ -75,11 +81,9 @@ static inline void sr_write_reg(struct omap_sr *sr, unsigned
offset, u32 value)
static inline void sr_modify_reg(struct omap_sr *sr, unsigned offset, u32 mask,
u32 value)
{
- u32 reg_val;
- u32 errconfig_offs = 0, errconfig_mask = 0;
-
- reg_val = __raw_readl(sr-base + offset);
- reg_val = ~mask;
+ u32 reg_val;
+ u32 errconfig_offs = 0;
+ u32 errconfig_mask = 0;
/*
* Smartreflex error config register is special as it contains
@@ -90,14 +94,23 @@ static inline void sr_modify_reg(struct omap_sr *sr,
unsigned offset, u32 mask,
* if they are currently set, but does allow the caller to write
* those bits.
*/
- if (sr-ip_type == SR_TYPE_V1) {
+ switch (sr-ip_type) {
+ case SR_TYPE_V1:
errconfig_offs = ERRCONFIG_V1;
errconfig_mask = ERRCONFIG_STATUS_V1_MASK;
- } else if (sr-ip_type == SR_TYPE_V2) {
+ break;
+ case SR_TYPE_V2:
errconfig_offs = ERRCONFIG_V2;
errconfig_mask = ERRCONFIG_VPBOUNDINTST_V2;
+ break;
+ default: /* should never happen */
+ dev_err(sr-pdev-dev, UNKNOWN IP type %d\n, sr-ip_type);
+ return;
}
+ reg_val = __raw_readl(sr-base + offset);
+ reg_val = ~mask;
+
if (offset == errconfig_offs)
reg_val = ~errconfig_mask;
@@ -113,7 +126,7 @@ static inline u32 sr_read_reg(struct omap_sr *sr, unsigned
offset)
static struct omap_sr *_sr_lookup(struct voltagedomain *voltdm)
{
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info;
if (!voltdm) {
pr_err(%s: Null voltage domain passed!\n, __func__);
@@ -130,33 +143,39 @@ static struct omap_sr *_sr_lookup(struct voltagedomain
*voltdm)
static irqreturn_t sr_interrupt(int irq, void *data)
{
- struct omap_sr *sr_info = (struct omap_sr *)data;
- u32 status = 0;
+ struct omap_sr *sr_info = data;
+ u32 status = 0;
- if (sr_info-ip_type == SR_TYPE_V1) {
+ switch (sr_info-ip_type) {
+ case SR_TYPE_V1:
/* Read the status bits */
status = sr_read_reg(sr_info, ERRCONFIG_V1);
/* Clear them by writing back */
sr_write_reg(sr_info, ERRCONFIG_V1, status);
- } else if (sr_info-ip_type == SR_TYPE_V2) {
+ break;
+ case SR_TYPE_V2:
/* Read the status bits */
[PATCH/RESEND #3 3/7] arm: omap: smartreflex: use dev_get_drvdata()
When we need to fetch struct omap_sr on PM
handlers, there's no need to access platform_data.
Instead, we can use dev_get_drvdata(dev) like
other drivers do.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 51 ++--
1 files changed, 9 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 443591b..bb3bfc0 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1002,22 +1002,9 @@ err_free_devinfo:
static int __devexit omap_sr_remove(struct platform_device *pdev)
{
- struct omap_sr_data *pdata = pdev-dev.platform_data;
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info = platform_get_drvdata(pdev);
struct resource *mem;
- if (!pdata) {
- dev_err(pdev-dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(pdev-dev, %s: omap_sr struct not found\n,
- __func__);
- return -EINVAL;
- }
-
if (sr_info-autocomp_active)
sr_stop_vddautocomp(sr_info);
if (sr_info-dbg_dir)
@@ -1034,20 +1021,10 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
static int omap_sr_suspend(struct device *dev)
{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info = dev_get_drvdata(dev);
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
+ if (!sr_info)
+ return 0;
if (!sr_info-autocomp_active)
return 0;
@@ -1055,7 +1032,7 @@ static int omap_sr_suspend(struct device *dev)
if (sr_info-is_suspended)
return 0;
- omap_sr_disable_reset_volt(pdata-voltdm);
+ omap_sr_disable_reset_volt(sr_info-voltdm);
sr_info-is_suspended = true;
/* Flag the same info to the other CPUs */
smp_wmb();
@@ -1065,20 +1042,10 @@ static int omap_sr_suspend(struct device *dev)
static int omap_sr_resume(struct device *dev)
{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
+ struct omap_sr *sr_info = dev_get_drvdata(dev);
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
+ if (!sr_info)
+ return 0;
if (!sr_info-autocomp_active)
return 0;
@@ -1089,7 +1056,7 @@ static int omap_sr_resume(struct device *dev)
sr_info-is_suspended = false;
/* Flag the same info to the other CPUs */
smp_wmb();
- omap_sr_enable(pdata-voltdm);
+ omap_sr_enable(sr_info-voltdm);
return 0;
}
--
1.7.8.rc0
--
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] OMAP2+: UART: Make the SERIAL_OMAP depend on ARCH_OMAP2PLUS
On Tue, Nov 15, 2011 at 11:57:40AM +0530, Shubhrajyoti D wrote: Making SERIAL_OMAP depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Acked-by: Felipe Balbi ba...@ti.com Suggested-by: Sricharan R r.sricha...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com There's another one: drivers/mtd/nand/Kconfig: depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) And the 'ARM ' is redundant. -- 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] OMAP2+: UART: Make the SERIAL_OMAP depend on ARCH_OMAP2PLUS
On Tuesday 15 November 2011 02:36 PM, Russell King - ARM Linux wrote: On Tue, Nov 15, 2011 at 11:57:40AM +0530, Shubhrajyoti D wrote: Making SERIAL_OMAP depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Acked-by: Felipe Balbi ba...@ti.com Suggested-by: Sricharan R r.sricha...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com There's another one: drivers/mtd/nand/Kconfig: depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) And the 'ARM ' is redundant. Will send a patch addressing the same. -- 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] MTD: nand: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS
Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/mtd/nand/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index cce7b70..b68dd5e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -110,7 +110,7 @@ config MTD_NAND_AMS_DELTA config MTD_NAND_OMAP2 tristate NAND Flash device on OMAP2, OMAP3 and OMAP4 - depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) + depends on ARCH_OMAP2PLUS help Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 platforms. -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API
Hi Ohad, On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote: Ohad Ben-Cohen (5): ARM: dev_archdata: add private iommu extension ARM: OMAP: omap_device: add a method to set iommu private archdata ARM: OMAP: iommu: declare a private iommu binding struct ARM: OMAP3: bind omap3isp_device to its iommu device iommu/omap: eliminate the public omap_find_iommu_device() method It doesn't apply cleanly, can you please rebase the code, collect the Acked-by's and resend? Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API
Hi Joerg, On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg joerg.roe...@amd.com wrote: It doesn't apply cleanly, can you please rebase the code, collect the Acked-by's and resend? Sure. I planned on resending after the hardware pgsize patches are merged, but please tell me if you prefer it the other way around. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API
On Tue, Nov 15, 2011 at 12:45:33PM +0200, Ohad Ben-Cohen wrote: Hi Joerg, On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg joerg.roe...@amd.com wrote: It doesn't apply cleanly, can you please rebase the code, collect the Acked-by's and resend? Sure. I planned on resending after the hardware pgsize patches are merged, but please tell me if you prefer it the other way around. It is almost merged :) I just had to struggle with some compile errors from upstream in my tests. But I think I will finish testing today and push everything out. Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API
On Tue, Nov 15, 2011 at 1:10 PM, Roedel, Joerg joerg.roe...@amd.com wrote: It is almost merged :) I just had to struggle with some compile errors from upstream in my tests. But I think I will finish testing today and push everything out. ok great thanks :) -- 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: Help with clk API
Hi Felipe On Fri, 11 Nov 2011, Felipe Balbi wrote: I have a doubt about using clk API to change CLKSEL_UTMI_P1 bit for a silicon errata (OMAP4460 i693) implementation. According to errata, I need to switch from external to internal clock during USB port suspend, wait 1ms and switch back from internal to external. How can I do that with clk API ? Is it by changing clk parent ? Any tips would be helpful ;-) thanks clk_set_parent() is the way to go. There are 44xx struct clks that references CLKSEL_UTMI_P1 and CLKSEL_UTMI_P2: see utmi_p1_gfclk and utmi_p2_gfclk in mach-omap2/clock44xx_data.c. The possible parent clocks are listed in utmi_p1_gfclk_sel and utmi_p2_gfclk_sel in the same file. So you should be able to clk_get() the possible parent clocks and utmi_p1_gfclk during module init, then use clk_set_parent() to switch between them. For example, for port 1: new_parent = clk_set_parent(utmi_p1_clk, init_60m_clk); /* test new_parent for error */ /* delay 1ms */ new_parent = clk_set_parent(utmi_p1_clk, xclk60mhsp1_ck); or something similar. Please let me know if something like the above turns out not to work for you. One comment. Erratum i693 in SWPZ017A Public is not 100% explicit on whether the new parent clock needs to be enabled before the clk_set_parent() executes. It seems to imply that it does need to be enabled first. If so, this is contrary to what we previously believed was a safe sequence based on Richard Woodruff's post here: http://lkml.org/lkml/2009/2/19/416 The concern is that the parent-switching process may not be glitch-free. Of course, if it isn't, we're in trouble, because we may not be able to shut off a clock like init_60m_clk if the other port is using it. Perhaps it would be enough to gate the downstream clock node (e.g. usb_host_hs_utmi_p1_clk). We'll need to get some clarification on this. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..c3bd640 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_init();
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a5b576b..d95df2e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,21 +478,6 @@ int __init omap4_panda_dvi_init(void)
return r;
}
-
-static void omap4_panda_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
@@ -555,8 +540,8 @@ void omap4_panda_display_init(void)
if (r)
pr_err(error initializing panda DVI\n);
- omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+ omap_hdmi_init();
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..8436088 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -29,6 +29,7 @@
#include plat/omap-pm.h
#include plat/common.h
+#include mux.h
#include control.h
#include display.h
@@ -96,6 +97,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static void omap4_hdmi_mux_pads()
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift;
@@ -129,6 +144,14 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+int omap_hdmi_init(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_hdmi_mux_pads();
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..0cb0469 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,8 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+/* HDMI mux init*/
+extern int omap_hdmi_init(void);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe
[PATCH v3 2/2] OMAPDSS: HDMI: Disable DDC internal pull up
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are expernal pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 13 -
arch/arm/mach-omap2/board-omap4panda.c | 14 +-
arch/arm/mach-omap2/display.c | 17 ++---
include/video/omapdss.h|4 +++-
4 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c3bd640..d0a82f9 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,7 +826,18 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
- omap_hdmi_init();
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 and OMAP4430 ES2.3 SDP, Blaze and Panda as the
+* external pull up are present. This is needed to avoid
+* EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_init(OMAP_HDMI_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d95df2e..44ff8e0 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,7 +541,19 @@ void omap4_panda_display_init(void)
pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
- omap_hdmi_init();
+
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor - This is a change needed in
+* OMAP4460 and OMAP4430 ES2.3 SDP, Blaze and Panda as the
+* external pull up are present. This is needed to avoid
+* EDID read failure.
+*/
+ if (cpu_is_omap446x() || (omap_rev() OMAP4430_REV_ES2_2))
+ omap_hdmi_init(OMAP_HDMI_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 8436088..a75e179 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -97,8 +97,11 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void omap4_hdmi_mux_pads()
+static void omap4_hdmi_mux_pads(int flags)
{
+ u32 reg;
+ u16 control_i2c_1;
+
/* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
omap_mux_init_signal(hdmi_hpd,
OMAP_PIN_INPUT_PULLUP);
@@ -109,6 +112,14 @@ static void omap4_hdmi_mux_pads()
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
OMAP_PIN_INPUT_PULLUP);
+
+ if (flags OMAP_HDMI_EXTERNAL_PULLUP) {
+ control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
+ reg = omap4_ctrl_pad_readl(control_i2c_1);
+ reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
+ OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
+ omap4_ctrl_pad_writel(reg, control_i2c_1);
+ }
}
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
@@ -144,10 +155,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
-int omap_hdmi_init(void)
+int omap_hdmi_init(int flags)
{
if (cpu_is_omap44xx())
- omap4_hdmi_mux_pads();
+ omap4_hdmi_mux_pads(flags);
return 0;
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 0cb0469..df585b5 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -49,6 +49,8 @@
#define DISPC_IRQ_FRAMEDONETV (1 24)
#define DISPC_IRQ_WBBUFFEROVERFLOW (1 25)
+#define OMAP_HDMI_EXTERNAL_PULLUP 0x1
+
struct omap_dss_device;
struct omap_overlay_manager;
@@ -310,7 +312,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_init(void);
+extern int omap_hdmi_init(int flags);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
Re: [PATCH v4-rebased 0/7] iommu: split mapping to page sizes as supported by the hardware
On Thu, Nov 10, 2011 at 11:32:24AM +0200, Ohad Ben-Cohen wrote: Ohad Ben-Cohen (7): iommu/core: stop converting bytes to page order back and forth iommu/core: split mapping to page sizes as supported by the hardware iommu/omap: announce supported page sizes iommu/msm: announce supported page sizes iommu/amd: announce supported page sizes iommu/intel: announce supported page sizes iommu/core: remove the temporary pgsize settings drivers/iommu/amd_iommu.c | 32 +--- drivers/iommu/intel-iommu.c | 30 --- drivers/iommu/iommu.c | 119 ++ drivers/iommu/msm_iommu.c | 25 - drivers/iommu/omap-iommu.c | 18 +++--- drivers/iommu/omap-iovmm.c | 17 ++ include/linux/iommu.h | 26 +++-- virt/kvm/iommu.c|8 ++-- 8 files changed, 205 insertions(+), 70 deletions(-) Applied, thanks. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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: [PATCHv3 10/11] omap3+: use lp params for calculating clock setup times
Hi Kevin, Thanks for the comments and sorry for a bit late reply. I was busy with other stuff but can work on this again. Anyway, all your comments to all of the patches make sense, and I will apply the changes to the next version of the set, also merging some of the patches back together again. One question though, do you want to have the auto_ret / auto_off support along with these changes? Some of the code in this set is only used when the auto_ret / auto_off is in, and it also makes it a bit more easier to test the resulting stuff. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: nand: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS
On Tue, Nov 15, 2011 at 03:52:36PM +0530, Shubhrajyoti D wrote: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Reported-by: Russell King li...@arm.linux.org.uk Thanks, but please make this rmk+ker...@arm.linux.org.uk. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/mtd/nand/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index cce7b70..b68dd5e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -110,7 +110,7 @@ config MTD_NAND_AMS_DELTA config MTD_NAND_OMAP2 tristate NAND Flash device on OMAP2, OMAP3 and OMAP4 - depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) + depends on ARCH_OMAP2PLUS help Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 platforms. -- 1.7.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 v16 09/12] OMAP: dmtimer: low-power mode support
Hi Tarun,
On Tue, Sep 20, 2011 at 6:30 AM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is enabled
and then disabled back at the end of access. Context save is done dynamically
whenever the registers are modified. Context restore is called when context is
lost.
Now that handling of the clock has been decoupled from
omap_dm_timer_request_specific/free and placed in start/stop
functions, there is a possible irq lock inversion dependency
detected for any attempt to enable the clock from soft|hard irq.
My use case is as follows:
DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
for processing the message, when it reaches tidspbridge it turns out
that the DSP wants to enable a gpt timer; however, locks involved
clocks_mutex and dm_timer_lock now could cause a deadlock as they
have been called from unsafe contexts in the past
(http://pastebin.com/7Dtz8t0f).
Is the intention to restrict enabling the dmtimer clocks from hard|soft irqs?
...
@@ -303,6 +342,22 @@ void omap_dm_timer_stop(struct omap_dm_timer *timer)
rate = clk_get_rate(timer-fclk);
__omap_dm_timer_stop(timer, timer-posted, rate, is_omap2);
+
+ if (timer-loses_context) {
+ if (timer-get_context_loss_count)
+ timer-ctx_loss_count =
+ timer-get_context_loss_count(timer-pdev-dev);
+ }
+
+ /*
+ * Since the register values are computed and written within
+ * __omap_dm_timer_stop, we need to use read to retrieve the
+ * context.
+ */
+ timer-context.tclr =
+ omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
+ timer-context.tisr = __raw_readl(timer-irq_stat);
+ omap_dm_timer_disable(timer);
}
EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
I didn't review the whole patch, but at least this part is not in
mainline, it seems like the patch modified by Tony and the v16 were
not the same.
I could diff and include the missing parts, if someone can confirm
that we need v16, which I believe so, since current stop function
doesn't call omap_dm_timer_disable.
Regards,
Omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] mmc: logging neatening and mmc_host_level
Joe Perches (4): mmc: Update logging style wbsd: Use current logging mmc: Logging neatening mmc: Add mmc_host_level logging drivers/mmc/card/block.c|4 +- drivers/mmc/card/mmc_test.c | 77 ++- drivers/mmc/card/queue.c|6 +- drivers/mmc/card/sdio_uart.c| 10 +- drivers/mmc/core/bus.c | 27 ++--- drivers/mmc/core/core.c | 116 ++--- drivers/mmc/core/host.c | 14 +-- drivers/mmc/core/mmc.c | 75 +- drivers/mmc/core/mmc_ops.c | 12 +-- drivers/mmc/core/sd.c | 73 +- drivers/mmc/core/sdio.c | 11 +-- drivers/mmc/core/sdio_bus.c |6 +- drivers/mmc/core/sdio_cis.c | 10 +- drivers/mmc/core/sdio_io.c | 14 ++- drivers/mmc/core/sdio_irq.c | 24 ++-- drivers/mmc/host/at91_mci.c | 12 +- drivers/mmc/host/au1xmmc.c | 35 +++--- drivers/mmc/host/bfin_sdh.c |3 +- drivers/mmc/host/dw_mmc.c | 18 ++-- drivers/mmc/host/mmc_spi.c |9 +- drivers/mmc/host/mmci.c |8 +- drivers/mmc/host/msm_sdcc.c | 101 -- drivers/mmc/host/mvsdio.c | 42 +++- drivers/mmc/host/omap_hsmmc.c | 19 +--- drivers/mmc/host/pxamci.c |4 +- drivers/mmc/host/s3cmci.c |3 +- drivers/mmc/host/sdhci-pci.c| 17 ++-- drivers/mmc/host/sdhci-pxav3.c |7 +- drivers/mmc/host/sdhci.c| 218 +-- drivers/mmc/host/sdricoh_cs.c | 12 +- drivers/mmc/host/tifm_sd.c | 12 +-- drivers/mmc/host/tmio_mmc.c |4 +- drivers/mmc/host/tmio_mmc_pio.c |4 +- drivers/mmc/host/via-sdmmc.c| 33 +++ drivers/mmc/host/vub300.c | 54 +- drivers/mmc/host/wbsd.c | 72 ++ include/linux/mmc/host.h| 11 ++ 37 files changed, 510 insertions(+), 667 deletions(-) -- 1.7.6.405.gc1be0 -- 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/4] mmc: Update logging style
Convert pr_warning to pr_warn.
Coalesce format strings.
Align arguments.
Add missing \n.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/mmc/card/block.c |4 +-
drivers/mmc/card/queue.c |6 +---
drivers/mmc/card/sdio_uart.c | 10
drivers/mmc/core/bus.c|4 +-
drivers/mmc/core/core.c |9 +++
drivers/mmc/core/mmc.c| 28 ++--
drivers/mmc/core/mmc_ops.c|4 +-
drivers/mmc/core/sd.c | 46 +
drivers/mmc/core/sdio.c |5 +--
drivers/mmc/core/sdio_bus.c |4 +-
drivers/mmc/core/sdio_cis.c |7 ++---
drivers/mmc/core/sdio_irq.c |7 ++---
drivers/mmc/host/mmci.c |5 +--
drivers/mmc/host/omap_hsmmc.c |5 +--
drivers/mmc/host/s3cmci.c |3 +-
drivers/mmc/host/sdhci.c | 18 +++-
drivers/mmc/host/tifm_sd.c|3 +-
drivers/mmc/host/wbsd.c | 24 -
18 files changed, 82 insertions(+), 110 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c80bb6d..fe489b1 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1238,8 +1238,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *rqc)
case MMC_BLK_ECC_ERR:
if (brq-data.blocks 1) {
/* Redo read one sector at a time */
- pr_warning(%s: retrying using single block
read\n,
- req-rq_disk-disk_name);
+ pr_warn(%s: retrying using single block
read\n,
+ req-rq_disk-disk_name);
disable_multi = 1;
break;
}
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index dcad59c..f1fd979 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -197,14 +197,12 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
*card,
if (bouncesz 512) {
mqrq_cur-bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
if (!mqrq_cur-bounce_buf) {
- pr_warning(%s: unable to
- allocate bounce cur buffer\n,
+ pr_warn(%s: unable to allocate bounce cur
buffer\n,
mmc_card_name(card));
}
mqrq_prev-bounce_buf = kmalloc(bouncesz, GFP_KERNEL);
if (!mqrq_prev-bounce_buf) {
- pr_warning(%s: unable to
- allocate bounce prev buffer\n,
+ pr_warn(%s: unable to allocate bounce prev
buffer\n,
mmc_card_name(card));
kfree(mqrq_cur-bounce_buf);
mqrq_cur-bounce_buf = NULL;
diff --git a/drivers/mmc/card/sdio_uart.c b/drivers/mmc/card/sdio_uart.c
index 2c151e1..e264ee2 100644
--- a/drivers/mmc/card/sdio_uart.c
+++ b/drivers/mmc/card/sdio_uart.c
@@ -1082,8 +1082,8 @@ static int sdio_uart_probe(struct sdio_func *func,
return -ENOMEM;
if (func-class == SDIO_CLASS_UART) {
- pr_warning(%s: need info on UART class basic setup\n,
- sdio_func_id(func));
+ pr_warn(%s: need info on UART class basic setup\n,
+ sdio_func_id(func));
kfree(port);
return -ENOSYS;
} else if (func-class == SDIO_CLASS_GPS) {
@@ -1101,9 +1101,9 @@ static int sdio_uart_probe(struct sdio_func *func,
break;
}
if (!tpl) {
- pr_warning(
- %s: can't find tuple 0x91 subtuple 0 (SUBTPL_SIOREG) for GPS class\n,
- sdio_func_id(func));
+ pr_warn(
+ %s: can't find tuple 0x91 subtuple 0 (SUBTPL_SIOREG) for GPS class\n,
+ sdio_func_id(func));
kfree(port);
return -EINVAL;
}
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 6be4924..2e1f028 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -303,10 +303,10 @@ int mmc_add_card(struct mmc_card *card)
mmc_card_ddr_mode(card) ? DDR : ,
type);
} else {
- printk(KERN_INFO %s: new %s%s%s card at address %04x\n,
+ pr_info(%s: new %s%s%s card at address %04x\n,
mmc_hostname(card-host),
mmc_sd_card_uhs(card) ? ultra high speed :
- (mmc_card_highspeed(card) ? high speed : ),
+
Re: [PATCH/RESEND #3 5/7] arm: omap: smartreflex: clean ups all over
On Tue, 15 Nov 2011 10:46:03 +0200, Felipe Balbi said: - int srid; - int ip_type; + struct list_headnode; + struct platform_device *pdev; + struct omap_sr_nvalue_table *nvalue_table; + struct voltagedomain*voltdm; As long as you're de-tabifying the function names that caused the problem... int nvalue_count; - boolautocomp_active; - boolis_suspended; Why are you leaveing the rest of the struct tabified out to East Podunk? pgpBSmOgFjmVF.pgp Description: PGP signature
Re: [PATCH 4/4] mmc: Add mmc_host_level logging
On Wed, 2011-11-16 at 09:52 +0900, NamJae Jeon wrote: 2011/11/16 Joe Perches j...@perches.com: Centralize the pr_level uses of mmc_hostname into specific mmc_host_level calls to allow a flexible presentation style and shorten the code a bit. I don't know why pr_info should be surely replaced by mmc_host_info. if it is needed for only host name, I think that existing pr_info/err/debug is sufficient. Please trim your replies and read the patch description. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: Add mmc_host_level logging
2011/11/16 Joe Perches j...@perches.com: On Wed, 2011-11-16 at 09:52 +0900, NamJae Jeon wrote: 2011/11/16 Joe Perches j...@perches.com: Centralize the pr_level uses of mmc_hostname into specific mmc_host_level calls to allow a flexible presentation style and shorten the code a bit. I don't know why pr_info should be surely replaced by mmc_host_info. if it is needed for only host name, I think that existing pr_info/err/debug is sufficient. Please trim your replies and read the patch description. my concern is that they feel confuse when coder add print code because they should use mmc_hostlevel for hostname, and pr_level is used in the other case. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: Add mmc_host_level logging
On Wed, 2011-11-16 at 10:14 +0900, NamJae Jeon wrote: 2011/11/16 Joe Perches j...@perches.com: On Wed, 2011-11-16 at 09:52 +0900, NamJae Jeon wrote: 2011/11/16 Joe Perches j...@perches.com: Centralize the pr_level uses of mmc_hostname into specific mmc_host_level calls to allow a flexible presentation style and shorten the code a bit. I don't know why pr_info should be surely replaced by mmc_host_info. if it is needed for only host name, I think that existing pr_info/err/debug is sufficient. Please trim your replies and read the patch description. my concern is that they feel confuse when coder add print code because they should use mmc_hostlevel for hostname, and pr_level is used in the other case. That's one point of view. It is the same issue though as using dev_level when you have a struct device * and also using pr_level otherwise. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: Logging neatening
On Wed, 2011-11-16 at 10:48 +0900, NamJae Jeon wrote: [123K of untrimmed reply] If you wrote something, I didn't find it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: Logging neatening
On Wed, 2011-11-16 at 10:55 +0900, NamJae Jeon wrote: 2011/11/16 Joe Perches j...@perches.com: On Wed, 2011-11-16 at 10:48 +0900, NamJae Jeon wrote: [123K of untrimmed reply] If you wrote something, I didn't find it. - dev_info(pdev-dev, DW MMC controller at irq %d, -%d bit host data width, -%u deep fifo\n, + dev_info(pdev-dev, + DW MMC controller at irq %d, %d bit host data width, %u deep fifo\n, irq, width, fifo_size); I think that tab is needed this DW MMC controller at irq ? Argument alignment isn't always the right thing. Very long formats should not necessarily be aligned at the open parenthesis. It helps to determine when the format string or the dmesg output line length is too long. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mmc: Logging neatening
2011/11/16 Joe Perches j...@perches.com: On Wed, 2011-11-16 at 10:55 +0900, NamJae Jeon wrote: 2011/11/16 Joe Perches j...@perches.com: On Wed, 2011-11-16 at 10:48 +0900, NamJae Jeon wrote: [123K of untrimmed reply] If you wrote something, I didn't find it. - dev_info(pdev-dev, DW MMC controller at irq %d, - %d bit host data width, - %u deep fifo\n, + dev_info(pdev-dev, + DW MMC controller at irq %d, %d bit host data width, %u deep fifo\n, irq, width, fifo_size); I think that tab is needed this DW MMC controller at irq ? Argument alignment isn't always the right thing. Very long formats should not necessarily be aligned at the open parenthesis. It helps to determine when the format string or the dmesg output line length is too long. Okay~ I understand clearly. Thanks. Coalesce formats. Align arguments. Add pr_fmt, remove prefixes from format strings. Neaten DBG uses, rearrange argument order. Signed-off-by: Joe Perches j...@perches.com Reviewed-by: NamJae Jeon linkinj...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: Add mmc_host_level logging
On Tue, Nov 15, 2011 at 03:32:08PM -0800, Joe Perches wrote: Centralize the pr_level uses of mmc_hostname into specific mmc_host_level calls to allow a flexible presentation style and shorten the code a bit. drivers/mmc/host/msm_sdcc.c | 101 ++- The MSM ones at least are quite straightforward, so I'm fine with this part of the change. Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MTD: nand: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS
Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/mtd/nand/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index cce7b70..b68dd5e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -110,7 +110,7 @@ config MTD_NAND_AMS_DELTA config MTD_NAND_OMAP2 tristate NAND Flash device on OMAP2, OMAP3 and OMAP4 - depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) + depends on ARCH_OMAP2PLUS help Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 platforms. -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] OMAPDSS: HDMI: update static timing table
Hi Tomi,
On Mon, Nov 14, 2011 at 12:50 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-11-11 at 18:39 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add the vsync polarity, hsync polarity, interlace to hdmi_video_timings.
Remove the now duplicate structure hdmi_timings.
update the static table structure in HDMI with CEA/VESA code and mode.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 96
++--
drivers/video/omap2/dss/ti_hdmi.h | 14 ++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 20 +++---
3 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c56378c..f76ae47 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -88,42 +88,42 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_timings cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
- { {640, 480, 25200, 96, 16, 48, 2, 10, 33} , 0 , 0},
- { {1280, 720, 74250, 40, 440, 220, 5, 5, 20}, 1, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1},
- { {720, 480, 27027, 62, 16, 60, 6, 9, 30}, 0, 0},
- { {2880, 576, 108000, 256, 48, 272, 5, 5, 39}, 0, 0},
- { {1440, 240, 27027, 124, 38, 114, 3, 4, 15}, 0, 0},
- { {1440, 288, 27000, 126, 24, 138, 3, 2, 19}, 0, 0},
- { {1920, 540, 74250, 44, 528, 148, 5, 2, 15}, 1, 1},
- { {1920, 540, 74250, 44, 88, 148, 5, 2, 15}, 1, 1},
- { {1920, 1080, 148500, 44, 88, 148, 5, 4, 36}, 1, 1},
- { {720, 576, 27000, 64, 12, 68, 5, 5, 39}, 0, 0},
- { {1440, 576, 54000, 128, 24, 136, 5, 5, 39}, 0, 0},
- { {1920, 1080, 148500, 44, 528, 148, 5, 4, 36}, 1, 1},
- { {2880, 480, 108108, 248, 64, 240, 6, 9, 30}, 0, 0},
- { {1920, 1080, 74250, 44, 638, 148, 5, 4, 36}, 1, 1},
- /* VESA From Here */
- { {640, 480, 25175, 96, 16, 48, 2 , 11, 31}, 0, 0},
- { {800, 600, 4, 128, 40, 88, 4 , 1, 23}, 1, 1},
- { {848, 480, 33750, 112, 16, 112, 8 , 6, 23}, 1, 1},
- { {1280, 768, 79500, 128, 64, 192, 7 , 3, 20}, 1, 0},
- { {1280, 800, 83500, 128, 72, 200, 6 , 3, 22}, 1, 0},
- { {1360, 768, 85500, 112, 64, 256, 6 , 3, 18}, 1, 1},
- { {1280, 960, 108000, 112, 96, 312, 3 , 1, 36}, 1, 1},
- { {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38}, 1, 1},
- { {1024, 768, 65000, 136, 24, 160, 6, 3, 29}, 0, 0},
- { {1400, 1050, 121750, 144, 88, 232, 4, 3, 32}, 1, 0},
- { {1440, 900, 106500, 152, 80, 232, 6, 3, 25}, 1, 0},
- { {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30}, 1, 0},
- { {1366, 768, 85500, 143, 70, 213, 3, 3, 24}, 1, 1},
- { {1920, 1080, 148500, 44, 148, 80, 5, 4, 36}, 1, 1},
- { {1280, 768, 68250, 32, 48, 80, 7, 3, 12}, 0, 1},
- { {1400, 1050, 101000, 32, 48, 80, 4, 3, 23}, 0, 1},
- { {1680, 1050, 119000, 32, 48, 80, 6, 3, 21}, 0, 1},
- { {1280, 800, 79500, 32, 48, 80, 6, 3, 14}, 0, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1}
+static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
+{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 88, 148, 5, 2, 15, 1, 1, 1}, {5, HDMI_HDMI} },
+{ {1440, 240, 27027, 124, 38, 114, 3, 4, 15, 0, 0, 1}, {6, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 88, 148, 5, 4, 36, 1, 1, 0}, {16, HDMI_HDMI} },
+{ {720, 576, 27000, 64, 12, 68, 5, 5, 39, 0, 0, 0}, {17, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 440, 220, 5, 5, 20, 1, 1, 0}, {19, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 528, 148, 5, 2, 15, 1, 1, 1}, {20, HDMI_HDMI} },
+{ {1440, 288, 27000, 126, 24, 138, 3, 2, 19, 0, 0, 1}, {21, HDMI_HDMI} },
+{ {1440, 576, 54000, 128, 24, 136, 5, 5, 39, 0, 0, 0}, {29, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 528, 148, 5, 4, 36, 1, 1, 0}, {31, HDMI_HDMI} },
+{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
+{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
+{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+/* VESA From Here */
+{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
+{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
+{ {848, 480, 33750, 112, 16, 112, 8 , 6, 23, 1, 1, 0}, {0xE, HDMI_DVI} },
+{ {1280, 768, 79500, 128, 64, 192, 7 , 3, 20, 1, 0, 0}, {0x17, HDMI_DVI} },
+{ {1280, 800, 83500, 128, 72, 200, 6 , 3, 22, 1, 0, 0}, {0x1C, HDMI_DVI} },
+{ {1360, 768, 85500, 112, 64, 256, 6 , 3, 18, 1, 1, 0}, {0x27, HDMI_DVI} },
+{ {1280, 960, 108000, 112, 96, 312, 3 , 1, 36, 1, 1, 0}, {0x20, HDMI_DVI} },
+{ {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38, 1, 1, 0}, {0x23, HDMI_DVI}
},
+{ {1024, 768, 65000, 136, 24, 160, 6,
Re: [PATCH] MTD: nand: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS
On Tuesday 15 November 2011 11:22 PM, Russell King - ARM Linux wrote: On Tue, Nov 15, 2011 at 03:52:36PM +0530, Shubhrajyoti D wrote: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of oring with ARCH2/3/4. Reported-by: Russell King li...@arm.linux.org.uk Thanks, but please make this rmk+ker...@arm.linux.org.uk. yes , will correct it. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/mtd/nand/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index cce7b70..b68dd5e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -110,7 +110,7 @@ config MTD_NAND_AMS_DELTA config MTD_NAND_OMAP2 tristate NAND Flash device on OMAP2, OMAP3 and OMAP4 -depends on ARM (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) +depends on ARCH_OMAP2PLUS help Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 platforms. -- 1.7.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: Add mmc_host_level logging
2011/11/16 Joe Perches j...@perches.com: Centralize the pr_level uses of mmc_hostname into specific mmc_host_level calls to allow a flexible presentation style and shorten the code a bit. Add mmc_host_level macros. Convert the logging calls from: pr_level(%s: ..., mmc_hostname(foo) to: mmc_host_level(foo, ...) Add a couple of missing newlines. Convert bare printks to pr_cont where appropriate. Spelling/typo fix of initialiazed to initialized. Signed-off-by: Joe Perches j...@perches.com Reviewed-by: NamJae Jeon linkinj...@gmail.com --- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: HDMI: change the timing match logic
On Mon, Nov 14, 2011 at 1:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Fri, 2011-11-11 at 18:39 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 162
---
1 files changed, 67 insertions(+), 95 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f76ae47..b859350 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -58,8 +58,6 @@
#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
-#define OMAP_HDMI_TIMINGS_NB 34
-
#define HDMI_DEFAULT_REGN 16
#define HDMI_DEFAULT_REGM2 1
@@ -88,7 +86,7 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+static const struct hdmi_config cea_timings[] = {
{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
@@ -104,6 +102,8 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+};
+static const struct hdmi_config vesa_timings[] = {
/* VESA From Here */
{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
@@ -126,39 +126,6 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {0x55, HDMI_DVI} }
};
-/*
- * This is a static mapping array which maps the timing values
- * with corresponding CEA / VESA code
- */
-static const int code_index[OMAP_HDMI_TIMINGS_NB] = {
- 1, 19, 4, 2, 37, 6, 21, 20, 5, 16, 17, 29, 31, 35, 32,
- /* --15 CEA 17-- vesa*/
- 4, 9, 0xE, 0x17, 0x1C, 0x27, 0x20, 0x23, 0x10, 0x2A,
- 0X2F, 0x3A, 0X51, 0X52, 0x16, 0x29, 0x39, 0x1B
-};
-
-/*
- * This is reverse static mapping which maps the CEA / VESA code
- * to the corresponding timing values
- */
-static const int code_cea[39] = {
- -1, 0, 3, 3, 2, 8, 5, 5, -1, -1,
- -1, -1, -1, -1, -1, -1, 9, 10, 10, 1,
- 7, 6, 6, -1, -1, -1, -1, -1, -1, 11,
- 11, 12, 14, -1, -1, 13, 13, 4, 4
-};
-
-static const int code_vesa[85] = {
- -1, -1, -1, -1, 15, -1, -1, -1, -1, 16,
- -1, -1, -1, -1, 17, -1, 23, -1, -1, -1,
- -1, -1, 29, 18, -1, -1, -1, 32, 19, -1,
- -1, -1, 21, -1, -1, 22, -1, -1, -1, 20,
- -1, 30, 24, -1, -1, -1, -1, 25, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, 31, 26, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, 27, 28, -1, 33};
-
static int hdmi_runtime_get(void)
{
int r;
@@ -188,82 +155,88 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int get_timings_index(void)
+static bool hdmi_find_code(const struct hdmi_config *timings_arr,
+ int len, struct hdmi_config *timing)
{
- int code;
+ int i;
- if (hdmi.mode == 0)
- code = code_vesa[hdmi.code];
- else
- code = code_cea[hdmi.code];
+ for (i = 0; i len; i++) {
+ if (timings_arr[i].cm.code == hdmi.code) {
+ *timing = timings_arr[i];
+ return true;
+ }
+ }
+
+ return false;
+}
You could return the hdmi_config pointer instead of making a copy and
returning a bool.
In this function i'm passing the timing value and finally there needs
to be one copy whether it is in this function or after the return,
because the timings array is a const and dssdev-paneltimings and
config timings are not, so do you see any benefit of doing that later
or suggest any other method?
You shouldn't use hdmi.code in this function, but get the code as a
parameter.
- if (code == -1) {
+static void hdmi_get_timings(struct hdmi_config *timing)
+{
+ int r;
+
+ if (hdmi.mode == 0) {
+ r = hdmi_find_code(vesa_timings,
+ ARRAY_SIZE(vesa_timings), timing);
+ } else {
+ r = hdmi_find_code(cea_timings,
+ ARRAY_SIZE(cea_timings), timing);
+ }
+ if (!r) {
/* HDMI code 4
Re: [PATCH v16 09/12] OMAP: dmtimer: low-power mode support
On Tue, Nov 15, 2011 at 11:27 PM, Omar Ramirez Luna or.r...@gmail.com wrote:
Hi Tarun,
On Tue, Sep 20, 2011 at 6:30 AM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Clock is enabled only when timer is started and disabled when the the timer
is stopped. Therefore before accessing registers in functions clock is
enabled
and then disabled back at the end of access. Context save is done dynamically
whenever the registers are modified. Context restore is called when context
is
lost.
Now that handling of the clock has been decoupled from
omap_dm_timer_request_specific/free and placed in start/stop
functions, there is a possible irq lock inversion dependency
detected for any attempt to enable the clock from soft|hard irq.
My use case is as follows:
DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
for processing the message, when it reaches tidspbridge it turns out
that the DSP wants to enable a gpt timer; however, locks involved
clocks_mutex and dm_timer_lock now could cause a deadlock as they
have been called from unsafe contexts in the past
(http://pastebin.com/7Dtz8t0f).
Is the intention to restrict enabling the dmtimer clocks from hard|soft irqs?
The aim is to prevent client drivers perform clock enable/disable independently.
Instead just use the request/start/stop APIs. In that way we can make clock
enable/disable functions static in the future.
...
@@ -303,6 +342,22 @@ void omap_dm_timer_stop(struct omap_dm_timer *timer)
rate = clk_get_rate(timer-fclk);
__omap_dm_timer_stop(timer, timer-posted, rate, is_omap2);
+
+ if (timer-loses_context) {
+ if (timer-get_context_loss_count)
+ timer-ctx_loss_count =
+ timer-get_context_loss_count(timer-pdev-dev);
+ }
+
+ /*
+ * Since the register values are computed and written within
+ * __omap_dm_timer_stop, we need to use read to retrieve the
+ * context.
+ */
+ timer-context.tclr =
+ omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
+ timer-context.tisr = __raw_readl(timer-irq_stat);
+ omap_dm_timer_disable(timer);
}
EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
I didn't review the whole patch, but at least this part is not in
mainline, it seems like the patch modified by Tony and the v16 were
not the same.
I could diff and include the missing parts, if someone can confirm
that we need v16, which I believe so, since current stop function
doesn't call omap_dm_timer_disable.
You are right. This change some how got missed in mainline.
I have posted a patch for this already.
--
Tarun
Regards,
Omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] I2C: OMAP: fix the clearing of interrupts
The register IRQENABLE_CLR is a bit map of interrupt events. All the bits have to be cleared to clear the interrupts. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 2dfb631..c7c6bb2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -309,7 +309,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev) dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); if (dev-rev = OMAP_I2C_REV_ON_4430) - omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1); + omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 0x6FFF); else omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
