RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver

[Janorkar, Mayuresh]

> -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

[Tomi Valkeinen]

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 
> > > > >
> > > > > 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
> > >
> > > 
> > >
> > > > > +
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +#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

[Janorkar, Mayuresh]

> -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 
> > > >
> > > > 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
> >
> > 
> >
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include "panel-picodlp.h"
> > > > +
> > > > +#define DRIVER_NAME"picodlp_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

[Tomi Valkeinen]

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 
> > >
> > > 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
> 
> 
> 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#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

RE: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver

[Janorkar, Mayuresh]

> -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 
> >
> > 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



> > +
> > +#include 
> > +#include 
> > +
> > +#include "panel-picodlp.h"
> > +
> > +#define DRIVER_NAME"picodlp_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

[Tomi Valkeinen]

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 
> 
> 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 
> Signed-off-by: Mythri P K 
> ---
> 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 
> + * Mayuresh Janorkar 
> + *
> + * 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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#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[] = {
> + { "picodlp_i2c_driver", 0 },
> +};
> +
> +struct picodlp_i2c_command {
> + u8 re

[PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver

[Mayuresh Janorkar]

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 

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 
Signed-off-by: Mythri P K 
---
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 
+ * Mayuresh Janorkar 
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "panel-picodlp.h"
+
+#define DRIVER_NAME"picodlp_i2c_driver"
+
+#define MAX_TRIAL_VALUE100
+
+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 },
+};
+
+struct picodlp_i2c_command {
+   u8 reg;
+   u32 value;
+};
+
+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 inline struct picodlp_panel_data
+   *get_panel_data(const struct omap_dss_device *dssdev)
+{
+   return (struct picodlp_panel_data *) dssdev->data;
+}
+
+s