drivers/media/platform/via/via-camera.c
Source file repositories/reference/linux-study-clean/drivers/media/platform/via/via-camera.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/media/platform/via/via-camera.c- Extension
.c- Size
- 34447 bytes
- Lines
- 1312
- Domain
- Driver Families
- Bucket
- drivers/media
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/kernel.hlinux/module.hlinux/device.hlinux/list.hlinux/pci.hlinux/gpio/consumer.hlinux/interrupt.hlinux/platform_device.hlinux/videodev2.hmedia/v4l2-device.hmedia/v4l2-ioctl.hmedia/v4l2-ctrls.hmedia/v4l2-event.hmedia/v4l2-image-sizes.hmedia/i2c/ov7670.hmedia/videobuf2-dma-sg.hlinux/delay.hlinux/dma-mapping.hlinux/pm_qos.hlinux/via-core.hlinux/via_i2c.hasm/olpc.hvia-camera.h
Detected Declarations
struct via_camerastruct via_bufferenum viacam_opstatefunction via_sensor_power_setupfunction via_sensor_power_upfunction via_sensor_power_downfunction via_sensor_power_releasefunction viacam_set_flipfunction viacam_configure_sensorfunction viacam_write_regfunction viacam_read_regfunction viacam_write_reg_maskfunction viacam_quick_irqfunction viacam_irqfunction viacam_int_enablefunction viacam_int_disablefunction viacam_ctlr_cbufsfunction viacam_set_scalefunction viacam_ctlr_imagefunction viacam_config_controllerfunction viacam_start_enginefunction viacam_stop_enginefunction viacam_vb2_queuefunction viacam_vb2_preparefunction viacam_vb2_queue_setupfunction viacam_vb2_start_streamingfunction viacam_vb2_stop_streamingfunction list_for_each_entry_safefunction viacam_openfunction viacam_releasefunction viacam_enum_inputfunction viacam_g_inputfunction viacam_s_inputfunction viacam_enum_fmt_vid_capfunction viacam_fmt_prefunction viacam_fmt_postfunction viacam_do_try_fmtfunction viacam_try_fmt_vid_capfunction viacam_g_fmt_vid_capfunction viacam_s_fmt_vid_capfunction viacam_querycapfunction viacam_g_parmfunction viacam_s_parmfunction viacam_enum_framesizesfunction viacam_enum_frameintervalsfunction viacam_suspendfunction viacam_resumefunction viacam_serial_is_enabled
Annotated Snippet
struct via_camera {
struct v4l2_device v4l2_dev;
struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
struct viafb_dev *viadev;
struct mutex lock;
enum viacam_opstate opstate;
unsigned long flags;
struct pm_qos_request qos_request;
/*
* GPIO info for power/reset management
*/
struct gpio_desc *power_gpio;
struct gpio_desc *reset_gpio;
/*
* I/O memory stuff.
*/
void __iomem *mmio; /* Where the registers live */
void __iomem *fbmem; /* Frame buffer memory */
u32 fb_offset; /* Reserved memory offset (FB) */
/*
* Capture buffers and related. The controller supports
* up to three, so that's what we have here. These buffers
* live in frame buffer memory, so we don't call them "DMA".
*/
unsigned int cb_offsets[3]; /* offsets into fb mem */
u8 __iomem *cb_addrs[3]; /* Kernel-space addresses */
int n_cap_bufs; /* How many are we using? */
struct vb2_queue vq;
struct list_head buffer_queue;
u32 sequence;
/*
* Video format information. sensor_format is kept in a form
* that we can use to pass to the sensor. We always run the
* sensor in VGA resolution, though, and let the controller
* downscale things if need be. So we keep the "real*
* dimensions separately.
*/
struct v4l2_pix_format sensor_format;
struct v4l2_pix_format user_format;
u32 mbus_code;
};
/* buffer for one video frame */
struct via_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_v4l2_buffer vbuf;
struct list_head queue;
};
/*
* Yes, this is a hack, but there's only going to be one of these
* on any system we know of.
*/
static struct via_camera *via_cam_info;
/*
* Flag values, manipulated with bitops
*/
#define CF_DMA_ACTIVE 0 /* A frame is incoming */
#define CF_CONFIG_NEEDED 1 /* Must configure hardware */
/*
* Nasty ugly v4l2 boilerplate.
*/
#define sensor_call(cam, optype, func, args...) \
v4l2_subdev_call(cam->sensor, optype, func, ##args)
/*
* Debugging and related.
*/
#define cam_err(cam, fmt, arg...) \
dev_err(&(cam)->platdev->dev, fmt, ##arg)
#define cam_warn(cam, fmt, arg...) \
dev_warn(&(cam)->platdev->dev, fmt, ##arg)
#define cam_dbg(cam, fmt, arg...) \
dev_dbg(&(cam)->platdev->dev, fmt, ##arg)
/*
* Format handling. This is ripped almost directly from Hans's changes
* to cafe_ccic.c. It's a little unfortunate; until this change, we
* didn't need to know anything about the format except its byte depth;
* now this information must be managed at this level too.
*/
static struct via_format {
__u32 pixelformat;
int bpp; /* Bytes per pixel */
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/module.h`, `linux/device.h`, `linux/list.h`, `linux/pci.h`, `linux/gpio/consumer.h`, `linux/interrupt.h`, `linux/platform_device.h`.
- Detected declarations: `struct via_camera`, `struct via_buffer`, `enum viacam_opstate`, `function via_sensor_power_setup`, `function via_sensor_power_up`, `function via_sensor_power_down`, `function via_sensor_power_release`, `function viacam_set_flip`, `function viacam_configure_sensor`, `function viacam_write_reg`.
- Atlas domain: Driver Families / drivers/media.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.