diff options
Diffstat (limited to 'Documentation/DocBook')
24 files changed, 881 insertions, 1194 deletions
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 91f6d89bb19f..d70f9b68174e 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -50,8 +50,7 @@ pdfdocs: $(PDF) HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) htmldocs: $(HTML) - $(call build_main_index) - $(call build_images) + $(call cmd,build_main_index) $(call install_media_images) MAN := $(patsubst %.xml, %.9, $(BOOKS)) @@ -139,7 +138,8 @@ quiet_cmd_db2pdf = PDF $@ index = index.html main_idx = $(obj)/$(index) -build_main_index = rm -rf $(main_idx); \ +quiet_cmd_build_main_index = HTML $(main_idx) + cmd_build_main_index = rm -rf $(main_idx); \ echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \ echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \ cat $(HTML) >> $(main_idx) @@ -227,6 +227,10 @@ dochelp: @echo ' mandocs - man pages' @echo ' installmandocs - install man pages generated by mandocs' @echo ' cleandocs - clean all generated DocBook files' + @echo + @echo 'make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs s1.xml s2.xml' + @echo ' valid values for DOCBOOKS are: $(DOCBOOKS)' + ### # Temporary files left by various tools diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 42a2d8593e39..cdd8b24db68d 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -238,83 +238,32 @@ X!Isound/sound_firmware.c !Iinclude/media/videobuf2-memops.h </sect1> <sect1><title>Digital TV (DVB) devices</title> -!Idrivers/media/dvb-core/dvb_ca_en50221.h -!Idrivers/media/dvb-core/dvb_frontend.h + <sect1><title>Digital TV Common functions</title> !Idrivers/media/dvb-core/dvb_math.h !Idrivers/media/dvb-core/dvb_ringbuffer.h !Idrivers/media/dvb-core/dvbdev.h - <sect1><title>Digital TV Demux API</title> - <para>The kernel demux API defines a driver-internal interface for - registering low-level, hardware specific driver to a hardware - independent demux layer. It is only of interest for Digital TV - device driver writers. The header file for this API is named - <constant>demux.h</constant> and located in - <constant>drivers/media/dvb-core</constant>.</para> - - <para>The demux API should be implemented for each demux in the - system. It is used to select the TS source of a demux and to manage - the demux resources. When the demux client allocates a resource via - the demux API, it receives a pointer to the API of that - resource.</para> - <para>Each demux receives its TS input from a DVB front-end or from - memory, as set via this demux API. In a system with more than one - front-end, the API can be used to select one of the DVB front-ends - as a TS source for a demux, unless this is fixed in the HW platform. - The demux API only controls front-ends regarding to their connections - with demuxes; the APIs used to set the other front-end parameters, - such as tuning, are not defined in this document.</para> - <para>The functions that implement the abstract interface demux should - be defined static or module private and registered to the Demux - core for external access. It is not necessary to implement every - function in the struct <constant>dmx_demux</constant>. For example, - a demux interface might support Section filtering, but not PES - filtering. The API client is expected to check the value of any - function pointer before calling the function: the value of NULL means - that the “function is not available”.</para> - <para>Whenever the functions of the demux API modify shared data, - the possibilities of lost update and race condition problems should - be addressed, e.g. by protecting parts of code with mutexes.</para> - <para>Note that functions called from a bottom half context must not - sleep. Even a simple memory allocation without using GFP_ATOMIC can - result in a kernel thread being put to sleep if swapping is needed. - For example, the Linux kernel calls the functions of a network device - interface from a bottom half context. Thus, if a demux API function - is called from network device code, the function must not sleep. - </para> - </sect1> - - <section id="demux_callback_api"> - <title>Demux Callback API</title> - <para>This kernel-space API comprises the callback functions that - deliver filtered data to the demux client. Unlike the other DVB - kABIs, these functions are provided by the client and called from - the demux code.</para> - <para>The function pointers of this abstract interface are not - packed into a structure as in the other demux APIs, because the - callback functions are registered and used independent of each - other. As an example, it is possible for the API client to provide - several callback functions for receiving TS packets and no - callbacks for PES packets or sections.</para> - <para>The functions that implement the callback API need not be - re-entrant: when a demux driver calls one of these functions, - the driver is not allowed to call the function again before - the original call returns. If a callback is triggered by a - hardware interrupt, it is recommended to use the Linux - “bottom half” mechanism or start a tasklet instead of - making the callback function call directly from a hardware - interrupt.</para> - <para>This mechanism is implemented by - <link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and - <link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para> - </section> - + </sect1> + <sect1><title>Digital TV Frontend kABI</title> +!Pdrivers/media/dvb-core/dvb_frontend.h Digital TV Frontend +!Idrivers/media/dvb-core/dvb_frontend.h + </sect1> + <sect1><title>Digital TV Demux kABI</title> +!Pdrivers/media/dvb-core/demux.h Digital TV Demux + <sect1><title>Demux Callback API</title> +!Pdrivers/media/dvb-core/demux.h Demux Callback + </sect1> !Idrivers/media/dvb-core/demux.h - </sect1> + </sect1> + <sect1><title>Digital TV Conditional Access kABI</title> +!Idrivers/media/dvb-core/dvb_ca_en50221.h + </sect1> + </sect1> <sect1><title>Remote Controller devices</title> !Iinclude/media/rc-core.h !Iinclude/media/lirc_dev.h </sect1> <sect1><title>Media Controller devices</title> +!Pinclude/media/media-device.h Media Controller !Iinclude/media/media-device.h !Iinclude/media/media-devnode.h !Iinclude/media/media-entity.h diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 201dcd3c2e9d..a8669330b456 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -124,6 +124,43 @@ <para> [Insert diagram of typical DRM stack here] </para> + <sect1> + <title>Style Guidelines</title> + <para> + For consistency this documentation uses American English. Abbreviations + are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so + on. To aid in reading, documentations make full use of the markup + characters kerneldoc provides: @parameter for function parameters, @member + for structure members, &structure to reference structures and + function() for functions. These all get automatically hyperlinked if + kerneldoc for the referenced objects exists. When referencing entries in + function vtables please use ->vfunc(). Note that kerneldoc does + not support referencing struct members directly, so please add a reference + to the vtable struct somewhere in the same paragraph or at least section. + </para> + <para> + Except in special situations (to separate locked from unlocked variants) + locking requirements for functions aren't documented in the kerneldoc. + Instead locking should be check at runtime using e.g. + <code>WARN_ON(!mutex_is_locked(...));</code>. Since it's much easier to + ignore documentation than runtime noise this provides more value. And on + top of that runtime checks do need to be updated when the locking rules + change, increasing the chances that they're correct. Within the + documentation the locking rules should be explained in the relevant + structures: Either in the comment for the lock explaining what it + protects, or data fields need a note about which lock protects them, or + both. + </para> + <para> + Functions which have a non-<code>void</code> return value should have a + section called "Returns" explaining the expected return values in + different cases and their meanings. Currently there's no consensus whether + that section name should be all upper-case or not, and whether it should + end in a colon or not. Go with the file-local style. Other common section + names are "Notes" with information for dangerous or tricky corner cases, + and "FIXME" where the interface could be cleaned up. + </para> + </sect1> </chapter> <!-- Internals --> @@ -615,18 +652,6 @@ char *date;</synopsis> <function>drm_gem_object_init</function>. Storage for private GEM objects must be managed by drivers. </para> - <para> - Drivers that do not need to extend GEM objects with private information - can call the <function>drm_gem_object_alloc</function> function to - allocate and initialize a struct <structname>drm_gem_object</structname> - instance. The GEM core will call the optional driver - <methodname>gem_init_object</methodname> operation after initializing - the GEM object with <function>drm_gem_object_init</function>. - <synopsis>int (*gem_init_object) (struct drm_gem_object *obj);</synopsis> - </para> - <para> - No alloc-and-init function exists for private GEM objects. - </para> </sect3> <sect3> <title>GEM Objects Lifetime</title> @@ -635,10 +660,10 @@ char *date;</synopsis> acquired and release by <function>calling drm_gem_object_reference</function> and <function>drm_gem_object_unreference</function> respectively. The caller must hold the <structname>drm_device</structname> - <structfield>struct_mutex</structfield> lock. As a convenience, GEM - provides the <function>drm_gem_object_reference_unlocked</function> and - <function>drm_gem_object_unreference_unlocked</function> functions that - can be called without holding the lock. + <structfield>struct_mutex</structfield> lock when calling + <function>drm_gem_object_reference</function>. As a convenience, GEM + provides <function>drm_gem_object_unreference_unlocked</function> + functions that can be called without holding the lock. </para> <para> When the last reference to a GEM object is released the GEM core calls @@ -649,15 +674,9 @@ char *date;</synopsis> </para> <para> <synopsis>void (*gem_free_object) (struct drm_gem_object *obj);</synopsis> - Drivers are responsible for freeing all GEM object resources, including - the resources created by the GEM core. If an mmap offset has been - created for the object (in which case - <structname>drm_gem_object</structname>::<structfield>map_list</structfield>::<structfield>map</structfield> - is not NULL) it must be freed by a call to - <function>drm_gem_free_mmap_offset</function>. The shmfs backing store - must be released by calling <function>drm_gem_object_release</function> - (that function can safely be called if no shmfs backing store has been - created). + Drivers are responsible for freeing all GEM object resources. This includes + the resources created by the GEM core, which need to be released with + <function>drm_gem_object_release</function>. </para> </sect3> <sect3> @@ -740,17 +759,10 @@ char *date;</synopsis> DRM identifies the GEM object to be mapped by a fake offset passed through the mmap offset argument. Prior to being mapped, a GEM object must thus be associated with a fake offset. To do so, drivers must call - <function>drm_gem_create_mmap_offset</function> on the object. The - function allocates a fake offset range from a pool and stores the - offset divided by PAGE_SIZE in - <literal>obj->map_list.hash.key</literal>. Care must be taken not to - call <function>drm_gem_create_mmap_offset</function> if a fake offset - has already been allocated for the object. This can be tested by - <literal>obj->map_list.map</literal> being non-NULL. + <function>drm_gem_create_mmap_offset</function> on the object. </para> <para> Once allocated, the fake offset value - (<literal>obj->map_list.hash.key << PAGE_SHIFT</literal>) must be passed to the application in a driver-specific way and can then be used as the mmap offset argument. </para> @@ -836,10 +848,11 @@ char *date;</synopsis> abstracted from the client in libdrm. </para> </sect3> - <sect3> - <title>GEM Function Reference</title> + </sect2> + <sect2> + <title>GEM Function Reference</title> !Edrivers/gpu/drm/drm_gem.c - </sect3> +!Iinclude/drm/drm_gem.h </sect2> <sect2> <title>VMA Offset Manager</title> @@ -970,12 +983,10 @@ int max_width, max_height;</synopsis> <sect2> <title>Atomic Mode Setting Function Reference</title> !Edrivers/gpu/drm/drm_atomic.c +!Idrivers/gpu/drm/drm_atomic.c </sect2> <sect2> - <title>Frame Buffer Creation</title> - <synopsis>struct drm_framebuffer *(*fb_create)(struct drm_device *dev, - struct drm_file *file_priv, - struct drm_mode_fb_cmd2 *mode_cmd);</synopsis> + <title>Frame Buffer Abstraction</title> <para> Frame buffers are abstract memory objects that provide a source of pixels to scanout to a CRTC. Applications explicitly request the @@ -994,73 +1005,6 @@ int max_width, max_height;</synopsis> and so expects TTM handles in the create ioctl and not GEM handles. </para> <para> - Drivers must first validate the requested frame buffer parameters passed - through the mode_cmd argument. In particular this is where invalid - sizes, pixel formats or pitches can be caught. - </para> - <para> - If the parameters are deemed valid, drivers then create, initialize and - return an instance of struct <structname>drm_framebuffer</structname>. - If desired the instance can be embedded in a larger driver-specific - structure. Drivers must fill its <structfield>width</structfield>, - <structfield>height</structfield>, <structfield>pitches</structfield>, - <structfield>offsets</structfield>, <structfield>depth</structfield>, - <structfield>bits_per_pixel</structfield> and - <structfield>pixel_format</structfield> fields from the values passed - through the <parameter>drm_mode_fb_cmd2</parameter> argument. They - should call the <function>drm_helper_mode_fill_fb_struct</function> - helper function to do so. - </para> - - <para> - The initialization of the new framebuffer instance is finalized with a - call to <function>drm_framebuffer_init</function> which takes a pointer - to DRM frame buffer operations (struct - <structname>drm_framebuffer_funcs</structname>). Note that this function - publishes the framebuffer and so from this point on it can be accessed - concurrently from other threads. Hence it must be the last step in the - driver's framebuffer initialization sequence. Frame buffer operations - are - <itemizedlist> - <listitem> - <synopsis>int (*create_handle)(struct drm_framebuffer *fb, - struct drm_file *file_priv, unsigned int *handle);</synopsis> - <para> - Create a handle to the frame buffer underlying memory object. If - the frame buffer uses a multi-plane format, the handle will - reference the memory object associated with the first plane. - </para> - <para> - Drivers call <function>drm_gem_handle_create</function> to create - the handle. - </para> - </listitem> - <listitem> - <synopsis>void (*destroy)(struct drm_framebuffer *framebuffer);</synopsis> - <para> - Destroy the frame buffer object and frees all associated - resources. Drivers must call - <function>drm_framebuffer_cleanup</function> to free resources - allocated by the DRM core for the frame buffer object, and must - make sure to unreference all memory objects associated with the - frame buffer. Handles created by the - <methodname>create_handle</methodname> operation are released by - the DRM core. - </para> - </listitem> - <listitem> - <synopsis>int (*dirty)(struct drm_framebuffer *framebuffer, - struct drm_file *file_priv, unsigned flags, unsigned color, - struct drm_clip_rect *clips, unsigned num_clips);</synopsis> - <para> - This optional operation notifies the driver that a region of the - frame buffer has changed in response to a DRM_IOCTL_MODE_DIRTYFB - ioctl call. - </para> - </listitem> - </itemizedlist> - </para> - <para> The lifetime of a drm framebuffer is controlled with a reference count, drivers can grab additional references with <function>drm_framebuffer_reference</function>and drop them @@ -1197,137 +1141,6 @@ int max_width, max_height;</synopsis> pointer to CRTC functions. </para> </sect3> - <sect3 id="drm-kms-crtcops"> - <title>CRTC Operations</title> - <sect4> - <title>Set Configuration</title> - <synopsis>int (*set_config)(struct drm_mode_set *set);</synopsis> - <para> - Apply a new CRTC configuration to the device. The configuration - specifies a CRTC, a frame buffer to scan out from, a (x,y) position in - the frame buffer, a display mode and an array of connectors to drive - with the CRTC if possible. - </para> - <para> - If the frame buffer specified in the configuration is NULL, the driver - must detach all encoders connected to the CRTC and all connectors - attached to those encoders and disable them. - </para> - <para> - This operation is called with the mode config lock held. - </para> - <note><para> - Note that the drm core has no notion of restoring the mode setting - state after resume, since all resume handling is in the full - responsibility of the driver. The common mode setting helper library - though provides a helper which can be used for this: - <function>drm_helper_resume_force_mode</function>. - </para></note> - </sect4> - <sect4> - <title>Page Flipping</title> - <synopsis>int (*page_flip)(struct drm_crtc *crtc, struct drm_framebuffer *fb, - struct drm_pending_vblank_event *event);</synopsis> - <para> - Schedule a page flip to the given frame buffer for the CRTC. This - operation is called with the mode config mutex held. - </para> - <para> - Page flipping is a synchronization mechanism that replaces the frame - buffer being scanned out by the CRTC with a new frame buffer during - vertical blanking, avoiding tearing. When an application requests a page - flip the DRM core verifies that the new frame buffer is large enough to - be scanned out by the CRTC in the currently configured mode and then - calls the CRTC <methodname>page_flip</methodname> operation with a - pointer to the new frame buffer. - </para> - <para> - The <methodname>page_flip</methodname> operation schedules a page flip. - Once any pending rendering targeting the new frame buffer has - completed, the CRTC will be reprogrammed to display that frame buffer - after the next vertical refresh. The operation must return immediately - without waiting for rendering or page flip to complete and must block - any new rendering to the frame buffer until the page flip completes. - </para> - <para> - If a page flip can be successfully scheduled the driver must set the - <code>drm_crtc->fb</code> field to the new framebuffer pointed to - by <code>fb</code>. This is important so that the reference counting - on framebuffers stays balanced. - </para> - <para> - If a page flip is already pending, the - <methodname>page_flip</methodname> operation must return - -<errorname>EBUSY</errorname>. - </para> - <para> - To synchronize page flip to vertical blanking the driver will likely - need to enable vertical blanking interrupts. It should call - <function>drm_vblank_get</function> for that purpose, and call - <function>drm_vblank_put</function> after the page flip completes. - </para> - <para> - If the application has requested to be notified when page flip completes - the <methodname>page_flip</methodname> operation will be called with a - non-NULL <parameter>event</parameter> argument pointing to a - <structname>drm_pending_vblank_event</structname> instance. Upon page - flip completion the driver must call <methodname>drm_send_vblank_event</methodname> - to fill in the event and send to wake up any waiting processes. - This can be performed with - <programlisting><![CDATA[ - spin_lock_irqsave(&dev->event_lock, flags); - ... - drm_send_vblank_event(dev, pipe, event); - spin_unlock_irqrestore(&dev->event_lock, flags); - ]]></programlisting> - </para> - <note><para> - FIXME: Could drivers that don't need to wait for rendering to complete - just add the event to <literal>dev->vblank_event_list</literal> and - let the DRM core handle everything, as for "normal" vertical blanking - events? - </para></note> - <para> - While waiting for the page flip to complete, the - <literal>event->base.link</literal> list head can be used freely by - the driver to store the pending event in a driver-specific list. - </para> - <para> - If the file handle is closed before the event is signaled, drivers must - take care to destroy the event in their - <methodname>preclose</methodname> operation (and, if needed, call - <function>drm_vblank_put</function>). - </para> - </sect4> - <sect4> - <title>Miscellaneous</title> - <itemizedlist> - <listitem> - <synopsis>void (*set_property)(struct drm_crtc *crtc, - struct drm_property *property, uint64_t value);</synopsis> - <para> - Set the value of the given CRTC property to - <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/> - for more information about properties. - </para> - </listitem> - <listitem> - <synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, - uint32_t start, uint32_t size);</synopsis> - <para> - Apply a gamma table to the device. The operation is optional. - </para> - </listitem> - <listitem> - <synopsis>void (*destroy)(struct drm_crtc *crtc);</synopsis> - <para> - Destroy the CRTC when not needed anymore. See - <xref linkend="drm-kms-init"/>. - </para> - </listitem> - </itemizedlist> - </sect4> - </sect3> </sect2> <sect2> <title>Planes (struct <structname>drm_plane</structname>)</title> @@ -1344,7 +1157,7 @@ int max_width, max_height;</synopsis> <listitem> DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary planes are the planes operated upon by CRTC modesetting and flipping - operations described in <xref linkend="drm-kms-crtcops"/>. + operations described in the page_flip hook in <structname>drm_crtc_funcs</structname>. </listitem> <listitem> DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor @@ -1381,52 +1194,6 @@ int max_width, max_height;</synopsis> primary plane with standard capabilities. </para> </sect3> - <sect3> - <title>Plane Operations</title> - <itemizedlist> - <listitem> - <synopsis>int (*update_plane)(struct drm_plane *plane, struct drm_crtc *crtc, - struct drm_framebuffer *fb, int crtc_x, int crtc_y, - unsigned int crtc_w, unsigned int crtc_h, - uint32_t src_x, uint32_t src_y, - uint32_t src_w, uint32_t src_h);</synopsis> - <para> - Enable and configure the plane to use the given CRTC and frame buffer. - </para> - <para> - The source rectangle in frame buffer memory coordinates is given by - the <parameter>src_x</parameter>, <parameter>src_y</parameter>, - <parameter>src_w</parameter> and <parameter>src_h</parameter> - parameters (as 16.16 fixed point values). Devices that don't support - subpixel plane coordinates can ignore the fractional part. - </para> - <para> - The destination rectangle in CRTC coordinates is given by the - <parameter>crtc_x</parameter>, <parameter>crtc_y</parameter>, - <parameter>crtc_w</parameter> and <parameter>crtc_h</parameter> - parameters (as integer values). Devices scale the source rectangle to - the destination rectangle. If scaling is not supported, and the source - rectangle size doesn't match the destination rectangle size, the - driver must return a -<errorname>EINVAL</errorname> error. - </para> - </listitem> - <listitem> - <synopsis>int (*disable_plane)(struct drm_plane *plane);</synopsis> - <para> - Disable the plane. The DRM core calls this method in response to a - DRM_IOCTL_MODE_SETPLANE ioctl call with the frame buffer ID set to 0. - Disabled planes must not be processed by the CRTC. - </para> - </listitem> - <listitem> - <synopsis>void (*destroy)(struct drm_plane *plane);</synopsis> - <para> - Destroy the plane when not needed anymore. See - <xref linkend="drm-kms-init"/>. - </para> - </listitem> - </itemizedlist> - </sect3> </sect2> <sect2> <title>Encoders (struct <structname>drm_encoder</structname>)</title> @@ -1483,27 +1250,6 @@ int max_width, max_height;</synopsis> encoders they want to use to a CRTC. </para> </sect3> - <sect3> - <title>Encoder Operations</title> - <itemizedlist> - <listitem> - <synopsis>void (*destroy)(struct drm_encoder *encoder);</synopsis> - <para> - Called to destroy the encoder when not needed anymore. See - <xref linkend="drm-kms-init"/>. - </para> - </listitem> - <listitem> - <synopsis>void (*set_property)(struct drm_plane *plane, - struct drm_property *property, uint64_t value);</synopsis> - <para> - Set the value of the given plane property to - <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/> - for more information about properties. - </para> - </listitem> - </itemizedlist> - </sect3> </sect2> <sect2> <title>Connectors (struct <structname>drm_connector</structname>)</title> @@ -1707,27 +1453,6 @@ int max_width, max_height;</synopsis> connector_status_unknown. </para> </sect4> - <sect4> - <title>Miscellaneous</title> - <itemizedlist> - <listitem> - <synopsis>void (*set_property)(struct drm_connector *connector, - struct drm_property *property, uint64_t value);</synopsis> - <para> - Set the value of the given connector property to - <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/> - for more information about properties. - </para> - </listitem> - <listitem> - <synopsis>void (*destroy)(struct drm_connector *connector);</synopsis> - <para> - Destroy the connector when not needed anymore. See - <xref linkend="drm-kms-init"/>. - </para> - </listitem> - </itemizedlist> - </sect4> </sect3> </sect2> <sect2> @@ -1854,462 +1579,6 @@ void intel_crt_init(struct drm_device *dev) entities. </para> <sect2> - <title>Helper Functions</title> - <itemizedlist> - <listitem> - <synopsis>int drm_crtc_helper_set_config(struct drm_mode_set *set);</synopsis> - <para> - The <function>drm_crtc_helper_set_config</function> helper function - is a CRTC <methodname>set_config</methodname> implementation. It - first tries to locate the best encoder for each connector by calling - the connector <methodname>best_encoder</methodname> helper - operation. - </para> - <para> - After locating the appropriate encoders, the helper function will - call the <methodname>mode_fixup</methodname> encoder and CRTC helper - operations to adjust the requested mode, or reject it completely in - which case an error will be returned to the application. If the new - configuration after mode adjustment is identical to the current - configuration the helper function will return without performing any - other operation. - </para> - <para> - If the adjusted mode is identical to the current mode but changes to - the frame buffer need to be applied, the - <function>drm_crtc_helper_set_config</function> function will call - the CRTC <methodname>mode_set_base</methodname> helper operation. If - the adjusted mode differs from the current mode, or if the - <methodname>mode_set_base</methodname> helper operation is not - provided, the helper function performs a full mode set sequence by - calling the <methodname>prepare</methodname>, - <methodname>mode_set</methodname> and - <methodname>commit</methodname> CRTC and encoder helper operations, - in that order. - </para> - </listitem> - <listitem> - <synopsis>void drm_helper_connector_dpms(struct drm_connector *connector, int mode);</synopsis> - <para> - The <function>drm_helper_connector_dpms</function> helper function - is a connector <methodname>dpms</methodname> implementation that - tracks power state of connectors. To use the function, drivers must - provide <methodname>dpms</methodname> helper operations for CRTCs - and encoders to apply the DPMS state to the device. - </para> - <para> - The mid-layer doesn't track the power state of CRTCs and encoders. - The <methodname>dpms</methodname> helper operations can thus be - called with a mode identical to the currently active mode. - </para> - </listitem> - <listitem> - <synopsis>int drm_helper_probe_single_connector_modes(struct drm_connector *connector, - uint32_t maxX, uint32_t maxY);</synopsis> - <para> - The <function>drm_helper_probe_single_connector_modes</function> helper - function is a connector <methodname>fill_modes</methodname> - implementation that updates the connection status for the connector - and then retrieves a list of modes by calling the connector - <methodname>get_modes</methodname> helper operation. - </para> - <para> - If the helper operation returns no mode, and if the connector status - is connector_status_connected, standard VESA DMT modes up to - 1024x768 are automatically added to the modes list by a call to - <function>drm_add_modes_noedid</function>. - </para> - <para> - The function then filters out modes larger than - <parameter>max_width</parameter> and <parameter>max_height</parameter> - if specified. It finally calls the optional connector - <methodname>mode_valid</methodname> helper operation for each mode in - the probed list to check whether the mode is valid for the connector. - </para> - </listitem> - </itemizedlist> - </sect2> - <sect2> - <title>CRTC Helper Operations</title> - <itemizedlist> - <listitem id="drm-helper-crtc-mode-fixup"> - <synopsis>bool (*mode_fixup)(struct drm_crtc *crtc, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode);</synopsis> - <para> - Let CRTCs adjust the requested mode or reject it completely. This - operation returns true if the mode is accepted (possibly after being - adjusted) or false if it is rejected. - </para> - <para> - The <methodname>mode_fixup</methodname> operation should reject the - mode if it can't reasonably use it. The definition of "reasonable" - is currently fuzzy in this context. One possible behaviour would be - to set the adjusted mode to the panel timings when a fixed-mode - panel is used with hardware capable of scaling. Another behaviour - would be to accept any input mode and adjust it to the closest mode - supported by the hardware (FIXME: This needs to be clarified). - </para> - </listitem> - <listitem> - <synopsis>int (*mode_set_base)(struct drm_crtc *crtc, int x, int y, - struct drm_framebuffer *old_fb)</synopsis> - <para> - Move the CRTC on the current frame buffer (stored in - <literal>crtc->fb</literal>) to position (x,y). Any of the frame - buffer, x position or y position may have been modified. - </para> - <para> - This helper operation is optional. If not provided, the - <function>drm_crtc_helper_set_config</function> function will fall - back to the <methodname>mode_set</methodname> helper operation. - </para> - <note><para> - FIXME: Why are x and y passed as arguments, as they can be accessed - through <literal>crtc->x</literal> and - <literal>crtc->y</literal>? - </para></note> - </listitem> - <listitem> - <synopsis>void (*prepare)(struct drm_crtc *crtc);</synopsis> - <para> - Prepare the CRTC for mode setting. This operation is called after - validating the requested mode. Drivers use it to perform - device-specific operations required before setting the new mode. - </para> - </listitem> - <listitem> - <synopsis>int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode, int x, int y, - struct drm_framebuffer *old_fb);</synopsis> - <para> - Set a new mode, position and frame buffer. Depending on the device - requirements, the mode can be stored internally by the driver and - applied in the <methodname>commit</methodname> operation, or - programmed to the hardware immediately. - </para> - <para> - The <methodname>mode_set</methodname> operation returns 0 on success - or a negative error code if an error occurs. - </para> - </listitem> - <listitem> - <synopsis>void (*commit)(struct drm_crtc *crtc);</synopsis> - <para> - Commit a mode. This operation is called after setting the new mode. - Upon return the device must use the new mode and be fully - operational. - </para> - </listitem> - </itemizedlist> - </sect2> - <sect2> - <title>Encoder Helper Operations</title> - <itemizedlist> - <listitem> - <synopsis>bool (*mode_fixup)(struct drm_encoder *encoder, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode);</synopsis> - <para> - Let encoders adjust the requested mode or reject it completely. This - operation returns true if the mode is accepted (possibly after being - adjusted) or false if it is rejected. See the - <link linkend="drm-helper-crtc-mode-fixup">mode_fixup CRTC helper - operation</link> for an explanation of the allowed adjustments. - </para> - </listitem> - <listitem> - <synopsis>void (*prepare)(struct drm_encoder *encoder);</synopsis> - <para> - Prepare the encoder for mode setting. This operation is called after - validating the requested mode. Drivers use it to perform - device-specific operations required before setting the new mode. - </para> - </listitem> - <listitem> - <synopsis>void (*mode_set)(struct drm_encoder *encoder, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode);</synopsis> - <para> - Set a new mode. Depending on the device requirements, the mode can - be stored internally by the driver and applied in the - <methodname>commit</methodname> operation, or programmed to the - hardware immediately. - </para> - </listitem> - <listitem> - <synopsis>void (*commit)(struct drm_encoder *encoder);</synopsis> - <para> - Commit a mode. This operation is called after setting the new mode. - Upon return the device must use the new mode and be fully - operational. - </para> - </listitem> - </itemizedlist> - </sect2> - <sect2> - <title>Connector Helper Operations</title> - <itemizedlist> - <listitem> - <synopsis>struct drm_encoder *(*best_encoder)(struct drm_connector *connector);</synopsis> - <para> - Return a pointer to the best encoder for the connecter. Device that - map connectors to encoders 1:1 simply return the pointer to the - associated encoder. This operation is mandatory. - </para> - </listitem> - <listitem> - <synopsis>int (*get_modes)(struct drm_connector *connector);</synopsis> - <para> - Fill the connector's <structfield>probed_modes</structfield> list - by parsing EDID data with <function>drm_add_edid_modes</function>, - adding standard VESA DMT modes with <function>drm_add_modes_noedid</function>, - or calling <function>drm_mode_probed_add</function> directly for every - supported mode and return the number of modes it has detected. This - operation is mandatory. - </para> - <para> - Note that the caller function will automatically add standard VESA - DMT modes up to 1024x768 if the <methodname>get_modes</methodname> - helper operation returns no mode and if the connector status is - connector_status_connected. There is no need to call - <function>drm_add_edid_modes</function> manually in that case. - </para> - <para> - When adding modes manually the driver creates each mode with a call to - <function>drm_mode_create</function> and must fill the following fields. - <itemizedlist> - <listitem> - <synopsis>__u32 type;</synopsis> - <para> - Mode type bitmask, a combination of - <variablelist> - <varlistentry> - <term>DRM_MODE_TYPE_BUILTIN</term> - <listitem><para>not used?</para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_TYPE_CLOCK_C</term> - <listitem><para>not used?</para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_TYPE_CRTC_C</term> - <listitem><para>not used?</para></listitem> - </varlistentry> - <varlistentry> - <term> - DRM_MODE_TYPE_PREFERRED - The preferred mode for the connector - </term> - <listitem> - <para>not used?</para> - </listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_TYPE_DEFAULT</term> - <listitem><para>not used?</para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_TYPE_USERDEF</term> - <listitem><para>not used?</para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_TYPE_DRIVER</term> - <listitem> - <para> - The mode has been created by the driver (as opposed to - to user-created modes). - </para> - </listitem> - </varlistentry> - </variablelist> - Drivers must set the DRM_MODE_TYPE_DRIVER bit for all modes they - create, and set the DRM_MODE_TYPE_PREFERRED bit for the preferred - mode. - </para> - </listitem> - <listitem> - <synopsis>__u32 clock;</synopsis> - <para>Pixel clock frequency in kHz unit</para> - </listitem> - <listitem> - <synopsis>__u16 hdisplay, hsync_start, hsync_end, htotal; - __u16 vdisplay, vsync_start, vsync_end, vtotal;</synopsis> - <para>Horizontal and vertical timing information</para> - <screen><![CDATA[ - Active Front Sync Back - Region Porch Porch - <-----------------------><----------------><-------------><--------------> - - //////////////////////| - ////////////////////// | - ////////////////////// |.................. ................ - _______________ - - <----- [hv]display -----> - <------------- [hv]sync_start ------------> - <--------------------- [hv]sync_end ---------------------> - <-------------------------------- [hv]total -----------------------------> -]]></screen> - </listitem> - <listitem> - <synopsis>__u16 hskew; - __u16 vscan;</synopsis> - <para>Unknown</para> - </listitem> - <listitem> - <synopsis>__u32 flags;</synopsis> - <para> - Mode flags, a combination of - <variablelist> - <varlistentry> - <term>DRM_MODE_FLAG_PHSYNC</term> - <listitem><para> - Horizontal sync is active high - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_NHSYNC</term> - <listitem><para> - Horizontal sync is active low - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_PVSYNC</term> - <listitem><para> - Vertical sync is active high - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_NVSYNC</term> - <listitem><para> - Vertical sync is active low - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_INTERLACE</term> - <listitem><para> - Mode is interlaced - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_DBLSCAN</term> - <listitem><para> - Mode uses doublescan - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_CSYNC</term> - <listitem><para> - Mode uses composite sync - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_PCSYNC</term> - <listitem><para> - Composite sync is active high - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_NCSYNC</term> - <listitem><para> - Composite sync is active low - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_HSKEW</term> - <listitem><para> - hskew provided (not used?) - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_BCAST</term> - <listitem><para> - not used? - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_PIXMUX</term> - <listitem><para> - not used? - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_DBLCLK</term> - <listitem><para> - not used? - </para></listitem> - </varlistentry> - <varlistentry> - <term>DRM_MODE_FLAG_CLKDIV2</term> - <listitem><para> - ? - </para></listitem> - </varlistentry> - </variablelist> - </para> - <para> - Note that modes marked with the INTERLACE or DBLSCAN flags will be - filtered out by - <function>drm_helper_probe_single_connector_modes</function> if - the connector's <structfield>interlace_allowed</structfield> or - <structfield>doublescan_allowed</structfield> field is set to 0. - </para> - </listitem> - <listitem> - <synopsis>char name[DRM_DISPLAY_MODE_LEN];</synopsis> - <para> - Mode name. The driver must call - <function>drm_mode_set_name</function> to fill the mode name from - <structfield>hdisplay</structfield>, - <structfield>vdisplay</structfield> and interlace flag after - filling the corresponding fields. - </para> - </listitem> - </itemizedlist> - </para> - <para> - The <structfield>vrefresh</structfield> value is computed by - <function>drm_helper_probe_single_connector_modes</function>. - </para> - <para> - When parsing EDID data, <function>drm_add_edid_modes</function> fills the - connector <structfield>display_info</structfield> - <structfield>width_mm</structfield> and - <structfield>height_mm</structfield> fields. When creating modes - manually the <methodname>get_modes</methodname> helper operation must - set the <structfield>display_info</structfield> - <structfield>width_mm</structfield> and - <structfield>height_mm</structfield> fields if they haven't been set - already (for instance at initialization time when a fixed-size panel is - attached to the connector). The mode <structfield>width_mm</structfield> - and <structfield>height_mm</structfield> fields are only used internally - during EDID parsing and should not be set when creating modes manually. - </para> - </listitem> - <listitem> - <synopsis>int (*mode_valid)(struct drm_connector *connector, - struct drm_display_mode *mode);</synopsis> - <para> - Verify whether a mode is valid for the connector. Return MODE_OK for - supported modes and one of the enum drm_mode_status values (MODE_*) - for unsupported modes. This operation is optional. - </para> - <para> - As the mode rejection reason is currently not used beside for - immediately removing the unsupported mode, an implementation can - return MODE_BAD regardless of the exact reason why the mode is not - valid. - </para> - <note><para> - Note that the <methodname>mode_valid</methodname> helper operation is - only called for modes detected by the device, and - <emphasis>not</emphasis> for modes set by the user through the CRTC - <methodname>set_config</methodname> operation. - </para></note> - </listitem> - </itemizedlist> - </sect2> - <sect2> <title>Atomic Modeset Helper Functions Reference</title> <sect3> <title>Overview</title> @@ -2327,8 +1596,12 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_atomic_helper.c </sect2> <sect2> - <title>Modeset Helper Functions Reference</title> -!Iinclude/drm/drm_crtc_helper.h + <title>Modeset Helper Reference for Common Vtables</title> +!Iinclude/drm/drm_modeset_helper_vtables.h +!Pinclude/drm/drm_modeset_helper_vtables.h overview + </sect2> + <sect2> + <title>Legacy CRTC/Modeset Helper Functions Reference</title> !Edrivers/gpu/drm/drm_crtc_helper.c !Pdrivers/gpu/drm/drm_crtc_helper.c overview </sect2> @@ -4039,92 +3312,6 @@ int num_ioctls;</synopsis> <sect2> <title>DPIO</title> !Pdrivers/gpu/drm/i915/i915_reg.h DPIO - <table id="dpiox2"> - <title>Dual channel PHY (VLV/CHV/BXT)</title> - <tgroup cols="8"> - <colspec colname="c0" /> - <colspec colname="c1" /> - <colspec colname="c2" /> - <colspec colname="c3" /> - <colspec colname="c4" /> - <colspec colname="c5" /> - <colspec colname="c6" /> - <colspec colname="c7" /> - <spanspec spanname="ch0" namest="c0" nameend="c3" /> - <spanspec spanname="ch1" namest="c4" nameend="c7" /> - <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" /> - <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" /> - <spanspec spanname="ch1pcs01" namest="c4" nameend="c5" /> - <spanspec spanname="ch1pcs23" namest="c6" nameend="c7" /> - <thead> - <row> - <entry spanname="ch0">CH0</entry> - <entry spanname="ch1">CH1</entry> - </row> - </thead> - <tbody valign="top" align="center"> - <row> - <entry spanname="ch0">CMN/PLL/REF</entry> - <entry spanname="ch1">CMN/PLL/REF</entry> - </row> - <row> - <entry spanname="ch0pcs01">PCS01</entry> - <entry spanname="ch0pcs23">PCS23</entry> - <entry spanname="ch1pcs01">PCS01</entry> - <entry spanname="ch1pcs23">PCS23</entry> - </row> - <row> - <entry>TX0</entry> - <entry>TX1</entry> - <entry>TX2</entry> - <entry>TX3</entry> - <entry>TX0</entry> - <entry>TX1</entry> - <entry>TX2</entry> - <entry>TX3</entry> - </row> - <row> - <entry spanname="ch0">DDI0</entry> - <entry spanname="ch1">DDI1</entry> - </row> - </tbody> - </tgroup> - </table> - <table id="dpiox1"> - <title>Single channel PHY (CHV/BXT)</title> - <tgroup cols="4"> - <colspec colname="c0" /> - <colspec colname="c1" /> - <colspec colname="c2" /> - <colspec colname="c3" /> - <spanspec spanname="ch0" namest="c0" nameend="c3" /> - <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" /> - <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" /> - <thead> - <row> - <entry spanname="ch0">CH0</entry> - </row> - </thead> - <tbody valign="top" align="center"> - <row> - <entry spanname="ch0">CMN/PLL/REF</entry> - </row> - <row> - <entry spanname="ch0pcs01">PCS01</entry> - <entry spanname="ch0pcs23">PCS23</entry> - </row> - <row> - <entry>TX0</entry> - <entry>TX1</entry> - <entry>TX2</entry> - <entry>TX3</entry> - </row> - <row> - <entry spanname="ch0">DDI2</entry> - </row> - </tbody> - </tgroup> - </table> </sect2> <sect2> @@ -4201,17 +3388,21 @@ int num_ioctls;</synopsis> </sect2> </sect1> <sect1> - <title>GuC-based Command Submission</title> + <title>GuC</title> <sect2> - <title>GuC</title> + <title>GuC-specific firmware loader</title> !Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader !Idrivers/gpu/drm/i915/intel_guc_loader.c </sect2> <sect2> - <title>GuC Client</title> -!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison + <title>GuC-based command submission</title> +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submission !Idrivers/gpu/drm/i915/i915_guc_submission.c </sect2> + <sect2> + <title>GuC Firmware Layout</title> +!Pdrivers/gpu/drm/i915/intel_guc_fwif.h GuC Firmware Layout + </sect2> </sect1> <sect1> @@ -4246,41 +3437,63 @@ int num_ioctls;</synopsis> <chapter id="modes_of_use"> <title>Modes of Use</title> - <sect1> - <title>Manual switching and manual power control</title> + <sect1> + <title>Manual switching and manual power control</title> !Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control - </sect1> - <sect1> - <title>Driver power control</title> + </sect1> + <sect1> + <title>Driver power control</title> !Pdrivers/gpu/vga/vga_switcheroo.c Driver power control - </sect1> + </sect1> </chapter> - <chapter id="pubfunctions"> - <title>Public functions</title> + <chapter id="api"> + <title>API</title> + <sect1> + <title>Public functions</title> !Edrivers/gpu/vga/vga_switcheroo.c - </chapter> - - <chapter id="pubstructures"> - <title>Public structures</title> + </sect1> + <sect1> + <title>Public structures</title> !Finclude/linux/vga_switcheroo.h vga_switcheroo_handler !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops - </chapter> - - <chapter id="pubconstants"> - <title>Public constants</title> + </sect1> + <sect1> + <title>Public constants</title> !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id !Finclude/linux/vga_switcheroo.h vga_switcheroo_state - </chapter> - - <chapter id="privstructures"> - <title>Private structures</title> + </sect1> + <sect1> + <title>Private structures</title> !Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv !Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client + </sect1> + </chapter> + + <chapter id="handlers"> + <title>Handlers</title> + <sect1> + <title>apple-gmux Handler</title> +!Pdrivers/platform/x86/apple-gmux.c Overview +!Pdrivers/platform/x86/apple-gmux.c Interrupt + <sect2> + <title>Graphics mux</title> +!Pdrivers/platform/x86/apple-gmux.c Graphics mux + </sect2> + <sect2> + <title>Power control</title> +!Pdrivers/platform/x86/apple-gmux.c Power control + </sect2> + <sect2> + <title>Backlight control</title> +!Pdrivers/platform/x86/apple-gmux.c Backlight control + </sect2> + </sect1> </chapter> !Cdrivers/gpu/vga/vga_switcheroo.c !Cinclude/linux/vga_switcheroo.h +!Cdrivers/platform/x86/apple-gmux.c </part> </book> diff --git a/Documentation/DocBook/iio.tmpl b/Documentation/DocBook/iio.tmpl index 98be322673da..f525bf56d1dd 100644 --- a/Documentation/DocBook/iio.tmpl +++ b/Documentation/DocBook/iio.tmpl @@ -458,7 +458,7 @@ .scan_type = { .sign = 's', .realbits = 12, - .storgebits = 16, + .storagebits = 16, .shift = 4, .endianness = IIO_LE, }, diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 08527e7ea4d0..2840ff483d5a 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -199,8 +199,10 @@ DVB_DOCUMENTED = \ # install_media_images = \ - $(Q)-mkdir $(MEDIA_OBJ_DIR)/media_api; \ - cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api + $(Q)if [ "x$(findstring media_api.xml,$(DOCBOOKS))" != "x" ]; then \ + mkdir -p $(MEDIA_OBJ_DIR)/media_api; \ + cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api; \ + fi $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64 $(Q)base64 -d $< >$@ diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 08227d4e9150..e579ae5088ae 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -76,7 +76,7 @@ int main(void) <para>NOTE: While it is possible to directly call the Kernel code like the above example, it is strongly recommended to use - <ulink url="http://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>, + <ulink url="https://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>, as it provides abstraction to work with the supported digital TV standards and provides methods for usual operations like program scanning and to read/write channel descriptor files.</para> diff --git a/Documentation/DocBook/media/dvb/examples.xml b/Documentation/DocBook/media/dvb/examples.xml index c9f68c7183cc..837fb3b64b72 100644 --- a/Documentation/DocBook/media/dvb/examples.xml +++ b/Documentation/DocBook/media/dvb/examples.xml @@ -3,7 +3,7 @@ </para> <para>NOTE: This section is out of date, and the code below won't even compile. Please refer to the - <ulink url="http://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink> + <ulink url="https://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink> for updated/recommended examples. </para> diff --git a/Documentation/DocBook/media/dvb/intro.xml b/Documentation/DocBook/media/dvb/intro.xml index 51db15648099..b5b701f5d8c2 100644 --- a/Documentation/DocBook/media/dvb/intro.xml +++ b/Documentation/DocBook/media/dvb/intro.xml @@ -32,7 +32,7 @@ and filtering several section and PES data streams at the same time. new standard Linux DVB API. As a commitment to the development of terminals based on open standards, Nokia and Convergence made it available to all Linux developers and published it on -<ulink url="http://www.linuxtv.org/" /> in September 2000. +<ulink url="https://linuxtv.org" /> in September 2000. Convergence is the maintainer of the Linux DVB API. Together with the LinuxTV community (i.e. you, the reader of this document), the Linux DVB API will be constantly reviewed and improved. With the Linux driver for diff --git a/Documentation/DocBook/media/v4l/capture.c.xml b/Documentation/DocBook/media/v4l/capture.c.xml index 1c5c49a2de59..22126a991b34 100644 --- a/Documentation/DocBook/media/v4l/capture.c.xml +++ b/Documentation/DocBook/media/v4l/capture.c.xml @@ -5,7 +5,7 @@ * This program can be used and distributed without restrictions. * * This program is provided with the V4L2 API - * see http://linuxtv.org/docs.php for more information + * see https://linuxtv.org/docs.php for more information */ #include <stdio.h> diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 5701a08ed792..5399e8904715 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2666,7 +2666,7 @@ is useful to display images captured with V4L2 devices.</para> <para>V4L2 does not support digital terrestrial, cable or satellite broadcast. A separate project aiming at digital receivers exists. You can find its homepage at <ulink -url="http://linuxtv.org">http://linuxtv.org</ulink>. The Linux DVB API +url="https://linuxtv.org">https://linuxtv.org</ulink>. The Linux DVB API has no connection to the V4L2 API except that drivers for hybrid hardware may support both.</para> </section> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index da654031ef3f..144158b3a5ac 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -699,7 +699,7 @@ linkend="v4l2-buf-type" /></entry> buffer. It depends on the negotiated data format and may change with each buffer for compressed variable size data like JPEG images. Drivers must set this field when <structfield>type</structfield> -refers to an input stream, applications when it refers to an output stream. +refers to a capture stream, applications when it refers to an output stream. If the application sets this to 0 for an output stream, then <structfield>bytesused</structfield> will be set to the size of the buffer (see the <structfield>length</structfield> field of this struct) by @@ -720,14 +720,14 @@ linkend="buffer-flags" />.</entry> <entry>Indicates the field order of the image in the buffer, see <xref linkend="v4l2-field" />. This field is not used when the buffer contains VBI data. Drivers must set it when -<structfield>type</structfield> refers to an input stream, +<structfield>type</structfield> refers to a capture stream, applications when it refers to an output stream.</entry> </row> <row> <entry>struct timeval</entry> <entry><structfield>timestamp</structfield></entry> <entry></entry> - <entry><para>For input streams this is time when the first data + <entry><para>For capture streams this is time when the first data byte was captured, as returned by the <function>clock_gettime()</function> function for the relevant clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in @@ -866,7 +866,7 @@ must set this to 0.</entry> <entry></entry> <entry>The number of bytes occupied by data in the plane (its payload). Drivers must set this field when <structfield>type</structfield> - refers to an input stream, applications when it refers to an output stream. + refers to a capture stream, applications when it refers to an output stream. If the application sets this to 0 for an output stream, then <structfield>bytesused</structfield> will be set to the size of the plane (see the <structfield>length</structfield> field of this struct) @@ -919,7 +919,7 @@ must set this to 0.</entry> <entry></entry> <entry>Offset in bytes to video data in the plane. Drivers must set this field when <structfield>type</structfield> - refers to an input stream, applications when it refers to an output stream. + refers to a capture stream, applications when it refers to an output stream. Note that data_offset is included in <structfield>bytesused</structfield>. So the size of the image in the plane is <structfield>bytesused</structfield>-<structfield>data_offset</structfield> at diff --git a/Documentation/DocBook/media/v4l/media-controller.xml b/Documentation/DocBook/media/v4l/media-controller.xml index 873ac3a621f0..5f2fc07a93d7 100644 --- a/Documentation/DocBook/media/v4l/media-controller.xml +++ b/Documentation/DocBook/media/v4l/media-controller.xml @@ -58,21 +58,36 @@ <title>Media device model</title> <para>Discovering a device internal topology, and configuring it at runtime, is one of the goals of the media controller API. To achieve this, hardware - devices are modelled as an oriented graph of building blocks called entities - connected through pads.</para> - <para>An entity is a basic media hardware or software building block. It can - correspond to a large variety of logical blocks such as physical hardware - devices (CMOS sensor for instance), logical hardware devices (a building - block in a System-on-Chip image processing pipeline), DMA channels or - physical connectors.</para> - <para>A pad is a connection endpoint through which an entity can interact - with other entities. Data (not restricted to video) produced by an entity - flows from the entity's output to one or more entity inputs. Pads should not - be confused with physical pins at chip boundaries.</para> - <para>A link is a point-to-point oriented connection between two pads, - either on the same entity or on different entities. Data flows from a source - pad to a sink pad.</para> + devices and Linux Kernel interfaces are modelled as graph objects on + an oriented graph. The object types that constitute the graph are:</para> + <itemizedlist> + <listitem><para>An <emphasis role="bold">entity</emphasis> + is a basic media hardware or software building block. It can correspond to + a large variety of logical blocks such as physical hardware devices + (CMOS sensor for instance), logical hardware devices (a building block in + a System-on-Chip image processing pipeline), DMA channels or physical + connectors.</para></listitem> + <listitem><para>An <emphasis role="bold">interface</emphasis> + is a graph representation of a Linux Kernel userspace API interface, + like a device node or a sysfs file that controls one or more entities + in the graph.</para></listitem> + <listitem><para>A <emphasis role="bold">pad</emphasis> + is a data connection endpoint through which an entity can interact with + other entities. Data (not restricted to video) produced by an entity + flows from the entity's output to one or more entity inputs. Pads should + not be confused with physical pins at chip boundaries.</para></listitem> + <listitem><para>A <emphasis role="bold">data link</emphasis> + is a point-to-point oriented connection between two pads, either on the + same entity or on different entities. Data flows from a source pad to a + sink pad.</para></listitem> + <listitem><para>An <emphasis role="bold">interface link</emphasis> + is a point-to-point bidirectional control connection between a Linux + Kernel interface and an entity.m</para></listitem> + </itemizedlist> </section> + + <!-- All non-ioctl specific data types go here. --> + &sub-media-types; </chapter> <appendix id="media-user-func"> @@ -83,6 +98,7 @@ &sub-media-func-ioctl; <!-- All ioctls go here. --> &sub-media-ioc-device-info; + &sub-media-ioc-g-topology; &sub-media-ioc-enum-entities; &sub-media-ioc-enum-links; &sub-media-ioc-setup-link; diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml index 5872f8bbf774..0c4f96bfc2de 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -59,15 +59,6 @@ <para>Entity IDs can be non-contiguous. Applications must <emphasis>not</emphasis> try to enumerate entities by calling MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error.</para> - <para>Two or more entities that share a common non-zero - <structfield>group_id</structfield> value are considered as logically - grouped. Groups are used to report - <itemizedlist> - <listitem><para>ALSA, VBI and video nodes that carry the same media - stream</para></listitem> - <listitem><para>lens and flash controllers associated with a sensor</para></listitem> - </itemizedlist> - </para> <table pgwide="1" frame="none" id="media-entity-desc"> <title>struct <structname>media_entity_desc</structname></title> @@ -106,7 +97,7 @@ <entry><structfield>revision</structfield></entry> <entry></entry> <entry></entry> - <entry>Entity revision in a driver/hardware specific format.</entry> + <entry>Entity revision. Always zero (obsolete)</entry> </row> <row> <entry>__u32</entry> @@ -120,7 +111,7 @@ <entry><structfield>group_id</structfield></entry> <entry></entry> <entry></entry> - <entry>Entity group ID</entry> + <entry>Entity group ID. Always zero (obsolete)</entry> </row> <row> <entry>__u16</entry> @@ -171,97 +162,6 @@ </tbody> </tgroup> </table> - - <table frame="none" pgwide="1" id="media-entity-type"> - <title>Media entity types</title> - <tgroup cols="2"> - <colspec colname="c1"/> - <colspec colname="c2"/> - <tbody valign="top"> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE</constant></entry> - <entry>Unknown device node</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry> - <entry>V4L video, radio or vbi device node</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_FB</constant></entry> - <entry>Frame buffer device node</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_ALSA</constant></entry> - <entry>ALSA card</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry> - <entry>DVB frontend devnode</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry> - <entry>DVB demux devnode</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry> - <entry>DVB DVR devnode</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry> - <entry>DVB CAM devnode</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry> - <entry>DVB network devnode</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry> - <entry>Unknown V4L sub-device</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry> - <entry>Video sensor</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry> - <entry>Flash controller</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry> - <entry>Lens controller</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry> - <entry>Video decoder, the basic function of the video decoder is to - accept analogue video from a wide variety of sources such as - broadcast, DVD players, cameras and video cassette recorders, in - either NTSC, PAL or HD format and still occasionally SECAM, separate - it into its component parts, luminance and chrominance, and output - it in some digital video standard, with appropriate embedded timing - signals.</entry> - </row> - <row> - <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry> - <entry>TV and/or radio tuner</entry> - </row> - </tbody> - </tgroup> - </table> - - <table frame="none" pgwide="1" id="media-entity-flag"> - <title>Media entity flags</title> - <tgroup cols="2"> - <colspec colname="c1"/> - <colspec colname="c2"/> - <tbody valign="top"> - <row> - <entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry> - <entry>Default entity for its type. Used to discover the default - audio, VBI and video devices, the default camera sensor, ...</entry> - </row> - </tbody> - </tgroup> - </table> </refsect1> <refsect1> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index 74fb394ec667..2bbeea9f3e18 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -118,35 +118,6 @@ </tgroup> </table> - <table frame="none" pgwide="1" id="media-pad-flag"> - <title>Media pad flags</title> - <tgroup cols="2"> - <colspec colname="c1"/> - <colspec colname="c2"/> - <tbody valign="top"> - <row> - <entry><constant>MEDIA_PAD_FL_SINK</constant></entry> - <entry>Input pad, relative to the entity. Input pads sink data and - are targets of links.</entry> - </row> - <row> - <entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry> - <entry>Output pad, relative to the entity. Output pads source data - and are origins of links.</entry> - </row> - <row> - <entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry> - <entry>If this flag is set and the pad is linked to any other - pad, then at least one of those links must be enabled for the - entity to be able to stream. There could be temporary reasons - (e.g. device configuration dependent) for the pad to need - enabled links even when this flag isn't set; the absence of the - flag doesn't imply there is none.</entry> - </row> - </tbody> - </tgroup> - </table> - <table pgwide="1" frame="none" id="media-link-desc"> <title>struct <structname>media_link_desc</structname></title> <tgroup cols="3"> @@ -171,33 +142,6 @@ </tgroup> </table> - <table frame="none" pgwide="1" id="media-link-flag"> - <title>Media link flags</title> - <tgroup cols="2"> - <colspec colname="c1"/> - <colspec colname="c2"/> - <tbody valign="top"> - <row> - <entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry> - <entry>The link is enabled and can be used to transfer media data. - When two or more links target a sink pad, only one of them can be - enabled at a time.</entry> - </row> - <row> - <entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry> - <entry>The link enabled state can't be modified at runtime. An - immutable link is always enabled.</entry> - </row> - <row> - <entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry> - <entry>The link enabled state can be modified during streaming. This - flag is set by drivers and is read-only for applications.</entry> - </row> - </tbody> - </tgroup> - </table> - <para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and - <constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para> </refsect1> <refsect1> diff --git a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml new file mode 100644 index 000000000000..63152ab9efba --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml @@ -0,0 +1,394 @@ +<refentry id="media-g-topology"> + <refmeta> + <refentrytitle>ioctl MEDIA_IOC_G_TOPOLOGY</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>MEDIA_IOC_G_TOPOLOGY</refname> + <refpurpose>Enumerate the graph topology and graph element properties</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>struct media_v2_topology *<parameter>argp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + + <variablelist> + <varlistentry> + <term><parameter>fd</parameter></term> + <listitem> + <para>File descriptor returned by + <link linkend='media-func-open'><function>open()</function></link>.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>request</parameter></term> + <listitem> + <para>MEDIA_IOC_G_TOPOLOGY</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para> + + <para>The typical usage of this ioctl is to call it twice. + On the first call, the structure defined at &media-v2-topology; should + be zeroed. At return, if no errors happen, this ioctl will return the + <constant>topology_version</constant> and the total number of entities, + interfaces, pads and links.</para> + <para>Before the second call, the userspace should allocate arrays to + store the graph elements that are desired, putting the pointers to them + at the ptr_entities, ptr_interfaces, ptr_links and/or ptr_pads, keeping + the other values untouched.</para> + <para>If the <constant>topology_version</constant> remains the same, the + ioctl should fill the desired arrays with the media graph elements.</para> + + <table pgwide="1" frame="none" id="media-v2-topology"> + <title>struct <structname>media_v2_topology</structname></title> + <tgroup cols="5"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <tbody valign="top"> + <row> + <entry>__u64</entry> + <entry><structfield>topology_version</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Version of the media graph topology. When the graph is + created, this field starts with zero. Every time a graph + element is added or removed, this field is + incremented.</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>num_entities</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Number of entities in the graph</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>ptr_entities</structfield></entry> + <entry></entry> + <entry></entry> + <entry>A pointer to a memory area where the entities array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + entities. It will just update + <constant>num_entities</constant></entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>num_interfaces</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Number of interfaces in the graph</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>ptr_interfaces</structfield></entry> + <entry></entry> + <entry></entry> + <entry>A pointer to a memory area where the interfaces array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + interfaces. It will just update + <constant>num_interfaces</constant></entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>num_pads</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Total number of pads in the graph</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>ptr_pads</structfield></entry> + <entry></entry> + <entry></entry> + <entry>A pointer to a memory area where the pads array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + pads. It will just update + <constant>num_pads</constant></entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>num_links</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Total number of data and interface links in the graph</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>ptr_links</structfield></entry> + <entry></entry> + <entry></entry> + <entry>A pointer to a memory area where the links array + will be stored, converted to a 64-bits integer. + It can be zero. if zero, the ioctl won't store the + links. It will just update + <constant>num_links</constant></entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="media-v2-entity"> + <title>struct <structname>media_v2_entity</structname></title> + <tgroup cols="5"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Unique ID for the entity.</entry> + </row> + <row> + <entry>char</entry> + <entry><structfield>name</structfield>[64]</entry> + <entry></entry> + <entry></entry> + <entry>Entity name as an UTF-8 NULL-terminated string.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>function</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Entity main function, see <xref linkend="media-entity-type" /> for details.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[12]</entry> + <entry>Reserved for future extensions. Drivers and applications must + set this array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="media-v2-interface"> + <title>struct <structname>media_v2_interface</structname></title> + <tgroup cols="5"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Unique ID for the interface.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>intf_type</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Interface type, see <xref linkend="media-intf-type" /> for details.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Interface flags. Currently unused.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[9]</entry> + <entry></entry> + <entry></entry> + <entry>Reserved for future extensions. Drivers and applications must + set this array to zero.</entry> + </row> + <row> + <entry>struct media_v2_intf_devnode</entry> + <entry><structfield>devnode</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Used only for device node interfaces. See <xref linkend="media-v2-intf-devnode" /> for details..</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="media-v2-intf-devnode"> + <title>struct <structname>media_v2_interface</structname></title> + <tgroup cols="5"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>major</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Device node major number.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>minor</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Device node minor number.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="media-v2-pad"> + <title>struct <structname>media_v2_pad</structname></title> + <tgroup cols="5"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Unique ID for the pad.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>entity_id</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Unique ID for the entity where this pad belongs.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Pad flags, see <xref linkend="media-pad-flag" /> for more details.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[9]</entry> + <entry></entry> + <entry></entry> + <entry>Reserved for future extensions. Drivers and applications must + set this array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="media-v2-link"> + <title>struct <structname>media_v2_pad</structname></title> + <tgroup cols="5"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Unique ID for the pad.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>source_id</structfield></entry> + <entry></entry> + <entry></entry> + <entry> + <para>On pad to pad links: unique ID for the source pad.</para> + <para>On interface to entity links: unique ID for the interface.</para> + </entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>sink_id</structfield></entry> + <entry></entry> + <entry></entry> + <entry> + <para>On pad to pad links: unique ID for the sink pad.</para> + <para>On interface to entity links: unique ID for the entity.</para> + </entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry></entry> + <entry></entry> + <entry>Link flags, see <xref linkend="media-link-flag" /> for more details.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[5]</entry> + <entry></entry> + <entry></entry> + <entry>Reserved for future extensions. Drivers and applications must + set this array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>ENOSPC</errorcode></term> + <listitem> + <para>This is returned when either one or more of the num_entities, + num_interfaces, num_links or num_pads are non-zero and are smaller + than the actual number of elements inside the graph. This may happen + if the <constant>topology_version</constant> changed when compared + to the last time this ioctl was called. Userspace should usually + free the area for the pointers, zero the struct elements and call + this ioctl again.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml new file mode 100644 index 000000000000..0ee0f3386cdf --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -0,0 +1,236 @@ +<section id="media-controller-types"> +<title>Types and flags used to represent the media graph elements</title> + + <table frame="none" pgwide="1" id="media-entity-type"> + <title>Media entity types</title> + <tgroup cols="2"> + <colspec colname="c1"/> + <colspec colname="c2"/> + <tbody valign="top"> + <row> + <entry><constant>MEDIA_ENT_F_UNKNOWN</constant> and <constant>MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN</constant></entry> + <entry>Unknown entity. That generally indicates that + a driver didn't initialize properly the entity, with is a Kernel bug</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_IO_V4L</constant></entry> + <entry>Data streaming input and/or output entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_IO_VBI</constant></entry> + <entry>V4L VBI streaming input or output entity</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_IO_SWRADIO</constant></entry> + <entry>V4L Software Digital Radio (SDR) streaming input or output entity</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_IO_DTV</constant></entry> + <entry>DVB Digital TV streaming input or output entity</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_DTV_DEMOD</constant></entry> + <entry>Digital TV demodulator entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_TS_DEMUX</constant></entry> + <entry>MPEG Transport stream demux entity. Could be implemented on hardware or in Kernelspace by the Linux DVB subsystem.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_DTV_CA</constant></entry> + <entry>Digital TV Conditional Access module (CAM) entity</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_DTV_NET_DECAP</constant></entry> + <entry>Digital TV network ULE/MLE desencapsulation entity. Could be implemented on hardware or in Kernelspace</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_CONN_RF</constant></entry> + <entry>Connector for a Radio Frequency (RF) signal.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_CONN_SVIDEO</constant></entry> + <entry>Connector for a S-Video signal.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_CONN_COMPOSITE</constant></entry> + <entry>Connector for a RGB composite signal.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_CAM_SENSOR</constant></entry> + <entry>Camera video sensor entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_FLASH</constant></entry> + <entry>Flash controller entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_LENS</constant></entry> + <entry>Lens controller entity.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_ATV_DECODER</constant></entry> + <entry>Analog video decoder, the basic function of the video decoder + is to accept analogue video from a wide variety of sources such as + broadcast, DVD players, cameras and video cassette recorders, in + either NTSC, PAL, SECAM or HD format, separating the stream + into its component parts, luminance and chrominance, and output + it in some digital video standard, with appropriate timing + signals.</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_F_TUNER</constant></entry> + <entry>Digital TV, analog TV, radio and/or software radio tuner.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="media-entity-flag"> + <title>Media entity flags</title> + <tgroup cols="2"> + <colspec colname="c1"/> + <colspec colname="c2"/> + <tbody valign="top"> + <row> + <entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry> + <entry>Default entity for its type. Used to discover the default + audio, VBI and video devices, the default camera sensor, ...</entry> + </row> + <row> + <entry><constant>MEDIA_ENT_FL_CONNECTOR</constant></entry> + <entry>The entity represents a data conector</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="media-intf-type"> + <title>Media interface types</title> + <tgroup cols="3"> + <colspec colname="c1"/> + <colspec colname="c2"/> + <colspec colname="c3"/> + <tbody valign="top"> + <row> + <entry><constant>MEDIA_INTF_T_DVB_FE</constant></entry> + <entry>Device node interface for the Digital TV frontend</entry> + <entry>typically, /dev/dvb/adapter?/frontend?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_DVB_DEMUX</constant></entry> + <entry>Device node interface for the Digital TV demux</entry> + <entry>typically, /dev/dvb/adapter?/demux?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_DVB_DVR</constant></entry> + <entry>Device node interface for the Digital TV DVR</entry> + <entry>typically, /dev/dvb/adapter?/dvr?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_DVB_CA</constant></entry> + <entry>Device node interface for the Digital TV Conditional Access</entry> + <entry>typically, /dev/dvb/adapter?/ca?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_DVB_FE</constant></entry> + <entry>Device node interface for the Digital TV network control</entry> + <entry>typically, /dev/dvb/adapter?/net?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_V4L_VIDEO</constant></entry> + <entry>Device node interface for video (V4L)</entry> + <entry>typically, /dev/video?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_V4L_VBI</constant></entry> + <entry>Device node interface for VBI (V4L)</entry> + <entry>typically, /dev/vbi?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_V4L_RADIO</constant></entry> + <entry>Device node interface for radio (V4L)</entry> + <entry>typically, /dev/vbi?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_V4L_SUBDEV</constant></entry> + <entry>Device node interface for a V4L subdevice</entry> + <entry>typically, /dev/v4l-subdev?</entry> + </row> + <row> + <entry><constant>MEDIA_INTF_T_V4L_SWRADIO</constant></entry> + <entry>Device node interface for Software Defined Radio (V4L)</entry> + <entry>typically, /dev/swradio?</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="media-pad-flag"> + <title>Media pad flags</title> + <tgroup cols="2"> + <colspec colname="c1"/> + <colspec colname="c2"/> + <tbody valign="top"> + <row> + <entry><constant>MEDIA_PAD_FL_SINK</constant></entry> + <entry>Input pad, relative to the entity. Input pads sink data and + are targets of links.</entry> + </row> + <row> + <entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry> + <entry>Output pad, relative to the entity. Output pads source data + and are origins of links.</entry> + </row> + <row> + <entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry> + <entry>If this flag is set and the pad is linked to any other + pad, then at least one of those links must be enabled for the + entity to be able to stream. There could be temporary reasons + (e.g. device configuration dependent) for the pad to need + enabled links even when this flag isn't set; the absence of the + flag doesn't imply there is none.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and + <constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para> + + <table frame="none" pgwide="1" id="media-link-flag"> + <title>Media link flags</title> + <tgroup cols="2"> + <colspec colname="c1"/> + <colspec colname="c2"/> + <tbody valign="top"> + <row> + <entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry> + <entry>The link is enabled and can be used to transfer media data. + When two or more links target a sink pad, only one of them can be + enabled at a time.</entry> + </row> + <row> + <entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry> + <entry>The link enabled state can't be modified at runtime. An + immutable link is always enabled.</entry> + </row> + <row> + <entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry> + <entry>The link enabled state can be modified during streaming. This + flag is set by drivers and is read-only for applications.</entry> + </row> + <row> + <entry><constant>MEDIA_LNK_FL_LINK_TYPE</constant></entry> + <entry><para>This is a bitmask that defines the type of the link. + Currently, two types of links are supported:</para> + <para><constant>MEDIA_LNK_FL_DATA_LINK</constant> + if the link is between two pads</para> + <para><constant>MEDIA_LNK_FL_INTERFACE_LINK</constant> + if the link is between an interface and an entity</para></entry> + </row> + </tbody> + </tgroup> + </table> + +</section> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 7e61643358de..42e626d6c936 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -152,6 +152,16 @@ structs, ioctls) must be noted in more detail in the history chapter (compat.xml), along with the possible impact on existing drivers and applications. --> <revision> + <revnumber>4.5</revnumber> + <date>2015-10-29</date> + <authorinitials>rr</authorinitials> + <revremark>Extend vidioc-g-ext-ctrls;. Replace ctrl_class with a new +union with ctrl_class and which. Which is used to select the current value of +the control or the default value. + </revremark> + </revision> + + <revision> <revnumber>4.4</revnumber> <date>2015-05-26</date> <authorinitials>ap</authorinitials> diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index 8ffe74f84af1..d81fa0d4016b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -58,7 +58,7 @@ <para>This ioctl is used to create buffers for <link linkend="mmap">memory mapped</link> or <link linkend="userp">user pointer</link> or <link linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in -addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter +addition to the &VIDIOC-REQBUFS; ioctl, when a tighter control over buffers is required. This ioctl can be called multiple times to create buffers of different sizes.</para> @@ -71,30 +71,28 @@ zeroed.</para> <para>The <structfield>format</structfield> field specifies the image format that the buffers must be able to handle. The application has to fill in this -&v4l2-format;. Usually this will be done using the -<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl() -to ensure that the requested format is supported by the driver. Unsupported -formats will result in an error.</para> +&v4l2-format;. Usually this will be done using the &VIDIOC-TRY-FMT; or &VIDIOC-G-FMT; ioctls +to ensure that the requested format is supported by the driver. +Based on the format's <structfield>type</structfield> field the requested buffer +size (for single-planar) or plane sizes (for multi-planar formats) will be +used for the allocated buffers. The driver may return an error if the size(s) +are not supported by the hardware (usually because they are too small).</para> <para>The buffers created by this ioctl will have as minimum size the size -defined by the <structfield>format.pix.sizeimage</structfield> field. If the +defined by the <structfield>format.pix.sizeimage</structfield> field (or the +corresponding fields for other format types). Usually if the <structfield>format.pix.sizeimage</structfield> field is less than the minimum -required for the given format, then <structfield>sizeimage</structfield> will be -increased by the driver to that minimum to allocate the buffers. If it is -larger, then the value will be used as-is. The same applies to the -<structfield>sizeimage</structfield> field of the -<structname>v4l2_plane_pix_format</structname> structure in the case of -multiplanar formats.</para> +required for the given format, then an error will be returned since drivers will +typically not allow this. If it is larger, then the value will be used as-is. +In other words, the driver may reject the requested size, but if it is accepted +the driver will use it unchanged.</para> <para>When the ioctl is called with a pointer to this structure the driver will attempt to allocate up to the requested number of buffers and store the actual number allocated and the starting index in the <structfield>count</structfield> and the <structfield>index</structfield> fields respectively. On return <structfield>count</structfield> can be smaller than -the number requested. The driver may also increase buffer sizes if required, -however, it will not update <structfield>sizeimage</structfield> field values. -The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that -information.</para> +the number requested.</para> <table pgwide="1" frame="none" id="v4l2-create-buffers"> <title>struct <structname>v4l2_create_buffers</structname></title> diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml index 4c4603c135fe..f14a3bb1afaa 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml @@ -99,7 +99,7 @@ if the driver supports writing registers to the device.</para> <para>We recommended the <application>v4l2-dbg</application> utility over calling this ioctl directly. It is available from the LinuxTV v4l-dvb repository; see <ulink -url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for +url="https://linuxtv.org/repo/">https://linuxtv.org/repo/</ulink> for access instructions.</para> <!-- Note for convenience vidioc-dbg-g-register.sgml diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml index 3d038e75d12b..5877f68a5820 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml @@ -117,7 +117,7 @@ However when a driver supports these ioctls it must also support <para>We recommended the <application>v4l2-dbg</application> utility over calling these ioctls directly. It is available from the LinuxTV v4l-dvb repository; see <ulink -url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for +url="https://linuxtv.org/repo/">https://linuxtv.org/repo/</ulink> for access instructions.</para> <!-- Note for convenience vidioc-dbg-g-chip-info.sgml diff --git a/Documentation/DocBook/media/v4l/vidioc-enumstd.xml b/Documentation/DocBook/media/v4l/vidioc-enumstd.xml index 8065099401d1..f18454e91752 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enumstd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enumstd.xml @@ -198,7 +198,7 @@ video4linux-list@redhat.com on 17 Oct 2002 <constant>V4L2_STD_ATSC_16_VSB</constant> are U.S. terrestrial digital TV standards. Presently the V4L2 API does not support digital TV. See also the Linux DVB API at <ulink -url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> +url="https://linuxtv.org">https://linuxtv.org</ulink>.</para> <para><programlisting> #define V4L2_STD_PAL_BG (V4L2_STD_PAL_B |\ V4L2_STD_PAL_B1 |\ diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 842536aae8b4..eb82f7e7d06b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -61,7 +61,7 @@ must belong to the same control class.</para> <para>Applications must always fill in the <structfield>count</structfield>, -<structfield>ctrl_class</structfield>, +<structfield>which</structfield>, <structfield>controls</structfield> and <structfield>reserved</structfield> fields of &v4l2-ext-controls;, and initialize the &v4l2-ext-control; array pointed to by the @@ -109,7 +109,7 @@ the driver whether wrong values are automatically adjusted to a valid value or if an error is returned.</para> <para>When the <structfield>id</structfield> or -<structfield>ctrl_class</structfield> is invalid drivers return an +<structfield>which</structfield> is invalid drivers return an &EINVAL;. When the value is out of bounds drivers can choose to take the closest valid value or return an &ERANGE;, whatever seems more appropriate. In the first case the new value is set in @@ -223,7 +223,12 @@ Valid if <constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set for this control <tgroup cols="3"> &cs-str; <tbody valign="top"> + <row> + <entry>union</entry> + <entry>(anonymous)</entry> + </row> <row> + <entry></entry> <entry>__u32</entry> <entry><structfield>ctrl_class</structfield></entry> <entry>The control class to which all controls belong, see @@ -235,6 +240,23 @@ with a <structfield>count</structfield> of 0. If that succeeds, then the driver supports this feature.</entry> </row> <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>which</structfield></entry> + <entry><para>Which value of the control to get/set/try. <constant>V4L2_CTRL_WHICH_CUR_VAL</constant> +will return the current value of the control and <constant>V4L2_CTRL_WHICH_DEF_VAL</constant> will +return the default value of the control. Please note that you can only get the default value of the +control, you cannot set or try it.</para> +<para>For backwards compatibility you can also use a control class here (see +<xref linkend="ctrl-class" />). In that case all controls have to belong to that +control class. This usage is deprecated, instead just use <constant>V4L2_CTRL_WHICH_CUR_VAL</constant>. +There are some very old drivers that do not yet support <constant>V4L2_CTRL_WHICH_CUR_VAL</constant> +and that require a control class here. You can test for such drivers by setting ctrl_class to +<constant>V4L2_CTRL_WHICH_CUR_VAL</constant> and calling VIDIOC_TRY_EXT_CTRLS with a count of 0. +If that fails, then the driver does not support <constant>V4L2_CTRL_WHICH_CUR_VAL</constant>.</para> +</entry> + </row> + <row> <entry>__u32</entry> <entry><structfield>count</structfield></entry> <entry>The number of controls in the controls array. May @@ -390,7 +412,7 @@ These controls are described in <xref linkend="rf-tuner-controls" />.</entry> <listitem> <para>The &v4l2-ext-control; <structfield>id</structfield> is invalid, the &v4l2-ext-controls; -<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control; +<structfield>which</structfield> is invalid, or the &v4l2-ext-control; <structfield>value</structfield> was inappropriate (e.g. the given menu index is not supported by the driver). This error code is also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 92037033f5eb..7b77e0f7b87d 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -19,10 +19,10 @@ <!ENTITY cs-def "<colspec colname='c1' colwidth='3*' /><colspec colname='c2' colwidth='1*' /><colspec colname='c3' colwidth='4*' /><spanspec spanname='hspan' namest='c1' nameend='c3' />"> <!-- Video for Linux mailing list address. --> -<!ENTITY v4l-ml "<ulink url='http://www.linuxtv.org/lists.php'>http://www.linuxtv.org/lists.php</ulink>"> +<!ENTITY v4l-ml "<ulink url='https://linuxtv.org/lists.php'>https://linuxtv.org/lists.php</ulink>"> <!-- LinuxTV v4l-dvb repository. --> -<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> +<!ENTITY v4l-dvb "<ulink url='https://linuxtv.org/repo/'>https://linuxtv.org/repo/</ulink>"> <!ENTITY dash-ent-8 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> <!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> <!ENTITY dash-ent-12 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> @@ -91,7 +91,7 @@ components, like mixers, PCM capture, PCM playback, etc, which are controlled via ALSA API.</para> <para>For additional information and for the latest development code, - see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> + see: <ulink url="https://linuxtv.org">https://linuxtv.org</ulink>.</para> <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> </preface> diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 7da8f0402af5..b442921bca54 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -162,12 +162,15 @@ <sect1 id="Basic_defines"> <title>Basic defines</title> <para> - At least you have to provide a mtd structure and - a storage for the ioremap'ed chip address. - You can allocate the mtd structure using kmalloc - or you can allocate it statically. - In case of static allocation you have to allocate - a nand_chip structure too. + At least you have to provide a nand_chip structure + and a storage for the ioremap'ed chip address. + You can allocate the nand_chip structure using + kmalloc or you can allocate it statically. + The NAND chip structure embeds an mtd structure + which will be registered to the MTD subsystem. + You can extract a pointer to the mtd structure + from a nand_chip pointer using the nand_to_mtd() + helper. </para> <para> Kmalloc based example @@ -180,7 +183,6 @@ static void __iomem *baseaddr; Static example </para> <programlisting> -static struct mtd_info board_mtd; static struct nand_chip board_chip; static void __iomem *baseaddr; </programlisting> @@ -235,7 +237,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd) <programlisting> static void board_hwcontrol(struct mtd_info *mtd, int cmd) { - struct nand_chip *this = (struct nand_chip *) mtd->priv; + struct nand_chip *this = mtd_to_nand(mtd); switch(cmd){ case NAND_CTL_SETCLE: this->IO_ADDR_W |= CLE_ADRR_BIT; break; case NAND_CTL_CLRCLE: this->IO_ADDR_W &= ~CLE_ADRR_BIT; break; @@ -274,13 +276,15 @@ static int __init board_init (void) int err = 0; /* Allocate memory for MTD device structure and private data */ - board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL); - if (!board_mtd) { + this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL); + if (!this) { printk ("Unable to allocate NAND MTD device structure.\n"); err = -ENOMEM; goto out; } + board_mtd = nand_to_mtd(this); + /* map physical address */ baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024); if (!baseaddr) { @@ -289,11 +293,6 @@ static int __init board_init (void) goto out_mtd; } - /* Get pointer to private data */ - this = (struct nand_chip *) (); - /* Link the private data with the MTD structure */ - board_mtd->priv = this; - /* Set address of NAND IO lines */ this->IO_ADDR_R = baseaddr; this->IO_ADDR_W = baseaddr; @@ -317,7 +316,7 @@ static int __init board_init (void) out_ior: iounmap(baseaddr); out_mtd: - kfree (board_mtd); + kfree (this); out: return err; } @@ -343,7 +342,7 @@ static void __exit board_cleanup (void) iounmap(baseaddr); /* Free the MTD device structure */ - kfree (board_mtd); + kfree (mtd_to_nand(board_mtd)); } module_exit(board_cleanup); #endif @@ -399,7 +398,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) <programlisting> static void board_select_chip (struct mtd_info *mtd, int chip) { - struct nand_chip *this = (struct nand_chip *) mtd->priv; + struct nand_chip *this = mtd_to_nand(mtd); /* Deselect all chips */ this->IO_ADDR_R &= ~BOARD_NAND_ADDR_MASK; |