amdkfd: Add process queue manager module

The queue scheduler divides into two sections, one section is process bounded
and the other section is device bounded.
The process bounded section is handled by this module. The PQM handles usermode
queue setup, updates and tear-down.

v3:

Used kernel parameter to limit queues per process instead of define
Added use of doorbell address from user

v4:

Modified pqm_create_queue so that only when creating usermode queues the
driver should return the queue properties to the userspace.

Added an info message print when no more queues can be opened because of the
queue per process limitation

v5:

Move amdkfd from drm/radeon/ to drm/amd/
Various fixes

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add packet manager module

The packet manager module builds PM4 packets for the sole use of the CP
scheduler. Those packets are used by the HIQ to submit runlists to the CP.

v3:

Removed include of cik_mqds.h
Changed lower_32/upper_32 calls to use linux macros
Used new gart allocation functions
Added documentation

v5:

Move amdkfd from drm/radeon/ to drm/amd/
Change format of mqd structure to match latest KV firmware
Add support for AQL queues creation to enable working with open-source HSA
runtime
Always chain runlist if you have more than 1 process or if you have
over-subscription over the number of queues.
Various fixes (typos, style)

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add module parameter of scheduling policy

This patch adds a new parameter to the amdkfd driver. This parameter enables
the user to select the scheduling policy of the CP. The choices are:

* CP Scheduling with support for over-subscription
* CP Scheduling without support for over-subscription
* Without CP Scheduling

Note that the third option (Without CP scheduling) is only for debug purposes
and bringup of new H/W. As such, it is _not_ guaranteed to work at all times on
all H/W versions.

v3: Fixed description of parameter, changed the permissions to read_only, added
a verification of the value and added documentation

v5: Set default sched_policy to HWS as it is now supported by firmware

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add kernel queue module

The kernel queue module enables the amdkfd to establish kernel queues, not
exposed to user space.

The kernel queues are used for HIQ (HSA Interface Queue) and DIQ (Debug
Interface Queue) operations

v3: Removed use of internal typedefs and added use of the new gart allocation
functions

v4: Fixed a miscalculation in kernel queue wrapping

v5:

Move amdkfd from drm/radeon/ to drm/amd/
Change format of mqd structure to match latest KV firmware
Add support for AQL queues creation to enable working with open-source HSA
runtime
Add define for kernel queue size
Various fixes

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add mqd_manager module

The mqd_manager module handles MQD data structures.
MQD stands for Memory Queue Descriptor, which is used by the H/W to
keep the usermode queue state in memory.

v3:

Removed new typedefs
Removed pragma pack 4
Remove cik_mqds.h file
Changed lower_32/upper_32 calls to use linux macros
Used new gart allocation functions
Added documentation

v4:

Added missing initialization of the addr field in init_mqd()

Setting the hqd persistent.preload_req bit ON so that when queues switches
on/off, their context will kept and read from the mqd when the cp reassign
them, and thus the dispatched workload context kept consistent without any
interrupts.

v5:

Move amdkfd from drm/radeon/ to drm/amd/
Change format of mqd structure to match latest KV firmware
Add support for AQL queues creation to enable working with open-source HSA
runtime.
Various fixes

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add queue module

The queue module enables allocating and initializing queues uniformly.

v3: Removed typedef and redundant memset call. Broke long pr_debug print to one
liners and Added documentation.

v5: Move amdkfd from drm/radeon/ to drm/amd/

Signed-off-by: Ben Goz <ben.goz@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add binding/unbinding calls to amd_iommu driver

This patch adds the functions to bind and unbind pasid
from a device through the amd_iommu driver.

The unbind function is called when the mm_struct of the
process is released.

The bind function is not called here because it is called
only in the IOCTLs which are not yet implemented at this
stage of the patchset.

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add basic modules to amdkfd

This patch adds the process module and three helper modules:

- kfd_process, which handles process which open /dev/kfd

- kfd_doorbell, which provides helper functions for doorbell allocation,
  release and mapping to userspace

- kfd_pasid, which provides helper functions for pasid allocation and release

- kfd_aperture, which provides helper functions for managing the LDS, Local GPU
  memory and Scratch memory apertures of the process

This patch only contains the basic kfd_process module, which doesn't contain
the reference to the queue scheduler. This was done to allow easier code review.

Also, this patch doesn't contain the calls to the IOMMU driver for binding the
pasid to the device. Again, this was done to allow easier code review

The kfd_process object is created when a process opens /dev/kfd and is closed
when the mm_struct of that process is teared-down.

v3:

Removed kfd_vidmem.c file
Replaced direct mmput call to mmu_notifier release
Removed typedefs
Moved bool field to end of the structure
Added new kernel params for gart usage limitation
Added initialization of sa manager
Fixed debug messages
Remove support for LDS in 32 bit
Changed code to support mmap of doorbell pages from userspace
Added documentation for apertures

v4: Replaced RCU by SRCU for kfd_process list management

v5:

Move amdkfd from drm/radeon/ to drm/amd/
Rename kfd_aperture.c to kfd_flat_memory.c
Protect against multiple init calls
MQD size is H/W dependent so moved it to device info structure
Rename kfd_mem_obj structure's members
Use delayed function for process tear-down

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add topology module to amdkfd

This patch adds the topology module to the driver. The topology is exposed to
userspace through the sysfs.

The calls to add and remove a device to/from topology are done by the radeon
driver.

v3:

The CPU information, that is provided in the topology section of the amdkfd
driver, is extracted from the CRAT table. Unlike the CPU information located
in /sys/devices/system/cpu/cpu*, which is extracted from the SRAT table.

While the CPU information provided by the CRAT and the SRAT tables might be
identical, the node topology might be different. The SRAT table contains the
topology of CPU nodes only. The CRAT table contains the topology of CPU and GPU
nodes together (and can be interleaved). For example CPU node 1 in SRAT can be
CPU node 3 in CRAT. Furthermore it's worth to mention that the CRAT table
contains only HSA compatible nodes (nodes which are compliant with the HSA
spec).

To recap, amdkfd exposes a different kind of topology than the one exposed by
/sys/devices/system/cpu/cpu even though it may contain similar information.

v4:

The topology module doesn't support uevent handling and doesn't notify the
userspace about runtime modifications. It is up to the userspace to acquire
snapshots of the topology information created by the amdkfd and exposed
in sysfs.

The following is an example of how the topology looks on a Kaveri A10-7850K
system with amdkfd installed:

/sys/devices/virtual/kfd/kfd/
|
--- topology/
      |
      |--- generation_id
      |--- system_properties
      |--- nodes/
            |
            |--- 0/
                 |
                 |--- gpu_id
                 |--- name
                 |--- properties
                 |--- caches/
                      |
                      |--- 0/
                           |
                           |--- properties
                      |--- 1/
                           |
                           |--- properties
                      |--- 2/
                           |
                           |--- properties
                 |--- io_links/
                      |
                 |--- mem_banks/
                      |
                      |--- 0/
                           |
                           |--- properties
                      |--- 1/
                           |
                           |--- properties
                      |--- 2/
                           |
                           |--- properties
                      |--- 3/
                           |
                           |--- properties

v5:

Move amdkfd from drm/radeon/ to drm/amd/

Add a check if dev->gpu pointer is null before accessing it in the
node_show function in kfd_topology.c
This situation may occur when amdkfd is loaded and there is a GPU with a CRAT
table, but that GPU isn't supported by amdkfd

Signed-off-by: Evgeny Pinchuk <evgeny.pinchuk@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add amdkfd skeleton driver

This patch adds the amdkfd skeleton driver. The driver does nothing except
define a /dev/kfd device.

It returns -ENODEV on all amdkfd IOCTLs.

v3: Move bool field to the end of structure, removed the pmc ioctls and added
a meaningful error message for ioctl error.

v5:

Create a new folder drm/amd and move amdkfd from drm/radeon/ to drm/amd/
Remove scheduler_class from kfd_priv.h as it was never used
Add skeleton implementation of the Get Version IOCTL

v6:
Update module version to the correct number and remove the "default m" from the
Kconfig file

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

amdkfd: Add IOCTL set definitions of amdkfd

- KFD_IOC_GET_VERSION:
Retrieves the interface version of amdkfd

- KFD_IOC_CREATE_QUEUE:
Creates a usermode queue that runs on a specific GPU device

- KFD_IOC_DESTROY_QUEUE:
Destroys an existing usermode queue

- KFD_IOC_SET_MEMORY_POLICY:
Sets the memory policy of the default and alternate aperture of the
        calling process

- KFD_IOC_GET_CLOCK_COUNTERS:
Retrieves counters (timestamps) of CPU and GPU

- KFD_IOC_GET_PROCESS_APERTURES:
Retrieves information about process apertures that were initialized
        during the open() call of the amdkfd device

- KFD_IOC_UPDATE_QUEUE:
Updates configuration of an existing usermode queue

v3: Remove pragma pack and pmc ioctls. Added parameter for doorbell offset and
a comment on counters

v5:

Add define for AQL queues.
Fix arguments of Get Version IOCTL
Make IOCTL's structures to be the same size on 32/64 bit

v6: Change the version of the amdkfd-thunk interface

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

Update MAINTAINERS and CREDITS files with amdkfd info

v6: Update entries to reflect new name & location of driver

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

drm/radeon: Add radeon <--> amdkfd interface

This patch adds the interface between the radeon driver and the amdkfd driver.
The interface implementation is contained in radeon_kfd.c and radeon_kfd.h.

The interface itself is represented by a pointer to struct
kfd_dev. The pointer is located inside radeon_device structure.

All the register accesses that amdkfd need are done using this interface. This
allows us to avoid direct register accesses in amdkfd proper,  while also
avoiding locking between amdkfd and radeon.

The single exception is the doorbells that are used in both of the drivers.
However, because they are located in separate pci bar pages, the danger of
sharing registers between the drivers is minimal.

Having said that, we are planning to move the doorbells as well to radeon.

v3:

Add interface for sa manager init and fini. The init function will allocate a
buffer on system memory and pin it to the GART address space via the radeon sa
manager.

All mappings of buffers to GART address space are done via the radeon sa
manager. The interface of allocate memory will use the radeon sa manager to sub
allocate from the single buffer that was allocated during the init function.

Change lower_32/upper_32 calls to use linux macros

Add documentation for the interface

v4:

Change ptr field type in kgd_mem from uint32_t* to void* to match to type that
is returned by radeon_sa_bo_cpu_addr

v5:

Change format of mqd structure to work with latest KV firmware
Add support for AQL queues creation to enable working with open-source HSA
runtime.
Move generic kfd-->kgd interface and other generic kgd definitions to a generic
header file that will be used by AMD's radeon and amdgpu drivers

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

drm/radeon: adding synchronization for GRBM GFX

Implementing a lock for selecting and accessing shader engines and arrays.
This lock will make sure that radeon and amdkfd are not colliding when
accessing shader engines and arrays with GRBM_GFX_INDEX register.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

drm/radeon: Report doorbell configuration to amdkfd

radeon and amdkfd share the doorbell aperture.
radeon sets it up, takes the doorbells required for its own rings
and reports the setup to amdkfd.
radeon reserved doorbells are at the start of the doorbell aperture.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

drm/radeon/cik: Don't touch int of pipes 1-7

amdkfd should set interrupts for pipes 1-7.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

drm/radeon: reduce number of free VMIDs and pipes in KV

To support HSA on KV, we need to limit the number of vmids and pipes
that are available for radeon's use with KV.

This patch reserves VMIDs 8-15 for amdkfd (so radeon can only use VMIDs
0-7) and also makes radeon thinks that KV has only a single MEC with a single
pipe in it

v3: Use define for static vmid allocation in radeon

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

iommu/amd: fix accounting of device_state

This patch fixes a bug in the accounting of the device_state.
In the current code, the device_state was put (decremented) too many times,
which sometimes lead to the driver getting stuck permanently in
put_device_state_wait(). That happen because the device_state->count would go
below zero, which is never supposed to happen.

The root cause is that the device_state was decremented in put_pasid_state()
and put_pasid_state_wait() but also in all the functions that call those
functions. Therefore, the device_state was decremented twice in each of these
code paths.

The fix is to decouple the device_state accounting from the pasid_state
accounting - remove the call to put_device_state() from the
put_pasid_state() and the put_pasid_state_wait())

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

iommu/amd: use new invalidate_range mmu-notifier

Make use of the new invalidate_range mmu_notifier call-back and remove the
old logic of assigning an empty page-table between invalidate_range_start
and invalidate_range_end.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
Tested-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Jay Cornwall <Jay.Cornwall@amd.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

mmu_notifier: add the callback for mmu_notifier_invalidate_range()

Now that the mmu_notifier_invalidate_range() calls are in place, add the
callback to allow subsystems to register against it.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Jay Cornwall <Jay.Cornwall@amd.com>
Cc: Oded Gabbay <Oded.Gabbay@amd.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

mmu_notifier: call mmu_notifier_invalidate_range() from VMM

Add calls to the new mmu_notifier_invalidate_range() function to all
places in the VMM that need it.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Jay Cornwall <Jay.Cornwall@amd.com>
Cc: Oded Gabbay <Oded.Gabbay@amd.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

mmu_notifier: add mmu_notifier_invalidate_range()

This notifier closes an important gap in the current mmu_notifier
implementation, the existing callbacks are called too early or too late to
reliably manage a non-CPU TLB.  Specifically, invalidate_range_start() is
called when all pages are still mapped and invalidate_range_end() when all
pages are unmapped and potentially freed.

This is fine when the users of the mmu_notifiers manage their own SoftTLB,
like KVM does.  When the TLB is managed in software it is easy to wipe out
entries for a given range and prevent new entries to be established until
invalidate_range_end is called.

But when the user of mmu_notifiers has to manage a hardware TLB it can
still wipe out TLB entries in invalidate_range_start, but it can't make
sure that no new TLB entries in the given range are established between
invalidate_range_start and invalidate_range_end.

To avoid silent data corruption the entries in the non-CPU TLB need to be
flushed when the pages are unmapped (at this point in time no _new_ TLB
entries can be established in the non-CPU TLB) but not yet freed (as the
non-CPU TLB may still have _existing_ entries pointing to the pages about
to be freed).

To fix this problem we need to catch the moment when the Linux VMM flushes
remote TLBs (as a non-CPU TLB is not very CPU TLB), as this is the point
in time when the pages are unmapped but _not_ yet freed.

The mmu_notifier_invalidate_range() function aims to catch that moment.

IOMMU code will be one user of the notifier-callback.  Currently this is
only the AMD IOMMUv2 driver, but its code is about to be more generalized
and converted to a generic IOMMU-API extension to fit the needs of similar
functionality in other IOMMUs as well.

The current attempt in the AMD IOMMUv2 driver to work around the
invalidate_range_start/end() shortcoming is to assign an empty page table
to the non-CPU TLB between any invalidata_range_start/end calls.  With the
empty page-table assigned, every page-table walk to re-fill the non-CPU
TLB will cause a page-fault reported to the IOMMU driver via an interrupt,
possibly causing interrupt storms.

The page-fault handler in the AMD IOMMUv2 driver doesn't handle the fault
if an invalidate_range_start/end pair is active, it just reports back
SUCCESS to the device and let it refault the page.  But existing hardware
(newer Radeon GPUs) that makes use of this feature don't re-fault
indefinitly, after a certain number of faults for the same address the
device enters a failure state and needs to be resetted.

To avoid the GPUs entering a failure state we need to get rid of the
empty-page-table workaround and use the mmu_notifier_invalidate_range()
function introduced with this patch.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Johannes Weiner <jweiner@redhat.com>
Cc: Jay Cornwall <Jay.Cornwall@amd.com>
Cc: Oded Gabbay <Oded.Gabbay@amd.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

Merge branch 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux into drm-next

Radeon patches for 3.19.  Christian has a number of GPUVM improvements
slated as well, but I'd like to wait until he gets back to work next week
to pull those in. Highlights of this pull:
- ttm performance improvements
- CI dpm fixes

* 'drm-next-3.19' of git://people.freedesktop.org/~agd5f/linux: (26 commits)
  drm/radeon/si/ci: make u8 static arrays constant
  drm/radeon: set power control in ci dpm enable
  drm/radeon: powertune fixes for hawaii
  drm/radeon: fix dpm mc init for certain hawaii boards
  drm/radeon: set bootup pcie level to max for ci dpm
  drm/radeon: fix default dpm state setup
  drm/radeon: workaround a hw bug in bonaire pcie dpm
  drm/radeon: fix mclk vddc configuration for cards for hawaii
  drm/radeon: fix sclk DS enablement
  drm/radeon: fix activity settings for sclk and mclk for CI
  drm/radeon: improve mclk param calcuations for ci dpm
  drm/radeon: fix dram timing for certain hawaii boards
  drm/radeon: switch force state commands for CI
  drm/radeon: fix for memory training on bonaire 0x6649
  drm/radeon/ci: handle gpio controlled dpm features properly
  drm/radeon: store the gpio shift as well
  drm/radeon: export radeon_atombios_lookup_gpio
  drm/radeon: fix typo in CI dpm disable
  drm/radeon: rework CI dpm thermal setup
  drm/radeon: rework SI dpm thermal setup
  ...

drm/radeon/si/ci: make u8 static arrays constant

These two arrays don't change, just make them constant,
reduces data segment by a few bytes.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: set power control in ci dpm enable

Necessary for poper operation.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: powertune fixes for hawaii

- bapm is not available on hawaii
- update pt defaults

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix dpm mc init for certain hawaii boards

Needs special overrides for certain vram configurations.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: set bootup pcie level to max for ci dpm

Avoids problems when re-loading the driver.  Does not
affect power saving when dpm is enabled.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix default dpm state setup

Only enable the first levels for mclk and sclk.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: workaround a hw bug in bonaire pcie dpm

Some boards get stuck in pcie x1 otherwise.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix mclk vddc configuration for cards for hawaii

Need to use vddc0 for vdcc1 for certain hawaii configurations.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix sclk DS enablement

Only enable it for levels 0 and 1.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix activity settings for sclk and mclk for CI

Only need to be enabled on the first level.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: improve mclk param calcuations for ci dpm

Properly take into account the post divider.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix dram timing for certain hawaii boards

Certain memory configurations need a fix.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: switch force state commands for CI

Use the preferred SMC commands for forcing state on CI.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix for memory training on bonaire 0x6649

Workaround for memory link training on certain variants
of 0x6649.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/ci: handle gpio controlled dpm features properly

Certain feature enablement depends on entries in the atom
gpio pin table.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: store the gpio shift as well

We need this in the dpm code.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: export radeon_atombios_lookup_gpio

We need it for dpm.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix typo in CI dpm disable

Need to disable DS, not enable it when disabling dpm.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: rework CI dpm thermal setup

In preparation for fan control.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: rework SI dpm thermal setup

In preparation for fan control.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/dpm: grab fan info from vbios

Required for fan control support.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN

DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
against the idea of TTM_PL_FLAG_TOPDOWN:

* The smallest hole may be in the overall bottom of the area
* If the hole isn't much larger than the BO, it doesn't make much
  difference whether the BO is placed at the bottom or at the top of the
  hole

Reviewed-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/ttm: Add DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN

If the BO should be placed at the top of the area, we should start looking
for holes from the top.

Reviewed-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Set TTM_PL_FLAG_TOPDOWN also for RADEON_GEM_CPU_ACCESS BOs

I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but
AFAICT it does.

Reviewed-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM

This avoids them getting in the way of BOs which might be accessed by
the CPU. They can still go to the CPU accessible part of VRAM though if
there's no space outside of it.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: More specific locking for get* ioctls

Motivated by the per-plane locking I've gone through all the get*
ioctls and reduced the locking to the bare minimum required.

v2: Rebase and make it compile ...

v3: Review from Sean:
- Simplify return handling in getplane_res.
- Add a comment to getplane_res that the plane list is invariant and
  can be walked locklessly.

v4: Actually git add.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Per-plane locking

Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:

- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
  justification as for the equivalent change in drm_crtc_init done in

commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 8 09:02:49 2014 +0200

    drm: Drop modeset locking from crtc init function

  Without these the drm_modeset_lock_init would fall over the exact
  same way.

- Since the atomic core code wraps the locking switching it to
  per-plane locks was a one-line change.

- For the legacy ioctls add a plane argument to the locking helper so
  that we can grab the right plane lock (cursor or primary). Since the
  universal cursor plane might not be there, or someone really crazy
  might forgoe the primary plane even accept NULL.

- Add some locking WARN_ON to the atomic helpers for good paranoid
  measure and to check that it all works out.

Tested on my exynos atomic hackfest with full lockdep checks and ww
backoff injection.

v2: I've forgotten about the load-detect code in i915.

v3: Thierry reported that in latest 3.18-rc vmwgfx doesn't compile any
more due to

commit 21e88620aa21b48d4f62d29275e3e2944a5ea2b5
Author: Rob Clark <robdclark@gmail.com>
Date:   Thu Oct 30 13:39:04 2014 -0400

    drm/vmwgfx: fix lock breakage

Rebased and fix this up.

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: export atomic wait_for_vblanks helper (v2)

v1: original
v2: danvet's kerneldoc nitpicks

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'v3.18-rc4' into drm-next

backmerge to get vmwgfx locking changes into next as the
conflict with per-plane locking.

drm/mode: document path property and function to set it. (v1.1)

These two didn't get documented properly, do so.

Pointed out by Daniel.

v1.1: add missing boilerplate (Daniel)

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel into drm-next

So here's my atomic series, finally all debugged&reviewed. Sean Paul has
done a full detailed pass over it all, and a lot of other people have
commented and provided feedback on some parts. Rob Clark also converted
msm over the w/e and seems happy. The only small thing is that Rob wants
to export the wait_for_vblank, which imo makes sense. Since there's other
stuff still to do I think we should apply Rob's patch (once it has grown
appropriate kerneldoc) later on top of this.

This is just the core<->driver interface plus a big pile of helpers. Short
recap of the main ideas:

- There are essentially three helper libraries in this patch set:

  * Transitional helpers to use the new plane callbacks for legacy plane
    updates and in the crtc helper's ->mode_set callback. These helpers are
    only temporarily used to convert drivers to atomic, but they allow a
    nice separation between changing the driver backend and switching to
    the atomic commit logic.

  * Legacy helpers to implement all the legacy driver entry points
    (page_flip, set_config, plane vfuncs) on top of the new atomic driver
    interface. These are completely driver agnostic. The reason for having
    the legacy support as helpers is that drivers can switch step-by-step.
    And they could e.g. even keep the legacy page_flip code around for some
    old platforms where converting to full-blown atomic isn't worth it.

  * Atomic helpers which implement the various new ->atomic_* driver
    interfaces in terms of the revised crtc helper and new plane helper
    hooks.

- The revised crtc helper implemenation essentially implements all the
  lessons learned in the i915 modeset rework (when using the atomic helpers
  only):

  * Enable/disable sequence for a given config are always the same and
    callbacks are always called in the same order. This contrast starkly
    with the crtc helpers, where the sequence of operations is heavily
    dependent on the previous config.

    One corollary of this is that if the configuration of a crtc only
    partially changes (e.g. a connector moves in a cloned config) the
    helper code will still disable/enable the full display pipeline. This
    is the only way to ensure that the enable/disable sequence is always
    the same.

  * It won't call disable or enable hooks more than once any more because
    it lost track of state, thanks to the atomic state tracking. And if
    drivers implement the ->reset hook properly (by either resetting the hw
    or reading out the hw state into the atomic structures) this even
    extends to the hardware state. So no more disable-me-harder kind of
    nonsense.

  * The only thing missing is the hw state readout/cross-check support, but
    if drivers have hw state readout support in their ->reset handlers it's
    simple to extend that to cross-check the hw state.

  * The crtc->mode_set callback is gone and its replacement only sets crtc
    timings and no longer updates the primary plane state. This way we can
    finally implement primary planes properly.

- The new plane helpers should be suitable enough for pretty much
  everything, and a perfect fit for hardware with GO bits. Even if they
  don't fit the atomic helper library is rather flexible and exports all
  the functions for the individual steps to drivers. So drivers can pick
  what matches and implement their own magic for everything else.

- A big difference compared to all previous atomic series is that this one
  doesn't implement async commit in a generic way. Imo driver requirements
  for that are too diverse to create anything reasonable sane which would
  actually work on a reasonable amount of different drivers. Also, we've
  never had a helper library for page_flips even, so it's really hard to
  know what might work and what's stupid without a bit of experience in the form
  of a few driver implementations.

  I think with the current flexibility for drivers to pick individual
  stages and existing helpers like drm_flip_queue it's rather easy though
  to implement proper async commit.

- There's a few other differences of minor importance to earlier atomic
  series:

  * Common/generic properties are parsed in the callers/core and not in
    drivers, and passed to drivers by directly setting the right members in
    atomic state structures. That greatly simplifies all the transitional
    and legacy helpers an removes a lot of boilerplate code.

  * There's no crazy trylock mode used for the async commit since these
    helpers don't do async commit. A simple ordered flip queue of atomic
    state updates should be sufficient for preventing concurrent hw access
    anyway, as long as synchronous updates stall correctly with e.g.
    flush_work_queue or similar function. Abusing locks to enforce ordering
    isn't a good idea imo anyway.

  * These helpers reuse the existing ->mode_fixup hooks in the atomic_check
    callback. Which means that drivers need to adapat and move a lot less code
    into their atomic_check callbacks.

Now this isn't everything needed in the drm core and helpers for full
atomic support. But it's enough to start with converting drivers, and
except for actually testing multiplane and multicrtc updates also enough to
implement full atomic updates. Still missing are:

- Per-plane locking. Since these helpers here encapsulate the locking
  completely this should be fairly easy to implement.

- fbdev support for atomic_check/commit, so that multi-pipe finally works
  sanely in fbcon.

- Adding and decoding shared/core properties. That just needs to be rebased
  from Rob's latest patch series, with minor adjustments so that the
  decoding happens in the core instead of in drivers.

- Actually adding the atomic ioctl. Again just rebasing Rob's latest patch
  should be all that's needed.

- Resolving how to deal with DPMS in atomic. Atomic is a good excuse to fix up
  the crazy semantics dpms currently has. I'm floating an RFC about this topic
  already.

- Finally I couldn't test connector/encoder stealing properly since my test
  vehicle here doesn't allow a connector on different crtcs. So drivers
  which support this might see some surprises in that area. There is no semantic
  change though in how encoder stealing and assignment works (or at least no
  intended one), so I think the risk is minimal.

As just mentioned I've done a fake conversion of an existing driver using
crtc helpers to debug the helper code and validate the smooth transition
approach. And that smooth transition was the really big motivation for
this. It seems to actually work and consists of 3 phases:

Phase 1: Rework driver backend for crtc/plane helpers

The requirement here is that universal plane support is already implement. If
universal plane support isn't implement yet it might be better though to just do
it as part of this phase, directly using the new plane helpers. There are two
big things to do:

- Split up the existing ->update/disable_plane hooks into check/commit
  hooks and extract the crtc-wide prep/flush parts (like setting/clearing
  GO bits).

- The other big change is to split the crtc->mode_set hook into the plane
  update (done using the plane helpers) and the crtc setup in a new
  ->mode_set_nofb hook.

When phase 1 is complete the driver implements all the new callbacks which
push the software state into hardware, but still using all the legacy entry
points and crtc helpers. The transitional helpers serve as impendance
mismatch here.

Phase 2: Rework state handling

This consists of rolling out the state handling helpers for planes, crtcs
and connectors and reviewing all ->mode_fixup and similar hooks to make
sure they don't depend upon implicit global state which might change in the
atomic world. Any such code must be moved into ->atomic_check functions which
just rely on the free-standing atomic state update structures.

This phase also adds a few small pieces of fixup code to make sure the
atomic state doesn't get out of sync in the legacy driver callbacks.

Phase 3: Roll out atomic support

Now it's just about replacing vfuncs with the ones provided by the helper
and filling out the small missing pieces (like atomic_check logic or async
commit support needed for page_flips). Due to the prep work in phase 1 no
changes to the driver backend functions should be required, and because of
the prep work in phase 2 atomic implementations can be rolled out
step-by-step. So if async commit ins't implemented yet page_flip can be
implemented with the legacy functions without wreaking havoc in the other
operations.

* tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel:
  drm/atomic: Refcounting for plane_state->fb
  drm: Docbook integration and over sections for all the new helpers
  drm/atomic-helpers: functions for state duplicate/destroy/reset
  drm/atomic-helper: implement ->page_flip
  drm/atomic-helpers: document how to implement async commit
  drm/atomic: Integrate fence support
  drm/atomic-helper: implementatations for legacy interfaces
  drm: Atomic crtc/connector updates using crtc/plane helper interfaces
  drm/crtc-helper: Transitional functions using atomic plane helpers
  drm/plane-helper: transitional atomic plane helpers
  drm: Add atomic/plane helpers
  drm: Global atomic state handling
  drm: Add atomic driver interface definitions for objects
  drm/modeset_lock: document trylock_only in kerneldoc
  drm: fixup kerneldoc in drm_crtc.h
  drm: Pull drm_crtc.h into the kerneldoc template
  drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h

Linux 3.18-rc4

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fixes from Catalin Marinas:
 - enable bpf syscall for compat
 - cpu_suspend fix when checking the idle state type
 - defconfig update

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: defconfig: update defconfig for 3.18
  arm64: compat: Enable bpf syscall
  arm64: psci: fix cpu_suspend to check idle state type for index

Merge tag 'armsoc-for-rc4' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "Another quiet week:

   - a fix to silence edma probe error on non-supported platforms from
     Arnd
   - a fix to enable the PL clock for Parallella, to make mainline
     usable with the SDK.
   - a somewhat verbose fix for the PLL clock tree on VF610
   - enabling of SD/MMC on one of the VF610-based boards (for testing)
   - a fix for i.MX where CONFIG_SPI used to be implicitly enabled and
     now needs to be added to the defconfig instead
   - another maintainer added for bcm2835: Lee Jones"

* tag 'armsoc-for-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: dts: zynq: Enable PL clocks for Parallella
  dma: edma: move device registration to platform code
  ARM: dts: vf610: add SD node to cosmic dts
  MAINTAINERS: update bcm2835 entry
  ARM: imx: Fix the removal of CONFIG_SPI option
  ARM: imx: clk-vf610: define PLL's clock tree

Merge branch 'devicetree/merge' of git://git./linux/kernel/git/glikely/linux

Pull devicetree bugfix from Grant Likely:
 "One buffer overflow bug that shouldn't be left around"

* 'devicetree/merge' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux:
  of: Fix overflow bug in string property parsing functions

Merge branch 'for-linus' of git://git./linux/kernel/git/mason/linux-btrfs

Pull btrfs fix from Chris Mason:
 "It's a one liner for an error cleanup path that leads to crashes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: fix kfree on list_head in btrfs_lookup_csums_range error cleanup

Merge tag 'driver-core-3.18-rc4' of git://git./linux/kernel/git/gregkh/driver-core

Pull driver core fixes from Greg KH:
 "Here are 3 tiny fixes for 3.18-rc4.

  One fixes up a long-stading race condition in the driver core for
  removing directories in /sys/devices/virtual/ and the other 2 fix up
  the wording of a new Kconfig option that was added in 3.18-rc1"

* tag 'driver-core-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  tiny: rename ENABLE_DEV_COREDUMP to ALLOW_DEV_COREDUMP
  tiny: reverse logic for DISABLE_DEV_COREDUMP
  sysfs: driver core: Fix glue dir race condition by gdp_mutex

Merge tag 'staging-3.18-rc4' of git://git./linux/kernel/git/gregkh/staging

Pull staging driver fixes from Greg KH:
 "Here are some staging/iio fixes for 3.18-rc4.

  Nothing major, just a few bugfixes of things that have been reported"

* tag 'staging-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging:iio:ade7758: Remove "raw" from channel name
  staging:iio:ade7758: Fix check if channels are enabled in prenable
  staging:iio:ade7758: Fix NULL pointer deref when enabling buffer
  iio: as3935: allocate correct iio_device size
  io: accel: kxcjk-1013: Fix iio_event_spec direction
  iio: tsl4531: Fix compiler error when CONFIG_PM_OPS is not defined
  iio: adc: mxs-lradc: Disable the clock on probe failure
  iio: st_sensors: Fix buffer copy
  staging:iio:ad5933: Drop "raw" from channel names
  staging:iio:ad5933: Fix NULL pointer deref when enabling buffer

Merge tag 'tty-3.18-rc4' of git://git./linux/kernel/git/gregkh/tty

Pull tty/serial fixes from Greg KH:
 "Here are some tiny serial/tty fixes for 3.18-rc4 that resolve some
  reported issues"

* tag 'tty-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  tty: Fix pty master poll() after slave closes v2
  serial: of-serial: fix uninitialized kmalloc variable
  tty/vt: don't set font mappings on vc not supporting this
  tty: serial: 8250_mtk: Fix quot calculation
  tty: Prevent "read/write wait queue active!" log flooding
  tty: Fix high cpu load if tty is unreleaseable
  serial: Fix divide-by-zero fault in uart_get_divisor()

Merge tag 'usb-3.18-rc4' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here are some USB fixes for 3.18-rc4.

  Just a bunch of little fixes resolving reported issues and new device
  ids for existing drivers.  Full details are in the shortlog"

* tag 'usb-3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (26 commits)
  USB: Update default usb-storage delay_use value in kernel-parameters.txt
  USB: cdc-acm: add quirk for control-line state requests
  phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
  USB: storage: Fix timeout in usb_stor_euscsi_init() and usb_stor_huawei_e220_init()
  USB: cdc-acm: only raise DTR on transitions from B0
  Revert "storage: Replace magic number with define in usb_stor_euscsi_init()"
  usb: core: notify disconnection when core detects disconnect
  usb: core: need to call usb_phy_notify_connect after device setup
  uas: Add US_FL_NO_ATA_1X quirk for 2 more Seagate models
  xhci: no switching back on non-ULT Haswell
  USB: quirks: enable device-qualifier quirk for yet another Elan touchscreen
  USB: quirks: enable device-qualifier quirk for another Elan touchscreen
  MAINTAINERS: Remove duplicate entry for usbip driver
  usb: storage: fix build warnings !CONFIG_PM
  usb: Remove references to non-existent PLAT_S5P symbol
  uas: Add NO_ATA_1X for VIA VL711 devices
  xhci: Disable streams on Asmedia 1042 xhci controllers
  USB: HWA: fix a warning message
  uas: Add US_FL_NO_ATA_1X quirk for 1 more Seagate model
  usb-storage: handle a skipped data phase
  ...

ARM: dts: zynq: Enable PL clocks for Parallella

The Parallella board comes with a U-Boot bootloader that loads one of
two predefined FPGA bitstreams before booting the kernel. Both define an
AXI interface to the on-board Epiphany processor.

Enable clocks FCLK0..FCLK3 for the Programmable Logic by default.

Otherwise accessing, e.g., the ESYSRESET register freezes the board,
as seen with the Epiphany SDK tools e-reset and e-hw-rev, using /dev/mem.

Cc: <stable@vger.kernel.org> # 3.17.x
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge branch 'i2c/for-current' of git://git./linux/kernel/git/wsa/linux

Pull i2c bugfixes from Wolfram Sang:
 "One bigger cleanup (FSF address removal) and two bugfixes for I2C"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: core: Dispose OF IRQ mapping at client removal time
  i2c: at91: don't account as iowait
  i2c: remove FSF address

Merge branch 'irq-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 "Two fixlets for the armada SoC interrupt controller"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip: armada-370-xp: Fix MPIC interrupt handling
  irqchip: armada-370-xp: Fix MSI interrupt handling

Merge git://git./linux/kernel/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:
 "For:
   - some regression fixes at the Remote Controller core and imon driver
   - a build fix for certain randconfigs with ir-hix5hd2
   - don't feed power to satellite system at ds3000 driver init

  It also contains some fixes for drivers added for Kernel 3.18:
   - some fixes at the new ISDB-S driver, and the corresponding bits to
     fix some descriptors for this Japanese TV standard at the DVB core
   - two warning cleanups for sp2 driver if PM is disabled
   - change the default mode for the new vivid driver"

* git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] sp2: sp2_init() can be static
  [media] dvb:tc90522: fix always-false expression
  [media] dvb-core: set default properties of ISDB-S
  [media] dvb:tc90522: fix stats report
  [media] vivid: default to single planar device instances
  [media] imon: fix other RC type protocol support
  [media] ir-hix5hd2 fix build warning
  [media] ds3000: fix LNB supply voltage on Tevii S480 on initialization
  [media] rc5-decoder: BZ#85721: Fix RC5-SZ decoding
  [media] rc-core: fix protocol_change regression in ir_raw_event_register

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS updates from Ralf Baechle:
 "This weeks' round of MIPS bug fixes for 3.18:

   - wire up the bpf syscall
   - fix TLB dump output for R3000 class TLBs
   - fix strnlen_user return value if no NUL character was found.
   - fix build with binutils 2.24.51+.  While there is no binutils 2.25
     release yet, toolchains derived from binutils 2.24.51+ are already
     in common use.
   - the Octeon GPIO code forgot to offline GPIO IRQs.
   - fix build error for XLP.
   - fix possible BUG assertion with EVA for CMA"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Fix build with binutils 2.24.51+
  MIPS: R3000: Fix debug output for Virtual page number
  MIPS: Fix strnlen_user() return value in case of overlong strings.
  MIPS: CMA: Do not reserve memory if not required
  MIPS: Wire up bpf syscall.
  MIPS/Xlp: Remove the dead function destroy_irq() to fix build error
  MIPS: Octeon: Make Octeon GPIO IRQ chip CPU hotplug-aware

Merge tag 'xfs-for-linus-3.18-rc3' of git://git./linux/kernel/git/dgc/linux-xfs

Pull xfs fixes from Dave Chinner:
 "This update fixes a warning in the new pagecache_isize_extended() and
  updates some related comments, another fix for zero-range
  misbehaviour, and an unforntuately large set of fixes for regressions
  in the bulkstat code.

  The bulkstat fixes are large but necessary.  I wouldn't normally push
  such a rework for a -rcX update, but right now xfsdump can silently
  create incomplete dumps on 3.17 and it's possible that even xfsrestore
  won't notice that the dumps were incomplete.  Hence we need to get
  this update into 3.17-stable kernels ASAP.

  In more detail, the refactoring work I committed in 3.17 has exposed a
  major hole in our QA coverage.  With both xfsdump (the major user of
  bulkstat) and xfsrestore silently ignoring missing files in the
  dump/restore process, incomplete dumps were going unnoticed if they
  were being triggered.  Many of the dump/restore filesets were so small
  that they didn't evenhave a chance of triggering the loop iteration
  bugs we introduced in 3.17, so we didn't exercise the code
  sufficiently, either.

  We have already taken steps to improve QA coverage in xfstests to
  avoid this happening again, and I've done a lot of manual verification
  of dump/restore on very large data sets (tens of millions of inodes)
  of the past week to verify this patch set results in bulkstat behaving
  the same way as it does on 3.16.

  Unfortunately, the fixes are not exactly simple - in tracking down the
  problem historic API warts were discovered (e.g xfsdump has been
  working around a 20 year old bug in the bulkstat API for the past 10
  years) and so that complicated the process of diagnosing and fixing
  the problems.  i.e. we had to fix bugs in the code as well as
  discover and re-introduce the userspace visible API bugs that we
  unwittingly "fixed" in 3.17 that xfsdump relied on to work correctly.

  Summary:

   - incorrect warnings about i_mutex locking in pagecache_isize_extended()
     and updates comments to match expected locking
   - another zero-range bug fix for stray file size updates
   - a bunch of fixes for regression in the bulkstat code introduced in
     3.17"

* tag 'xfs-for-linus-3.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
  xfs: track bulkstat progress by agino
  xfs: bulkstat error handling is broken
  xfs: bulkstat main loop logic is a mess
  xfs: bulkstat chunk-formatter has issues
  xfs: bulkstat chunk formatting cursor is broken
  xfs: bulkstat btree walk doesn't terminate
  mm: Fix comment before truncate_setsize()
  xfs: rework zero range to prevent invalid i_size updates
  mm: Remove false WARN_ON from pagecache_isize_extended()
  xfs: Check error during inode btree iteration in xfs_bulkstat()
  xfs: bulkstat doesn't release AGI buffer on error

Merge tag 'regulator-v3.18-rc3' of git://git./linux/kernel/git/broonie/regulator

Pull regulator fixes from Mark Brown:
 "More changes than I'd like here, most of them for a single bug
  repeated in a bunch of drivers with data not being initialized
  correctly, plus a fix to lower the severity of a warning introduced in
  the last merge window which can legitimately go off so we don't want
  to alarm users excessively"

* tag 'regulator-v3.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: s2mpa01: zero-initialize regulator match table array
  regulator: max8660: zero-initialize regulator match table array
  regulator: max77802: zero-initialize regulator match table
  regulator: max77686: zero-initialize regulator match table
  regulator: max1586: zero-initialize regulator match table array
  regulator: max77693: Fix use of uninitialized regulator config
  regulator: of: Lower the severity of the error with no container

Merge tag 'spi-v3.18-rc3' of git://git./linux/kernel/git/broonie/spi

Pull spi bugfixes from Mark Brown:
 "A couple of small driver fixes for v3.18, both quite problematic if
  you hit a use case that's affected"

* tag 'spi-v3.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: pxa2xx: toggle clocks on suspend if not disabled by runtime PM
  spi: fsl-dspi: Fix CTAR selection

tiny: rename ENABLE_DEV_COREDUMP to ALLOW_DEV_COREDUMP

The ENABLE_DEV_COREDUMP option is misleading as it implies that
it gets the framework enabled, this isn't true it just allows it
to get enabled if a driver needs it.

Rename it to ALLOW_DEV_COREDUMP to better capture its semantics.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Aristeu Rozanski <aris@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tiny: reverse logic for DISABLE_DEV_COREDUMP

It's desirable for allnconfig and tinyconfig targets to result in the
least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to
switch off DEV_COREDUMP regardless if any drivers select
WANT_DEV_COREDUMP.

This patch renames the option to ENABLE_DEV_COREDUMP and setting it to
'n' (as in allnconfig or tinyconfig) will effectively disable device
coredump.

Cc: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Aristeu Rozanski <arozansk@redhat.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i2c: core: Dispose OF IRQ mapping at client removal time

Clients instantiated from OF get an IRQ mapping created at device
registration time. Dispose the mapping when the client is removed.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2c: at91: don't account as iowait

iowait is for blkio [1]. I2C shouldn't use it.

[1] https://lkml.org/lkml/2014/11/3/317

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Cc: stable@kernel.org

i2c: remove FSF address

We have a central copy of the GPL for that. Some addresses were already
outdated.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

USB: Update default usb-storage delay_use value in kernel-parameters.txt

Back in 2010 the default usb-storage delay_use time was reduced from 5 to 1
second (commit a4a47bc03fe520e95e0c4212bf97c86545fb14f9), but
kernel-parameters.txt wasn't updated to reflect that.

Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sysfs: driver core: Fix glue dir race condition by gdp_mutex

There is a race condition when removing glue directory.
It can be reproduced in following test:

path 1: Add first child device
device_add()
    get_device_parent()
            /*find parent from glue_dirs.list*/
            list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
                    if (k->parent == parent_kobj) {
                            kobj = kobject_get(k);
                            break;
                    }
            ....
            class_dir_create_and_add()

path2: Remove last child device under glue dir
device_del()
    cleanup_device_parent()
            cleanup_glue_dir()
                    kobject_put(glue_dir);

If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.

This is a "classic" problem we have of a kref in a list
that can be found while the last instance could be removed
at the same time.

This patch reuse gdp_mutex to fix this race condition.

The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.

-----------------------------------------------------
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611]  [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615]  [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618]  [<ffffffff81215963>] kobject_get+0x33/0x40
<4>[ 3965.441624]  [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627]  [<ffffffff812d22d4>] device_add+0xd4/0x6d0
<4>[ 3965.441631]  [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
....
<2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
...
<4>[ 3965.686743]  [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
<4>[ 3965.686748]  [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753]  [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
<4>[ 3965.686756]  [<ffffffff812030bc>] add_disk+0x1cc/0x490
....
-------------------------------------------------------

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
Cc: <stable@vger.kernel.org> #3.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

MIPS: Fix build with binutils 2.24.51+

Starting with version 2.24.51.20140728 MIPS binutils complain loudly
about mixing soft-float and hard-float object files, leading to this
build failure since GCC is invoked with "-msoft-float" on MIPS:

{standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
  LD      arch/mips/alchemy/common/built-in.o
mipsel-softfloat-linux-gnu-ld: Warning: arch/mips/alchemy/common/built-in.o
 uses -msoft-float (set by arch/mips/alchemy/common/prom.o),
 arch/mips/alchemy/common/sleeper.o uses -mhard-float

To fix this, we detect if GAS is new enough to support "-msoft-float" command
option, and if it does, we can let GCC pass it to GAS;  but then we also need
to sprinkle the files which make use of floating point registers with the
necessary ".set hardfloat" directives.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/8355/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Merge tag 'topic/core-stuff-2014-11-05' of git://anongit.freedesktop.org/drm-intel into drm-next

Just various stuff all over from a bunch of people. Shortlog gives a beter
overview, it's really all misc drm patches.

* tag 'topic/core-stuff-2014-11-05' of git://anongit.freedesktop.org/drm-intel:
  drm/edid: add #defines and helpers for ELD
  drm/dp: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs
  drm: Remove compiler BUG_ON() test
  drm: Fix DRM_FORCE_ON_DIGITAL use
  drm/gma500: Don't destroy DRM properties in the driver
  drm/i915: Don't destroy DRM properties in the driver
  drm: Add a note to drm_property_create() about property lifetime
  gpu: drm: Fix warning caused by a parameter description in drm_crtc.c
  drm/dp-helper: Move the legacy helpers to gma500
  drm/crtc: Remove duplicated ioctl code
  drm/crtc: Fix two typos
  gpu:drm: Fix typo in Documentation/DocBook/drm.xml
  gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat
  drm: drm_err: Remove unnecessary __func__ argument
  drm: Implement O_NONBLOCK support on /dev/dri/cardN

drm: drop README.drm, ancient scrolls

This stuff is ancient, we have docs now in the kernel,
lets just drop it.

Pointed out by Glenn

Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

xfs: track bulkstat progress by agino

The bulkstat main loop progress is tracked by the "lastino"
variable, which is a full 64 bit inode. However, the loop actually
works on agno/agino pairs, and so there's a significant disconnect
between the rest of the loop and the main cursor. Convert this to
use the agino, and pass the agino into the chunk formatting function
and convert it too.

This gets rid of the inconsistency in the loop processing, and
finally makes it simple for us to skip inodes at any point in the
loop simply by incrementing the agino cursor.

cc: <stable@vger.kernel.org> # 3.17
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: bulkstat error handling is broken

The error propagation is a horror - xfs_bulkstat() returns
a rval variable which is only set if there are formatter errors. Any
sort of btree walk error or corruption will cause the bulkstat walk
to terminate but will not pass an error back to userspace. Worse
is the fact that formatter errors will also be ignored if any inodes
were correctly formatted into the user buffer.

Hence bulkstat can fail badly yet still report success to userspace.
This causes significant issues with xfsdump not dumping everything
in the filesystem yet reporting success. It's not until a restore
fails that there is any indication that the dump was bad and tha
bulkstat failed. This patch now triggers xfsdump to fail with
bulkstat errors rather than silently missing files in the dump.

This now causes bulkstat to fail when the lastino cookie does not
fall inside an existing inode chunk. The pre-3.17 code tolerated
that error by allowing the code to move to the next inode chunk
as the agino target is guaranteed to fall into the next btree
record.

With the fixes up to this point in the series, xfsdump now passes on
the troublesome filesystem image that exposes all these bugs.

cc: <stable@vger.kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>

xfs: bulkstat main loop logic is a mess

There are a bunch of variables tha tare more wildy scoped than they
need to be, obfuscated user buffer checks and tortured "next inode"
tracking. This all needs cleaning up to expose the real issues that
need fixing.

cc: <stable@vger.kernel.org> # 3.17
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: bulkstat chunk-formatter has issues

The loop construct has issues:
- clustidx is completely unused, so remove it.
- the loop tries to be smart by terminating when the
  "freecount" tells it that all inodes are free. Just drop
  it as in most cases we have to scan all inodes in the
  chunk anyway.
- move the "user buffer left" condition check to the only
  point where we consume space int eh user buffer.
- move the initialisation of agino out of the loop, leaving
  just a simple loop control logic using the clusteridx.

Also, double handling of the user buffer variables leads to problems
tracking the current state - use the cursor variables directly
rather than keeping local copies and then having to update the
cursor before returning.

cc: <stable@vger.kernel.org> # 3.17
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: bulkstat chunk formatting cursor is broken

The xfs_bulkstat_agichunk formatting cursor takes buffer values from
the main loop and passes them via the structure to the chunk
formatter, and the writes the changed values back into the main loop
local variables. Unfortunately, this complex dance is full of corner
cases that aren't handled correctly.

The biggest problem is that it is double handling the information in
both the main loop and the chunk formatting function, leading to
inconsistent updates and endless loops where progress is not made.

To fix this, push the struct xfs_bulkstat_agichunk outwards to be
the primary holder of user buffer information. this removes the
double handling in the main loop.

Also, pass the last inode processed by the chunk formatter as a
separate parameter as it purely an output variable and is not
related to the user buffer consumption cursor.

Finally, the chunk formatting code is not shared by anyone, so make
it local to xfs_itable.c.

cc: <stable@vger.kernel.org> # 3.17
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: bulkstat btree walk doesn't terminate

The bulkstat code has several different ways of detecting the end of
an AG when doing a walk. They are not consistently detected, and the
code that checks for the end of AG conditions is not consistently
coded. Hence the are conditions where the walk code can get stuck in
an endless loop making no progress and not triggering any
termination conditions.

Convert all the "tmp/i" status return codes from btree operations
to a common name (stat) and apply end-of-ag detection to these
operations consistently.

cc: <stable@vger.kernel.org> # 3.17
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

mm: Fix comment before truncate_setsize()

XFS doesn't always hold i_mutex when calling truncate_setsize() and it
uses a different lock to serialize truncates and writes. So fix the
comment before truncate_setsize().

Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

USB: cdc-acm: add quirk for control-line state requests

Add new quirk for devices that cannot handle control-line state
requests.

Note that we currently send these requests to all devices, regardless of
whether they claim to support it, but that errors are only logged if
support is claimed.

Since commit 0943d8ead30e ("USB: cdc-acm: use tty-port dtr_rts"), which
only changed the timings for these requests slightly, this has been
reported to cause occasional firmware crashes on Simtec Electronics
Entropy Key devices after re-enumeration. Enable the quirk for this
device.

Reported-by: Nix <nix@esperi.org.uk>
Tested-by: Nix <nix@esperi.org.uk>
Cc: stable <stable@vger.kernel.org> # v3.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'fixes-for-v3.18-rc4' of git://git./linux/kernel/git/balbi/usb into usb-linus

Felipe writes:

usb: fixes for v3.18-rc4

A single fix this for dwc2 this time. Because of
excessive debugging messages, dwc2 would sometimes
fail enumeration. The fix is simple, just converting
a dev_info() into dev_dbg().

Signed-off-by: Felipe Balbi <balbi@ti.com>

tty: Fix pty master poll() after slave closes v2

Commit f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
introduces a race window where a pty master can be signalled that the pty
slave was closed before all the data that the slave wrote is delivered.
Commit f8747d4a466a ("tty: Fix pty master read() after slave closes") fixed the
problem in case of n_tty_read, but the problem still exists for n_tty_poll.
This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
where test.py is:

import os, select, pty

(pid, pty_fd) = pty.fork()

if pid == 0:
   os.write(1, 'This string should be received by parent')
else:
   poller = select.epoll()
   poller.register( pty_fd, select.EPOLLIN )
   ready = poller.poll( 1 * 1000 )
   for fd, events in ready:
      if not events & select.EPOLLIN:
         print 'missed POLLIN event'
      else:
         print os.read(fd, 100)
   poller.close()

The string from the slave is missed several times.
This patch takes the same approach as the fix for read and special cases
this condition for poll.
Tested on 3.16.

Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'usb-serial-3.18-rc4' of git://git./linux/kernel/git/johan/usb-serial into usb-linus

Johan writes:

USB-serial fixes for v3.18-rc4

Two fixes of non-atomic allocations in write paths.

Signed-off-by: Johan Hovold <johan@kernel.org>

drm/atomic: Refcounting for plane_state->fb

So my original plan was that the drm core refcounts framebuffers like
with the legacy ioctls. But that doesn't work for a bunch of reasons:

- State objects might live longer than until the next fb change
  happens for a plane. For example delayed cleanup work only happens
  _after_ the pageflip ioctl has completed. So this definitely doesn't
  work without the plane state holding its own references.

- The other issue is transition from legacy to atomic implementations,
  where the driver works under a mix of both worlds. Which means
  legacy paths might not properly update the ->fb pointer under
  plane->state->fb. Which is a bit a problem when then someone comes
  around and _does_ try to clean it up when it's long gone.

The second issue is just a bit a transition bug, since drivers should
update plane->state->fb in all the paths that aren't converted yet.
But a bit more robustness for the transition can't hurt - we pull
similar tricks with cleaning up the old fb in the transitional helpers
already.

The pattern for drivers that transition is

if (plane->state)
drm_atomic_set_fb_for_plane(plane->state, plane->fb);

inserted after the fb update has logically completed at the end of
->set_config (or ->set_base/mode_set if using the crtc helpers),
->page_flip, ->update_plane or any other entry point which updates
plane->fb.

v2: Update kerneldoc - copypasta fail.

v3: Fix spelling in the commit message (Sean).

Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Docbook integration and over sections for all the new helpers

In all cases the text requires that new drivers are converted to the
atomic interfaces.

v2: Add overview for state handling.

v3: Review from Sean: Some spelling fixes and drop the misguided
hunk to remove rgba8888 from the plane helpers compat list.

Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic-helpers: functions for state duplicate/destroy/reset

The atomic users and helpers assume that there is always a obj->state
structure around. Which means drivers need to somehow create that at
driver load time. Also it should obviously reset hardware state, so
needs to be reset upon resume.

Finally the destroy/duplicate_state functions are an awful lot of
boilerplate if the driver doesn't need anything beyond the default
state objects.

So add helper functions for all of this.

v2: Somehow the plane/connector versions got lost in the first
version.

v3: Add kerneldoc.

v4: Make duplicate_state functions a bit more robust, which is useful
for debugging state tracking issues when transitioning to atomic.

v5: Clear temporary variables in the crtc state when duplicating it,
like ->mode_changed or ->planes_changed. If we don't do this stale
values for these might pollute the next atomic modeset.

v6: Also clear crtc_state->event in case the driver didn't (yet) clear
this out.

v7: Split out wrong squashed commit. Also improve the kerneldoc to
mention that obj->state can be NULL and when.  Both suggested by
Daniel Thompson.

Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic-helper: implement ->page_flip

Currently there is no way to implement async flips using atomic, that
essentially requires us to be able to cancel pending requests
mid-flight.

To be able to do that (and I guess we want this since vblank synced
updates which opportunistically cancel still pending updates seem to be
wanted) we'd need to add a mandatory cancellation mode. Depending upon
the exact semantics we decide upon that could mean that userspace will
not get completion events, or will get them all stacked up.

So reject async updates for now. Also async updates usually means not
vblank synced at all, and I guess for drivers which want to support
this they should simply add a special pageflip handler (since usually
you need a special flip cmd to achieve this). That kind of async flip
is pretty much exclusively just used for games and benchmarks where
dropping just one frame means you'll get a headshot or something bad
like that ... And so slight amounts of tearing is acceptable.

v2: Fixup kerneldoc, reported by Paulo.

v3: Use the set_crtc_for_plane function to assign the crtc, since
otherwise the book-keeping is off.

v4: Update crtc->primary->fb since ->page_flip is the only driver
callback where the core won't do this itself. We might want to fix
this inconsistency eventually.

v5: Use set_crtc_for_connector as suggested by Sean.

v6: Daniel Thompson noticed that my error handling is inconsistent
and that in a few cases I didn't handle fatal errors (i.e. not
-EDEADLK). Fix this by consolidate the ww mutex backoff handling
into one check in the fail: block and flatten the error control
flow everywhere else.

v7: Fix spelling mistake in the commit message (Sean).

Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic-helpers: document how to implement async commit

No helper function to do it all yet provided since no driver has
support for driver core fences yet. Which we'd need to make the
implementation really generic.

v2: Clarify async howto a bit per the discussion With Rob Clark.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atomic: Integrate fence support

This patch is for enabling async commits. It replaces an earlier
approach which added an async boolean paramter to the ->prepare_fb
callbacks. The idea is that prepare_fb picks up the right fence to
synchronize against, which is then used by the synchronous commit
helper. For async commits drivers can either register a callback to
the fence or simply do the synchronous wait in their async work queue.

v2: Remove unused variable.

v3: Only wait for fences after the point of no return in the part
of the commit function which can be run asynchronously. This is after
the atomic state has been swapped in, hence now check
plane->state->fence.

Also add a WARN_ON to make sure we don't try to wait on a fence when
there's no fb, just as a sanity check.

Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/atomic-helper: implementatations for legacy interfaces

Well, except page_flip since that requires async commit, which isn't
there yet.

For the functions which changes planes there's a bit of trickery
involved to keep the fb refcounting working. But otherwise fairly
straight-forward atomic updates.

The property setting functions are still a bit incomplete. Once we
have generic properties (e.g. rotation, but also all the properties
needed by the atomic ioctl) we need to filter those out and parse them
in the helper. Preferrably with the same function as used by the real
atomic ioctl implementation.

v2: Fixup kerneldoc, reported by Paulo.

v3: Add missing EXPORT_SYMBOL.

v4: We need to look at the crtc of the modeset, not some random
leftover one from a previous loop when udpating the connector->crtc
routing. Also push some local variables into inner loops to avoid
these kinds of bugs.

v5: Adjust semantics - drivers now own the atomic state upon
successfully synchronous commit.

v6: Use the set_crtc_for_plane function to assign the crtc, since
otherwise the book-keeping is off.

v7:
- Improve comments.
- Filter out the crtc of the ->set_config call when recomputing
  crtc_state->enabled: We should compute the same state, but not doing
  so will give us a good chance to catch bugs and inconsistencies -
  the atomic helper's atomic_check function re-validates this again.
- Fix the set_config implementation logic when disabling the crtc: We
  still need to update the output routing to disable all the
  connectors properly in the state. Caught by the atomic_check
  functions, so at least that part worked ;-) Also add some WARN_ONs
  to ensure ->set_config preconditions all apply.

v8: Fixup an embarrassing h/vdisplay mixup.

v9: Shuffled bad squash to the right patch, spotted by Daniel

v10: Use set_crtc_for_connector as suggested by Sean.

v11: Daniel Thompson noticed that my error handling is inconsistent
and that in a few cases I didn't handle fatal errors (i.e. not
-EDEADLK). Fix this by consolidate the ww mutex backoff handling
into one check in the fail: block and flatten the error control
flow everywhere else.

v12: Review and discussion with Sean:
- One spelling fix.
- Correctly skip the crtc from the set_config set when recomputing
  ->enable state. That should allow us to catch any bugs in higher
  levels in computing that state (which is supplied to the
  ->set_config implementation). I've screwed this up and Sean spotted
  that the current code is pointless.

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>