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 who had
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 value is
On Thursday 10 December 2009 18:00:29 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
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
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) |
+
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
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 like
From: Muralidharan Karicheri m-kariche...@ti.com
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.
Also fixed a bug in the probe() in the linux-next tree
