The pull request you sent on Tue, 4 Feb 2020 09:26:45 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-02-04
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9717c1cea16e3eae81ca226f4c3670bb799b61ad
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
Right now several architectures allow their set_memory_*() family of
functions to fail, but callers may not be checking the return values.
If set_memory_*() returns with an error, call-site assumptions may be
infact wrong to assume that it would either succeed or not succeed at
all. Ideally, th
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> If we fail training at a lower DP link rate let's now keep trying
> until we run out of rates to try. Basically the algorithm here is to
> start at the link rate that is the theoretical minimum and then slowly
> bump up until we run out of r
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> This series contains a pile of patches that was created to support
> hooking up the AUO B116XAK01 panel to the eDP side of the bridge. In
> general it should be useful for hooking up a wider variety of DP
> panels to the bridge, especially t
Hi,
On Thu, Jan 30, 2020 at 08:20:55AM +0200, Stefan Mavrodiev wrote:
> On 1/29/20 6:43 PM, Maxime Ripard wrote:
> > On Tue, Jan 28, 2020 at 04:06:42PM +0200, Stefan Mavrodiev wrote:
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > > b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> > > ind
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/ccree/cc_cipher.c: In function 'cc_setup_state_desc':
drivers/crypto/ccree/cc_cipher.c:536:15: warning:
variable 'du_size' set but not used [-Wunused-but-set-variable]
commit 5c83e8ec4d51 ("crypto: ccree - fix FDE descriptor sequence"
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> These two things were in one function. Split into two. This looks
> like it's duplicating some code, but don't worry. This is is just in
> preparation for future changes.
>
> This is intended to have zero functional change and will just m
When the lock was introduced in 72aabfb862e40 ("drm/i915/gvt: Add mutual
lock for ppgtt mm LRU list") one place got lost.
Signed-off-by: Igor Druzhinin
---
drivers/gpu/drm/i915/gvt/gtt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915
Reviewed-by: Alyssas Rosenzweig , thank
you!
On Mon, Feb 03, 2020 at 03:27:24PM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
> drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
>
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> The driver used to say that the value to program into bridge register
> 0x93 was dp_lanes - 1. Looking at the datasheet for the bridge, this
> is wrong. The data sheet says:
> * 1 = 1 lane
> * 2 = 2 lanes
> * 3 = 4 lanes
>
> A more proper
Check that computed crc value is matching the one encoded in the message.
Signed-off-by: Benjamin Gaignard
---
CC: ly...@redhat.com
CC: airl...@linux.ie
CC: jani.nik...@linux.intel.com
drivers/gpu/drm/drm_dp_mst_topology.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/d
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> When we iterate over ti_sn_bridge_dp_rate_lut, there's no reason to
> start at index 0 which always contains the value 0. 0 is not a valid
> link rate.
>
> This change should have no real effect but is a small cleanup.
>
> Signed-off-by: D
Quoting abhin...@codeaurora.org (2020-01-31 13:01:38)
> Hi Steven
>
> Any further comments on this change?
>
No. I was more of a drive by review comment on the previous patch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fr
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> At least one panel hooked up to the bridge (AUO B116XAK01) only
> supports 1 lane of DP. Let's read this information and stop
> hardcoding 4 DP lanes.
>
> Signed-off-by: Douglas Anderson
> Tested-by: Rob Clark
> Reviewed-by: Rob Clark
R
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup':
drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning:
variable 'bo' set but not used [-Wunused-but-set-variable]
commit bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> The current bridge driver always forced us to use 24 bits per pixel
> over the DP link. This is a waste if you are hooked up to a panel
> that only supports 6 bits per color or fewer, since in that case you
> ran run at 18 bits per pixel and
> On Feb 3, 2020, at 11:16 AM, Christian König wrote:
>
> Am 03.02.20 um 17:18 schrieb Tianlin Li:
>> Right now several architectures allow their set_memory_*() family of
>> functions to fail,
>
> Oh, that is a detail I previously didn't recognized. Which architectures are
> that?
>
> Cause t
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> We'll re-organize the ti_sn_bridge_enable() function a bit to group
> together all the parts relating to link training and split them into a
> sub-function. This is not intended to have any functional change and
> is in preparation for tryin
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> Based on work by Bjorn Andersson ,
> Jeffrey Hugo , and
> Rob Clark .
>
> Let's read the SUPPORTED_LINK_RATES and/or MAX_LINK_RATE (depending on
> the eDP version of the sink) to figure out what eDP rates are
> supported and pick the ideal o
On Wed 18 Dec 14:35 PST 2019, Douglas Anderson wrote:
> The ti-sn65dsi86 is a bridge from MIPI to DP and thus has two links:
> the MIPI link and the DP link. The two links do not need to have the
> same format or number of lanes. Stop using MIPI variables when
> talking about the DP link.
>
> T
drm-Remove-PageReserved-manipulation-from-drm_pci_alloc/20200203-201707
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s2-20200204 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
# save the attached .config to linux
On Tue, 28 Jan 2020, Pankaj Bharadiya
wrote:
> Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> include device information in the backtrace, so we know what device
> the warnings originate from.
>
> Similar to this, add new struct drm_device based drm_WARN* macros. These
>
On Thu, 30 Jan 2020, Wambui Karuga wrote:
> This series continues the conversion of the printk based logging macros
> to the new struct drm_device based logging macros in the drm/i915/display
> folder.
Thanks for the patches, series pushed to drm-intel-next-queued.
BR,
Jani.
--
Jani Nikula, In
Le jeu. 23 janv. 2020 à 10:47, Philippe CORNU a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Philippe :-)
>
> On 1/20/20 2:46 PM, Yannick Fertre wrote:
> > From: Yannick Fertré
> >
> > When connected to a dsi host, the ltdc display controller
> > must se
Le jeu. 23 janv. 2020 à 10:49, Philippe CORNU a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Philippe :-)
>
> On 1/21/20 11:13 AM, Yannick Fertre wrote:
> > The number of interrupts depends on the ltdc version.
> > Don't try to get interrupt which not exi
Le jeu. 23 janv. 2020 à 10:50, Philippe CORNU a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Philippe :-)
>
> On 1/21/20 11:14 AM, Yannick Fertre wrote:
> > Following investigations of a hardware bug, the LIE interrupt
> > can occur while the display cont
Le jeu. 23 janv. 2020 à 10:54, Philippe CORNU a écrit :
>
> Dears Yannick & Etienne,
> Thank you for your patch,
>
> Reviewed-by: Philippe Cornu
>
> Philippe :-)
>
> On 1/21/20 11:24 AM, Yannick Fertre wrote:
> > From: Etienne Carriere
> >
> > Change DSI driver to not print an error trace when p
Le jeu. 23 janv. 2020 à 10:51, Philippe CORNU a écrit :
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Philippe :-)
>
> On 1/21/20 11:14 AM, Yannick Fertre wrote:
> > Number of endpoints could exceed the fix value MAX_ENDPOINTS(2).
> > Instead of increase simply th
Hello Christian König,
The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
from Apr 16, 2019, leads to the following static checker warning:
drivers/gpu/drm/ttm/ttm_bo.c:1610 ttm_bo_global_release()
warn: passing freed memory 'glob'
drivers/gpu/drm/ttm/ttm_bo.c
On Mon, Feb 03, 2020 at 08:15:51PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Ville Syrjala
> > Sent: Saturday, January 25, 2020 1:32 AM
> > To: dri-devel@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org; Andres Rodriguez
> >
https://bugzilla.kernel.org/show_bug.cgi?id=206393
Bjoern Franke (b...@nord-west.org) changed:
What|Removed |Added
Regression|No |Yes
--
You are rece
From: Thierry Reding
Older Tegra devices only allow addressing 32 bits of memory, so whether
or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU
attachment is only needed on devices that can address memory beyond the
32-bit boundary and where the host1x doesn't support the wide
From: Thierry Reding
Hi,
this contains a couple of fixes for a DMA API performance regression
that was introduced in v5.5 for older Tegra devices. Patches 1 and 2
will likely have to be backported to v5.5.
Thierry
Thierry Reding (3):
drm/tegra: Relax IOMMU usage criteria on old Tegra
drm/t
From: Thierry Reding
The DMA direction is only used by the DMA API, so there is no use in
setting it when a buffer object isn't mapped with the DMA API.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/job.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/ho
From: Thierry Reding
This partially reverts the DMA API support that was recently merged
because it was causing performance regressions on older Tegra devices.
Unfortunately, the cache maintenance performed by dma_map_sg() and
dma_unmap_sg() causes performance to drop by a factor of 10.
The righ
Am 04.02.20 um 13:57 schrieb Dan Carpenter:
Hello Christian König,
The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
from Apr 16, 2019, leads to the following static checker warning:
drivers/gpu/drm/ttm/ttm_bo.c:1610 ttm_bo_global_release()
warn: passing freed
On Sun, Feb 02, 2020 at 05:16:35PM +, Chris Wilson wrote:
> The drm_pci_alloc routines have been a thin wrapper around the core dma
> coherent routines. Remove the crutch of a wrapper and the exported
> symbols, marking it for only internal legacy use.
>
> Signed-off-by: Chris Wilson
Since A
On Tue, Feb 04, 2020 at 03:03:43PM +0100, Christian König wrote:
> Am 04.02.20 um 13:57 schrieb Dan Carpenter:
> > Hello Christian König,
> >
> > The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
> > from Apr 16, 2019, leads to the following static checker warning:
> >
> > d
Am 04.02.20 um 15:24 schrieb Dan Carpenter:
On Tue, Feb 04, 2020 at 03:03:43PM +0100, Christian König wrote:
Am 04.02.20 um 13:57 schrieb Dan Carpenter:
Hello Christian König,
The patch bd4264112f93: "drm/ttm: fix re-init of global structures"
from Apr 16, 2019, leads to the following static c
Jobs can be in-flight when the file descriptor is closed (either because
the process did not terminate properly, or because it didn't wait for
all GPU jobs to be finished), and apparently panfrost_job_close() does
not cancel already running jobs. Let's refcount the MMU context object
so it's lifeti
->job_run() can return an ERR_PTR() if somethings fails. Let's
propagate the error returned by panfrost_fence_create() instead of
returning NULL.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
On Mon, Feb 03, 2020 at 10:31:13PM +0100, Mauro Rossi wrote:
> Fixes the following building error:
>
> CC [M] drivers/gpu/drm/drm_edid.o
> ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function
> 'cea_mode_alternate_timings':
> ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2:
On Tue, 4 Feb 2020 15:35:03 +0100
Boris Brezillon wrote:
> Jobs can be in-flight when the file descriptor is closed (either because
> the process did not terminate properly, or because it didn't wait for
> all GPU jobs to be finished), and apparently panfrost_job_close() does
> not cancel alread
> -Original Message-
> From: Ville Syrjälä
> Sent: Tuesday, February 4, 2020 7:02 PM
> To: Shankar, Uma
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; Andres
> Rodriguez
> Subject: Re: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA
> data
> bl
CI didn't like my test-with tag :-/
Test-with: 20200128112549.172135-1-daniel.vet...@ffwll.ch
Daniel Vetter (5):
drm: Complain if drivers still use the ->load callback
drm/fbdev-helper: don't force restores
drm/client: Rename _force to _locked
drm: Push drm_global_mutex locking in drm_ope
This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).
With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open
Kinda time to get this sorted. The locking around this really is not
nice.
Thomas mentioned in his review that the only drivers left unconverted
are radeon and amdgpu.
Cc: Harry Wentland
Cc: Alex Deucher
Reviewed-by: Chris Wilson
Reviewed-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
--
We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity. Historical
aside: When the kernel-wide BKL was removed, it was replaced by
drm_global_mutex within the sco
Plus extend the kerneldoc a bit to explain how this should be used.
With the previous patch to drop the force restore the main user of
this function is not emphasis on the "I hold the internal master lock
already" aspect, so rename the function to match.
Suggested by Noralf.
Cc: Noralf Trønnes
R
Instead check for master status, in case we've raced.
This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mo
On Mon, Feb 03, 2020 at 04:40:40PM -0800, Rob Clark wrote:
> On Mon, Feb 3, 2020 at 4:21 PM John Stultz wrote:
> >
> > On Wed, Jan 22, 2020 at 11:19 PM Sharat Masetty
> > wrote:
> > >
> > > This patch adds support for enabling Graphics Bus Interface(GBIF)
> > > used in multiple A6xx series chipe
Hi Andy,
On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko
wrote:
> Replace with appropriate types.h.
Thanks for your patch!
I have only one very short question: why?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.
Mostly looks good, some comments below:
On Fri, 2020-01-31 at 11:01 +0100, Benjamin Gaignard wrote:
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
> If functions returns are not used anymore make them void.
>
> Signed-off-by: Benjamin Gaignard
> ---
> ve
Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") added a
universal GBIF un-halt into a6xx_start(). This can cause problems for
a630 targets which do not use GBIF and might have access protection
enabled on the region now occupied by the GBIF registers.
But it turns out that we didn't n
+jstultz
On Tue, Feb 4, 2020 at 9:42 AM Jordan Crouse wrote:
>
> Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") added a
> universal GBIF un-halt into a6xx_start(). This can cause problems for
> a630 targets which do not use GBIF and might have access protection
> enabled on the regi
Hi,
On Tue, Feb 4, 2020 at 6:15 AM Harigovindan P wrote:
>
> Updating bindings of dsi and dpu by adding and removing certain
> properties.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v1:
> - Adding "ahb" clock as a required property.
> - Adding "bus", "rot", "lut" as o
On Tue, Feb 04, 2020 at 06:39:34PM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko wrote:
> > Replace with appropriate types.h.
>
> Thanks for your patch!
>
> I have only one very short question: why?
Likewise :-) The patch itself looks fine, but the commit mess
Reviewed-by: Lyude Paul
On Mon, 2020-02-03 at 13:16 +0100, Benjamin Gaignard wrote:
> Check that computed crc value is matching the one encoded in the message.
>
> Signed-off-by: Benjamin Gaignard
> ---
> CC: ly...@redhat.com
> CC: airl...@linux.ie
> CC: jani.nik...@linux.intel.com
> drivers/g
Hi,
On Tue, Feb 4, 2020 at 6:15 AM Harigovindan P wrote:
>
> Add display, DSI hardware DT nodes for sc7180.
>
> Co-developed-by: Kalyan Thota
> Signed-off-by: Kalyan Thota
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v1:
> - Added display DT nodes for sc7180
> Changes in v2:
>
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but
This reverts commit d2a4bb6f8bc8cf2d788adf7e59b5b52fe3ac.
So, turns out that this ended up just breaking things. While many
laptops incorrectly advertise themselves as supporting PWM backlight
controls, they actually will only work with DPCD backlight controls.
Unfortunately, it also seems the
Unfortunately, it turned out that the DPCD is also not a reliable way of
probing for DPCD backlight support as some panels will lie and say they
have DPCD backlight controls when they don't actually.
So, revert back to the old behavior and add a bunch of EDID-based DP
quirks for the panels that we
The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can
According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls dep
Hi Andy,
On Tue, Feb 4, 2020 at 8:30 PM Andy Shevchenko
wrote:
> On Tue, Feb 04, 2020 at 08:26:21PM +0200, Laurent Pinchart wrote:
> > On Tue, Feb 04, 2020 at 06:39:34PM +0100, Geert Uytterhoeven wrote:
> > > On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko wrote:
> > > > Replace with appropriate t
Quoting Alex Deucher (2020-02-03 21:49:48)
> On Sun, Feb 2, 2020 at 12:16 PM Chris Wilson wrote:
> >
> > drm_pci_alloc/drm_pci_free are very thin wrappers around the core dma
> > facilities, and we have no special reason within the drm layer to behave
> > differently. In particular, since
> >
> >
These are deprecated and the drm will soon start warning when drivers still
use them. It was a long and twisty road, but seems to work.
Alex Deucher (14):
drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup
drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs
drm/amdgpu/pm: move debugfs
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for pm.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 9 +---
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for SA (sub allocator).
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
to amdgpu_debugfs_fini. It will be used for other things in
the future.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
3 files changed, 4 insertions(+),
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for fence handling.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 3
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for ttm.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for rings.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 23 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ring
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for gem.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
2 fi
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for firmware.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for register access files.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_device
To handle debugfs setup on non DP MST connectors.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/displa
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for display.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 ++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_d
Into the function that creates the debugfs files rather
than setting them explicitly in the callers.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 +++
drivers/gpu/drm/amd/displa
We've moved the debugfs handling into a centralized place
so we can remove the legacy load an unload callbacks.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 13 +++--
2 files changed, 11 insertions(+),
The core does this for us now.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 1 -
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 1 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/
https://bugzilla.kernel.org/show_bug.cgi?id=203905
Sandor Ecker (esa...@freemail.hu) changed:
What|Removed |Added
CC||esa...@freemail.hu
--
https://bugzilla.kernel.org/show_bug.cgi?id=203905
--- Comment #5 from Sandor Ecker (esa...@freemail.hu) ---
Would it be possible to set max_brightness to 2^16-1 ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dr
On 2020-02-01 03:13, Doug Anderson wrote:
Hi,
On Fri, Jan 31, 2020 at 4:04 AM Sharat Masetty
wrote:
+ adreno_smmu: iommu@504 {
+ compatible = "qcom,sc7180-smmu-v2",
"qcom,smmu-v2";
+ reg = <0 0x0504 0 0x1>;
+
virtio has its own commit fail function. Add the
drm_atomic_helper_fake_vblank() call there.
Fixes: 2a735ad3d211 ("drm/virtio: Remove sending of vblank event")
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
From: Taniya Das
In the cases where the GPU SW requires to use the GX GDSCR add
support for the same.
Signed-off-by: Taniya Das
---
include/dt-bindings/clock/qcom,gpucc-sc7180.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/dt-bindings/clock/qcom,gpucc-sc7180.h
I used this branch qcom/arm64-for-5.6-to-be-rebased as suggested by Matthias.
This patch needs the clock patches and the clock patches have not yet landed, so
please apply the following series and patches in order
a) All patches from
https://patchwork.kernel.org/project/linux-clk/list/?series=203
From: Taniya Das
Most of the time the CPU should not be touching the GX domain on the
GPU
except for a very special use case when the CPU needs to force the GX
headswitch off. Add a dummy enable function for the GX gdsc to simulate
success so that the pm_runtime reference counting is correct
This patch adds the required dt nodes and properties
to enabled A618 GPU.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 102 +++
1 file changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/
Hi
Am 05.02.20 um 07:53 schrieb Gerd Hoffmann:
> virtio has its own commit fail function. Add the
> drm_atomic_helper_fake_vblank() call there.
>
> Fixes: 2a735ad3d211 ("drm/virtio: Remove sending of vblank event")
Thanks for fixing the fallout.
> Signed-off-by: Gerd Hoffmann
Acked-by: Thoma
90 matches
Mail list logo
