Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 10月, 2010 2 次提交
  3. 19 5月, 2010 3 次提交
  5. 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
  7. 27 2月, 2010 1 次提交
  9. 19 2月, 2010 1 次提交
  11. 16 12月, 2009 5 次提交
  13. 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
  15. 12 9月, 2009 2 次提交
  17. 25 7月, 2009 1 次提交
  19. 13 7月, 2009 1 次提交
  21. 17 6月, 2009 3 次提交
  23. 07 4月, 2009 3 次提交
  25. 30 3月, 2009 11 次提交
    • H
      V4L/DVB (11278): bttv: convert to v4l2_subdev since i2c autoprobing will disappear. · 859f0277
      由 Hans Verkuil 提交于 
      Since i2c autoprobing will disappear bttv needs to be converted to use
v4l2_subdev instead.

Without autoprobing the autoload module option has become obsolete. A warning
is generated if it is set, but it is otherwise ignored.

Since the bttv card definitions are of questionable value a new option was
introduced to allow the user to control which audio module is selected:
msp3400, tda7432 or tvaudio (or none at all).

By default bttv will use the card definitions and fallback on tvaudio as the
last resort.

If no audio device was found a warning is printed.

The saa6588 RDS device is now also explicitly probed since it is no longer
possible to autoprobe it. A new saa6588 module option was added to override
the card definition since I suspect more cards have this device than one
would guess from the card definitions.

Note that the probe addresses of the i2c modules are hardcoded in this
driver. Once all v4l drivers are converted to v4l2_subdev this will be
cleaned up. Such data belongs in an i2c driver header.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      859f0277
    • T
      V4L/DVB (11262): bttv: Remove buffer type check from vidioc_g_parm · 601bc298
      由 Trent Piepho 提交于 
      The v4l2-ioctl core only allows buffer types for which the corresponding
->vidioc_try_fmt_xxx() methods are defined to be used with
vidioc_(q|dq|query)bufs(), vidioc_reqbufs() and now vidioc_(s|g)_parm.

The driver was only allowing VIDEO_CAPTURE buffers for g_parm, but since
the driver defines ->vidioc_try_fmt_vid_overlay() and
->vidioc_try_fmt_vbi_cap() it will now allow VIDEO_OVERLAY and VBI_CAPTURE
buffers as well.  This should be fine as the driver only fills in the frame
rate field, which is just as valid for video overlay and vbi capture as it
is for video capture.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      601bc298
    • H
      V4L/DVB (11046): bttv: convert to v4l2_device. · 74fc7bd9
      由 Hans Verkuil 提交于 
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      74fc7bd9
    • T
      V4L/DVB (10815): bttv: Don't need to zero ioctl parameter fields · 522a5f14
      由 Trent Piepho 提交于 
      The v4l2 core code in v4l2_ioctl will zero out the structure the driver is
supposed to fill in for read-only ioctls.  For read/write ioctls, all the
fields which aren't supplied from userspace will be zeroed out.

Zeroing code is removed from enum_input and g_tuner.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      522a5f14
    • T
      V4L/DVB (10813): v4l2: New function v4l2_video_std_frame_period · 51f0b8d5
      由 Trent Piepho 提交于 
      Some code was calling v4l2_video_std_construct() when all it cared about
was the frame period.  So make a function that just returns that and have
v4l2_video_std_construct() use it.

At this point there are no users of v4l2_video_std_construct() left outside
of v4l2-ioctl, so it could be un-exported and made static.

Change v4l2_video_std_construct() so that it doesn't zero out the struct
v4l2_standard passed in.  It's already been zeroed out in the common ioctl
code.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      51f0b8d5
    • T
      V4L/DVB (10568): bttv: dynamically allocate device data · 4b10d3b6
      由 Trent Piepho 提交于 
      The bttv driver had static array of structures for up to 16 possible bttv
devices, even though few users have more than one or two.  The structures
were quite large and this resulted in a huge BSS segment.

Change the driver to allocate the bttv device data dynamically, which
changes "struct bttv bttvs[BTTV_MAX]" to "struct bttv *bttvs[BTTV_MAX]".
It would be nice to get ride of "bttvs" entirely but there are some
complications with gpio access from the audio & mpeg drivers.

To help bttvs removal along anyway, I changed the open() methods use the
video device's drvdata to get the driver data instead of looking it up in
the bttvs array.  This is also more efficient.  Some WARN_ON()s are added
in cases the device node exists by the bttv device doesn't, which I don't
think should be possible.

The gpio access functions need to check if bttvs[card] is NULL now.  Though
calling them on a non-existent card in the first place is wrong, but hard
to solve given the fundamental problems in how the gpio access code works.

This patch reduces the bss size by 66560 bytes on ia32.  Overall change is a
reduction of 66398 bytes, as the WARN_ON()s add some 198 bytes.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      4b10d3b6
    • T
      V4L/DVB (10567): bttv: shrink muxsel data in card database · 6f98700a
      由 Trent Piepho 提交于 
      Over half of the card database was used to store muxsel data.  64 bytes
were used to store one 32 bit word for each of up to 16 inputs.

The Bt8x8 only has two bits to control its mux, so muxsel data for 16
inputs will fit into a single 32 bit word.  There were a couple cards that
had special muxsel data that didn't fit in two bits, but I cleaned them up
in earlier patches.

Unfortunately, C doesn't allow us to have an array of bit fields.  This
makes initializing the structure more of a pain.  But with some cpp magic,
we can do it by changing:
	.muxsel = { 2, 3, 0, 1 },
	.muxsel = { 2, 2, 2, 2, 3, 3, 3, 3, 1, 1 },
Into:
	.muxsel = MUXSEL(2, 3, 0, 1),
	.muxsel = MUXSEL(2, 2, 2, 2, 3, 3, 3, 3, 1, 1),

That's not so bad.  MUXSEL is a fancy macro that packs the arguments (of
which there can be one to sixteen!) into a single word two bits at a time.
It's a compile time constant (a variadic function wouldn't be) so we can
use it to initialize the structure.  It's important the the arguments to
the macro only be plain decimal integers.  Stuff like "0x01", "(2)", or
"MUX3" won't work properly.

I also created an accessor function, bttv_muxsel(btv, input), that gets the
mux bits for the selected input.  It makes it cleaner to change the way the
muxsel data is stored.

This patch doesn't change the code size and decreases the datasegment by
9440 bytes.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      6f98700a
    • T
      V4L/DVB (10562): bttv: rework the way digital inputs are indicated · 5221e21e
      由 Trent Piepho 提交于 
      The code was using a muxsel value of -1U to indicate a digital input.  A
couple places in were checking of muxsel < 0 to detect this, which doesn't
work of course because muxsel is unsigned and can't be negative.

Only a couple cards had digital inputs and it was always the last one, so
for the card database create a one bit field that indicates the last input
is digital.  On init, this is used to set a new field in the bttv struct to
the digital input's number or UNSET for none.  This makes it easier to
check if the current input is digital.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5221e21e
    • T
      V4L/DVB (10560): bttv: make tuner card info more consistent · abb0362f
      由 Trent Piepho 提交于 
      The bttv card database structure had a "tuner" field that was the input
number of the tuner input or UNSET for no tuner.  However, the only values
it could ever be are 0 and UNSET.  Having a tuner on an input other than 0
didn't work and was never used.

There is also a "tuner_type" field that can be set to TUNER_ABSENT to
indicate no tuner, which makes "tuner = UNSET" redundant.  In many cases,
tuner_type was set to UNSET when there was no tuner, which isn't quite
correct.  tuner_type == UNSET is supposed to mean the tuner type isn't yet
known.

So, I changed cards where "tuner == UNSET" to always have tuner_type of
TUNER_ABSENT.  At this point the tuner field is redundant, so I deleted it.

I have the card setup code set the card's tuner_type (not the card type's
tuner_type!) to TUNER_ABSENT if it hasn't yet been set at the end of the
setup code.  Various places that check if the card has a tuner will now
look for this instead of checking the card type's "tuner" field.

Also autoload the tuner module before issuing the TUNER_SET_TYPE_ADDR I2C
client call instead of after issuing it.

Overall, on ia32 this decreases compiled code size by about 24 bytes and
reduces the data size by 640 bytes.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      abb0362f
    • T
      V4L/DVB (10559): bttv: Fix TDA9880 norm setting code · 72134a6d
      由 Trent Piepho 提交于 
      The code to set the norm for the TDA9880 analog demod was comparing
btv->norm, an index into the bttv driver's norm array, to V4L2_STD_NTSC,
which is a bit flag that's part of the V4L2 API.  This doesn't work of
course and results in the PAL path always being taken.

What's more, it modified the bttv_tvcards[] entries for cards using the
TDA9880.  This is wrong because changing the norm on one card will also
affect other cards of the same type.  Writing to bttv_tvcards is also bad
because it should be read-only or even devinitdata.

Changing the norm would also cause the audio to become unmuted.

Have the code get called for both norm setting and audio input setting
(which where the gpios are set) to avoid needed to modify bttv_tvcards.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      72134a6d
    • T
      V4L/DVB (10558): bttv: norm value should be unsigned · 4ef2ccc2
      由 Trent Piepho 提交于 
      The norm value in the driver is an index into an array and the the driver
doesn't allow it to be negative or otherwise invalid.  It should be
unsigned but wasn't in all places.

Fix some structs and functions to have the norm be unsigned.  Get rid of
useless checks for "< 0".  Most of the driver code can't handle a norm
value that's out of range, so change some ">= BTTV_TVNORMS" checks to
BUG_ON().  There's no point in silently ignoring invalid driver state just
to crash because of it later.
Reported-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      4ef2ccc2
  27. 03 1月, 2009 3 次提交
  29. 22 10月, 2008 1 次提交
    • H
      V4L/DVB (9327): v4l: use video_device.num instead of minor in video%d · c6330fb8
      由 Hans Verkuil 提交于 
      The kernel number of a v4l2 node (e.g. videoX, radioX or vbiX) is now
independent of the minor number. So instead of using the minor field
of the video_device struct one has to use the num field: this always
contains the kernel number of the device node.

I forgot about this when I did the v4l2 core change, so this patch
converts all drivers that use it in one go. Luckily the change is
trivial.

Cc: michael@mihu.de
Cc: mchehab@infradead.org
Cc: corbet@lwn.net
Cc: luca.risolia@studio.unibo.it
Cc: isely@pobox.com
Cc: pe1rxq@amsat.org
Cc: royale@zerezo.com
Cc: mkrufky@linuxtv.org
Cc: stoth@linuxtv.org
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c6330fb8