Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 26 9月, 2012 3 次提交
  3. 16 8月, 2012 1 次提交
  5. 19 6月, 2012 1 次提交
  7. 12 6月, 2012 1 次提交
  9. 11 4月, 2012 1 次提交
    • A
      [media] Default bt878 contrast value · 961e668b
      由 Alan McIvor 提交于 
      The default_value for the Bt878 V4L2_CID_CONTRAST control is currently
set to 32768. Internally this gets translated to an analog input
circuit gain of 1.19. However, the default gain should be 1.0. This
patch alters the default value to 27648 which corresponds to a gain of
1.0. It also alters the probe routine so that the correct value is
written on board initialisation.

[mchehab@redhat.com: behavior confirmed via Fusion 878a datasheet]
Signed-off-by: NAlan McIvor <alan.mcivor@reveal.co.nz>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      961e668b
  11. 15 2月, 2012 1 次提交
    • H
      [media] v4l2: standardize log start/end message · e2ecb257
      由 Hans Verkuil 提交于 
      For drivers that properly use the v4l2 framework (i.e. set v4l2_dev in the
video_device struct), the start and end messages of VIDIOC_LOG_STATUS are
now generated automatically. People tended to forget these, but the v4l2-ctl
tool scans for these messages, and it also makes it easier to read the status
output in the kernel log.

The cx18, ivtv and bttv drivers were changed since they no longer need to
log these start/end messages.

In saa7164 two empty log_status functions were removed.

Also added a helper function to v4l2-ctrl.c that can be used as the
vidioc_log_status callback if all you need to do is to log the current control
values. This is now used by pwc and vivi.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Steven Toth <stoth@kernellabs.com>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e2ecb257
  13. 08 11月, 2011 1 次提交
  15. 04 9月, 2011 1 次提交
    • J
      [media] bt8xx: Use current logging styles · 8af443e5
      由 Joe Perches 提交于 
      This converts some messages that were emitted at
KERN_INFO to KERN_DEBUG.  All of these messages
were guarded by bttv_debug tests.

Add pr_fmt.
Convert printks to pr_<level>
Convert printks without KERN_<level> to appropriate pr_<level>.
Removed embedded prefixes when pr_fmt was added.
Whitespace cleanups when around other conversions.
Macros coded with if statements should be do { if... } while (0)
so the macros can be used in other if tests.
Use ##__VA_ARGS__ for variadic macro as well.
Coalesce format strings.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      8af443e5
  17. 28 7月, 2011 1 次提交
    • M
      [media] Stop using linux/version.h on most video drivers · 1990d50b
      由 Mauro Carvalho Chehab 提交于 
      All the modified drivers didn't have any version increment since
Jan, 1 2011. Several of them didn't have any version increment
for a long time, even having new features and important bug fixes
happening.

As we're now filling the QUERYCAP version with the current Kernel
Release, we don't need to maintain a per-driver version control
anymore. So, let's just use the default.

In order to preserve the Kernel module version history, a
KERNEL_VERSION() macro were added to all modified drivers, and
the extraver number were incremented.

I opted to preserve the per-driver version control to a few
pwc, pvrusb2, s2255, s5p-fimc and sh_vou.

A few drivers are still using the legacy way to handle ioctl's.
So, we can't do such change on them, otherwise, they'll break.
Those are: uvc, et61x251 and sn9c102.

The rationale is that the per-driver version control seems to be
actively maintained on those.

Yet, I think that the better for them would be to just use the
default version numbering, instead of doing that by themselves.

While here, removed a few uneeded include linux/version.h
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1990d50b
  19. 08 7月, 2011 1 次提交
  21. 20 5月, 2011 1 次提交
  23. 29 12月, 2010 3 次提交
  25. 24 12月, 2010 1 次提交
    • T
      media/video: explicitly flush request_module work · 707bcf32
      由 Tejun Heo 提交于 
      Video drivers request submodules using a work during probe and calls
flush_scheduled_work() on exit to make sure the work is complete
before being unloaded.  This patch makes these drivers flush the work
directly instead of using flush_scheduled_work().

While at it, relocate request_submodules() call in saa7134_initdev()
right right before successful return as in other drivers to avoid
failing after the work is scheduled and returning failure without the
work still active.

This is in preparation for the deprecation of flush_scheduled_work().
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      707bcf32
  27. 18 12月, 2010 2 次提交
  29. 18 11月, 2010 1 次提交
  31. 21 10月, 2010 5 次提交
  33. 19 5月, 2010 3 次提交
  35. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  37. 27 2月, 2010 1 次提交
  39. 19 2月, 2010 1 次提交
  41. 16 12月, 2009 5 次提交
  43. 07 11月, 2009 2 次提交
    • M
      V4L/DVB (13170): bttv: Fix reversed polarity error when switching video standard · 2de26c0a
      由 Mike Isely 提交于 
      The bttv driver function which handles switching of the video standard
(set_tvnorm() in bttv-driver.c) includes a check which can optionally
also reset the cropping configuration to a default value.  It is
"optional" based on a comparison of the cropcap parameters of the
previous vs the newly requested video standard.  The comparison is
being done with a memcmp(), a function which only returns a true value
if the comparison actually fails.

This if-statement appears to have been written to assume wrong
memcmp() semantics.  That is, it was re-initializing the cropping
configuration only if the new video standard did NOT have different
cropcap values.  That doesn't make any sense.  One definitely should
reset things if the cropcap parameters are different - if there's any
comparison to made at all.

The effect of this problem was that a transition from, say, PAL to
NTSC would leave in place old cropping setup that made sense for the
PAL geometry but not for NTSC.  If the application doesn't care about
cropping it also won't try to reset the cropping configuration,
resulting in an improperly cropped video frame.  In the case I was
testing this actually caused black video frames to be displayed.

Another interesting effect of this bug is that if one does something
which does NOT change the video standard and this function is run,
then the cropping setup gets reset anyway - again because of the
backwards comparison.  It turns out that just running anything which
merely opens and closes the video device node (e.g. v4l-info) will
cause this to happen.  One can argue that simply opening the device
node and not doing anything to it should not mess with any of its
state - but because of this behavior, any TV app which does such
things (e.g. xawtv) probably therefore doesn't see the problem.

The solution is to fix the sense of the if-statement.  It's easy to
see how this mistake could have been made given how memcmp() works.
The patch is therefore removal of a single "!" character from the
if-statement in set_tvnorm in bttv-driver.c.
Signed-off-by: NMike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      2de26c0a
    • M
      V4L/DVB (13169): bttv: Fix potential out-of-order field processing · 66349b4e
      由 Mike Isely 提交于 
      There is a subtle interaction in the bttv driver which can result in
fields being repeatedly processed out of order.  This is a problem
specifically when running in V4L2_FIELD_ALTERNATE mode (probably the
most common case).

1. The determination of which fields are associated with which buffers
happens in videobuf, before the bttv driver gets a chance to queue the
corresponding DMA.  Thus by the point when the DMA is queued for a
given buffer, the algorithm has to do the queuing based on the
buffer's already assigned field type - not based on which field is
"next" in the video stream.

2. The driver normally tries to queue both the top and bottom fields
at the same time (see bttv_irq_next_video()).  It tries to sort out
top vs bottom by looking at the field type for the next 2 available
buffers and assigning them appropriately.

3. However the bttv driver *always* actually processes the top field
first.  There's even an interrupt set aside for specifically
recognizing when the top field has been processed so that it can be
marked done even while the bottom field is still being DMAed.

Given all of the above, if one gets into a situation where
bttv_irq_next_video() gets entered when the first available buffer has
been pre-associated as a bottom field, then the function is going to
process the buffers out of order.  That first available buffer will be
put into the bottom field slot and the buffer after that will be put
into the top field slot.  Problem is, since the top field is always
processed first by the driver, then that second buffer (the one after
the first available buffer) will be the first one to be finished.
Because of the strict fifo handling of all video buffers, then that
top field won't be seen by the app until after the bottom field is
also processed.  Worse still, the app will get back the
chronologically later bottom field first, *before* the top field is
received.  The buffer's timestamps will even be backwards.

While not fatal to most TV apps, this behavior can subtlely degrade
userspace deinterlacing (probably will cause jitter).  That's probably
why it has gone unnoticed.  But it will also cause serious problems if
the app in question discards all but the latest received buffer (a
latency minimizing tactic) - causing one field to only ever be
displayed since the other is now always late.  Unfortunately once you
get into this state, you're stuck this way - because having consumed
two buffers, now the next time around the "first" available buffer
will again be a bottom field and the same thing happens.

How can we get into this state?  In a perfect world, where there's
always a few free buffers queued to the driver, it should be
impossible.  However if something disrupts streaming, e.g. if the
userspace app can't queue free buffers fast enough for a moment due
perhaps to a CPU scheduling glitch, then the driver can get
momentarily starved and some number of fields will be dropped.  That's
OK.  But if an odd number of fields get dropped, then that "first"
available buffer might be the bottom field and now we're stuck...

This patch fixes that problem by deliberately only setting up a single
field for one frame if we don't get a top field as the first available
buffer.  By purposely skipping the other field, then we only handle a
single buffer thus bringing things back into proper sync (i.e. top
field first) for the next frame.  To do this we just drop the few
lines in bttv_irq_next_video() that attempt to set up the second
buffer when that second buffer isn't for the bottom field.

This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode.  In
the other modes this change either has no effect or doesn't harm
things any further anyway.
Signed-off-by: NMike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      66349b4e
  45. 12 9月, 2009 2 次提交