[PATCH 00/29] staging: add drivers from the fbtft project

[Noralf Tronnes]

Den 18.01.2015 02:42, skrev Greg KH:
> On Sun, Jan 18, 2015 at 02:30:17AM +0100, Noralf Tronnes wrote:
>> Den 18.01.2015 01:39, skrev Greg KH:
>>> On Mon, Jan 12, 2015 at 06:06:44PM +0100, Noralf Tronnes wrote:
>>>>> Here is a proposal to include in the staging tree the drivers from the
>>>>> fbtft project at https://github.com/notro/fbtft. This project contains
>>>>> a number of drivers small TFT LCD display modules, which are not
>>>>> otherwise supported by the Linux kernel. This set of drivers appears
>>>>> to be quite widely used in the RasberryPi community, and it's a shame
>>>>> that they are not submitted to the upstream Linux kernel.
>>>>>
>>>>> This is for now just a raw import, with only minimal changes compared
>>>>> to the upstream version: I have not tried to fix any coding style
>>>>> issue, or make any other improvement. I have only verified that the
>>>>> entire set of drivers was building fine, which I believe is the main
>>>>> rule when it comes to get code added to the staging tree.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Thomas Petazzoni
>>>> Hi,
>>>>
>>>> I'm the maintainer of the fbtft project.
>>>> Even though I didn't know about this submission beforehand, I'm all for
>>>> having this in staging.
>>>> I didn't know about the staging tree, that drivers not meeting the strict
>>>> Linux coding practices still could be included.
>>>>
>>>> Signed-off-by: Noralf Tronnes <notro at tronnes.org>
>>>>
>>>>
>>>> Previously this project was almost only used by the Raspberry Pi community,
>>>> and some use on Beagle Bone Black, but in the last 6 months it has seen use
>>>> on
>>>> many more platforms (which I have lost count of). Not just ARM, but also
>>>> Intel Edison and Galileo.
>>>> In the same timeperiod there has been an explosion in display shields/capes
>>>> for the Raspberry Pi using these drivers.
>>>> I have also started to see fbtft being pulled into board specific kernel
>>>> trees.
>>>>
>>>> Two months ago I started rewriting this project from scratch to make it a
>>>> better fit for inclusion. Fbtft was the first kernel programming I did, so I
>>>> have picked up a better understanding of the kernel since then.
>>>> I have also a much better understanding of the differences and similarities
>>>> between these LCD controllers, yielding better and cleaner abstractions.
>>>> It will take some time to get it ready for review, and even more time to get
>>>> the same controller/display coverage. I'm hoping to have something ready
>>>> for review during this year, but since it's a for fun freetime project, it's
>>>> hard
>>>> to predict when it's ready.
>>>> Status: https://github.com/notro/fbdbi/wiki
>>> That implies that you are trying to come up with something to obsolete
>>> what we have here, right?  Or am I incorrect?
>>>
>>> thanks,
>>>
>>> greg k-h
>> Yes, you're right, I'm working on a successor that in time will obsolete
>> this.
>> But as I point out, it will take a while to complete the "framework" and
>> surely longer to support all the controllers.
> Rewrites usually don't work, why not iterate this current codebase into
> something clean and acceptable that we can merge properly?  Adding this
> codebase now, which you feel isn't going to go anywhere isn't a good
> idea for me to do, I don't want "stale" code in the tree.
>
> Also, iteration, while taking longer, ends up with a better end-solution
> as everyone participates and provides help.  Doing it all on your own
> isn't a good idea, and isn't how successful kernel code is developed.

When I started this rewrite I didn't anticipate fbtft entering the kernel,
and to me it was easier to just start from scratch. However I'd much
rather go with proven practices, so I will do as you suggest.

At least the lcd register abstraction I've worked on, should be more or
less a bolt-on to fbtft.


Noralf.