Jonathan Corbet [Sat, 11 Jun 2011 17:46:44 +0000 (14:46 -0300)]
[media] marvell-cam: Pass sensor parameters from the platform
Depending on the controller, the ov7670 sensor may be told to work with a
different clock speed or to use the SMBUS protocol. Remove the wired-in
code and pass that information from the platform layer. The Cafe driver
now just assumes it's running on an OLPC XO 1; I do not believe it has ever
run anywhere else.
Cc: Daniel Drake <dsd@laptop.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jonathan Corbet [Sat, 11 Jun 2011 17:46:43 +0000 (14:46 -0300)]
[media] marvell-cam: Separate out the Marvell camera core
There will eventually be multiple users of the core camera controller, so
separate it from the bus/platform/i2c stuff. I've tried to do the minimal
set of changes to get the driver functioning in this configuration; I did
clean up a bunch of old checkpatch gripes in the process. This driver
works like the old one did on OLPC XO 1 systems.
Cc: Daniel Drake <dsd@laptop.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jonathan Corbet [Sat, 11 Jun 2011 17:46:42 +0000 (17:46 +0000)]
[media] marvell-cam: Move cafe-ccic into its own directory
This driver will soon become a family of drivers, so let's give it its own
place to live. This move requires putting ov7670.h into include/media, but
there are no code changes.
Cc: Daniel Drake <dsd@laptop.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch utility doesn't work with non-binary files. This causes some
tools to break, like generating tarball targets and the scripts that
generate diff patches at http://www.kernel.org/pub/linux/kernel/v2.6/.
So, let's convert all binaries to ascii using base64, and add a
logic at Makefile to convert them back into binaries at runtime.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Reported-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
David Härdeman [Thu, 28 Apr 2011 15:13:58 +0000 (12:13 -0300)]
[media] rc-core: lirc use unsigned int
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Revert "[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS"
Based on those feedback:
http://www.spinics.net/lists/linux-media/msg33704.html
http://www.spinics.net/lists/linux-media/msg33700.html
I'm reverting the removal of this unused ioctl, as it seems that some
drivers under development may be using. So, I'll wait until the next
merge window before removing those unused ioctls, to give a chance for
developers to submit their pending work.
[media] DocBook/video.xml: Document the remaining data structures
Now, all data structures are commented. A few ioctls remain undocumented:
Error: no ID for constraint linkend: VIDEO_GET_SIZE.
Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE.
Error: no ID for constraint linkend: VIDEO_GET_PTS.
Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT.
Error: no ID for constraint linkend: VIDEO_COMMAND.
Error: no ID for constraint linkend: VIDEO_TRY_COMMAND.
The av7110 uses an OSD API. Such API is not documented at all. Also,
the osd.h API uses camelCase and some other weird stuff. Also, dvb-core
doesn't recognize it.
I don't see any good reason why we should document it. It seems better
to just let it as-is. If ever needed, it is probably better to write
a different API for dvb-core.
[media] DocBook/net.xml: Synchronize Network data structure
There's no documentation at all for the DVB net API. Still, better to
remove a few warnings about the missing symbols. So, add the net data
structure inside the net.xml. Now, only the ioctl documentation is missed.
[media] DocBook/demux.xml: Add the remaining data structures to the API spec
Still, there are a few ioctl's not documented:
Error: no ID for constraint linkend: DMX_GET_PES_PIDS.
Error: no ID for constraint linkend: DMX_GET_CAPS.
Error: no ID for constraint linkend: DMX_SET_SOURCE.
Error: no ID for constraint linkend: DMX_ADD_PID.
Error: no ID for constraint linkend: DMX_REMOVE_PID.
[media] Docbook/ca.xml: match section ID's with the reference links
Make sure that both ca.h.xml and ca.xml will match the same names for
the sections/links.
This way, it is now possible to identify API spec gaps:
Error: no ID for constraint linkend: ca-pid.
Error: no ID for constraint linkend: ca-pid.
Error: no ID for constraint linkend: CA_RESET.
Error: no ID for constraint linkend: CA_GET_CAP.
Error: no ID for constraint linkend: CA_GET_SLOT_INFO.
Error: no ID for constraint linkend: CA_GET_DESCR_INFO.
Error: no ID for constraint linkend: CA_GET_MSG.
Error: no ID for constraint linkend: CA_SEND_MSG.
Error: no ID for constraint linkend: CA_SET_DESCR.
Error: no ID for constraint linkend: CA_SET_PID.
Basically, in this case, no CA ioctl is described at the specs, and one
file structure (ca-pid) is missing.
[media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
While this ioctl is defined inside dvb/audio.h, it is not docummented
at the API specs, nor implemented on any driver inside the Linux Kernel.
So, it doesn't make sense to keep it here.
As this is not used anywere, removing it is not a regression. So,
there's no need to use the normal features-to-be-removed process.
Although this ioctl is only used at the av7110 driver, it is not
described at the API docbook. Yet, AUDIO_PAUSE ioctl description
somewhat describes it. Fill the gap by using the information there
and by looking inside av7110 implementation.
[media] DocBook/audio.xml: match section ID's with the reference links
Make sure that both audio.h.xml and audio.xml will match the same names.
This way, it is now possible to identify API spec gaps:
Error: no ID for constraint linkend: AUDIO_CONTINUE.
Error: no ID for constraint linkend: AUDIO_GET_PTS.
Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT.
While here, fix the cut-and-paste description error on AUDIO_SET_KARAOKE.
[media] DocBook/dvbproperty.xml: Document the terrestrial delivery systems
Instead of repeating duplicate parameters to each delivery system,
just add a section for each specific delivery system, showing
what's applicable to each case. This helps userspace app developers
to know what DVB parameters are applicable to each delivery system.
[media] DocBook/frontend.xml: Recomend the usage of the new API
The old way of setting delivery system parameters were to use
an union with specific per-system parameters. However, as newer
delivery systems required more data, the structure size weren't
enough to fit. So, recomend using the DVBS2API instead.
[media] DocBook/dvbproperty.xml: Document the remaining S2API parameters
There were lots of DVB S2API parameters that were never documented.
Let's add a definition for all of them, based on what's currently
used inside the core and the drivers.
The description here is not complete nor perfect, so patches
improving it are welcome.
Various coding style changes:
- removed unused / commented out code
- changed C++ style comments to C format
- renamed functions and variables that included upper case letters in the name
- removed tabs from module parameter descriptions
- replaced the use of XC_RESULT_* with standard error codes
Istvan Varga [Sat, 4 Jun 2011 15:25:19 +0000 (12:25 -0300)]
[media] xc4000: detect also xc4100
Added code to detect the XC4100 chip, which is presumably an analog-only
"value" version of the XC4000. It is not sure, however, if any devices
using this have actually been produced and sold, so the patch may be
unneeded.
Istvan Varga [Sat, 4 Jun 2011 15:21:17 +0000 (12:21 -0300)]
[media] xc4000: removed redundant tuner reset
This patch causes the tuner reset command to be ignored in the firmware
code, since this only happens when the BASE/INIT1 firmware is loaded by
check_firmware(), and in that case check_firmware() already calls the
reset callback before starting to load the firmware.
Istvan Varga [Sat, 4 Jun 2011 15:15:51 +0000 (12:15 -0300)]
[media] xc4000: added audio_std module parameter
The 'audio_std' module parameter makes it possible to fine tune
some audio related aspects of the driver, like setting the exact
audio standard (NICAM, A2, etc.) to be used for some video standards.
Istvan Varga [Sat, 4 Jun 2011 15:12:42 +0000 (12:12 -0300)]
[media] xc4000: setting registers
This patch implements setting the registers in xc4000_set_params()
and xc4000_set_analog_params(). A new register is defined which enables
filtering of the composite video output (this is needed to avoid bad
picture quality with some boards).
Istvan Varga [Sat, 4 Jun 2011 15:08:29 +0000 (12:08 -0300)]
[media] xc4000: debug message improvements
The following patch makes a few minor changes to the printing
of debug messages, and reporting the tuner status. The 'debug'
module parameter can now be set from 0 to 2 to control the
verbosity of debug messages.
Istvan Varga [Sat, 4 Jun 2011 15:03:03 +0000 (12:03 -0300)]
[media] xc4000: implemented power management
The following patch implements the xc4000_sleep() function.
The 'no_powerdown' module parameter is now interpreted differently:
- 0 uses a device-specific default
- 1 disables power management like before
- 2 enables power management
Istvan Varga [Sat, 4 Jun 2011 14:59:54 +0000 (11:59 -0300)]
[media] xc4000: check_firmware() cleanup
This patch makes the following fixes in check_firmware():
- there is only one BASE and INIT1 firmware for XC4000
- loading SCODE is needed also for FM radio
Istvan Varga [Fri, 3 Jun 2011 15:27:30 +0000 (12:27 -0300)]
[media] xc4000: fixed frequency error
The xc_get_frequency_error() function reported the frequency error
incorrectly. The data read from the hardware is a signed integer, in
15625 Hz units. The attached patch fixes the bug.
Istvan Varga [Fri, 3 Jun 2011 13:55:24 +0000 (10:55 -0300)]
[media] xc4000: updated standards table
This patch makes the following changes to the standards table:
- added 'u16 int_freq' to struct XC_TV_STANDARD (needed for analog TV
and radio, 0 for DVB-T)
- added new standard for SECAM-D/K video with PAL-D/K audio
- the 'int_freq' values are now specified in the table
- changed VideoMode for NTSC and PAL-B/G standards
Istvan Varga [Fri, 3 Jun 2011 13:11:48 +0000 (10:11 -0300)]
[media] xc4000: code cleanup
This is the first of a set of patches that update the original xc4000
sources to my modified version. It removes some unused code, and makes
a few minor formatting changes.
Based on a reference trace under Windows, reverse engineer the PLL config.
Note that the xtal is not yet setup, and the timf cannot be determined yet
because my reference trace doesn't actually achieve a signal lock.
It was confirmed by DibCom that i2c stretching is broken in the i2c master
on the dib7700. So we need to put a hack into the xc4000 driver to not
complain in certain very specific cases where we know i2c stretching occurs.
[media] xc4000: continued cleanup of the firmware loading routine
Properly setup the standard firmware loading and scode loading, as well as
getting rid of a ton of dead code. Note that I am getting a single i2c
error when the standard firmware sets the video standard, but everything else
seems to be loading properly now.
[media] xc4000: add code to do standard and scode firmware loading
Add code to handle firmware blobs for the standard and scode. Note there
appears to be some issue with loading the DTV8 standard firmware, probably
related to direct/indirect mode.
Since we use the xc3028 version of the firmware file parsing routine (which
includes support for scodes and separate blobs), we can drop the xc5000
version of the code.
[media] xc4000: remove XREG_BUSY code only supported in xc5000
The xc4000 driver is based on the original xc5000 driver, and while the
xc5000 supports the XREG_BUSY register, the xc4000 does not. So remove the
code in question.
[media] xc4000: cut over to using xc5000 version for loading i2c sequences
The xc3028 version does i2c splitting in a different manner than xc4000 and
xc5000, so reuse the xc5000 version of the routine (the key here being that
xc4000 expects the first *two* bytes to be the same for splitting transactions.
Doing it the xc3028 way was resulting in i2c errors partially through the
firmware load. With this change, it would appear that the entire base firmware
is being loaded successfully (product id now properly shows 0x0FA0).
Add the board profile for the PCTV 340eSE, since that's what I have here
for development.
[mchehab@redhat.com: rebased on the top of the current tree] Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Davide Ferri [Wed, 24 Jun 2009 01:34:06 +0000 (22:34 -0300)]
[media] dib0700: add initial code for PCTV 340e by Davide Ferri
This is initial code written by Davide Ferri for the PCTV 340e, including
a new xc4000 driver. I am checking in all the code unmodified, and making
no assertions about its quality (other than confirming it compiles).
[mchehab@redhat.com: rebased on the top of the current tree] Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Davide Ferri <davidef1986@gmail.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The implementation of the gain calculation for this sensor is incorrect.
It is only working for the first 127 values.
The reason is, that the gain cannot be set directly by writing a value
into the gain registers of the sensor. The gain register work this way
(see datasheet page 24): bits 0 to 6 are called "initial gain". These
are linear. But bits 7 and 8 ("analog multiplicative factors") and bits
9 and 10 ("digital multiplicative factors") work completely different:
Each of these bits increase the gain by the factor 2. So if the bits
7-10 are 0011, 0110, 1100 or 0101 for example, the gain from bits 0-6 is
multiplied by 4. The order of the bits 7-10 is not important for the
resulting gain. (But there are some recommended values for low noise)
The current driver doesn't do this correctly: If the current gain is 000
0111 1111 (127) and the gain is increased by 1, you would expect the
image to become brighter. But the image is completly dark, because the
new gain is 000 1000 0000 (128). This means: Initial gain of 0,
multiplied by 2. The result is 0.
This patch adds a new function which does the gain calculation and also
fixes the same bug for red_balance and blue_balance. Additionally, the
driver follows the recommendation from the datasheet, which says, that
the gain should always be above 0x0020.
There are problems when you use this camera/sensor in a very bright room
or outside. The image is completely white, because it is overexposed.
The driver uses a default value which is not suitable for all
environments.
This patch makes it possible to adjust the exposure time by youself. I
found out by logging the i2c-data, that the windows driver for this
sensor is doing this, too. I tested the camera on a sunny day and after
adjusting the exposure time, I was able to see a very good image.
[media] mt9v011: Fixed incorrect value for the first valid column
According to the datasheet (page 8), the first optical clear
pixel-column is not at position 14. The correct/recommended value is 20.
Without this patch there is a dark line on the left side of the image.
David Härdeman [Wed, 30 Mar 2011 14:20:14 +0000 (11:20 -0300)]
[media] rc-core: fix winbond-cir issues
The conversion of winbond-cir to use rc-core seems to have missed a
a few bits and pieces which were in my local tree. Kudos to
Juan Jesús García de Soria Lucena <skandalfo@gmail.com> for noticing.
[mchehab@redhat.com: fix two UTF-8 violations] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Dan Carpenter [Thu, 26 May 2011 08:52:01 +0000 (05:52 -0300)]
[media] rc: double unlock in rc_register_device()
If change_protocol() fails and we goto out_raw, then it calls unlock
twice. I noticed that the other time we called change_protocol() we
held the &dev->lock, so I changed it to hold it here too.
Reviewed-by: Jarod Wilson <jarod@redhat.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
projects / mv-sheeva.git / log