[Resend][PATCH] Fix for the i2c initialization error on 2430sdp
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]
---
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
--
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
DISPC register values to eliminate the omapfb irq errors on 2430SDP
FYI
By changing the gfx fifo threshold and burst size values
i could able to completely eliminate the omapfb irq
error messages on 2430 SDP board.
I am pasting the changes here for anybody
who wants to try it out.
##
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 6aff476..4cf83b6 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -290,8 +290,8 @@ static void setup_plane_fifo(int plane, int ext_mode)
low = l * 3 / 4;
high = l;
} else {
- low = l / 4;
- high = l * 3 / 4;
+ low = l - 64;
+ high = l - 1;
}
MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 9) | FLD_MASK(0, 9),
(high 16) | low);
@@ -409,7 +409,7 @@ static inline int _setup_plane(int plane, int channel_out,
l |= cconv_en 9;
l = ~(0x03 burst_shift);
- l |= DISPC_BURST_8x32 burst_shift;
+ l |= DISPC_BURST_16x32 burst_shift;
l = ~(1 chout_shift);
l |= chout_val chout_shift;
###
Regards,
Arun C
--
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] PRCM: OMAP3: Fix to wrongly modified omap2_clk_wait_ready
omap2_clk_wait_ready was wrongly modified to check registers contents. This fix changes it back to check addresses. Signed-off-by: Jouni Hogander [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c index d3ab537..ed15868 100644 --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -246,8 +246,8 @@ static void omap2_clk_wait_ready(struct clk *clk) /* REVISIT: What are the appropriate exclusions for 34XX? */ /* OMAP3: ignore DSS-mod clocks */ if (cpu_is_omap34xx() - ((reg ~0xff) == cm_read_mod_reg(OMAP3430_DSS_MOD, 0) || -(((reg ~0xff) == cm_read_mod_reg(CORE_MOD, 0)) + ((reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(OMAP3430_DSS_MOD, 0) || +(((reg ~0xff) == (__force u32)OMAP34XX_CM_REGADDR(CORE_MOD, 0)) clk-enable_bit == OMAP3430_EN_SSI_SHIFT))) return; -- 1.5.5 -- 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
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]
---
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
[PATCH 2/2] ARM: OMAP: Add OMAP34xx pin muxing into I2C bus registration helper
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
---
arch/arm/plat-omap/i2c.c | 51 -
1 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 7990ab1..23c2920 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -80,26 +80,39 @@ static struct platform_device omap_i2c_devices[] = {
#endif
};
-static void __init omap_i2c_mux_pins(int bus_id)
+static const int omap1_pins[][2] = {
+ { I2C_SCL, I2C_SDA },
+};
+static const int omap24xx_pins[][2] = {
+ { M19_24XX_I2C1_SCL, L15_24XX_I2C1_SDA },
+ { J15_24XX_I2C2_SCL, H19_24XX_I2C2_SDA },
+};
+static const int omap34xx_pins[][2] = {
+ { K21_34XX_I2C1_SCL, J21_34XX_I2C1_SDA},
+ { AF15_34XX_I2C2_SCL, AE15_34XX_I2C2_SDA},
+ { AF14_34XX_I2C3_SCL, AG14_34XX_I2C3_SDA},
+ { AD26_34XX_I2C4_SCL, AE26_34XX_I2C4_SDA},
+};
+
+static void __init omap_i2c_mux_pins(int bus)
{
- /* TODO: Muxing for OMAP3 */
- switch (bus_id) {
- case 1:
- if (cpu_class_is_omap1()) {
- omap_cfg_reg(I2C_SCL);
- omap_cfg_reg(I2C_SDA);
- } else if (cpu_is_omap24xx()) {
- omap_cfg_reg(M19_24XX_I2C1_SCL);
- omap_cfg_reg(L15_24XX_I2C1_SDA);
- }
- break;
- case 2:
- if (cpu_is_omap24xx()) {
- omap_cfg_reg(J15_24XX_I2C2_SCL);
- omap_cfg_reg(H19_24XX_I2C2_SDA);
- }
- break;
+ int scl, sda;
+
+ if (cpu_class_is_omap1()) {
+ scl = omap1_pins[bus][0];
+ sda = omap1_pins[bus][1];
+ } else if (cpu_is_omap24xx()) {
+ scl = omap24xx_pins[bus][0];
+ sda = omap24xx_pins[bus][1];
+ } else if (cpu_is_omap34xx()) {
+ scl = omap34xx_pins[bus][0];
+ sda = omap34xx_pins[bus][1];
+ } else {
+ return;
}
+
+ omap_cfg_reg(sda);
+ omap_cfg_reg(scl);
}
int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
@@ -143,6 +156,6 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
res[1].start = irq;
}
- omap_i2c_mux_pins(bus_id);
+ omap_i2c_mux_pins(bus_id - 1);
return platform_device_register(pdev);
}
--
1.5.5.3
--
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: OSK5912 Camera Port
Maybe this link can be useful. Haven't tried it yet, but I plan to do so. http://oskfordummies.hp.infoseek.co.jp/howto/usb_camera.html Regards, Pablo Recabal 2008/6/9 Mikhail [EMAIL PROTECTED]: Did anyone work with osk5912 camera port ? If you did, please, can you explain how you did that ? -- 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: 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 http://vger.kernel.org/majordomo-info.html
RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge
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? DSP has to access all the external memory buffers through DSP MMU. Best Regards Vijay -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 Viraj, 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 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
[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
[PATCH 0/3] Updates for tea5761 (take #2)
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 | 564 - 4 files changed, 330 insertions(+), 292 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 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 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 | 564 +--
3 files changed, 279 insertions(+), 288 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..a6ea185 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 3/3] radio-tea5761: Update driver
On Mon, Jun 09, 2008 at 04:05:43PM -0400, Eduardo Valentin wrote:
+static void tea5761_set_audout_mode(struct tea5761_device *tea, int audmode)
{
- struct tea5761_regs *r = tea-regs;
-
- if (!(r-tnctrl TEA5761_TNCTRL_PUPD0)) {
- r-tnctrl = ~(TEA5761_TNCTRL_AFM | TEA5761_TNCTRL_MU |
-TEA5761_TNCTRL_HLSI);
- r-testreg |= TEA5761_TESTREG_TRIGFR;
- r-tnctrl |= TEA5761_TNCTRL_PUPD0;
- return tea5761_write_regs(tea);
+ struct dvb_frontend *fe = tea-fe;
+ struct dvb_tuner_ops *fe_tuner_ops = fe-ops.tuner_ops;
+ struct analog_parameters params = {
+ .mode = V4L2_TUNER_RADIO,
+ .frequency = tea-freq,
+ .audmode= audmode,
+ };
+
+ if (NULL == fe_tuner_ops-set_analog_params) {
+ dev_warn(tea-dev,
+ Tuner frontend module has no way to set frequency\n);
+ return;
}
+ if (!fe_tuner_ops-set_analog_params(fe, params))
+ tea-audmode = audmode;
instead of both ifs, how about:
if (fe_tuner_ops-set_analog_params) {
tea-audmode =
fe_tuner_ops-set_analog_params(fe, params) ?
audmode : 0;
}
}
+static void tea5761_mute(struct tea5761_device *tea, int on)
+{
+ struct dvb_frontend *fe = tea-fe;
+ struct dvb_tuner_ops *fe_tuner_ops = fe-ops.tuner_ops;
+ struct analog_parameters params = {
+ .mode = on ? T_STANDBY : V4L2_TUNER_RADIO,
+ .frequency = tea-freq,
+ .audmode= tea-audmode,
+ };
+
+ if (NULL == fe_tuner_ops-set_analog_params) {
+ dev_warn(tea-dev,
+ Tuner frontend module has no way to set frequency\n);
+ return;
}
+ if (!fe_tuner_ops-set_analog_params(fe, params))
+ tea-mute = on;
samething here.
}
static int tea5761_i2c_driver_probe(struct i2c_client *client,
@@ -422,12 +407,24 @@ static int tea5761_i2c_driver_probe(struct i2c_client
*client,
mutex_init(tea-mutex);
- tea-i2c_dev = client;
+ /* Tuner attach */
+ if (!dvb_attach(tea5761_attach, tea-fe, client-adapter,
+ client-addr)) {
+ dev_err(client-dev, Could not attach tuner\n);
+ err = -ENODEV;
+ goto exit;
+ }
+
+ /* initialize and power off the chip */
+ tea5761_power_up(tea);
+ tea5761_set_audout_mode(tea, V4L2_TUNER_MODE_STEREO);
+ tea5761_mute(tea, 0);
+ tea5761_power_down(tea);
/* V4L initialization */
video_dev = video_device_alloc();
if (video_dev == NULL) {
if (!video_dev)
- dev_err(client-dev, couldn't allocate memory\n);
+ dev_err(client-dev, Could not allocate memory\n);
err = -ENOMEM;
goto exit;
}
@@ -436,25 +433,15 @@ static int tea5761_i2c_driver_probe(struct i2c_client
*client,
*video_dev = tea5761_video_device;
video_dev-dev = client-dev;
i2c_set_clientdata(client, video_dev);
-
- /* initialize and power off the chip */
- tea5761_read_regs(tea);
- tea5761_set_audout_mode(tea, V4L2_TUNER_MODE_STEREO);
- tea5761_mute(tea, 0);
- tea5761_power_down(tea);
-
- tea5761.video_dev = video_dev;
- tea5761.i2c_dev = client;
+ tea-video_dev = video_dev;
+ tea-dev = client-dev;
err = video_register_device(video_dev, VFL_TYPE_RADIO, radio_nr);
if (err) {
- dev_err(client-dev, couldn't register video device\n);
+ dev_err(client-dev, Could not register video device\n);
goto err_video_alloc;
}
- dev_info(client-dev, tea5761 (version %d) detected\n,
- (tea-regs.manid 12) 0xf);
-
return 0;
err_video_alloc:
@@ -492,7 +479,8 @@ static int __init tea5761_init(void)
{
int res;
- if ((res = i2c_add_driver(tea5761_driver))) {
+ res = i2c_add_driver(tea5761_driver);
+ if (res) {
printk(KERN_ERR DRIVER_NAME : driver registration failed\n);
return res;
not needed, return i2c_add_driver(tea5761_driver); is enough as i2c
subsystem already prints out error messages in case of failed probe.
}
--
Best Regards,
Felipe Balbi
[EMAIL PROTECTED]
http://blog.felipebalbi.com
--
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] PRCM: OMAP3: Fix to wrongly modified omap2_clk_wait_ready
On Mon, 9 Jun 2008, Jouni Hogander wrote: omap2_clk_wait_ready was wrongly modified to check registers contents. This fix changes it back to check addresses. Signed-off-by: Jouni Hogander [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] - Paul -- 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,
Sorry for the delay on looking at this, it's looking pretty good in
general. Few more mostly cosmetic comments below.
* Tero Kristo [EMAIL PROTECTED] [080603 01:53]:
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.
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm-debug.c | 132
arch/arm/mach-omap2/pm.h |8 --
arch/arm/mach-omap2/pm24xx.c | 53 ++-
arch/arm/mach-omap2/pm34xx.c |5 ++
arch/arm/mach-omap2/serial.c | 118
include/asm-arm/arch-omap/common.h |3 +
6 files changed, 162 insertions(+), 157 deletions(-)
snip
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b0fa582..65571f9 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,8 +23,47 @@
#include asm/arch/common.h
#include asm/arch/board.h
+#include prm.h
+#include pm.h
+
+#define SERIAL_AWAKE_TIME 5
+
static struct clk *uart_ick[OMAP_MAX_NR_PORTS];
static struct clk *uart_fck[OMAP_MAX_NR_PORTS];
+static s64 omap_serial_next_sleep;
+
+static const u32 omap2_uart_wk_st[OMAP_MAX_NR_PORTS] = {
+ PM_WKST1, PM_WKST1, OMAP24XX_PM_WKST2
+};
+static const u32 omap2_uart_wk_en[OMAP_MAX_NR_PORTS] = {
+ PM_WKEN1, PM_WKEN1, OMAP24XX_PM_WKEN2
+};
+const u32 omap2_uart_wk_bit[OMAP_MAX_NR_PORTS] = {
+ OMAP24XX_ST_UART1, OMAP24XX_ST_UART2, OMAP24XX_ST_UART3
+};
+
+#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.
+/* 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.
static struct plat_serial8250_port serial_platform_data[] = {
{
@@ -83,6 +122,15 @@ static inline void __init omap_serial_reset(struct
plat_serial8250_port *p)
serial_write_reg(p, UART_OMAP_SYSC, (0x02 3) | (1 2) | (1 0));
}
+static void omap_serial_kick(void)
+{
+ struct timespec t;
+
+ getnstimeofday(t);
+ omap_serial_next_sleep = timespec_to_ns(t) +
+ (s64)SERIAL_AWAKE_TIME * (s64)10;
+}
+
void omap_serial_enable_clocks(int enable)
{
int i;
@@ -99,6 +147,71 @@ void omap_serial_enable_clocks(int enable)
}
}
+void omap_serial_fclk_mask(u32 *f1, u32 *f2)
+{
+ if (uart_ick[0])
+ *f1 = ~omap_uart_fclk_mask[0];
+ if (uart_ick[1])
+ *f1 = ~omap_uart_fclk_mask[1];
+ if (uart_ick[2])
+ *f2 = ~omap_uart_fclk_mask[2];
+}
+
+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?
+ 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.
+int omap_serial_can_sleep(void)
+{
+ s64 cnt;
+ int i;
+ struct timespec t;
+
+ struct plat_serial8250_port *p = serial_platform_data;
+
+ getnstimeofday(t);
+ cnt = timespec_to_ns(t);
+
+ for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+ if (!uart_ick[i])
+ continue;
+ /* Check if we have data in the transmit buffer */
+ if ((serial_read_reg(p + i,
Re: [PATCH 2/2] ARM: OMAP: Add OMAP34xx pin muxing into I2C bus registration helper
On Mon, 9 Jun 2008 17:46:41 +0300
Jarkko Nikula [EMAIL PROTECTED] wrote:
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
---
arch/arm/plat-omap/i2c.c | 51 +++
+- 1 files changed, 32 insertions(+), 19 deletions(-)
-static void __init omap_i2c_mux_pins(int bus_id)
+static const int omap1_pins[][2] = {
+ { I2C_SCL, I2C_SDA },
+};
+static const int omap24xx_pins[][2] = {
+ { M19_24XX_I2C1_SCL, L15_24XX_I2C1_SDA },
+ { J15_24XX_I2C2_SCL, H19_24XX_I2C2_SDA },
+};
+static const int omap34xx_pins[][2] = {
+ { K21_34XX_I2C1_SCL, J21_34XX_I2C1_SDA},
+ { AF15_34XX_I2C2_SCL, AE15_34XX_I2C2_SDA},
+ { AF14_34XX_I2C3_SCL, AG14_34XX_I2C3_SDA},
+ { AD26_34XX_I2C4_SCL, AE26_34XX_I2C4_SDA},
+};
+
NAK to myself. Avoiding few #ifdefs is not an excuse for spending some
bytes here and also it doesn't look good to add muxing support for bus
4 where the module itself doesn't support it (yet).
Lazy me :-)
Jarkko
--
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 2/2] ARM: OMAP: Add OMAP34xx pin multiplexing into I2C bus registration helper
- Simplify function omap_i2c_mux_pins
- Add OMAP34xx pin multiplexing for busses 1 - 3
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
---
arch/arm/plat-omap/i2c.c | 55 ++
1 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 7990ab1..eddc24e 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -80,26 +80,43 @@ static struct platform_device omap_i2c_devices[] = {
#endif
};
-static void __init omap_i2c_mux_pins(int bus_id)
+#if defined(CONFIG_ARCH_OMAP24XX)
+static const int omap24xx_pins[][2] = {
+ { M19_24XX_I2C1_SCL, L15_24XX_I2C1_SDA },
+ { J15_24XX_I2C2_SCL, H19_24XX_I2C2_SDA },
+};
+#else
+static const int omap24xx_pins[][2] = {};
+#endif
+#if defined(CONFIG_ARCH_OMAP34XX)
+static const int omap34xx_pins[][2] = {
+ { K21_34XX_I2C1_SCL, J21_34XX_I2C1_SDA},
+ { AF15_34XX_I2C2_SCL, AE15_34XX_I2C2_SDA},
+ { AF14_34XX_I2C3_SCL, AG14_34XX_I2C3_SDA},
+};
+#else
+static const int omap34xx_pins[][2] = {};
+#endif
+
+static void __init omap_i2c_mux_pins(int bus)
{
- /* TODO: Muxing for OMAP3 */
- switch (bus_id) {
- case 1:
- if (cpu_class_is_omap1()) {
- omap_cfg_reg(I2C_SCL);
- omap_cfg_reg(I2C_SDA);
- } else if (cpu_is_omap24xx()) {
- omap_cfg_reg(M19_24XX_I2C1_SCL);
- omap_cfg_reg(L15_24XX_I2C1_SDA);
- }
- break;
- case 2:
- if (cpu_is_omap24xx()) {
- omap_cfg_reg(J15_24XX_I2C2_SCL);
- omap_cfg_reg(H19_24XX_I2C2_SDA);
- }
- break;
+ int scl, sda;
+
+ if (cpu_class_is_omap1()) {
+ scl = I2C_SCL;
+ sda = I2C_SDA;
+ } else if (cpu_is_omap24xx()) {
+ scl = omap24xx_pins[bus][0];
+ sda = omap24xx_pins[bus][1];
+ } else if (cpu_is_omap34xx()) {
+ scl = omap34xx_pins[bus][0];
+ sda = omap34xx_pins[bus][1];
+ } else {
+ return;
}
+
+ omap_cfg_reg(sda);
+ omap_cfg_reg(scl);
}
int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
@@ -143,6 +160,6 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
res[1].start = irq;
}
- omap_i2c_mux_pins(bus_id);
+ omap_i2c_mux_pins(bus_id - 1);
return platform_device_register(pdev);
}
--
1.5.5.3
--
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
