linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Dr. H. Nikolaus Schaller" <hns@goldelico.com>,
	Lars-Peter Clausen <lars@metafoo.de>
Cc: Belisko Marek <marek.belisko@gmail.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Date: Fri, 11 Oct 2013 10:09:25 +0000	[thread overview]
Message-ID: <5257CE55.3090902@ti.com> (raw)
In-Reply-To: <B8F44C8A-362C-4E78-BE91-D9C0783B998B@goldelico.com>

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

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

> Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
> unknown - "3 wire serial interface". Or is it a "3(+1) GPIO slave device"?
> I am still not sure about this.

Lars-Peter said "Back in the OpenMoko days we used the panel in normal
4-wire SPI mode with the GPIO bitbang SPI master."

I don't know much about SPI, so I can't answer to that. If the serial
bus is indeed not any kind of more or less standard SPI version, but
really a custom bus for this controller, then the case is a bit unclear.

> If we really want to do it correctly, we may have to write a driver for that
> special serial protocol as well. If it turns out that we can't mis-use and tweak
> it into a standard SPI driver with bit-bang backend.
> 
> I simply fear that we get dependencies with the SPI subsystem and have
> to test, debug and maintain it. Maintaining the GPIO thing we currently have
> is easy.
> 
> What would be against taking the GPIO approach first and then upgrade as soon
> as someone raises his/her finger that he/she wants to really interface this display
> differently and is not happy with the 3/4 GPIOs? Either they come up with a patch
> or contact the driver author (=me).

I don't have anything against that as long as we use only platform data.

But DT data is not an in-kernel API, it's an external API. Once we
define that the DT data for this panel is something, that's it, we
should stick to it. Of course, we can build compatibility layers for old
DT data, but I would avoid that if at all possible.

If we now create the DT data with gpios, and the panel as platform
device, it'd be rather nasty change to make it a child of an spi bus. (I
presume, I have never made such a change).

And, as the gpios and platform device approach is clearly wrong way to
describe the hardware, I'm quite against using that description in the
DT data.

That said, one option is to describe the hardware correctly in the DT
data, but have a platform device for the panel, with panel driver doing
the bitbanging. In that case it is possible to update the system to use
SPI framework if needed, without changing the DT data. However, I'm not
sure how easy that would be.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

  reply	other threads:[~2013-10-11 10:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-09 21:08 [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD Marek Belisko
2013-10-10  8:19 ` Tomi Valkeinen
2013-10-10  9:34   ` Dr. H. Nikolaus Schaller
2013-10-10 11:10     ` Tomi Valkeinen
2013-10-10 11:52       ` Dr. H. Nikolaus Schaller
2013-10-10 12:13         ` Tomi Valkeinen
2013-10-10 12:26           ` Lars-Peter Clausen
2013-10-10 13:42             ` Dr. H. Nikolaus Schaller
2013-10-10 18:58               ` Lars-Peter Clausen
2013-10-11  4:41                 ` Tomi Valkeinen
2013-10-11  7:08                   ` Lars-Peter Clausen
2013-10-11  7:42                     ` Dr. H. Nikolaus Schaller
2013-10-11  8:17                       ` Tomi Valkeinen
2013-10-11  8:59                         ` Belisko Marek
2013-10-11  9:04                           ` Tomi Valkeinen
2013-10-11  9:06                           ` Lars-Peter Clausen
2013-10-11  9:50                             ` Dr. H. Nikolaus Schaller
2013-10-11 10:09                               ` Tomi Valkeinen [this message]
2013-10-11 11:03                                 ` Dr. H. Nikolaus Schaller
2013-10-11  7:29                   ` Dr. H. Nikolaus Schaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5257CE55.3090902@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=hns@goldelico.com \
    --cc=lars@metafoo.de \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=marek.belisko@gmail.com \
    --cc=plagnioj@jcrosoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).