intel_update_cdclk() will already display the boot CDCLK for DDI
platforms, no need to repeat there.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We can operate with DPLL0 off with CDCLK backed by the 24Mhz reference
clock, and that's a supported configuration. Don't warn when notice
DPLL0 is off then.

We still have a separate warn at boot if cdclk is disabled (because we
don't currently try to handle the case (that shouldn't happen on SKL as
far as I know) where we boot with display not initialized.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Add support for changing cdclk frequency during runtime on BDW.

Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when computing the max pixel rate.

v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
v4: Rebased to the latest
v5: Rebased to the latest
v6: Patch order shuffle so that Broadwell CD clock change is
    applied before the patch for Haswell CD clock change
v7: Fix for patch style problems
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We need to tell BDW ULT and ULX apart.

v2: Rebased to the latest
v3: Rebased to the latest
v4: Fix for patch style problems
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
exceeds 95% of the core display clock. Apparently this can cause
underruns.

There's no similar restriction listed for HSW, so leave that one alone
for now.

v2: Add pipe_config_supports_ips() (Chris)
v3: Compare against the max cdclk insted of the current cdclk
v4: Rebased to the latest
v5: Rebased to the latest
v6: Fix for patch style problems

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83497Tested-by: NTimo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Keep the cdclk maximum supported frequency around in dev_priv so that we
can verify certain things against it before actually changing the cdclk
frequency.

For now only VLV/CHV have support changing cdclk frequency, so other
plarforms get to assume cdclk is fixed.

v2: Rebased to the latest
v3: Rebased to the latest
v4: Fix for patch style problems
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.

v2: Rebased to the latest
v3: Rebased to the latest
v4: Fix for patch style problems
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Rather that extracting the current cdclk freuqncy every time someone
wants to know it, cache the current value and use that. VLV/CHV already
stored a cached value there so just expand that to cover all platforms.

v2: Rebased to the latest
v3: Rebased to the latest
v4: Rebased to the latest
v5: Removed spurious call to 'intel_update_cdclk(dev)' based on
    Damien Lespiau's comment
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Backmerge drm-next so I can apply Maarten's drm/i915 atomic conversion
patches.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Yay, thanks to Gerd for pull this together.

* 'virtio-gpu-drm-next' of git://git.kraxel.org/linux:
  Add MAINTAINERS entry for virtio-gpu.
  Add virtio gpu driver.
  drm_vblank_get: don't WARN_ON in case vblanks are not initialized
  break kconfig dependency loop

Please pull the contents of "Use DRM component API in tilcdc to
connect to tda998x" patch series.

* 'linux-4.1.0-rc5-tilcdc-refactor' of https://github.com/jsarha/linux:
  drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
  drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support
  drm/tilcdc: use pm_runtime_irq_safe()
  drm/tilcdc: Add support for external tda998x encoder
  drm/tilcdc: Remove tilcdc slave support for tda998x driver
  drm/tilcdc: Fix module unloading

Linux 4.1-rc6

backmerge 4.1-rc6 as some of the later pull reqs are based on newer bases
and I'd prefer to do the fixup myself.

This fixes some regressions in i915 when converting to atomic.
set_config failed with -EINVAL, and I received the following warning
in dmesg:

[drm:drm_atomic_crtc_check] [CRTC:20] active without enabled

Solve this by clearing active when a crtc is disabled.

Because crtc_state->enable implies that connectors are active the
change from disabled->enabled can only happen for the crtc that's
being set_config'd, and checking for !crtc_state->enable is sufficient
here.

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

One more round of drm-misc, again mostly atomic. Big thing is the
userspace blob code from Daniel Stone, with support for the mode_id blob
now added to the atomic ioctl. Finally we can do atomic modesets!

Note that the atomic ioctl is still behind the module knob since the
weston patches aren't quite ready yet imo - they lack TEST_ONLY support,
which is a fairly crucial bit of the atomic api. But besides that I think
it's all good to go. That's also why we didn't bother to hide the new blob
ioctls behind the knob, that part won't need to change. And if weston
patches get in shape in time we could throw the "atomic by default patch"
on top for 4.2.

* tag 'topic/drm-misc-2015-05-27' of git://anongit.freedesktop.org/drm-intel:
  drm: Fix off-by-one in vblank hardware counter wraparound handling
  drm/atomic: fix out of bounds read in for_each_*_in_state helpers
  drm/atomic: Add MODE_ID property
  drm/atomic: Add current-mode blob to CRTC state
  drm: Add drm_atomic_set_mode_for_crtc
  drm: check for garbage in unused addfb2 fields
  drm: Retain reference to blob properties in lookup
  drm/mode: Add user blob-creation ioctl
  drm: Return error value from blob creation
  drm: Allow creating blob properties without copy
  drm/mode: Unstatic kernel-userspace mode conversion
  drm/mode: Validate modes inside drm_crtc_convert_umode
  drm/crtc_helper: Replace open-coded CRTC state helpers
  drm: kerneldoc fixes for blob properties
  drm/DocBook: Add more drm_bridge documentation
  drm: bridge: Allow daisy chaining of bridges
  drm/atomic: add all affected planes in drm_atomic_helper_check_modeset
  drm/atomic: add drm_atomic_add_affected_planes
  drm/atomic: add commit_planes_on_crtc helper

drm-amdkfd-next-2015-06-03:

- Add the H/W debugger support module, including new IOCTLs to:
  - register/unregister a process as a debugged process
  - Set address watch-point in the debugged process's GPU kernel
  - Do a wave control operation in the debugged process's waves
  See the commit messages for more details on the available operations.

  The debugged process can only perform debug operation on itself. It is
  blocked by the amdkfd+H/W from performing operations on other processes's
  waves or GPU kernels. The blocking is done by setting the VMID and PASID of
  the debugged process in the packets that are sent to the CP with the debug
  instructions.

- Add support for static user-mode queues. These queues are regular queues,
  but because they belong to the debugged process, we need to make sure the CP
  doesn't preempt them during a debug operation. Therefore, we mark them as
  static for the CP ignore them during preemption.

- Support killing all the waves when a process is terminated. This is needed
  in case a process is terminated but we can't UNMAP its queues (can occur due
  to several reasons). In that case, the CP could be stuck unless we kill all
  its waves. This function is *very* important as it provides the kernel a high
  level of control over the GPU. The reason we didn't upstream this function
  so far, is because it is implemented using the H/W debugger module functions,
  so we had to wait until we can upstream the H/W debugger module.

- Replace declaration of bitmap from unsigned long to standard DECLARE_BITMAP

* tag 'drm-amdkfd-next-2015-06-03' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: Enforce kill all waves on process termination
  drm/radeon: Add ATC VMID<-->PASID functions to kfd->kgd
  drm/amdkfd: Implement address watch debugger IOCTL
  drm/amdkfd: Implement wave control debugger IOCTL
  drm/amdkfd: Implement (un)register debugger IOCTLs
  drm/amdkfd: Add address watch operation to debugger
  drm/amdkfd: Add wave control operation to debugger
  drm/amdkfd: Add skeleton H/W debugger module support
  drm/amdkfd: Add static user-mode queues support
  drm/amdkfd: add H/W debugger IOCTL set definitions
  drm/radeon: Add H/W debugger kfd->kgd functions
  drm/amdkfd: Use DECLARE_BITMAP

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This patch adds a kms driver for the virtio gpu.  The xorg modesetting
driver can handle the device just fine, the framebuffer for fbcon is
there too.

Qemu patches for the host side are under review currently.

The pci version of the device comes in two variants: with and without
vga compatibility.  The former has a extra memory bar for the vga
framebuffer, the later is a pure virtio device.  The only concern for
this driver is that in the virtio-vga case we have to kick out the
firmware framebuffer.

Initial revision has only 2d support, 3d (virgl) support requires
some more work on the qemu side and will be added later.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>

MI_MODE is saved in the logical context so WaDisableAsyncFlipPerfMode
must be applied using LRIs on gen8.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

INSTPM is saved in the logical context so we should initialize it using
LRIs on gen8. It actually defaults to 1 starting from HSW, but let's
keep the write around anyway.

Also drop the INSTPM_FORCE_ORDERING setup entirely on gen9+ since it's
now a reserved bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This commit makes sure that on process termination, after
we're destroying all the active queues, we're killing all the
existing wave front of the current process.

By doing this we're making sure that if any of the CUs were blocked
by infinite loop we're enforcing it to end the shader explicitly.
Signed-off-by: NBen Goz <ben.goz@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This patch adds three new interfaces to kfd2kgd interface file of radeon.

The interfaces are:

- Check if a specific VMID has a valid PASID mapping
- Retrieve the PASID which is mapped to a specific VMID
- Issue a VMID invalidation request to the ATC
Signed-off-by: NAlexey Skidanov <Alexey.Skidanov@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

v2:

- rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it
- change void* to uint64_t inside ioctl arguments
- use kmalloc instead of kzalloc because we use copy_from_user
  immediately after it
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

v2:

- rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it
- change void* to uint64_t inside ioctl arguments
- use kmalloc instead of kzalloc because we use copy_from_user
  immediately after it
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

v2: rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

The address watch operation gives the ability to specify watch points
which will generate a shader breakpoint, based on a specified single
address or range of addresses.

There is support for read/write/any access modes.
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

The wave control operation supports several command types executed upon
existing wave fronts that belong to the currently debugged process.

The available commands are:

HALT   - Freeze wave front(s) execution
RESUME - Resume freezed wave front(s) execution
KILL   - Kill existing wave front(s)
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This patch adds the skeleton H/W debugger module support. This code
enables registration and unregistration of a single HSA process at a
time.

The module saves the process's pasid and use it to verify that only the
registered process is allowed to execute debugger operations through the
kernel driver.

v2: rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This patch adds support for static user-mode queues in QCM.
Queues which are designated as static can NOT be preempted by
the CP microcode when it is executing its scheduling algorithm.

This is needed for supporting the debugger feature, because we
can't allow the CP to preempt queues which are currently being debugged.

The number of queues that can be designated as static is limited by the
number of HQDs (Hardware Queue Descriptors).
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This patch adds four new IOCTLs to amdkfd. These IOCTLs expose a H/W
debugger functionality to the userspace.

The IOCTLs are:

- AMDKFD_IOC_DBG_REGISTER:

The purpose of this IOCTL is to notify amdkfd that a process wants to use
GPU debugging facilities on itself only.
It is expected that this IOCTL would be called before any other H/W
debugger requests are sent to amdkfd and for each GPU where the H/W
debugging needs to be enabled. The use of this IOCTL ensures that only
one instance of a debugger is active in the system.

- AMDKFD_IOC_DBG_UNREGISTER:

This IOCTL detaches the debugger/debugged process from the H/W
Debug which was established by the AMDKFD_IOC_DBG_REGISTER IOCTL.

- AMDKFD_IOC_DBG_ADDRESS_WATCH:

This IOCTL allows to set different watchpoints with various conditions as
indicated by the IOCTL's arguments. The available number of watchpoints
is retrieved from topology. This operation is confined to the current
debugged process, which was registered through AMDKFD_IOC_DBG_REGISTER.

- AMDKFD_IOC_DBG_WAVE_CONTROL:

This IOCTL allows to control a wavefront as indicated by the IOCTL's
arguments. For example, you can halt/resume or kill either a
single wavefront or a set of wavefronts. This operation is confined to
the current debugged process, which was registered through
AMDKFD_IOC_DBG_REGISTER.

Because the arguments for the address watch IOCTL and wave control IOCTL
are dynamic, meaning that they could vary in size, the userspace passes a
pointer to a structure (in userspace) that contains the value of the
arguments. The kernel driver is responsible to parse this structure and
validate its contents.

v2: change void* to uint64_t inside ioctl arguments
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This patch adds new interface functions to the kfd2kgd interface file. The
new functions allow to perform H/W debugger operations by writing to GPU
registers.
Signed-off-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Use the generic mechanism to declare a bitmap instead of unsigned long.

It seems that "struct kfd_process.allocated_queue_bitmap" is unused.
Maybe it could be deleted instead.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.

v2: Adding clock in bxt_clk_div struct and then look for the entry with
required rate (Ville)
v3: 'clock' has the selected value, no need to use link_bw or rate_select
for selecting pll(Ville)
v4: Make bxt_dp_clk_val const and remove size (Ville)
v5: Rebased
v6: Removed setting of vco while rebasing in v5, adding it back
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4)
Reviewed-by: NVandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

 commit 65ca7514
 Author: Damien Lespiau <damien.lespiau@intel.com>
 Date:   Mon Feb 9 19:33:22 2015 +0000

    drm/i915/skl: Implement WaBarrierPerformanceFixDisable

got misapplied and the code landed in chv_init_workarounds() instead of
the intended skl_init_workarounds(). Move it over to the right place.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

After adding virtio-gpu I get this funky kconfig dependency loop.

scripts/kconfig/conf --oldconfig Kconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34:     symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU
drivers/gpu/drm/virtio/Kconfig:1:       symbol DRM_VIRTIO_GPU depends on VIRTIO
drivers/virtio/Kconfig:1:       symbol VIRTIO is selected by REMOTEPROC
drivers/remoteproc/Kconfig:4:   symbol REMOTEPROC is selected by OMAP_REMOTEPROC
drivers/remoteproc/Kconfig:12:  symbol OMAP_REMOTEPROC depends on OMAP_IOMMU
drivers/iommu/Kconfig:141:      symbol OMAP_IOMMU is selected by VIDEO_OMAP3
drivers/media/platform/Kconfig:96:      symbol VIDEO_OMAP3 depends on VIDEO_V4L2
drivers/media/v4l2-core/Kconfig:6:      symbol VIDEO_V4L2 depends on I2C
drivers/i2c/Kconfig:7:  symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
drivers/video/fbdev/Kconfig:374:        symbol FB_CYBER2000_DDC depends on FB_CYBER2000
drivers/video/fbdev/Kconfig:362:        symbol FB_CYBER2000 depends on FB

Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the
loop, which looks like the best way to handle it to me.  Updated OMAP_IOMMU
help text accordingly.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Merge tag 'drm-intel-next-fixes-2015-05-29' of git://anongit.freedesktop.org/drm-intel into drm-next

Fixes for 4.2. Nothing too serious (given that it's still pre merge
window). With that it's off for 2 weeks of vacation for me and taking care
of 4.2 fixes for Jani.

* tag 'drm-intel-next-fixes-2015-05-29' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: limit PPGTT size to 2GB in 32-bit platforms
  drm/i915: Another fbdev hack to avoid PSR on fbcon.
  drm/i915: Return the frontbuffer flip to enable intel_crtc_enable_planes.
  drm/i915: disable IPS while getting the sink CRCs
  drm/i915: Disable 12bpc hdmi for now
  drm/i915: Adjust sideband locking a bit for CHV/VLV
  drm/i915: s/dpio_lock/sb_lock/
  drm/i915: Kill intel_flush_primary_plane()
  drm/i915: Throw out WIP CHV power well definitions
  drm/i915: Use the default 600ns LDO programming sequence delay
  drm/i915: Remove unnecessary null check in execlists_context_unqueue
  drm/i915: Use spinlocks for checking when to waitboost
  drm/i915: Fix the confusing comment about the ioctl limits
  Revert "drm/i915: Force clean compilation with -Werror"

dma_alloc_coherent() can return memory in the vmalloc range.
virt_to_page() cannot handle such addresses and crashes. This
patch detects such cases and obtains the struct page * using
vmalloc_to_page() instead.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>