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 for Android: free password hash cracker in your pocket

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

Message-ID: <509288D9.7030406@iki.fi>
Date:	Thu, 01 Nov 2012 16:36:09 +0200
From:	Tomi Valkeinen <tomba@....fi>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
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

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

--
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/