[ATTN] Please review/check the REVIEWv4 compound control patch series

[ATTN] Please review/check the REVIEWv4 compound control patch series

[Hans Verkuil]

Mauro & anyone else with an interest,

I'd appreciate it if this patch series was reviewed, in particular
with respect to the handling of multi-dimensional arrays:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg75929.html

This patch series incorporates all comments from the REVIEWv3 series
except for two (see the cover letter of the patch series for details),

If support for arrays with more than 8 dimensions is really needed,
then I would like to know asap so I can implement that in time for
3.17.

Regards,

	Hans

Re: [ATTN] Please review/check the REVIEWv4 compound control patch series

[Ricardo Ribalda Delgado]

Hello Hans

I am planning to test this patchset for dead pixels by the end of this
week and the beggining of the next. I am thinking about comparing the
performance a list of deadpixels against a list of all pixels with
their property (ok pixel, dead pixel, white pixel, slow pixel...)

Will write back (hopefully) soon

Regards!

On Thu, Jun 12, 2014 at 2:08 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Mauro & anyone else with an interest,
>
> I'd appreciate it if this patch series was reviewed, in particular
> with respect to the handling of multi-dimensional arrays:
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg75929.html
>
> This patch series incorporates all comments from the REVIEWv3 series
> except for two (see the cover letter of the patch series for details),
>
> If support for arrays with more than 8 dimensions is really needed,
> then I would like to know asap so I can implement that in time for
> 3.17.
>
> Regards,
>
>         Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Ricardo Ribalda

Re: [ATTN] Please review/check the REVIEWv4 compound control patch series

[Ricardo Ribalda Delgado]

Hello Hans


Guess it is too late, but just so you know. I have successfully uses
this patches to implement a dead pixel array list.

Tested-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>
Thanked-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>  :)

Thanks!

On Thu, Jul 17, 2014 at 3:56 PM, Ricardo Ribalda Delgado
<ricardo.ribalda@gmail.com> wrote:
> Hello Hans
>
> I am planning to test this patchset for dead pixels by the end of this
> week and the beggining of the next. I am thinking about comparing the
> performance a list of deadpixels against a list of all pixels with
> their property (ok pixel, dead pixel, white pixel, slow pixel...)
>
> Will write back (hopefully) soon
>
> Regards!
>
> On Thu, Jun 12, 2014 at 2:08 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> Mauro & anyone else with an interest,
>>
>> I'd appreciate it if this patch series was reviewed, in particular
>> with respect to the handling of multi-dimensional arrays:
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg75929.html
>>
>> This patch series incorporates all comments from the REVIEWv3 series
>> except for two (see the cover letter of the patch series for details),
>>
>> If support for arrays with more than 8 dimensions is really needed,
>> then I would like to know asap so I can implement that in time for
>> 3.17.
>>
>> Regards,
>>
>>         Hans
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Ricardo Ribalda



-- 
Ricardo Ribalda

Re: [ATTN] Please review/check the REVIEWv4 compound control patch series

[Hans Verkuil]

Hi Ricardo,

On 07/25/14 13:52, Ricardo Ribalda Delgado wrote:
> Hello Hans
> 
> 
> Guess it is too late, but just so you know. I have successfully uses
> this patches to implement a dead pixel array list.
> 
> Tested-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>
> Thanked-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>  :)

Nevertheless nice to hear about this!

BTW, are you planning on upstreaming this driver? Or do you need to
have multi-selection support first? That needs the compound control
support as well, so at least it's closer to becoming a reality.

Regards,

	Hans

> 
> Thanks!
> 
> On Thu, Jul 17, 2014 at 3:56 PM, Ricardo Ribalda Delgado
> <ricardo.ribalda@gmail.com> wrote:
>> Hello Hans
>>
>> I am planning to test this patchset for dead pixels by the end of this
>> week and the beggining of the next. I am thinking about comparing the
>> performance a list of deadpixels against a list of all pixels with
>> their property (ok pixel, dead pixel, white pixel, slow pixel...)
>>
>> Will write back (hopefully) soon
>>
>> Regards!
>>
>> On Thu, Jun 12, 2014 at 2:08 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> Mauro & anyone else with an interest,
>>>
>>> I'd appreciate it if this patch series was reviewed, in particular
>>> with respect to the handling of multi-dimensional arrays:
>>>
>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg75929.html
>>>
>>> This patch series incorporates all comments from the REVIEWv3 series
>>> except for two (see the cover letter of the patch series for details),
>>>
>>> If support for arrays with more than 8 dimensions is really needed,
>>> then I would like to know asap so I can implement that in time for
>>> 3.17.
>>>
>>> Regards,
>>>
>>>         Hans
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Ricardo Ribalda
> 
> 
> 

Re: [ATTN] Please review/check the REVIEWv4 compound control patch series

[Ricardo Ribalda Delgado]

Hello Hans

I still need the multiselection support first. Right now it is done by
a modified g/s_selection ioctl.

I would love to upstream the driver, but maybe it is not the right
moment right now. We are selling a mainly to a couple of customers and
the total size of the drivers is > 16000 lines of code, plus 200 MB in
firmware files.

Once we are ready to launch the product to a wider market we will
upstream it, now it will just annoy a lot of people.

Thanks



On Fri, Jul 25, 2014 at 1:56 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Hi Ricardo,
>
> On 07/25/14 13:52, Ricardo Ribalda Delgado wrote:
>> Hello Hans
>>
>>
>> Guess it is too late, but just so you know. I have successfully uses
>> this patches to implement a dead pixel array list.
>>
>> Tested-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>
>> Thanked-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>  :)
>
> Nevertheless nice to hear about this!
>
> BTW, are you planning on upstreaming this driver? Or do you need to
> have multi-selection support first? That needs the compound control
> support as well, so at least it's closer to becoming a reality.
>
> Regards,
>
>         Hans
>
>>
>> Thanks!
>>
>> On Thu, Jul 17, 2014 at 3:56 PM, Ricardo Ribalda Delgado
>> <ricardo.ribalda@gmail.com> wrote:
>>> Hello Hans
>>>
>>> I am planning to test this patchset for dead pixels by the end of this
>>> week and the beggining of the next. I am thinking about comparing the
>>> performance a list of deadpixels against a list of all pixels with
>>> their property (ok pixel, dead pixel, white pixel, slow pixel...)
>>>
>>> Will write back (hopefully) soon
>>>
>>> Regards!
>>>
>>> On Thu, Jun 12, 2014 at 2:08 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>> Mauro & anyone else with an interest,
>>>>
>>>> I'd appreciate it if this patch series was reviewed, in particular
>>>> with respect to the handling of multi-dimensional arrays:
>>>>
>>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg75929.html
>>>>
>>>> This patch series incorporates all comments from the REVIEWv3 series
>>>> except for two (see the cover letter of the patch series for details),
>>>>
>>>> If support for arrays with more than 8 dimensions is really needed,
>>>> then I would like to know asap so I can implement that in time for
>>>> 3.17.
>>>>
>>>> Regards,
>>>>
>>>>         Hans
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> --
>>> Ricardo Ribalda
>>
>>
>>
>



-- 
Ricardo Ribalda

Re: [ATTN] Please review/check the REVIEWv4 compound control patch series

[Hans Verkuil]

On 07/25/14 14:09, Ricardo Ribalda Delgado wrote:
> Hello Hans
> 
> I still need the multiselection support first. Right now it is done by
> a modified g/s_selection ioctl.
> 
> I would love to upstream the driver, but maybe it is not the right
> moment right now. We are selling a mainly to a couple of customers and
> the total size of the drivers is > 16000 lines of code, plus 200 MB in
> firmware files.

I was thinking of just the sensor driver, not the other components.
That would provide a proper use-case for both the dead pixel array
and multi-selection.

I assume that the sensor driver is a lot smaller? Does it need fw as well?

Regards,

	Hans

> 
> Once we are ready to launch the product to a wider market we will
> upstream it, now it will just annoy a lot of people.
> 
> Thanks
> 
> 
> 
> On Fri, Jul 25, 2014 at 1:56 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> Hi Ricardo,
>>
>> On 07/25/14 13:52, Ricardo Ribalda Delgado wrote:
>>> Hello Hans
>>>
>>>
>>> Guess it is too late, but just so you know. I have successfully uses
>>> this patches to implement a dead pixel array list.
>>>
>>> Tested-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>
>>> Thanked-by: Ricardo Ribalda <ricardo.ribalda@gmail.com>  :)
>>
>> Nevertheless nice to hear about this!
>>
>> BTW, are you planning on upstreaming this driver? Or do you need to
>> have multi-selection support first? That needs the compound control
>> support as well, so at least it's closer to becoming a reality.
>>
>> Regards,
>>
>>         Hans
>>
>>>
>>> Thanks!
>>>
>>> On Thu, Jul 17, 2014 at 3:56 PM, Ricardo Ribalda Delgado
>>> <ricardo.ribalda@gmail.com> wrote:
>>>> Hello Hans
>>>>
>>>> I am planning to test this patchset for dead pixels by the end of this
>>>> week and the beggining of the next. I am thinking about comparing the
>>>> performance a list of deadpixels against a list of all pixels with
>>>> their property (ok pixel, dead pixel, white pixel, slow pixel...)
>>>>
>>>> Will write back (hopefully) soon
>>>>
>>>> Regards!
>>>>
>>>> On Thu, Jun 12, 2014 at 2:08 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>> Mauro & anyone else with an interest,
>>>>>
>>>>> I'd appreciate it if this patch series was reviewed, in particular
>>>>> with respect to the handling of multi-dimensional arrays:
>>>>>
>>>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg75929.html
>>>>>
>>>>> This patch series incorporates all comments from the REVIEWv3 series
>>>>> except for two (see the cover letter of the patch series for details),
>>>>>
>>>>> If support for arrays with more than 8 dimensions is really needed,
>>>>> then I would like to know asap so I can implement that in time for
>>>>> 3.17.
>>>>>
>>>>> Regards,
>>>>>
>>>>>         Hans
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> --
>>>> Ricardo Ribalda
>>>
>>>
>>>
>>
> 
> 
> 

Re: [ATTN] Please review/check the REVIEWv4 compound control patch series

[Ricardo Ribalda Delgado]

Hi Hans!

> I was thinking of just the sensor driver, not the other components.
> That would provide a proper use-case for both the dead pixel array
> and multi-selection.
>
> I assume that the sensor driver is a lot smaller? Does it need fw as well?
>

We support multiple sensors. The one that requires dead-pixel
correction is: FPA-320x256-C

Unfortunately, the chip only outputs the data as an analog output. The
data is processed by an FPGA. The FPGA requires firmware (the
bitstream).

I guess most of the code is useless for anybody else, if they don't
have access to the proper hw.

Thanks

Ricardo