On 2012-11-01 17:18, Pantelis Antoniou wrote:
> omap_device is going private.
>
> Move the da8xx-dt adapter device to arch/arm/mach-omap2.
>
> Signed-off-by: Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx>
> +
> + /* display_panel */
> + priv->lcd_panel.panel_type = QVGA;
> + priv->lcd_panel.max_bpp = 16;
> + priv->lcd_panel.min_bpp = 16;
> + priv->lcd_panel.panel_shade = COLOR_ACTIVE;
> +
> + /* lcd_ctrl_config */
> + priv->lcd_cfg.p_disp_panel = &priv->lcd_panel;
> + priv->lcd_cfg.ac_bias = 255;
> + priv->lcd_cfg.ac_bias_intrpt = 0;
> + priv->lcd_cfg.dma_burst_sz = 16;
> + priv->lcd_cfg.bpp = 16;
> + priv->lcd_cfg.fdd = 0x80;
> + priv->lcd_cfg.tft_alt_mode = 0;
> + priv->lcd_cfg.stn_565_mode = 0;
> + priv->lcd_cfg.mono_8bit_mode = 0;
> + priv->lcd_cfg.invert_line_clock = 1;
> + priv->lcd_cfg.invert_frm_clock = 1;
> + priv->lcd_cfg.sync_edge = 0;
> + priv->lcd_cfg.sync_ctrl = 1;
> + priv->lcd_cfg.raster_order = 0;
> +
> + /* da8xx_lcdc_platform_data */
> + strcpy(priv->lcd_pdata.manu_name, "BBToys");
> + priv->lcd_pdata.controller_data = &priv->lcd_cfg;
> + strcpy(priv->lcd_pdata.type, panel_type);
> +
> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
> + if (priv->lcdc_oh == NULL) {
> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n");
> + return -ENODEV;
> + }
> +
> + priv->lcdc_pdev = omap_device_build("da8xx_lcdc", 0, priv->lcdc_oh,
> + &priv->lcd_pdata,
> + sizeof(struct da8xx_lcdc_platform_data),
> + NULL, 0, 0);
> + if (priv->lcdc_pdev == NULL) {
> + dev_err(&pdev->dev, "Failed to build LCDC device\n");
> + return -ENODEV;
> + }
I know nothing about BeagleBone, da8xx_lcdc, or the capes, but here are
my thoughts... =)
If I understood this cape-thing correctly, to handle the LCDs properly
the da8xx_lcdc driver should be changed to be more dynamic.
The da8xx_lcdc device should be always added by the standard SoC code.
If the LCD panel is fixed for the board in question, the lcdc could be
passed the LCD data as done now (I guess).
But in beaglebone's case the platform data for lcdc should be empty, and
the lcdc driver should do just minimal setup, like memmapping its
registers. No pinmuxing nor other such things.
When the cape is identified and the cape's driver is loaded, the driver
would configure lcdc depending on the cape, including pinmuxing. After
that the LCD should be functional.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
