Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
...snip... Fair point. It will be harder to maintain and won't be consistent. Am not sure what you mean because secure API as such isn't a problem. If you mean one standard interface for all the ARM SOC's then that's something won't be easy to handled because it is tied up the security architecture which can vary across SoCs. The latter. This is exactly the kind of pain I forsaw with this security shite, and when I heard about it I was utterly dismayed at ARM Ltd for coming up with such a brain-dead lack of design here. You're having to struggle with the results of that by having lots of SoC specific hooks all around the place to fiddle with this that and the other. Your need to have something called from the early assembly code is just yet more of that disease caused by ARM Ltd's lack of forsight on this matter. I have no solution for you on this I managed use some secure macro kind of code but as you said it will be really hard to maintain. So we are stuck with this issue then. So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... Cheers, Joe Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume
and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME.
This patch removes the omap_i2c_unidle/idle functions and folds them
into the runtime callbacks.
This fixes the below warn when CONFIG_PM_RUNTIME is not defined
CC arch/arm/mach-omap2/board-ti8168evm.o
drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not
used
drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used
CC net/ipv4/ip_forward.o
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Rebased to Kevin's tree i2c misc branch
Tested on omsp4sdp and omap3sdp
drivers/i2c/busses/i2c-omap.c | 75 +---
1 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..914bed8 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -269,47 +269,6 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
-* Don't write to this register if the IE state is 0 as it can
-* cause deadlock.
-*/
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-}
-
-static void omap_i2c_idle(struct omap_i2c_dev *dev)
-{
- u16 iv;
-
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
- omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
- else
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
-
- if (dev-rev OMAP_I2C_OMAP1_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
- } else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
-
- /* Flush posted write */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
-}
-
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
@@ -1163,8 +1122,22 @@ static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+ u16 iv;
+
+ _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
+ if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+
+ if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
+ iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
+ } else {
+ omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
- omap_i2c_idle(_dev);
+ /* Flush posted write */
+ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
+ }
return 0;
}
@@ -1174,7 +1147,23 @@ static int omap_i2c_runtime_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
- omap_i2c_unidle(_dev);
+ if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
+ omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
+
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (_dev-iestate)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Tue, Jan 17, 2012 at 07:32:47AM +, AnilKumar, Chimata wrote: Recalling the patch, provide the comments if there are any if not please include this patch to v3.3 kernel. There's no way this is going to make it into the 3.3 kernel at this point, we're almost at the end of the merge window. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Santosh, Russel, On Monday 16 January 2012 06:52 PM, Shilimkar, Santosh wrote: On Mon, Jan 16, 2012 at 2:13 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote: This code will be in assembly and that's what I have been using. Not having stack shoudn't be a blocker and can be work-around in this code. And this API has to be anyway called before MMU is enabled. What about SMC on OMAP potentially corrupting most of the integer registers? What if it corrupts an integer register which we depend upon? You don't have a stack here to save those registers. We'd need at least one additional register to save the old 'lr' value. That's right. What about other secure monitors? Some implementations require you to give parameters via memory. How do you obtain that memory that early on in the kernel boot (you haven't parsed anything here.) Not only that but you're asking to make the kernel boot a _lot_ more fragile, when people start stuffing all kinds of utter shite into this hook - and then we're burdened again with the old 'my kernel won't boot and it remains silent, well your debug code is utter shite get rid of it' crap that we used to have in the early 2000s. I really don't want to go anywhere near that situation. Fair point. It will be harder to maintain and won't be consistent. Am not sure what you mean because secure API as such isn't a problem. If you mean one standard interface for all the ARM SOC's then that's something won't be easy to handled because it is tied up the security architecture which can vary across SoCs. The latter. This is exactly the kind of pain I forsaw with this security shite, and when I heard about it I was utterly dismayed at ARM Ltd for coming up with such a brain-dead lack of design here. You're having to struggle with the results of that by having lots of SoC specific hooks all around the place to fiddle with this that and the other. Your need to have something called from the early assembly code is just yet more of that disease caused by ARM Ltd's lack of forsight on this matter. I have no solution for you on this I managed use some secure macro kind of code but as you said it will be really hard to maintain. So we are stuck with this issue then. Can't we delay the L2 initialization a bit and do it when we have a stack, like we do in OMAP4 (early_initcall)? Am I missing something? br, Aneesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR
Hi Olof, On Saturday 14 January 2012 01:06 AM, Aneesh V wrote: Hi Olof, snip We wish to drop the DDR3 support because we have concluded that our platforms with DDR3 memories will not scale DDR frequency due to limitations in DDR3 protocol(operating frequency can vary only in a small range). So, is it ok to persist with my bindings for LPDDR2 (fixing the comments already given by you) and drop the DDR3 part from it? Ping! Forgive my impatience, but I would like to close on this at the earliest to continue my work on the driver. thanks, Aneesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote: So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... It could but the Linux decompressor needs to be aware and either flush the L2 (more difficult as it doesn't have all the device information) or set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). The latter may still not work if there are stale L2 cache lines left by U-Boot (and that's always possible unless U-Boot also uses outer non-cacheable memory attributes). But I would agree with Aneesh - can we not enabled the L2 at a later point? -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Hi Catalin, On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote: So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... It could but the Linux decompressor needs to be aware and either flush the L2 (more difficult as it doesn't have all the device information) or Cortex-A8 is aware of L2$ and can flush it, isn't it? set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). If the above is right, this is not needed right? The latter may still not work if there are stale L2 cache lines left by U-Boot (and that's always possible unless U-Boot also uses outer non-cacheable memory attributes). U-Boot flushes the caches before disabling it. On top of it, it does an invalidate after the disabling the caches to cover some corner case. So, it's guaranteed that there won't be any stale entries in L2 after U-Boot. So, we could as well leave L2$ enabled (and invalidated) and caches disabled globally after U-Boot. But I thought enabling L2$ again in kernel is the cleaner solution. br, Aneesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V ane...@ti.com wrote: Hi Catalin, On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote: So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... It could but the Linux decompressor needs to be aware and either flush the L2 (more difficult as it doesn't have all the device information) or Cortex-A8 is aware of L2$ and can flush it, isn't it? set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). If the above is right, this is not needed right? Well the L2 can be configured as inner or outer, so above alone won't work. Boot-loader disabling L2 cache ( all caches) is still right thing and that's what kernel expect. Since the early kernel code can't be patches for A8, may be delaying L2 enabled would work. But then on A15, we are back to square one since there is no control to turn ON/OFF l2 cache. On A15 infact there are other CP15 registers which needs to be set before MMU is enabled to have best configuration. So the need of this early hook is pretty much there. May be separate CPU setup code for such cases is a possible way to go. Basically the problem needs to be sorted out, because I already see this is needed for A15 as well Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAPDSS: HDMI PHY burnout fix
The main patch in this set is the last one, which implements a fix for the HW bug on OMAP4 which causes physical damage to the board if the HDMI cable is not connected but HDMI output is enabled. The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix can be implemented. Note that I haven't gotten a confirmation that using LDO_ON for the HDMI PHY power fixes the issue. So whether the fix works or not is unclear. Tomi Tomi Valkeinen (6): OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD OMAPDSS: remove wrong HDMI HPD muxing OMAP: 4430SDP/Panda: setup HDMI GPIO muxes OMAP: 4430SDP/Panda: add HDMI HPD gpio OMAPDSS: HDMI: PHY burnout fix arch/arm/mach-omap2/board-4430sdp.c | 18 ++-- arch/arm/mach-omap2/board-omap4panda.c| 18 ++-- arch/arm/mach-omap2/display.c |4 -- drivers/video/omap2/dss/hdmi.c|3 + drivers/video/omap2/dss/ti_hdmi.h |4 ++ drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++-- include/video/omapdss.h |5 ++ 7 files changed, 104 insertions(+), 16 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
Instead of freeing the GPIOs individually, use gpio_free_array().
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
arch/arm/mach-omap2/board-omap4panda.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4af874a..d7017f2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -614,8 +614,7 @@ static int sdp4430_panel_enable_hdmi(struct omap_dss_device
*dssdev)
static void sdp4430_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(sdp4430_hdmi_gpios, ARRAY_SIZE(sdp4430_hdmi_gpios));
}
static struct nokia_dsi_panel_data dsi1_panel = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 00103e3..b9f90ba 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -497,8 +497,7 @@ static int omap4_panda_panel_enable_hdmi(struct
omap_dss_device *dssdev)
static void omap4_panda_panel_disable_hdmi(struct omap_dss_device *dssdev)
{
- gpio_free(HDMI_GPIO_LS_OE);
- gpio_free(HDMI_GPIO_HPD);
+ gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
static struct omap_dss_device omap4_panda_hdmi_device = {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|4 ++--
arch/arm/mach-omap2/board-omap4panda.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index d7017f2..ae0c09f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -52,7 +52,7 @@
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -596,7 +596,7 @@ static void __init omap_sfh7741prox_init(void)
}
static struct gpio sdp4430_hdmi_gpios[] = {
- { HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b9f90ba..133b5a7 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -51,7 +51,7 @@
#define GPIO_HUB_NRESET62
#define GPIO_WIFI_PMENA43
#define GPIO_WIFI_IRQ 53
-#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
+#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
/* wl127x BT, FM, GPS connectivity chip */
@@ -479,7 +479,7 @@ int __init omap4_panda_dvi_init(void)
}
static struct gpio panda_hdmi_gpios[] = {
- { HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
+ { HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] OMAPDSS: remove wrong HDMI HPD muxing
hdmi_hpd pin is muxed to INPUT and PULLUP, but the pin is not currently used, and in the future when it is used, the pin is used as a GPIO and is board specific, not an OMAP4 wide thing. So remove the muxing for now. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/display.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index ffd9bd9..d6e65e2 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -102,12 +102,8 @@ static void omap4_hdmi_mux_pads(enum omap_hdmi_flags flags) u32 reg; u16 control_i2c_1; - /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */ - omap_mux_init_signal(hdmi_hpd, - OMAP_PIN_INPUT_PULLUP); omap_mux_init_signal(hdmi_cec, OMAP_PIN_INPUT_PULLUP); - /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */ omap_mux_init_signal(hdmi_ddc_scl, OMAP_PIN_INPUT_PULLUP); omap_mux_init_signal(hdmi_ddc_sda, -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured. This patch configures them as output pins. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/board-4430sdp.c|3 +++ arch/arm/mach-omap2/board-omap4panda.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index ae0c09f..5dcc8df 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -833,6 +833,9 @@ static void omap_4430sdp_display_init(void) omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP); else omap_hdmi_init(0); + + omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT); + omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT); } #ifdef CONFIG_OMAP_MUX diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 133b5a7..06a7075 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -549,6 +549,9 @@ void omap4_panda_display_init(void) omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP); else omap_hdmi_init(0); + + omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT); + omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT); } static void __init omap4_panda_init(void) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] OMAP: 4430SDP/Panda: add HDMI HPD gpio
Both Panda and 4430SDP use GPIO 64 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 5dcc8df..a776c26 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -54,6 +54,7 @@
#define OMAP4_SFH7741_ENABLE_GPIO 188
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -598,6 +599,7 @@ static void __init omap_sfh7741prox_init(void)
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -836,6 +838,7 @@ static void omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 06a7075..b22a288 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -53,6 +53,7 @@
#define GPIO_WIFI_IRQ 53
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -481,6 +482,7 @@ int __init omap4_panda_dvi_init(void)
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -552,6 +554,7 @@ void omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
static void __init omap4_panda_init(void)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] i2c-omap: use usleep_range(), get rid out of jiffies
Use usleep_range() with return value to implement time-bounded
wait-for hardware loop where delay is applicable; use ktime
instead of jiffies for a busy-wait loop.
Signed-off-by: Dmitry Antipov dmitry.anti...@linaro.org
---
drivers/i2c/busses/i2c-omap.c | 23 +++
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fa23faa..401a622 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,8 +49,8 @@
#define OMAP_I2C_REV_ON_3430 0x3C
#define OMAP_I2C_REV_ON_3530_4430 0x40
-/* timeout waiting for the controller to respond */
-#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
+/* timeout waiting for the controller to respond, in usecs */
+#define OMAP_I2C_TIMEOUT USEC_PER_SEC
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
enum {
@@ -333,16 +333,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, SYSC_SOFTRESET_MASK);
/* For some reason we need to set the EN bit before the
* reset done bit gets set. */
- timeout = jiffies + OMAP_I2C_TIMEOUT;
+ timeout = 0;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
while (!(omap_i2c_read_reg(dev, OMAP_I2C_SYSS_REG)
SYSS_RESETDONE_MASK)) {
- if (time_after(jiffies, timeout)) {
+ if (timeout OMAP_I2C_TIMEOUT) {
dev_warn(dev-dev, timeout waiting
for controller reset\n);
return -ETIMEDOUT;
}
- msleep(1);
+ timeout += usleep_range(1000, 2000);
}
/* SYSC register is cleared by the reset; rewrite it */
@@ -498,15 +498,14 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
*/
static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
{
- unsigned long timeout;
+ unsigned long timeout = 0;
- timeout = jiffies + OMAP_I2C_TIMEOUT;
while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) OMAP_I2C_STAT_BB) {
- if (time_after(jiffies, timeout)) {
+ if (timeout OMAP_I2C_TIMEOUT) {
dev_warn(dev-dev, timeout waiting for bus ready\n);
return -ETIMEDOUT;
}
- msleep(1);
+ timeout += usleep_range(1000, 2000);
}
return 0;
@@ -564,13 +563,13 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* Don't write stt and stp together on some hardware.
*/
if (dev-b_hw stop) {
- unsigned long delay = jiffies + OMAP_I2C_TIMEOUT;
+ ktime_t start = ktime_get();
u16 con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
while (con OMAP_I2C_CON_STT) {
con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
/* Let the user know if i2c is in a bad state */
- if (time_after(jiffies, delay)) {
+ if (ktime_us_delta(ktime_get(), start)
OMAP_I2C_TIMEOUT) {
dev_err(dev-dev, controller timed out
waiting for start condition to finish\n);
return -ETIMEDOUT;
@@ -588,7 +587,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* into arbitration and we're currently unable to recover from it.
*/
r = wait_for_completion_timeout(dev-cmd_complete,
- OMAP_I2C_TIMEOUT);
+ usecs_to_jiffies(OMAP_I2C_TIMEOUT));
dev-buf_len = 0;
if (r 0)
return r;
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is powered on when the cable is not connected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
ticking and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |5 ++
arch/arm/mach-omap2/board-omap4panda.c|5 ++
drivers/video/omap2/dss/hdmi.c|3 +
drivers/video/omap2/dss/ti_hdmi.h |4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 68 +++--
include/video/omapdss.h |5 ++
6 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a776c26..d4fe511 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -732,6 +732,10 @@ static void sdp4430_lcd_init(void)
pr_err(%s: Could not get lcd2_reset_gpio\n, __func__);
}
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device sdp4430_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
@@ -739,6 +743,7 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.platform_enable = sdp4430_panel_enable_hdmi,
.platform_disable = sdp4430_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = sdp4430_hdmi_data,
};
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b22a288..c28ef20 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -502,6 +502,10 @@ static void omap4_panda_panel_disable_hdmi(struct
omap_dss_device *dssdev)
gpio_free_array(panda_hdmi_gpios, ARRAY_SIZE(panda_hdmi_gpios));
}
+static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
+ .hpd_gpio = HDMI_GPIO_HPD,
+};
+
static struct omap_dss_device omap4_panda_hdmi_device = {
.name = hdmi,
.driver_name = hdmi_panel,
@@ -509,6 +513,7 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.platform_enable = omap4_panda_panel_enable_hdmi,
.platform_disable = omap4_panda_panel_disable_hdmi,
.channel = OMAP_DSS_CHANNEL_DIGIT,
+ .data = omap4_panda_hdmi_data,
};
static struct omap_dss_device *omap4_panda_dss_devices[] = {
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 92a6679..3b76a20 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -469,6 +469,7 @@ bool omapdss_hdmi_detect(void)
int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev)
{
+ struct omap_dss_hdmi_data *priv = dssdev-data;
int r = 0;
DSSDBG(ENTER hdmi_display_enable\n);
@@ -481,6 +482,8 @@ int omapdss_hdmi_display_enable(struct omap_dss_device
*dssdev)
goto err0;
}
+ hdmi.ip_data.hpd_gpio = priv-hpd_gpio;
+
r = omap_dss_start_device(dssdev);
if (r) {
DSSERR(failed to start device\n);
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 26ec6d1..cb6f0f2 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -122,6 +122,10 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+
+ /* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
+ int hpd_gpio;
+ bool phy_tx_enabled;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index a229ae7..34e58dd 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/string.h
#include linux/seq_file.h
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V ane...@ti.com wrote: Hi Catalin, On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote: So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... It could but the Linux decompressor needs to be aware and either flush the L2 (more difficult as it doesn't have all the device information) or Cortex-A8 is aware of L2$ and can flush it, isn't it? set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). If the above is right, this is not needed right? Well the L2 can be configured as inner or outer, so above alone won't work. Boot-loader disabling L2 cache ( all caches) is still right thing and that's what kernel expect. Since the early kernel code can't be patches for A8, may be delaying L2 enabled would work. Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this case, I would argue to just leave it enabled since as long as the MMU is off it won't be accessed. Why does U-Boot need to disable the L2 (I suspect via some auxiliary control register)? But then on A15, we are back to square one since there is no control to turn ON/OFF l2 cache. Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit as is the L1 cache. It does not need to be disabled independently. On A15 infact there are other CP15 registers which needs to be set before MMU is enabled to have best configuration. Yes, there are, and my view is that it is up to the platform firmware to set things right. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 12:27:25PM +, Aneesh V wrote: Hi Catalin, On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote: So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... It could but the Linux decompressor needs to be aware and either flush the L2 (more difficult as it doesn't have all the device information) or Cortex-A8 is aware of L2$ and can flush it, isn't it? As I said to Santosh, I only had the outer cache in mind (e.g. PL310). There is no extra configuration needed in the kernel decompressor in this case. set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). If the above is right, this is not needed right? Correct, since L2 is inner cache. The latter may still not work if there are stale L2 cache lines left by U-Boot (and that's always possible unless U-Boot also uses outer non-cacheable memory attributes). U-Boot flushes the caches before disabling it. On top of it, it does an invalidate after the disabling the caches to cover some corner case. So, it's guaranteed that there won't be any stale entries in L2 after U-Boot. So, we could as well leave L2$ enabled (and invalidated) and caches disabled globally after U-Boot. Yes. But I thought enabling L2$ again in kernel is the cleaner solution. Why? It gets enabled via SCTLR.M together with L1. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V ane...@ti.com wrote: Hi Catalin, On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: On Tue, Jan 17, 2012 at 08:54:44AM +, Joe Woodward wrote: So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... It could but the Linux decompressor needs to be aware and either flush the L2 (more difficult as it doesn't have all the device information) or Cortex-A8 is aware of L2$ and can flush it, isn't it? set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). If the above is right, this is not needed right? Well the L2 can be configured as inner or outer, so above alone won't work. Boot-loader disabling L2 cache ( all caches) is still right thing and that's what kernel expect. Since the early kernel code can't be patches for A8, may be delaying L2 enabled would work. Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this case, I would argue to just leave it enabled since as long as the MMU is off it won't be accessed. Why does U-Boot need to disable the L2 (I suspect via some auxiliary control register)? But then on A15, we are back to square one since there is no control to turn ON/OFF l2 cache. Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit as is the L1 cache. It does not need to be disabled independently. On A15 infact there are other CP15 registers which needs to be set before MMU is enabled to have best configuration. Yes, there are, and my view is that it is up to the platform firmware to set things right. Firmware is ROM'ed in SOC's and can't be altered without a new silicon spin. Then we get into situations where Errata A will say turn OFF/ON x bit and so on. Most of these bits are secure write-only registers hence ROM code provides few API's to alter these registers in future if needed. BTW, look at the processor setup functions where we are altering these bits in kernel today (Diagnostic, RR policy etc) and they work on ARM SoC's which either don't use trustzone or kernel is in secure mode. Now same thing if needs to be done for SoC's like OMAP where these bits are under secure control, we need to use the ROM secure API's and kernel don't seems to give any flexibility to patch that. I don't understand how __only__ these devices needs to be patches outside the kernel. Firmware point is actually irrelevant for OMAP since it can't be changed once it is ROMed. Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 3:39 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote: Well the L2 can be configured as inner or outer, so above alone won't work. Boot-loader disabling L2 cache ( all caches) is still right thing and that's what kernel expect. Since the early kernel code can't be patches for A8, may be delaying L2 enabled would work. Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. At least on my OMAP3 board it's not. There is L2 AUX control register L2 inner bit that's always cleared here. I know outer cacheablility bits in page table descriptors have effect here, we have tested performace before.. -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Catalin Marinas catalin.mari...@arm.com writes: On Tue, Jan 17, 2012 at 12:27:25PM +, Aneesh V wrote: But I thought enabling L2$ again in kernel is the cleaner solution. Why? It gets enabled via SCTLR.M together with L1. Not if the L2EN bit of the auxiliary control register was cleared, and u-boot messes with this bit. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Tue, Jan 17, 2012 at 10:54:42AM +, Mark Brown wrote: On Tue, Jan 17, 2012 at 07:32:47AM +, AnilKumar, Chimata wrote: Recalling the patch, provide the comments if there are any if not please include this patch to v3.3 kernel. There's no way this is going to make it into the 3.3 kernel at this point, we're almost at the end of the merge window. Agreed, the merge window is for subsystem maintainers, not everyone else. I'll queue this up for review for after 3.3-rc1 is out. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 01:58:18PM +, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote: On A15 infact there are other CP15 registers which needs to be set before MMU is enabled to have best configuration. Yes, there are, and my view is that it is up to the platform firmware to set things right. Firmware is ROM'ed in SOC's and can't be altered without a new silicon spin. Then we get into situations where Errata A will say turn OFF/ON x bit and so on. Most of these bits are secure write-only registers hence ROM code provides few API's to alter these registers in future if needed. BTW, does the firmware make any checks on what bits it allows to be set? Some of them may have security implications (and may not even be documented). Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). BTW, look at the processor setup functions where we are altering these bits in kernel today (Diagnostic, RR policy etc) and they work on ARM SoC's which either don't use trustzone or kernel is in secure mode. What we did for many of them was to check whether the bits are already set to avoid a fault when running in NS mode. Now same thing if needs to be done for SoC's like OMAP where these bits are under secure control, we need to use the ROM secure API's and kernel don't seems to give any flexibility to patch that. I don't understand how __only__ these devices needs to be patches outside the kernel. Because there isn't a standard API to set those registers. And such generic API would not even be easily possible given that you can't tell what auxiliary (or even undocumented) registers a new CPU may have in the future (unless the API is part of the TRM). Firmware point is actually irrelevant for OMAP since it can't be changed once it is ROMed. Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. I don't disagree with this, a solution is needed. In the past I was for having platform hooks in the early kernel code path but in the light of latest kernel developments (FDT, single zImage), I no longer see this as acceptable. If you can't change the boot loader, an alternative could be for the SoC vendor to provide an additional binary that is executed by the boot loader before Linux is started. Such binary could either live in some flash or it could be wrapped around the Linux kernel image before the kernel is stored into flash. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Jan 17, 2012 at 01:58:18PM +, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Tue, Jan 17, 2012 at 12:40:54PM +, Shilimkar, Santosh wrote: On A15 infact there are other CP15 registers which needs to be set before MMU is enabled to have best configuration. Yes, there are, and my view is that it is up to the platform firmware to set things right. Firmware is ROM'ed in SOC's and can't be altered without a new silicon spin. Then we get into situations where Errata A will say turn OFF/ON x bit and so on. Most of these bits are secure write-only registers hence ROM code provides few API's to alter these registers in future if needed. BTW, does the firmware make any checks on what bits it allows to be set? Some of them may have security implications (and may not even be documented). Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). That's true. BTW, look at the processor setup functions where we are altering these bits in kernel today (Diagnostic, RR policy etc) and they work on ARM SoC's which either don't use trustzone or kernel is in secure mode. What we did for many of them was to check whether the bits are already set to avoid a fault when running in NS mode. Yes but then as I mentioned for the secure kernels, they can set from the kernel code. Now same thing if needs to be done for SoC's like OMAP where these bits are under secure control, we need to use the ROM secure API's and kernel don't seems to give any flexibility to patch that. I don't understand how __only__ these devices needs to be patches outside the kernel. Because there isn't a standard API to set those registers. And such generic API would not even be easily possible given that you can't tell what auxiliary (or even undocumented) registers a new CPU may have in the future (unless the API is part of the TRM). Firmware point is actually irrelevant for OMAP since it can't be changed once it is ROMed. Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. I don't disagree with this, a solution is needed. In the past I was for having platform hooks in the early kernel code path but in the light of latest kernel developments (FDT, single zImage), I no longer see this as acceptable. Thanks for acknowledging the problem. Not allowing such hooks for single zImage doesn't seems to be right. Nobody ships kernel build for all socs, and it's usage is really limited to few distro's. But that's different topic. How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. If you can't change the boot loader, an alternative could be for the SoC vendor to provide an additional binary that is executed by the boot loader before Linux is started. Such binary could either live in some flash or it could be wrapped around the Linux kernel image before the kernel is stored into flash. We tried something similar with boot-loaders and failed badly to get that right for all the product trees. So if the single zImage is the blocker I would like to tackle that and have all this important information within kernel code. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas catalin.mari...@arm.com wrote: BTW, does the firmware make any checks on what bits it allows to be set? Some of them may have security implications (and may not even be documented). Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). That's true. That stack is ugly and _does_ break XIP (even if there aren't that many if at all on ARMv7). Since we're already writing to RAM while setting up the initial page table and therefore we did the necessary work to locate it already, we could as well put a temporary stack for early usage right below the page table. Firmware point is actually irrelevant for OMAP since it can't be changed once it is ROMed. Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. I don't disagree with this, a solution is needed. In the past I was for having platform hooks in the early kernel code path but in the light of latest kernel developments (FDT, single zImage), I no longer see this as acceptable. Thanks for acknowledging the problem. Not allowing such hooks for single zImage doesn't seems to be right. Nobody ships kernel build for all socs, and it's usage is really limited to few distro's. But that's different topic. No, I think this is right on topic. If nobody ships a kernel for multiple SOCs, this is because right now this can't be done. But distros are craving for this ability. How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 02:58:18PM +0100, Shilimkar, Santosh wrote: Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. And I'll re-iterate that it'll create an absolute abonimation of code to do this in the kernel - not only will it be extremely fragile, it will be hell to maintain in the longer term. It will also be highly platform specific. Essentially, what you're asking is for us to find some way to call a platform specific function depending on the platform (which we haven't parsed yet), which uses a set of undefined registers, which may corrupt an undefined set of registers. And call that function from a place in the kernel which requires a set of registers to be preserved, with no stack available to save registers, and call the function via a PC relative branch (as its virtual address is useless to us at this point.) If anything goes wrong, there's no way to report that as your only option is to stop dead (if you're lucky) or maybe end up with the processor trying to execute instructions from a non-existent or uninitialized vectors page, etc. This is far too much. This is far too fragile. This is asking for undebuggable problems. This is asking for lots of people with unbootable kernels. No. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote: Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). It _is_ a problem. How much stack space would these undefined platform specific functions require? 16 words? 32 words? A page? Where does this memory come from? The .data section, or are we going to stuff it into what is supposed to be the read-only text section? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] adding rpmsg and remoteproc to 3.3
On Thu, Jan 12, 2012 at 9:01 PM, Ohad Ben-Cohen o...@wizery.com wrote: Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git for-next-acked To get the remoteproc and rpmsg frameworks, and a few fixes that were collected after the frameworks were already merged into linux-next. (I also tried to push this as a signed tag rpmsg-for-3.3 but am not sure how successful that feat really was) git log --show-signature gives me the exact same output as git log does (just built 1.7.9.rc1.3.gb6310 to have it), so I'm not sure about the signature revalidation. But I do see the tag and it looks sane, and being able to include a merge commentary is indeed nice. And I guess the signature revalidation isn't too important since I'm anyway using k.org. Please let me know if there are any issues, Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote: Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). It _is_ a problem. How much stack space would these undefined platform specific functions require? 16 words? 32 words? A page? Where does this memory come from? The .data section, or are we going to stuff it into what is supposed to be the read-only text section? Stack requirement is limited to saving and restoring the processor registers. There is no additional need. If this is an issue, we can also use SRAM as a stack for this operation. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas catalin.mari...@arm.com wrote: BTW, does the firmware make any checks on what bits it allows to be set? Some of them may have security implications (and may not even be documented). Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). That's true. That stack is ugly and _does_ break XIP (even if there aren't that many if at all on ARMv7). Since we're already writing to RAM while setting up the initial page table and therefore we did the necessary work to locate it already, we could as well put a temporary stack for early usage right below the page table. Firmware point is actually irrelevant for OMAP since it can't be changed once it is ROMed. Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. I don't disagree with this, a solution is needed. In the past I was for having platform hooks in the early kernel code path but in the light of latest kernel developments (FDT, single zImage), I no longer see this as acceptable. Thanks for acknowledging the problem. Not allowing such hooks for single zImage doesn't seems to be right. Nobody ships kernel build for all socs, and it's usage is really limited to few distro's. But that's different topic. No, I think this is right on topic. If nobody ships a kernel for multiple SOCs, this is because right now this can't be done. But distros are craving for this ability. How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OMAP: 4430SDP/Panda: add HDMI HPD gpio
On Tuesday 17 January 2012 06:19 PM, Tomi Valkeinen wrote:
Both Panda and 4430SDP use GPIO 64 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Minor comment: the commit message says GPIO 64, and the macros use gpio
63. Is this done intentionally?
Archit
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 5dcc8df..a776c26 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -54,6 +54,7 @@
#define OMAP4_SFH7741_ENABLE_GPIO 188
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
#define DLP_POWER_ON_GPIO 40
@@ -598,6 +599,7 @@ static void __init omap_sfh7741prox_init(void)
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int sdp4430_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -836,6 +838,7 @@ static void omap_4430sdp_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 06a7075..b22a288 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -53,6 +53,7 @@
#define GPIO_WIFI_IRQ 53
#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
+#define HDMI_GPIO_HPD 63 /* Hotplug detect */
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
@@ -481,6 +482,7 @@ int __init omap4_panda_dvi_init(void)
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_CT_CP_HPD, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ct_cp_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
+ { HDMI_GPIO_HPD, GPIOF_DIR_IN, hdmi_gpio_hpd },
};
static int omap4_panda_panel_enable_hdmi(struct omap_dss_device *dssdev)
@@ -552,6 +554,7 @@ void omap4_panda_display_init(void)
omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
+ omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
}
static void __init omap4_panda_init(void)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? I don't care if this is OMAP, UX500 or i.MX. There is a line to be drawn and this is just too bad if you are trying to cross it. Nicolas
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 09:11:37PM +0100, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote: Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). It _is_ a problem. How much stack space would these undefined platform specific functions require? 16 words? 32 words? A page? Where does this memory come from? The .data section, or are we going to stuff it into what is supposed to be the read-only text section? Stack requirement is limited to saving and restoring the processor registers. There is no additional need. If this is an issue, we can also use SRAM as a stack for this operation. How do you know that's all that would be required? Let's look at another secure monitor API implementation in the kernel. MSM has one - arch/arm/mach-msm/scm.c. This requires parameters passed through memory - a command buffer consisting of at least four words in memory, followed by a response buffer of at least three words. So where would this be placed if not on the stack? Pick some random address and hope that there's some memory there? This is what I'm saying: while we may know what the requirement is for OMAP, that's not what it is for other SoCs. Every SoC has different requirements for this, and so we have _no_ idea what so ever how much stack space would actually be required. And if we don't know that, we have a real chance of having some implementation overflow the stack, thereby overwriting something (eg, maybe your DT data, maybe your initramfs image) which would be extremely detrimental. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Nicolas Pitre wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Alternatively, you may leverage all the infrastructure that was implemented to support CPU offlining i.e. the creation of a 1:1 mapping needed to disable the MMU and so on. That should be possible for you to just have the MMU turned off, then call the secure mode to turn on L2, then restore MMU and normal operation of the kernel. This can be accomplished later during boot rather than right at the beginning. Nicolas
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? I don't care if this is OMAP, UX500 or i.MX. There is a line to be drawn and this is just too bad if you are trying to cross it. Well I was trying to get a solution for a genuine problem. Let's take an example. #ifdef CONFIG_ARM_ERRATA_742230 cmp r6, #0x22 @ only present up to r2p2 mrcle p15, 0, r10, c15, c0, 1 @ read diagnostic register orrle r10, r10, #1 4 @ set bit #4 mcrle p15, 0, r10, c15, c0, 1 @ write diagnostic register #endif The SoC's which doesn't have security restriction and the kernel is in secure mode, above errata is applied in it's right place. Before MMU is enabled. There are many bits like this which are patched in kernel. On OMAP, all these can't be set-up in kernel since kernel is in non-secure mode. To set such bit's we need to call some pre-defined security calls. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? I don't care if this is OMAP, UX500 or i.MX. There is a line to be drawn and this is just too bad if you are trying to cross it. Well I was trying to get a solution for a genuine problem. Let's take an example. #ifdef CONFIG_ARM_ERRATA_742230 cmp r6, #0x22 @ only present up to r2p2 mrcle p15, 0, r10, c15, c0, 1 @ read diagnostic register orrle r10, r10, #1 4 @ set bit #4 mcrle p15, 0, r10, c15, c0, 1 @ write diagnostic register #endif The SoC's which doesn't have security restriction and the kernel is in secure mode, above errata is applied in it's right place. Before MMU is enabled. There are many bits like this which are patched in kernel. On OMAP, all these can't be set-up in kernel since kernel is in non-secure mode. To set such bit's we need to call some pre-defined security calls. Absolutely. Just don't do it in the early kernel boot code where it is not convenient to do so. Nicolas
Re: [RFC PATCH v2 7/8] media: video: introduce object detection driver module
On 01/04/2012 09:13 AM, Ming Lei wrote:
+
+int odif_open(struct file *file)
+{
+ struct odif_dev *dev = video_drvdata(file);
+
+ kref_get(dev-ref);
+ return v4l2_fh_open(file);
+}
Individual drivers may need to perform some initialization when
device node is opened. So I consider taking this possibility away
from them not a good idea.
OK, it can be handled easily by introducing new callbacks(such as.
.open_detect and .close_detect for close) in struct odif_ops.
Certainly, we can introduce plenty of new callbacks, another levels of
indirection that would just obfuscate things. It should rather be done
like v4l2-mem2mem does, where file operation handlers are implemented
by each driver and from their open()/close() handlers relevant init
and release functions are called (v4l2_m2m_init/v4l2_m2m_release).
I think we can always change the kernel interfaces once there is more
devices like OMAP4 FDIF. It may look easy for you when you refer to
just one hardware implementation with your theoretically generic module.
Or have you referred to other devices than OMAP4 FDIF when designing it ?
+static int vidioc_g_od_result(struct file *file, void *priv,
+ struct v4l2_od_result *f)
+{
+ struct odif_dev *dev = video_drvdata(file);
+ unsigned long flags;
+ struct v4l2_odif_result *tmp;
+ struct v4l2_odif_result *fr = NULL;
+ unsigned int cnt = 0;
+ int ret = -EINVAL;
+
+ spin_lock_irqsave(dev-lock, flags);
+ list_for_each_entry(tmp,dev-odif_dq.complete, list)
+ if (tmp-frm_seq == f-frm_seq) {
+ fr = tmp;
+ list_del(tmp-list);
+ break;
+ }
+ spin_unlock_irqrestore(dev-lock, flags);
+
+ if (fr) {
+ ret = 0;
+ cnt = min(f-obj_cnt, fr-obj_cnt);
+ if (cnt)
+ memcpy(f-od, fr-objs,
+ sizeof(struct v4l2_od_object) * cnt);
+ f-obj_cnt = cnt;
+
+ free_result(fr);
Some drivers may be designed so they do not discard the result data
automatically once it is read by user application. AFAICS this module
doesn't allow such behaviour.
For instance, it might be required to discard the oldest results data
when the ring buffer gets filled in.
Looks like no any benefit about keeping the old result data, could you
give some use cases which require the old results need to be kept for
some time?
Consider scenario where one thread writes image data and multiple threads
read the FD results. Having all data discarded on first read only one
thread could get the data. This is not what we want in a standard API.
Also in V4L2 it is always assumed that multiple applications can read
state of a device, and the application priority API [1] aims at
managing the devices state modifications among multiple processes.
...
+static int buffer_init(struct vb2_buffer *vb)
+{
+ struct odif_dev *dev = vb2_get_drv_priv(vb-vb2_queue);
+
+ /*
+ * This callback is called once per buffer, after its allocation.
+ *
+ * Vivi does not allow changing format during streaming, but it is
+ * possible to do so when streaming is paused (i.e. in streamoff
state).
+ * Buffers however are not freed when going into streamoff and so
+ * buffer size verification has to be done in buffer_prepare, on each
+ * qbuf.
+ * It would be best to move verification code here to buf_init and
+ * s_fmt though.
+ */
+ dprintk(dev, 1, %s vaddr=%p\n, __func__,
+ vb2_plane_vaddr(vb, 0));
+
+ return 0;
+}
As I already mentioned this empty callback can be removed. Anyway IMO the
implementation of the buffer queue operations should be left to individual
drivers. Having them in generic module doesn't sound flexible enough.
IMO, the buffer queue operations can be shared for use case of
detecting objects from user space images, so it may be kept it in
generic driver.
Not necessarily, sometimes device specific logic needs to be implemented
in these callbacks. And the ioctl handlers (vidioc_*) should be just
pass-through for the vb2 callbacks.
+void odif_add_detection(struct odif_dev *dev,
+ struct v4l2_odif_result *v4l2_fr)
+{
+ unsigned long flags;
+ struct v4l2_odif_result *old = NULL;
+ struct v4l2_odif_result *tmp;
+
+ spin_lock_irqsave(dev-lock, flags);
+ list_for_each_entry(tmp,dev-odif_dq.complete, list)
+ if (tmp-frm_seq == v4l2_fr-frm_seq) {
+ old = tmp;
+ list_del(tmp-list);
+ break;
+ }
+ list_add_tail(v4l2_fr-list,dev-odif_dq.complete);
+ spin_unlock_irqrestore(dev-lock, flags);
+
+ if (old)
+ free_result(old);
+ else
+ atomic_inc(dev-odif_dq.complete_cnt);
+}
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, Jan 17, 2012 at 09:27:02PM +0100, Shilimkar, Santosh wrote: There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. There is nothing fancy about not being permitted to access registers due to security restrictions. What is fancy is that every SoC vendor out there implements their own private API to provide a method to access these registers without any form of commonality. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? To confirm what Nicolas said in reply to this - I really don't care either what kind of SoC this is. This is purely about the technical problems with what is being proposed. And, as I've said several times already, the root cause of this problem is not the SoC vendors, but a lack of standardization about how these services are provided. Imagine this: what if every vendor of a PC out there provided their ACPI data in totally different formats? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2/PM on 3.2 broken?
On Sat, 14 Jan 2012 10:09:15 +1100 NeilBrown ne...@suse.de wrote: On Fri, 13 Jan 2012 04:31:37 -0700 (MST) Paul Walmsley p...@pwsan.com wrote: On Fri, 13 Jan 2012, NeilBrown wrote: Also, the HDQ access to the battery 'fuel gauge' is working fine, so presumably that gets disturbed by one of the lower power states (3,4,5). I guess it is 4,5,6 when CORE goes to RET or OFF. So we need some way for HDQ to say I'm busy just like UART can. omap_hdq_can_sleep() ??? There must be a cleaner way... The first thing to try is the HDQ runtime PM conversion series that was sent separately. Maybe let us know if that fixes the problem. Not completely - but I'm still exploring. I've finished exploring (for now) and am seriously stumped. Maybe you can help... I modified your patch so that hdq uses autosuspend - because it seemed like a good idea and ends up providing slightly more informative failure modes. The normal behaviour of the bq27000 driver is to request lots of values in quick succession. So using autosuspend (with 100ms timeout) means that we have only one pm_resume and one pm_suspend for each batch of requests which at least reduces the noise. I have added an omap_hdq_can_sleep() function which only succeeds if the hdq device is run-time suspended, and call it in the same place that omap_uart_can_sleep is called, to ensure the core never goes to a lower state while he hdq is active. I've double-checked that this really works. HDQ all works find normally, but then normally CORE stays ON because the UART keeps it on. If I tell the UARTs they can sleep (by setting sleep_timeout) and then access the bq27000 via HDQ it doesn't work properly. The normal sequence is that it resets the HDQ and sends a 'BREAK' signal (possibly not really necessary) for which we get a TIMEOUT interrupt. Then write address - get TX interrupt - wait a bit - get RX interrupt - read byte. We normally get the TIMEOUT interrupt and often get the first TX and then RX interrupts but then the device goes silent. No more interrupts come in, and the status register (which shows interrupt source) reads as zero. Occasionally I have seen maybe half a dozen successful reads before it goes silent, but usually it is zero or 1. It is as though something is timing out and going to sleep. A clock auto-sleeping? Seems unlikely. If I set all the UART sleep_timeout values to 0 to keep CORE always ON, the problem doesn't fix itself. Whatever got turned off stays off. Once it starts failing, it never works again until a reboot. Could we be caching something in memory which we think is on, but due to CORE going into RET (or maybe OFF), the thing is now off and we never bother to reset it because the cached value is 'on' ?? I'm wondering about _sysc_cache, but I haven't looked very deeply into it. Any other ideas? Oh - another thing. Sometimes during early boot I get: [0.158447] omap_hwmod: usbtll_fck: missing clockdomain for usbtll_fck. [0.176879] omap_hwmod: hdq: softreset failed (waited 1 usec) At the same time the UART seem to hiccup and my USB-Serial port loses track and doesn't see any more characters until I close and re-open. Could that be related? Any idea what it means? Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
On Tue, 17 Jan 2012 07:32:47 +
AnilKumar, Chimata anilku...@ti.com wrote:
Hi All,
Recalling the patch, provide the comments if there are any if not please
include
this patch to v3.3 kernel.
The patch is all mangled by someone's email client. Wordwrapping, mime
crap which my MUA can't decrypt, etc.
-Original Message-
From: AnilKumar, Chimata
Sent: Friday, December 23, 2011 10:55 AM
To: a...@arndb.de; g...@kroah.com; eric.p...@tremplin-utc.net;
a...@linux-foundation.org; broo...@opensource.wolfsonmicro.com;
linux-ker...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; Nori, Sekhar; AnilKumar, Chimata
A pet peeve which I haven't told anyone about. If you've cc'ed someone
on a patch then I want to cc them on the patch too. That means I have
to add their Cc: lines to the changelog. But such Cc: lines include
their real names. By omitting their real names in the above fashion,
you cause extra hassle for me. Ideally, you should add their Cc: to
the changelog as well as to the mail headers, to give thsoe people the
best chance of seeing what is happening with the patch.
..
+static ssize_t lis3lv02d_range_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ lis3lv02d_sysfs_poweron(lis3_dev);
+ return sprintf(buf, %d\n, lis3_dev.g_range);
+}
Are these interfaces documented anywhere? If so, please update that
documentation. If not, why not ;)
@@ -809,15 +881,33 @@ static ssize_t lis3lv02d_rate_set(struct device *dev,
return count;
}
+static ssize_t lis3lv02d_range_set(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ unsigned long range;
+
+ if (strict_strtoul(buf, 0, range))
checkpatch would have told you that strict_strtoul() is deprecated.
Please always use checkpatch.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: List i2c-omap and i2c-davinci drivers
On Tue, Jan 10, 2012 at 03:36:40PM +0100, Jean Delvare wrote: This will ensure that the right people and lists are notified when these drivers are modified. sounds like a good idea. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@ti.com --- If there are no objections, I'll send this to Linus quickly. MAINTAINERS |3 +++ 1 file changed, 3 insertions(+) --- linux-3.3-rc0.orig/MAINTAINERS2012-01-10 15:24:37.0 +0100 +++ linux-3.3-rc0/MAINTAINERS 2012-01-10 15:27:28.0 +0100 @@ -4673,6 +4673,8 @@ Q: http://patchwork.kernel.org/project/l T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git S: Maintained F: arch/arm/*omap*/ +F: drivers/i2c/busses/i2c-omap.c +F: include/linux/i2c-omap.h OMAP CLOCK FRAMEWORK SUPPORT M: Paul Walmsley p...@pwsan.com @@ -5945,6 +5947,7 @@ L: davinci-linux-open-source@linux.davin Q: http://patchwork.kernel.org/project/linux-davinci/list/ S: Supported F: arch/arm/mach-davinci +F: drivers/i2c/busses/i2c-davinci.c SIS 190 ETHERNET DRIVER M: Francois Romieu rom...@fr.zoreil.com -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi stephane Will, On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian eran...@googlemail.com wrote: See the dmesg from my 3.2 kernel: [ 0.00] Booting Linux on physical CPU 0[ 0.00] Looks no obvious failure can be found from your 'dmesg'. I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and found perf can work well on my panda board. 0001-arm-introduce-cross-trigger-interface-helpers.patch 0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch 0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2] 0004-arm-omap4-create-pmu-device-via-hwmod.patch[3] 0005-arm-omap4-support-pmu.patch[4] 0006-arm-omap4-pmu-support-runtime-pm.patch[5] Could you verify the above patches on 3.2 to see if perf can work well? If it doesn't, I may share my u-boot and mlo for your test if you'd like to do. BTW: #1 and #2 have been in Will's -next tree. thanks, -- Ming Lei [1], uname -a cat /proc/interrupts [root@root]#uname -a Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012 armv7l GNU/Linux [root@root]#cat /proc/interrupts CPU0 CPU1 29: 29014 17353 GIC twd 33: 56231 0 GIC arm-pmu 34: 0 25778 GIC arm-pmu [2], http://marc.info/?l=linux-omapm=132162118104901w=2 [3],http://marc.info/?t=13222762152r=1w=2 [4],http://marc.info/?t=13222762172r=1w=2 [5],http://marc.info/?t=13222762173r=1w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Thanks Greg On Tue, Jan 17, 2012 at 21:33:35, g...@kroah.com wrote: On Tue, Jan 17, 2012 at 10:54:42AM +, Mark Brown wrote: On Tue, Jan 17, 2012 at 07:32:47AM +, AnilKumar, Chimata wrote: Recalling the patch, provide the comments if there are any if not please include this patch to v3.3 kernel. There's no way this is going to make it into the 3.3 kernel at this point, we're almost at the end of the merge window. Agreed, the merge window is for subsystem maintainers, not everyone else. I'll queue this up for review for after 3.3-rc1 is out. thanks, greg k-h Regards AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OMAP: 4430SDP/Panda: add HDMI HPD gpio
On Wed, 2012-01-18 at 02:02 +0530, Archit wrote: On Tuesday 17 January 2012 06:19 PM, Tomi Valkeinen wrote: Both Panda and 4430SDP use GPIO 64 as HDMI hot-plug-detect. Configure this GPIO in the board files. Minor comment: the commit message says GPIO 64, and the macros use gpio 63. Is this done intentionally? Thanks, it's a typo. HPD gpio is 63. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] arm/dts: omap3-evm: Add i2c and twl4030 support
Add support for TWL4030, which is interfaced on i2c1 bus.
Also add clock frequencies for other i2c instances(2 3)
required for client-device exist on OMAP3EVM board.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-evm.dts | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..530bdc0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,31 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+
+ /*
+* TVP5146 Video decoder-in for analog input support.
+*/
+ tvp5146@5C {
+ compatible = ti,tvp5146m2;
+ reg = 0x5C;
+ };
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm/dts: Add support for TI AM3517/05 EVM board
Add AM3517 EVM (AM3517/05) DTS file to use the omap3.dtsi SoC file,
along with memory node and basic i2c information.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am3517-evm.dts | 32
1 files changed, 32 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/am3517-evm.dts
diff --git a/arch/arm/boot/dts/am3517-evm.dts b/arch/arm/boot/dts/am3517-evm.dts
new file mode 100644
index 000..474f760
--- /dev/null
+++ b/arch/arm/boot/dts/am3517-evm.dts
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI AM3517 EVM (AM3517/05);
+ compatible = ti,am3517-evm, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+i2c1 {
+ clock-frequency = 40;
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2/PM on 3.2 broken?
On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote: Having CPUIDLE makes the DSS2 problem worse: lots of [ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled messages whenever the CPU isn't busy. I'm not sure if it is the case here, but DSS has restrictions about the max DSS clocks on different OPPs. For example, on OMAP4430 LCD clock maximum is 186MHz at OPP100, and 93MHz at OPP50. So it's a quite big drop, causing problems with all but the rather small displays. And the DSS driver doesn't have any support to handle this at the moment, as there isn't support in the PM framework to do this. I think the only way to handle this at the moment is for the DSS driver to set an arbitrarily high constraint on, say, mem throughput, and hope that it keeps the OMAP in the required OPP. Tomi signature.asc Description: This is a digitally signed message part
[PATCH 1/2] arm:omap2:board-generic: Add DT support for AM33xx devices
Although we consider am33xx device under omap34xx family of devices,
there is indeed difference between them, for example,
- Initial required mapping (-map_io)
- Early init (-init_early)
Here, the whole sequence/data is different than omap3,
For example, clock/hwmod/power/voltage data.
- clock event/source timer (name and instances)
So, this patch adds seperate machine descriptor for AM33XX family
of devices in board-generic.c file.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
CC: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
Tested it on AM335x-EVM, AM37xEVM and AM3517EVM.
arch/arm/mach-omap2/board-generic.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index f7b4b24..2faecc8 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -106,6 +106,25 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
MACHINE_END
#endif
+#if defined(CONFIG_SOC_OMAPAM33XX)
+static const char *am33xx_boards_compat[] __initdata = {
+ ti,am33xx,
+ NULL,
+};
+
+DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree))
+ .atag_offset= 0x100,
+ .reserve= omap_reserve,
+ .map_io = am33xx_map_io,
+ .init_early = am33xx_init_early,
+ .init_irq = omap_init_irq,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .timer = omap3_am33xx_timer,
+ .dt_compat = am33xx_boards_compat,
+MACHINE_END
+#endif
+
#if defined(CONFIG_ARCH_OMAP4)
static const char *omap4_boards_compat[] __initdata = {
ti,omap4,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm/dts: Add support for TI AM335x EVM board
Add AM335x EVM DTS file to use the omap3.dtsi SoC file,
along with memory node and i2c information.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/am335x-evm.dts | 39 ++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/am335x-evm.dts
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
new file mode 100644
index 000..8cc877f
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -0,0 +1,39 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TI AM335x EVM;
+ compatible = ti,am335x-evm, ti,am33xx, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+intc {
+ /*
+* AM33XX family of devices have 128 interrupts
+*/
+ ti,intc-size = 128;
+};
+
+i2c1 {
+ clock-frequency = 40;
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 DSS2 - VENC timings
On Mon, 2012-01-16 at 11:08 -0700, Gary Thomas wrote: I'm running a frame buffer console on a TV device via the VENC. The video timings don't see to be quite right as Tux is about 1/2 off the screen - both directions, i.e. his head and right side have been cut off as they are outside the viewable area. Also, when I send data to the device (via /dev/tty1) which has 90x35 characters, I lose 4 characters on each end of every line. Is there something I can do about this? I've looked at the timings in drivers/video/omap2/dss/venc.c I don't know much about analog TV, but my understanding is that there's always overscanning going on. You just have to size and position the overlay so that it is visible on your TV. Also, how can I select NTSC vs PAL setups via the command line? I have only the one video device VENC. Documentation/arm/OMAP/DSS says you can echo pal or ntsc to sys/devices/platform/omapdss/display?/timings file. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital
Hi Andrew,
Thanks for reviewing the patch
On Wed, Jan 18, 2012 at 05:17:02, Andrew Morton wrote:
On Tue, 17 Jan 2012 07:32:47 +
AnilKumar, Chimata anilku...@ti.com wrote:
Hi All,
Recalling the patch, provide the comments if there are any if not please
include
this patch to v3.3 kernel.
The patch is all mangled by someone's email client. Wordwrapping, mime
crap which my MUA can't decrypt, etc.
My bad, in a hurry I have sent a mail by doing reply to all that makes
all this non-sense will not repeated again.
Thanks for your patience here.
...snip...
A pet peeve which I haven't told anyone about. If you've cc'ed someone
on a patch then I want to cc them on the patch too. That means I have
to add their Cc: lines to the changelog. But such Cc: lines include
their real names. By omitting their real names in the above fashion,
you cause extra hassle for me. Ideally, you should add their Cc: to
the changelog as well as to the mail headers, to give thsoe people the
best chance of seeing what is happening with the patch.
Above comment applies here as well.
..
+static ssize_t lis3lv02d_range_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ lis3lv02d_sysfs_poweron(lis3_dev);
+ return sprintf(buf, %d\n, lis3_dev.g_range);
+}
Are these interfaces documented anywhere? If so, please update that
documentation. If not, why not ;)
Yes, these interfaces are documented at
Documentation/misc-devices/lis3lv02d but range is not included
there, which is added in this patch. Will be updated and send it
as a separate patch.
@@ -809,15 +881,33 @@ static ssize_t lis3lv02d_rate_set(struct device *dev,
return count;
}
+static ssize_t lis3lv02d_range_set(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
+{
+ unsigned long range;
+
+ if (strict_strtoul(buf, 0, range))
checkpatch would have told you that strict_strtoul() is deprecated.
Please always use checkpatch.
Somehow I missed this, I will update with kstrtoul. I have to update
the same API in other set function.
Thanks
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 DSS2 - VENC timings
On Wed, Jan 18, 2012 at 13:08:23, Valkeinen, Tomi wrote: On Mon, 2012-01-16 at 11:08 -0700, Gary Thomas wrote: I'm running a frame buffer console on a TV device via the VENC. The video timings don't see to be quite right as Tux is about 1/2 off the screen - both directions, i.e. his head and right side have been cut off as they are outside the viewable area. Also, when I send data to the device (via /dev/tty1) which has 90x35 characters, I lose 4 characters on each end of every line. I am not sure whether this applies here with your issue, but if I remember correctly, during initial days of development we had similar issue where, corners of the display cuts-off. The conclusion was, analog TV's crops the ~5-10% of the input image (depends on TV). I don't quite remember further details on this... Thanks, Vaibhav Is there something I can do about this? I've looked at the timings in drivers/video/omap2/dss/venc.c I don't know much about analog TV, but my understanding is that there's always overscanning going on. You just have to size and position the overlay so that it is visible on your TV. Also, how can I select NTSC vs PAL setups via the command line? I have only the one video device VENC. Documentation/arm/OMAP/DSS says you can echo pal or ntsc to sys/devices/platform/omapdss/display?/timings file. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
