linux-kernel - Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

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: <5257B420.10808@ti.com>
Date:	Fri, 11 Oct 2013 11:17:36 +0300
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>,
	Lars-Peter Clausen <lars@...afoo.de>
CC:	Marek Belisko <marek@...delico.com>, <plagnioj@...osoft.com>,
	<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1
 LCD.

On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:

> I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
> work (reliably) and tested it might need a lot of work for us. At least I think
> such a change (e.g. setting up clock polarity etc.) is not done in some minutes.
> And the only feedback we have from the panel is "does not work"/"works". I.e.
> if we are not lucky that it works immediately we have no real means to debug.
> 
> IMHO it also gives more flexibility to board designers to choose GPIOs instead
> of enforcing some SPI interface by the driver (and encapsulate this arguable
> protocol in the driver). Maybe some board has 3 spare GPIOs but neither
> McBSPs nor McSPIs available.

This has been an interesting thread, I've learnt a lot =).

I still think the panel driver should not handle this, but there should
be a separate spi bitbang driver for it.

I understand you're not enthusiastic going that way, as the current
version works for you. However, when using DT, we need to think how to
represent the hardware in the device tree data, and it has to be right
from the beginning.

That's why I won't allow representing this panel as having 4 gpios in
the DT data, because that is not correct. The panel has 3 pins. But
then, the panel does allow reading, which could be implemented using 4
gpios as you have done. This data should be in the spi-bitbang data, and
the panel should just use the standard SPI framework.

Using SPI framework does not mean you should use McBSP or McSPI. It's up
to you how the 3-wire SPI is implemented on the SoC side, the panel
would just work in all the cases.

 Tomi

Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)