- 14 Feb, 2018 8 commits
-
-
Sergei Shtylyov authored
According to the latest revisions of the R-Car Gen3 manual, the LVDS mode must be set before the LVDS I/O pins are enabled, not after -- fix the Gen3 LVDS startup sequence accordingly. Fixes: e947eccb ("drm: rcar-du: Add support for LVDS mode selection") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Updated comment in rcar_du_lvdsenc_start_gen3()] [Moved Gen2 startup comment update to separate commit] [Fixed =| typo] Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Sergei Shtylyov authored
According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS and the bias circuit must be enabled after the LVDS I/O pins are enabled, not before. Fix the Gen2 LVDS startup sequence accordingly. While at it, also fix the comment preceding the first LVDCR0 write that still talks about hardcoding the LVDS mode 0. Fixes: 90374b5c ("drm/rcar-du: Add internal LVDS encoder support") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
According to the latest versions of both the Gen2 and Gen3 datasheets, the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all SoCs. Update the driver accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
-
Sergei Shtylyov authored
The LVDCR1 register for the R-Car gen3 SoCs was documented as having the layout different from the gen2 SoCs in the early R-Car gen3 manuals but since v0.52 the LVDCR1 layout is described as being the same as on the gen2 SoCs; the old CHn control values are said to be prohibited now (and there seems to be no valid output signal when they are used). Fixes: 6bc2e15c ("drm: rcar-du: lvds: Add R-Car Gen3 support") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
On Gen3 hardware the VSP compositor is required for display. Enable it by default in the kernel configuration. The option is kept user-configurable for testing purpose on Gen2 platforms. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
Kuninori Morimoto authored
In general, PLL has VCO (= Voltage controlled oscillator), one of the very important electronic feature called as "jitter" is related to this VCO. In academic generalism, VCO should be maximum to be more small jitter. In high frequency clock, jitter will be large impact. Thus, selecting Hi VCO is general theory. fin fvco fout fclkout in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out +-> | | | | | +-----------------[1/N]<-------------+ fclkout = fvco / P / FDPLL -- (1) In PD, it will loop until fin/M = fvco/P/N fvco = fin * P * N / M -- (2) (1) + (2) indicates fclkout = fin * N / M / FDPLL In this device, N = (n + 1), M = (m + 1), P = 2, FDPLL = (fdpll + 1). fclkout = fin * (n + 1) / (m + 1) / (fdpll + 1) This is the datasheet formula. One note here is that it should be 2kHz < fvco < 4096MHz To be smaller jitter, fvco should be maximum, in other words, N as large as possible, M as small as possible driver should select. Here, basically M=1. This patch do it. Reported-by: HIROSHI INOSE <hiroshi.inose.rb@renesas.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Small clarifications in comments, renamed finnm to fout] Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Kuninori Morimoto authored
It is difficult to understand its scale if number has many 0s. This patch uses "* 1000" to avoid it in rcar_du_dpll_divider(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Laurent Pinchart authored
Since commit 2fc4d838 ("drm: rcar: use generic code for managing zpos plane property") the rcar-du driver stores the plane zpos in the drm_plane_state structure. The commit however forgot to remove the zpos field from the rcar_du_vsp_plane_state structure. Remove it. Fixes: 2fc4d838 ("drm: rcar: use generic code for managing zpos plane property") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 Feb, 2018 3 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2018-02-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Fix for pcode timeouts on BXT and GLK, cmdparser fixes and fixes for new vbt version on CFL and CNL. GVT contains vGPU reset enhancement, which refines vGPU reset flow and the support of virtual aperture read/write when x-no-mmap=on is set in KVM, which is required by a test case from Redhat and also another fix for virtual OpRegion. * tag 'drm-intel-next-fixes-2018-02-07' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915/bios: add DP max link rate to VBT child device struct drm/i915/cnp: Properly handle VBT ddc pin out of bounds. drm/i915/cnp: Ignore VBT request for know invalid DDC pin. drm/i915/cmdparser: Do not check past the cmd length. drm/i915/cmdparser: Check reg_table_count before derefencing. drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing drm/i915/gvt: Use KVM r/w to access guest opregion drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on drm/i915/gvt: only reset execlist state of one engine during VM engine reset drm/i915/gvt: refine intel_vgpu_submission_ops as per engine ops
-
Jani Nikula authored
Update VBT defs to reflect revision 216. While at it, default the expected child device struct size to sizeof the size rather than a hardcoded value. v2: Fix bit order (David) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180118153310.32437-1-jani.nikula@intel.com (cherry picked from commit c4fb60b9) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
A few more misc fixes for 4.16. * 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: re-enable CGCG on CZ and disable on ST drm/amdgpu: disable coarse grain clockgating for ST drm/radeon: adjust tested variable drm/amdgpu: remove WARN_ON when VM isn't found v2 drm/amdgpu: fix locking in vega10_ih_prescreen_iv drm/amdgpu: fix another potential cause of VM faults drm/amdgpu: use queue 0 for kiq ring drm/ttm: Fix 'buf' pointer update in ttm_bo_vm_access_kmap() (v2) drm/ttm: fix missing parameter change for ttm_bo_cleanup_refs
-
- 06 Feb, 2018 10 commits
-
-
Rodrigo Vivi authored
If the table result is out of bounds on the array map there is something really wrong with VBT pin so we don't return that vbt_pin, but only return 0 instead. This basically reverts commit 'a8e6f388 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")' Also this properly fixes commit 9c3b2689 ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") v2: Do in a way that we don't break other platforms. (Jani) v3: Keep debug message (Jani) v4: Don't mess with 0 mapping was noticed by Jani and addressed with a simple solution suggested by Lucas that makes this even simpler. Fixes: a8e6f388 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.") Fixes: 9c3b2689 ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.") Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrigo.vivi@intel.com (cherry picked from commit 3393ce1e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Rodrigo Vivi authored
Let's ignore VBT request if the pin is clearly wrong. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139 Cc: Kai Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123174050.4261-1-rodrigo.vivi@intel.comReviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> (cherry picked from commit a8e6f388) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Michal Srb authored
The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2. In that case check_cmd will read bits from the following command, or even past the end of the buffer. If the offset ends up outside of the command length, reject the command. Fixes: 351e3db2 ("drm/i915: Implement command buffer parsing logic") Signed-off-by: Michal Srb <msrb@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205151745.29292-1-msrb@suse.comReviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180205160438.3267-2-chris@chris-wilson.co.uk (cherry picked from commit 3aec7f87) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Michal Srb authored
The find_reg function was assuming that there is always at least one table in reg_tables. It is not always true. In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0, implying that no register-accessing commands are allowed. However, the command tables include commands such as MI_STORE_REGISTER_MEM. When trying to check such command, the find_reg would dereference NULL pointer. Now it will just return NULL meaning that the register was not found and the command will be rejected. Fixes: 76ff480e ("drm/i915/cmdparser: Use binary search for faster register lookup") Signed-off-by: Michal Srb <msrb@suse.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180205142916.27092-2-msrb@suse.com Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180205160438.3267-1-chris@chris-wilson.co.uk register lookup") (cherry picked from commit 2f265fad) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Imre Deak authored
Currently we see sporadic timeouts during CDCLK changing both on BXT and GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by changing the frequency in a tight loop after blanking the display. The upper bound for the completion time is 800us based on my tests, so increase it from the current 500us to 2ms; with that I couldn't trigger the problem either on BXT or GLK. Note that timeouts happened during both the change notification and the voltage level setting PCODE request. (For the latter one BSpec doesn't require us to wait for completion before further HW programming.) This issue is similar to commit 2c7d0602 ("drm/i915/gen9: Fix PCODE polling during CDCLK change notification") but there the PCODE request does complete (as shown by the mbox busy flag), only the reply we get from PCODE indicates a failure. So there we keep resending the request until a success reply, here we just have to increase the timeout for the one PCODE request we send. v2: - s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com (cherry picked from commit e76019a8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Tina Zhang authored
For KVMGT, the guest opregion, which is handled by VFIO, is actually a piece of guest memory which won't be accessed by devices. So, its mfn shouldn't be obtained through VFIO interface. This patch uses KVM r/w interface to access the data in guest opregion. Fix the guest opregion accessing issue when host "intel_iommu=on". v3: - Remove mapped flag for KVM/VFIO usage, as it's useless for KVM. v2: - Set the gpa correctly when invoking KVM r/w operations. (Zhenyu) Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Changbin Du authored
When add 'x-no-mmap=on' for vfio-pci option, aperture access in guest is emulated. But the vgpu_aperture_rw() function take wrong offset when do memcpy, since vgpu->gm.aperture_va is not the base of entire aperture. This mistake cause GPU command in guest get lost and so the seqno is not updated in engine HWSP. This patch fix this, and it also move the emulation code to kvmgt. Because only vfio need to emulate it. Put aperture rw to MMIO emulation path breaks assumptions in xengt. v2: Remove PAGE_ALIGN for size (zhenyu) Fixes: f090a00d ("drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach") Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Weinan Li authored
Only reset vgpu execlist state of the exact engine which gets reset request from VM. After read context status from HWSP enabled, KMD will use the saved CSB read pointer but not always read from MMIO. When one engine reset happen, only the read pointer of this engine will be reset, in GVT-g host side also need to align with this policy, otherwise VM may get wrong CSB status after one engine reset compeleted. v2: Split refine and fix patch, code refine(Zhenyu) v3: Move active flag of vgpu scheduler into sched_data(Zhenyu) Cc: Fred Gao <fred.gao@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Weinan Li authored
Using per engine ops will be more flexible, here refine sub-ops(init, clean) as per engine operation align with reset operation. This change also will be used in next fix patch for VM engine reset. Cc: Fred Gao <fred.gao@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Shirish S authored
The CGCG feature on Stoney is causing GFX related issues such as freezes and blank outs. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
- 05 Feb, 2018 2 commits
-
-
git://github.com/skeggsb/linuxDave Airlie authored
- initial kepler clock gating support - atomic gamma handling fixes - support for gp108 "secure boot" (enables acceleration, finally) * 'linux-4.16' of git://github.com/skeggsb/linux: drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning drm/nouveau/mmu: Fix trailing semicolon drm/nouveau: Introduce NvPmEnableGating option drm/nouveau: Add support for SLCG for Kepler2 drm/nouveau: Add support for BLCG on Kepler2 drm/nouveau: Add support for BLCG on Kepler1 drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau/kms/nv50: fix handling of gamma since atomic conversion drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on newer chipsets drm/nouveau/kms/nv50: use "low res" lut for indexed mode drm/nouveau/kms/nv50: prepare for double-buffered LUTs drm/nouveau/bo: add helper functions for handling pinned+mapped buffers drm/nouveau/fbcon: add module parameter to select bits-per-pixel drm/nouveau/secboot/gp108: implement on top of acr_r370 drm/nouveau/secboot/r370: implement support for booting LS SEC2 ucode drm/nouveau/secboot/r370: move a bunch of r375 stuff to a new implementation drm/nouveau: nouveau: use correct string length drm/nouveau/drm/nouveau/mmu: fix odd_ptr_err.cocci warnings drm/nouveau/pmu/fuc: don't use movw directly anymore
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2018-02-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Fixes for GPU hangs and other bugs around hangcheck and result; Fix for regression on suspend case with vgaswitcheroo; Fixes for eDP and HDMI blank screens Fix for protecting WC allocation to avoid overflow on page vec; Cleanup around unpublished GLK firmware blobs, and other small fixes. This also contains GVT pull request mostly with regression fixes on vGPU display dmabuf, mmio switch and other misc changes. * tag 'drm-intel-next-fixes-2018-02-01' of git://anongit.freedesktop.org/drm/drm-intel: (21 commits) drm/i915/ppgtt: Pin page directories before allocation drm/i915: Always run hangcheck while the GPU is busy Revert "drm/i915: mark all device info struct with __initconst" drm/i915/edp: Do not do link training fallback or prune modes on EDP drm/i915: Check for fused or unused pipes drm/i915: Protect WC stash allocation against direct reclaim drm/i915: Only attempt to scan the requested number of shrinker slabs drm/i915: Always call to intel_display_set_init_power() in resume_early. drm/i915/gvt: cancel scheduler timer when no vGPU exists drm/i915/gvt: cancel virtual vblank timer when no vGPU exists drm/i915/gvt: Keep obj->dma_buf link NULL during exporting drm/i915/pmu: Reconstruct active state on starting busy-stats drm/i915: Stop getting the fault address from RING_FAULT_REG drm/i915/guc: Add uc_fini_wq in gem_init unwind path drm/i915: Fix using BIT_ULL() vs. BIT() for power domain masks drm/i915: Try EDID bitbanging on HDMI after failed read drm/i915/glk: Disable Guc and HuC on GLK drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the mocs regs array drm/i915/gvt: validate gfn before set shadow page entry drm/i915/gvt: add PLANE_KEYMAX regs to mmio track list ...
-
- 02 Feb, 2018 17 commits
-
-
Arnd Bergmann authored
gcc thinks that interpreting a multiplication result as a bool is confusing: drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] Adding a temporary variable to contain the divisor helps make it clear what is going on and avoids that warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Luis de Bethencourt authored
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt <luisbg@kernel.org> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
This adds the NvPmEnableGating config option to nouveau, which can be used to enable or disable clockgating for supported chipsets. Enabling can be done by passing config=NvPmEnableGating=1 To nouveau. If your chipset supports it, you'll see a message in your kernel log indicating that clockgating is enabled. Since clockgating has only had limited testing thus far, we leave this option disabled by default for now. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
That's right, there's still more power saving to go! Starting with kepler 2, nvidia hardware has an additional level of clockgating known as second level clockgating. The details of this are not exact, but it seems to work by waiting for a collection of dependent hardware blocks to be gated before taking affect. As with the previous series, this results in another noticeable drop in power consumption and is programmed in the same manner. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
Same as the previous patch, but for Kepler2 now Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more power hungry then they need to be, so the nvidia driver writes it's own more optimized set of BLCG settings before enabling CG_CTRL. This adds support for programming the optimized BLCG values during engine/subdev init, which enables rather significant power savings. This introduces the nvkm_therm_clkgate_init() helper, which we use to program the optimized BLCG settings before enabling clockgating with nvkm_therm_clkgate_enable. As well, this commit shares a lot more code with Fermi since BLCG is mostly the same there as far as we can tell. In the future, it's likely we'll reformat the clkgate_packs for kepler1 so that they share a list of mmio packs with Fermi. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Lyude Paul authored
This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling basic clockgating: nvkm_therm_clkgate_enable() - enables clockgating through CG_CTRL, done after initializing the GPU fully nvkm_therm_clkgate_fini() - prepares clockgating for suspend or driver unload A lot of this code was originally going to be based off of fermi; however it turns out that while Fermi's the first line of GPUs that introduced this kind of power saving, Fermi requires more fine tuned control of the CG_CTRL registers from the driver while reclocking that we don't entirely understand yet. For the simple parts we will be sharing with Fermi for certain however, we at least add those into a new subdev/therm/gf100.h header. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We've still been directly using the legacy crtc gamma_set() hook even after conversion to atomic modesetting. For userspace clients this was fine, however, fbcon will use the atomic property when it's running on an atomic driver, which means we miss its colormap updates - which is particularly bad for 8bpp framebuffers! This commit converts the driver to use the atomic property + the helper function implementing the legacy hook on top of atomic. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
For some reason forgotten by history, we've been using a 1025-entry LUT mode, and sparsely filling it with the 256-entry LUT we're handed. Until we land support for the full atomic colour management properties, this commit switches to using the 257-entry mode to fix colour mapping with depth 30 framebuffers. Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
This is what was done prior to the big refactor in kernel 3.8, and what was done by xf86-video-nv. Experimentally, it seems like there's some sort of issue with the high-res lut to be used there. Tested on G92. This ends up mattering because fbcon/fbdev chooses the C8 fb format for low-vram systems, which can occur with some IGP-based configurations with little "stolen" vram. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We need to double-buffer LUTs to handle their update atomically. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This is a common, awkward sequence. Let's wrap it up! Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Useful for debugging. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
-
Ben Skeggs authored
It's entirely possibly that the other r375 code is relevant to r370 too, but I've not confirmed this, so I'll leave it where it is for now. NVIDIA's copyright headers maintained, as it's still all their code. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Gourav Samaiya <gsamaiya@nvidia.com>
-
Arnd Bergmann authored
gcc-8 reports drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd': include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation] We need one less byte or call strlcpy() to make it a nul-terminated string. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-