Re: [PATCH v4 1/3] ARM: OMAP: Beagle: revision detection
* Robert Nelson robertcnel...@gmail.com [100816 17:29]:
Due to the omap3530 ES3.0 Silicon being used on both the
B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
routines to differentiate the Beagle Boards.
However gpio pins 171,172,173 where setup for this prupose, so
lets use them.
Changes:
for older U-Boot's, use omap_mux_init_gpio()
keep Beagle Rev in board-omap3beagle.c
Tested on Beagle Revisions: B5, C2, C4, and xMA
Looks good, just one minor comment below.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
Cc: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 79
+++
1 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 87969c7..01a288f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -50,6 +50,84 @@
#define NAND_BLOCK_SIZE SZ_128K
+/*
+ * OMAP3 Beagle revision
+ * Run time detection of Beagle revision is done by reading GPIO.
+ * GPIO ID -
+ * AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
+ * C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
+ * C4 = GPIO173, GPIO172, GPIO171: 1 0 1
+ * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ */
+enum {
+ OMAP3BEAGLE_BOARD_AXBX = 0,
+ OMAP3BEAGLE_BOARD_C1_3,
+ OMAP3BEAGLE_BOARD_C4,
+ OMAP3BEAGLE_BOARD_XM,
+};
+
+static u8 omap3_beagle_version;
+
+u8 get_omap3_beagle_rev(void)
+{
+ return omap3_beagle_version;
+}
Please make this static u8 get_omap3_beagle_rev().
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] iommu: fix end address of vm area comparation in alloc_iovm_area
From: Hiroshi DOYU [hiroshi.d...@nokia.com] Sent: Tuesday, August 17, 2010 12:27 AM To: Guzman Lugo, Fernando Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kanigeri, Hari Subject: Re: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: RE: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area Date: Tue, 17 Aug 2010 06:48:14 +0200 From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando [fernando.l...@ti.com] Sent: Monday, August 16, 2010 10:51 PM To: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org Cc: hiroshi.d...@nokia.com; Kanigeri, Hari Subject: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area From cc48c0adaee97c8385a356aefa5b64a51818b4fd Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Mon, 16 Aug 2010 22:28:24 -0500 Subject: [PATCH] iommu: fix end address of vm area comparation in alloc_iovm_area End address of the vm area is “start + bytes -1”, not “start + byte”. This patch fixes that issue by doing an inclusive comparison with tmp-da_start. This issue was preventing allocate an area of size exactly the same than the free area. I did no change the value of da_end of each vm area because it is used to get area size in several places. Ok for me. Is this patch against the latest? not it isn't, but I don't think it could have issues applying. However I will resend it, base against the latest and include you ack. Regards, Fernando. -- 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: linux-next: manual merge of the sound-asoc tree with the omap tree
* Stephen Rothwell s...@canb.auug.org.au [100817 05:14]: Hi all, Today's linux-next merge of the sound-asoc tree got a conflict in arch/arm/mach-omap2/board-n8x0.c between commits 1c37553eb1778802f0e7b6730df36542752e801e (omap: n8x0: Cleanup i2c1 and menelaus registration) and 69be0f6f4b8e3be992ab6a333a3a82e043784c52 (omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810) from the omap tree and commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 (ASoC: multi-component - ASoC Multi-Component Support) from the sound-asoc tree. I couldn't figure this out, so I effectively reverted the part of the latter commit affecting that file. Is there no way that the latter commit can be broken up into smaller self contained pieces? Let's let Jarkko and Liam to queue these along with the other ASoC patches, I'll drop them from omap for-next. Jarkko, can you please rebase them? 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: linux-next: manual merge of the sound-asoc tree with the omap tree
On Tue, 17 Aug 2010 09:15:59 +0300 Tony Lindgren t...@atomide.com wrote: * Stephen Rothwell s...@canb.auug.org.au [100817 05:14]: Hi all, Today's linux-next merge of the sound-asoc tree got a conflict in arch/arm/mach-omap2/board-n8x0.c between commits 1c37553eb1778802f0e7b6730df36542752e801e (omap: n8x0: Cleanup i2c1 and menelaus registration) and 69be0f6f4b8e3be992ab6a333a3a82e043784c52 (omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810) from the omap tree and commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 (ASoC: multi-component - ASoC Multi-Component Support) from the sound-asoc tree. I couldn't figure this out, so I effectively reverted the part of the latter commit affecting that file. Is there no way that the latter commit can be broken up into smaller self contained pieces? Let's let Jarkko and Liam to queue these along with the other ASoC patches, I'll drop them from omap for-next. Jarkko, can you please rebase them? I think it's easier if you keep them in l-o for-next and I send a patch to ASoC multi-component removing board-n8x0.c changes. That way the N810 audio is usable in linux-omap before m-c merge and m-c patch touch less board files. -- 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: linux-next: manual merge of the sound-asoc tree with the omap tree
* Jarkko Nikula jhnik...@gmail.com [100817 09:27]: On Tue, 17 Aug 2010 09:15:59 +0300 Tony Lindgren t...@atomide.com wrote: * Stephen Rothwell s...@canb.auug.org.au [100817 05:14]: Hi all, Today's linux-next merge of the sound-asoc tree got a conflict in arch/arm/mach-omap2/board-n8x0.c between commits 1c37553eb1778802f0e7b6730df36542752e801e (omap: n8x0: Cleanup i2c1 and menelaus registration) and 69be0f6f4b8e3be992ab6a333a3a82e043784c52 (omap: n8x0: Register i2c2 and add board info with tlv320aic3xfor N810) from the omap tree and commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 (ASoC: multi-component - ASoC Multi-Component Support) from the sound-asoc tree. I couldn't figure this out, so I effectively reverted the part of the latter commit affecting that file. Is there no way that the latter commit can be broken up into smaller self contained pieces? Let's let Jarkko and Liam to queue these along with the other ASoC patches, I'll drop them from omap for-next. Jarkko, can you please rebase them? I think it's easier if you keep them in l-o for-next and I send a patch to ASoC multi-component removing board-n8x0.c changes. That way the N810 audio is usable in linux-omap before m-c merge and m-c patch touch less board files. OK sounds good to me. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/13] dmtimer: hwmod: OMAP: rev field to identify timer version
Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 16, 2010 5:30 PM
To: DebBarma, Tarun Kanti
Cc: linux-omap@vger.kernel.org; Basak, Partha; Shilimkar, Santosh;
Gopinath, Thara; Paul Walmsley; Kevin Hilman; Tony Lindgren
Subject: Re: [PATCH 3/13] dmtimer: hwmod: OMAP: rev field to identify
timer version
Hi Tarun,
You series is missing the omap4 hwmod data. You should rebase it on the
latest pm_wip/hwmods-omap4 and add the hwmod data for the timers.
For further details please read this:
http://www.spinics.net/lists/linux-omap/msg34700.html
OK.
On 8/14/2010 5:38 PM, DebBarma, Tarun Kanti wrote:
This patch adds revision (.rev) to hwmod class to identify different
timer types. In the present implementation it is used to identify
millisecond timers, legacy timers and highlander timers present in
OMAP4. This identification serves following purposes:
(1) select appropriate timers register maps associated with legacy
ip timers and highlander ip timers present on OMAP4.
(2) select millisecond timers to perform specific operations upon
them during _probe()
Signed-off-by: Partha Basakp-bas...@ti.com
Signed-off-by: Santosh Shilimkarsantosh.shilim...@ti.com
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Tony Lindgrent...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +++
arch/arm/plat-omap/include/plat/dmtimer.h |5 +
3 files changed, 11 insertions(+), 0 deletions(-)
mode change 100644 = 100755 arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
mode change 100644 = 100755 arch/arm/plat-
omap/include/plat/dmtimer.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-
omap2/omap_hwmod_3xxx_data.c
index 6b9e7a1..98fcf3d 100755
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -17,6 +17,7 @@
#includemach/irqs.h
#includeplat/cpu.h
#includeplat/dma.h
+#includeplat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -115,6 +116,7 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_1ms_sysc = {
static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
.name = timer_1ms,
.sysc =omap3xxx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_MILLISECOND,
};
@@ -131,6 +133,7 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_sysc = {
static struct omap_hwmod_class omap3xxx_timer_hwmod_class = {
.name = timer,
.sysc =omap3xxx_timer_sysc,
+ .rev = OMAP_TIMER_IP_LEGACY,
};
/* timer10 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 9736a49..c5478f7
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -4339,6 +4340,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_1ms_sysc = {
static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
.name = timer_1ms,
.sysc =omap44xx_timer_1ms_sysc,
+ .rev = OMAP_TIMER_MILLISECOND,
That information is redundant, you already know from the class that this
is a 1ms timer.
If you need to get that information from the driver, you can set this
settings in device data using the class name at device init time.
Moreover, this rev field is supposed to contain the revision per class
so in your case it should contain OMAP_TIMER_IP_LEGACY.
Following changes will be posted in the next series:
(1) OMAP_TIMER_IP_VERSION_1 replaces OMAP_TIMER_IP_LEGACY
(2) OMAP_TIMER_MILLISECOND replaced by OPAM_TIMER_IP_VERSION_1
(3) add is_ms_timer field in struct omap_dmtimer_platform_data.
this field is updated during device build based upon the .name=timer_1ms and
used during probe() to skip calling pm_runtime_enable() for millisecond timers
since the framework is not fully functional during early init.
};
static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
@@ -4353,6 +4355,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_timer_sysc = {
static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
.name = timer,
.sysc =omap44xx_timer_sysc,
+ .rev = OMAP_TIMER_IP_VERSION_2,
};
/* timer1 */
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-
omap/include/plat/dmtimer.h
index 20f1054..2926dc6
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -44,6 +44,11 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW 0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE 0x02
+/* timer ip
[PATCH 3/3] RTC:s35390a: Add update_irq (per Min interrupt) support
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/rtc/rtc-s35390a.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index d456b70..a6b0412 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -391,6 +391,35 @@ static int s35390a_rtc_set_irq_freq(struct device *dev,
int freq)
return s35390a_set_irq_freq(to_i2c_client(dev), freq);
}
+static int s35390a_update_irq_enable(struct i2c_client *client,
+ unsigned enabled)
+{
+ struct s35390a *s35390a = i2c_get_clientdata(client);
+ char buf[1];
+
+ if (s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, buf, sizeof(buf)) 0)
+ return -EIO;
+
+ /* This chip returns the bits of each byte in reverse order */
+ buf[0] = bitrev8(buf[0]);
+
+ buf[0] = ~S35390A_INT1_MODE_MASK;
+ if (enabled)
+ buf[0] |= S35390A_INT1_MODE_PMIN_EDG;
+ else
+ buf[0] |= S35390A_INT1_MODE_NOINTR;
+
+ /* This chip expects the bits of each byte in reverse order */
+ buf[0] = bitrev8(buf[0]);
+
+ return s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, buf, sizeof(buf));
+}
+
+static int s35390a_rtc_update_irq_enable(struct device *dev, unsigned enabled)
+{
+ return s35390a_update_irq_enable(to_i2c_client(dev), enabled);
+}
+
static void s35390a_work(struct work_struct *work)
{
struct s35390a *s35390a;
@@ -445,6 +474,7 @@ static const struct rtc_class_ops s35390a_rtc_ops = {
.read_alarm = s35390a_rtc_read_alarm,
.irq_set_freq = s35390a_rtc_set_irq_freq,
.irq_set_state = s35390a_rtc_freq_irq_enable,
+ .update_irq_enable = s35390a_rtc_update_irq_enable,
};
static struct i2c_driver s35390a_driver;
--
1.6.2.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
[PATCH 0/3] RTC:A35390A: Add Interrupt API interfaces
From: Vaibhav Hiremath hvaib...@ti.com This patch adds support for interrupt API interfaces like, - Alarm interrupt - Periodic interrupt - Per minute interrupt Vaibhav Hiremath (3): RTC:s35390a: Add Alarm interrupt support RTC:s35390a: Add Periodic interrupt support RTC:s35390a: Add update_irq (per Min interrupt) support drivers/rtc/rtc-s35390a.c | 302 - 1 files changed, 299 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] RTC:s35390a: Add Alarm interrupt support
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/rtc/rtc-s35390a.c | 208 -
1 files changed, 205 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index f789e00..3d34fc5 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -19,6 +19,8 @@
#define S35390A_CMD_STATUS10
#define S35390A_CMD_STATUS21
#define S35390A_CMD_TIME1 2
+#define S35390A_CMD_TIME2 3
+#define S35390A_CMD_INT1_REG1 4
#define S35390A_BYTE_YEAR 0
#define S35390A_BYTE_MONTH 1
@@ -28,12 +30,24 @@
#define S35390A_BYTE_MINS 5
#define S35390A_BYTE_SECS 6
+#define S35390A_ALRM_BYTE_WDAY 0
+#define S35390A_ALRM_BYTE_HOURS1
+#define S35390A_ALRM_BYTE_MINS 2
+
#define S35390A_FLAG_POC 0x01
#define S35390A_FLAG_BLD 0x02
#define S35390A_FLAG_24H 0x40
#define S35390A_FLAG_RESET 0x80
#define S35390A_FLAG_TEST 0x01
+#define S35390A_INT1_MODE_MASK 0xF
+
+#define S35390A_INT1_MODE_NOINTR 0x0
+#define S35390A_INT1_MODE_FREQ 0x1
+#define S35390A_INT1_MODE_PMIN_EDG 0x2
+#define S35390A_INT1_MODE_PMIN_STDY0x3
+#define S35390A_INT1_MODE_ALARM0x4
+
static const struct i2c_device_id s35390a_id[] = {
{ s35390a, 0 },
{ }
@@ -44,6 +58,8 @@ struct s35390a {
struct i2c_client *client[8];
struct rtc_device *rtc;
int twentyfourhour;
+ struct work_struct work;
+ struct rtc_wkalrm alarm;
};
static int s35390a_set_reg(struct s35390a *s35390a, int reg, char *buf, int
len)
@@ -194,9 +210,179 @@ static int s35390a_rtc_set_time(struct device *dev,
struct rtc_time *tm)
return s35390a_set_datetime(to_i2c_client(dev), tm);
}
+static int s35390a_alarm_irq_enable(struct i2c_client *client, unsigned
enabled)
+{
+ struct s35390a *s35390a = i2c_get_clientdata(client);
+ struct rtc_wkalrm *alm;
+ char buf[3], sts;
+ int err, i;
+
+ err = s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, sts, sizeof(sts));
+ if (err) {
+ dev_err(client-dev, %s: failed to read STS2 reg\n,
+ __func__);
+ return err;
+ }
+
+ /* This chip returns the bits of each byte in reverse order */
+ sts = bitrev8(sts);
+
+ sts = ~S35390A_INT1_MODE_MASK;
+
+ if (enabled)
+ sts |= S35390A_INT1_MODE_ALARM;
+ else
+ sts |= S35390A_INT1_MODE_NOINTR;
+
+ /* This chip expects the bits of each byte in reverse order */
+ sts = bitrev8(sts);
+
+ err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, sts, sizeof(sts));
+ if (err) {
+ dev_err(client-dev, %s: failed to set STS2 reg\n, __func__);
+ return err;
+ }
+
+ alm = s35390a-alarm;
+
+ if (alm-time.tm_wday != -1)
+ buf[S35390A_ALRM_BYTE_WDAY] = bin2bcd(alm-time.tm_wday) | 0x80;
+
+ buf[S35390A_ALRM_BYTE_HOURS] = s35390a_hr2reg(s35390a,
+ alm-time.tm_hour) | 0x80;
+ buf[S35390A_ALRM_BYTE_MINS] = bin2bcd(alm-time.tm_min) | 0x80;
+
+ if (alm-time.tm_hour = 12)
+ buf[S35390A_ALRM_BYTE_HOURS] |= 0x40;
+
+ /* This chip expects the bits of each byte to be in reverse order */
+ for (i = 0; i 3; ++i)
+ buf[i] = bitrev8(buf[i]);
+
+ return s35390a_set_reg(s35390a, S35390A_CMD_INT1_REG1, buf,
+ sizeof(buf));
+}
+
+static int s35390a_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
+{
+ return s35390a_alarm_irq_enable(to_i2c_client(dev), enabled);
+}
+
+static int s35390a_set_alarm(struct i2c_client *client, struct rtc_wkalrm *alm)
+{
+ struct s35390a *s35390a = i2c_get_clientdata(client);
+
+ dev_dbg(client-dev, %s: alm is secs=%d, mins=%d, hours=%d mday=%d,
+ mon=%d, year=%d, wday=%d\n, __func__, alm-time.tm_sec,
+ alm-time.tm_min, alm-time.tm_hour, alm-time.tm_mday,
+ alm-time.tm_mon, alm-time.tm_year, alm-time.tm_wday);
+
+ /* Copy Alarm time */
+ memcpy(s35390a-alarm, alm, sizeof(s35390a-alarm));
+
+ return 0;
+}
+
+static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
+{
+ return s35390a_set_alarm(to_i2c_client(dev), alm);
+}
+
+static int s35390a_read_alarm(struct i2c_client *client, struct rtc_wkalrm
*alm)
+{
+ struct s35390a *s35390a = i2c_get_clientdata(client);
+ char buf[3], sts;
+ int i, err;
+
+ if (s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, sts,
+ sizeof(sts)) 0)
+ return -EIO;
+
+ /* This chip returns the bits of each byte in reverse order */
+ sts = bitrev8(sts);
+
+
[PATCH 2/3] RTC:s35390a: Add Periodic interrupt support
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/rtc/rtc-s35390a.c | 66 -
1 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index 3d34fc5..d456b70 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -332,6 +332,65 @@ static int s35390a_rtc_read_alarm(struct device *dev,
struct rtc_wkalrm *alm)
return s35390a_read_alarm(to_i2c_client(dev), alm);
}
+static int s35390a_freq_irq_enable(struct i2c_client *client, unsigned enabled)
+{
+ struct s35390a *s35390a = i2c_get_clientdata(client);
+ char buf[1];
+ int err;
+
+ err = s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, buf, sizeof(buf));
+ if (err) {
+ dev_err(client-dev, %s: failed to read STS2 reg\n,
+ __func__);
+ return err;
+ }
+
+ /* This chip returns the bits of each byte in reverse order */
+ buf[0] = bitrev8(buf[0]);
+
+ buf[0] = ~S35390A_INT1_MODE_MASK;
+ if (enabled)
+ buf[0] |= S35390A_INT1_MODE_FREQ;
+ else
+ buf[0] |= S35390A_INT1_MODE_NOINTR;
+
+ /* This chip expects the bits of each byte in reverse order */
+ buf[0] = bitrev8(buf[0]);
+
+ err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, buf, sizeof(buf));
+ if (err) {
+ dev_err(client-dev, %s: failed to set STS2 reg\n, __func__);
+ return err;
+ }
+
+ if (enabled) {
+ buf[0] = s35390a-rtc-irq_freq;
+ buf[0] = bitrev8(buf[0]);
+ err = s35390a_set_reg(s35390a, S35390A_CMD_INT1_REG1, buf,
+ sizeof(buf));
+ }
+
+ return err;
+}
+
+static int s35390a_rtc_freq_irq_enable(struct device *dev, int enabled)
+{
+ return s35390a_freq_irq_enable(to_i2c_client(dev), enabled);
+}
+
+static int s35390a_set_irq_freq(struct i2c_client *client, int freq)
+{
+ if (!is_power_of_2(freq) || (freq 16))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int s35390a_rtc_set_irq_freq(struct device *dev, int freq)
+{
+ return s35390a_set_irq_freq(to_i2c_client(dev), freq);
+}
+
static void s35390a_work(struct work_struct *work)
{
struct s35390a *s35390a;
@@ -354,6 +413,8 @@ static void s35390a_work(struct work_struct *work)
if (buf[0] BIT(2)) {
rtc_update_irq(s35390a-rtc, 1, RTC_IRQF | RTC_AF);
s35390a_alarm_irq_enable(client, 0);
+ } else if (buf[0] BIT(0)) {
+ rtc_update_irq(s35390a-rtc, 1, RTC_IRQF | RTC_PF);
}
enable_irq(client-irq);
@@ -382,7 +443,8 @@ static const struct rtc_class_ops s35390a_rtc_ops = {
.alarm_irq_enable = s35390a_rtc_alarm_irq_enable,
.set_alarm = s35390a_rtc_set_alarm,
.read_alarm = s35390a_rtc_read_alarm,
-
+ .irq_set_freq = s35390a_rtc_set_irq_freq,
+ .irq_set_state = s35390a_rtc_freq_irq_enable,
};
static struct i2c_driver s35390a_driver;
@@ -465,6 +527,8 @@ static int s35390a_probe(struct i2c_client *client,
err = PTR_ERR(s35390a-rtc);
goto exit_intr;
}
+ s35390a-rtc-irq_freq = 0;
+ s35390a-rtc-max_user_freq = 16;
return 0;
--
1.6.2.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 V2] OMAP: DSS2: don't power off a panel twice
Is there any feedback about this patch,
Tested-by: Bryan Wu bryan...@canonical.com
-Bryan
On 08/11/2010 02:50 PM, Bryan Wu wrote:
Tested on my Beagle board. It fixed the issue.
Thanks,
-Bryan
On 08/11/2010 11:19 AM, Stanley.Miao wrote:
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now check the state of a dssdev
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-acx565akm.c |6 ++
drivers/video/omap2/displays/panel-generic.c |6 ++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 ++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 ++
drivers/video/omap2/displays/panel-taal.c |6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c|6 ++
.../video/omap2/displays/panel-tpo-td043mtea1.c|6 ++
7 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index 1f8eb70..374cbeb 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -587,6 +587,9 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
mutex_lock(md-mutex);
r = omapdss_sdi_display_enable(dssdev);
@@ -642,6 +645,9 @@ static void acx_panel_power_off(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
mutex_lock(md-mutex);
if (!md-enabled) {
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..395a68d 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -39,6 +39,9 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -58,6 +61,9 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..0c6896c 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -43,6 +43,9 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -65,6 +68,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..9a138f6 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -135,6 +135,9 @@ static int sharp_ls_power_on(struct omap_dss_device
*dssdev)
{
int r = 0;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -157,6 +160,9 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index aaf5d30..c649f06 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -635,6 +635,9 @@ static int taal_power_on(struct omap_dss_device *dssdev)
u8 id1, id2, id3;
int r;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
if (dssdev-platform_enable) {
r = dssdev-platform_enable(dssdev);
if (r)
@@ -715,6 +718,9 @@ static void taal_power_off(struct omap_dss_device
*dssdev)
{
struct taal_data *td =
Re: [PATCH V2] OMAP: DSS2: don't power off a panel twice
It should be Tomi to maintain DSS2. I didn't get any response from Tomi.
Stanley.
Bryan Wu wrote:
Is there any feedback about this patch,
Tested-by: Bryan Wu bryan...@canonical.com
-Bryan
On 08/11/2010 02:50 PM, Bryan Wu wrote:
Tested on my Beagle board. It fixed the issue.
Thanks,
-Bryan
On 08/11/2010 11:19 AM, Stanley.Miao wrote:
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now check the state of a dssdev
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-acx565akm.c |6 ++
drivers/video/omap2/displays/panel-generic.c |6 ++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 ++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 ++
drivers/video/omap2/displays/panel-taal.c |6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c|6 ++
.../video/omap2/displays/panel-tpo-td043mtea1.c|6 ++
7 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index 1f8eb70..374cbeb 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -587,6 +587,9 @@ static int acx_panel_power_on(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
mutex_lock(md-mutex);
r = omapdss_sdi_display_enable(dssdev);
@@ -642,6 +645,9 @@ static void acx_panel_power_off(struct omap_dss_device
*dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
mutex_lock(md-mutex);
if (!md-enabled) {
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..395a68d 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -39,6 +39,9 @@ static int generic_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -58,6 +61,9 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..0c6896c 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -43,6 +43,9 @@ static int sharp_lq_panel_power_on(struct omap_dss_device
*dssdev)
{
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -65,6 +68,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..9a138f6 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -135,6 +135,9 @@ static int sharp_ls_power_on(struct omap_dss_device *dssdev)
{
int r = 0;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -157,6 +160,9 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index aaf5d30..c649f06 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -635,6 +635,9 @@ static int taal_power_on(struct omap_dss_device *dssdev)
u8 id1, id2, id3;
int r;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
if (dssdev-platform_enable) {
r = dssdev-platform_enable(dssdev);
if (r)
@@ -715,6 +718,9 @@ static void taal_power_off(struct
Re: [PATCH 1/3] RTC:s35390a: Add Alarm interrupt support
On Tue, Aug 17, 2010 at 10:48:39AM +0200, ext hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
you need a description here.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
[snip]
+static void s35390a_work(struct work_struct *work)
+{
+ struct s35390a *s35390a;
+ struct i2c_client *client;
+ char buf[1];
+
+ s35390a = container_of(work, struct s35390a, work);
+ if (!s35390a)
+ return;
container_of() will never return NULL. You can remove this check. You
won't need this, actually after converting to threaded_irq, see below.
+static irqreturn_t s35390a_irq(int irq, void *client)
+{
+ struct s35390a *s35390a;
all the other drivers will do:
static irqreturn_t s35390a_irq(int irq, void *_s35390a)
{
struct s35390a *s35390a = _s35390a
[...]
+ if (!client)
+ return IRQ_HANDLED;
if client is NULL, you should let this oops.
+ schedule_work(s35390a-work);
please don't use workqueue. Use threaded IRQ.
@@ -261,15 +447,30 @@ static int s35390a_probe(struct i2c_client *client,
if (s35390a_get_datetime(client, tm) 0)
dev_warn(client-dev, clock needs to be set\n);
+ INIT_WORK(s35390a-work, s35390a_work);
+
+ if (client-irq 0) {
irq 0 is a valid number.
+ err = request_irq(client-irq, s35390a_irq, IRQF_TRIGGER_LOW,
+ client-name, client);
instead of the i2c client, you can pass s35390. Also use
request_threaded_irq();
--
balbi
DefectiveByDesign.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] RTC:s35390a: Add Periodic interrupt support
On Tue, Aug 17, 2010 at 10:48:40AM +0200, ext hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com description ?? Signed-off-by: Vaibhav Hiremath hvaib...@ti.com -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] RTC:s35390a: Add update_irq (per Min interrupt) support
On Tue, Aug 17, 2010 at 10:48:41AM +0200, ext hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com description Signed-off-by: Vaibhav Hiremath hvaib...@ti.com -- balbi DefectiveByDesign.org -- 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] OMAP: DSS2: don't power off a panel twice
I can also reproduce it when I try to use kexec to reboot the system. And this
patch fix that.
-Bryan
On 08/17/2010 05:27 PM, stanley.miao wrote:
It should be Tomi to maintain DSS2. I didn't get any response from Tomi.
Stanley.
Bryan Wu wrote:
Is there any feedback about this patch,
Tested-by: Bryan Wu bryan...@canonical.com
-Bryan
On 08/11/2010 02:50 PM, Bryan Wu wrote:
Tested on my Beagle board. It fixed the issue.
Thanks,
-Bryan
On 08/11/2010 11:19 AM, Stanley.Miao wrote:
If we blank the panel by
echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank
Then, we reboot the sytem, the kernel will crash at
drivers/video/omap2/dss/core.c:323
This is because the panel is closed twice. Now check the state of a
dssdev
to forbid a panel is power on or power off twice.
Signed-off-by: Stanley.Miao stanley.m...@windriver.com
---
drivers/video/omap2/displays/panel-acx565akm.c |6 ++
drivers/video/omap2/displays/panel-generic.c |6 ++
.../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 ++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 ++
drivers/video/omap2/displays/panel-taal.c |6 ++
.../video/omap2/displays/panel-toppoly-tdo35s.c|6 ++
.../video/omap2/displays/panel-tpo-td043mtea1.c|6 ++
7 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index 1f8eb70..374cbeb 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -587,6 +587,9 @@ static int acx_panel_power_on(struct
omap_dss_device *dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
mutex_lock(md-mutex);
r = omapdss_sdi_display_enable(dssdev);
@@ -642,6 +645,9 @@ static void acx_panel_power_off(struct
omap_dss_device *dssdev)
dev_dbg(dssdev-dev, %s\n, __func__);
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
mutex_lock(md-mutex);
if (!md-enabled) {
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..395a68d 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -39,6 +39,9 @@ static int generic_panel_power_on(struct
omap_dss_device *dssdev)
{
int r;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -58,6 +61,9 @@ err0:
static void generic_panel_power_off(struct omap_dss_device *dssdev)
{
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
index 1026746..0c6896c 100644
--- a/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
+++ b/drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
@@ -43,6 +43,9 @@ static int sharp_lq_panel_power_on(struct
omap_dss_device *dssdev)
{
int r;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -65,6 +68,9 @@ err0:
static void sharp_lq_panel_power_off(struct omap_dss_device *dssdev)
{
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 7d9eb2b..9a138f6 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -135,6 +135,9 @@ static int sharp_ls_power_on(struct
omap_dss_device *dssdev)
{
int r = 0;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
r = omapdss_dpi_display_enable(dssdev);
if (r)
goto err0;
@@ -157,6 +160,9 @@ err0:
static void sharp_ls_power_off(struct omap_dss_device *dssdev)
{
+if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+return;
+
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index aaf5d30..c649f06 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -635,6 +635,9 @@ static int taal_power_on(struct omap_dss_device
*dssdev)
u8 id1, id2, id3;
int r;
+if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+return 0;
+
if
Re: [PATCH V2] OMAP: DSS2: don't power off a panel twice
Hi, On Wed, 2010-08-11 at 05:19 +0200, ext Stanley.Miao wrote: If we blank the panel by echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank Then, we reboot the sytem, the kernel will crash at drivers/video/omap2/dss/core.c:323 This is because the panel is closed twice. Now check the state of a dssdev to forbid a panel is power on or power off twice. Otherwise this looks fine, except that panel-taal.c does not need modifications, as it already handles this case. Also, at some point I (or somebody else =) should think how to do proper locking for the panel drivers. Currently it's rather broken, and, for example, enabling and disabling a panel at the same time will cause problems. Except for panel-taal, which uses its own lock. Tomi -- 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] OMAP4: pm.c extensions for OMAP4 support
On 08/16/2010 11:36 PM, Thara Gopinath wrote:
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
a bit confused regarding this - IVA on OMAP3 was a C64 DSP. OMAP3 also
had iva accelerators, but ARM does not directly talk to the
accellerators. C64 did (that was why we had the dspbridge to talk to the
C64).
Could you clarify the intent of the patch?
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.
Signed-off-by: Thara Gopinathth...@ti.com
---
v2: Removed fixing of l3_main hwmod for OMAP4 as Benoit has
already submitted a pach fixing the same.
arch/arm/mach-omap2/pm.c | 19 ++-
arch/arm/plat-omap/include/plat/common.h |3 ++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..a98b5e8 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -21,8 +21,9 @@
static struct omap_device_pm_latency *pm_lats;
static struct device *mpu_dev;
-static struct device *dsp_dev;
+static struct device *iva_dev;
static struct device *l3_dev;
+static struct device *dsp_dev;
struct device *omap2_get_mpuss_device(void)
{
@@ -30,10 +31,10 @@ struct device *omap2_get_mpuss_device(void)
return mpu_dev;
}
-struct device *omap2_get_dsp_device(void)
+struct device *omap2_get_iva_device(void)
{
- WARN_ON_ONCE(!dsp_dev);
- return dsp_dev;
+ WARN_ON_ONCE(!iva_dev);
+ return iva_dev;
}
struct device *omap2_get_l3_device(void)
@@ -42,6 +43,13 @@ struct device *omap2_get_l3_device(void)
return l3_dev;
}
+struct device *omap4_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+EXPORT_SYMBOL(omap4_get_dsp_device);
+
/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
static int _init_omap_device(char *name, struct device **new_dev)
{
@@ -69,7 +77,8 @@ static int _init_omap_device(char *name, struct device
**new_dev)
static void omap2_init_processor_devices(void)
{
_init_omap_device(mpu,mpu_dev);
- _init_omap_device(iva,dsp_dev);
+ _init_omap_device(iva,iva_dev);
+ _init_omap_device(dsp,dsp_dev);
_init_omap_device(l3_main,l3_dev);
}
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..c45dbb9 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -91,7 +91,8 @@ void omap3_map_io(void);
})
extern struct device *omap2_get_mpuss_device(void);
-extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
+extern struct device *omap4_get_dsp_device(void);
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DSS2: don't power off a panel twice
On Tue, 2010-08-10 at 14:16 +0200, ext Stanley.Miao wrote: If we blank the panel by echo 1 /sys/devices/platform/omapfb/graphics/fb0/blank Then, we reboot the sytem, the kernel will crash at drivers/video/omap2/dss/core.c:323 This is because the panel is closed twice. Now add a variable panel_enabled to forbid a panel is power on or power off twice. Signed-off-by: Stanley.Miao stanley.m...@windriver.com --- drivers/video/omap2/displays/panel-generic.c | 11 +++ .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 11 +++ .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 11 +++ drivers/video/omap2/displays/panel-taal.c |6 ++ .../video/omap2/displays/panel-toppoly-tdo35s.c| 11 +++ .../video/omap2/displays/panel-tpo-td043mtea1.c|9 + 6 files changed, 59 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/displays/panel-generic.c b/drivers/video/omap2/displays/panel-generic.c index 300eff5..607f11a 100644 --- a/drivers/video/omap2/displays/panel-generic.c +++ b/drivers/video/omap2/displays/panel-generic.c @@ -22,6 +22,8 @@ #include plat/display.h +static int panel_enabled; While there's a revised version of this patch, I just wanted to point out that you can't use static variables in panel drivers, as there can be multiple devices using the same driver. Tomi -- 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: dss2: Add SPI dependency to Kconfig of ACX565AKM panel
On Wed, 2010-08-11 at 14:23 +0200, ext Jarkko Nikula wrote: This panel driver is using SPI for its communication so add CONFIG_SPI dependency. Thanks, applied. Tomi -- 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: DSS2 patch series
On Tue, 2010-08-10 at 11:33 +0200, ext Taneja, Archit wrote: [Archit] I have collected some information about what these revision numbers mean from the TI folks. The following is what I have gathered: -For each broad version of OMAP, like OMAP3430, OMAP3630, OMAP4430 and so on, there is an independent revision list. These are changed/incremented when the corresponding IP blocks are modified. The numbers which we see are probably the ones which were chosen to put into the silicon. So, it is possible that the revision numbers of ES_1 of OMAP3430 is exactly the same as the ES_1 of OMAP3630 even if the IP blocks have changed. This is what is seen in the prints of the revision of 3430 and 3630 I sent in the previous mail. These revision numbers are hence useful only within the revisions of a particular OMAP. It looks like that there is no single revision chain since OMAP2. -After discussions with more TI DSS folks, it seems that some changes that we may need to make in DSS software may not be dependent on the DSS hardware at all. For example, the patch OMAP3630:DSS2: Updating MAX divider value was introduced because of a change in PRCM. So it seems that we will need to have omap2, omap3 and omap4 checks , best we can do is prevent them from scattering around, i.e have them at a single place during initialization. Ok. Well, good that it's clear now =). How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). Tomi -- 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] Hacks to allow booting ARM SMP kernel on UP ARMv7
Hi all, Here are some experimental patches to allow booting ARMv7 SMP kernel on UP to some extent. Posting these early in case it is of any help as I know at least Bryan Wu is working on similar issues. The patches are very much work in progress, and does not quite boot to init yet so there's all kinds of things to fix. But at least these patches allow booting to the point where the fixing issues might be a bit easier.. Currently it boots to the point where there are tons of WARNING: at mm/percpu-vm.c:320 pcpu_alloc prints. I've only tested these on omap3 UP systems so far so YMMV. The patches are posted on top of v2.6.36-rc1 + omap-fixes branch. Also available in devel-smp-on-unicore branch in the linux-omap tree. Cheers, Tony --- Tony Lindgren (4): ARM: Add SMP_ON_UP Kconfig option for booting SMP kernel on UP ARM: Allow optional UP processor functions for SMP kernels ARM: Set separate proc-v7 functions for SMP omap: Fix SMP on UP interrupt handling for multi-omap arch/arm/Kconfig |7 ++ arch/arm/include/asm/cacheflush.h |6 ++ arch/arm/include/asm/proc-fns.h|8 ++ arch/arm/include/asm/procinfo.h|6 ++ arch/arm/include/asm/smp_plat.h|9 +++ arch/arm/include/asm/tlbflush.h| 16 - arch/arm/kernel/setup.c| 45 ++ arch/arm/mach-omap2/include/mach/entry-macro.S | 22 +++ arch/arm/mach-omap2/omap-smp.c | 16 - arch/arm/mach-omap2/timer-gp.c |7 ++ arch/arm/mm/cache-v7.S | 60 +++ arch/arm/mm/mmu.c | 20 +++--- arch/arm/mm/proc-v7.S | 77 ++-- arch/arm/mm/tlb-v7.S | 51 14 files changed, 325 insertions(+), 25 deletions(-) -- Signature -- 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] ARM: Add SMP_ON_UP Kconfig option for booting SMP kernel on UP
Add Kconfig option to boot SMP kernel on uniprocessor systems, and define MULTI_CPU, MULTI_TLB and MULTI_CACHE when SMP_ON_UP option is set. This will allow us to dynamically set the uniprocessor functions during the boot in a way that should also work with ZBOOT_ROM. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig |7 +++ arch/arm/include/asm/cacheflush.h |6 ++ arch/arm/include/asm/proc-fns.h |8 arch/arm/include/asm/tlbflush.h |6 ++ 4 files changed, 27 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9295110..1e9df6d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1166,6 +1166,13 @@ config SMP If you don't know what to do here, say N. +config SMP_ON_UP + bool Allow booting SMP kernel on uniprocessor systems (EXPERIMENTAL) + depends on SMP + default y + help + Allows booting SMP kernel on uniprocessor systems. + config HAVE_ARM_SCU bool depends on SMP diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index 4656a24..e0ed5b4 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -26,6 +26,12 @@ #undef _CACHE #undef MULTI_CACHE +/* Force multiple cache support to boot SMP kernel on uniprocessor systems */ +#ifdef CONFIG_SMP_ON_UP +# undef MULTI_CACHE +# define MULTI_CACHE 1 +#endif + #if defined(CONFIG_CPU_CACHE_V3) # ifdef _CACHE # define MULTI_CACHE 1 diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h index 8fdae9b..87a558b 100644 --- a/arch/arm/include/asm/proc-fns.h +++ b/arch/arm/include/asm/proc-fns.h @@ -20,6 +20,14 @@ #undef MULTI_CPU #undef CPU_NAME +/* Force multiple CPU support to boot SMP kernel on uniprocessor systems */ +#ifdef CONFIG_SMP_ON_UP +# undef MULTI_CPU +# undef CPU_NAME +# define MULTI_CPU +# define CPU_NAME +#endif + /* * CPU_NAME - the prefix for CPU related functions */ diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h index 33b546a..9b310bd 100644 --- a/arch/arm/include/asm/tlbflush.h +++ b/arch/arm/include/asm/tlbflush.h @@ -70,6 +70,12 @@ #undef _TLB #undef MULTI_TLB +/* Force multiple TLB support to boot SMP kernel on uniprocessor systems */ +#ifdef CONFIG_SMP_ON_UP +# undef MULTI_TLB +# define MULTI_TLB 1 +#endif + #define v3_tlb_flags (TLB_V3_FULL | TLB_V3_PAGE) #ifdef CONFIG_CPU_TLB_V3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: Allow optional UP processor functions for SMP kernels
Attempt to detect if the hardware is UP hardware, and use the optional
UP specific processors functions in struct proc_info_list if available.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/include/asm/procinfo.h |6 +
arch/arm/include/asm/smp_plat.h |9
arch/arm/kernel/setup.c | 45 +++
arch/arm/mm/mmu.c | 20 ++---
4 files changed, 71 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/procinfo.h b/arch/arm/include/asm/procinfo.h
index ca52e58..962d01e 100644
--- a/arch/arm/include/asm/procinfo.h
+++ b/arch/arm/include/asm/procinfo.h
@@ -40,6 +40,12 @@ struct proc_info_list {
struct cpu_tlb_fns *tlb;
struct cpu_user_fns *user;
struct cpu_cache_fns*cache;
+
+#ifdef CONFIG_SMP_ON_UP
+ struct processor*proc_up;
+ struct cpu_tlb_fns *tlb_up;
+ struct cpu_cache_fns*cache_up;
+#endif
};
#else /* __KERNEL__ */
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index e621530..1c2f587 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -18,4 +18,13 @@ static inline int cache_ops_need_broadcast(void)
return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 1;
}
+#ifdef CONFIG_SMP_ON_UP
+extern int smp_on_up(void);
+#else
+static inline int smp_on_up(void)
+{
+ return 0;
+}
+#endif
+
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d5231ae..5f3606c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -289,6 +289,50 @@ static void __init feat_v6_fixup(void)
elf_hwcap = ~HWCAP_TLS;
}
+#ifdef CONFIG_SMP_ON_UP
+
+static int _smp_on_up;
+
+int smp_on_up(void)
+{
+ return _smp_on_up;
+}
+
+static void __init smp_on_up_fixup(struct proc_info_list *list)
+{
+ int id;
+
+ id = read_cpuid_id() 0xff0f;
+ if ((id == 0x4107) || (id == 0x410f)) {
+ int mpidr;
+
+ asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
+ mpidr = 30;
+
+ /* SMP hardware? */
+ if (!((mpidr == 0) || (mpidr == 3)))
+ return;
+ }
+
+ _smp_on_up = 1;
+
+ pr_info(CPU: SMP kernel on UP hardware\n);
+
+ if (list-proc_up)
+ processor = *list-proc_up;
+
+ if (list-tlb_up)
+ cpu_tlb = *list-tlb_up;
+
+ if (list-cache_up)
+ cpu_cache = *list-cache_up;
+}
+#else
+static inline void smp_on_up_fixup(struct proc_info_list *list)
+{
+}
+#endif
+
static void __init setup_processor(void)
{
struct proc_info_list *list;
@@ -331,6 +375,7 @@ static void __init setup_processor(void)
elf_hwcap = ~HWCAP_THUMB;
#endif
+ smp_on_up_fixup(list);
feat_v6_fixup();
cacheid_init();
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 6e1c4f6..f320901 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -430,15 +430,17 @@ static void __init build_mem_type_table(void)
/*
* Mark memory with the shared attribute for SMP systems
*/
- user_pgprot |= L_PTE_SHARED;
- kern_pgprot |= L_PTE_SHARED;
- vecs_pgprot |= L_PTE_SHARED;
- mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
- mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
- mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
- mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
- mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ if (!smp_on_up()) {
+ user_pgprot |= L_PTE_SHARED;
+ kern_pgprot |= L_PTE_SHARED;
+ vecs_pgprot |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
+ mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
+ mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
+ mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
+ }
#endif
}
--
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/4] ARM: Set separate proc-v7 functions for SMP
Set separate proc-v7 functions for SMP
NOTE: The v7wbi_tlb_flags need to be checked
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/include/asm/tlbflush.h | 10 +++--
arch/arm/mm/cache-v7.S | 60 ++
arch/arm/mm/proc-v7.S | 77 ---
arch/arm/mm/tlb-v7.S| 51 ++
4 files changed, 188 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 9b310bd..0b2087e 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -191,12 +191,14 @@
# define v6wbi_always_flags(-1UL)
#endif
-#ifdef CONFIG_SMP
-#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \
+#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \
TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
-#else
-#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BTB | \
+#define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_BTB | \
TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
+#ifdef CONFIG_SMP
+#define v7wbi_tlb_flagsv7wbi_tlb_flags_smp
+#else
+#define v7wbi_tlb_flagsv7wbi_tlb_flags_up
#endif
#ifdef CONFIG_CPU_TLB_V7
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index 37c8157..acc889c 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -101,6 +101,19 @@ ENTRY(v7_flush_kern_cache_all)
mov pc, lr
ENDPROC(v7_flush_kern_cache_all)
+#ifdef CONFIG_SMP_ON_UP
+ENTRY(v7_flush_kern_cache_all_up)
+ ARM( stmfd sp!, {r4-r5, r7, r9-r11, lr})
+ THUMB(stmfd sp!, {r4-r7, r9-r11, lr})
+ bl v7_flush_dcache_all
+ mov r0, #0
+ mcr p15, 0, r0, c7, c5, 0 @ I+BTB cache invalidate
+ ARM( ldmfd sp!, {r4-r5, r7, r9-r11, lr})
+ THUMB(ldmfd sp!, {r4-r7, r9-r11, lr})
+ mov pc, lr
+ENDPROC(v7_flush_kern_cache_all_up)
+#endif
+
/*
* v7_flush_cache_all()
*
@@ -193,6 +206,37 @@ ENTRY(v7_coherent_user_range)
ENDPROC(v7_coherent_kern_range)
ENDPROC(v7_coherent_user_range)
+#ifdef CONFIG_SMP_ON_UP
+ENTRY(v7_coherent_kern_range_up)
+ENTRY(v7_coherent_user_range_up)
+ UNWIND(.fnstart )
+ dcache_line_size r2, r3
+ sub r3, r2, #1
+ bic r0, r0, r3
+1:
+ USER( mcr p15, 0, r0, c7, c11, 1 ) @ clean D line to the point of
unification
+ dsb
+ USER( mcr p15, 0, r0, c7, c5, 1 ) @ invalidate I line
+ add r0, r0, r2
+2:
+ cmp r0, r1
+ blo 1b
+ mov r0, #0
+ mcr p15, 0, r0, c7, c5, 6 @ invalidate BTB
+ dsb
+ isb
+ mov pc, lr
+
+9001:
+ mov r0, r0, lsr #12
+ mov r0, r0, lsl #12
+ add r0, r0, #4096
+ b 2b
+ UNWIND(.fnend )
+ENDPROC(v7_coherent_kern_range_up)
+ENDPROC(v7_coherent_user_range_up)
+#endif
+
/*
* v7_flush_kern_dcache_area(void *addr, size_t size)
*
@@ -319,3 +363,19 @@ ENTRY(v7_cache_fns)
.long v7_dma_unmap_area
.long v7_dma_flush_range
.size v7_cache_fns, . - v7_cache_fns
+
+#ifdef CONFIG_SMP_ON_UP
+ .type v7_cache_fns_up, #object
+ENTRY(v7_cache_fns_up)
+ .long v7_flush_kern_cache_all_up
+ .long v7_flush_user_cache_all
+ .long v7_flush_user_cache_range
+ .long v7_coherent_kern_range_up
+ .long v7_coherent_user_range_up
+ .long v7_flush_kern_dcache_area
+ .long v7_dma_map_area
+ .long v7_dma_unmap_area
+ .long v7_dma_flush_range
+ .size v7_cache_fns_up, . - v7_cache_fns_up
+#endif
+
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 6a8506d..65981c3 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -30,15 +30,13 @@
#define TTB_IRGN_WT((1 0) | (0 6))
#define TTB_IRGN_WB((1 0) | (1 6))
-#ifndef CONFIG_SMP
/* PTWs cacheable, inner WB not shareable, outer WB not shareable */
#define TTB_FLAGS TTB_IRGN_WB|TTB_RGN_OC_WB
#define PMD_FLAGS PMD_SECT_WB
-#else
+
/* PTWs cacheable, inner WBWA shareable, outer WBWA not shareable */
-#define TTB_FLAGS TTB_IRGN_WBWA|TTB_S|TTB_NOS|TTB_RGN_OC_WBWA
-#define PMD_FLAGS PMD_SECT_WBWA|PMD_SECT_S
-#endif
+#define TTB_FLAGS_SMP TTB_IRGN_WBWA|TTB_S|TTB_NOS|TTB_RGN_OC_WBWA
+#define PMD_FLAGS_SMP PMD_SECT_WBWA|PMD_SECT_S
ENTRY(cpu_v7_proc_init)
mov pc, lr
@@ -105,7 +103,11 @@ ENTRY(cpu_v7_switch_mm)
#ifdef CONFIG_MMU
mov r2, #0
ldr r1, [r1, #MM_CONTEXT_ID]@ get mm-context.id
+#ifdef CONFIG_SMP
+ orr r0, r0, #TTB_FLAGS_SMP
+#else
orr r0, r0, #TTB_FLAGS
+#endif
#ifdef CONFIG_ARM_ERRATA_430973
mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB
#endif
@@ -119,6 +121,31 @@ ENTRY(cpu_v7_switch_mm)
mov pc, lr
[PATCH 4/4] omap: Fix SMP on UP interrupt handling for multi-omap
Fix SMP on UP interrupt handling for multi-omap
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++
arch/arm/mach-omap2/omap-smp.c | 16
arch/arm/mach-omap2/timer-gp.c |7 +--
3 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index 06e64e1..75c67aa 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -189,17 +189,38 @@ omap_irq_base:.word 0
*/
.macro test_for_ipi, irqnr, irqstat, base, tmp
+
+#ifdef MULTI_OMAP2
+ ldr \tmp, =OMAP4_IRQ_BASE
+ cmp \base, \tmp
+ beq 9993f
+ cmpne \tmp, \tmp
+ beq 9994f
+9993:
+#endif
+
bic \irqnr, \irqstat, #0x1c00
cmp \irqnr, #16
it cc
strcc \irqstat, [\base, #GIC_CPU_EOI]
it cs
cmpcs \irqnr, \irqnr
+9994:
.endm
/* As above, this assumes that irqstat and base are preserved */
.macro test_for_ltirq, irqnr, irqstat, base, tmp
+
+#ifdef MULTI_OMAP2
+ ldr \tmp, =OMAP4_IRQ_BASE
+ cmp \base, \tmp
+ beq 9995f
+ cmpne \tmp, \tmp
+ beq 9996f
+9995:
+#endif
+
bic \irqnr, \irqstat, #0x1c00
mov \tmp, #0
cmp \irqnr, #29
@@ -207,6 +228,7 @@ omap_irq_base: .word 0
moveq \tmp, #1
streq \irqstat, [\base, #GIC_CPU_EOI]
cmp \tmp, #0
+9996:
.endm
#endif /* CONFIG_SMP */
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 9e9f70e..8ea16de 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -22,6 +22,7 @@
#include asm/cacheflush.h
#include asm/localtimer.h
+#include asm/smp_plat.h
#include asm/smp_scu.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -114,11 +115,15 @@ void __init smp_init_cpus(void)
{
unsigned int i, ncores;
- /* Never released */
- scu_base = ioremap(OMAP44XX_SCU_BASE, SZ_256);
- BUG_ON(!scu_base);
+ if (smp_on_up()) {
+ ncores = 1;
+ } else {
+ /* Never released */
+ scu_base = ioremap(OMAP44XX_SCU_BASE, SZ_256);
+ BUG_ON(!scu_base);
- ncores = get_core_count();
+ ncores = get_core_count();
+ }
for (i = 0; i ncores; i++)
set_cpu_possible(i, true);
@@ -146,6 +151,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
smp_store_cpu_info(cpu);
+ if (smp_on_up())
+ ncores = 1;
+
/*
* are we trying to boot more cores than exist?
*/
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 74fbed8..badf5f2 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -37,6 +37,7 @@
#include linux/clockchips.h
#include asm/mach/time.h
+#include asm/smp_plat.h
#include plat/dmtimer.h
#include asm/localtimer.h
@@ -228,8 +229,10 @@ static void __init omap2_gp_clocksource_init(void)
static void __init omap2_gp_timer_init(void)
{
#ifdef CONFIG_LOCAL_TIMERS
- twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
- BUG_ON(!twd_base);
+ if (smp_on_up()) {
+ twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);
+ BUG_ON(!twd_base);
+ }
#endif
omap_dm_timer_init();
--
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:DSS:Add support for Additional color modes supported by OMAP4
Hi,
On Wed, 2010-08-11 at 11:22 +0200, ext K, Mythri P wrote:
Hi Tomi,
Can you please comment on the below patch . This is to add new color modes
supported by OMAP4.
Thanks and regards,
Mythri.
-Original Message-
From: K, Mythri P
Sent: Thursday, August 05, 2010 11:24 AM
To: linux-omap@vger.kernel.org
Cc: tomi.valkei...@nokia.com; Semwal, Sumit; K, Mythri P
Subject: [PATCH] OMAP:DSS:Add support for Additional color modes supported by
OMAP4
From: Sumit semwal sumit.sem...@ti.com
This patch adds support for new color modes that are supported by the
video/graphics pipeline of OMAP4
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h | 16 -
drivers/video/omap2/dss/dispc.c | 53
++---
drivers/video/omap2/dss/overlay.c |6 ++-
3 files changed, 59 insertions(+), 16 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 7a6eedd..ebf1020 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -89,6 +89,12 @@ enum omap_color_mode {
OMAP_DSS_COLOR_ARGB32 = 1 11, /* ARGB32 */
OMAP_DSS_COLOR_RGBA32 = 1 12, /* RGBA32 */
OMAP_DSS_COLOR_RGBX32 = 1 13, /* RGBx32 */
+ OMAP_DSS_COLOR_NV12 = 1 14, /* NV12 format: YUV 4:2:0 */
+ OMAP_DSS_COLOR_RGBA12 = 1 15, /* RGBA12 - */
Is this the same as ARGB16? Or is it the same, except alpha value is in
the other end? If so, I think the naming should be coherent, and either
this should be RGBA16, or ARGB16 should be ARGB12.
Then again, if TRM says this is RGBA12, and the other one is ARGB16, I
guess we should stick with TRM naming...
+ OMAP_DSS_COLOR_XRGB12 = 1 16, /* xRGB12, 16-bit container */
Is this RGB12U, or again otherwise same but the empty value is on the
other end?
+ OMAP_DSS_COLOR_ARGB16_1555 = 1 17, /* ARGB16-1555 */
+ OMAP_DSS_COLOR_RGBX24_32_ALGN = 1 18, /* 32-msb aligned 24bit */
Hmm, what is this?
+ OMAP_DSS_COLOR_XRGB15 = 1 19, /* xRGB15: 1555*/
OMAP_DSS_COLOR_GFX_OMAP2 =
OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
@@ -112,9 +118,17 @@ enum omap_color_mode {
OMAP_DSS_COLOR_VID1_OMAP3 =
OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P |
- OMAP_DSS_COLOR_YUV2 | OMAP_DSS_COLOR_UYVY,
+ OMAP_DSS_COLOR_YUV2 | OMAP_DSS_COLOR_UYVY |
+ OMAP_DSS_COLOR_NV12 | OMAP_DSS_COLOR_RGBA12 |
+ OMAP_DSS_COLOR_XRGB12 | OMAP_DSS_COLOR_ARGB16_1555 |
+ OMAP_DSS_COLOR_RGBX24_32_ALGN | OMAP_DSS_COLOR_XRGB15 |
+ OMAP_DSS_COLOR_ARGB32 | OMAP_DSS_COLOR_RGBA32 |
+ OMAP_DSS_COLOR_RGBX32,
Why do you change OMAP3 modes, if this patch is about supported OMAP4
modes?
Tomi
--
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] ARM: Allow optional UP processor functions for SMP kernels
On Tue, Aug 17, 2010 at 01:53:25PM +0300, Tony Lindgren wrote:
diff --git a/arch/arm/include/asm/smp_plat.h b/arch/arm/include/asm/smp_plat.h
index e621530..1c2f587 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -18,4 +18,13 @@ static inline int cache_ops_need_broadcast(void)
return ((read_cpuid_ext(CPUID_EXT_MMFR3) 12) 0xf) 1;
}
+#ifdef CONFIG_SMP_ON_UP
+extern int smp_on_up(void);
+#else
+static inline int smp_on_up(void)
+{
+ return 0;
+}
+#endif
+
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d5231ae..5f3606c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -289,6 +289,50 @@ static void __init feat_v6_fixup(void)
elf_hwcap = ~HWCAP_TLS;
}
+#ifdef CONFIG_SMP_ON_UP
+
+static int _smp_on_up;
+
+int smp_on_up(void)
+{
+ return _smp_on_up;
+}
This kind of function to access one bit of data is really silly and
expensive. If you want to do something like this to hide the data
itself, then instead do this in the header file:
static inline int smp_on_up(void)
{
#ifdef CONFIG_SMP_ON_UP
extern int _smp_on_up;
return _smp_on_up;
#else
return 0;
#endif
}
rather than making the compiler unable to optimize this call by spilling
at least 5 registers each time.
+ if (list-proc_up)
+ processor = *list-proc_up;
+
+ if (list-tlb_up)
+ cpu_tlb = *list-tlb_up;
+
+ if (list-cache_up)
+ cpu_cache = *list-cache_up;
I don't think this is a good approach at all - most of the assembly
is identical and I'm sure there's a much better approach to fixing
these things up.
--
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: DSS2 patch series
Hi, Ok. Well, good that it's clear now =). How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). I talked to some more folks about this. To summarize: - The revision registers aren't reliable enough, it's better to use the combination of cpu_is_ and and omap_rev macros. These should be enough for making an DSS specific feature list. -The feature framework(HWMOD) can help out with the following things - The internal IP blocks within DSS. - The PRCM clocks and IRQs coming to DSS, and PM stuff which I don't know much about. - Effectively, the information on how the outside world communicates with DSS. -DSS features like number of vid pipelines, supported color modes,internal clocks and PLL info, bit fields needs to be managed by us. One good input was that we can manage internal DSS clocks using the exisiting clock framework and custom clock modes. I don't know much about it. Others in the list can probably help out with this :) The present way of handling DSS2 clocks is good, but we need to see if it can be scalable when more OMAPs come in. The dss_features.c idea sounds good, we will still have these new bunch of functions scattered around in the code. But it will be much than an if else chain of omap checks. So should we stick with this idea? Thanks, Archit-- 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] ARM: Allow optional UP processor functions for SMP kernels
* Russell King - ARM Linux li...@arm.linux.org.uk [100817 14:01]: On Tue, Aug 17, 2010 at 01:53:25PM +0300, Tony Lindgren wrote: + if (list-proc_up) + processor = *list-proc_up; + + if (list-tlb_up) + cpu_tlb = *list-tlb_up; + + if (list-cache_up) + cpu_cache = *list-cache_up; I don't think this is a good approach at all - most of the assembly is identical and I'm sure there's a much better approach to fixing these things up. We could simplify it if we tried to detect SMP kernel running on UP hardware early on and then select the UP vs SMP code as needed. 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 4/4] omap: Fix SMP on UP interrupt handling for multi-omap
On Tue, 2010-08-17 at 12:53 +0200, Tony Lindgren wrote: Fix SMP on UP interrupt handling for multi-omap Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++ arch/arm/mach-omap2/omap-smp.c | 16 arch/arm/mach-omap2/timer-gp.c |7 +-- 3 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 06e64e1..75c67aa 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S There is one patch lying in Russell's tracker (6284/1) which attempts to use the common IRQ helper macros instead of platforms duplicating this file. Perhaps you may need to re-base to that if Russell is ok with that patch, of course. srinidhi -- 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] omap: Fix SMP on UP interrupt handling for multi-omap
* srinidhi srinidhi.kasa...@stericsson.com [100817 14:00]: On Tue, 2010-08-17 at 12:53 +0200, Tony Lindgren wrote: Fix SMP on UP interrupt handling for multi-omap Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++ arch/arm/mach-omap2/omap-smp.c | 16 arch/arm/mach-omap2/timer-gp.c |7 +-- 3 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 06e64e1..75c67aa 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S There is one patch lying in Russell's tracker (6284/1) which attempts to use the common IRQ helper macros instead of platforms duplicating this file. Perhaps you may need to re-base to that if Russell is ok with that patch, of course. Nice to see. Ideally test_for_ipi and test_for_ltirq would return early automatically when running SMP kernel on UP. BTW, did you test patch 6284/1 with omap3_defconfig to make sure that still boots on omap3 4? 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: DSS2 patch series
Hi Archit, On 8/17/2010 1:16 PM, Taneja, Archit wrote: Hi, Ok. Well, good that it's clear now =). How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). I talked to some more folks about this. To summarize: - The revision registers aren't reliable enough, it's better to use the combination of cpu_is_ and and omap_rev macros. These should be enough for making an DSS specific feature list. -The feature framework(HWMOD) can help out with the following things - The internal IP blocks within DSS. - The PRCM clocks and IRQs coming to DSS, and PM stuff which I don't know much about. - Effectively, the information on how the outside world communicates with DSS. -DSS features like number of vid pipelines, supported color modes,internal clocks and PLL info, bit fields needs to be managed by us. You can use hwmod to store that as well. Other IPs might require features management, so instead of doing a DSS dedicated solution, you can directly leverage the existing fmwk and extend it to manage your features. One good input was that we can manage internal DSS clocks using the exisiting clock framework and custom clock modes. I don't know much about it. Others in the list can probably help out with this :) The present way of handling DSS2 clocks is good, but we need to see if it can be scalable when more OMAPs come in. Good? It works, but this is still redoing what the clocks framework can already do. The good approach will be to encode your clocks nodes using the clock framework, as you've just said. The dss_features.c idea sounds good, we will still have these new bunch of functions scattered around in the code. But it will be much than an if else chain of omap checks. So should we stick with this idea? Using directly the hwmod struct sound a much better idea for my point of view. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DSS2 patch series
On Tue, 2010-08-17 at 13:16 +0200, ext Taneja, Archit wrote: Hi, Ok. Well, good that it's clear now =). How do you think we can clean things up? If I remember right, there's some kind of feature framework being worked on (or ready?), but I haven't looked at that at all. That may or may not suit our needs. But perhaps we could just have a separate dss_features.c file, which would contain a bunch of functions that can be used to ask whether a certain feature is supported, and also to ask certain values (max dividers or similar). I talked to some more folks about this. To summarize: - The revision registers aren't reliable enough, it's better to use the combination of cpu_is_ and and omap_rev macros. These should be enough for making an DSS specific feature list. -The feature framework(HWMOD) can help out with the following things - The internal IP blocks within DSS. - The PRCM clocks and IRQs coming to DSS, and PM stuff which I don't know much about. - Effectively, the information on how the outside world communicates with DSS. -DSS features like number of vid pipelines, supported color modes,internal clocks and PLL info, bit fields needs to be managed by us. One good input was that we can manage internal DSS clocks using the exisiting clock framework and custom clock modes. I don't know much about it. Others in the list can probably help out with this :) The present way of handling DSS2 clocks is good, but we need to see if it can be scalable when more OMAPs come in. The dss_features.c idea sounds good, we will still have these new bunch of functions scattered around in the code. But it will be much than an if else chain of omap checks. So should we stick with this idea? Yes, and even if the dss_features.c isn't what is needed in the end, it'll still be easier to convert to whatever way we want in the future. But this is also not a very high priority thing. So I don't see a need to start converting everything to use dss_features.c right away. We can start by converting the places where OMAP4 changes require feature checks. Tomi -- 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] omap: Fix SMP on UP interrupt handling for multi-omap
On Tue, 2010-08-17 at 13:30 +0200, Tony Lindgren wrote: * srinidhi srinidhi.kasa...@stericsson.com [100817 14:00]: On Tue, 2010-08-17 at 12:53 +0200, Tony Lindgren wrote: Fix SMP on UP interrupt handling for multi-omap Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++ arch/arm/mach-omap2/omap-smp.c | 16 arch/arm/mach-omap2/timer-gp.c |7 +-- 3 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 06e64e1..75c67aa 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S There is one patch lying in Russell's tracker (6284/1) which attempts to use the common IRQ helper macros instead of platforms duplicating this file. Perhaps you may need to re-base to that if Russell is ok with that patch, of course. Nice to see. Ideally test_for_ipi and test_for_ltirq would return early automatically when running SMP kernel on UP. BTW, did you test patch 6284/1 with omap3_defconfig to make sure that still boots on omap3 4? Just build tested for all other machines and boot tested on ux500 machine. I do not have omap and other boards :( Srinidhi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP: hwmod: Force a softreset during _setup
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Cousson, Benoit
Sent: Thursday, August 05, 2010 3:43 AM
To: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
p...@pwsan.com
Cc: Nayak, Rajendra; Shilimkar, Santosh; Cousson, Benoit
Subject: [PATCH 3/3] OMAP: hwmod: Force a softreset during _setup
Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index 53b08e3..91ad9c6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -856,8 +856,8 @@ static int _reset(struct omap_hwmod *oh)
/* clocks must be on for this operation */
if (oh-_state != _HWMOD_STATE_ENABLED) {
- WARN(1, omap_hwmod: %s: reset can only be entered from
- enabled state\n, oh-name);
+ pr_warning(omap_hwmod: %s: reset can only be entered from
+enabled state\n, oh-name);
return -EINVAL;
}
@@ -874,8 +874,8 @@ static int _reset(struct omap_hwmod *oh)
MAX_MODULE_RESET_WAIT, c);
if (c == MAX_MODULE_RESET_WAIT)
- WARN(1, omap_hwmod: %s: failed to reset in %d usec\n,
- oh-name, MAX_MODULE_RESET_WAIT);
+ pr_warning(omap_hwmod: %s: failed to reset in %d usec\n,
+oh-name, MAX_MODULE_RESET_WAIT);
http://focus.ti.com/pdfs/wtbu/SWPU177B_FinalEPDF_12_04_2009.pdf
This is leading to the above warning for DSS on OMAP3430/3630. Referring to the
reference manual (7.5.1 Display Subsystem Reset), successful reset of DSS would
need PRCM.CM_FCLKEN_DSS[2] EN_TV bit set to 1. For DSS, even though TV clock is
an optional clock, this is mandatory for successful DSS reset. We could ignore
this warning, or possibly WA it.
One way could be:
1. In the database, have HWMOD_INIT_NO_RESET flag set so that _setup() skips
reset.
2. After omap device build of DSS is done, lookup the opt-clock and enable it
(using clock framework).
3. Then do DSS reset again calling omap_device_reset().
All IPs that potentially have any special soft-reset sequence will need
customized handling. Should we keep the framework light and handle such special
cases in the drivers? In that case, the framework need not throw up a warning.
Please comment.
else
pr_debug(omap_hwmod: %s: reset in %d usec\n, oh-name, c);
@@ -1074,12 +1074,11 @@ static int _setup(struct omap_hwmod *oh, void
*data)
}
if (!(oh-flags HWMOD_INIT_NO_RESET)) {
+ _reset(oh);
/*
- * XXX Do the OCP_SYSCONFIG bits need to be
- * reprogrammed after a reset? If not, then this can
- * be removed. If they do, then probably the
- * _omap_hwmod_enable() function should be split to avoid the
- * rewrite of the OCP_SYSCONFIG register.
+ * OCP_SYSCONFIG bits need to be reprogrammed after a
softreset.
+ * The _omap_hwmod_enable() function should be split to
+ * avoid the rewrite of the OCP_SYSCONFIG register.
*/
if (oh-class-sysc) {
_update_sysc_cache(oh);
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
On Tue, Aug 17, 2010 at 01:53:12PM +0300, Tony Lindgren wrote:
Here are some experimental patches to allow booting ARMv7 SMP
kernel on UP to some extent. Posting these early in case it is
of any help as I know at least Bryan Wu is working on similar
issues.
I think these are compeltely the wrong direction. First thing to realise
is that XIP in the SMP and UP in one kernel is not really practical -
I'm not sure that many people who want that kind of flexibility also want
XIP too.
So let's forget about the kernel text being read-only.
The second thing to realise is that most of the SMP dependencies are in
assembly - and we can make lists of instructions and their modified
versions that would be necessary to boot a SMP kernel on UP.
So something like this will do (though note that not everywhere has been
fixed up - such as the page table flags - or this patch tested yet.)
If we don't want the SMP-on-UP support for SMP kernels (it's not actually
all that big - around 512 bytes) then we can discard the .smpalt.init
section and the __fixup_smp code.
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 6e8f05c..55974d2 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -154,16 +154,32 @@
.long b,9001f;\
.popsection
+#ifdef CONFIG_SMP
+#define SMP(instr...) \
+9998: instr
+#define UP(instr...) \
+ .pushsection .smpalt.init, a;\
+ .word 9998b ;\
+ instr ;\
+ .popsection
+#else
+#define SMP(instr...)
+#define UP(instr...) instr
+#endif
+
/*
* SMP data memory barrier
*/
.macro smp_dmb
#ifdef CONFIG_SMP
#if __LINUX_ARM_ARCH__ = 7
- dmb
+ SMP(dmb)
#elif __LINUX_ARM_ARCH__ == 6
- mcr p15, 0, r0, c7, c10, 5 @ dmb
+ SMP(mcr p15, 0, r0, c7, c10, 5) @ dmb
+#else
+#error Incompatible SMP platform
#endif
+ UP(nop)
#endif
.endm
diff --git a/arch/arm/include/asm/smp_midr.h b/arch/arm/include/asm/smp_midr.h
index e69de29..4538ba4 100644
--- a/arch/arm/include/asm/smp_midr.h
+++ b/arch/arm/include/asm/smp_midr.h
@@ -0,0 +1,17 @@
+#ifndef ASMARM_SMP_MIDR_H
+#define ASMARM_SMP_MIDR_H
+
+#define hard_smp_processor_id()
\
+ ({ \
+ unsigned int cpunum;\
+ __asm__(\n\
+ 1: mrc p15, 0, %0, c0, c0, 5\n\
+ .pushsection \.smpalt.init\, \a\\n \
+ .word 1b\n \
+ mov %0, #0\n \
+ .popsection\
+ : =r (cpunum)); \
+ cpunum = 0x0F; \
+ })
+
+#endif
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 33b546a..0644860 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -185,12 +185,15 @@
# define v6wbi_always_flags(-1UL)
#endif
-#ifdef CONFIG_SMP
-#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \
+#define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \
TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
-#else
-#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BTB | \
+#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BTB | \
TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
+
+#ifdef CONFIG_SMP
+#define v7wbi_tlb_flagsv7wbi_tlb_flags_smp
+#else
+#define v7wbi_tlb_flagsv7wbi_tlb_flags_up
#endif
#ifdef CONFIG_CPU_TLB_V7
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index bb8e93a..bb2ef60 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -965,11 +965,8 @@ kuser_cmpxchg_fixup:
beq 1b
rsbsr0, r3, #0
/* beware -- each __kuser slot must be 8 instructions max */
-#ifdef CONFIG_SMP
- b __kuser_memory_barrier
-#else
- usr_ret lr
-#endif
+ SMP(b __kuser_memory_barrier)
+ UP(usr_ret lr)
#endif
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index eb62bf9..feabbf0 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -86,6 +86,9 @@ ENTRY(stext)
movsr8, r5 @ invalid machine (r5=0)?
beq __error_a @ yes, error 'a'
bl __vet_atags
+#ifdef CONFIG_SMP
+ bl __fixup_smp
+#endif
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
* Russell King - ARM Linux li...@arm.linux.org.uk [100817 16:44]: On Tue, Aug 17, 2010 at 01:53:12PM +0300, Tony Lindgren wrote: Here are some experimental patches to allow booting ARMv7 SMP kernel on UP to some extent. Posting these early in case it is of any help as I know at least Bryan Wu is working on similar issues. I think these are compeltely the wrong direction. First thing to realise is that XIP in the SMP and UP in one kernel is not really practical - I'm not sure that many people who want that kind of flexibility also want XIP too. So let's forget about the kernel text being read-only. OK, at least for me. The second thing to realise is that most of the SMP dependencies are in assembly - and we can make lists of instructions and their modified versions that would be necessary to boot a SMP kernel on UP. OK cool. So something like this will do (though note that not everywhere has been fixed up - such as the page table flags - or this patch tested yet.) Great, will give it a try hopefully tomorrow. Sounds like that's the way to deal with fixing up things when booting up older UP ARMv6 without the 32v6 support :) If we don't want the SMP-on-UP support for SMP kernels (it's not actually all that big - around 512 bytes) then we can discard the .smpalt.init section and the __fixup_smp code. OK 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 4/4] omap: Fix SMP on UP interrupt handling for multi-omap
* srinidhi srinidhi.kasa...@stericsson.com [100817 15:07]: On Tue, 2010-08-17 at 13:30 +0200, Tony Lindgren wrote: * srinidhi srinidhi.kasa...@stericsson.com [100817 14:00]: On Tue, 2010-08-17 at 12:53 +0200, Tony Lindgren wrote: Fix SMP on UP interrupt handling for multi-omap Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++ arch/arm/mach-omap2/omap-smp.c | 16 arch/arm/mach-omap2/timer-gp.c |7 +-- 3 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 06e64e1..75c67aa 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S There is one patch lying in Russell's tracker (6284/1) which attempts to use the common IRQ helper macros instead of platforms duplicating this file. Perhaps you may need to re-base to that if Russell is ok with that patch, of course. Nice to see. Ideally test_for_ipi and test_for_ltirq would return early automatically when running SMP kernel on UP. BTW, did you test patch 6284/1 with omap3_defconfig to make sure that still boots on omap3 4? Just build tested for all other machines and boot tested on ux500 machine. I do not have omap and other boards :( OK, I'll give your patch a try on some omap3 board, maybe Santosh can test it on omap4. 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 4/4] omap: Fix SMP on UP interrupt handling for multi-omap
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, August 17, 2010 7:44 PM To: srinidhi Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; bryan...@canonical.com; Shilimkar, Santosh Subject: Re: [PATCH 4/4] omap: Fix SMP on UP interrupt handling for multi- omap * srinidhi srinidhi.kasa...@stericsson.com [100817 15:07]: On Tue, 2010-08-17 at 13:30 +0200, Tony Lindgren wrote: * srinidhi srinidhi.kasa...@stericsson.com [100817 14:00]: On Tue, 2010-08-17 at 12:53 +0200, Tony Lindgren wrote: Fix SMP on UP interrupt handling for multi-omap Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/include/mach/entry-macro.S | 22 ++ arch/arm/mach-omap2/omap-smp.c | 16 arch/arm/mach-omap2/timer-gp.c |7 +-- 3 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S b/arch/arm/mach-omap2/include/mach/entry-macro.S index 06e64e1..75c67aa 100644 --- a/arch/arm/mach-omap2/include/mach/entry-macro.S +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S There is one patch lying in Russell's tracker (6284/1) which attempts to use the common IRQ helper macros instead of platforms duplicating this file. Perhaps you may need to re-base to that if Russell is ok with that patch, of course. Nice to see. Ideally test_for_ipi and test_for_ltirq would return early automatically when running SMP kernel on UP. BTW, did you test patch 6284/1 with omap3_defconfig to make sure that still boots on omap3 4? Just build tested for all other machines and boot tested on ux500 machine. I do not have omap and other boards :( OK, I'll give your patch a try on some omap3 board, maybe Santosh can test it on omap4. I tested patch 6284/1 on OMAP4 and OMAP3 SDPs with multi-omap and normal build. Both boots well Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Hacks to allow booting ARM SMP kernel on UP ARMv7
On Tue, Aug 17, 2010 at 05:12:11PM +0300, Tony Lindgren wrote: Great, will give it a try hopefully tomorrow. Sounds like that's the way to deal with fixing up things when booting up older UP ARMv6 without the 32v6 support :) What I've also been debating about is adding another word to the smpalt structure, that being a set of flags which denote the situation where the alternative should be used. That means we can use it to do individual word replacements for SMP vs UP, ARMv6 vs ARMv6k etc. -- 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] iommu: fix end address of vm area comparation in alloc_iovm_area
End address of the vm area is .start + bytes -1., not start + byte. This patch fixes that issue by doing an inclusive comparison with tmp-da_start. This issue was preventing allocate an area of size exactly the same than the free area. I did no change the value of da_end of each vm area because it is used to get area size in several places. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 8ce0de2..24ca9c4 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -292,7 +292,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, if (prev_end = start) break; - if (start + bytes tmp-da_start) + if (start + bytes = tmp-da_start) goto found; if (flags IOVMF_DA_ANON) -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] ARM: OMAP: Beagle: revision detection
On Tue, Aug 17, 2010 at 12:48 AM, Jarkko Nikula jhnik...@gmail.com wrote:
Hi
On Mon, 16 Aug 2010 09:36:41 -0500
Robert Nelson robertcnel...@gmail.com wrote:
+u8 get_omap3_beagle_rev(void)
+{
+ return omap3_beagle_version;
+}
+
+static void __init omap3_beagle_get_revision(void)
+{
+ int ret;
+ u16 beagle_rev = 0;
+
+ omap_mux_init_gpio(171, OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_gpio(172, OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_gpio(173, OMAP_PIN_INPUT_PULLUP);
+
+ ret = gpio_request(171, rev_id_0);
+ if (ret 0)
+ goto fail;
+
+ ret = gpio_request(172, rev_id_1);
+ if (ret 0)
+ goto fail;
+
+ ret = gpio_request(173, rev_id_2);
+ if (ret 0)
+ goto fail;
+
Thanks Jarkko
Sorry, I didn't notice this earlier: you should free already allocated
gpios if the next one fails.
Sure, i'll add something like:
fail3:
gpio_free(173);
fail2:
gpio_free(172);
fail1:
gpio_free(171);
Do you have any preference if the gpio allocation fails? Right now
it'll just halts, we could just return as Cx based board.. Which would
be the route the current kernel would take without this patch...
minor
I was thinking would it make a sense to rename funtions below. I.e. to
indicate that only one of them is for runtime revision detection and
another is for revision initialization only. What do you think?
get_omap3_beagle_rev - omap3_beagle_get_rev
omap3_beagle_get_revision - omap3_beagle_init_rev
That does help clear up the two functions a little.
I didn't give much thought to the names, they just came from the evm
board revision example: s/evm/beagle/g
Regards,
--
Robert Nelson
http://www.rcn-ee.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 v4 1/3] ARM: OMAP: Beagle: revision detection
On Tue, Aug 17, 2010 at 1:10 AM, Tony Lindgren t...@atomide.com wrote:
* Robert Nelson robertcnel...@gmail.com [100816 17:29]:
Due to the omap3530 ES3.0 Silicon being used on both the
B5/B6 and C1/2/3 Beagle we can't use the cpu_is_omap34xx()
routines to differentiate the Beagle Boards.
However gpio pins 171,172,173 where setup for this prupose, so
lets use them.
Changes:
for older U-Boot's, use omap_mux_init_gpio()
keep Beagle Rev in board-omap3beagle.c
Tested on Beagle Revisions: B5, C2, C4, and xMA
Looks good, just one minor comment below.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
Cc: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 79
+++
1 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 87969c7..01a288f 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -50,6 +50,84 @@
#define NAND_BLOCK_SIZE SZ_128K
+/*
+ * OMAP3 Beagle revision
+ * Run time detection of Beagle revision is done by reading GPIO.
+ * GPIO ID -
+ * AXBX = GPIO173, GPIO172, GPIO171: 1 1 1
+ * C1_3 = GPIO173, GPIO172, GPIO171: 1 1 0
+ * C4 = GPIO173, GPIO172, GPIO171: 1 0 1
+ * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ */
+enum {
+ OMAP3BEAGLE_BOARD_AXBX = 0,
+ OMAP3BEAGLE_BOARD_C1_3,
+ OMAP3BEAGLE_BOARD_C4,
+ OMAP3BEAGLE_BOARD_XM,
+};
+
+static u8 omap3_beagle_version;
+
+u8 get_omap3_beagle_rev(void)
+{
+ return omap3_beagle_version;
+}
Please make this static u8 get_omap3_beagle_rev().
Thanks Tony,
that's changed..
Regards,
--
Robert Nelson
http://www.rcn-ee.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: NAND ECC in linux-omap
-Original Message- From: Cliff Brake [mailto:cliff.br...@gmail.com] Sent: Wednesday, August 18, 2010 3:27 AM To: Linux OMAP Users; Ghorai, Sukumar Subject: NAND ECC in linux-omap Hi, I'm using the latest pm branch (based on linux-omap I think), and running into the following problems. The first is my x-loader uses software ECC. Looking in the omap nand driver, I made the following change which gets x-loader/u-boot working again: diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 133d515..1593c60 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -7,7 +7,7 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#define CONFIG_MTD_NAND_OMAP_HWECC +//#define CONFIG_MTD_NAND_OMAP_HWECC #include linux/platform_device.h #include linux/dma-mapping.h But, I'm still getting a ton of ECC errors in JFFS2 flash filesystem. Does anyone have any suggestions as to where to go from here? I see some patches on the mail lists from Sukumar Ghorai that make HW/SW ECC selectable from the board file. Thanks, Cliff [Ghorai] 1. Can you send the git tree link and branch you are referring? 2. I am working to support the NAND BCH and not upstream yet, how you apply this patch in PM branch. 3. which x-loader and u-boot you are referring? And no x-loader/ u-boot supports the BCH -- = http://bec-systems.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] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
This change adds in MMC and I2C support to the HTC Herald board, as well
as adding the HTCPLD driver for the PLD used on this phone. It also
adds in the gpio-keys entries for the front directional keys and
selector and the cursor keys on the slide-out keyboard, and gpio-leds
support for the LEDs attached to the htcpld.
Additionally, SPI bus support (using the spi100k driver) and
touchscreen support (using the ads7846 driver) were added.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/board-htcherald.c | 322 -
1 files changed, 316 insertions(+), 6 deletions(-)
This submission is a merging of the two patches:
[OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
[OMAP] htcherald: SPI register config, TSC2046 touchscreen
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 311899f..7ea75c1 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -30,6 +30,13 @@
#include linux/input.h
#include linux/io.h
#include linux/gpio.h
+#include linux/gpio_keys.h
+#include linux/i2c.h
+#include linux/i2c-gpio.h
+#include linux/htcpld.h
+#include linux/leds.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -39,6 +46,7 @@
#include plat/board.h
#include plat/keypad.h
#include plat/usb.h
+#include plat/mmc.h
#include mach/irqs.h
@@ -52,13 +60,123 @@
#define OMAP_LCDC_CTRL_LCD_EN (1 0)
#define OMAP_LCDC_STAT_DONE (1 0)
-static struct omap_lcd_config htcherald_lcd_config __initdata = {
- .ctrl_name = internal,
-};
+/* GPIO definitions for the power button and keyboard slide switch */
+#define HTCHERALD_GPIO_POWER 139
+#define HTCHERALD_GPIO_SLIDE 174
+#define HTCHERALD_GIRQ_BTNS 141
-static struct omap_board_config_kernel htcherald_config[] __initdata = {
- { OMAP_TAG_LCD, htcherald_lcd_config },
-};
+/* GPIO definitions for the touchscreen */
+#define HTCHERALD_GPIO_TS 76
+
+/* HTCPLD definitions */
+
+/*
+ * CPLD Logic
+ *
+ * Chip 3 - 0x03
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * DPAD light x x x x x x x 1
+ * SoundDevx x x x 1 x x x
+ * Screen white1 x x x x x x x
+ * MMC power onx x x x x 1 x x
+ * Happy times (n) 0 x x x x 1 x x
+ *
+ * Chip 4 - 0x04
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * Keyboard light x x x x x x x 1
+ * LCD Bright (4) x x x x x 1 1 x
+ * LCD Bright (3) x x x x x 0 1 x
+ * LCD Bright (2) x x x x x 1 0 x
+ * LCD Bright (1) x x x x x 0 0 x
+ * LCD Off x x x x 0 x x x
+ * LCD image (fb) 1 x x x x x x x
+ * LCD image (white) 0 x x x x x x x
+ * Caps lock LED x x 1 x x x x x
+ *
+ * Chip 5 - 0x05
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * Red (solid) x x x x x 1 x x
+ * Red (flash) x x x x x x 1 x
+ * Green (GSM flash) x x x x 1 x x x
+ * Green (GSM solid) x x x 1 x x x x
+ * Green (wifi flash) x x 1 x x x x x
+ * Blue (bt flash) x 1 x x x x x x
+ * DPAD Int Enable 1 x x x x x x 0
+ *
+ * (Combinations of the above can be made for different colors.)
+ * The direction pad interrupt enable must be set each time the
+ * interrupt is handled.
+ *
+ * Chip 6 - 0x06
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * Vibratorx x x x 1 x x x
+ * Alt LED x x x 1 x x x x
+ * Screen white1 x x x x x x x
+ * Screen whitex x 1 x x x x x
+ * Screen whitex 0 x x x x x x
+ * Enable kbd dpad x x x x x x 0 x
+ * Happy Times 0 1 0 x x x 0 x
+ */
+
+/*
+ * HTCPLD GPIO lines start 16 after OMAP_MAX_GPIO_LINES to account
+ * for the 16 MPUIO lines.
+ */
+#define HTCPLD_GPIO_START_OFFSET (OMAP_MAX_GPIO_LINES + 16)
+#define HTCPLD_IRQ(chip, offset) (OMAP_IRQ_END + 8 * (chip) + (offset))
+#define HTCPLD_BASE(chip, offset) \
+ (HTCPLD_GPIO_START_OFFSET + 8 * (chip) + (offset))
+
+#define HTCPLD_GPIO_LED_DPAD HTCPLD_BASE(0, 0)
+#define HTCPLD_GPIO_LED_KBDHTCPLD_BASE(1, 0)
+#define HTCPLD_GPIO_LED_CAPS HTCPLD_BASE(1, 5)
+#define HTCPLD_GPIO_LED_RED_FLASH HTCPLD_BASE(2, 1)
+#define HTCPLD_GPIO_LED_RED_SOLID HTCPLD_BASE(2, 2)
+#define HTCPLD_GPIO_LED_GREEN_FLASHHTCPLD_BASE(2, 3)
+#define HTCPLD_GPIO_LED_GREEN_SOLIDHTCPLD_BASE(2, 4)
+#define HTCPLD_GPIO_LED_WIFI HTCPLD_BASE(2, 5)
+#define HTCPLD_GPIO_LED_BT HTCPLD_BASE(2, 6)
+#define HTCPLD_GPIO_LED_VIBRATEHTCPLD_BASE(3, 3)
+#define HTCPLD_GPIO_LED_ALTHTCPLD_BASE(3, 4)
+
+#define HTCPLD_GPIO_RIGHT_KBD HTCPLD_BASE(6, 7)
+#define HTCPLD_GPIO_UP_KBD HTCPLD_BASE(6,
[PATCH] [OMAP] HTCHERALD: MMC, I2C, HTCPLD, SPI, TSC2046
This change adds in MMC and I2C support to the HTC Herald board, as well
as adding the HTCPLD driver for the PLD used on this phone. It also
adds in the gpio-keys entries for the front directional keys and
selector and the cursor keys on the slide-out keyboard, and gpio-leds
support for the LEDs attached to the htcpld.
Additionally, SPI bus support (using the spi100k driver) and
touchscreen support (using the ads7846 driver) were added.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/board-htcherald.c | 322 -
1 files changed, 316 insertions(+), 6 deletions(-)
This submission is a merging of the two patches:
[OMAP] HTCHERALD: MMC, I2C, HTCPLD and related devices
[OMAP] htcherald: SPI register config, TSC2046 touchscreen
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 311899f..7ea75c1 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -30,6 +30,13 @@
#include linux/input.h
#include linux/io.h
#include linux/gpio.h
+#include linux/gpio_keys.h
+#include linux/i2c.h
+#include linux/i2c-gpio.h
+#include linux/htcpld.h
+#include linux/leds.h
+#include linux/spi/spi.h
+#include linux/spi/ads7846.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -39,6 +46,7 @@
#include plat/board.h
#include plat/keypad.h
#include plat/usb.h
+#include plat/mmc.h
#include mach/irqs.h
@@ -52,13 +60,123 @@
#define OMAP_LCDC_CTRL_LCD_EN (1 0)
#define OMAP_LCDC_STAT_DONE (1 0)
-static struct omap_lcd_config htcherald_lcd_config __initdata = {
- .ctrl_name = internal,
-};
+/* GPIO definitions for the power button and keyboard slide switch */
+#define HTCHERALD_GPIO_POWER 139
+#define HTCHERALD_GPIO_SLIDE 174
+#define HTCHERALD_GIRQ_BTNS 141
-static struct omap_board_config_kernel htcherald_config[] __initdata = {
- { OMAP_TAG_LCD, htcherald_lcd_config },
-};
+/* GPIO definitions for the touchscreen */
+#define HTCHERALD_GPIO_TS 76
+
+/* HTCPLD definitions */
+
+/*
+ * CPLD Logic
+ *
+ * Chip 3 - 0x03
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * DPAD light x x x x x x x 1
+ * SoundDevx x x x 1 x x x
+ * Screen white1 x x x x x x x
+ * MMC power onx x x x x 1 x x
+ * Happy times (n) 0 x x x x 1 x x
+ *
+ * Chip 4 - 0x04
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * Keyboard light x x x x x x x 1
+ * LCD Bright (4) x x x x x 1 1 x
+ * LCD Bright (3) x x x x x 0 1 x
+ * LCD Bright (2) x x x x x 1 0 x
+ * LCD Bright (1) x x x x x 0 0 x
+ * LCD Off x x x x 0 x x x
+ * LCD image (fb) 1 x x x x x x x
+ * LCD image (white) 0 x x x x x x x
+ * Caps lock LED x x 1 x x x x x
+ *
+ * Chip 5 - 0x05
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * Red (solid) x x x x x 1 x x
+ * Red (flash) x x x x x x 1 x
+ * Green (GSM flash) x x x x 1 x x x
+ * Green (GSM solid) x x x 1 x x x x
+ * Green (wifi flash) x x 1 x x x x x
+ * Blue (bt flash) x 1 x x x x x x
+ * DPAD Int Enable 1 x x x x x x 0
+ *
+ * (Combinations of the above can be made for different colors.)
+ * The direction pad interrupt enable must be set each time the
+ * interrupt is handled.
+ *
+ * Chip 6 - 0x06
+ *
+ * Function7 6 5 4 3 2 1 0
+ *
+ * Vibratorx x x x 1 x x x
+ * Alt LED x x x 1 x x x x
+ * Screen white1 x x x x x x x
+ * Screen whitex x 1 x x x x x
+ * Screen whitex 0 x x x x x x
+ * Enable kbd dpad x x x x x x 0 x
+ * Happy Times 0 1 0 x x x 0 x
+ */
+
+/*
+ * HTCPLD GPIO lines start 16 after OMAP_MAX_GPIO_LINES to account
+ * for the 16 MPUIO lines.
+ */
+#define HTCPLD_GPIO_START_OFFSET (OMAP_MAX_GPIO_LINES + 16)
+#define HTCPLD_IRQ(chip, offset) (OMAP_IRQ_END + 8 * (chip) + (offset))
+#define HTCPLD_BASE(chip, offset) \
+ (HTCPLD_GPIO_START_OFFSET + 8 * (chip) + (offset))
+
+#define HTCPLD_GPIO_LED_DPAD HTCPLD_BASE(0, 0)
+#define HTCPLD_GPIO_LED_KBDHTCPLD_BASE(1, 0)
+#define HTCPLD_GPIO_LED_CAPS HTCPLD_BASE(1, 5)
+#define HTCPLD_GPIO_LED_RED_FLASH HTCPLD_BASE(2, 1)
+#define HTCPLD_GPIO_LED_RED_SOLID HTCPLD_BASE(2, 2)
+#define HTCPLD_GPIO_LED_GREEN_FLASHHTCPLD_BASE(2, 3)
+#define HTCPLD_GPIO_LED_GREEN_SOLIDHTCPLD_BASE(2, 4)
+#define HTCPLD_GPIO_LED_WIFI HTCPLD_BASE(2, 5)
+#define HTCPLD_GPIO_LED_BT HTCPLD_BASE(2, 6)
+#define HTCPLD_GPIO_LED_VIBRATEHTCPLD_BASE(3, 3)
+#define HTCPLD_GPIO_LED_ALTHTCPLD_BASE(3, 4)
+
+#define HTCPLD_GPIO_RIGHT_KBD HTCPLD_BASE(6, 7)
+#define HTCPLD_GPIO_UP_KBD HTCPLD_BASE(6,
