linux-next: manual merge of the omap_dss2 tree with the omap tree
Stephen Rothwell
Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-omap3pandora.c between commit
f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
reflect independence from twl4030") from the omap tree and commit
aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
support and related regulators") from the omap_dss2 tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell s...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-omap3pandora.c
index 9967b5d,bd3e577..0000000
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@@ -192,7 -193,62 +193,62 @@@ static struct twl4030_keypad_data pando
.rep = 1,
};
+ static struct omap_dss_device pandora_lcd_device = {
+ .name = "lcd",
+ .driver_name = "tpo_td043mtea1_panel",
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .reset_gpio = 157,
+ };
+
+ static struct omap_dss_device pandora_tv_device = {
+ .name = "tv",
+ .driver_name = "venc",
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ };
+
+ static struct omap_dss_device *pandora_dss_devices[] = {
+ &pandora_lcd_device,
+ &pandora_tv_device,
+ };
+
+ static struct omap_dss_board_info pandora_dss_data = {
+ .num_devices = ARRAY_SIZE(pandora_dss_devices),
+ .devices = pandora_dss_devices,
+ .default_device = &pandora_lcd_device,
+ };
+
+ static struct platform_device pandora_dss_device = {
+ .name = "omapdss",
+ .id = -1,
+ .dev = {
+ .platform_data = &pandora_dss_data,
+ },
+ };
+
+ static struct regulator_consumer_supply pandora_vcc_lcd_supply = {
+ .supply = "vcc",
+ .dev = &pandora_lcd_device.dev,
+ };
+
+ static struct regulator_consumer_supply pandora_vdda_dac_supply = {
+ .supply = "vdda_dac",
+ .dev = &pandora_dss_device.dev,
+ };
+
+ static struct regulator_consumer_supply pandora_vdds_supplies[] = {
+ {
+ .supply = "vdds_sdi",
+ .dev = &pandora_dss_device.dev,
+ },
+ {
+ .supply = "vdds_dsi",
+ .dev = &pandora_dss_device.dev,
+ },
+ };
+
-static struct twl4030_hsmmc_info omap3pandora_mmc[] = {
+static struct omap2_hsmmc_info omap3pandora_mmc[] = {
{
.mmc = 1,
.wires = 4,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Grazvydas Ignotas
On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <s...@canb.auug.org.au> wrote:
> Hi Tomi,
>
> Today's linux-next merge of the omap_dss2 tree got a conflict in
> arch/arm/mach-omap2/board-omap3pandora.c between commit
> f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> reflect independence from twl4030") from the omap tree and commit
> aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> support and related regulators") from the omap_dss2 tree.
I've rebased my patch against linux-omap/for-next (attached). To fix
the conflict, Tomi can rebase his queue on linux-omap/for-next, or
Tony can simply take this to his queue - this has no "hard"
dependencies on other queued DSS2 changes, has only board file changes
and builds fine in linux-omap/for-next. I would prefer the second
option, as I plan sending more boardfile changes to linux-omap.
Tony Lindgren
> hi,
>
> On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <s...@canb.auug.org.au> wrote:
> > Hi Tomi,
> >
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-omap3pandora.c between commit
> > f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> > reflect independence from twl4030") from the omap tree and commit
> > aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> > support and related regulators") from the omap_dss2 tree.
>
> I've rebased my patch against linux-omap/for-next (attached). To fix
> the conflict, Tomi can rebase his queue on linux-omap/for-next, or
> Tony can simply take this to his queue - this has no "hard"
> dependencies on other queued DSS2 changes, has only board file changes
> and builds fine in linux-omap/for-next. I would prefer the second
> option, as I plan sending more boardfile changes to linux-omap.
Thanks Stephen and Grazvydas.
This sounds good to me, I've added this patch into omap for-next.
Tomi can you please drop the earlier version from your branch?
Regards,
Tony
Tomi Valkeinen
> * Grazvydas Ignotas <not...@gmail.com> [100203 04:27]:
> > hi,
> >
> > On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <s...@canb.auug.org.au> wrote:
> > > Hi Tomi,
> > >
> > > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > > arch/arm/mach-omap2/board-omap3pandora.c between commit
> > > f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> > > reflect independence from twl4030") from the omap tree and commit
> > > aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> > > support and related regulators") from the omap_dss2 tree.
> >
> > I've rebased my patch against linux-omap/for-next (attached). To fix
> > the conflict, Tomi can rebase his queue on linux-omap/for-next, or
> > Tony can simply take this to his queue - this has no "hard"
> > dependencies on other queued DSS2 changes, has only board file changes
> > and builds fine in linux-omap/for-next. I would prefer the second
> > option, as I plan sending more boardfile changes to linux-omap.
>
> Thanks Stephen and Grazvydas.
>
> This sounds good to me, I've added this patch into omap for-next.
>
> Tomi can you please drop the earlier version from your branch?
Sounds good to me. I dropped the patch from my tree.
Tomi
Stephen Rothwell
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 s...@canb.auug.org.au
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
*/
Tomi Valkeinen
> 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
Stephen Rothwell
On Mon, 08 Feb 2010 11:29:06 +0200 Tomi Valkeinen <tomi.va...@nokia.com> 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 s...@canb.auug.org.au
Tomi Valkeinen
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 <tomi.va...@nokia.com> 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.
Tony Lindgren
> 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
Tomi Valkeinen
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
Hiremath, Vaibhav
Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
[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