[PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions
The vaux2 (VCSI) regulator is left on by the bootloader
in rx-51. Since there the product has shipped and there
won't be any bootloader updates to fix this issue, we
need to define all the regulators and declare full
constraints for the regulator FW. This will allow the
regulator FW to disable unused regulators.
Also this helps in adding more fine grain regulator
support for rx-51 in the future.
Thanks for Mark Brown for pointing out the correct
solution.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 69 ++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..4026b4b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -475,6 +475,32 @@ static struct regulator_init_data rx51_vmmc2 = {
.consumer_supplies = rx51_vmmc2_supplies,
};
+static struct regulator_init_data rx51_vpll1 = {
+ .constraints = {
+ .name = VPLL,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+};
+
+static struct regulator_init_data rx51_vpll2 = {
+ .constraints = {
+ .name = VSDI_CSI,
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+};
+
static struct regulator_init_data rx51_vsim = {
.constraints = {
.name = VMMC2_IO_18,
@@ -519,6 +545,43 @@ static struct regulator_init_data rx51_vio = {
.consumer_supplies = rx51_vio_supplies,
};
+static struct regulator_init_data rx51_vintana1 = {
+ .constraints = {
+ .name = VINTANA1,
+ .min_uV = 150,
+ .max_uV = 150,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+};
+
+static struct regulator_init_data rx51_vintana2 = {
+ .constraints = {
+ .name = VINTANA2,
+ .min_uV = 275,
+ .max_uV = 275,
+ .apply_uV = true,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+};
+
+static struct regulator_init_data rx51_vintdig = {
+ .constraints = {
+ .name = VINTDIG,
+ .min_uV = 150,
+ .max_uV = 150,
+ .always_on = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+};
+
static struct si4713_platform_data rx51_si4713_i2c_data __initdata_or_module =
{
.gpio_reset = RX51_FMTX_RESET_GPIO,
};
@@ -767,8 +830,13 @@ static struct twl4030_platform_data rx51_twldata
__initdata = {
.vaux2 = rx51_vaux2,
.vaux4 = rx51_vaux4,
.vmmc1 = rx51_vmmc1,
+ .vpll1 = rx51_vpll1,
+ .vpll2 = rx51_vpll2,
.vsim = rx51_vsim,
.vdac = rx51_vdac,
+ .vintana1 = rx51_vintana1,
+ .vintana2 = rx51_vintana2,
+ .vintdig= rx51_vintdig,
.vio= rx51_vio,
};
@@ -969,6 +1037,7 @@ error:
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
+ regulator_has_full_constraints();
gpmc_onenand_init(board_onenand_data);
board_smc91x_init();
rx51_add_gpio_keys();
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
[PATCH v2 0/1] RX-51: add full regulator definitions
Adding regulator definitions to correctly shut down unneeded regulators. Needed, but previously undefined regulators were marked always_on. Tested on top of MeeGo N900 DE daily release (.37 kernel) and with linux-omap. Patch based on linux-omap HEAD. v2: updated as per comments from Jarkko Nikula and Mark Brown. Kalle Jokiniemi (1): OMAP3: rx-51: Add full regulator definitions arch/arm/mach-omap2/board-rx51-peripherals.c | 69 ++ 1 files changed, 69 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] OMAP3: rx-51: Add full regulator definitions
On Mon, 2 May 2011 05:19:46 + kalle.jokini...@nokia.com wrote: It seems I was not answering your question quite rightly... So these are used to power some internal blocks inside the TWL5030. The dependencies there are not very well documented, so it's best to leave them be. I think these could be turned off via the power scripts during OFF mode (if we would be using that). Sounds safe assumption for those two. Also I don't point out from public schematics where are the vintana2 and vpll2 routed so looks like need keep them on as well. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions
On Mon, 2 May 2011 09:28:53 +0300 Kalle Jokiniemi kalle.jokini...@nokia.com wrote: The vaux2 (VCSI) regulator is left on by the bootloader in rx-51. Since there the product has shipped and there won't be any bootloader updates to fix this issue, we need to define all the regulators and declare full constraints for the regulator FW. This will allow the regulator FW to disable unused regulators. Also this helps in adding more fine grain regulator support for rx-51 in the future. Thanks for Mark Brown for pointing out the correct solution. Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com --- Reviewed-by: Jarkko Nikula jhnik...@gmail.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 1/1] OMAP3: rx-51: Add full regulator definitions
Hi, -Original Message- From: ext Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: 2. toukokuuta 2011 9:57 To: Jokiniemi Kalle (Nokia-SD/Tampere) Cc: t...@atomide.com; Ailus Sakari (Nokia-SD/Helsinki); linux- o...@vger.kernel.org; l...@slimlogic.co.uk; broo...@opensource.wolfsonmicro.com Subject: Re: [PATCH 1/1] OMAP3: rx-51: Add full regulator definitions On Mon, 2 May 2011 05:19:46 + kalle.jokini...@nokia.com wrote: It seems I was not answering your question quite rightly... So these are used to power some internal blocks inside the TWL5030. The dependencies there are not very well documented, so it's best to leave them be. I think these could be turned off via the power scripts during OFF mode (if we would be using that). Sounds safe assumption for those two. Also I don't point out from public schematics where are the vintana2 and vpll2 routed so looks like need keep them on as well. In case you're interested, the high level routings are listed in the TPS65950 TRM: http://focus.ti.com/lit/ug/swcu050g/swcu050g.pdf See chapter 6.3, figure 6-3. - Kalle -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi,
-Original Message-
From: ext Tony Lindgren [mailto:t...@atomide.com]
Sent: 29. huhtikuuta 2011 12:14
To: Jokiniemi Kalle (Nokia-SD/Tampere)
Cc: laurent.pinch...@ideasonboard.com; mche...@infradead.org; linux-
o...@vger.kernel.org; linux-me...@vger.kernel.org
Subject: Re: [PATCH 2/2] OMAP3: RX-51: define vdds_csib regulator supply
* Kalle Jokiniemi kalle.jokini...@nokia.com [110429 00:09]:
The RX-51 uses the CSIb IO complex for camera operation. The
board file is missing definition for the regulator supplying
the CSIb complex, so this is added for better power
management.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
This looks safe to merge along with the other patch
Acked-by: Tony Lindgren t...@atomide.com
Thanks Tony, adding Mauro's correct email...
- Kalle
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..1324ba3 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -337,6 +337,13 @@ static struct omap2_hsmmc_info mmc[] __initdata =
{
static struct regulator_consumer_supply rx51_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
+static struct regulator_consumer_supply rx51_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(vdds_csib, omap3isp),
+ {
+ .supply = vaux2,
+ },
+};
+
static struct regulator_consumer_supply rx51_vaux3_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
@@ -400,6 +407,8 @@ static struct regulator_init_data rx51_vaux2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vaux2_supplies),
+ .consumer_supplies = rx51_vaux2_supplies,
};
/* VAUX3 - adds more power to VIO_18 rail */
--
1.7.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 v2 1/2] OMAP3: ISP: Add regulator control for omap34xx
The current omap3isp driver is missing regulator handling
for CSIb complex in omap34xx based devices. This patch
adds a mechanism for this to the omap3isp driver.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
---
drivers/media/video/omap3isp/ispccp2.c | 27 +--
drivers/media/video/omap3isp/ispccp2.h |1 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c
index 0e16cab..ec9e395 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/uaccess.h
+#include linux/regulator/consumer.h
#include isp.h
#include ispreg.h
@@ -163,6 +164,9 @@ static void ccp2_if_enable(struct isp_ccp2_device *ccp2, u8
enable)
struct isp_pipeline *pipe = to_isp_pipeline(ccp2-subdev.entity);
int i;
+ if (enable ccp2-vdds_csib)
+ regulator_enable(ccp2-vdds_csib);
+
/* Enable/Disable all the LCx channels */
for (i = 0; i CCP2_LCx_CHANS_NUM; i++)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCP2, ISPCCP2_LCx_CTRL(i),
@@ -186,6 +190,9 @@ static void ccp2_if_enable(struct isp_ccp2_device *ccp2, u8
enable)
ISPCCP2_LC01_IRQENABLE,
ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ);
}
+
+ if (!enable ccp2-vdds_csib)
+ regulator_disable(ccp2-vdds_csib);
}
/*
@@ -1137,6 +1144,9 @@ error:
*/
void omap3isp_ccp2_cleanup(struct isp_device *isp)
{
+ struct isp_ccp2_device *ccp2 = isp-isp_ccp2;
+
+ regulator_put(ccp2-vdds_csib);
}
/*
@@ -1151,14 +1161,27 @@ int omap3isp_ccp2_init(struct isp_device *isp)
init_waitqueue_head(ccp2-wait);
- /* On the OMAP36xx, the CCP2 uses the CSI PHY1 or PHY2, shared with
+ /*
+* On the OMAP34xx the CSI1 receiver is operated in the CSIb IO
+* complex, which is powered by vdds_csib power rail. Hence the
+* request for the regulator.
+*
+* On the OMAP36xx, the CCP2 uses the CSI PHY1 or PHY2, shared with
* the CSI2c or CSI2a receivers. The PHY then needs to be explicitly
* configured.
*
* TODO: Don't hardcode the usage of PHY1 (shared with CSI2c).
*/
- if (isp-revision == ISP_REVISION_15_0)
+ if (isp-revision == ISP_REVISION_2_0) {
+ ccp2-vdds_csib = regulator_get(isp-dev, vdds_csib);
+ if (IS_ERR(ccp2-vdds_csib)) {
+ dev_dbg(isp-dev,
+ Could not get regulator vdds_csib\n);
+ ccp2-vdds_csib = NULL;
+ }
+ } else if (isp-revision == ISP_REVISION_15_0) {
ccp2-phy = isp-isp_csiphy1;
+ }
ret = ccp2_init_entities(ccp2);
if (ret 0)
diff --git a/drivers/media/video/omap3isp/ispccp2.h
b/drivers/media/video/omap3isp/ispccp2.h
index 5505a86..6674e9d 100644
--- a/drivers/media/video/omap3isp/ispccp2.h
+++ b/drivers/media/video/omap3isp/ispccp2.h
@@ -81,6 +81,7 @@ struct isp_ccp2_device {
struct isp_interface_mem_config mem_cfg;
struct isp_video video_in;
struct isp_csiphy *phy;
+ struct regulator *vdds_csib;
unsigned int error;
enum isp_pipeline_stream_state state;
wait_queue_head_t wait;
--
1.7.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 v2 0/2] omap3isp/rx-51: Add vdds_csib regulator handling
The CSIb block is used in rx-51 to handle camera ccp2 IO. Adding support to omap3isp driver for managing the power supply for the CSIb IO complex via regulator framework. Also create the apropriate regulator definitions in the rx-51 board file. I propose to push this set through the linux-media, since most of the changes are on the omap3isp driver side. Any comments/review appreciated. Tested on Nokia N900 and the MeeGo testing daily images (.37 based kernel). Patches on top of Mauro's linux-next tree, build tested and boot tested with that. v2: updated patch 1/2 with comment from Laurent Pinchart Kalle Jokiniemi (2): OMAP3: ISP: Add regulator control for omap34xx OMAP3: RX-51: define vdds_csib regulator supply arch/arm/mach-omap2/board-rx51-peripherals.c |9 drivers/media/video/omap3isp/ispccp2.c | 27 - drivers/media/video/omap3isp/ispccp2.h |1 + 3 files changed, 35 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] OMAP3: RX-51: define vdds_csib regulator supply
The RX-51 uses the CSIb IO complex for camera operation. The
board file is missing definition for the regulator supplying
the CSIb complex, so this is added for better power
management.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..1324ba3 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -337,6 +337,13 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
static struct regulator_consumer_supply rx51_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
+static struct regulator_consumer_supply rx51_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(vdds_csib, omap3isp),
+ {
+ .supply = vaux2,
+ },
+};
+
static struct regulator_consumer_supply rx51_vaux3_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
@@ -400,6 +407,8 @@ static struct regulator_init_data rx51_vaux2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vaux2_supplies),
+ .consumer_supplies = rx51_vaux2_supplies,
};
/* VAUX3 - adds more power to VIO_18 rail */
--
1.7.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 v3] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
special sequence to reset the module. The sequence is
- Disable the I2C.
- Write to SOFTRESET bit.
- Enable the I2C.
- Poll on the RESETDONE bit.
The sequence is implemented as a function and the i2c_class is updated with
the correct 'reset' pointer. omap_hwmod_softreset function is implemented
which triggers the softreset by writing into sysconfig register. On following
this sequence, i2c module resets properly and timeouts are not seen.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
---
The patch is based on
* git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
* master branch.
* 9be20f0 commit. ( Linux-omap rebuilt: Updated to -rc5 )
Changes from previous versions:
from v1:
- moved i2c specific things from hwmod files to i2c files.
- fixed comments from Paul.
- http://www.spinics.net/lists/linux-omap/msg49483.html
from v2:
- Avoided direct SYSCONFIG access in i2c.c
- http://www.spinics.net/lists/linux-omap/msg49632.html
Testing:
* build tested omap2plus_defconfig for warnings and errors. none introduced.
* boot tested on 2430.
* tested for 'core off' in suspend resume on 3430 sdp. core off counters
increment after suspend resume.
arch/arm/mach-omap2/i2c.c| 54 ++
arch/arm/mach-omap2/omap_hwmod.c | 12 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/plat-omap/include/plat/i2c.h|4 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
7 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index 79c478c..bd50e26 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -21,9 +21,16 @@
#include plat/cpu.h
#include plat/i2c.h
+#include plat/common.h
#include mux.h
+/* In register I2C_CON, Bit 15 is the I2C enable bit */
+#define I2C_EN BIT(15)
+#define I2C_CON_OFFSET 0x24
+/* Maximum microseconds to wait for OMAP module to softreset */
+#define MAX_MODULE_SOFTRESET_WAIT 1
+
void __init omap2_i2c_mux_pins(int bus_id)
{
char mux_name[sizeof(i2c2_scl.i2c2_scl)];
@@ -37,3 +44,50 @@ void __init omap2_i2c_mux_pins(int bus_id)
sprintf(mux_name, i2c%i_sda.i2c%i_sda, bus_id, bus_id);
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
}
+
+/**
+ * omap_i2c_reset- reset the omap i2c module.
+ * @oh: struct omap_hwmod *
+ *
+ * The i2c moudle in omap2, omap3 had a special sequence to reset. The
+ * sequence is:
+ * - Disable the I2C.
+ * - Write to SOFTRESET bit.
+ * - Enable the I2C.
+ * - Poll on the RESETDONE bit.
+ * The sequence is implemented in below function. This is called for 2420,
+ * 2430 and omap3.
+ */
+int omap_i2c_reset(struct omap_hwmod *oh)
+{
+ u32 v;
+ int c = 0;
+
+ /* Disable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v = v ~I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Write to the SOFTRESET bit */
+ omap_hwmod_softreset(oh);
+
+ /* Enable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v |= I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Poll on RESETDONE bit */
+ omap_test_timeout((omap_hwmod_read(oh,
+ oh-class-sysc-syss_offs)
+SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+
+ if (c == MAX_MODULE_SOFTRESET_WAIT)
+ pr_warning(%s: %s: softreset failed (waited %d usec)\n,
+ __func__, oh-name, MAX_MODULE_SOFTRESET_WAIT);
+ else
+ pr_debug(%s: %s: softreset in %d usec\n, __func__,
+ oh-name, c);
+
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..771fc15 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1561,6 +1561,18 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16
reg_offs)
__raw_writel(v, oh-_mpu_rt_va + reg_offs);
}
+void omap_hwmod_softreset(struct omap_hwmod *oh)
+{
+ u32 v;
+
+ /* Write to the SOFTRESET bit in SYSCONFIG */
+ v = oh-_sysc_cache;
+ v |= (0x1 oh-class-sysc-sysc_fields-srst_shift);
+
+ oh-_sysc_cache = v;
+ omap_hwmod_write(v, oh, oh-class-sysc-sysc_offs);
+}
+
/**
* omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
* @oh: struct omap_hwmod *
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
Re: [PATCH] usb: musb: omap2430: Fix retention idle on musb peripheral only boards
On Wed, Apr 27, 2011 at 05:02:37PM +0300, Jarkko Nikula wrote: Recent runtime pm and hwmod conversions for 2.6.39 broke the musb peripheral mode OMAP retention idle on boards where the board mode in struct musb_hdrc_platform_data is set to MUSB_PERIPHERAL. These conversions changed the way how the OTG_SYSCONFIG register is configured and used in runtime. Before 2.6.39 smart standby/idle modes were activated statically in OTG_SYSCONFIG. Those modes allow that the musb is able to idle when peripheral device is not connected to host. In 2.6.39 the OTG_SYSCONFIG is updated runtime depending on VBUS status. No standby/idle modes are used when device is connected and force standby/idle when disconnected. Unfortunately VBUS disconnect event that handles the disconnect case lets the peripheral musb to idle only when board mode is MUSB_OTG. Fix this by checking the peripheral mode also. Signed-off-by: Jarkko Nikula jhnik...@gmail.com applied, thanks -- balbi -- 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] usb: musb: gadget: Fix out-of-sync runtime pm calls
On Fri, Apr 29, 2011 at 04:17:35PM +0300, Jarkko Nikula wrote: If cable is not connected to peripheral only board when initializing the gadget driver, then runtime pm calls are out-of-sync and the musb cannot idle with omap2430.c. This was noted on Nokia N900 where musb prevented the CPU to be able to enter deeper retention idle state. This was working in 2.6.38 before runtime pm conversions but there musb smart standby/idle modes were configured statically where they are now updated runtime depending on use and cable status. Reason for out-of-sync is that runtime pm is activated in function musb_gadget.c: usb_gadget_probe_driver but suspended only in OTG mode if cable is not connected when initializing. In peripheral only mode this leads to out-of-sync runtime pm since runtime pm remain active and is activated another time in omap2430.c: musb_otg_notifications for VBUS Connect event and thus cannot suspend for VBUS Disconnect event since the use count remains active. Fix this by moving cable status check and pm_runtime_put call in usb_gadget_probe_driver out of is_otg_enabled block. Signed-off-by: Jarkko Nikula jhnik...@gmail.com applied, thanks -- balbi -- 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] mfd: Fix usbhs_enable error handling
On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote: From: Axel Lin axel@gmail.com In the case of missing platform_data we do not hold a spin_lock, thus we should not call spin_unlock_irqrestore in the error path. Also simplify the error handling by separating the successful path from error path. I think this change improves readability. Signed-off-by: Axel Lin axel@gmail.com applied, thanks -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:usb: fixing ehci phy gpio values for omap3
On Thu, Apr 21, 2011 at 07:52:42PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The gpio of EHCI phy should be 0 instead of 1; This fixes the hub enumeration issue in beagle xm board. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com applied, thanks -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:usb: add regulator support for EHCI
On Thu, Apr 21, 2011 at 07:52:43PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com in case of ehci phy mode; regulator of phy should be enabled before initializing the usbhs core driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com applied, thanks -- balbi -- 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] usb: musb: am35x: fix compile error when building am35x
am35x_musb_set_mode() was redefined. Fix it.
Reported-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/plat-omap/include/plat/usb.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index ce7d5e6..d8a0484 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -396,7 +396,7 @@ static struct omap_musb_board_data musb_board_data = {
.power = 500,
.set_phy_power = am35x_musb_phy_power,
.clear_irq = am35x_musb_clear_irq,
- .set_mode = am35x_musb_set_mode,
+ .set_mode = am35x_set_mode,
.reset = am35x_musb_reset,
};
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 05f6abc..eff6e24 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -228,7 +228,7 @@ void am35x_musb_clear_irq(void)
regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
}
-void am35x_musb_set_mode(u8 musb_mode)
+void am35x_set_mode(u8 musb_mode)
{
u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 02b96c8..17d3c93 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -113,7 +113,7 @@ extern int omap4430_phy_suspend(struct device *dev, int
suspend);
extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
-extern void am35x_musb_set_mode(u8 musb_mode);
+extern void am35x_set_mode(u8 musb_mode);
/*
* FIXME correct answer depends on hmc_mode,
--
1.7.4.1.343.ga91df
--
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: USB-ehci enumeration issue
Hi, On Fri, Apr 15, 2011 at 05:44:44PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, I tried to test ehci based in 2.6.39 rc2 + reverts commit 09173b589d547c002b6a2b560e150c4d7bb56c99. I connected a HS device to HS-USB1 and find it's trying to enumerate the device as FS and fails. / # [ 25.171356] usb usb1: usb wakeup-resume [ 25.175689] usb usb1: usb auto-resume [ 25.179565] ehci-omap ehci-omap.0: resume root hub [ 25.226654] hub 1-0:1.0: hub_resume [ 25.230346] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT [ 25.239654] hub 1-0:1.0: port 1: status 0501 change 0001 [ 25.351806] hub 1-0:1.0: state 7 ports 3 chg 0002 evt [ 25.357604] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s [ 25.421966] ehci-omap ehci-omap.0: port 1 full speed -- companion [ 25.428436] ehci-omap ehci-omap.0: GetStatus port:1 status 003801 0 ACK POWER OWNER sig=j CONNECT [ 25.437866] hub 1-0:1.0: port 1 not reset yet, waiting 50ms [ 25.500030] ehci-omap ehci-omap.0: GetStatus port:1 status 003002 0 ACK POWER OWNER sig=se0 CSC [ 25.509399] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 25.515838] hub 1-0:1.0: state 7 ports 3 chg evt 0002 [ 27.976806] hub 1-0:1.0: hub_suspend [ 27.980590] usb usb1: bus auto-suspend [ 27.984527] ehci-omap ehci-omap.0: suspend root hub Does anyone else observe this issue? could be the regulators problem. Can you try with my hci branch ? git://gitorious.org/usb/usb.git hci -- balbi -- 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/2] OMAP: DSS: Support new dpi panels
Hi all, These patches add support for two new panels to the generic-dpi-panel. The first patch adds support for the Seiko 70WVW1TZ3 LCD panel, and the second adds support for the Powertip PH480272T LCD panel. Tested with an IGEP v2 board. Please consider to add in next merge window, thanks, Enric Balletbo i Serra (2): OMAP: DSS2: Support for Seiko 70WVW1TZ3 OMAP: DSS2: Support for Powertip PH480272T drivers/video/omap2/displays/panel-generic-dpi.c | 50 ++ 1 files changed, 50 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP: DSS2: Support for Seiko 70WVW1TZ3
Add support for Seiko 70WVW1TZ3, a LCD 7.0inch WVGA (800x480) display
type with 24-bit RGB interface and Touch-Panel, to panel-generic-dpi.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 4a9b9ff..e8819ee 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -181,6 +181,31 @@ static struct panel_config generic_dpi_panels[] = {
.power_off_delay= 0,
.name = samsung_lte430wq_f0c,
},
+
+ /* Seiko 70WVW1TZ3Z3 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock= 33000,
+
+ .hsw= 128,
+ .hfp= 10,
+ .hbp= 10,
+
+ .vsw= 2,
+ .vfp= 4,
+ .vbp= 11,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = 70wvw1tz3,
+ },
};
struct panel_drv_data {
--
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] OMAP: DSS2: Support for Powertip PH480272T
Add support for Powertip PH480242T, a LCD 4.3inch (480x242) display
type with 24-bit RGB interface, to panel-generic-dpi.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index e8819ee..3250a85 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -206,6 +206,31 @@ static struct panel_config generic_dpi_panels[] = {
.power_off_delay= 0,
.name = 70wvw1tz3,
},
+
+ /* Powertip PH480272T */
+ {
+ {
+ .x_res = 480,
+ .y_res = 272,
+
+ .pixel_clock= 9000,
+
+ .hsw= 40,
+ .hfp= 2,
+ .hbp= 2,
+
+ .vsw= 10,
+ .vfp= 2,
+ .vbp= 2,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IEO,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = ph480272t,
+ },
};
struct panel_drv_data {
--
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: [PATCH 1/2] OMAP3: ISP: Add regulator control for omap34xx
Hi,
-Original Message-
From: ext Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: 29. huhtikuuta 2011 12:49
To: Jokiniemi Kalle (Nokia-SD/Tampere)
Cc: t...@atomide.com; mche...@infradead.org; linux-
o...@vger.kernel.org; linux-me...@vger.kernel.org
Subject: Re: [PATCH 1/2] OMAP3: ISP: Add regulator control for omap34xx
Hi Kalle,
On Friday 29 April 2011 09:11:59 Kalle Jokiniemi wrote:
The current omap3isp driver is missing regulator handling
for CSIb complex in omap34xx based devices. This patch
adds a mechanism for this to the omap3isp driver.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
Thanks for the patch.
Sent an updated one, comments on what was done below.
The CSIb pins are multiplexed with the parallel interface cam_d[6:9] signals,
so the driver might need to handle the vdds_csib regulator for the parallel
interface as well. We can leave that out now though, as I'm not sure we'll
ever see a platform that will require that.
---
drivers/media/video/omap3isp/ispccp2.c | 24
+++-
drivers/media/video/omap3isp/ispccp2.h |1 +
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c index 0e16cab..3b17b0d 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/uaccess.h
+#include linux/regulator/consumer.h
#include isp.h
#include ispreg.h
@@ -163,6 +164,9 @@ static void ccp2_if_enable(struct isp_ccp2_device
*ccp2, u8 enable) struct isp_pipeline *pipe =
to_isp_pipeline(ccp2-subdev.entity); int i;
+ if (enable ccp2-vdds_csib)
+ regulator_enable(ccp2-vdds_csib);
+
/* Enable/Disable all the LCx channels */
for (i = 0; i CCP2_LCx_CHANS_NUM; i++)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCP2,
ISPCCP2_LCx_CTRL(i),
@@ -186,6 +190,8 @@ static void ccp2_if_enable(struct isp_ccp2_device
*ccp2, u8 enable) ISPCCP2_LC01_IRQENABLE,
ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ);
}
If you resubmit the patch to address the comments below, please add a blank
line here.
Done.
+ if (!enable ccp2-vdds_csib)
+ regulator_disable(ccp2-vdds_csib);
}
/*
@@ -1137,6 +1143,10 @@ error:
*/
void omap3isp_ccp2_cleanup(struct isp_device *isp)
{
+ struct isp_ccp2_device *ccp2 = isp-isp_ccp2;
+
+ if (isp-revision == ISP_REVISION_2_0)
+ regulator_put(ccp2-vdds_csib);
What about testing ccp2-vdds_csib != NULL here like you do above ? Not all
ES2.0 platforms will use a regulator, so you can end up calling
regulator_put(NULL). regulator_put() will return immediately, but the API
doesn't allow it explictly either.
If regulator_put(NULL) is deemed to be safe, I would remove the revision
check
here. If it isn't, I would replace it with a ccp2-vdds_csib != NULL check.
Regulator_put checks for NULL, so it's safe to call always.
}
/*
@@ -1155,10 +1165,22 @@ int omap3isp_ccp2_init(struct isp_device *isp)
* the CSI2c or CSI2a receivers. The PHY then needs to be explicitly
* configured.
*
+ * On the OMAP34xx the CSI1/CCB is operated in the CSIb IO complex,
CSI1/CCB ? Do you mean CCP ?
The OMAP34xx has no CCP2 support anyway, so I would s,CSI1/CCB,CSI1
receiver,.
Done.
+ * which is powered by vdds_csib power rail. Hence the request for
+ * the regulator.
+ *
* TODO: Don't hardcode the usage of PHY1 (shared with CSI2c).
*/
- if (isp-revision == ISP_REVISION_15_0)
+ if (isp-revision == ISP_REVISION_15_0) {
ccp2-phy = isp-isp_csiphy1;
+ } else if (isp-revision == ISP_REVISION_2_0) {
+ ccp2-vdds_csib = regulator_get(isp-dev, vdds_csib);
+ if (IS_ERR(ccp2-vdds_csib)) {
+ dev_dbg(isp-dev,
+ Could not get regulator vdds_csib\n);
+ ccp2-vdds_csib = NULL;
+ }
+ }
If you resubmit your patch to address the above comments, could you please
reorder the code (and the comment) here and put the ES2.0 check before the
15.0 ?
Done for both the code and comments.
- Kalle
ret = ccp2_init_entities(ccp2);
if (ret 0)
diff --git a/drivers/media/video/omap3isp/ispccp2.h
b/drivers/media/video/omap3isp/ispccp2.h index 5505a86..6674e9d 100644
--- a/drivers/media/video/omap3isp/ispccp2.h
+++ b/drivers/media/video/omap3isp/ispccp2.h
@@ -81,6 +81,7 @@ struct isp_ccp2_device {
struct isp_interface_mem_config mem_cfg;
struct isp_video video_in;
struct isp_csiphy *phy;
+ struct regulator *vdds_csib;
unsigned int error;
Re: [PATCH] omap:usb: fixing ehci phy gpio values for omap3
On Mon, May 2, 2011 at 3:08 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Apr 21, 2011 at 07:52:42PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The gpio of EHCI phy should be 0 instead of 1; This fixes the hub enumeration issue in beagle xm board. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com applied, thanks -- balbi Thanks balbi but ,.his patch is was made by Juergen Kilb ( patch description and link is given below); But I was not aware of it and reinvented wheel with beagle-xm board :( So, Juergen Kilb is the first author of this patch. Here is the link : http://www.mail-archive.com/linux-omap@vger.kernel.org/msg48215.html omap:usbhs:Fixed gpio polarity of gpio USB-phy reset With commit 19403165 a main part of ehci-omap.c moved to drivers/mfd/omap-usb-host.c created by commit 17cdd29d. Due to this reorganisation the polarity used to reset the external USB phy changed and USB host doesn't recognize any devices. Signed-off-by: Juergen Kilb j.k...@phytec.de -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:usb: fixing ehci phy gpio values for omap3
On Mon, May 02, 2011 at 05:01:05PM +0530, Munegowda, Keshava wrote: On Mon, May 2, 2011 at 3:08 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Apr 21, 2011 at 07:52:42PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The gpio of EHCI phy should be 0 instead of 1; This fixes the hub enumeration issue in beagle xm board. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com applied, thanks -- balbi Thanks balbi but ,.his patch is was made by Juergen Kilb ( patch description and link is given below); But I was not aware of it and reinvented wheel with beagle-xm board :( So, Juergen Kilb is the first author of this patch. Here is the link : http://www.mail-archive.com/linux-omap@vger.kernel.org/msg48215.html omap:usbhs:Fixed gpio polarity of gpio USB-phy reset With commit 19403165 a main part of ehci-omap.c moved to drivers/mfd/omap-usb-host.c created by commit 17cdd29d. Due to this reorganisation the polarity used to reset the external USB phy changed and USB host doesn't recognize any devices. Signed-off-by: Juergen Kilb j.k...@phytec.de I sent a pull request to Greg with that patch in, so it looks like Samuel also didn't send this patch before. Can you reply to the pull request I sent saying that this patch should be dropped just so Greg knows and I recreate the branch and send another pull request ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:usb: fixing ehci phy gpio values for omap3
On Mon, May 2, 2011 at 5:24 PM, Felipe Balbi ba...@ti.com wrote: On Mon, May 02, 2011 at 05:01:05PM +0530, Munegowda, Keshava wrote: On Mon, May 2, 2011 at 3:08 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Apr 21, 2011 at 07:52:42PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com The gpio of EHCI phy should be 0 instead of 1; This fixes the hub enumeration issue in beagle xm board. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com applied, thanks -- balbi Thanks balbi but ,.his patch is was made by Juergen Kilb ( patch description and link is given below); But I was not aware of it and reinvented wheel with beagle-xm board :( So, Juergen Kilb is the first author of this patch. Here is the link : http://www.mail-archive.com/linux-omap@vger.kernel.org/msg48215.html omap:usbhs:Fixed gpio polarity of gpio USB-phy reset With commit 19403165 a main part of ehci-omap.c moved to drivers/mfd/omap-usb-host.c created by commit 17cdd29d. Due to this reorganisation the polarity used to reset the external USB phy changed and USB host doesn't recognize any devices. Signed-off-by: Juergen Kilb j.k...@phytec.de I sent a pull request to Greg with that patch in, so it looks like Samuel also didn't send this patch before. Can you reply to the pull request I sent saying that this patch should be dropped just so Greg knows and I recreate the branch and send another pull request ? -- balbi yes Balbi, I have send a mail to Greg. once again, I am sorry , this patch came in 14th april and i was returning from ELC-2011. I missed it. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] OMAP3: ISP: Add regulator control for omap34xx
Hi Kalle,
Thanks for the patch.
On Monday 02 May 2011 11:16:16 Kalle Jokiniemi wrote:
The current omap3isp driver is missing regulator handling
for CSIb complex in omap34xx based devices. This patch
adds a mechanism for this to the omap3isp driver.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/ispccp2.c | 27 +--
drivers/media/video/omap3isp/ispccp2.h |1 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c index 0e16cab..ec9e395 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -30,6 +30,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/uaccess.h
+#include linux/regulator/consumer.h
#include isp.h
#include ispreg.h
@@ -163,6 +164,9 @@ static void ccp2_if_enable(struct isp_ccp2_device
*ccp2, u8 enable) struct isp_pipeline *pipe =
to_isp_pipeline(ccp2-subdev.entity); int i;
+ if (enable ccp2-vdds_csib)
+ regulator_enable(ccp2-vdds_csib);
+
/* Enable/Disable all the LCx channels */
for (i = 0; i CCP2_LCx_CHANS_NUM; i++)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCP2, ISPCCP2_LCx_CTRL(i),
@@ -186,6 +190,9 @@ static void ccp2_if_enable(struct isp_ccp2_device
*ccp2, u8 enable) ISPCCP2_LC01_IRQENABLE,
ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ);
}
+
+ if (!enable ccp2-vdds_csib)
+ regulator_disable(ccp2-vdds_csib);
}
/*
@@ -1137,6 +1144,9 @@ error:
*/
void omap3isp_ccp2_cleanup(struct isp_device *isp)
{
+ struct isp_ccp2_device *ccp2 = isp-isp_ccp2;
+
+ regulator_put(ccp2-vdds_csib);
}
/*
@@ -1151,14 +1161,27 @@ int omap3isp_ccp2_init(struct isp_device *isp)
init_waitqueue_head(ccp2-wait);
- /* On the OMAP36xx, the CCP2 uses the CSI PHY1 or PHY2, shared with
+ /*
+ * On the OMAP34xx the CSI1 receiver is operated in the CSIb IO
+ * complex, which is powered by vdds_csib power rail. Hence the
+ * request for the regulator.
+ *
+ * On the OMAP36xx, the CCP2 uses the CSI PHY1 or PHY2, shared with
* the CSI2c or CSI2a receivers. The PHY then needs to be explicitly
* configured.
*
* TODO: Don't hardcode the usage of PHY1 (shared with CSI2c).
*/
- if (isp-revision == ISP_REVISION_15_0)
+ if (isp-revision == ISP_REVISION_2_0) {
+ ccp2-vdds_csib = regulator_get(isp-dev, vdds_csib);
+ if (IS_ERR(ccp2-vdds_csib)) {
+ dev_dbg(isp-dev,
+ Could not get regulator vdds_csib\n);
+ ccp2-vdds_csib = NULL;
+ }
+ } else if (isp-revision == ISP_REVISION_15_0) {
ccp2-phy = isp-isp_csiphy1;
+ }
ret = ccp2_init_entities(ccp2);
if (ret 0)
diff --git a/drivers/media/video/omap3isp/ispccp2.h
b/drivers/media/video/omap3isp/ispccp2.h index 5505a86..6674e9d 100644
--- a/drivers/media/video/omap3isp/ispccp2.h
+++ b/drivers/media/video/omap3isp/ispccp2.h
@@ -81,6 +81,7 @@ struct isp_ccp2_device {
struct isp_interface_mem_config mem_cfg;
struct isp_video video_in;
struct isp_csiphy *phy;
+ struct regulator *vdds_csib;
unsigned int error;
enum isp_pipeline_stream_state state;
wait_queue_head_t wait;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi Kalle,
On Monday 02 May 2011 11:16:17 Kalle Jokiniemi wrote:
The RX-51 uses the CSIb IO complex for camera operation. The
board file is missing definition for the regulator supplying
the CSIb complex, so this is added for better power
management.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c index bbcb677..1324ba3
100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -337,6 +337,13 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
static struct regulator_consumer_supply rx51_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
+static struct regulator_consumer_supply rx51_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(vdds_csib, omap3isp),
+ {
+ .supply = vaux2,
+ },
Just for my curiosity, what is the the second consumer supply (vaux2) for ?
+};
+
static struct regulator_consumer_supply rx51_vaux3_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
@@ -400,6 +407,8 @@ static struct regulator_init_data rx51_vaux2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vaux2_supplies),
+ .consumer_supplies = rx51_vaux2_supplies,
};
/* VAUX3 - adds more power to VIO_18 rail */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] omap: cleanup board files
ping? On Mon, Apr 25, 2011 at 1:09 PM, Mike Rapoport m...@compulab.co.il wrote: Hi Tony, These patches cleanup some of the common code in the board files. The changes are basically almost mechanically move the code shared among several boards into some common place. There are a lot of places for further improvement, especially DSS and TWL initialization. I'll try to find some time to sort these out as well. Special thanks to Igor Grinberg for the original idea :) Mike Rapoport (4): omap: consolidate touch screen initialization among different boards omap: use common initialization for PMIC i2c bus omap: move detection of NAND CS to common-board-devices omap: musb: introduce default baord config arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/board-2430sdp.c | 20 +--- arch/arm/mach-omap2/board-3430sdp.c | 85 ++- arch/arm/mach-omap2/board-4430sdp.c | 16 +--- arch/arm/mach-omap2/board-cm-t35.c | 78 +- arch/arm/mach-omap2/board-devkit8000.c | 119 + arch/arm/mach-omap2/board-igep0020.c | 23 + arch/arm/mach-omap2/board-igep0030.c | 21 +--- arch/arm/mach-omap2/board-ldp.c | 77 +- arch/arm/mach-omap2/board-omap3beagle.c | 66 +--- arch/arm/mach-omap2/board-omap3evm.c | 72 + arch/arm/mach-omap2/board-omap3logic.c | 13 +-- arch/arm/mach-omap2/board-omap3pandora.c | 69 +--- arch/arm/mach-omap2/board-omap3stalker.c | 78 +- arch/arm/mach-omap2/board-omap3touchbook.c | 101 ++ arch/arm/mach-omap2/board-omap4panda.c | 17 +--- arch/arm/mach-omap2/board-overo.c | 108 +-- arch/arm/mach-omap2/board-rm680.c | 21 +--- arch/arm/mach-omap2/board-rx51-peripherals.c | 13 +-- arch/arm/mach-omap2/board-zoom-peripherals.c | 21 +--- arch/arm/mach-omap2/common-board-devices.c | 148 ++ arch/arm/mach-omap2/common-board-devices.h | 52 + arch/arm/mach-omap2/usb-musb.c | 14 +++- 23 files changed, 293 insertions(+), 941 deletions(-) create mode 100644 arch/arm/mach-omap2/common-board-devices.c create mode 100644 arch/arm/mach-omap2/common-board-devices.h -- 1.7.3.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
Re: [PATCH 4/4] omap: musb: introduce default baord config
* Oleg Drokin gr...@linuxhacker.ru [110428 09:33]:
Hello!
On Apr 28, 2011, at 12:28 PM, Russell King - ARM Linux wrote:
mm, it looks to me like we're ending up with two layers on top of
each other, both trying to provide some kind of generic board interface.
I think they should be squashed together. And that:
static struct musb_hdrc_platform_data musb_plat = {
#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
.mode = MUSB_HOST,
#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
.mode = MUSB_PERIPHERAL,
#endif
in usb-musb.c needs the same treatment as I mentioned in the previous
message if it really is board specific. If not, I see no reason why
the above can't go into the musb driver itself.
In the end it's chip dependent. And the musb can work in all three modes.
Of course the board dictates if the power is supplied to the bus in host
mode and such, but even that could be worked around as nokia 9x0 saga for
USB host shows.
So to me it looks like something totally in realm of musb driver itself.
Nothing bad happens if you configure your MUSB as say OTG while in fact only
peripheral mode was implemented, it continues to work as it did.
Of course enabling HOST mode may not magically make things work, but
I suspect this could be addressed from Kconfig itself instead.
Now I totally expect musb maintainer to jump in and explain
how many misconceptions I have ;)
As far as I remember MUSB always relies on the OTG hardware to enable
the host mode.. So I don't even know if the driver is usable with
host only configuration. And for the peripheral mode, it should be
possible to have OTG enabled, for cert testing some strings need
to be changed in that case for peripheral only configuration.
I think Felipe already has some patches to remove the various Kconfig
options for musb? In any case, the musb configuration should be a
runtime configuration passed in the platform data or cmdline.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] omap: cleanup board files
* Mike Rapoport m...@compulab.co.il [110502 06:54]: ping? Looks OK to me, let's wait on Felipe's comments on the musb related stuff. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v2] AM35xx-Craneboard: USB EHCI: Fix USB ECHI PHY reset
From: Srinath.R srin...@mistralsolutions.com
This patch fixes the EHCI PHY reset issue found on CraneBoard.
History:
https://patchwork.kernel.org/patch/740741/
Signed-off-by: Srinath.R srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index a890d24..05867b5 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -60,7 +60,7 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
+ .phy_reset = false,
.reset_gpio_port[0] = GPIO_USB_NRESET,
.reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL
--
1.5.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
On Mon, May 02, 2011 at 07:20:52AM -0700, Tony Lindgren wrote:
* Oleg Drokin gr...@linuxhacker.ru [110428 09:33]:
Hello!
On Apr 28, 2011, at 12:28 PM, Russell King - ARM Linux wrote:
mm, it looks to me like we're ending up with two layers on top of
each other, both trying to provide some kind of generic board interface.
I think they should be squashed together. And that:
static struct musb_hdrc_platform_data musb_plat = {
#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
.mode = MUSB_HOST,
#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
.mode = MUSB_PERIPHERAL,
#endif
in usb-musb.c needs the same treatment as I mentioned in the previous
message if it really is board specific. If not, I see no reason why
the above can't go into the musb driver itself.
In the end it's chip dependent. And the musb can work in all three modes.
Of course the board dictates if the power is supplied to the bus in host
mode and such, but even that could be worked around as nokia 9x0 saga for
USB host shows.
So to me it looks like something totally in realm of musb driver itself.
Nothing bad happens if you configure your MUSB as say OTG while in fact only
peripheral mode was implemented, it continues to work as it did.
Of course enabling HOST mode may not magically make things work, but
I suspect this could be addressed from Kconfig itself instead.
Now I totally expect musb maintainer to jump in and explain
how many misconceptions I have ;)
As far as I remember MUSB always relies on the OTG hardware to enable
the host mode.. So I don't even know if the driver is usable with
host only configuration. And for the peripheral mode, it should be
yes, it is :-)
possible to have OTG enabled, for cert testing some strings need
to be changed in that case for peripheral only configuration.
I think Felipe already has some patches to remove the various Kconfig
options for musb? In any case, the musb configuration should be a
runtime configuration passed in the platform data or cmdline.
Yeah, I'm planning to get rid of all the ifdeferry and always compile it
with HOST and Peripheral support. It's only few extra tens of bytes
anyway. Still, I doubt I can get that done for this merge window, I
already have pending the debugging rework.
--
balbi
--
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] AM35xx-Craneboard:Display: Add DVI and TV Support
From: Srinath.R srin...@mistralsolutions.com
Added Display (DVI and TV) support for CraneBoard.
History:
https://patchwork.kernel.org/patch/740761/
Signed-off-by: Srinath.R srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 73 +++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 05867b5..26fa565 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -29,12 +29,15 @@
#include plat/board.h
#include plat/common.h
#include plat/usb.h
+#include plat/display.h
+#include plat/panel-generic-dpi.h
#include mux.h
#include control.h
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET38
+#define GPIO_DVI_ENABLE52
/* Board initialization */
@@ -66,11 +69,78 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata
= {
.reset_gpio_port[2] = -EINVAL
};
+static void __init am3517_crane_display_init(void)
+{
+ int ret;
+
+ ret = omap_mux_init_gpio(GPIO_DVI_ENABLE, OMAP_PIN_OUTPUT);
+ if (ret 0) {
+ pr_err(Can not configure mux for GPIO_DVI_ENABLE %d\n,
+ GPIO_DVI_ENABLE);
+ return;
+ }
+
+ ret = gpio_request_one(GPIO_DVI_ENABLE, GPIOF_OUT_INIT_HIGH,
+ dvi_enable);
+ if (ret 0) {
+ pr_err(Can not request GPIO %d\n, GPIO_DVI_ENABLE);
+ return;
+ }
+
+}
+
+static struct omap_dss_device am3517_crane_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = tv,
+ .driver_name= venc,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+ .platform_enable= NULL,
+ .platform_disable = NULL,
+};
+
+static int am3517_crane_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 1);
+ return 0;
+}
+
+static void am3517_crane_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(GPIO_DVI_ENABLE, 0);
+}
+
+
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= am3517_crane_panel_enable_dvi,
+ .platform_disable = am3517_crane_panel_disable_dvi,
+};
+
+static struct omap_dss_device am3517_crane_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = dvi,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
+ .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *am3517_crane_dss_devices[] = {
+ am3517_crane_tv_device,
+ am3517_crane_dvi_device,
+};
+
+static struct omap_dss_board_info am3517_crane_dss_data = {
+ .num_devices= ARRAY_SIZE(am3517_crane_dss_devices),
+ .devices= am3517_crane_dss_devices,
+ .default_device = am3517_crane_dvi_device,
+};
+
static void __init am3517_crane_init(void)
{
int ret;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_display_init(am3517_crane_dss_data);
omap_serial_init();
omap_board_config = am3517_crane_config;
@@ -103,6 +173,9 @@ static void __init am3517_crane_init(void)
}
usbhs_init(usbhs_bdata);
+
+ /* DSS */
+ am3517_crane_display_init();
}
MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
--
1.5.3.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
smsc911x: regression on overo platform
introduced by: 6629398945426f388d61392eecd76a6316a4 environment: OMAP3503, Gumstix Overo, linux-omap-2.6.39-rc5 kernel .config @ http://pastebin.com/QESCFb6j Thank you for looking into it. [0.205139] kobject (c04ce3a8): tried to init an initialized object, something is seriously wrong. [0.205200] [c004258c] (unwind_backtrace+0x0/0xe4) from [c01d1794] (kobject_init+0x38/0x70) [0.205261] [c01d1794] (kobject_init+0x38/0x70) from [c0213dd4] (device_initialize+0x20/0xa4) [0.205322] [c0213dd4] (device_initialize+0x20/0xa4) from [c02179a0] (platform_device_register+0x10/0x1c) [0.205383] [c02179a0] (platform_device_register+0x10/0x1c) from [c00128f4] (gpmc_smsc911x_init+0x110/0x184) [0.205413] [c00128f4] (gpmc_smsc911x_init+0x110/0x184) from [c0011cdc] (overo_init+0xe8/0x32c) [0.205444] [c0011cdc] (overo_init+0xe8/0x32c) from [c000b19c] (customize_machine+0x1c/0x28) [0.205505] [c000b19c] (customize_machine+0x1c/0x28) from [c00333b4] (do_one_initcall+0x98/0x16c) [0.205535] [c00333b4] (do_one_initcall+0x98/0x16c) from [c0008388] (kernel_init+0x8c/0x13c) [0.205566] [c0008388] (kernel_init+0x8c/0x13c) from [c003dd38] (kernel_thread_exit+0x0/0x8) [0.205627] [ cut here ] [0.205657] WARNING: at kernel/resource.c:491 __insert_resource+0x44/0x12c() [0.205688] Modules linked in: [0.205718] [c004258c] (unwind_backtrace+0x0/0xe4) from [c0065428] (warn_slowpath_common+0x4c/0x64) [0.205749] [c0065428] (warn_slowpath_common+0x4c/0x64) from [c0065458] (warn_slowpath_null+0x18/0x1c) [0.205810] [c0065458] (warn_slowpath_null+0x18/0x1c) from [c006bd64] (__insert_resource+0x44/0x12c) [0.205841] [c006bd64] (__insert_resource+0x44/0x12c) from [c006bfc0] (insert_resource_conflict+0x24/0x3c) [0.205871] [c006bfc0] (insert_resource_conflict+0x24/0x3c) from [c006bfe0] (insert_resource+0x8/0x14) [0.205902] [c006bfe0] (insert_resource+0x8/0x14) from [c02178e4] (platform_device_add+0xb4/0x160) [0.205963] [c02178e4] (platform_device_add+0xb4/0x160) from [c00128f4] (gpmc_smsc911x_init+0x110/0x184) [0.205993] [c00128f4] (gpmc_smsc911x_init+0x110/0x184) from [c0011cdc] (overo_init+0xe8/0x32c) [0.206024] [c0011cdc] (overo_init+0xe8/0x32c) from [c000b19c] (customize_machine+0x1c/0x28) [0.206085] [c000b19c] (customize_machine+0x1c/0x28) from [c00333b4] (do_one_initcall+0x98/0x16c) [0.206115] [c00333b4] (do_one_initcall+0x98/0x16c) from [c0008388] (kernel_init+0x8c/0x13c) [0.206146] [c0008388] (kernel_init+0x8c/0x13c) from [c003dd38] (kernel_thread_exit+0x0/0x8) [0.206542] ---[ end trace 1b75b31a2719ed1c ]--- [0.206573] smsc911x: failed to claim resource 0 [0.206573] Unable to register smsc911x device [0.206604] [ cut here ] [0.206634] WARNING: at drivers/gpio/gpiolib.c:1236 gpmc_smsc911x_init+0x130/0x184() [0.206634] Modules linked in: [0.206665] [c004258c] (unwind_backtrace+0x0/0xe4) from [c0065428] (warn_slowpath_common+0x4c/0x64) [0.206726] [c0065428] (warn_slowpath_common+0x4c/0x64) from [c0065458] (warn_slowpath_null+0x18/0x1c) [0.206756] [c0065458] (warn_slowpath_null+0x18/0x1c) from [c0012914] (gpmc_smsc911x_init+0x130/0x184) [0.206787] [c0012914] (gpmc_smsc911x_init+0x130/0x184) from [c0011cdc] (overo_init+0xe8/0x32c) [0.206848] [c0011cdc] (overo_init+0xe8/0x32c) from [c000b19c] (customize_machine+0x1c/0x28) [0.206878] [c000b19c] (customize_machine+0x1c/0x28) from [c00333b4] (do_one_initcall+0x98/0x16c) [0.206909] [c00333b4] (do_one_initcall+0x98/0x16c) from [c0008388] (kernel_init+0x8c/0x13c) [0.206939] [c0008388] (kernel_init+0x8c/0x13c) from [c003dd38] (kernel_thread_exit+0x0/0x8) [0.206970] ---[ end trace 1b75b31a2719ed1d ]--- [0.207031] Could not initialize smsc911x -- 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 3/7] OMAP: DSS: Adding a picodlp panel driver
From: Mythri P K mythr...@ti.com
A projector panel named picodlp is supported by OMAP.
panel driver is required to be added with the name picodlp_panel.
It is a WVGA panel with resolution 864 X 480 and panel timing data
is defined in the panel driver.
picodlp makes use of parallel (DPI) interface multiplexed with secondary lcd
in case of OMAP4.
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
Changes since v1:
1. Removed msleep
drivers/video/omap2/displays/panel-picodlp.c | 226 ++
1 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
new file mode 100644
index 000..e83e399
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -0,0 +1,226 @@
+/*
+ * picodlp panel driver
+ *
+ * Copyright (C) 2009-2011 Texas Instruments
+ * Author: Mythri P K mythr...@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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/input.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/firmware.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/delay.h
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+struct picodlp_data {
+ struct mutex lock;
+};
+
+static struct omap_video_timings pico_ls_timings = {
+ .x_res = 864,
+ .y_res = 480,
+ .hsw= 7,
+ .hfp= 11,
+ .hbp= 7,
+
+ .pixel_clock= 19200,
+
+ .vsw= 2,
+ .vfp= 3,
+ .vbp= 14,
+};
+
+static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ if (dssdev-platform_enable) {
+ r = dssdev-platform_enable(dssdev);
+ if (r)
+ return r;
+ }
+
+ r = omapdss_dpi_display_enable(dssdev);
+ if (r) {
+ dev_err(dssdev-dev, failed to enable DPI\n);
+ goto err;
+ }
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ return 0;
+
+err:
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+
+ return r;
+}
+
+static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
+{
+ omapdss_dpi_display_disable(dssdev);
+
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int picodlp_panel_probe(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod;
+
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_ONOFF |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IVS;
+ dssdev-panel.acb = 0x0;
+ dssdev-panel.timings = pico_ls_timings;
+
+ picod = kzalloc(sizeof(struct picodlp_data), GFP_KERNEL);
+ if (!picod)
+ return -ENOMEM;
+
+ mutex_init(picod-lock);
+ dev_set_drvdata(dssdev-dev, picod);
+ return 0;
+}
+
+static void picodlp_panel_remove(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+ dev_set_drvdata(dssdev-dev, NULL);
+ dev_dbg(dssdev-dev, removing picodlp panel\n);
+ kfree(picod);
+}
+
+static int picodlp_panel_enable(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+ int r;
+
+ dev_dbg(dssdev-dev, enabling picodlp panel\n);
+
+ mutex_lock(picod-lock);
+ if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
+ mutex_unlock(picod-lock);
+ return -EINVAL;
+ }
+
+ r = picodlp_panel_power_on(dssdev);
+ mutex_unlock(picod-lock);
+
+ return r;
+}
+
+static void picodlp_panel_disable(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+ mutex_lock(picod-lock);
+ /* Turn off DLP Power */
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
+ picodlp_panel_power_off(dssdev);
+
+ dev_dbg(dssdev-dev, disabling picodlp panel\n);
+ dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
+ mutex_unlock(picod-lock);
+}
+
+static int picodlp_panel_suspend(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+
[PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp
The configurations and data transfer with picodlp panel happens through i2c.
An i2c client with name picodlp_i2c_driver is registered inside panel.
dpp2600 requires 4 gpio lines for interfacing it with any processor,
phy_reset, ready_reset, park, display_select
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v2:
1. Removed unused variable picodlp_i2c_data
2. Removed msleep
checkpatch.pl warning:
WARNING: msleep 20ms can sleep for up to 20ms; see
Documentation/timers/timers-howto.txt
But I think this can be ignored.
drivers/video/omap2/displays/panel-picodlp.c | 126 +-
1 files changed, 121 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index e83e399..fdbfdcf 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -1,8 +1,10 @@
/*
* picodlp panel driver
+ * picodlp_i2c_driver: i2c_client driver
*
* Copyright (C) 2009-2011 Texas Instruments
* Author: Mythri P K mythr...@ti.com
+ * Mayuresh Janorkar ma...@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
@@ -23,13 +25,29 @@
#include linux/firmware.h
#include linux/slab.h
#include linux/mutex.h
+#include linux/i2c.h
#include linux/delay.h
+#include linux/gpio.h
#include plat/display.h
#include plat/panel-picodlp.h
+#define DRIVER_NAMEpicodlp_i2c_driver
struct picodlp_data {
struct mutex lock;
+ struct i2c_client *picodlp_i2c_client;
+};
+
+static struct i2c_board_info picodlp_i2c_board_info = {
+ I2C_BOARD_INFO(picodlp_i2c_driver, 0x1b),
+};
+
+struct picodlp_i2c_data {
+ struct mutex xfer_lock;
+};
+
+struct i2c_device_id picodlp_i2c_id[] = {
+ { picodlp_i2c_driver, 0 },
};
static struct omap_video_timings pico_ls_timings = {
@@ -46,9 +64,56 @@ static struct omap_video_timings pico_ls_timings = {
.vbp= 14,
};
+static inline struct picodlp_panel_data
+ *get_panel_data(const struct omap_dss_device *dssdev)
+{
+ return (struct picodlp_panel_data *) dssdev-data;
+}
+
+static int picodlp_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct picodlp_i2c_data *picodlp_i2c_data;
+
+ picodlp_i2c_data = kzalloc(sizeof(struct picodlp_i2c_data), GFP_KERNEL);
+
+ if (!picodlp_i2c_data)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, picodlp_i2c_data);
+
+ return 0;
+}
+
+static int picodlp_i2c_remove(struct i2c_client *client)
+{
+ struct picodlp_i2c_data *picodlp_i2c_data =
+ i2c_get_clientdata(client);
+
+ kfree(picodlp_i2c_data);
+ i2c_unregister_device(client);
+ return 0;
+}
+
+static struct i2c_driver picodlp_i2c_driver = {
+ .driver = {
+ .name = picodlp_i2c_driver,
+ },
+ .probe = picodlp_i2c_probe,
+ .remove = picodlp_i2c_remove,
+ .id_table = picodlp_i2c_id,
+};
+
static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
{
- int r;
+ int r = 0;
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+ struct picodlp_panel_data *picodlp_pdata;
+
+ picodlp_pdata = get_panel_data(dssdev);
+ gpio_set_value(picodlp_pdata-display_sel_gpio, 1);
+ gpio_set_value(picodlp_pdata-park_gpio, 1);
+ gpio_set_value(picodlp_pdata-phy_reset_gpio, 1);
if (dssdev-platform_enable) {
r = dssdev-platform_enable(dssdev);
@@ -63,8 +128,7 @@ static int picodlp_panel_power_on(struct omap_dss_device
*dssdev)
}
dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
- return 0;
-
+ return r;
err:
if (dssdev-platform_disable)
dssdev-platform_disable(dssdev);
@@ -83,6 +147,11 @@ static void picodlp_panel_power_off(struct omap_dss_device
*dssdev)
static int picodlp_panel_probe(struct omap_dss_device *dssdev)
{
struct picodlp_data *picod;
+ struct picodlp_panel_data *picodlp_pdata;
+ struct i2c_adapter *adapter;
+ struct i2c_client *picodlp_i2c_client;
+ struct picodlp_i2c_data *picodlp_i2c_data;
+ int r = 0, picodlp_adapter_id;
dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_ONOFF |
OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IVS;
@@ -94,8 +163,36 @@ static int picodlp_panel_probe(struct omap_dss_device
*dssdev)
return -ENOMEM;
mutex_init(picod-lock);
+
+ picodlp_pdata = get_panel_data(dssdev);
+ picodlp_adapter_id = picodlp_pdata-picodlp_adapter_id;
+
+ adapter = i2c_get_adapter(picodlp_adapter_id);
+ if (!adapter) {
+ dev_err(dssdev-dev, can't get
[PATCH v2 7/7] OMAP4: DSS: Adding picodlp panel entry in Kconfig and Makefile
From: Mythri P K mythr...@ti.com A new panel picodlp for OMAP4 has been introduced picodlp is a projector available on OMAP4430SDP and EVM platforms. Signed-off-by: Mythri P K mythr...@ti.com Signed-off-by: Mayuresh Janorkar ma...@ti.com --- Changes since v1: Nil drivers/video/omap2/displays/Kconfig |7 +++ drivers/video/omap2/displays/Makefile |1 + 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index 609a280..0b05593 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -30,6 +30,13 @@ config PANEL_NEC_NL8048HL11_01B This NEC NL8048HL11-01B panel is TFT LCD used in the Zoom2/3/3630 sdp boards. +config PANEL_PICODLP + tristate OMAP PICO DLP Panel + depends on OMAP2_DSS + help + Projector Panel used in TI's SDP4430 and EVM boards + For more info please visit http://www.dlp.com/projector/ + config PANEL_TAAL tristate Taal DSI Panel depends on OMAP2_DSS_DSI diff --git a/drivers/video/omap2/displays/Makefile b/drivers/video/omap2/displays/Makefile index 0f601ab..d90f73c 100644 --- a/drivers/video/omap2/displays/Makefile +++ b/drivers/video/omap2/displays/Makefile @@ -4,5 +4,6 @@ obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o obj-$(CONFIG_PANEL_TAAL) += panel-taal.o +obj-$(CONFIG_PANEL_PICODLP) += panel-picodlp.o obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o -- 1.7.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 v2 0/7] picodlp projector driver
picodlp projector is supported by OMAP. OMAP4430 SDP and EVM boards have an on board projector called as picodlp projector. picodlp would be connected to display sub system as a display panel. It has a dlp processor dpp2600. The panel would be connected using 24 bit parallel interface. It is a WVGA panel with 864 X 480 resolution. To know more about picodlp please visit: http://omappedia.org/wiki/PicoDLP_projector_guide picodlp is muxed with DSI2 so we can either use secondary LCD or picodlp. So the channel used is OMAP_DSS_CHANNEL_LCD2. GPIO pin settings are also required and are done in board file. Configuartion of picodlp involves passing number of commands through i2c. All these commands are defined in a panel header file. About DLP (Digital Light Processing): DLP is Texas Instruments award-winning display technology which has powered the worlds top projectors and displays, delivering pictures rich with color, contrast, clarity and brightness to screens of all sizes. Every DLP chip features an array of up to 2.2 million microscopic mirrors that switch at ultra high speeds an innovative advantage that remains cutting edge and ideal for current and future applications alike. The results are high-resolution, highly reliable, razor-sharp images, that even work with fast motion video. To learn more about DLP technology, please visit www.DLP.com picodlp on OMAP4430 boards would make use of same technology. picodlp makes use of i2c bus device at 0x1b address for sending configuration commands to panel. In software picodlp panel driver has an i2c client. To know more about picodlp configuration commands please visit: http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf The link talks more about the timing specific things: http://focus.ti.com/lit/ds/dlps019b/dlps019b.pdf To know more about i2c_client model please visit: http://lxr.linux.no/#linux+v2.6.38/Documentation/i2c/writing-clients -- These patches have been developed on top of master branch of Tomi's gitorious tree. I am maintaining a gitorious tree for these patches and can be found at: http://gitorious.org/~mayuresh/linux-omap-dss2/mayuresh-picodlp/commits/picodlp The driver has been tested when compiled as a module. Validated with a Penguin logos on OMAP4430 SDP ES2.1 Checkpatch.pl warnings: WARNING: msleep 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt I think this warning can be ignored New compilation warnings introduced: Nil - Mayuresh Janorkar (3): OMAP: DSS: Adding a header file for picodlp panel data OMAP: DSS: Add i2c client driver for picodlp OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file Mythri P K (4): OMAP: DSS: Adding a picodlp panel header file OMAP: DSS: Adding a picodlp panel driver OMAP: DSS: Adding initialization routine to picodlp panel OMAP4: DSS: Adding picodlp panel entry in Kconfig and Makefile arch/arm/mach-omap2/board-4430sdp.c | 40 ++ arch/arm/plat-omap/include/plat/panel-picodlp.h | 25 + drivers/video/omap2/displays/Kconfig|7 + drivers/video/omap2/displays/Makefile |1 + drivers/video/omap2/displays/panel-picodlp.c| 554 +++ drivers/video/omap2/displays/panel-picodlp.h| 287 6 files changed, 914 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/panel-picodlp.h create mode 100644 drivers/video/omap2/displays/panel-picodlp.c create mode 100644 drivers/video/omap2/displays/panel-picodlp.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
[PATCH v2 1/7] OMAP: DSS: Adding a header file for picodlp panel data
picodlp is a TI projector panel supported by OMAP
picodlp makes use of i2c interface for transferring commands to the panel
panel data is required for identifying i2c_adapter id and dlp GPIOs
A new header file has been added for panel data and
picodlp_panel_data struct has been introduced
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
Changes since v1: Nil
arch/arm/plat-omap/include/plat/panel-picodlp.h | 25 +++
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-picodlp.h
diff --git a/arch/arm/plat-omap/include/plat/panel-picodlp.h
b/arch/arm/plat-omap/include/plat/panel-picodlp.h
new file mode 100644
index 000..89ac4b9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-picodlp.h
@@ -0,0 +1,25 @@
+/*
+ * panel data for picodlp panel
+ *
+ * Copyright (C) 2011 Texas Instruments
+ *
+ * Author: Mayuresh Janorkar ma...@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.
+ */
+#ifndef __ARCH_ARM_PLAT_PANEL_PICODLP_H
+#define __ARCH_ARM_PLAT_PANEL_PICODLP_H
+/**
+ * struct : picodlp panel data
+ * picodlp_adapter_id: i2c_adapter number for picodlp
+ */
+struct picodlp_panel_data {
+ int picodlp_adapter_id;
+ int phy_reset_gpio;
+ int ready_reset_gpio;
+ int park_gpio;
+ int display_sel_gpio;
+};
+#endif /* __ARCH_ARM_PLAT_PANEL_PICODLP_H */
--
1.7.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 v2 5/7] OMAP: DSS: Adding initialization routine to picodlp panel
From: Mythri P K mythr...@ti.com
picodlp_i2c_client needs to send commands over i2c as a part of initialiazation.
system controller dlp pico processor dpp2600 is used.
It configures the splash screen of picodlp using a sequence of commands.
A programmer's guide is available at:
http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf
API is defined for sending command over i2c as an i2c_write operation.
Signed-off-by: Mythri P K mythr...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
Changes since v1:
1. Removed initial splash screen
2. i2c_commands regrouped
3. Removed long msleep
4. Added try-after-sleep in i2c_write
drivers/video/omap2/displays/panel-picodlp.c | 212 ++
1 files changed, 212 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
index fdbfdcf..493a411 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -32,7 +32,15 @@
#include plat/display.h
#include plat/panel-picodlp.h
+#include panel-picodlp.h
+
#define DRIVER_NAMEpicodlp_i2c_driver
+
+/* This defines the minit of data which is allowed into single write block */
+#define MAX_I2C_WRITE_BLOCK_SIZE 32
+#define PICO_MAJOR 1 /* 2 bits */
+#define PICO_MINOR 1 /* 2 bits */
+
struct picodlp_data {
struct mutex lock;
struct i2c_client *picodlp_i2c_client;
@@ -50,6 +58,11 @@ struct i2c_device_id picodlp_i2c_id[] = {
{ picodlp_i2c_driver, 0 },
};
+struct picodlp_i2c_command {
+ u8 reg;
+ u32 value;
+};
+
static struct omap_video_timings pico_ls_timings = {
.x_res = 864,
.y_res = 480,
@@ -70,6 +83,197 @@ static inline struct picodlp_panel_data
return (struct picodlp_panel_data *) dssdev-data;
}
+static int picodlp_i2c_write_block(struct i2c_client *client,
+ u8 *data, int len)
+{
+ struct i2c_msg msg;
+ int i, r, msg_count = 1, trial = 4;
+
+ struct picodlp_i2c_data *picodlp_i2c_data = i2c_get_clientdata(client);
+
+ if (len 1 || len MAX_I2C_WRITE_BLOCK_SIZE) {
+ dev_err(client-dev,
+ too long syn_write_block len %d\n, len);
+ return -EIO;
+ }
+retry:
+ mutex_lock(picodlp_i2c_data-xfer_lock);
+
+ msg.addr = client-addr;
+ msg.flags = 0;
+ msg.len = len;
+ msg.buf = data;
+ r = i2c_transfer(client-adapter, msg, msg_count);
+ mutex_unlock(picodlp_i2c_data-xfer_lock);
+
+ /*
+* i2c_transfer returns:
+* number of messages sent in case of success
+* a negative error number in case of failure
+* i2c controller might timeout, in such a case sleep for sometime
+* and then retry
+*/
+ if (r != msg_count) {
+ msleep(2);
+ if (trial--)
+ goto retry;
+
+ dev_err(client-dev, picodlp_i2c_write error\n);
+ return r;
+ }
+
+ /* In case of success */
+ for (i = 0; i len; i++)
+ dev_dbg(client-dev,
+ addr %x bw 0x%02x[%d]: 0x%02x\n,
+ client-addr, data[0] + i, i, data[i]);
+
+ return 0;
+}
+
+static int picodlp_i2c_write(struct i2c_client *client, u8 reg, u32 value)
+{
+ u8 data[5];
+ int i;
+
+ data[0] = reg;
+ for (i = 1; i 5; i++)
+ data[i] = (value (32 - (i) * 8)) 0xFF;
+
+ return picodlp_i2c_write_block(client, data, 5);
+}
+
+static int picodlp_i2c_write_array(struct i2c_client *client,
+ const struct picodlp_i2c_command commands[],
+ int count)
+{
+ int i, r = 0;
+ for (i = 0; i count; i++) {
+ r = picodlp_i2c_write(client, commands[i].reg,
+ commands[i].value);
+ if (r)
+ return r;
+ }
+ return r;
+}
+/**
+ * picodlp_i2c_init: i2c_initialization routine
+ * client: i2c_client for communication
+ *
+ * @return
+ * 0 : Success, no error
+ * error code : Failure
+ */
+static int picodlp_i2c_init(struct i2c_client *client)
+{
+ int r;
+ static const struct picodlp_i2c_command init_cmd_set1[] = {
+ {SOFT_RESET, 1},
+ {DMD_PARK_TRIGGER, 1},
+ {MISC_REG, (PICO_MAJOR 2 | PICO_MINOR)},
+ {SEQ_CONTROL, 0},
+ {SEQ_VECTOR, 0x100},
+ {DMD_BLOCK_COUNT, 7},
+ {DMD_VCC_CONTROL, 0x109},
+ {DMD_PARK_PULSE_COUNT, 0xA},
+ {DMD_PARK_PULSE_WIDTH, 0xB},
+ {DMD_PARK_DELAY, 0x2ED},
+ {DMD_SHADOW_ENABLE, 0},
+ {FLASH_OPCODE, 0xB},
+
[PATCH v2 6/7] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file
An on-board panel named picodlp projector is available for OMAP4430 SDP.
Entry for this panel is being added in dss_devices in the board file.
It also needs 4 GPIO pins and are defined and used in board file.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v1: Removed unnecessary changes
arch/arm/mach-omap2/board-4430sdp.c | 38 +++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 570e83f..979eab7 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
#include plat/omap4-keypad.h
#include plat/display.h
#include plat/nokia-dsi-panel.h
+#include plat/panel-picodlp.h
#include mux.h
#include hsmmc.h
@@ -812,9 +813,45 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.channel = OMAP_DSS_CHANNEL_DIGIT,
};
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+ .picodlp_adapter_id = 2,
+ .phy_reset_gpio = 40,
+ .ready_reset_gpio = 44,
+ .park_gpio = 45,
+ .display_sel_gpio = 59,
+};
+
+static void sdp4430_picodlp_init(void)
+{
+ int status = 0;
+ struct gpio picodlp_gpios[] = {
+ {sdp4430_picodlp_pdata.phy_reset_gpio, GPIOF_OUT_INIT_LOW,
+ DLP PHY RESET},
+ {sdp4430_picodlp_pdata.ready_reset_gpio, GPIOF_IN,
+ DLP REDY RESET},
+ {sdp4430_picodlp_pdata.park_gpio, GPIOF_INIT_LOW, DLP PARK},
+ {sdp4430_picodlp_pdata.display_sel_gpio, GPIOF_OUT_INIT_LOW,
+ DLP DISPLAY SEL},
+ };
+
+ status = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
+ if (status)
+ pr_err(Cannot request OMAP4_DLP_GPIOs, error %d\n, status);
+}
+
+static struct omap_dss_device sdp4430_picodlp_device = {
+ .name = picodlp,
+ .driver_name= picodlp_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .channel= OMAP_DSS_CHANNEL_LCD2,
+ .data = sdp4430_picodlp_pdata,
+};
+
static struct omap_dss_device *sdp4430_dss_devices[] = {
sdp4430_lcd_device,
sdp4430_hdmi_device,
+ sdp4430_picodlp_device,
};
static struct omap_dss_board_info sdp4430_dss_data = {
@@ -827,6 +864,7 @@ void omap_4430sdp_display_init(void)
{
sdp4430_lcd_init();
sdp4430_hdmi_mux_init();
+ sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
}
--
1.7.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
WARNING: at handle_irq_event_percpu
I've got a Gumstix Overo with linux-2.6.39-rc5 (pulled from Sakoman's tree). Every boot I get this message. I'm not sure whether I should be worried about it or not. [1.996582] [ cut here ] [2.001586] WARNING: at kernel/irq/handle.c:130 handle_irq_event_percpu+0xf8/0x220() [2.010101] irq 379 handler twl_rtc_interrupt+0x0/0x94 enabled interrupts [2.017272] Modules linked in: [2.020538] [c00471ec] (unwind_backtrace+0x0/0xe0) from [c006aa4c] (warn_slowpath_common+0x4c/0x64) [2.030456] [c006aa4c] (warn_slowpath_common+0x4c/0x64) from [c006aae4] (warn_slowpath_fmt+0x2c/0x3c) [2.040557] [c006aae4] (warn_slowpath_fmt+0x2c/0x3c) from [c00a5880] (handle_irq_event_percpu+0xf8/0x220) [2.051025] [c00a5880] (handle_irq_event_percpu+0xf8/0x220) from [c00a59e4] (handle_irq_event+0x3c/0x5c) [2.061401] [c00a59e4] (handle_irq_event+0x3c/0x5c) from [c00a76b8] (handle_edge_irq+0x104/0x13c) [2.071166] [c00a76b8] (handle_edge_irq+0x104/0x13c) from [c02a4eb4] (handle_twl4030_sih+0xac/0xd4) [2.081085] [c02a4eb4] (handle_twl4030_sih+0xac/0xd4) from [c02a4d98] (twl4030_irq_thread+0xb4/0x108) [2.091186] [c02a4d98] (twl4030_irq_thread+0xb4/0x108) from [c008546c] (kthread+0x7c/0x84) [2.100311] [c008546c] (kthread+0x7c/0x84) from [c00429b8] (kernel_thread_exit+0x0/0x8) [2.109161] ---[ end trace 041d11a82aa47d13 ]--- There are few differences between `omap2plus_defconfig` and my config (only enough to get it to boot on the overo) I only enable the board features that my board has (and disable everything else) and I turn on devtmpfs : System Type --- TI OMAP2/3/4 Specific Features --- * Typical OMAP configuration * TI OMAP3 * Gumstix Overo Board Device Drivers -- Generic Driver Options --- * Maintain a devtmpfs filesystem to mount at /dev * Automount devtmpfs at /dev, after the kernel mounted the rootfs Also, I'm not loading any modules either. Is this an expected / okay failure? AJ ONeal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi,
-Original Message-
From: ext Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: 2. toukokuuta 2011 16:50
To: Jokiniemi Kalle (Nokia-SD/Tampere)
Cc: mauroche...@gmail.com; t...@atomide.com; linux-
o...@vger.kernel.org; linux-me...@vger.kernel.org
Subject: Re: [PATCH v2 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi Kalle,
On Monday 02 May 2011 11:16:17 Kalle Jokiniemi wrote:
The RX-51 uses the CSIb IO complex for camera operation. The
board file is missing definition for the regulator supplying
the CSIb complex, so this is added for better power
management.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c index bbcb677..1324ba3
100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -337,6 +337,13 @@ static struct omap2_hsmmc_info mmc[] __initdata =
{
static struct regulator_consumer_supply rx51_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
+static struct regulator_consumer_supply rx51_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(vdds_csib, omap3isp),
+ {
+ .supply = vaux2,
+ },
Just for my curiosity, what is the the second consumer supply (vaux2) for ?
I must admit, that I just copied the format from the other regulator
definitions.
No idea really. Maybe those could be removed from the others as well?
- Kalle
+};
+
static struct regulator_consumer_supply rx51_vaux3_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
@@ -400,6 +407,8 @@ static struct regulator_init_data rx51_vaux2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vaux2_supplies),
+ .consumer_supplies = rx51_vaux2_supplies,
};
/* VAUX3 - adds more power to VIO_18 rail */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi,
-Original Message-
From: Jokiniemi Kalle (Nokia-SD/Tampere)
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -337,6 +337,13 @@ static struct omap2_hsmmc_info mmc[] __initdata
=
{
static struct regulator_consumer_supply rx51_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
+static struct regulator_consumer_supply rx51_vaux2_supplies[] = {
+ REGULATOR_SUPPLY(vdds_csib, omap3isp),
+ {
+ .supply = vaux2,
+ },
Just for my curiosity, what is the the second consumer supply (vaux2)
for ?
I must admit, that I just copied the format from the other regulator
definitions.
No idea really. Maybe those could be removed from the others as well?
Now that I looked closer, there's no such thing in the other definitions, I
wonder
where I managed to find that. Maybe it was the older kernel I was using... I'll
update the patch and remove the vaux2 part.
- Kalle
--
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
