linux-kernel - Re: [PATCH RFC v2 0/2] pxa_camera transition to v4l2 standalone device

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: <87oa6d8k36.fsf@belgarion.home>
Date:	Mon, 04 Jul 2016 18:05:33 +0200
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Hans Verkuil <hverkuil@...all.nl>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC v2 0/2] pxa_camera transition to v4l2 standalone device

Hans Verkuil <hverkuil@...all.nl> writes:

> Hi Robert,
>
> On 04/02/2016 04:26 PM, Robert Jarzmik wrote:
>> Hi Hans and Guennadi,
>> 
>> This is the second opus of this RFC. The goal is still to see how close our
>> ports are to see if there are things we could either reuse of change.
>> 
>> From RFCv1, the main change is cleaning up in function names and functions
>> grouping, and fixes to make v4l2-compliance happy while live tests still show no
>> regression.
>> 
>> For the next steps, I'll have to :
>>  - split the second patch, which will be a headache task, into :
>>    - first functions grouping and renaming
>>      => this to ensure the "internal functions" are almost untouched
>>    - the the port itself
>> 
>> I'm leaving soc_mediabus for now, that's another task.
>> 
>> I'm not seeing a big review traction, especially on the vb2 conversion, so I'll
>> leave this patchset in RFC form until vb2 patch is reviewed and merged, and then
>> will come back to this work.
>
> I have been trying on-and-off to convert the sh_mobile_ceu_camera to a regular
> driver with basically no success. One major problem is that the sh driver doesn't
> use the device tree, so I can't copy code from the new rcar-vin driver. The scaling
> and cropping code is also tightly coupled to soc-camera.
Yeah, I had the same problem and applied a rather "harsh solution" : amputation
:) I'll add back the cropping code later.

> It is of course possible to do given enough time, but I don't think it is worth it.
>
> So instead I am going for plan B: convert all other soc-camera drivers to 'regular'
> drivers so in the end soc-camera is only used by the sh driver. Then I can turn
> soc-camera into an sh driver, making it impossible for other drivers to use the
> framework.
Good plan.

> In other words, it would be great if you can continue this work, because after
> this driver is converted only the atmel-isi driver remains (besides the sh driver,
> of course).
Of course I will, I committed to. As long as I feel having feedback on the other
end I'll push until the conversion is complete, and beyond (ie. adding back lost
functionality and "beautifying the design"). It's very refreshing for my brain
to do this :)

I'll have more spare time in the comming monthes also, and as I'm doing this on
my spare time, that means more hours to dedicate to pxa maintainance.

Cheers.

-- 
Robert