Hi Tomi,
On Nov 1, 2012, at 4:36 PM, Tomi Valkeinen wrote:
> 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 <pa...@antoniou-consulting.com>
>
>
>> +
>> + /* 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
>
You are absolutely correct. That's the proper way to go about it,
but you go to war with the drivers you have, and not the drivers you wish
you had :)
Meaning, it is getting fixed by the da8xx maintainers, but it's not ready yet.
The da8xx-dt can die a short and merciful death then.
Regards
-- Pantelis--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
