2010-02-08 06:25:27

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: manual merge of the omap_dss2 tree with the omap tree

Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-am3517evm.c between commit
13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
Support") from the omap tree and commit
56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
AM3517EVM board") from the omap_dss2 tree.

Juts overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.

P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.
--
Cheers,
Stephen Rothwell [email protected]

diff --cc arch/arm/mach-omap2/board-am3517evm.c
index a166bcc,54af5f8..0000000
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@@ -33,15 -33,147 +34,156 @@@

#include "mux.h"

+ #define LCD_PANEL_PWR 176
+ #define LCD_PANEL_BKLIGHT_PWR 182
+ #define LCD_PANEL_PWM 181
+
+ static int lcd_enabled;
+ static int dvi_enabled;
+
+ static void __init am3517_evm_display_init(void)
+ {
+ int r;
+
+ omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR, OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
+ /*
+ * Enable GPIO 182 = LCD Backlight Power
+ */
+ r = gpio_request(LCD_PANEL_BKLIGHT_PWR, "lcd_backlight_pwr");
+ if (r) {
+ printk(KERN_ERR "failed to get lcd_backlight_pwr\n");
+ return;
+ }
+ gpio_direction_output(LCD_PANEL_BKLIGHT_PWR, 1);
+ /*
+ * Enable GPIO 181 = LCD Panel PWM
+ */
+ r = gpio_request(LCD_PANEL_PWM, "lcd_pwm");
+ if (r) {
+ printk(KERN_ERR "failed to get lcd_pwm\n");
+ goto err_1;
+ }
+ gpio_direction_output(LCD_PANEL_PWM, 1);
+ /*
+ * Enable GPIO 176 = LCD Panel Power enable pin
+ */
+ r = gpio_request(LCD_PANEL_PWR, "lcd_panel_pwr");
+ if (r) {
+ printk(KERN_ERR "failed to get lcd_panel_pwr\n");
+ goto err_2;
+ }
+ gpio_direction_output(LCD_PANEL_PWR, 1);
+
+ printk(KERN_INFO "Display initialized successfully\n");
+ return;
+
+ err_2:
+ gpio_free(LCD_PANEL_PWM);
+ err_1:
+ gpio_free(LCD_PANEL_BKLIGHT_PWR);
+ }
+
+ static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
+ {
+ if (dvi_enabled) {
+ printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ return -EINVAL;
+ }
+ gpio_set_value(LCD_PANEL_PWR, 1);
+ lcd_enabled = 1;
+
+ return 0;
+ }
+
+ static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
+ {
+ gpio_set_value(LCD_PANEL_PWR, 0);
+ lcd_enabled = 0;
+ }
+
+ static struct omap_dss_device am3517_evm_lcd_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "lcd",
+ .driver_name = "sharp_lq_panel",
+ .phy.dpi.data_lines = 16,
+ .platform_enable = am3517_evm_panel_enable_lcd,
+ .platform_disable = am3517_evm_panel_disable_lcd,
+ };
+
+ static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
+ {
+ return 0;
+ }
+
+ static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
+ {
+ }
+
+ static struct omap_dss_device am3517_evm_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .driver_name = "venc",
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .platform_enable = am3517_evm_panel_enable_tv,
+ .platform_disable = am3517_evm_panel_disable_tv,
+ };
+
+ static int am3517_evm_panel_enable_dvi(struct omap_dss_device *dssdev)
+ {
+ if (lcd_enabled) {
+ printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
+ return -EINVAL;
+ }
+ dvi_enabled = 1;
+
+ return 0;
+ }
+
+ static void am3517_evm_panel_disable_dvi(struct omap_dss_device *dssdev)
+ {
+ dvi_enabled = 0;
+ }
+
+ static struct omap_dss_device am3517_evm_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .driver_name = "generic_panel",
+ .phy.dpi.data_lines = 24,
+ .platform_enable = am3517_evm_panel_enable_dvi,
+ .platform_disable = am3517_evm_panel_disable_dvi,
+ };
+
+ static struct omap_dss_device *am3517_evm_dss_devices[] = {
+ &am3517_evm_lcd_device,
+ &am3517_evm_tv_device,
+ &am3517_evm_dvi_device,
+ };
+
+ static struct omap_dss_board_info am3517_evm_dss_data = {
+ .num_devices = ARRAY_SIZE(am3517_evm_dss_devices),
+ .devices = am3517_evm_dss_devices,
+ .default_device = &am3517_evm_lcd_device,
+ };
+
+ struct platform_device am3517_evm_dss_device = {
+ .name = "omapdss",
+ .id = -1,
+ .dev = {
+ .platform_data = &am3517_evm_dss_data,
+ },
+ };
+
+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);
+
+ return 0;
+}
+
/*
* Board initialization
*/


2010-02-08 09:26:41

by Tomi Valkeinen

[permalink] [raw]
Subject: Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> Hi Tomi,
>
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-am3517evm.c between commit
> 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> Support") from the omap tree and commit
> 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> AM3517EVM board") from the omap_dss2 tree.
>
> Juts overlapping additions. I fixed it up (see below) and can carry the
> fix as necessary.

Thanks. I guess we can't properly fix this until the patch from omap
tree goes into mainline.

Tony, do you think this current way, in which we have board file changes
in both linux-omap and the dss tree, is best we can do? Or should all
the board file changes go through linux-omap? I fear that we will have
conflicts with every new board.

> P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.

Hmm, do you mean there's something wrong with that, or "jfyi"? Aren't I,
as a subsys maintainer, supposed to ack the patches?

Tomi

2010-02-08 10:57:23

by Stephen Rothwell

[permalink] [raw]
Subject: Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

Hi Tomi,

On Mon, 08 Feb 2010 11:29:06 +0200 Tomi Valkeinen <[email protected]> wrote:
>
> > P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.
>
> Hmm, do you mean there's something wrong with that, or "jfyi"? Aren't I,
> as a subsys maintainer, supposed to ack the patches?

If a patch goes through your tree, you are supposed to add a Signed-off-by
line. See Documentation/SubmittingPatches section called "Sign your
work".

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (564.00 B)
(No filename) (198.00 B)
Download all attachments

2010-02-08 11:40:53

by Tomi Valkeinen

[permalink] [raw]
Subject: Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

Hi,

On Mon, 2010-02-08 at 11:57 +0100, ext Stephen Rothwell wrote:
> Hi Tomi,
>
> On Mon, 08 Feb 2010 11:29:06 +0200 Tomi Valkeinen <[email protected]> wrote:
> >
> > > P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-off-by.
> >
> > Hmm, do you mean there's something wrong with that, or "jfyi"? Aren't I,
> > as a subsys maintainer, supposed to ack the patches?
>
> If a patch goes through your tree, you are supposed to add a Signed-off-by
> line. See Documentation/SubmittingPatches section called "Sign your
> work".

So it is. Thanks for pointing this out, I'll change the acks to
signed-offs.

Tomi


2010-02-09 16:51:32

by Tony Lindgren

[permalink] [raw]
Subject: Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

* Tomi Valkeinen <[email protected]> [100208 01:23]:
> On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> > Hi Tomi,
> >
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-am3517evm.c between commit
> > 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> > Support") from the omap tree and commit
> > 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> > AM3517EVM board") from the omap_dss2 tree.
> >
> > Juts overlapping additions. I fixed it up (see below) and can carry the
> > fix as necessary.
>
> Thanks. I guess we can't properly fix this until the patch from omap
> tree goes into mainline.

Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next
tree.

> Tony, do you think this current way, in which we have board file changes
> in both linux-omap and the dss tree, is best we can do? Or should all
> the board file changes go through linux-omap? I fear that we will have
> conflicts with every new board.

Yeah we should just move the conflicting files into omap for-next. The board
file changes conflict easily when new platform device init code is being
added.

Tomi, how about you ack and let me know about the patches (or git branch)
you want me to add into omap for-next? Otherwise I'll assume anything
DSS2 related is yours.

Regards,

Tony

2010-02-10 08:18:48

by Tomi Valkeinen

[permalink] [raw]
Subject: Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

On Tue, 2010-02-09 at 17:52 +0100, ext Tony Lindgren wrote:
> * Tomi Valkeinen <[email protected]> [100208 01:23]:
> > On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote:
> > > Hi Tomi,
> > >
> > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > arch/arm/mach-omap2/board-am3517evm.c between commit
> > > 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> > > Support") from the omap tree and commit
> > > 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2 for
> > > AM3517EVM board") from the omap_dss2 tree.
> > >
> > > Juts overlapping additions. I fixed it up (see below) and can carry the
> > > fix as necessary.
> >
> > Thanks. I guess we can't properly fix this until the patch from omap
> > tree goes into mainline.
>
> Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next
> tree.
>
> > Tony, do you think this current way, in which we have board file changes
> > in both linux-omap and the dss tree, is best we can do? Or should all
> > the board file changes go through linux-omap? I fear that we will have
> > conflicts with every new board.
>
> Yeah we should just move the conflicting files into omap for-next. The board
> file changes conflict easily when new platform device init code is being
> added.
>
> Tomi, how about you ack and let me know about the patches (or git branch)
> you want me to add into omap for-next? Otherwise I'll assume anything
> DSS2 related is yours.

This sounds good. However, we need to be careful that there are no
dependencies from the board file patches to the DSS patches (like panel
drivers).

But this is getting out of topic for this mail thread, let's deal with
this separately =).

Tomi

2010-02-10 09:52:26

by Hiremath, Vaibhav

[permalink] [raw]
Subject: RE: linux-next: manual merge of the omap_dss2 tree with the omap tree



Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927

> -----Original Message-----
> From: Stephen Rothwell [mailto:[email protected]]
> Sent: Monday, February 08, 2010 11:55 AM
> To: Tomi Valkeinen
> Cc: [email protected]; [email protected];
> Hiremath, Vaibhav; Tony Lindgren; [email protected]
> Subject: linux-next: manual merge of the omap_dss2 tree with the
> omap tree
>
> Hi Tomi,
>
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-am3517evm.c between commit
> 13560d875d67c06239c82a6148c1b87075701fe9 ("AM3517: Enable basic I2C
> Support") from the omap tree and commit
> 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac ("OMAP: AM3517: Enable DSS2
> for
> AM3517EVM board") from the omap_dss2 tree.
>
> Juts overlapping additions. I fixed it up (see below) and can
> carry the
> fix as necessary.
>
> P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-
> off-by.
> --
> Cheers,
> Stephen Rothwell [email protected]
>
> diff --cc arch/arm/mach-omap2/board-am3517evm.c
> index a166bcc,54af5f8..0000000
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@@ -33,15 -33,147 +34,156 @@@
>
> #include "mux.h"
>
[Hiremath, Vaibhav] I don't see display.h being added here, but when I looked into linux-next repo, I could see that. I think the following commit only shows for the conflicted part, so should be ok.

Thanks,
Vaibhav

> + #define LCD_PANEL_PWR 176
> + #define LCD_PANEL_BKLIGHT_PWR 182
> + #define LCD_PANEL_PWM 181
> +
> + static int lcd_enabled;
> + static int dvi_enabled;
> +
> + static void __init am3517_evm_display_init(void)
> + {
> + int r;
> +
> + omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
> + omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR,
> OMAP_PIN_INPUT_PULLDOWN);
> + omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
> + /*
> + * Enable GPIO 182 = LCD Backlight Power
> + */
> + r = gpio_request(LCD_PANEL_BKLIGHT_PWR, "lcd_backlight_pwr");
> + if (r) {
> + printk(KERN_ERR "failed to get lcd_backlight_pwr\n");
> + return;
> + }
> + gpio_direction_output(LCD_PANEL_BKLIGHT_PWR, 1);
> + /*
> + * Enable GPIO 181 = LCD Panel PWM
> + */
> + r = gpio_request(LCD_PANEL_PWM, "lcd_pwm");
> + if (r) {
> + printk(KERN_ERR "failed to get lcd_pwm\n");
> + goto err_1;
> + }
> + gpio_direction_output(LCD_PANEL_PWM, 1);
> + /*
> + * Enable GPIO 176 = LCD Panel Power enable pin
> + */
> + r = gpio_request(LCD_PANEL_PWR, "lcd_panel_pwr");
> + if (r) {
> + printk(KERN_ERR "failed to get lcd_panel_pwr\n");
> + goto err_2;
> + }
> + gpio_direction_output(LCD_PANEL_PWR, 1);
> +
> + printk(KERN_INFO "Display initialized successfully\n");
> + return;
> +
> + err_2:
> + gpio_free(LCD_PANEL_PWM);
> + err_1:
> + gpio_free(LCD_PANEL_BKLIGHT_PWR);
> + }
> +
> + static int am3517_evm_panel_enable_lcd(struct omap_dss_device
> *dssdev)
> + {
> + if (dvi_enabled) {
> + printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> + return -EINVAL;
> + }
> + gpio_set_value(LCD_PANEL_PWR, 1);
> + lcd_enabled = 1;
> +
> + return 0;
> + }
> +
> + static void am3517_evm_panel_disable_lcd(struct omap_dss_device
> *dssdev)
> + {
> + gpio_set_value(LCD_PANEL_PWR, 0);
> + lcd_enabled = 0;
> + }
> +
> + static struct omap_dss_device am3517_evm_lcd_device = {
> + .type = OMAP_DISPLAY_TYPE_DPI,
> + .name = "lcd",
> + .driver_name = "sharp_lq_panel",
> + .phy.dpi.data_lines = 16,
> + .platform_enable = am3517_evm_panel_enable_lcd,
> + .platform_disable = am3517_evm_panel_disable_lcd,
> + };
> +
> + static int am3517_evm_panel_enable_tv(struct omap_dss_device
> *dssdev)
> + {
> + return 0;
> + }
> +
> + static void am3517_evm_panel_disable_tv(struct omap_dss_device
> *dssdev)
> + {
> + }
> +
> + static struct omap_dss_device am3517_evm_tv_device = {
> + .type = OMAP_DISPLAY_TYPE_VENC,
> + .name = "tv",
> + .driver_name = "venc",
> + .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
> + .platform_enable = am3517_evm_panel_enable_tv,
> + .platform_disable = am3517_evm_panel_disable_tv,
> + };
> +
> + static int am3517_evm_panel_enable_dvi(struct omap_dss_device
> *dssdev)
> + {
> + if (lcd_enabled) {
> + printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
> + return -EINVAL;
> + }
> + dvi_enabled = 1;
> +
> + return 0;
> + }
> +
> + static void am3517_evm_panel_disable_dvi(struct omap_dss_device
> *dssdev)
> + {
> + dvi_enabled = 0;
> + }
> +
> + static struct omap_dss_device am3517_evm_dvi_device = {
> + .type = OMAP_DISPLAY_TYPE_DPI,
> + .name = "dvi",
> + .driver_name = "generic_panel",
> + .phy.dpi.data_lines = 24,
> + .platform_enable = am3517_evm_panel_enable_dvi,
> + .platform_disable = am3517_evm_panel_disable_dvi,
> + };
> +
> + static struct omap_dss_device *am3517_evm_dss_devices[] = {
> + &am3517_evm_lcd_device,
> + &am3517_evm_tv_device,
> + &am3517_evm_dvi_device,
> + };
> +
> + static struct omap_dss_board_info am3517_evm_dss_data = {
> + .num_devices = ARRAY_SIZE(am3517_evm_dss_devices),
> + .devices = am3517_evm_dss_devices,
> + .default_device = &am3517_evm_lcd_device,
> + };
> +
> + struct platform_device am3517_evm_dss_device = {
> + .name = "omapdss",
> + .id = -1,
> + .dev = {
> + .platform_data = &am3517_evm_dss_data,
> + },
> + };
> +
> +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);
> +
> + return 0;
> +}
> +
> /*
> * Board initialization
> */