-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel…
…/git/mchehab/linux-2.6 * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (313 commits) V4L/DVB (9186): Added support for Prof 7300 DVB-S/S2 cards V4L/DVB (9185): S2API: Ensure we have a reasonable ROLLOFF default V4L/DVB (9184): cx24116: Change the default SNR units back to percentage by default. V4L/DVB (9183): S2API: Return error of the caller provides 0 commands. V4L/DVB (9182): S2API: Added support for DTV_HIERARCHY V4L/DVB (9181): S2API: Add support fot DTV_GUARD_INTERVAL and DTV_TRANSMISSION_MODE V4L/DVB (9180): S2API: Added support for DTV_CODE_RATE_HP/LP V4L/DVB (9179): S2API: frontend.h cleanup V4L/DVB (9178): cx24116: Add module parameter to return SNR as ESNO. V4L/DVB (9177): S2API: Change _8PSK / _16APSK to PSK_8 and APSK_16 V4L/DVB (9176): Add support for DvbWorld USB cards with STV0288 demodulator. V4L/DVB (9175): Remove NULL pointer in stb6000 driver. V4L/DVB (9174): Allow custom inittab for ST STV0288 demodulator. V4L/DVB (9173): S2API: Remove the hardcoded command limit during validation V4L/DVB (9172): S2API: Bugfix related to DVB-S / DVB-S2 tuning for the legacy API. V4L/DVB (9171): S2API: Stop an OOPS if illegal commands are dumped in S2API. V4L/DVB (9170): cx24116: Sanity checking to data input via S2API to the cx24116 demod. V4L/DVB (9169): uvcvideo: Support two new Bison Electronics webcams. V4L/DVB (9168): Add support for MSI TV@nywhere Plus remote V4L/DVB: v4l2-dev: remove duplicated #include ...
- Loading branch information
Showing
377 changed files
with
29,913 additions
and
6,866 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
This document describes the ALi m5602 bridge connected | ||
to the following supported sensors: | ||
OmniVision OV9650, | ||
Samsung s5k83a, | ||
Samsung s5k4aa, | ||
Micron mt9m111, | ||
Pixel plus PO1030 | ||
|
||
This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution. | ||
In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats | ||
|
||
Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,120 @@ | ||
Soc-Camera Subsystem | ||
==================== | ||
|
||
Terminology | ||
----------- | ||
|
||
The following terms are used in this document: | ||
- camera / camera device / camera sensor - a video-camera sensor chip, capable | ||
of connecting to a variety of systems and interfaces, typically uses i2c for | ||
control and configuration, and a parallel or a serial bus for data. | ||
- camera host - an interface, to which a camera is connected. Typically a | ||
specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH, | ||
AVR32, i.MX27, i.MX31. | ||
- camera host bus - a connection between a camera host and a camera. Can be | ||
parallel or serial, consists of data and control lines, e.g., clock, vertical | ||
and horizontal synchronization signals. | ||
|
||
Purpose of the soc-camera subsystem | ||
----------------------------------- | ||
|
||
The soc-camera subsystem provides a unified API between camera host drivers and | ||
camera sensor drivers. It implements a V4L2 interface to the user, currently | ||
only the mmap method is supported. | ||
|
||
This subsystem has been written to connect drivers for System-on-Chip (SoC) | ||
video capture interfaces with drivers for CMOS camera sensor chips to enable | ||
the reuse of sensor drivers with various hosts. The subsystem has been designed | ||
to support multiple camera host interfaces and multiple cameras per interface, | ||
although most applications have only one camera sensor. | ||
|
||
Existing drivers | ||
---------------- | ||
|
||
As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for | ||
PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers: | ||
mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This | ||
list is not supposed to be updated, look for more examples in your tree. | ||
|
||
Camera host API | ||
--------------- | ||
|
||
A host camera driver is registered using the | ||
|
||
soc_camera_host_register(struct soc_camera_host *); | ||
|
||
function. The host object can be initialized as follows: | ||
|
||
static struct soc_camera_host pxa_soc_camera_host = { | ||
.drv_name = PXA_CAM_DRV_NAME, | ||
.ops = &pxa_soc_camera_host_ops, | ||
}; | ||
|
||
All camera host methods are passed in a struct soc_camera_host_ops: | ||
|
||
static struct soc_camera_host_ops pxa_soc_camera_host_ops = { | ||
.owner = THIS_MODULE, | ||
.add = pxa_camera_add_device, | ||
.remove = pxa_camera_remove_device, | ||
.suspend = pxa_camera_suspend, | ||
.resume = pxa_camera_resume, | ||
.set_fmt_cap = pxa_camera_set_fmt_cap, | ||
.try_fmt_cap = pxa_camera_try_fmt_cap, | ||
.init_videobuf = pxa_camera_init_videobuf, | ||
.reqbufs = pxa_camera_reqbufs, | ||
.poll = pxa_camera_poll, | ||
.querycap = pxa_camera_querycap, | ||
.try_bus_param = pxa_camera_try_bus_param, | ||
.set_bus_param = pxa_camera_set_bus_param, | ||
}; | ||
|
||
.add and .remove methods are called when a sensor is attached to or detached | ||
from the host, apart from performing host-internal tasks they shall also call | ||
sensor driver's .init and .release methods respectively. .suspend and .resume | ||
methods implement host's power-management functionality and its their | ||
responsibility to call respective sensor's methods. .try_bus_param and | ||
.set_bus_param are used to negotiate physical connection parameters between the | ||
host and the sensor. .init_videobuf is called by soc-camera core when a | ||
video-device is opened, further video-buffer management is implemented completely | ||
by the specific camera host driver. The rest of the methods are called from | ||
respective V4L2 operations. | ||
|
||
Camera API | ||
---------- | ||
|
||
Sensor drivers can use struct soc_camera_link, typically provided by the | ||
platform, and used to specify to which camera host bus the sensor is connected, | ||
and arbitrarily provide platform .power and .reset methods for the camera. | ||
soc_camera_device_register() and soc_camera_device_unregister() functions are | ||
used to add a sensor driver to or remove one from the system. The registration | ||
function takes a pointer to struct soc_camera_device as the only parameter. | ||
This struct can be initialized as follows: | ||
|
||
/* link to driver operations */ | ||
icd->ops = &mt9m001_ops; | ||
/* link to the underlying physical (e.g., i2c) device */ | ||
icd->control = &client->dev; | ||
/* window geometry */ | ||
icd->x_min = 20; | ||
icd->y_min = 12; | ||
icd->x_current = 20; | ||
icd->y_current = 12; | ||
icd->width_min = 48; | ||
icd->width_max = 1280; | ||
icd->height_min = 32; | ||
icd->height_max = 1024; | ||
icd->y_skip_top = 1; | ||
/* camera bus ID, typically obtained from platform data */ | ||
icd->iface = icl->bus_id; | ||
|
||
struct soc_camera_ops provides .probe and .remove methods, which are called by | ||
the soc-camera core, when a camera is matched against or removed from a camera | ||
host bus, .init, .release, .suspend, and .resume are called from the camera host | ||
driver as discussed above. Other members of this struct provide respective V4L2 | ||
functionality. | ||
|
||
struct soc_camera_device also links to an array of struct soc_camera_data_format, | ||
listing pixel formats, supported by the camera. | ||
|
||
-- | ||
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.