On Wed, Dec 16, 2009 at 13:11:57, Hans Verkuil wrote:
> On Wednesday 16 December 2009 00:37:52 Karicheri, Muralidharan wrote:
> > Hans,
> >
> > I remember there was a comment against an earlier patch that asks
> > for combining such statements since it makes the function appear
> > as big. Not sure
hans,
>>
>> Yes, isif_config_bclamp() set values in the register.
>
>Huh? That does not explain why apparently bc->horz.win_h_sz_calc can be
>larger
>than ISIF_HORZ_BC_WIN_H_SIZE_MASK.
because the values come from the user and since we can't use the enum
for the types, I have to make sure the valu
On Wednesday 16 December 2009 00:37:52 Karicheri, Muralidharan wrote:
> Hans,
>
> I remember there was a comment against an earlier patch that asks
> for combining such statements since it makes the function appear
> as big. Not sure who had made that comment. That is the reason you
> find code li
Hans,
I remember there was a comment against an earlier patch that asks
for combining such statements since it makes the function appear
as big. Not sure who had made that comment. That is the reason you
find code like this in this patch. It was initially done with multiple
OR statements to constr
Note that the other patches from this series are fine as far as I am concerned.
One general note: I always have difficulties with constructions like this:
> + val = (bc->horz.win_count_calc &
> + ISIF_HORZ_BC_WIN_COUNT_MASK) |
> +
On Thursday 10 December 2009 18:00:29 m-kariche...@ti.com wrote:
> From: Muralidharan Karicheri
>
> Added a experimental IOCTL, to read the CCDC parameters.
> Default handler was not getting the original pointer from the core.
> So a wrapper function added to handle the default handler properly.
