linux-kernel - Re: [PATCH 2/3] da8xx-dt: Create da8xx DT adapter device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <CA59AE1A-AF06-4BB2-B0C2-C6B79021C740@antoniou-consulting.com>
Date:	Thu, 1 Nov 2012 16:38:03 +0200
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Tomi Valkeinen <tomba@....fi>
Cc:	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org
Subject: Re: [PATCH 2/3] da8xx-dt: Create da8xx DT adapter device

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 <panto@...oniou-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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/