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
[PATCH 1/2] ARM: OMAP2: Add pin multiplexing configuration for OMAP34xx I2C pins
Signed-off-by: Jarkko Nikula <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/mux.c | 18 ++
include/asm-arm/arch-omap/mux.h |9 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 6919d52..5a68fb3 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -226,6 +226,24 @@ static struct pin_config __initdata_or_module
omap34xx_pins[] = {
* mux-mode | [active-mode | off-mode]
*/
+/* 34xx I2C */
+MUX_CFG_34XX("K21_34XX_I2C1_SCL", 0x1ba,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("J21_34XX_I2C1_SDA", 0x1bc,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AF15_34XX_I2C2_SCL", 0x1be,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE15_34XX_I2C2_SDA", 0x1c0,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AF14_34XX_I2C3_SCL", 0x1c2,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AG14_34XX_I2C3_SDA", 0x1c4,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AD26_34XX_I2C4_SCL", 0xa00,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE26_34XX_I2C4_SDA", 0xa02,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+
/* PHY - HSUSB: 12-pin ULPI PHY: Port 1*/
MUX_CFG_34XX("Y8_3430_USB1HS_PHY_CLK", 0x5da,
OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_OUTPUT)
diff --git a/include/asm-arm/arch-omap/mux.h b/include/asm-arm/arch-omap/mux.h
index ad39b0b..7a51aa0 100644
--- a/include/asm-arm/arch-omap/mux.h
+++ b/include/asm-arm/arch-omap/mux.h
@@ -644,6 +644,15 @@ enum omap24xx_index {
};
enum omap34xx_index {
+ /* 34xx I2C */
+ 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,
/* PHY - HSUSB: 12-pin ULPI PHY: Port 1*/
Y8_3430_USB1HS_PHY_CLK,
--
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
Accelerating video playback on OMAP2 & OMAP3
I cam currently looking into accelerating video playback on the OMAP2420, OMAP2430, OMAP3430 and eventually the OMAP3530 (once we recieve some hardware). >From what I understand, we can use the v4l2 interface to send buffers to the >display hardware, which will do the scaling & YUV->RGB conversion in hardware. However, I was wondering what the options are for doing mpeg decode in hardware too. I believe the DaVinci platforms ship with GStreamer elements which will do MPEG decoding on the DSP and provide the output to a seperate GStreamer video sync. Are there any gstreamer elements avaliable to do the same on the OMAP2 & OMAP3 processors? If not, how can we accelerate the MPEG decode? We eventually want to be able to switch to rendering video frames into off-screen buffers. We hope this will allow us to upload them as a textures, which our compositing system can use for window animations. Once the animation has finished and windows are static, we'd then switch back to using the v4l2 overlay. Help & advice is greatly appreciated! :-) Cheers, Tom PS: This is a repost ater the original was sent to the old mailing list. Sorry if you get it twice. -- 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
#include
#include
+#include
+
+#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)
+ fe_tuner_ops->init(fe);
+ tea->power = 1;
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, ¶ms))
> + 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, ¶ms) ?
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, ¶ms))
> + 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 3/3] radio-tea5761: Update driver
Hi Balbi,
On Mon, Jun 9, 2008 at 7:40 PM, Felipe Balbi <[EMAIL PROTECTED]> wrote:
> 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, ¶ms))
>> + 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, ¶ms) ?
>audmode : 0;
>}
>> }
I don't know. I personally do not like "silent fail" style. The way you
proposed it will say nothing if set_anolog_params is not set. And that
is a very important part of this code.
>
>> +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, ¶ms))
>> + tea->mute = on;
>
> samething here.
same 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 fa
Re: [PATCH 3/3] radio-tea5761: Update driver
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. -- 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 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(-)
>
> 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
> #include
>
> +#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])
> +
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
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
compiling X11 fails at makekeys
Dear All, I am trying to compile X for omap5912-osk. i am following the steps given in: http://oskfordummies.hp.infoseek.co.jp/howto/x-window.html all the xlib- libraries are compiling till i reach the X11 library. i am struck at this point for a month now. some one please help me out. am attaching the build log (error at the last line): == Building X11 == autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force nls/C/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/C/Makefile.am:1: (probably a GNU make extension) nls/armscii-8/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/armscii-8/Makefile.am:1: (probably a GNU make extension) nls/en_US.UTF-8/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/en_US.UTF-8/Makefile.am:1: (probably a GNU make extension) nls/georgian-academy/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/georgian-academy/Makefile.am:1: (probably a GNU make extension) nls/georgian-ps/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/georgian-ps/Makefile.am:1: (probably a GNU make extension) nls/ibm-cp1133/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ibm-cp1133/Makefile.am:1: (probably a GNU make extension) nls/iscii-dev/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iscii-dev/Makefile.am:1: (probably a GNU make extension) nls/isiri-3342/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/isiri-3342/Makefile.am:1: (probably a GNU make extension) nls/iso8859-1/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-1/Makefile.am:1: (probably a GNU make extension) nls/iso8859-10/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-10/Makefile.am:1: (probably a GNU make extension) nls/iso8859-11/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-11/Makefile.am:1: (probably a GNU make extension) nls/iso8859-13/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-13/Makefile.am:1: (probably a GNU make extension) nls/iso8859-14/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-14/Makefile.am:1: (probably a GNU make extension) nls/iso8859-15/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-15/Makefile.am:1: (probably a GNU make extension) nls/iso8859-2/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-2/Makefile.am:1: (probably a GNU make extension) nls/iso8859-3/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-3/Makefile.am:1: (probably a GNU make extension) nls/iso8859-4/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-4/Makefile.am:1: (probably a GNU make extension) nls/iso8859-5/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-5/Makefile.am:1: (probably a GNU make extension) nls/iso8859-6/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-6/Makefile.am:1: (probably a GNU make extension) nls/iso8859-7/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-7/Makefile.am:1: (probably a GNU make extension) nls/iso8859-8/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-8/Makefile.am:1: (probably a GNU make extension) nls/iso8859-9/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-9/Makefile.am:1: (probably a GNU make extension) nls/iso8859-9e/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/iso8859-9e/Makefile.am:1: (probably a GNU make extension) nls/ja.JIS/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ja.JIS/Makefile.am:1: (probably a GNU make extension) nls/ja.S90/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ja.S90/Makefile.am:1: (probably a GNU make extension) nls/ja.SJIS/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ja.SJIS/Makefile.am:1: (probably a GNU make extension) nls/ja.U90/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ja.U90/Makefile.am:1: (probably a GNU make extension) nls/ja/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ja/Makefile.am:1: (probably a GNU make extension) nls/ja_JP.UTF-8/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ja_JP.UTF-8/Makefile.am:1: (probably a GNU make extension) nls/ko/Makefile.am:1: shell basename `pwd`: non-POSIX variable name nls/ko/Makefile.am:1: (probably a GNU make extension) nls/ko_KR.UTF-8/Makefile.am:1: s
