Re: [PATCH 1/1] Added sleep support to UART
* Tony Lindgren [EMAIL PROTECTED] [080609 22:11]:
Hi,
Sorry for the delay on looking at this, it's looking pretty good in
general. Few more mostly cosmetic comments below.
Here's one more comment:
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
if (omap2_pm_debug) {
unsigned long long tmp;
- u32 resume_time;
+ s64 resume_time;
+ struct timespec t;
- resume_time = omap2_read_32k_sync_counter();
+ getnstimeofday(t);
+ resume_time = timespec_to_ns(t);
tmp = resume_time - sleep_time;
- tmp *= 100;
- omap2_pm_dump(0, 1, tmp / 32768);
+ omap2_pm_dump(0, 1, tmp / 1000);
}
You should make all these calculations using timespec_sub():
struct timespec ts1, ts2, ts_delta;
getnstimeofday(ts1);
getnstimeofday(ts2);
ts_delta = timespec_sub(ts2, ts1);
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/02] OMAP3 CPUidle patches
Hi, The next couple of patches which follow implement the Basic OMAP3 CPUidle driver. The following C states are defined C0 - System executing code C1 - MPU WFI + Core active C2 - MPU CSWR + Core active C3 - MPU OFF + Core active C4 - MPU CSWR + Core CSWR C5 - MPU OFF + Core CSWR C6 - MPU OFF + Core OFF Currently only C0/C1/C2/C4 are enabled as OFF support is missing. For now CPUidle is kept disabled by default. regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
GUI on omap-osk
Dear All, Could some one tell me how to install Qtopia/OPIE/QTEmbedded on omap5912 -osk? Thank you, Shareef -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GUI on omap-osk
On Tuesday 10 June 2008 09:31:18 mohammed shareef wrote: Dear All, Could some one tell me how to install Qtopia/OPIE/QTEmbedded on omap5912 -osk? That's probably a bit off-topic for this list. Try the Qtopia-Interest mailing list we run: http://lists.trolltech.com/qtopia-interest/ I'll try to help you on there. Cheers, Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: doubt about adding entries in mux.c
Arun, J15 is the ball on the BGA package that I2C2_SCL is assigned to on the OMAP242x. The reason this may be important for some signals, is they may actually have multiplexing options to come out on a number of different balls. The I2C2_SCL only comes out on J15, so it is redundant, but for convention purposes, stating the ball is used. Brandon Azbell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arun KS Sent: Tuesday, June 10, 2008 6:19 AM To: linux-omap@vger.kernel.org Subject: doubt about adding entries in mux.c Hi all, Is there any naming convention for adding the entry in mux.c? I could'nt understand what this J15 signifies in the following name, J15_24XX_I2C2_SCL, for example. Could someone help me. Best Regards, Arun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Added sleep support to UART
Hi,
I'll resend the patch in the following email. Comments below what has
been changed.
-Original Message-
From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: 10 June, 2008 09:06
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/1] Added sleep support to UART
* Tony Lindgren [EMAIL PROTECTED] [080609 22:11]:
Hi,
Sorry for the delay on looking at this, it's looking pretty good in
general. Few more mostly cosmetic comments below.
Here's one more comment:
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
if (omap2_pm_debug) {
unsigned long long tmp;
- u32 resume_time;
+ s64 resume_time;
+ struct timespec t;
- resume_time = omap2_read_32k_sync_counter();
+ getnstimeofday(t);
+ resume_time = timespec_to_ns(t);
tmp = resume_time - sleep_time;
- tmp *= 100;
- omap2_pm_dump(0, 1, tmp / 32768);
+ omap2_pm_dump(0, 1, tmp / 1000);
}
You should make all these calculations using timespec_sub():
struct timespec ts1, ts2, ts_delta;
getnstimeofday(ts1);
getnstimeofday(ts2);
ts_delta = timespec_sub(ts2, ts1);
Fixed this in several places now to use timespec_sub, timespec_add and
timespec_compare.
copy-paste from another email
+#if defined(CONFIG_ARCH_OMAP2)
+static const u32 omap_uart_fclk_mask[OMAP_MAX_NR_PORTS] = {
+OMAP24XX_EN_UART1, OMAP24XX_EN_UART2, OMAP24XX_EN_UART3 };
#endif
+
+#if defined(CONFIG_ARCH_OMAP3)
+static const u32 omap_uart_fclk_mask[OMAP_MAX_NR_PORTS] = {
+OMAP3430_EN_UART1, OMAP3430_EN_UART2, OMAP3430_EN_UART3 };
The above should be omap24xx_uart_fclk_mask and
omap34xx_uart_fclk_mask.
Otherwise we cannot compile in both 24xx and 34xx into the same kernel.
Changed. Added omap_uart_fclk_mask to point to these structures though,
initialized at boot time. Also removed those #ifdef:s from the code.
+/* UART padconfig registers, these may differ if non-default
padconfig
+ is used */
+#define CONTROL_PADCONF_UART1_RX 0x48002182 #define
+CONTROL_PADCONF_UART2_RX 0x4800217A #define CONTROL_PADCONF_UART3_RX
+0x4800219E #define PADCONF_WAKEUP_ST 0x8000
+
+static const u32 omap_uart_padconf[OMAP_MAX_NR_PORTS] = {
+CONTROL_PADCONF_UART1_RX, CONTROL_PADCONF_UART2_RX,
+CONTROL_PADCONF_UART3_RX }; #endif
This should be omap34xx_uart_padconf is only used for 34xx. Also, it's
currently not defined for 24xx and breaks build.
Changed.
+void omap_serial_check_wakeup(void)
+{
+int i;
+
+if (cpu_is_omap34xx())
+for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+if (!uart_ick[i])
+continue;
+if (omap_readw(omap_uart_padconf[i])
PADCONF_WAKEUP_ST)
+omap_serial_kick();
+return;
+}
The formatting for return above looks one tab too much to the right?
This is actually a hidden bug, that return should be part of that if
statement. Luckily enough the code worked if you had only one UART
enabled in configs. Added braces around that stuff now.
+if (cpu_is_omap24xx()) {
+u32 l;
+
+for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+if (!uart_ick[i])
+continue;
+l = prm_read_mod_reg(CORE_MOD,
omap2_uart_wk_st[i]);
+if (l omap2_uart_wk_bit[i])
+omap_serial_kick();
+return;
+}
+}
+}
Here too.
Similar bug.
+
+if (cpu_is_omap24xx())
+prm_set_mod_reg_bits(omap2_uart_wk_bit[i],
CORE_MOD,
+omap2_uart_wk_en[i]);
}
How about run the patch through checkpatch.pl, this line looks too
long?
Ok, split the code lines that caused warnings now to be multiline
statements.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
omap osk audio
Dear all, I am working on omap osk. i want to enable audio on it. But am not able to do that. The kernel boot log says it has initialized audio device. but i am not able to configure the audio setting nor run some recording code. the system hangs and i have to restart. the kernel boot code says: TLV320AIC23 I2C version 1.8 (10-Feb-2006) audio support initialized ALSA device list: #0: OSK AIC23 i have created nodes: # mknod /dev/mixer c 14 0 # mknod /dev/dsp c 14 3 thanx, Shareef -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge
Thanks Hari, I took these changes and built new bridgedriver.ko. I could see 50% reduction in time taken to queue a buffer of size of 3MB. (old time: 28 ms, new time: 13 ms). If I reserve and map a buffer only once and use the mapped address for future (avoiding map/unmap every time) I get better numbers (9 ms). So only thing which I am doing is flushing the buffer for consistency since this buffer is input to codec on DSP. But 9ms only for flushing seems very high. I am not 100% sure, but it seems like the kernel flush code is scanning through all the virtual addresses of the buffer and flush if any of those are cached. But actually the L2 cache is only 256Kb. So a small part of the buffer might be in cache ( 256Kb). This will add unnecessary overhead for huge (my buffer size is 3MB) buffers. Is there any way so that I can flush full cache to avoid overhead? Regards, Viraj -Original Message- From: Kanigeri, Hari [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 10:51 PM To: Viraj Karandikar; Gupta, Ramesh; linux-omap@vger.kernel.org Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hi Viraj, You can use the attached file to get the DMM optimimzation that Ramesh is referring to. The location of this file is mpu_driver\src\wmd\omap\3430 Thank you, Best regards, Hari -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viraj Karandikar Sent: Monday, June 09, 2008 10:18 AM To: Gupta, Ramesh; linux-omap@vger.kernel.org Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Thanks Ramesh. I was reserving and mapping buffers every time. This was not required. I modified the code to reserve and map a buffer only once and use the mapped address for future. This modification reduced the overhead. I have one more doubt. Does DSP use virtual-to-physical mapping for all the addresses it accesses (including DSP's local buffers)? Or it uses this mapping only to access shared buffers? Wont it be a big overhead if DSP accesses all the memories through virtual-to-physical mapping? Regards, Viraj -Original Message- From: Ramesh Gupta G [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 11:03 AM To: Viraj Karandikar; [EMAIL PROTECTED] Subject: Re: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hi Vijay, - Original Message - From: Viraj Karandikar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 07, 2008 3:45 PM Subject: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hi all, I am working on omap3430 using bridge. I am using Dynamically Mapped Memory (DMM) method for sharing buffers. For sending buffers to DSP I am doing calls to DSPProcessor_ReserveMemory() and DSPProcessor_Map(). For these calls are taking around 18ms (for 3-4MB buffers) which is not acceptable for the application. I am not able to understand why it is taking so much time? Which version of bridge you are using? We have optimized the code for DSPProcessor_Map(), You can see significant change in the numbers with the latest code. My understanding of DMM method is - - Use malloc() to allocate a buffer on ARM. - Reserve required chunk of memory from DMM pool (using DSPProcessor_ReserveMemory() ) - Translate this memory to ARM virtual address space in DSPProcessor_Map() function. Actually DSPProcessor_Map() maps ARM physical addresses to DSP Virtual addresses. - Send the reserved memory address to DSP. Is this correct? I am confused about how exactly this happens. You are correct except above point about DSPProcessor_Map(). Also Ihave a doubt if the reserved memory address is from DSP physical address space? Or is it from ARM virtual address space for DSP physical address space? Reserved Memory is from DSP Virtual Address. Is DMM method does copy from malloc'ed address to reserved address in any way? Do you mean copying the contents? No copying is involved. Only mapping of addresses is performed. It will be helpful if anybody put some light on this. Please let me know if you see any issues. Regards, Viraj Thanks Regards Ramesh Gupta G ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] ** ___ Linux-omap-open-source mailing list [EMAIL PROTECTED] http://linux.omap.com/mailman/listinfo/linux-omap-open-source -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at
[PATCH 2/3] tea5761 tuner: fix registers utilization
From: Eduardo Valentin [EMAIL PROTECTED]
Fix registers utilization.
tnctrl register was supposed to be used but it was
right shifted. frqset also was being configured using
incorrect equation.
Signed-off-by: Eduardo Valentin [EMAIL PROTECTED]
---
drivers/media/common/tuners/tea5761.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/tuners/tea5761.c
b/drivers/media/common/tuners/tea5761.c
index 8e86cb2..b3d4786 100644
--- a/drivers/media/common/tuners/tea5761.c
+++ b/drivers/media/common/tuners/tea5761.c
@@ -101,6 +101,8 @@ struct tea5761_priv {
/* All zero = no test mode */
+#define TEA5761_TESTREG_TRIGFR 0x08
+
/* MANID - Read: bytes 12 and 13 */
/* First byte - should be 0x10 */
@@ -147,20 +149,21 @@ static int set_radio_freq(struct dvb_frontend *fe,
if (params-mode == T_STANDBY) {
tuner_dbg(TEA5761 set to standby mode\n);
- buffer[5] |= TEA5761_TNCTRL_MU;
+ buffer[4] |= TEA5761_TNCTRL_MU;
} else {
- buffer[4] |= TEA5761_TNCTRL_PUPD_0;
+ buffer[3] |= TEA5761_TNCTRL_PUPD_0;
}
+ buffer[5] = TEA5761_TESTREG_TRIGFR;
if (params-audmode == V4L2_TUNER_MODE_MONO) {
tuner_dbg(TEA5761 set to mono\n);
- buffer[5] |= TEA5761_TNCTRL_MST;
+ buffer[4] |= TEA5761_TNCTRL_MST;
} else {
tuner_dbg(TEA5761 set to stereo\n);
}
- div = (1000 * (frq * 4 / 16 + 700 + 225) ) 15;
+ div = (frq * 125 / 2 - 225000) 13;
buffer[1] = (div 8) 0x3f;
buffer[2] = div 0xff;
--
1.5.6.rc0.84.g06f60.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Updates for tea5761 (take #3)
From: Eduardo Valentin [EMAIL PROTECTED] Hi guys, Following recommendation from v4l people, I'm sending this update to our tea5761 driver. They already had a tuner for this device which communicates through i2c. I needed to update it because there were some register mis-utilization. Here is a series which updates their tuner and our driver. After acks and merging here in linux-omap I'll send it to v4l again. Cheers, Eduardo Valentin (3): tea5761: Add init and sleep callbacks on tea5761 tuner tea5761 tuner: fix registers utilization radio-tea5761: Update driver drivers/media/common/tuners/tea5761.c | 55 +++- drivers/media/radio/Kconfig |1 + drivers/media/radio/Makefile |2 + drivers/media/radio/radio-tea5761.c | 570 - 4 files changed, 329 insertions(+), 299 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tea5761: Add init and sleep callbacks on tea5761 tuner
From: Eduardo Valentin [EMAIL PROTECTED]
Add init and sleep callbacks on tea5761 tuner
Signed-off-by: Eduardo Valentin [EMAIL PROTECTED]
---
drivers/media/common/tuners/tea5761.c | 44 +
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/tea5761.c
b/drivers/media/common/tuners/tea5761.c
index b93cdef..8e86cb2 100644
--- a/drivers/media/common/tuners/tea5761.c
+++ b/drivers/media/common/tuners/tea5761.c
@@ -175,6 +175,48 @@ static int set_radio_freq(struct dvb_frontend *fe,
return 0;
}
+static int tea5761_init(struct dvb_frontend *fe)
+{
+ struct tea5761_priv *priv = fe-tuner_priv;
+ unsigned char buffer[] = {0, 0, 0, 0, 0, 0, 0 };
+ int rc;
+
+ tuner_dbg(Power up radio\n);
+
+ buffer[3] = TEA5761_TNCTRL_PUPD_0;
+
+ if (debug)
+ tea5761_status_dump(buffer);
+
+ rc = tuner_i2c_xfer_send(priv-i2c_props, buffer, ARRAY_SIZE(buffer));
+ if (rc != ARRAY_SIZE(buffer))
+ tuner_warn(i2c i/o error: rc == %d (should be %d)\n, rc,
+ ARRAY_SIZE(buffer));
+
+ return 0;
+}
+
+static int tea5761_sleep(struct dvb_frontend *fe)
+{
+ struct tea5761_priv *priv = fe-tuner_priv;
+ unsigned char buffer[] = {0, 0, 0, 0, 0, 0, 0 };
+ int rc;
+
+ tuner_dbg(Power down radio\n);
+
+ buffer[3] = ~TEA5761_TNCTRL_PUPD_0;
+
+ if (debug)
+ tea5761_status_dump(buffer);
+
+ rc = tuner_i2c_xfer_send(priv-i2c_props, buffer, ARRAY_SIZE(buffer));
+ if (rc != ARRAY_SIZE(buffer))
+ tuner_warn(i2c i/o error: rc == %d (should be %d)\n, rc,
+ ARRAY_SIZE(buffer));
+
+ return 0;
+}
+
static int tea5761_read_status(struct dvb_frontend *fe, char *buffer)
{
struct tea5761_priv *priv = fe-tuner_priv;
@@ -287,6 +329,8 @@ static struct dvb_tuner_ops tea5761_tuner_ops = {
.get_frequency = tea5761_get_frequency,
.get_status= tea5761_get_status,
.get_rf_strength = tea5761_get_rf_strength,
+ .init = tea5761_init,
+ .sleep = tea5761_sleep,
};
struct dvb_frontend *tea5761_attach(struct dvb_frontend *fe,
--
1.5.6.rc0.84.g06f60.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] radio-tea5761: Update driver
Hi Balbi, On Mon, Jun 9, 2008 at 10:07 PM, Felipe Balbi [EMAIL PROTECTED] wrote: On Mon, Jun 09, 2008 at 09:14:21PM -0400, Eduardo Valentin wrote: If I understood correctly what you said, the same comment I said before also applies here. Eventhough it prints that the probe failed, this way I sent it says: The probe failed and The driver registration failed. More easy to debug the code when in a error situation. But if probe fails, driver registration failed. The same comment Jean Delvare gave me when I was sending some isp1301 patches upstream, so later on, when this driver goes to mailine, it'll probably, if Jean happens to see this one, get commented on this point as well. If you look at drivers/i2c/chips/*.c you'll see that only in two cases they are printing error if i2c_add_driver() fails and those are really necessary cases (check those drivers). But anyway, if you think it's really necessary. Ok. I've just resent the whole series with this message removed. :) -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] radio-tea5761: Update driver
From: Eduardo Valentin [EMAIL PROTECTED]
This patch updates this driver by changing the way it accesses
the device. There is the tuner API which already has an implementation
for tea5761.
This patch changes the driver to use tuner API.
It also changes the way ioctls are handled. This way
it is more easy to deal with v4l2 and v4l calls.
Some cleans are also done.
Signed-off-by: Eduardo Valentin [EMAIL PROTECTED]
---
drivers/media/radio/Kconfig |1 +
drivers/media/radio/Makefile|2 +
drivers/media/radio/radio-tea5761.c | 570 +--
3 files changed, 278 insertions(+), 295 deletions(-)
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index de6ca27..b45f834 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -341,6 +341,7 @@ config RADIO_ZOLTRIX_PORT
config RADIO_TEA5761
tristate Philips Semiconductors TEA5761 I2C FM Radio
+ depends on MEDIA_TUNER_TEA5761
help
Choose Y here if you have one of these AM/FM radio cards.
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f5bffcc..a843007 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -25,3 +25,5 @@ obj-$(CONFIG_USB_DSBR) += dsbr100.o
obj-$(CONFIG_USB_SI470X) += radio-si470x.o
EXTRA_CFLAGS += -Isound
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/
+EXTRA_CFLAGS += -Idrivers/media/common/tuners/
diff --git a/drivers/media/radio/radio-tea5761.c
b/drivers/media/radio/radio-tea5761.c
index e8ccf29..cc39a44 100644
--- a/drivers/media/radio/radio-tea5761.c
+++ b/drivers/media/radio/radio-tea5761.c
@@ -23,79 +23,29 @@
#include linux/i2c.h
#include linux/delay.h
#include media/v4l2-common.h
+#include media/tuner.h
+
+#include dvb_frontend.h
+#include tea5761.h
#define DRIVER_NAME tea5761
#define TEA5761_VERSIONKERNEL_VERSION(0, 0, 1)
-#define TEA5761_I2C_ADDR 0x10
-
-#define TEA5761_MANID 0x002b
-#define TEA5761_CHIPID 0x5761
-
-#define TEA5761_INTREG_BLMSK 0x0001
-#define TEA5761_INTREG_FRRMSK 0x0002
-#define TEA5761_INTREG_LEVMSK 0x0008
-#define TEA5761_INTREG_IFMSK 0x0010
-#define TEA5761_INTREG_BLMFLAG 0x0100
-#define TEA5761_INTREG_FRRFLAG 0x0200
-#define TEA5761_INTREG_LEVFLAG 0x0800
-#define TEA5761_INTREG_IFFLAG 0x1000
-
-#define TEA5761_FRQSET_SUD 0x8000
-#define TEA5761_FRQSET_SM 0x4000
-
-#define TEA5761_TNCTRL_PUPD0 0x4000
-#define TEA5761_TNCTRL_BLIM0x2000
-#define TEA5761_TNCTRL_SWPM0x1000
-#define TEA5761_TNCTRL_IFCTC 0x0800
-#define TEA5761_TNCTRL_AFM 0x0400
-#define TEA5761_TNCTRL_SMUTE 0x0200
-#define TEA5761_TNCTRL_SNC 0x0100
-#define TEA5761_TNCTRL_MU 0x0080
-#define TEA5761_TNCTRL_SSL10x0040
-#define TEA5761_TNCTRL_SSL00x0020
-#define TEA5761_TNCTRL_HLSI0x0010
-#define TEA5761_TNCTRL_MST 0x0008
-#define TEA5761_TNCTRL_SWP 0x0004
-#define TEA5761_TNCTRL_DTC 0x0002
-#define TEA5761_TNCTRL_AHLSI 0x0001
-
-#define TEA5761_TUNCHK_LEVEL(x)(((x) 0x00F0) 4)
-#define TEA5761_TUNCHK_IFCNT(x) (((x) 0xFE00) 9)
-#define TEA5761_TUNCHK_TUNTO 0x0100
-#define TEA5761_TUNCHK_LD 0x0008
-#define TEA5761_TUNCHK_STEREO 0x0004
-
-#define TEA5761_TESTREG_TRIGFR 0x0800
-
#define TEA5761_FREQ_LOW 87500
#define TEA5761_FREQ_HIGH 108000
-struct tea5761_regs {
- u16 intreg;
- u16 frqset;
- u16 tnctrl;
- u16 frqchk;
- u16 tunchk;
- u16 testreg;
- u16 manid;
- u16 chipid;
-} __attribute__ ((packed));
-
-struct tea5761_write_regs {
- u8 intreg;
- u16 frqset;
- u16 tnctrl;
- u16 testreg;
-} __attribute__ ((packed));
-
struct tea5761_device {
struct video_device *video_dev;
- struct i2c_client *i2c_dev;
- struct tea5761_regs regs;
+ struct device *dev;
+ struct dvb_frontend fe;
+ /* To control number of users access (.users field) */
struct mutexmutex;
int users;
+ unsigned intfreq;
+ u16 audmode;
+ u8 mute;
+ u8 power;
};
static struct tea5761_device tea5761;
@@ -103,267 +53,286 @@ static struct tea5761_device tea5761;
static struct i2c_driver tea5761_driver;
static int radio_nr = -1;
-static int tea5761_read_regs(struct tea5761_device *tea)
+static void tea5761_power_up(struct tea5761_device *tea)
{
- int rc, i;
- u16 *p = (u16 *) tea-regs;
- struct i2c_client *client = tea-i2c_dev;
+ struct dvb_frontend *fe = tea-fe;
+ struct dvb_tuner_ops *fe_tuner_ops = fe-ops.tuner_ops;
- rc = i2c_master_recv(client, (void*) tea-regs, sizeof(tea-regs));
- for (i = 0; i 8; i++) {
- p[i] = __be16_to_cpu(p[i]);
- }
+ if (fe_tuner_ops-init)
+
Re: [PATCH 00/02] OMAP3 CPUidle patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 10 jun 2008, om 09:08 heeft Rajendra Nayak het volgende geschreven: Hi, The next couple of patches which follow implement the Basic OMAP3 CPUidle driver. The following C states are defined C0 - System executing code C1 - MPU WFI + Core active C2 - MPU CSWR + Core active C3 - MPU OFF + Core active C4 - MPU CSWR + Core CSWR C5 - MPU OFF + Core CSWR C6 - MPU OFF + Core OFF Currently only C0/C1/C2/C4 are enabled as OFF support is missing. For now CPUidle is kept disabled by default. Seems to work on my beagleboard. regards, Koen regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFITudCMkyGM64RGpERAnuDAKCv6C9SSiPxFiYaBJ48McdXD6pgvACcCe55 tP803wO51XzvFGdLjRgptJA= =o2j3 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend][PATCH] Fix for the i2c initialization error on 2430sdp
* Eduardo Valentin [EMAIL PROTECTED] [080609 05:55]:
On Mon, Jun 9, 2008 at 2:25 AM, arun c [EMAIL PROTECTED] wrote:
Hi all,
Resending the patch after incorporating comments from
Chandra , Eduardo Valentin and Felipe.
From ee2a6fd572c6d0464166fc8123982a38b36e7776 Mon Sep 17 00:00:00 2001
From: arun [EMAIL PROTECTED]
Date: Fri, 6 Jun 2008 18:18:50 +0530
Subject: [PATCH] Fix for the i2c initialization error on 2430sdp
Signed-off-by: arun [EMAIL PROTECTED]
Acked-by: Eduardo Valentin [EMAIL PROTECTED]
Pushing today.
Tony
---
arch/arm/mach-omap2/board-2430sdp.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index e078a2a..780913e 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -379,8 +379,12 @@ static struct omap_board_config_kernel
sdp2430_config[] __initdata = {
static int __init omap2430_i2c_init(void)
{
- omap_register_i2c_bus(1, 400, NULL, 0);
+ /*
+* Registering bus 2 first to avoid twl4030 misbehaving as 2430SDP
+* has twl4030 on bus 2
+*/
omap_register_i2c_bus(2, 2600, NULL, 0);
+ omap_register_i2c_bus(1, 400, NULL, 0);
return 0;
}
--
1.5.3.4
#
Regards,
Arun C
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd omap2 nand driver: extend to work with omap3 boards
Hi,
* Steve Sakoman [EMAIL PROTECTED] [080531 23:38]:
From: Teerth Reddy [EMAIL PROTECTED], Steve Sakoman [EMAIL PROTECTED]
Extend omap2 mtd nand driver to work with ARCH_OMAP3 boards
This patch is pretty badly wrapped, can you please repost using some
working mailer + server combo? Please check the other patches too.
Thanks,
Tony
Signed-off-by: Steve Sakoman [EMAIL PROTECTED]
---
Kconfig |6 -
omap2.c | 230
2 files changed, 147 insertions(+), 89 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3d5e432..02b9ced 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -70,10 +70,10 @@ config MTD_NAND_AMS_DELTA
Support for NAND flash on Amstrad E3 (Delta).
config MTD_NAND_OMAP2
- tristate NAND Flash device on OMAP 2420H4/2430SDP boards
- depends on (ARM ARCH_OMAP2 MTD_NAND)
+ tristate NAND Flash device on OMAP2 and OMAP3
+ depends on ARM MTD_NAND (ARCH_OMAP2 || ARCH_OMAP3)
help
- Support for NAND flash on Texas Instruments 2430SDP/2420H4
platforms.
+ Support for NAND flash on Texas Instruments OMAP2 and OMAP3
platforms.
config MTD_NAND_OMAP
tristate NAND Flash device on OMAP H3/H2/P2 boards
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3b7307c..3aac1d2 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -111,15 +111,6 @@
static const char *part_probes[] = { cmdlinepart, NULL };
#endif
-static int hw_ecc = 1;
-
-/* new oob placement block for use with hardware ecc generation */
-static struct nand_ecclayout omap_hw_eccoob = {
- .eccbytes = 12,
- .eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
- .oobfree = {{16, 32}, {33, 63} },
-};
-
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -133,6 +124,13 @@ struct omap_nand_info {
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
};
+
+/*
+ * omap_nand_wp - This function enable or disable the Write Protect feature
on
+ * NAND device
+ * @mtd: MTD device structure
+ * @mode: WP ON/OFF
+ */
static void omap_nand_wp(struct mtd_info *mtd, int mode)
{
struct omap_nand_info *info = container_of(mtd,
@@ -189,11 +187,11 @@ static void omap_hwcontrol(struct mtd_info *mtd,
int cmd, unsigned int ctrl)
}
/*
-* omap_read_buf - read data from NAND controller into buffer
-* @mtd: MTD device structure
-* @buf: buffer to store date
-* @len: number of bytes to read
-*/
+ * omap_read_buf - read data from NAND controller into buffer
+ * @mtd: MTD device structure
+ * @buf: buffer to store date
+ * @len: number of bytes to read
+ */
static void omap_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
struct omap_nand_info *info = container_of(mtd,
@@ -207,11 +205,11 @@ static void omap_read_buf(struct mtd_info *mtd,
u_char *buf, int len)
}
/*
-* omap_write_buf - write buffer to NAND controller
-* @mtd: MTD device structure
-* @buf: data buffer
-* @len: number of bytes to write
-*/
+ * omap_write_buf - write buffer to NAND controller
+ * @mtd: MTD device structure
+ * @buf: data buffer
+ * @len: number of bytes to write
+ */
static void omap_write_buf(struct mtd_info *mtd, const u_char * buf, int len)
{
struct omap_nand_info *info = container_of(mtd,
@@ -250,10 +248,16 @@ static int omap_verify_buf(struct mtd_info *mtd,
const u_char * buf, int len)
return 0;
}
+#ifdef CONFIG_MTD_NAND_OMAP_HWECC
+/*
+ * omap_hwecc_init-Initialize the Hardware ECC for NAND flash in GPMC
controller
+ * @mtd: MTD device structure
+ */
static void omap_hwecc_init(struct mtd_info *mtd)
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ register struct nand_chip *chip = mtd-priv;
unsigned long val = 0x0;
/* Read from ECC Control Register */
@@ -264,16 +268,15 @@ static void omap_hwecc_init(struct mtd_info *mtd)
/* Read from ECC Size Config Register */
val = __raw_readl(info-gpmc_baseaddr + GPMC_ECC_SIZE_CONFIG);
- /* ECCSIZE1=512 | ECCSIZE0=8bytes | Select eccResultsize[0123] */
- val = ((0x00FF22) | (0x000312) | (0x000F));
+ /* ECCSIZE1=512 | Select eccResultsize[0-3] */
+ val = chip-ecc.size 1) - 1) 22) | (0x000F));
__raw_writel(val, info-gpmc_baseaddr + GPMC_ECC_SIZE_CONFIG);
-
-
}
/*
- * This function will generate true ECC value, which can be used
+ * gen_true_ecc - This function will generate true ECC value, which can be
used
* when correcting data read from NAND flash memory core
+ * @ecc_buf: buffer to store ecc code
*/
static void gen_true_ecc(u8 *ecc_buf)
{
@@
Re: [PATCH v2] omap3beagle: add a platform device to hook up the GPIO leds to the leds-gpio driver
* Tony Lindgren [EMAIL PROTECTED] [080610 14:35]: * Koen Kooi [EMAIL PROTECTED] [080610 14:26]: Op 31 mei 2008, om 02:59 heeft Koen Kooi het volgende geschreven: From: Koen Kooi [EMAIL PROTECTED] omap3beagle: add a platform device to hook up the GPIO leds to the leds-gpio driver * on revision A5 and earlier board the two leds can't be controlled seperately, should be fixed in rev. B and C boards. Changes since v1: indented structs with tabs Signed-off-by: Koen Kooi [EMAIL PROTECTED] Any objections against applying this patch? Nope, and blinking leds are always considered the highhest priority patches ;) Pushing today. Actually I ended up reformatting it a bit more. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added sleep support to UART
* Tero Kristo [EMAIL PROTECTED] [080610 07:16]:
UART usage (e.g. serial console) now denies sleep for 5 seconds. This
makes it possible to use serial console when dynamic idle is enabled.
Also moved code from pm-debug.c to serial.c, and made pm24xx.c use this
new implementation.
I've pushed some fixes to l-o tree for CONFIG_PM_DEBUG, and that
requires the following patch for 24xx on top of your patch. Also changed
to use div_s64() to avoid hitting the gcc bug undefined reference
to __aeabi_ldivmod'.
Regards,
Tony
From e1d4cc54adacaa6a713e68b84151935f47be7895 Mon Sep 17 00:00:00 2001
From: Tony Lindgren [EMAIL PROTECTED]
Date: Tue, 10 Jun 2008 17:39:15 -0700
Subject: [PATCH] Fixes for 24xx debug uart handling
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 27af921..304a2e8 100755
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -137,11 +137,12 @@ no_sleep:
if (omap2_pm_debug) {
struct timespec t;
- struct timespec ts_delta
+ struct timespec ts_delta;
getnstimeofday(t);
ts_delta = timespec_sub(t, sleep_time);
- omap2_pm_dump(0, 1, timespec_to_ns(ts_delta) / NSEC_PER_USEC);
+ omap2_pm_dump(0, 1,
+ div_s64(timespec_to_ns(ts_delta), NSEC_PER_USEC));
}
omap2_gpio_resume_after_retention();
@@ -155,16 +156,16 @@ no_sleep:
prm_clear_mod_reg_bits(0x4 | 0x1, WKUP_MOD, PM_WKST);
/* MPU domain wake events */
- l = prm_read_mod_reg(OCP_MOD, OMAP24XX_PRCM_IRQSTATUS_MPU_OFFSET);
+ l = prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET);
if (l 0x01)
prm_write_mod_reg(0x01, OCP_MOD,
- OMAP24XX_PRCM_IRQSTATUS_MPU_OFFSET);
+ OMAP2_PRM_IRQSTATUS_MPU_OFFSET);
if (l 0x20)
prm_write_mod_reg(0x20, OCP_MOD,
- OMAP24XX_PRCM_IRQSTATUS_MPU_OFFSET);
+ OMAP2_PRM_IRQSTATUS_MPU_OFFSET);
/* Mask future PRCM-to-MPU interrupts */
- prm_write_mod_reg(0x0, OCP_MOD, OMAP24XX_PRCM_IRQSTATUS_MPU_OFFSET);
+ prm_write_mod_reg(0x0, OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET);
}
static int omap2_i2c_active(void)
@@ -243,7 +244,7 @@ static void omap2_enter_mpu_retention(void)
getnstimeofday(t);
ts_delta = timespec_sub(t, sleep_time);
omap2_pm_dump(only_idle ? 2 : 1, 1,
- timespec_to_ns(ts_delta) / NSEC_PER_USEC);
+ div_s64(timespec_to_ns(ts_delta), NSEC_PER_USEC));
}
}
@@ -362,7 +363,7 @@ static void __init prcm_setup_regs(void)
/* Enable autoidle */
prm_write_mod_reg(OMAP24XX_AUTOIDLE, OCP_MOD,
- OMAP24XX_PRCM_SYSCONFIG_OFFSET);
+ OMAP24XX_PRM_SYSCONFIG_OFFSET);
/* Set all domain wakeup dependencies */
prm_write_mod_reg(OMAP_EN_WKUP_MASK, MPU_MOD, PM_WKDEP);
@@ -491,7 +492,7 @@ int __init omap2_pm_init(void)
u32 l;
printk(KERN_INFO Power Management for OMAP2 initializing\n);
- l = prm_read_mod_reg(OCP_MOD, OMAP24XX_PRCM_REVISION_OFFSET);
+ l = prm_read_mod_reg(OCP_MOD, OMAP24XX_PRM_REVISION_OFFSET);
printk(KERN_INFO PRCM revision %d.%d\n, (l 4) 0x0f, l 0x0f);
/* Look up important powerdomains, clockdomains */
Re: FW: driver DVI output OMAP3 EVM
ops, I'm sorry, The end of that email: I'm trying to do it on a omap3430sdp. Thanks in advance Best Regards, vivijim On Wed, Jun 11, 2008 at 1:42 AM, Rodrigo Vivi [EMAIL PROTECTED] wrote: Hi there, I'd like to use the vga output trough s-video conector. I already have this 3 files and they seems ok to me. Apparently they are setting correctly all bits. But when echoing tv to /sys/.../graphics the lcd is turned off but nothing appears on the tv... am I missing something? has anyone already tried to do it? is it working? On Mon, Jun 2, 2008 at 9:08 AM, Syed Mohammed, Khasim [EMAIL PROTECTED] wrote: Resending: I think you have received the attachments if not do let me know. -Original Message- From: [EMAIL PROTECTED] [mailto:linux-omap-open-source- [EMAIL PROTECTED] On Behalf Of Royer, Fabien Sent: Monday, June 02, 2008 4:55 PM To: [EMAIL PROTECTED] Subject: driver DVI output OMAP3 EVM Hello, I would like to know how to drive the DVI output on the OMAP3 EVM. Hi Fabien, If you use TI's release for OMAP3 EVM then the mods required to get DVI working is as given below, basically it is hardcoded version, LCD will not work from there on. At present we don't have a version that allows you to dynamically switch between DVI and LCD. The files attached are bit old, may be you have to twik in a bit to get it compiled. Hardware: On EVM 3530 Base board, replace the Resistor R18 (It's near to DVI connector [TOP SIDE] of the board) with a 510 ohm (its 10K now). Software: The attached files have to be copied to respective directories. - arch/arm/plat-omap/display.c - drivers/video/omap/omap_disp_out.c - drivers/video/omap/omap_fb.c Changes for different resolution: It is now configured for 1280x720. If you want to modify it to your monitor resolution then do the following. 1) In arch/arm/plat-omap/display.c function omap2_disp_set_panel_size() dispc_reg_out(DISPC_SIZE_LCD,0x2CF04FF); /* it is 720 = 2cf , 1280 = 0x4ff */ 2) In drivers/video/omap/omap_disp_out.c #define H4_LCD_XRES 1280 /* Change these */ #define H4_LCD_YRES 720 Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Rodrigo Vivi INdT - Instituto Nokia de Tecnologia Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net -- Rodrigo Vivi INdT - Instituto Nokia de Tecnologia Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
