From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
Date: Fri, 23 May 2014 14:10:35 +0000 [thread overview]
Message-ID: <537F56DB.1050709@ti.com> (raw)
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]
On 23/05/14 16:13, Alexander Shiyan wrote:
>> Would it be possible to add the new driver along the old driver, and use
>> the new driver only for the boards you have, and for boards for which
>> it's clear the the old driver is not working? This could be merged for 3.16.
>
> At this time yes, we can. But since I plan to add multiplatform support
> for this SOC, this seems not possible.
> I can try to make multiplatform support optional, then it could be done...
Hmm, why is that not possible with multiplatform support? What do you
mean with multiplatform support here?
While the drivers would handle the same device, if they have different
names then they are different device drivers from Linux's perspective.
Why can't one board use the old driver, and an other board use the new
driver?
> If there will be two drivers, I will do the following: remove the non-DT
> support (for new driver) and will create a patch for 3.16 (this patch will
> no affect to arm-soc).
There would be no one using the driver in 3.16, then, right?
> After that, I will do optional multiplatform support for this CPU and move
> the boards, which do not use FB.
> After this architecture will be ready to add DT support, and after all boards
> will be converted, I'll remove the old version of the driver.
>
> OK?
I'm a bit unclear what the multiplatform stuff means here, but yes,
generally sounds ok.
But I don't want to make this more difficult for you than it needs to.
As I said, I'm fine with the current patches, if we skip 3.16 and get
them to linux-next right after the merge window. If nobody would use the
new driver in 3.16 anyway (in your proposal above), would this be the
easiest way?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-05-23 14:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-12 6:53 [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver Alexander Shiyan
2014-04-24 5:03 ` Alexander Shiyan
2014-04-24 7:57 ` Tomi Valkeinen
2014-04-24 8:39 ` Tomi Valkeinen
2014-04-30 11:14 ` Tomi Valkeinen
2014-05-05 5:06 ` Olof Johansson
2014-05-07 9:40 ` Tomi Valkeinen
2014-05-08 10:14 ` Tomi Valkeinen
2014-05-16 22:56 ` Olof Johansson
2014-05-23 12:31 ` Tomi Valkeinen
2014-05-23 12:43 ` Tomi Valkeinen
2014-05-23 13:48 ` Arnd Bergmann
2014-05-23 14:10 ` Tomi Valkeinen [this message]
2014-05-23 14:14 ` Arnd Bergmann
2014-05-23 14:26 ` Tomi Valkeinen
2014-05-23 14:32 ` Tomi Valkeinen
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=537F56DB.1050709@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=linux-fbdev@vger.kernel.org \
/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).