lkml.org 
[lkml]   [2017]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [linux-sunxi] Cedrus driver
From
Date
On 16/11/17 14:17, Giulio Benetti wrote:
> Hi Hans,
>
> Il 16/11/2017 14:12, Hans Verkuil ha scritto:
>> On 16/11/17 13:57, Giulio Benetti wrote:
>>> Il 16/11/2017 13:53, Maxime Ripard ha scritto:
>>>> On Thu, Nov 16, 2017 at 01:30:52PM +0100, Giulio Benetti wrote:
>>>>>> On Thu, Nov 16, 2017 at 11:37:30AM +0100, Giulio Benetti wrote:
>>>>>>> Il 16/11/2017 11:31, Andreas Baierl ha scritto:
>>>>>>>> Am 16.11.2017 um 11:13 schrieb Giulio Benetti:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>> I'm wondering why cedrus
>>>>>>>>> https://github.com/FlorentRevest/linux-sunxi-cedrus has never been
>>>>>>>>> merged with linux-sunxi sunxi-next.
>>>>>>>>>
>>>>>>>> Because it is not ready to be merged. It depends on the v4l2 request
>>>>>>>> API, which was not merged and which is re-worked atm.
>>>>>>>> Also, sunxi-cedrus itself is not in a finished state and is not as
>>>>>>>> feature-complete to be merged. Anyway it might be something for
>>>>>>>> staging... Has there been a [RFC] on the mailing list at all?
>>>>>>>
>>>>>>> Where can I find a list of TODOs to get it ready to be merged?
>>>>>>
>>>>>> Assuming that the request API is in, we'd need to:
>>>>>> - Finish the MPEG4 support
>>>>>> - Work on more useful codecs (H264 comes to my mind)
>>>>>> - Implement the DRM planes support for the custom frame format
>>>>>> - Implement the DRM planes support for scaling
>>>>>> - Test it on more SoCs
>>>>>>
>>>>>> Or something along those lines.
>>>>>
>>>>> Lot of work to do
>>>>
>>>> Well... If it was fast and easy it would have been done already :)
>>>
>>> :))
>>>
>>>>
>>>>>>>>> I see it seems to be dead, no commit in 1 year.
>>>>>>>>
>>>>>>>> Yes, because the author did this during an internship, which ended ...
>>>>>>>> Afaik nobody picked up his work yet.
>>>>>>
>>>>>> That's not entirely true. Some work has been done by Thomas (in CC),
>>>>>> especially on the display engine side, but last time we talked his
>>>>>> work was not really upstreamable.
>>>>>>
>>>>>> We will also resume that effort starting next march.
>>>>>
>>>>> Is it possible a preview on a separate Reporitory to start working on now?
>>>>> Expecially to start porting everything done by FlorentRevest to mainline,
>>>>> admitted you've not already done.
>>>>
>>>> I'm not sure what you're asking for. Florent's work *was* on mainline.
>>>
>>> and then they took it off because it was unmantained?
>>> You've spoken about Thomas(in CC) not ready,
>>> maybe I could help on that if it's public to accelerate.
>>> If I'm able to of course, this is my primary concern.
>>>
>>> Otherwise, in which way can I help improving it to make it accept to linux-sunxi?
>>> Starting from Florent's work and porting it to sunxi-next to begin?
>>> And after that adding all features you've listed?
>>> Tell me what I can do(I repeat, if I'm able to).
>>
>> The bottleneck is that the Request API is not mainlined. We restarted work
>> on it after a meeting a few weeks back where we all agreed on the roadmap
>> so hopefully it will go into mainline Q1 or Q2 next year.
>>
>> That said, you can use Florent's patch series for further development.
>> It should be relatively easy to convert it to the final version of the
>> Request API. Just note that the public API of the final Request API will
>> be somewhat different from the old version Florent's patch series is using.
>
> So I'm going to try soon to :
> 1) adapt that patchset to sunxi-next
> 2) add A20 support
> 3) add A33 support
> 4) after mainlined APIs, merge
>
> Alright?

Sounds reasonable.

Regards,

Hans

>
> Regards
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>>>
>>>> Maxime
>>>>
>>>
>>> Thank you
>>>
>>
>
>

\
 
 \ /
  Last update: 2017-11-17 17:17    [W:0.108 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site