As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
Practically we can achive only 99% of these cdclk values (HW team
checking on this). So cdclk should be calculated for the given pixclk as
per that otherwise it may lead to screen corruption, explained below:
1. For DSI AUO panel(1920x1200 @60) required pixclk is 157100 KHZ
2. glk_calc_cdclk returns 79200 KHZ for this pixclk, For 2PPC it
will be 158400 KHZ
3. Practically 100% of the cdclk can’t be achieved, so 99% of 158400
KHZ = 156816 which is less than the desired pixlclk and causes
panel corruption.
v2: Rebased to new CDLCK code framework
v3: Addressed review comments from Ander/Jani
- Add comment in code about 99% usage of CDCLK
- Calculate max dot clock as well with 99% limit
v4 by Jani:
- drop superfluous whitespace change
- rewrite code comments to clarify
v5: Added details of non-working scenario in commit message
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491397463-13637-1-git-send-email-madhav.chauhan@intel.com
There is some conflation related to sink rates, making this change more
complicated than it would otherwise have to be. There are three changes
here that are rather difficult to split up:
1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We
initialize it from DPCD on eDP 1.4 like before, but generate it based
on DP_MAX_LINK_RATE on others. This reduces code complexity when we
need to use the sink rates; they are all always in the sink_rates
array.
2) Update the sink rate array whenever we read DPCD, and use the
information from there. This increases code readability when we need
the sink rates.
3) Disentangle fallback rate limiting from sink rates. In the code, the
max rate is a dynamic property of the *link*, not of the *sink*. Do
the limiting after intersecting the source and sink rates, which are
static properties of the devices.
This paves the way for follow-up refactoring that I've refrained from
doing here to keep this change as simple as it possibly can.
v2: introduce use_rate_select and handle non-confirming eDP (Ville)
v3: don't clobber cached eDP rates on short pulse (Ville)
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
It's too chatty to have three places to tell us which one
is next vgpu for schedule. My log file was bloated to eat
all disk space..
Cc: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
The goal is to push all the kms locking down into these separate
_atomic and _legacy functions, so that we can correctly pass the
acquire ctx into all atomic drivers. Instead of playing games with
hidden ctx in mode_config.acquire_ctx. All the fbdev state will be
protected by a new fbdev private lock that Thierry is working on.
This here is just prep by creating a clean split between atomic and
legacy paths, which also simplifies the control flow a bit.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-16-daniel.vetter@ffwll.ch
It just doesn't work. It probably stopped working way, way before that
(e.g. i915 grabbed random mutexes all over in modeset code at least
since gen6), but with atomic and all the ww_mutex stuff it's indeed
hopeless.
Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and
nouveau) that still had one (both had dummy implementations already
anyway), and shunt atomic drivers in the helpers debug_enter/leave
functions.
I'll leave the code in for radeon and amdgpu, but I think as soon as
amdgpu is atomic we should think about just ripping it out. Only
having it around for radeon and pre-nv50 is rather pointless. This
would also allow us to nuke all that code from fbdev.
Funny part is that _all_ kms drivers set this hook, despite that no
one else provides the required ->mode_set_base_atomic implementation.
The reason I'm jumping on this is that I want to wire up a full
acquire ctx for the benefit of atomic drivers, everywhere. And the
debug_enter/leave implementations call ->gamma_set. And there's just
no way ever we can create an acquire_ctx in the nmi context of kgdb.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-11-daniel.vetter@ffwll.ch
GP10B's power is managed by generic PM domains, so it does not require a
VDD regulator. Add this option into the chip function structure.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GR is similar to GP100, with a few unavailable registers.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GP10B requires a specific initialization sequence due to the absence of
devinit.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GP10B's MC is compatible with GP100's, but engines need to be explicitly
put out of ELPG during init.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GP10B's FB is largely compatible with the GP100 implementation.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GP10B's FIFO is similar to GP100's, but only allows 512 channels.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The GP10B firmware is very close to GM20B's. The only difference is that
it supports booting multiple falcons. In order to avoid having too much
functions and structures shared, implement its support in the same
source file as GM20B firmware.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GP10B's secboot is largely similar to GM20B's. Only differences are MC
base address and the fact that GPCCS is also securely managed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Allow the MC base address to be specified as an argument for the WPR
region reading function. GP10B uses a different address layout as GM20B,
so this is necessary. Also export the function to be used by GP10B.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The LS firmware post-run hook is the right place to start said LS
firmware. Moving it here also allows to remove special handling in the
ACR code.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A LS post-run hook can meet an error meaning the failure of secure boot.
Make sure this can be reported.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Having access to the secboot instance loading a LS firmware can be
useful to LS firmware handlers. At least more useful than just having an
out-of-context subdev pointer.
GP10B's firmware will also need to know the WPR address, which can be
obtained from the secboot instance.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Change the secboot and msgqueue interfaces to take a mask of falcons to
reset instead of a single falcon. The GP10B firmware interface requires
FECS and GPCCS to be booted in a single firmware command.
For firmwares that only support single falcon boot, it is trivial to
loop over the mask and boot each falcons individually.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The gk20a implementation of instance memory uses vmap()/vunmap() to map
memory regions into the kernel's virtual address space. These functions
may sleep, so protecting them by a spin lock is not safe. This triggers
a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this
by using a mutex instead.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Forked from GP106 implementation.
Split out from commit enabling secboot/gr support so that it can be
added to earlier kernels.
Cc: stable@vger.kernel.org [4.10+]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the atomic support was added to nouveau, the DRM core did not do this.
However, later in the same merge window, a commit (drm/fence: add in-fences
support) was merged that added it, leading to use-after-frees of the fence
object.
Cc: stable@vger.kernel.org [4.10+]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
and PCI varieties, rather than a core PCIE chip with a bridge for
AGP/PCI as necessary. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.
Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Forked from GP106 implementation.
Split out from commit enabling secboot/gr support so that it can be
added to earlier kernels.
Cc: stable@vger.kernel.org [4.10+]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the atomic support was added to nouveau, the DRM core did not do this.
However, later in the same merge window, a commit (drm/fence: add in-fences
support) was merged that added it, leading to use-after-frees of the fence
object.
Cc: stable@vger.kernel.org [4.10+]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
and PCI varieties, rather than a core PCIE chip with a bridge for
AGP/PCI as necessary. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.
Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fix wrong initial csb read pointer value. This fixes the random
engine timeout issue in guest when guest boots up.
Fixes: 8453d674ae ("drm/i915/gvt: vGPU execlist virtualization")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Min He <min.he@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
