Re: USB lockup on OMAP3530
On Thu, Feb 11, 2010 at 7:57 PM, Michael Trimarchi wrote: > > Use an hub with external power and connect the hub to the OTG and the device > to the HUB. > Is it the same? > Uhm... what do you think how I attached a hard disk and a network device to the Beagle's USB OTG port (ONE port) that can only supply 100 mA? Of course I have everything connected to a powered hub that is connected to the OTG port. Note that my bug report is not about USB devices not working at all. -- 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] Input: ads7846: add regulator support
On Sat, Feb 13, 2010 at 09:40:26PM +0200, Mike Rapoport wrote: > On Sat, Feb 13, 2010 at 6:31 PM, Grazvydas Ignotas wrote: > > + ts->reg = regulator_get(&spi->dev, "vcc"); > "vcc" is way too generic name. What about "vcc-ts" or "vcc-touch"? This should be OK as-is - the general style for regulators is to use whatever the name the datasheet gives to the supply. The string used is namespaced using the supplied struct device and isn't connected to the strings used to name the regulator providing the supply so there should be no cause for name collisions. Only supplies for things like CPUs which don't currently have struct devices associated with them have issues with name collisions. -- 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] Input: ads7846: add regulator support
Just one nitpicking comment below:
On Sat, Feb 13, 2010 at 6:31 PM, Grazvydas Ignotas wrote:
> The ADS7846/TSC2046 touchscreen controllers can (and usually are)
> connected to various regulators for power, so add regulator support.
>
> Valid regulator will now be required, so boards without complete
> regulator setup should either disable regulator framework or enable
> CONFIG_REGULATOR_DUMMY.
>
> Signed-off-by: Grazvydas Ignotas
> ---
> drivers/input/touchscreen/ads7846.c | 28 +++-
> 1 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> index 52d2ca1..8b05d8e 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /*
> @@ -85,6 +86,7 @@ struct ads7846 {
> char name[32];
>
> struct spi_device *spi;
> + struct regulator *reg;
>
> #if defined(CONFIG_HWMON) || defined(CONFIG_HWMON_MODULE)
> struct attribute_group *attr_group;
> @@ -788,6 +790,8 @@ static void ads7846_disable(struct ads7846 *ts)
> }
> }
>
> + regulator_disable(ts->reg);
> +
> /* we know the chip's in lowpower mode since we always
> * leave it that way after every request
> */
> @@ -799,6 +803,8 @@ static void ads7846_enable(struct ads7846 *ts)
> if (!ts->disabled)
> return;
>
> + regulator_enable(ts->reg);
> +
> ts->disabled = 0;
> ts->irq_disabled = 0;
> enable_irq(ts->spi->irq);
> @@ -1139,6 +1145,19 @@ static int __devinit ads7846_probe(struct spi_device
> *spi)
>
> ts->last_msg = m;
>
> + ts->reg = regulator_get(&spi->dev, "vcc");
"vcc" is way too generic name. What about "vcc-ts" or "vcc-touch"?
> + if (IS_ERR(ts->reg)) {
> + dev_err(&spi->dev, "unable to get regulator: %ld\n",
> + PTR_ERR(ts->reg));
> + goto err_free_gpio;
> + }
> +
> + err = regulator_enable(ts->reg);
> + if (err) {
> + dev_err(&spi->dev, "unable to enable regulator: %d\n", err);
> + goto err_put_regulator;
> + }
> +
> if (request_irq(spi->irq, ads7846_irq, IRQF_TRIGGER_FALLING,
> spi->dev.driver->name, ts)) {
> dev_info(&spi->dev,
> @@ -1148,7 +1167,7 @@ static int __devinit ads7846_probe(struct spi_device
> *spi)
> spi->dev.driver->name, ts);
> if (err) {
> dev_dbg(&spi->dev, "irq %d busy?\n", spi->irq);
> - goto err_free_gpio;
> + goto err_disable_regulator;
> }
> }
>
> @@ -1180,6 +1199,10 @@ static int __devinit ads7846_probe(struct spi_device
> *spi)
> ads784x_hwmon_unregister(spi, ts);
> err_free_irq:
> free_irq(spi->irq, ts);
> + err_disable_regulator:
> + regulator_disable(ts->reg);
> + err_put_regulator:
> + regulator_put(ts->reg);
> err_free_gpio:
> if (ts->gpio_pendown != -1)
> gpio_free(ts->gpio_pendown);
> @@ -1208,6 +1231,9 @@ static int __devexit ads7846_remove(struct spi_device
> *spi)
> /* suspend left the IRQ disabled */
> enable_irq(ts->spi->irq);
>
> + regulator_disable(ts->reg);
> + regulator_put(ts->reg);
> +
> if (ts->gpio_pendown != -1)
> gpio_free(ts->gpio_pendown);
>
> --
> 1.6.3.3
>
> --
> 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
>
--
Sincerely Yours,
Mike.
--
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] Input: ads7846: add regulator support
On Sat, Feb 13, 2010 at 06:31:54PM +0200, Grazvydas Ignotas wrote: > The ADS7846/TSC2046 touchscreen controllers can (and usually are) > connected to various regulators for power, so add regulator support. > > Valid regulator will now be required, so boards without complete > regulator setup should either disable regulator framework or enable > CONFIG_REGULATOR_DUMMY. > > Signed-off-by: Grazvydas Ignotas Looks good from a regulator API point of view: Acked-by: Mark Brown -- 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] Input: ads7846: add regulator support
The ADS7846/TSC2046 touchscreen controllers can (and usually are)
connected to various regulators for power, so add regulator support.
Valid regulator will now be required, so boards without complete
regulator setup should either disable regulator framework or enable
CONFIG_REGULATOR_DUMMY.
Signed-off-by: Grazvydas Ignotas
---
drivers/input/touchscreen/ads7846.c | 28 +++-
1 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index 52d2ca1..8b05d8e 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
/*
@@ -85,6 +86,7 @@ struct ads7846 {
charname[32];
struct spi_device *spi;
+ struct regulator*reg;
#if defined(CONFIG_HWMON) || defined(CONFIG_HWMON_MODULE)
struct attribute_group *attr_group;
@@ -788,6 +790,8 @@ static void ads7846_disable(struct ads7846 *ts)
}
}
+ regulator_disable(ts->reg);
+
/* we know the chip's in lowpower mode since we always
* leave it that way after every request
*/
@@ -799,6 +803,8 @@ static void ads7846_enable(struct ads7846 *ts)
if (!ts->disabled)
return;
+ regulator_enable(ts->reg);
+
ts->disabled = 0;
ts->irq_disabled = 0;
enable_irq(ts->spi->irq);
@@ -1139,6 +1145,19 @@ static int __devinit ads7846_probe(struct spi_device
*spi)
ts->last_msg = m;
+ ts->reg = regulator_get(&spi->dev, "vcc");
+ if (IS_ERR(ts->reg)) {
+ dev_err(&spi->dev, "unable to get regulator: %ld\n",
+ PTR_ERR(ts->reg));
+ goto err_free_gpio;
+ }
+
+ err = regulator_enable(ts->reg);
+ if (err) {
+ dev_err(&spi->dev, "unable to enable regulator: %d\n", err);
+ goto err_put_regulator;
+ }
+
if (request_irq(spi->irq, ads7846_irq, IRQF_TRIGGER_FALLING,
spi->dev.driver->name, ts)) {
dev_info(&spi->dev,
@@ -1148,7 +1167,7 @@ static int __devinit ads7846_probe(struct spi_device *spi)
spi->dev.driver->name, ts);
if (err) {
dev_dbg(&spi->dev, "irq %d busy?\n", spi->irq);
- goto err_free_gpio;
+ goto err_disable_regulator;
}
}
@@ -1180,6 +1199,10 @@ static int __devinit ads7846_probe(struct spi_device
*spi)
ads784x_hwmon_unregister(spi, ts);
err_free_irq:
free_irq(spi->irq, ts);
+ err_disable_regulator:
+ regulator_disable(ts->reg);
+ err_put_regulator:
+ regulator_put(ts->reg);
err_free_gpio:
if (ts->gpio_pendown != -1)
gpio_free(ts->gpio_pendown);
@@ -1208,6 +1231,9 @@ static int __devexit ads7846_remove(struct spi_device
*spi)
/* suspend left the IRQ disabled */
enable_irq(ts->spi->irq);
+ regulator_disable(ts->reg);
+ regulator_put(ts->reg);
+
if (ts->gpio_pendown != -1)
gpio_free(ts->gpio_pendown);
--
1.6.3.3
--
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 00/17] OMAP DSS2 model restructuring
On Mon, Feb 8, 2010 at 5:57 PM, Tomi Valkeinen wrote: > Here are a bunch of patches that change the DSS2 driver's driver model a bit. > This change was triggered by trying to support new hardware, and realizing > that > the current model just won't work. > > Currently the omapdss driver is in control of most aspects of the DSS, and > omapdss calls necessary functions in display drivers. I made it that way to > keep the display drivers simple, and I, naively, thought that it will work > because the display panels are using standard bus interfaces and thus will be > very similar. I was so wrong =). > > This patch set moves the control to the display driver. The display driver > then > calls omapdss functions to perform whatever deed is needed at that time. This > will make display drivers slightly more complex, but it will be easier to > control the hardware properly with strange or complex display devices. > > As a simple example, let's look at the update function. > > Currently user space app issues OMAPFB_UPDATE_WINDOW ioctl, and omapfb driver > then calls update() in corresponding dss device struct, which goes to omapdss. > omapdss will configure the update, calling the panel driver if needed. > > After these patches, omapfb will call update() in the panel driver. The panel > driver will then call functions in omapdss to setup the update, start the > update, and the panel driver will eventually get a callback informing that the > update is done. > > These patches are still under work, but my basic tests on 3430SDP board seems > to work ok. > > The patches can also be found from > http://gitorious.org/linux-omap-dss2/linux work branch Tested those along with the other series, seems to work fine on pandora too. Panel callbacks like set_mirror also work now, thanks. Tested-by: Grazvydas Ignotas > > Tomi Valkeinen (17): > OMAP: DSS2: DSI: change DSI bus_lock to semaphore > OMAP: DSS2: DSI: remove auto-update perf measurement > OMAP: DSS2: move run_test() > OMAP: DSS2: move memory_read() > OMAP: DSS2: move set/get_mirror() > OMAP: DSS2: move get/set_rotate() > OMAP: DSS2: move wait_vsync() > OMAP: DSS2: move enable/disable_channel to overlay manager > OMAP: DSS2: move get_resolution() > OMAP: DSS2: move get_recommended_bpp() > OMAP: DSS2: move enable/get_te() > OMAP: DSS2: move set/get_update_mode() > OMAP: DSS2: move update() and sync() > OMAP: DSS2: move enable/disable/suspend/resume > OMAP: DSS2: move set/get_wss() > OMAP: DSS2: move timing functions > OMAP: DSS2: DSI: Add VC support for update > > arch/arm/plat-omap/include/plat/display.h | 108 ++-- > drivers/video/omap2/displays/panel-generic.c | 56 ++- > .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 67 ++- > .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 42 +- > drivers/video/omap2/displays/panel-taal.c | 221 +-- > .../video/omap2/displays/panel-toppoly-tdo35s.c | 56 ++- > .../video/omap2/displays/panel-tpo-td043mtea1.c | 61 ++- > drivers/video/omap2/dss/core.c | 7 + > drivers/video/omap2/dss/dispc.c | 36 +- > drivers/video/omap2/dss/display.c | 87 +-- > drivers/video/omap2/dss/dpi.c | 149 + > drivers/video/omap2/dss/dsi.c | 829 > > drivers/video/omap2/dss/dss.h | 4 +- > drivers/video/omap2/dss/manager.c | 48 +- > drivers/video/omap2/dss/overlay.c | 2 +- > drivers/video/omap2/dss/rfbi.c | 321 +--- > drivers/video/omap2/dss/sdi.c | 115 +--- > drivers/video/omap2/dss/venc.c | 294 +++ > drivers/video/omap2/omapfb/omapfb-ioctl.c | 44 +- > drivers/video/omap2/omapfb/omapfb-main.c | 89 ++- > drivers/video/omap2/omapfb/omapfb.h | 6 + > 21 files changed, 1004 insertions(+), 1638 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 > -- 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-V3] AM3517: Enable RTC driver support for AM3517EVM
From: Vaibhav Hiremath
Add platform hook-up interface to support RTC driver (S35390A).
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-am3517evm.c | 39 +
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 247c700..9589e46 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -175,6 +175,39 @@ struct platform_device am3517_evm_dss_device = {
},
};
+static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("s35390a", 0x30),
+ .type = "s35390a",
+ },
+};
+
+/*
+ * RTC - S35390A
+ */
+#define GPIO_RTCS35390A_IRQ55
+
+static void __init am3517_evm_rtc_init(void)
+{
+ int r;
+
+ omap_mux_init_gpio(GPIO_RTCS35390A_IRQ, OMAP_PIN_INPUT_PULLUP);
+ r = gpio_request(GPIO_RTCS35390A_IRQ, "rtcs35390a-irq");
+ if (r < 0) {
+ printk(KERN_WARNING "failed to request GPIO#%d\n",
+ GPIO_RTCS35390A_IRQ);
+ return;
+ }
+ r = gpio_direction_input(GPIO_RTCS35390A_IRQ);
+ if (r < 0) {
+ printk(KERN_WARNING "GPIO#%d cannot be configured as input\n",
+ GPIO_RTCS35390A_IRQ);
+ gpio_free(GPIO_RTCS35390A_IRQ);
+ return;
+ }
+ am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
+}
+
static int __init am3517_evm_i2c_init(void)
{
omap_register_i2c_bus(1, 400, NULL, 0);
@@ -235,6 +268,12 @@ static void __init am3517_evm_init(void)
usb_ehci_init(&ehci_pdata);
/* DSS */
am3517_evm_display_init();
+
+ /* RTC - S35390A */
+ am3517_evm_rtc_init();
+
+ i2c_register_board_info(1, am3517evm_i2c_boardinfo,
+ ARRAY_SIZE(am3517evm_i2c_boardinfo));
}
static void __init am3517_evm_map_io(void)
--
1.6.2.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-V3] AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM
From: Vaibhav Hiremath
Add platform hook-up interface to support I2C based GPIo expander
(TCA6416).
There are 3 instances of I2C Expander on AM3517EVM,
- One is over I2C-2 mounted on Base board
- Two are over I2C3 mounted on UI Card
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/board-am3517evm.c | 40 +++-
1 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 9589e46..757dbcf 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -208,11 +209,46 @@ static void __init am3517_evm_rtc_init(void)
am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
}
+/*
+ * I2C GPIO Expander - TCA6416
+ */
+
+/* Mounted on Base-Board */
+static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+};
+static struct i2c_board_info __initdata am3517evm_tca6516_info_0[] = {
+ {
+ I2C_BOARD_INFO("tca6416", 0x21),
+ .platform_data = &am3517evm_gpio_expander_info_0,
+ },
+};
+
+/* Mounted on UI Card */
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_1 = {
+ .gpio_base = OMAP_MAX_GPIO_LINES + 16,
+};
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
+ .gpio_base = OMAP_MAX_GPIO_LINES + 32,
+};
+static struct i2c_board_info __initdata am3517evm_ui_tca6516_info[] = {
+ {
+ I2C_BOARD_INFO("tca6416", 0x20),
+ .platform_data = &am3517evm_ui_gpio_expander_info_1,
+ },
+ {
+ I2C_BOARD_INFO("tca6416", 0x21),
+ .platform_data = &am3517evm_ui_gpio_expander_info_2,
+ },
+};
+
static int __init am3517_evm_i2c_init(void)
{
omap_register_i2c_bus(1, 400, NULL, 0);
- omap_register_i2c_bus(2, 400, NULL, 0);
- omap_register_i2c_bus(3, 400, NULL, 0);
+ omap_register_i2c_bus(2, 400, am3517evm_tca6516_info_0,
+ ARRAY_SIZE(am3517evm_tca6516_info_0));
+ omap_register_i2c_bus(3, 400, am3517evm_ui_tca6516_info,
+ ARRAY_SIZE(am3517evm_ui_tca6516_info));
return 0;
}
--
1.6.2.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 0/2-V3] Add support for I2C based devices to AM3517EVM
From: Vaibhav Hiremath This series of patchset adds platform hook-up interface for I2C based devices to AM3517 - - Real Time Clock (S35390A) - I2C GPIO Expander (TCA6416) Changes from last submission (V2) - - Added seperate function for RTC init, to handle error return properly (comment provided by Tony). Vaibhav Hiremath (2): AM3517: Enable RTC driver support for AM3517EVM AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM arch/arm/mach-omap2/board-am3517evm.c | 79 - 1 files changed, 77 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
RE: Moving board patches from DSS2 to linux-omap
> -Original Message- > From: Hiremath, Vaibhav > Sent: Saturday, February 13, 2010 4:04 PM > To: 'Tomi Valkeinen'; ext Tony Lindgren > Cc: ext Mike Rapoport; linux-omap@vger.kernel.org > Subject: RE: Moving board patches from DSS2 to linux-omap > > > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Friday, February 12, 2010 4:14 PM > > To: ext Tony Lindgren > > Cc: ext Mike Rapoport; Hiremath, Vaibhav; linux- > o...@vger.kernel.org > > Subject: Re: Moving board patches from DSS2 to linux-omap > > > > On Thu, 2010-02-11 at 19:52 +0100, ext Tony Lindgren wrote: > > > * Tomi Valkeinen [100211 03:59]: > > > > On Thu, 2010-02-11 at 12:50 +0100, ext Mike Rapoport wrote: > > > > > Tomi Valkeinen wrote: > > > > > > Hi, > > > > > > > > > > > > As discussed previously, board file changes in DSS2 tree > > cause conflicts > > > > > > with linux-omap easily. There are currently three board > file > > patches in > > > > > > DSS2's for-next branch: > > > > > > > > > > > > 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: > add > > DSS2 display support > > > > > > 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: > > Enable DSS2 for AM3517EVM board > > > > > > 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 > > for OMAP3EVM board > > > > > > > > > > > > The problem here is of course that DSS2 tree may contain > > unmerged panel > > > > > > drivers, and those board file changes try to use these new > > panel > > > > > > drivers. > > > > > > OK, Tomi, can you please set up a banch against mainline -rc7 > with > > > whatever board-*.c dss2 patches you want me to pull? I'll pull > > them > > > into omap-for-linus, and rebase omap for-next on those. > > > > Here: > > > > git://gitorious.org/linux-omap-dss2/linux.git for-tony > > > > I removed the defconfig changes from the patches, and compile > > tested. > > I'll add the defconfig changes as separate patches in my tree, and > > I'll > > push them to Linus only after the board changes from Tony's tree > > have > > gone through. > > > [Hiremath, Vaibhav] Tomi, > > I have pulled in for-tony branch and validated it on OAMP3EVM (with > omap3_defconfig) and AM3517EVM without any issues. > [Hiremath, Vaibhav] Missed to mention one point, Tomi, Probably you have not merged sharp LQ043T1DG01 panel support patch required for AM3517? Can you merge that patch also? Thanks, Vaibhav > Do you need any help here? Do you want me to separate defconfig > patches for you? > > Thanks, > Vaibhav > > > 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
RE: omap3 camera interface driver
> -Original Message- > From: Weng, Wending [mailto:ww...@rheinmetall.ca] > Sent: Friday, February 12, 2010 9:51 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: omap3 camera interface driver > > Hi Hiremath, > > I used to work with BSP from TI, there is driver for > camera interface. Now I switched to 2.6.33.rc3, don't see any omap3 > camera interface driver, could you tell me the status of this > driver? Thanks. > [Hiremath, Vaibhav] Yes that's right, we do not have OMAP3 Camera support available in main-line kernel yet. The Camera support currently available is based on V4L2-Int framework which has become legacy framework. We have to migrate to sub-device framework to get it merged in Main-line, which will eventually happen over period of time. At this point of time I do not have any time lines for this activity, but yes I have this activity listed in my todo. I believe when you are saying you were working on TI BSP, you are referring to 2.6.22 based kernel releases. As of now I can point you to the V4L2-Int based Camera driver support which I am maintaining (forward ported) for our releases http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=summary Thanks, Vaibhav > Software Engineer > Wending -- 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: Moving board patches from DSS2 to linux-omap
> -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Friday, February 12, 2010 4:14 PM > To: ext Tony Lindgren > Cc: ext Mike Rapoport; Hiremath, Vaibhav; linux-omap@vger.kernel.org > Subject: Re: Moving board patches from DSS2 to linux-omap > > On Thu, 2010-02-11 at 19:52 +0100, ext Tony Lindgren wrote: > > * Tomi Valkeinen [100211 03:59]: > > > On Thu, 2010-02-11 at 12:50 +0100, ext Mike Rapoport wrote: > > > > Tomi Valkeinen wrote: > > > > > Hi, > > > > > > > > > > As discussed previously, board file changes in DSS2 tree > cause conflicts > > > > > with linux-omap easily. There are currently three board file > patches in > > > > > DSS2's for-next branch: > > > > > > > > > > 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add > DSS2 display support > > > > > 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: > Enable DSS2 for AM3517EVM board > > > > > 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 > for OMAP3EVM board > > > > > > > > > > The problem here is of course that DSS2 tree may contain > unmerged panel > > > > > drivers, and those board file changes try to use these new > panel > > > > > drivers. > > > > OK, Tomi, can you please set up a banch against mainline -rc7 with > > whatever board-*.c dss2 patches you want me to pull? I'll pull > them > > into omap-for-linus, and rebase omap for-next on those. > > Here: > > git://gitorious.org/linux-omap-dss2/linux.git for-tony > > I removed the defconfig changes from the patches, and compile > tested. > I'll add the defconfig changes as separate patches in my tree, and > I'll > push them to Linus only after the board changes from Tony's tree > have > gone through. > [Hiremath, Vaibhav] Tomi, I have pulled in for-tony branch and validated it on OAMP3EVM (with omap3_defconfig) and AM3517EVM without any issues. Do you need any help here? Do you want me to separate defconfig patches for you? Thanks, Vaibhav > 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
Re: [PATCH v2 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
On Fri, Feb 12, 2010 at 2:49 AM, Tony Lindgren wrote:
> * Tony Lindgren [100211 12:43]:
>> * Vimal Singh [100210 21:16]:
>> > From: Vimal Singh
>> >
>> > This patch adds 'board-zoom-flash.c', which could be utilized
>> > by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
>> >
>> > This does initialization for NAND device based on the 'cs' number
>> > and partition information passed from board file (ex: board-zoom2.c).
>> >
>> > Signed-off-by: Vimal Singh
>> > ---
>> > arch/arm/mach-omap2/board-zoom-flash.c | 85
>> > +
>> > arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++
>> > 2 files changed, 96 insertions(+), 0 deletions(-)
>> > create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
>> >
>> > diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
>> > b/arch/arm/mach-omap2/board-zoom-flash.c
>> > new file mode 100644
>> > index 000..f2328a4
>> > --- /dev/null
>> > +++ b/arch/arm/mach-omap2/board-zoom-flash.c
>> > @@ -0,0 +1,85 @@
>> > +/*
>> > + * board-zoom-flash.c
>> > + *
>> > + * Copyright (C) 2009 Texas Instruments Inc.
>> > + * Vimal Singh
>> > + *
>> > + * 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.
>> > + */
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#include
>> > +
>> > +#if defined(CONFIG_MTD_NAND_OMAP2) || \
>> > + defined(CONFIG_MTD_NAND_OMAP2_MODULE)
>> > +
>> > +/* Note that all values in this struct are in nanoseconds */
>> > +static struct gpmc_timings nand_timings = {
>> > +
>> > + .sync_clk = 0,
>> > +
>> > + .cs_on = 0,
>> > + .cs_rd_off = 36,
>> > + .cs_wr_off = 36,
>> > +
>> > + .adv_on = 6,
>> > + .adv_rd_off = 24,
>> > + .adv_wr_off = 36,
>> > +
>> > + .we_off = 30,
>> > + .oe_off = 48,
>> > +
>> > + .access = 54,
>> > + .rd_cycle = 72,
>> > + .wr_cycle = 72,
>> > +
>> > + .wr_access = 30,
>> > + .wr_data_mux_bus = 0,
>> > +};
>> > +
>> > +/* NAND chip access: 16 bit */
>> > +static struct omap_nand_platform_data zoom_nand_data = {
>> > + .nand_setup = NULL,
>> > + .gpmc_t = &nand_timings,
>> > + .dma_channel = -1, /* disable DMA in OMAP NAND driver */
>> > + .dev_ready = NULL,
>> > + .devsize = 1, /* '0' for 8-bit, '1' for 16-bit device */
>> > +};
>> > +
>> > +/**
>> > + * zoom_flash_init - Identify devices connected to GPMC and register.
>> > + *
>> > + * @return - void.
>> > + */
>> > +void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[],
>> > int cs)
>> > +{
>> > + u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
>> > +
>> > + zoom_nand_data.cs = cs;
>> > + zoom_nand_data.parts = zoom_nand_parts[0].parts;
>> > + zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
>> > + zoom_nand_data.gpmc_baseaddr = (void *)(gpmc_base_add);
>> > + zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
>> > + GPMC_CS0_BASE +
>> > + cs * GPMC_CS_SIZE);
>>
>> The gpmc_baseaddr and gpmc_cs_baseaddr should no longer be
>> needed with gpmc-nand.c, right?
As said earlier too these are needed by 'nand/omap2.c' driver not for
gpmc.-nand.c, we still need to pass these.
>
> Yeah.. For now, I suggest you set the gpmc_baseaddr and
> gpmc_cs_baseaddr in gpmc_nand_init() based on the results from
> gpmc_cs_request.
>
> That will allow us to remove the insane hardcoded gpmc virtual
> addresses from all board-*.c files.
OK
>
> And then we can finally fix gpmc-nand.c driver not to go tinker
You mean omap2.c nand driver?
> with the GPMC registers directly. All of that should be in
> gpmc-nand.c using gpmc.c. The driver should be just a generic
> NAND driver.
Yes, but that will take complete clean-up of omap2.c nand driver by
moving all functions accessing GPMC registers from 'nand/omap2.c' to
'gpmc-nand.c'. And we can take that work later.
Once everything is working fine and is at proper place, clean-up will
have more visibility.
IMHO, you can still take patches for now. As, this is how already done
for sdp boards too.
--
Regards,
Vimal Singh
--
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
