- 15 Jun, 2015 8 commits
-
-
Ville Syrjälä authored
Check that the DIP is enabled on the right port on IBX and VLV/CHV as we're doing on g4x, and also check for all the infoframe enable bits on all platforms. Eventually we should track each infoframe type independently, and also their contents. This is a small step in that direction as .infoframe_enabled() return value could be easily turned into a bitmask. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chandra Konduru <Chandra.konduru@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Currently we just disable the GCP infoframe when turning off the port. That means if the same transcoder is used on a DP port next, we might end up pushing infoframes over DP, which isn't intended. Just disable all the infoframes when turning off the port. Also protect against two ports stomping on each other on g4x due to the single video DIP instance. Now only the first port to enable gets to send infoframes. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
Follow the procedure listed in Bspec to toggle the port enable bit off and on when enabling HDMI with 12bpc and pixel repeat on IBX. The old code didn't actually enable the port before "toggling" the bit back off, so the whole workaround was essentially a nop. Also take the opportunity to clarify the code by splitting the gmch platforms to a separate (much more straightforward) function. v2: Rebased due to crtc->config changes Signed-off-by:
-
Ville Syrjälä authored
IBX BSpec says we must specify 8bpc in TRANSCONF for both 8bpc and 12bpc HDMI output. Do so. v2: Pass intel_crtc to intel_pipe_has_type() Signed-off-by:
-
Ville Syrjälä authored
When the video timings are suitably aligned so that all different periods start at phase 0 (ie. none of the periods start mid-pixel) we can inform the sink about this. Supposedly the sink can then optimize certain things. Obviously this is only relevant when outputting >8bpc data since otherwise there are no mid-pixel phases. v2: Rebased due to crtc->config changes Signed-off-by:
-
Ville Syrjälä authored
GCP infoframes are required to inform the HDMI sink about the color depth. Send the GCP infoframe whenever the sink supports any deep color modes since such sinks must anyway be capable of receiving them. For sinks that don't support deep color let's skip the GCP in case it might confuse the sink, although HDMI 1.4 spec does say all sinks must be capable of reciving them. In theory we could skip the GCP infoframe for deep color sinks in 8bpc mode as well since sinks must fall back to 8bpc whenever GCP isn't received for some time. BSpec says we should disable GCP after disabling the port, so do that as well. v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/ Rebased due to crtc->config changes Signed-off-by:Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement it, and to keep things neat pull the code into a function. v2: Rebased due to crtc->config changes s/HDMI_GC/HDMIUNIT_GC/ to match spec better Factor out intel_enable_hdmi_audio() Signed-off-by: -
Daniel Vetter authored
Pull in patches Jani applied while I was on vacation. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
- 12 Jun, 2015 15 commits
-
-
Imre Deak authored
According to bspec the DDI PHY vswing scale value is "don't care" in case the scale enable bit [27] is clear. But this doesn't seem to be correct. The scale value seems to also matter if the scale mode bit [26] is set. So both bit 26 and 27 depend on the value. Setting the scale value to 0 while either bit is set results in a failed modeset on HDMI (sink reports no signal). After reset the scale value is 0x98, but according to the spec we have to program it to 0x9a. So for consistency program it always to 0x9a regardless of the scale enable bit. Signed-off-by:
Imre Deak <imre.deak@intel.com> Tested-by:
Matt Roper <matthew.d.roper@intel.com> Acked-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Damien Lespiau authored
Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Ville's and Mika's cdclk series was in flight at the same time as the SKL S3 patches so we were missing that update. intel_update_max_cdclk() and intel_update_cdclk() had to be moved up a bit to avoid forward declarations. Signed-off-by:
-
Damien Lespiau authored
intel_update_cdclk() will already display the boot CDCLK for DDI platforms, no need to repeat there. Signed-off-by:
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Ville Syrjälä authored
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:Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
Timo Aaltonen <tjaalton@ubuntu.com> Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
- 04 Jun, 2015 1 commit
-
-
Jani Nikula authored
Backmerge drm-next so I can apply Maarten's drm/i915 atomic conversion patches. Signed-off-by:
-
- 03 Jun, 2015 16 commits
-
-
git://git.kraxel.org/linuxDave Airlie authored
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
-
https://github.com/jsarha/linuxDave Airlie authored
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
-
Dave Airlie authored
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.
-
Maarten Lankhorst authored
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:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
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
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
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
-
Gerd Hoffmann authored
Signed-off-by:Gerd Hoffmann <kraxel@redhat.com>
-
Dave Airlie authored
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:
Michael S. Tsirkin <mst@redhat.com>
-
Ville Syrjälä authored
MI_MODE is saved in the logical context so WaDisableAsyncFlipPerfMode must be applied using LRIs on gen8. Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ben Goz authored
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:
Ben Goz <ben.goz@amd.com> Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com>
-
Alexey Skidanov authored
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:
Alexey Skidanov <Alexey.Skidanov@amd.com> Signed-off-by:
-
Yair Shachar authored
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:
Yair Shachar <yair.shachar@amd.com> Signed-off-by:
-
Yair Shachar authored
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:
-
Yair Shachar authored
v2: rename get_dbgmgr_mutex to kfd_get_dbgmgr_mutex to namespace it Signed-off-by:
-
Yair Shachar authored
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:
-
