Quoting Maarten Lankhorst (2018-10-02 11:51:45)
> Op 23-08-18 om 00:57 schreef Matt Roper:
> > On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> >> Add plane alpha blending support with the different blend modes.
> >> This has been tested on a icl to show the correct results,
> >
On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> These are the approaches which could have been taken to handle
> this scenario -
>
> * Replace vm_insert_page with vmf_insert_page and then write few
>extra lines of code to convert VM_FAULT_CODE to errno which
>makes dri
Now as Amstrad Delta board - the only user of this driver - provides
GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
use the table to locate required GPIO pins.
Declare static variables for storing GPIO descriptors and replace
gpio_ function calls with their gpiod_ equivalents
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 115017 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/video/fbdev/arcfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/
Currently blend mode is set accordingly to pixel format.
Add pixel blend mode property and make that configurable.
Decon hardware doesn't support premultiplied mode,
chose coverage as default.
Tested on TM2 with Exynos 5433 CPU, on top of exynos-drm-next
using modetest.
Signed-off-by: Christoph M
vm_insert_kmem_page is similar to vm_insert_page and will
be used by drivers to map kernel (kmalloc/vmalloc/pages)
allocated memory to user vma.
Going forward, the plan is to restrict future drivers not
to use vm_insert_page ( *it will generate new errno to
VM_FAULT_CODE mapping code for new drive
The decon hardware supports variable plane alpha. Currently planes
are opaque, make this configurable.
Tested on TM2 with Exynos 5433 CPU, on top of exynos-drm-next.
Signed-off-by: Christoph Manszewski
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 30 +++
drivers/g
Hi Souptick,
On Wed, Oct 3, 2018 at 8:55 PM Souptick Joarder wrote:
>
> vm_insert_kmem_page is similar to vm_insert_page and will
> be used by drivers to map kernel (kmalloc/vmalloc/pages)
> allocated memory to user vma.
>
> Going forward, the plan is to restrict future drivers not
> to use vm_in
Hello,
This patch series adds two new configurable properties
to exynos5433_drm_decon.
Patch 1 add window alpha property.
Patch 2 add pixel blend mode property.
Regards,
Chris
Christoph Manszewski (2):
drm/exynos: decon: Make plane alpha configurable
drm/exynos: decon: Make pixel blend mode
On Wed, Oct 03, 2018 at 11:14:45PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > > These are the approaches which could have been taken to handle
> > > this scenario
On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
>
> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
> > >
> > >
> > > Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > > > The variable is now referenced unconditionally,
On Wed, Oct 03, 2018 at 03:24:40PM -0700, Radhakrishna Sripada wrote:
> On Mon, Oct 01, 2018 at 09:23:38AM +0200, Daniel Vetter wrote:
> > On Mon, Sep 24, 2018 at 02:08:14PM -0700, Radhakrishna Sripada wrote:
> > > At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> > > level shift
On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> drm fbdev emulation doesn't support changing the pixel format at all,
> so reject all pixel format changing requests.
For next time around: Please keep the note here why we need this and what
the impact is. Otherwise it's not immed
drm-misc-fixes-2018-10-04:
drm-misc-fixes for v4.19-rc7:
- Fix use-after-free in drm_mode_create_lease_ioctl()
- Fix crash in fbdev error path.
The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)
are available in the Git repos
The mode_config max_width/max_height determines the maximum framebuffer
size the pixel reader can handle. But the values were set thinking they
were determining the maximum screen dimensions.
This patch changes the values to the maximum height/width the CANVAS block
can handle rounded to some cohe
From: Hans Verkuil
The first patch adds new status flags to indicate when a pending
message is aborted because the CEC adapter is unconfigured, and when
a transmit times out (this indicates a driver bug).
The second and third patch fix a minor issue with the adv HDMI receivers:
if the EDID goes
From: Hans Verkuil
When there is no EDID the CEC adapter should be unconfigured as
well. So call cec_phys_addr_invalidate() when this happens.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7842.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ad
From: Hans Verkuil
The TX FIFO has to be cleared if the transmit failed due to e.g.
a NACK condition, otherwise the hardware will keep trying to
transmit the message.
An attempt was made to do this, but it was done after the call to
cec_transmit_done, which can cause a race condition since the c
From: Hans Verkuil
When there is no EDID the CEC adapter should be unconfigured as
well. So call cec_phys_addr_invalidate() when this happens.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7604.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ad
From: Hans Verkuil
If the HDMI cable is disconnected or the CEC adapter is manually
unconfigured, then all pending transmits and wait-for-replies are
aborted. Signal this with new status bits (CEC_RX/TX_STATUS_ABORTED).
If due to (usually) a driver bug a transmit never ends (i.e. the
transmit_do
From: Hans Verkuil
The HDMI_CEC_DBG_3 register does have a retransmit count, but you
can't write to it, those bits are read-only.
So drop the attempt to set the retransmit count, since it doesn't
work.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 3 ---
1 file cha
This patch series starts off with a bug fixes in devfreq code, followed by
refactoring the devfreq code needed for supporting different chipsets, and
ends with adding devfreq support for A6xx.
v2, v3: Addressed review comments from Jordan Crouse.
v4: Patches raised against Rob's msm-next. Fixed a
Add a simple function to read 64 registers in the GMU domain
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index ad3bc5a..f3463
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if needed.
The driver code then tries to set this new frequency on the GPU by
sending an Out Of Band(OOB) request t
Devfreq turns on and starts recommending power level as soon as it is
initialized. The GPU is still not powered on by the time the devfreq
init happens and this leads to problems on GPU's where register access
is needed to get/set power levels. So we start suspended and only restart
devfreq when GP
The devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counteres for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be targ
On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
> The mode_config max_width/max_height determines the maximum framebuffer
> size the pixel reader can handle. But the values were set thinking they
> were determining the maximum screen dimensions.
>
> This patch changes the values to
On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> drm fbdev emulation doesn't support changing the pixel format at all,
> so reject all pixel format changing requests.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v1->v2:
> * Reject all pixel fo
range-diff is awesome, but the interface is a bit silly. Add a bunch
of shortcuts, inspired by what git diff does.
Signed-off-by: Daniel Vetter
---
dim | 13 +
dim.rst | 8
2 files changed, 21 insertions(+)
diff --git a/dim b/dim
index 12c80e2051b6..c4663aca6b5c 100755
On Thu, Oct 04, 2018 at 01:34:22PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> > drm fbdev emulation doesn't support changing the pixel format at all,
> > so reject all pixel format changing requests.
> >
> > Cc: sta...@vger.kernel.org
> > Signe
range-diff is awesome, but the interface is a bit silly. Add a bunch
of shortcuts, inspired by what git diff does.
v2: Add it to the developer commmands list. With this dim range-diff
is useable on any git repo, not just a dim managed one.
Signed-off-by: Daniel Vetter
---
dim | 14 +
On Thu, Oct 04, 2018 at 12:49:38PM +0200, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 01:34:22PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> > > drm fbdev emulation doesn't support changing the pixel format at all,
> > > so reject all pixel
https://bugs.freedesktop.org/show_bug.cgi?id=108130
Petri Latvala changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, 2018-10-03 at 08:07 +, Alexandru-Cosmin Gheorghe wrote:
> On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > > Hi,
> > >
> > > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy
>
On Thu, Oct 04, 2018 at 12:04:57PM +, Lisovskiy, Stanislav wrote:
> On Wed, 2018-10-03 at 08:07 +, Alexandru-Cosmin Gheorghe wrote:
> > On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> > > On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > > > Hi,
On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > > > These are the
Set shared_max to the number of shared fences right before we release
the lock.
This way every attempt to add a shared fence without previously
reserving a slot will cause an error.
Signed-off-by: Christian König
---
include/linux/reservation.h | 5 +
1 file changed, 5 insertions(+)
diff -
No need for that any more. Just replace the list when there isn't enough
room any more for the additional fence.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 178 ++
include/linux/reservation.h | 4 -
2 files changed, 58 insertion
Let's support simultaneous submissions to multiple engines.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c| 13 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/a
Let's support simultaneous submissions to multiple engines.
v2: rename the field to num_shared and fix up all users
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/
This allows us to drop the extra reserve in TTM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers
The driver is now responsible to allocate enough shared slots.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 83b465
It is perfectly possible that the BO list is created before the BO is
exported. While at it cleanup setting shared to one instead of true.
v2: add comment and simplify logic
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_
And drop the now superflous extra reservations.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 ++-
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
On Wed, 19 Sep 2018 at 10:31, Chunming Zhou wrote:
>
> Signed-off-by: Chunming Zhou
> ---
> include/drm/amdgpu_drm.h | 10 ++
> 1 file changed, 10 insertions(+)
>
For this and 1/5 - see include/drm/README and git log for examples how
files in include/drm should be updated.
I'll pull merg
[adding etnaviv@ for bigger exposure]
Hi Guido,
On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote:
>
> This makes it simple to test if all cache types are mappable.
>
> Signed-off-by: Guido Günther
> ---
> Prompted by
>
> https://lists.freedesktop.org/archives/etnaviv/2018-September/001946.ht
On Wed, 5 Sep 2018 at 19:01, Stefan Agner wrote:
>
> Use libutil to lookup connector type names and state. This also
> makes sure that the latest connector type addition "DPI" gets
> printed correctly.
>
> Signed-off-by: Stefan Agner
For the series:
Reviewed-by: Emil Velikov
Will do some sanity
Hi Dave,
Here comes -fixes for drm-next.
One compiler warning fix and adding back a removed max stride
check, nothing end user visible.
Regards, Joonas
PS. Travelling next week, so I'll skip PR unless there's
something big.
---
drm-intel-next-fixes-2018-10-04:
Compiler warning fix and adding
Am Donnerstag, den 04.10.2018, 14:20 +0100 schrieb Emil Velikov:
> [adding etnaviv@ for bigger exposure]
>
> Hi Guido,
>
> > On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote:
> >
> > This makes it simple to test if all cache types are mappable.
> >
> > > > Signed-off-by: Guido Günther
> > --
The GPU hardware fences and the job out-fences are on different timelines
so it's wrong to compare them. Fix this by only looking at the out-fence.
Fixes: 2c83a726d6fb (drm/etnaviv: bring back progress check in job
timeout handler)
Signed-off-by: Lucas Stach
---
drivers/gpu/
On Thu, 20 Sep 2018 at 13:25, Eric Engestrom wrote:
>
> On Wednesday, 2018-09-19 23:05:48 -0700, Lucas De Marchi wrote:
> > Signed-off-by: Lucas De Marchi
>
> Reviewed-by: Eric Engestrom
>
> But it'd be good to have a confirmation from Rob that it actually works:
> Cc: Rob Herring
>
Yes it does
On Sat, 22 Sep 2018 at 14:28, Ezequiel Garcia wrote:
>
> This is the DRM driver for all Allwinner (sunxi) platforms.
>
> Signed-off-by: Ezequiel Garcia
Reviewed-by: Emil Velikov
Will push this in a moment.
Thanks
Emil
___
dri-devel mailing list
dri-d
On Mon, 1 Oct 2018 at 16:09, Ayan Kumar Halder wrote:
>
> Generated using make headers_install from the drm-next
> tree - git://anongit.freedesktop.org/drm/drm
> branch - drm-next
> commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
>
> The changes were as follows :-
>
> core: (drm.h, drm_fourcc.
On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote:
>
> Hi, Emil,
>
> On 09/05/2018 03:53 PM, Emil Velikov wrote:
> > On 5 September 2018 at 14:20, Thomas Hellstrom
> > wrote:
> >
> >>> In that case, please give me 24h to do a libdrm release before pushing.
> >>> I had to push some workarounds
Den 04.10.2018 09.48, skrev Daniel Vetter:
On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
Den 02.10.2018 22.58, skrev Arnd Bergmann:
The variable is now referenced unco
On Thu, Oct 04, 2018 at 03:11:43PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to se
Hi,
On Thu, Oct 04, 2018 at 03:43:11PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 04.10.2018, 14:20 +0100 schrieb Emil Velikov:
> > [adding etnaviv@ for bigger exposure]
> >
> > Hi Guido,
> >
> > > On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote:
> > >
> > > This makes it simple to test i
On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
> Den 04.10.2018 09.48, skrev Daniel Vetter:
> > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
> >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> >>> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
>
> D
On 04/10/2018 12:09, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
>> The mode_config max_width/max_height determines the maximum framebuffer
>> size the pixel reader can handle. But the values were set thinking they
>> were determining the maximum screen di
This release adds a fallback for realpath() which was blocked by the
web-browser sand-boxing. While the browsers are fixed-up they seem to have
little incentive to roll bugfix releases :-\
-Emil
Ayan Kumar Halder (1):
libdrm: headers: Sync with drm-next
Christian König (4):
tests/amd
Hi Dave,
Just two small fixes for 4.19:
- Fix an ordering issue in DC with respect to atomic flips that could result
in a crash
- Fix incorrect use of process->mm in KFD
The following changes since commit d8938c981f58ee344687b7910a611ac345960045:
Merge branch 'drm-tda9950-fixes' of git://git
https://bugs.freedesktop.org/show_bug.cgi?id=97810
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=91831
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Assignee|xorg-driver-...@list
Hi Christian,
On Thu, Sep 27, 2018 at 12:55 AM Nayan Deshmukh
wrote:
>
> Hi Christian,
>
>
> On Wed, Sep 26, 2018, 10:13 AM Christian König
> wrote:
>>
>> Am 26.09.2018 um 09:39 schrieb Lucas Stach:
>> > Hi Nayan,
>> >
>> > Am Mittwoch, den 26.09.2018, 02:09 +0900 schrieb Nayan Deshmukh:
>> >>
https://bugs.freedesktop.org/show_bug.cgi?id=104531
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Assignee|xorg-driver-...@lis
https://bugs.freedesktop.org/show_bug.cgi?id=105744
Michel Dänzer changed:
What|Removed |Added
Product|xorg|DRI
Component|Driver/AMDgpu
https://bugs.freedesktop.org/show_bug.cgi?id=103791
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org
Hi, Emil,
On 10/04/2018 04:12 PM, Emil Velikov wrote:
> On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote:
>> Hi, Emil,
>>
>> On 09/05/2018 03:53 PM, Emil Velikov wrote:
>>> On 5 September 2018 at 14:20, Thomas Hellstrom
>>> wrote:
>>>
> In that case, please give me 24h to do a libdrm re
On Thu, Oct 04, 2018 at 02:55:42PM +1000, Dave Airlie wrote:
> Hi Greg,
>
> Nothing too much happening at this point,
>
> 3 i915 fixes:
> compressed error handling zlib fix
> compiler warning cleanup
> and a minor code cleanup
>
> 2 tda9950:
> Two fixes for the HDMI CEC
>
> 1 exynos:
> A fix re
Hi Daniel,
On Wednesday, 3 October 2018 12:08:38 EEST Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> > On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > > It's the default. The exported version was kinda a transition state,
> > > before w
On Wed, Oct 03, 2018 at 06:12:42PM +0200, Daniel Vetter wrote:
> On Wed, Oct 03, 2018 at 05:50:17PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When we decide that a plane is attached to the wrong pipe we try
> > to turn off said plane. However we are passing around the crtc we
>
Am 04.10.2018 um 18:32 schrieb Nayan Deshmukh:
Hi Christian,
On Thu, Sep 27, 2018 at 12:55 AM Nayan Deshmukh
wrote:
Hi Christian,
On Wed, Sep 26, 2018, 10:13 AM Christian König
wrote:
Am 26.09.2018 um 09:39 schrieb Lucas Stach:
Hi Nayan,
Am Mittwoch, den 26.09.2018, 02:09 +0900 schrieb
https://bugs.freedesktop.org/show_bug.cgi?id=106374
--- Comment #4 from Hugo Sánchez ---
I am having the same issue. That is a big problem cause GPU cannot reach its
max power. A RX Vega 64 for example can consume around 300w with OC and the
220w is causing frame drops in the case of games.
--
From: Colin Ian King
The return statement is redundant as there is a return statement
immediately before it so we have dead code that can be removed.
Also remove the unused declaration of ret.
Detected by CoverityScan, CID#1473793 ("Structurally dead code")
Signed-off-by: Colin Ian King
---
d
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #8 from quirin.blae...@freenet.de ---
4.18.12
Bug still present, removing 93b100ddda3be284be160e9ccba28c7f8f21ab73 solves
this problem for now.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=201275
quirin.blae...@freenet.de changed:
What|Removed |Added
Summary|Power consumption RX460 |Power consumption RX560
On Thu, Oct 4, 2018 at 5:05 PM Neil Armstrong wrote:
>
> On 04/10/2018 12:09, Daniel Vetter wrote:
> > On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
> >> The mode_config max_width/max_height determines the maximum framebuffer
> >> size the pixel reader can handle. But the values
On Tue, Oct 02, 2018 at 03:35:10PM +0200, Daniel Vetter wrote:
> It's the default. The exported version was kinda a transition state,
> before we made this the default.
>
> To stop new atomic drivers from using it (instead of just relying on
> the default) let's unexport it.
>
> Signed-off-by: Da
If you want DT bindings reviewed, you have to cc the DT list. (Or wait
for Sean Paul to ping me on IRC)
On Fri, Sep 28, 2018 at 7:39 PM Abhinav Kumar wrote:
>
> Add the device tree bindings for Truly NT35597 panel driver. This panel
> driver supports both single DSI and dual DSI.
By driver, you
On Thu, Oct 04, 2018 at 02:33:24PM -0400, Sean Paul wrote:
> On Tue, Oct 02, 2018 at 03:35:10PM +0200, Daniel Vetter wrote:
> > It's the default. The exported version was kinda a transition state,
> > before we made this the default.
> >
> > To stop new atomic drivers from using it (instead of jus
On Thu, Oct 04, 2018 at 05:04:21PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
> > Den 04.10.2018 09.48, skrev Daniel Vetter:
> > > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
> > >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> > >>> On Wed
Hi Rob
Thanks for the review. Will copy the DT list in the next patchset.
Some comments inline.
Thanks
Abhinav
On 2018-10-04 12:01, Rob Herring wrote:
If you want DT bindings reviewed, you have to cc the DT list. (Or wait
for Sean Paul to ping me on IRC)
On Fri, Sep 28, 2018 at 7:39 PM Abhi
Hi,
On Wed, Oct 03, 2018 at 04:24:57PM +0200, Giulio Benetti wrote:
> At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
> has been used, but that macro doesn't check if tcon->panel pointer is
> null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
>
> Remo
On Wed, Oct 03, 2018 at 04:24:58PM +0200, Giulio Benetti wrote:
> If using tcon with VGA,
We don't have support for VGA at the moment. Or are you talking about
using a VGA bridge?
> tcon->panel will be null(0), this will cause segmentation fault when
> trying to dereference tcon->panel->connector
On Tue, Oct 02, 2018 at 04:36:31PM +, Thomas Hellstrom wrote:
> On 10/02/2018 05:15 PM, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 03:35:12PM +0200, Daniel Vetter wrote:
> >> The core _does_ the call to drm_atomic_commit for you. That's pretty
> >> much the entire point of having the fanc
Good catch.
Reviewed-by: Sinclair Yeh
On Thu, Oct 04, 2018 at 06:49:53PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The return statement is redundant as there is a return statement
> immediately before it so we have dead code that can be removed.
> Also remove the unused declaration o
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
I don't think this is a bug. The problem is, prior to that patch, the display
component was requesting minimum clocks that were 10x too low. This saved
power, but led to display proble
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
v2: amdgpu uses ->best_encoder internally, give it a local copy. It
might be a good idea to
The core _does_ the call to drm_atomic_commit for you. That's pretty
much the entire point of having the fancy new atomic_set/get_prop
callbacks.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
1 file c
It's the default. The exported version was kinda a transition state,
before we made this the default.
To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.
v2: rename the default implementation to a more fitting name and add a
comment (Laurent)
Sign
These do absolutely nothing for atomic drivers.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 --
1 file changed, 2 deletions(
The idea behind allowing drivers to override legacy ioctls (instead of
using the generic implementations unconditionally) is to handle bugs
in old driver-specific userspace. Like e.g. vmw_kms_set_config does,
to work around some vmwgfx userspace not clearing its ioctl structs
properly.
But you can
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
Signed-off-by:
Hi all,
Resend mostly unchanged, except a few patches tacked on a the end. Main
goal here is to get intel-gfx-ci to approve this, since last time around
patchwork didn't parse what I've done :-)
Still a bunch of unreviewed stuff, so feedback highly welcome.
Cheers, Daniel
Daniel Vetter (20):
Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
around in.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
We already have a separate overview doc for this, makes sense to
untangle it from the overall atomic helpers.
v2: Rebase
v3: Rebase more.
Acked-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 19 +-
drivers/gpu/drm/Makefile |
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
The sti cleanup code seems supremely confused:
- In the l
These do absolutely nothing for atomic drivers.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 965
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
v2: Rebase.
Reviewed-by: Ville Syrjälä
Acked-by: Eric A
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
1 - 100 of 153 matches
Mail list logo
