RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Mon, 2011-05-16 at 09:54 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 8:40 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Thu, 2011-05-12 at 20:25 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico
Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus
the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAME picodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE 100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's
better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these
MACROs.
Well, the problem with this macro is that it's very unclear. What does
max trial value mean? It doesn't define anything sensible, just a number
which doesn't mean anything without the code context.
If it was MAX_TRIAL_TIME_MS, telling the maximum time in milliseconds
that the code would wait, then it would be sensible.
Another problem is that you used the same macro in two different places,
which have nothing to do with each other. The other place requires a
wait of 500ms, if I recall right, and is related to the power up. The
other one is related to waiting for some DMA transfer inside pico to
finish, and this time is in microseconds or possibly few milliseconds if
I understood right.
It's not good to use the same define in such different places,
especially as it only defines a max loop number, so it depends on the
msleeps in the code.
+struct picodlp_data {
+ struct mutex lock;
+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);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c
client is being removed, i.e. when somebody has called
i2c_unregister_device()?
The matching API for i2c_add_device is i2c_del_device.
These are _driver_ functions not device.
And i2c_unregister_device is a matching API for i2c_new_device.
i2c_del_device (a call present in picodlp_exit) would call i2c_remove
and then i2c_remove has a call to i2c_unregister_device which would
unregister the i2c_device.
So panel_remove should also have a call to i2c_unregister_device.
This would solve the problem.
I believe panel_remove should be the only place to have
i2c_unregister_device. It is, as you said, counterpart of
i2c_new_device, and that is called from panel_probe.
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 v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message- From: Valkeinen, Tomi Sent: Monday, May 16, 2011 12:29 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Subject: RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver On Mon, 2011-05-16 at 09:54 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 8:40 PM To: Janorkar, Mayuresh Cc: linux-omap@vger.kernel.org; K, Mythri P Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c client is being removed, i.e. when somebody has called i2c_unregister_device()? The matching API for i2c_add_device is i2c_del_device. These are _driver_ functions not device. And i2c_unregister_device is a matching API for i2c_new_device. i2c_del_device (a call present in picodlp_exit) would call i2c_remove and then i2c_remove has a call to i2c_unregister_device which would unregister the i2c_device. So panel_remove should also have a call to i2c_unregister_device. This would solve the problem. I believe panel_remove should be the only place to have i2c_unregister_device. It is, as you said, counterpart of i2c_new_device, and that is called from panel_probe. Looks fine. 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 v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 8:40 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Thu, 2011-05-12 at 20:25 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico
Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus
the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAMEpicodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's
better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these
MACROs.
Well, the problem with this macro is that it's very unclear. What does
max trial value mean? It doesn't define anything sensible, just a number
which doesn't mean anything without the code context.
If it was MAX_TRIAL_TIME_MS, telling the maximum time in milliseconds
that the code would wait, then it would be sensible.
Another problem is that you used the same macro in two different places,
which have nothing to do with each other. The other place requires a
wait of 500ms, if I recall right, and is related to the power up. The
other one is related to waiting for some DMA transfer inside pico to
finish, and this time is in microseconds or possibly few milliseconds if
I understood right.
It's not good to use the same define in such different places,
especially as it only defines a max loop number, so it depends on the
msleeps in the code.
+struct picodlp_data {
+ struct mutex lock;
+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);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c
client is being removed, i.e. when somebody has called
i2c_unregister_device()?
The matching API for i2c_add_device is i2c_del_device.
And i2c_unregister_device is a matching API for i2c_new_device.
i2c_del_device (a call present in picodlp_exit) would call i2c_remove and then
i2c_remove has a call to i2c_unregister_device which would unregister the
i2c_device.
So panel_remove should also have a call to i2c_unregister_device.
This would solve the problem.
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 v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
DPP2600
is stable, then PWRGOOD should be deactivated (Set to a logic high).
The DPP2600 will then perform a power-up initialization routine that will
first
configure and lock its PLL followed by loading self configuration data from
external flash. DPP2600 would be activated and the EMU_DONE signal will be
driven high. After this once internal initialization routine,
which will take approximately 510ms, i2c commands can be sent.
To know more please visit:
http://www.omappedia.org/wiki/PicoDLP_projector_guide
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v3:
msleep moved to appropriate place
gpio requests moved to board file
Changes since v2:
Merged panel picodlp patches into a single patch
Introduced DMA_DONE polling between flash transfer
Changed GPIO handling
Reduced sleeps
drivers/video/omap2/displays/Kconfig |7 +
drivers/video/omap2/displays/Makefile|1 +
drivers/video/omap2/displays/panel-picodlp.c | 614
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
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
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
new file mode 100644
index 000..8dd8651
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -0,0 +1,614 @@
+/*
+ * 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
+ * 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/i2c.h
+#include linux/delay.h
+#include linux/gpio.h
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAME picodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE 100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
+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[] = {
+
RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAMEpicodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these MACROs.
+struct picodlp_data {
+ struct mutex lock;
+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);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
I will add this sequence at dss_remove
+ return 0;
+}
+* then only i2c commands can be successfully sent to dpp2600
+*/
+ msleep(510);
+ if (omapdss_dpi_display_enable(dssdev)) {
+ dev_err(dssdev-dev, failed to enable DPI\n);
+ goto err;
+ }
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ if (!picodlp_i2c_data) {
+ dev_err(dssdev-dev, could not find picodlp i2c data\n);
+ goto err;
If you goto err here, you have to call dpi_display_disable.
I think it's simpler if you get the picodlp_i2c_data somewhere in the
beginning of this function. That way you can bail out if it's NULL
before doing any HW writes.
That looks to be the BEST approach.
+ }
+ r = picodlp_i2c_init(picod-picodlp_i2c_client);
+ if (r)
+ goto err;
And same here.
Yes, I would add dpi_display_disable at err label.
+
+ return r;
+err:
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+
+ return r;
+}
+
+static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
+{
+ struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
+
+ omapdss_dpi_display_disable(dssdev);
+
+ picod-picodlp_i2c_client = picodlp_i2c_client;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ if (!picodlp_i2c_data) {
+ dev_err(dssdev-dev, could not fine picodlp i2c data);
+ r = -ENODEV;
+ goto err;
+ }
You shouldn't use picodlp_i2c_data here. You don't need it and there's
no guarantee that the i2c probe has been ran yet.
It's enough to check it at power_on.
Looks fine.
+ dev_set_drvdata(dssdev-dev, picod);
+ return r;
+
+err:
+ kfree(picod);
+ return r;
+}
+
+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);
+ return r;
+}
+
+static void __exit picodlp_exit(void)
+{
+ i2c_del_driver(picodlp_i2c_driver);
+ omap_dss_unregister_driver(picodlp_driver);
+}
These two could be the other way around. I'm not sure it affects the
removal, but it's usually safer to do things in reverse order.
Looks fine.
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 v4 4/4] OMAP: DSS: Add picodlp panel driver
On Thu, 2011-05-12 at 20:25 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAME picodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE 100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these MACROs.
Well, the problem with this macro is that it's very unclear. What does
max trial value mean? It doesn't define anything sensible, just a number
which doesn't mean anything without the code context.
If it was MAX_TRIAL_TIME_MS, telling the maximum time in milliseconds
that the code would wait, then it would be sensible.
Another problem is that you used the same macro in two different places,
which have nothing to do with each other. The other place requires a
wait of 500ms, if I recall right, and is related to the power up. The
other one is related to waiting for some DMA transfer inside pico to
finish, and this time is in microseconds or possibly few milliseconds if
I understood right.
It's not good to use the same define in such different places,
especially as it only defines a max loop number, so it depends on the
msleeps in the code.
+struct picodlp_data {
+ struct mutex lock;
+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);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c
client is being removed, i.e. when somebody has called
i2c_unregister_device()?
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
