Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 0d9d349d authored by Daniel Vetter's avatar Daniel Vetter
Browse files

Merge commit origin/master into drm-intel-next 



Conflicts are getting out of hand, and now we have to shuffle even
more in -next which was also shuffled in -fixes (the call for
drm_mode_config_reset needs to move yet again).

So do a proper backmerge. I wanted to wait with this for the 3.13
relaese, but alas let's just do this now.

Conflicts:
	drivers/gpu/drm/i915/i915_reg.h
	drivers/gpu/drm/i915/intel_ddi.c
	drivers/gpu/drm/i915/intel_display.c
	drivers/gpu/drm/i915/intel_pm.c

Besides the conflict around the forcewake get/put (where we chaged the
called function in -fixes and added a new parameter in -next) code all
the current conflicts are of the adjacent lines changed type.

Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
parents cba1c073 145830df

CREDITS

+5 −0
Original line number Diff line number Diff line
@@ -655,6 +655,11 @@ S: Stanford University 
S: Stanford, California 94305

S: USA



N: Carlos Chinea

E: carlos.chinea@nokia.com

E: cch.devel@gmail.com

D: Author of HSI Subsystem



N: Randolph Chung

E: tausq@debian.org

D: Linux/PA-RISC hacker

Documentation/DocBook/media/v4l/vidioc-expbuf.xml

+5 −3
Original line number Diff line number Diff line
@@ -73,7 +73,8 @@ range from zero to the maximal number of valid planes for the currently active 
format. For the single-planar API, applications must set <structfield> plane

</structfield> to zero.  Additional flags may be posted in the <structfield>

flags </structfield> field.  Refer to a manual for open() for details.

Currently only O_CLOEXEC is supported.  All other fields must be set to zero.

Currently only O_CLOEXEC, O_RDONLY, O_WRONLY, and O_RDWR are supported.  All

other fields must be set to zero.

In the case of multi-planar API, every plane is exported separately using

multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
@@ -170,8 +171,9 @@ multi-planar API. Otherwise this value must be set to zero. </entry> 
	    <entry>__u32</entry>

	    <entry><structfield>flags</structfield></entry>

	    <entry>Flags for the newly created file, currently only <constant>

O_CLOEXEC </constant> is supported, refer to the manual of open() for more

details.</entry>

O_CLOEXEC </constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY

</constant>, and <constant>O_RDWR</constant> are supported, refer to the manual

of open() for more details.</entry>

	  </row>

	  <row>

	    <entry>__s32</entry>

Documentation/assoc_array.txt

+3 −3
Original line number Diff line number Diff line
@@ -164,10 +164,10 @@ This points to a number of methods, all of which need to be provided: 


 (4) Diff the index keys of two objects.



	int (*diff_objects)(const void *a, const void *b);

	int (*diff_objects)(const void *object, const void *index_key);



     Return the bit position at which the index keys of two objects differ or

     -1 if they are the same.

     Return the bit position at which the index key of the specified object

     differs from the given index key or -1 if they are the same.





 (5) Free an object.

Documentation/block/null_blk.txt

0 → 100644
+72 −0
Original line number Diff line number Diff line 
Null block device driver

================================================================================



I. Overview



The null block device (/dev/nullb*) is used for benchmarking the various

block-layer implementations. It emulates a block device of X gigabytes in size.

The following instances are possible:



  Single-queue block-layer

    - Request-based.

    - Single submission queue per device.

    - Implements IO scheduling algorithms (CFQ, Deadline, noop).

  Multi-queue block-layer

    - Request-based.

    - Configurable submission queues per device.

  No block-layer (Known as bio-based)

    - Bio-based. IO requests are submitted directly to the device driver.

    - Directly accepts bio data structure and returns them.



All of them have a completion queue for each core in the system.



II. Module parameters applicable for all instances:



queue_mode=[0-2]: Default: 2-Multi-queue

  Selects which block-layer the module should instantiate with.



  0: Bio-based.

  1: Single-queue.

  2: Multi-queue.



home_node=[0--nr_nodes]: Default: NUMA_NO_NODE

  Selects what CPU node the data structures are allocated from.



gb=[Size in GB]: Default: 250GB

  The size of the device reported to the system.



bs=[Block size (in bytes)]: Default: 512 bytes

  The block size reported to the system.



nr_devices=[Number of devices]: Default: 2

  Number of block devices instantiated. They are instantiated as /dev/nullb0,

  etc.



irq_mode=[0-2]: Default: 1-Soft-irq

  The completion mode used for completing IOs to the block-layer.



  0: None.

  1: Soft-irq. Uses IPI to complete IOs across CPU nodes. Simulates the overhead

     when IOs are issued from another CPU node than the home the device is

     connected to.

  2: Timer: Waits a specific period (completion_nsec) for each IO before

     completion.



completion_nsec=[ns]: Default: 10.000ns

  Combined with irq_mode=2 (timer). The time each completion event must wait.



submit_queues=[0..nr_cpus]:

  The number of submission queues attached to the device driver. If unset, it

  defaults to 1 on single-queue and bio-based instances. For multi-queue,

  it is ignored when use_per_node_hctx module parameter is 1.



hw_queue_depth=[0..qdepth]: Default: 64

  The hardware queue depth of the device.



III: Multi-queue specific parameters



use_per_node_hctx=[0/1]: Default: 0

  0: The number of submit queues are set to the value of the submit_queues

     parameter.

  1: The multi-queue block layer is instantiated with a hardware dispatch

     queue for each CPU node in the system.

Documentation/device-mapper/cache.txt

+6 −4
Original line number Diff line number Diff line
@@ -266,10 +266,12 @@ E.g. 
Invalidation is removing an entry from the cache without writing it

back.  Cache blocks can be invalidated via the invalidate_cblocks

message, which takes an arbitrary number of cblock ranges.  Each cblock

must be expressed as a decimal value, in the future a variant message

that takes cblock ranges expressed in hexidecimal may be needed to

better support efficient invalidation of larger caches.  The cache must

be in passthrough mode when invalidate_cblocks is used.

range's end value is "one past the end", meaning 5-10 expresses a range

of values from 5 to 9.  Each cblock must be expressed as a decimal

value, in the future a variant message that takes cblock ranges

expressed in hexidecimal may be needed to better support efficient

invalidation of larger caches.  The cache must be in passthrough mode

when invalidate_cblocks is used.



   invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]*