| Age | Commit message (Collapse) | Author | Files | Lines |
|
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct intel_dp or struct
drm_i915_private pointer is available.
Conversion is done with below sementic patch:
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule3@
identifier func, T;
@@
func(struct intel_dp *T,...) {
+ struct drm_i915_private *i915 = dp_to_i915(T);
<+...
(
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(...) {
...
struct intel_dp *T = ...;
+ struct drm_i915_private *i915 = dp_to_i915(T);
<+...
(
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-3-pankaj.laxminarayan.bharadiya@intel.com
|
|
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct i915_power_domains
struct is available.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(struct i915_power_domains *T,...) {
+ struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, power_domains);
<+...
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
...+>
}
changes since v1:
- Fix commit subject (Jani)
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-2-pankaj.laxminarayan.bharadiya@intel.com
|
|
Make sure to select the port's AUX power domain while holding the TC
port lock. The domain depends on the port's current TC mode, which may
get changed under us if we're not holding the lock.
This was left out from
commit 8c10e2262663 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers")
Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514204553.27193-1-imre.deak@intel.com
|
|
If the mapping address is wrong then we have to release the reference to
it before returning -EINVAL.
Fixes: 088880ddc0b2 ("drm/etnaviv: implement softpin")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
|
The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are relevant:
doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains
doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain
The userspace driver wants to get a list of all perfmon domains and
their perfmon signals. This is done by iterating over all domains and
their signals. If the userspace driver wants to access the domain with
id 8 the kernel driver fails and returns invalid data from doms_3d with
and invalid offset.
This results in:
Unable to handle kernel paging request at virtual address 00000000
On such a device it is not possible to use the userspace driver at all.
The fix for this off-by-one error is quite simple.
Reported-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Paul Cercueil <paul@crapouillou.net>
Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
|
|
Prefer ARRAY_SIZE instead of using sizeof
Fixes coccicheck warning: Use ARRAY_SIZE
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Aishwarya Ramakrishnan <aishwaryarj100@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200518150336.15265-1-aishwaryarj100@gmail.com
|
|
When CONFIG_DRM_I915_DEBUG_GEM is not set, clang warns:
drivers/gpu/drm/i915/gvt/scheduler.c:884:1: warning: function
'check_shadow_context_ppgtt' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
check_shadow_context_ppgtt(struct execlist_ring_context *c, struct
intel_vgpu_mm *m)
^
1 warning generated.
This warning is similar to -Wunused-function but rather than warning
that the function is completely unused, it warns that it is used in some
expression within the file but that expression will be evaluated to a
constant or be optimized away in the final assembly, essentially making
it appeared used but really isn't. Usually, this happens when a function
or variable is only used in sizeof, where it will appear to be used but
will be evaluated at compile time and not be required to be emitted.
In this case, the function is only used in GEM_BUG_ON, which is defined
as BUILD_BUG_ON_INVALID, which intentionally follows this pattern. To
fix this warning, add __maybe_unused to make it clear that this is
intentional depending on the configuration.
Fixes: bec3df930fbd ("drm/i915/gvt: Support PPGTT table load command")
Link: https://github.com/ClangBuiltLinux/linux/issues/1027
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200516023545.3332334-1-natechancellor@gmail.com
|
|
I've checked a bunch of gen3/4 machines and all seem to have
consistent FSB frequency information in the CLKCFG register.
So let's read out hrawclk on all gen3+ machines. Although
apart from g4x/pnv aux/pps dividers we only really need this
for for i965g/gm cs timestamp increment.
The CLKCFG memory clock values seem less consistent but we
don't care about those here.
For posterity here's a list of CLKCFG vs. FSB dumps from
a bunch of machines (only missing lpt for a full set):
machine CLKCFG FSB
alv1 0x00001411 533
alv2 0x00000420 400 (Chris)
gdg1 0x20000022 800
gdg2 0x20000022 800
cst 0x00010043 666
blb 0x00002034 1333
pnv1 0x00000423 666
pnv2 0x00000433 666
965gm 0x00004342 800
946gz 0x00000022 800
965g 0x00000422 800
g35 0x00000430 1066
0x00000434 1333
ctg1 0x00644056 1066
ctg2 0x00644066 1066
elk1 0x00012420 1066
0x00012424 1333
0x00012436 1600
0x00012422 800
elk2 0x00012040 1066
For the mobile parts the chipset docs generally have these
documented to some degree (alv being the exception).
The two settings w/o any evidence are 0x5=400MHz on desktop
and 0x7=1333MHz on mobile. Though the mobile 1333MHz case
probably doesn't even exist since ctg is only documented
to go up to 1066MHz.
v2: Fix 400mhz readout for Chris's alv/celeron machine
Do a clean mobile vs. dekstop split since that's really
what seems to be going on
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-3-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Document the fact that we aren't reading out the actual FSB
frequency but rather just the state of the FSB straps.
Some BIOSen allow you to configure the two independently.
So if someone sets the two up in an inconsistent manner
we'll get the wrong answer here and thus will end up with
incorrect aux/pps clock dividers. Alas, proper docs are no
longer around so we can't do any better.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Looks like elk redefines some of the CLKCFG FSB values to
make room for 400 MHz FSB. The setting overlaps with one of
the 266MHz settings (which is even documented in the ctg docs,
and cofirmed to be correct on my ctg). So we limit the special
case to elk only.
Though it might also be that we have some kind of desktop vs.
mobile difference going on here as eg. both g35 and elk
use 0x0 for the 266 MHz setting, vs. 0x6 used by ctg). The
g35 doesn't let me select 400MHz for the FSB strap so can't
confirm which way it would go here. But anyways as it seems
only elk has the 400MHz option we shouldn't lose anything
by limiting the special case to it alone.
My earlier experiments on this appear to have been nonsense as
the comment I added claims that FSB strap of 400MHz results in
a value of 0x4, but I've now retested it and I definitely get a
value of 0x6 instead. So let's remove that bogus comment.
v2: s/_ELK/_ALT/ in the define in anticipation of a full
mobile vs. desktop CLKCFG split
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-1-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The VRAM helpers managed the framebuffer memory for mgag200. This came
with several problems, as some MGA device require the scanout address
to be located at VRAM offset 0. It's incompatible with the page-flip
semantics of DRM's atomic modesettting. With atomic modesetting, old and
new framebuffers have to be located in VRAM at the same time. So at least
one of them has to reside at a non-0 offset.
This patch replaces VRAM helpers with SHMEM helpers. GEM SHMEM buffers
reside in system memory, and are shadow-copied into VRAM during page
flips. The shadow copy always starts at VRAM offset 0.
v2:
* revert dev->pdev changes
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-16-tzimmermann@suse.de
|
|
The mgag200 supports a single pipeline with only a primary plane. It can
be converted to simple KMS helpers. This also adds support for atomic
modesetting. Wayland compositors, which use pageflip ioctls, can now be
used with mgag200.
v2:
* prepare encoder and CRTC in a separate patch
* remove suspend/resume code in a separate patch
* don't call set_format_regs() in pipe_update()
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-15-tzimmermann@suse.de
|
|
The MGA CRTC data structure struct mga_crtc contains unused additional
fields; so it can removed. The standard DRM CRTC and encoder structures
are embedded now in struct drm_simple_display_pipe. Done in preparation
of converting mgag200 to simple KMS helpers.
v3:
* remove now-unused define MGAG200FB_CONN_LIMIT
* remove unused define MATROX_DPMS_CLEARED
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-14-tzimmermann@suse.de
|
|
The suspend/resume helpers are unused. Also remove associated state
from struct mga_device.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-13-tzimmermann@suse.de
|
|
Registers are initialized with constants. This is now done in
mgag200_init_regs(), mgag200_set_dac_regs() and mgag200_set_pci_regs().
Later patches should move these calls from mode setting to device
initialization.
v2:
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-12-tzimmermann@suse.de
|
|
The hiprivlvl settings are now updated in mgag200_g200se_set_hiprilvl()
and mgag200_g200ev_set_hiprilvl().
v2:
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-11-tzimmermann@suse.de
|
|
The TAGFIFO state is now reset in mgag200_g200er_reset_tagfifo().
v2:
* define MGAREG_SEQ1_SCROFF
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-10-tzimmermann@suse.de
|
|
The primary plane's format registers are now updated in a
mgag200_set_format_regs().
v2:
* get bpp shift from helper function
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-9-tzimmermann@suse.de
|
|
The framebuffer's pitch is now set in mgag200_set_offset().
v2:
* move offset and bpp-shift calculation into helper functions
* use u8 instead of uint8_t
* add MGAREG_CRTCEXT0_OFFSET_MASK
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-8-tzimmermann@suse.de
|
|
Setting the plane registers first and the mode registers afterwards
reproduces the sequence used by atomic helpers. Done in preparation
of switching to simple KMS helpers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-7-tzimmermann@suse.de
|
|
Set different fields in MISC in their rsp location in the code. This
patch also fixes a bug in the original code where the mode's SYNC flags
were never written into the MISC register.
v2:
* use u8 instead of uint8_t
* define MGAREG_MISC_CLK_SEL_MASK
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-6-tzimmermann@suse.de
|
|
The mode-setting code is now located in mgag200_set_mode_regs(), sans
a few flags that will be moved in a later patch for clarity.
v2:
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-5-tzimmermann@suse.de
|
|
The function now only takes the device structure, and the old and new
framebuffers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-4-tzimmermann@suse.de
|
|
All register names and fields are now named according to the
MGA programming manuals. The function doesn't need the CRTC, so
callers pass in the device structure directly. The logging now
uses device-specific macros.
The original implementation busy-waited for the VSYNC flag to go
up, to synchronize the page flip with the display's vblank. This
code has been moved to mga_crtc_mode_set_base(). It's still present
in the non-atomic code paths, but won't be used in atomic commits.
With atomic, we should use interrupts to synchronize with vblanks.
v3:
* clarify commit message wrt. vblank busy-waiting
v2:
* use to_mga_device()
* use MiB instead of MB
* replace empty while loop with do-while, fixes checkpatch warning
* replace uint{8,32}_t with u{8,32}
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-3-tzimmermann@suse.de
|
|
The HW cursor of Matrox G200 cards only supports a 16-color palette
format. Univeral planes require at least ARGB or a similar component-
based format, so remove the HW cursor.
Alternatively, the driver could dither a cursor image from ARGB to
16 colors. But this does not produce pleasent-looking results in
general, so it's useless for modern compositors.
Without HW support, compositors will use software rendering.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: John Donnelly <John.p.donnelly@oracle.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-2-tzimmermann@suse.de
|
|
struct platform_driver panel_driver is only used from tilcdc_panel.c, so
it can be static.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-3-tomi.valkeinen@ti.com
Reviewed-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
|
|
tilcdc_plane_atomic_check() exits if state->fb == NULL, so no need to
check it again later.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-2-tomi.valkeinen@ti.com
Reviewed-by: Jyri Sarha <jsarha@ti.com>
|
|
If videomode_from_timings() returns true, the mode allocated with
drm_mode_create will be leaked.
Also, the return value of drm_mode_create() is never checked, and thus
could cause NULL deref.
Fix these two issues.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-1-tomi.valkeinen@ti.com
Reviewed-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
|
|
The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
remapping of eDP lanes and also polarity inversion. Both of these
features have been described in the device tree bindings for the
device since the beginning but were never implemented in the driver.
Implement both of them.
Part of this change also allows you to (via the same device tree
bindings) specify to use fewer than the max number of DP lanes that
the panel reports. This could be useful if your display supports more
lanes but only a few are hooked up on your board.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518114656.REPOST.v2.1.Ibc8eeddcee94984a608d6900b46f9ffde4045da4@changeid
|
|
If the rate in our table is _equal_ to the rate we want then it's OK
to pick it. It doesn't need to be greater than the one we want.
Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504213225.1.I21646c7c37ff63f52ae6cdccc9bc829fbc3d9424@changeid
|
|
The AUX channel transfer error bits in the status register are latched
and need to be cleared. Clear them before doing our transfer so we
don't see old bits and get confused.
Without this patch having a single failure would mean that all future
transfers would look like they failed.
Fixes: b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200508163314.1.Idfa69d5d3fc9623083c0ff78572fea87dccb199c@changeid
|
|
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system. Each pin can be configured as input,
output, or a special function for the bridge chip. These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM
Let's expose these pins as GPIOs. A few notes:
- Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
- These pins can't be configured for IRQ.
- There are no programmable pulls or other fancy features.
- Keeping the bridge chip powered might be expensive. The driver is
setup such that if all used GPIOs are only inputs we'll power the
bridge chip on just long enough to read the GPIO and then power it
off again. Setting a GPIO as output will keep the bridge powered.
- If someone releases a GPIO we'll implicitly switch it to an input so
we no longer need to keep the bridge powered for it.
Because of all of the above limitations we just need to implement a
bare-bones GPIO driver. The device tree bindings already account for
this device being a GPIO controller so we only need the driver changes
for it.
NOTE: Despite the fact that these pins are nominally muxable I don't
believe it makes sense to expose them through the pinctrl interface as
well as the GPIO interface. The special functions are things that the
bridge chip driver itself would care about and it can just configure
the pins as needed.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
[added pdata->gchip.base = -1;]
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.1.Ia50267a5549392af8b37e67092ca653a59c95886@changeid
|
|
drivers/gpu/drm/i915/intel_pm.c:5920 skl_ddb_add_affected_pipes() error: uninitialized symbol 'ret'.
Fixes: 3cf43cdc63fb ("drm/i915: Introduce proper dbuf state")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516190940.12675-1-chris@chris-wilson.co.uk
|
|
The current dbuf slice computation only happens when there are
active pipes. If we are turning off all the pipes we just leave
the dbuf slice mask at it's previous value, which may be something
other that BIT(S1). If runtime PM will kick in it will however
turn off everything but S1. Then on the next atomic commit (if
the new dbuf slice mask matches the stale value we left behind)
the code will not turn on the other slices we now need. This will
lead to underruns as the planes are trying to use a dbuf slice
that's not powered up.
To work around let's just just explicitly set the dbuf slice mask
to BIT(S1) when we are turning off all the pipes. Really the code
should just calculate this stuff the same way regardless whether
the pipes are on or off, but we're not quite there yet (need a
bit more work on the dbuf state for that).
v2: Let's not put the fix into dead code
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 3cf43cdc63fb ("drm/i915: Introduce proper dbuf state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518121354.20401-1-ville.syrjala@linux.intel.com
|
|
In order to keep all the tasklets in the same execution lists and so
fifo ordered, be consistent and use the same priority for all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518081440.17948-3-chris@chris-wilson.co.uk
|
|
A405 device has a different set of registers than a4xx_registers. It
has no VMIDMT or XPU registers, and VBIF registers are different. Let's
add a405_registers for a405 device.
As adreno_is_a405() works only after adreno_gpu_init() gets called, the
assignments get moved down after adreno_gpu_init().
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Jordan Crouse <jcrouse@codeauorora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
It adds support for adreno a405 found on MSM8939. The adreno_is_a430()
check in adreno_submit() needs an extension to cover a405. The
downstream driver suggests it should cover the whole a4xx generation.
That's why it gets changed to adreno_is_a4xx(), while a420 is not
tested though.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Adreno 640 and 650 GPUs need some registers set differently.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
This is required for a650 to work.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Update the gmu_pdc registers for A640 and A650.
Some of the RSCC registers on A650 are in a separate region.
Note this also changes the address of these registers:
RSCC_TCS1_DRV0_STATUS
RSCC_TCS2_DRV0_STATUS
RSCC_TCS3_DRV0_STATUS
Based on the values in msm-4.14 and msm-4.19 kernels.
v3: replaced adreno_is_a650 around ->rscc with checks for "rscc" resource
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Newer GPUs have different GMU firmware path.
v3: updated a6xx_gmu_fw_load based on feedback, including gmu_write_bulk,
and removed extra whitespace change
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Add HFI v2 code paths required by Adreno 640 and 650 GPUs.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Add Adreno 640 and 650 GPU info to the gpulist.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
This gives more fine-grained control over how memory is allocated over the
DMA api. In particular, it allows using an address range or pinning to
a fixed address.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
This flag sets IOMMU_PRIV, which is required for some a6xx GMU objects.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeauorora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
This function allows pinning iova to a specific page range (for a6xx GMU).
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Writing to the devfreq sysfs nodes while the GPU is powered down can
result in a system crash (on a5xx) or a nasty GMU error (on a6xx):
$ /sys/class/devfreq/5000000.gpu# echo 500000000 > min_freq
[ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob]
*ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0
Despite the fact that we carefully try to suspend the devfreq device when
the hardware is powered down there are lots of holes in the governors that
don't check for the suspend state and blindly call into the devfreq
callbacks that end up triggering hardware reads in the GPU driver.
Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq()
callbacks to skip the hardware access if it isn't active.
v3: Only check pm_runtime_get_if_in_use() for == 0 per Eric Anholt
v2: Use pm_runtime_get_if_in_use() per Eric Anholt
Cc: stable@vger.kernel.org
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Maximum allowed bandwidth has no dependency on the type
of panel used. Hence, cleanup the code to use max_bw_high
as the threshold value for bandwidth checks.
Update the maximum allowed bandwidth as 6.8Gbps for
SC7180 target.
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
This change adds support to scale src clk and bandwidth as
per composition requirements.
Interconnect registration for bw has been moved to mdp
device node from mdss to facilitate the scaling.
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
This change adds support for color correction sub block
for SC7180 device.
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Tested-by: Fritz Koenig <frkoenig@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
|