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