https://bugs.freedesktop.org/show_bug.cgi?id=110823
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Icenowy Zheng
The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
for portable devices. This driver adds initial support for RGB to eDP
mode, without HPD and interrupts.
This is a configuration usually seen in eDP applications.
Signed-off-by: Icenowy Zheng
The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.
Add a binding document for it.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Rob Herring
Signed-off-by: Torsten Duwe
Reviewed-by: Laurent Pinchart
---
From: Icenowy Zheng
Some code can be shared within different DP bridges by Analogix.
Extract them to analogix_dp.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Signed-off-by: Torsten Duwe
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/analogix/Makefile |
From: Icenowy Zheng
As ANA78xx chips are designed and produced by Analogix Semiconductor,
Inc, move their driver codes into analogix subdirectory.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Laurent Pinchart
Signed-off-by: Torsten Duwe
Reviewed-by: Andrzej
From: Icenowy Zheng
Some definitions currently in analogix-anx78xx.h are not restricted to
the ANX78xx series, but also applicable to other DisplayPort
transmitters by Analogix.
Split out them to dedicated headers, and make analogix-anx78xx.h include
them.
Signed-off-by: Icenowy Zheng
Add bit definitions required for the anx6345 and add a
sanity check in anx_dp_aux_transfer.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Signed-off-by: Torsten Duwe
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus.
Enable it in the device tree, and enable the display engine, video mixer
and tcon0 as well.
Signed-off-by: Icenowy Zheng
Signed-off-by: Torsten Duwe
---
https://bugs.freedesktop.org/show_bug.cgi?id=112226
Bug ID: 112226
Summary: [HadesCanyon] GPU hangs don't anymore recover
(although kernel still claims that they do)
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=112226
Eero Tamminen changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
On 2019/11/7 上午6:58, Alex Williamson wrote:
On Wed, 6 Nov 2019 14:50:30 -0800
Randy Dunlap wrote:
On 11/5/19 11:05 PM, Jason Wang wrote:
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..13a2443e18e0 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,16 @@
https://bugs.freedesktop.org/show_bug.cgi?id=112226
--- Comment #4 from Eero Tamminen ---
Created attachment 145909
--> https://bugs.freedesktop.org/attachment.cgi?id=145909=edit
Xorg log
X dies to ConfigureWindow() -> miResizeWindow() -> miCopyRegion() ->
glamor_create_pixmap() ->
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
---
MAINTAINERS | 1 +
drivers/vfio/mdev/mdev_core.c| 21 +
drivers/vfio/mdev/mdev_private.h | 2 +
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only
Currently, except for the create and remove, the rest of
mdev_parent_ops is designed for vfio-mdev driver only and may not help
for kernel mdev driver. With the help of class id, this patch
introduces device specific callbacks inside mdev_device
structure. This allows different set of callback to
On Thu, 7 Nov 2019 23:11:06 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside
On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig wrote:
>
> Hardware only natively supports BGR UBWC.
> UBWC support for RGB can be had by pretending
> that the buffer is BGR.
Just to expand, this aligns with how we handle RGB component order in
mesa for tiled or tiled+ubwc. If uncompressed
Hi Daniel,
On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
> >
> > Hi Daniel,
> >
> > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > > Hi Andrzej,
> > > Thanks for taking this on! It's looking better than v1
There is no need for brackets for a single line inside the 'if' block,
so remove the unneeded brackets.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix typo in commit log
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #4 from har...@gmx.de ---
Yes, your patch works and has the same effect, apparently.
What confused me and the reason why i prefered to leave the
vega10_update_avfs() call before the flag modification, was the code inside
Rob Clark writes:
> On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig wrote:
>>
>> Hardware only natively supports BGR UBWC.
>> UBWC support for RGB can be had by pretending
>> that the buffer is BGR.
>
> Just to expand, this aligns with how we handle RGB component order in
> mesa for tiled
On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig wrote:
> >>
> >> Hardware only natively supports BGR UBWC.
> >> UBWC support for RGB can be had by pretending
> >> that the buffer is BGR.
> >
> > Just to
> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote:
>
> Hi John
>
> Am 07.11.19 um 14:12 schrieb John Donnelly:
>> Hi Thomas ; Thank you for reaching out.
>>
>> See inline:
>>
>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote:
>>>
>>> Hi John,
>>>
>>> apparently the vgaarb
https://bugs.freedesktop.org/show_bug.cgi?id=112226
--- Comment #5 from Alex Deucher ---
(In reply to Eero Tamminen from comment #3)
>
> AFAIK reset should affect only the context running in the GPU when it was
> reseted, not the others [1], and in this case the problematic client should
> be
On Wed, 6 Nov 2019 at 14:24, Chris Wilson wrote:
>
> As drm now exports a method to create an anonymous struct file around a
> drm_device for internal use, make use of it to avoid our horrible hacks.
>
> Signed-off-by: Chris Wilson
As per your eventual plan, fwiw,
Reviewed-by: Matthew Auld
On Thu, Nov 07, 2019 at 04:24:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Annoyingly __drm_atomic_helper_crtc_reset() does two
> totally separate things:
> a) reset the state to defaults values
> b) assign the crtc->state pointer
>
> I just want a) without the b) so let's split
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #8 from Matt Coffin ---
(In reply to Matt Coffin from comment #7)
> This patch should take care of the problem by treating navi10's TDPODLimit
> the same as vega20 does: https://patchwork.freedesktop.org/series/69090/
Sorry for the
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #9 from tempel.jul...@gmail.com ---
Thank you, I'll try it out at some point.
I also got an email by fin4478 with the suggestion to try out
amdgpu.ppfeaturemask=0xfffd7fff.
--
You are receiving this mail because:
You are the
On Thu, Nov 7, 2019 at 3:10 AM Brian Masney wrote:
>
> On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > wrote:
> > >
> > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
> > > >
> > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
Hi Daniel,
On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> Hi Andrzej,
> Thanks for taking this on! It's looking better than v1 for sure. A few
> things below:
>
> On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> > +bool drm_afbc_check_offset(struct drm_device
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #7 from Matt Coffin ---
This patch should take care of the problem by treating navi10's TDPODLimit the
same as vega20 does: https://patchwork.freedesktop.org/series/69090/
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #133 from Wilko Bartels ---
(In reply to haro41 from comment #132)
> (In reply to Wilko Bartels from comment #131)
> > Thank you. I already tried exactly that. And the unit unable to autostart
> > (permission denied). Only manual
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 285821
--> https://bugzilla.kernel.org/attachment.cgi?id=285821=edit
possible fix
Does this patch work? I think it would be better to move the change above the
Hi Fabrizio,
thanks for the patch.
On Mon, Nov 04, 2019 at 04:58:00PM +, Fabrizio Castro wrote:
> lvds-encoder.c implementation is also suitable for LVDS decoders,
> not just LVDS encoders.
> Instead of creating a new driver for addressing support for
> transparent LVDS decoders, repurpose
There is no need for brackets when for a single line inside
the 'if' block, so remove the unneeded brackets.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
Quoting Daniel Vetter (2019-11-07 08:39:24)
> On Wed, Nov 06, 2019 at 02:24:30PM +, Chris Wilson wrote:
> > As drm now exports a method to create an anonymous struct file around a
> > drm_device for internal use, make use of it to avoid our horrible hacks.
> >
> > Signed-off-by: Chris Wilson
On Thu, Nov 07, 2019 at 05:17:00PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-11-07 08:39:24)
> > On Wed, Nov 06, 2019 at 02:24:30PM +, Chris Wilson wrote:
> > > As drm now exports a method to create an anonymous struct file around a
> > > drm_device for internal use, make use of
On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
>
> Hi Daniel,
>
> On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > Hi Andrzej,
> > Thanks for taking this on! It's looking better than v1 for sure. A few
> > things below:
> >
> > On Mon, 2019-11-04 at 23:12 +0100, Andrzej
On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This thing can get called several thousand times per LUT
> so seems like we want to inline it to:
> - avoid the function call overhead
> - allow constant folding
>
> A quick synthetic test (w/o any hardware
Hello Fabrizio,
On Thu, Aug 29, 2019 at 02:38:06PM +, Fabrizio Castro wrote:
> On 29 August 2019 15:03 Rob Herring wrote:
> > On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro wrote:
> >>
> >> Dual-LVDS connections need markers in the DT, this patch adds
> >> some common documentation to be
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:36PM +0100, Fabrizio Castro wrote:
> Add binding for the idk-2121wr LVDS panel from Advantech.
>
> Some panel-specific documentation can be found here:
>
On 28.10.19 21:10, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs
On Thu, Nov 7, 2019 at 10:21 AM Daniel Vetter wrote:
>
> On Thu, Nov 7, 2019 at 10:08 AM Patrik Jakobsson
> wrote:
> >
> > On Thu, Nov 7, 2019 at 9:31 AM Daniel Vetter wrote:
> > >
> > > On Wed, Nov 06, 2019 at 04:24:59PM +0100, Patrik Jakobsson wrote:
> > > > On Wed, Nov 6, 2019 at 10:44 AM
On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
> Replace the use of the dev_err macro with the DRM_DEV_ERROR
> DRM helper macro.
The commit message should show the reason _why_ you are doing
this instead of just stating that you are doing this.
It's not that dev_err is uncommon in
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #132 from har...@gmx.de ---
(In reply to Wilko Bartels from comment #131)
> Thank you. I already tried exactly that. And the unit unable to autostart
> (permission denied). Only manual systemctl start works. Dont know why.
If you
Hi Noralf
Am 06.11.19 um 12:48 schrieb Noralf Trønnes:
>
>
> Den 06.11.2019 11.47, skrev Thomas Zimmermann:
>> Simply removes all the obsolete GEM code from udl. No functional
>> changes.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/udl/Makefile | 2 +-
>>
Udl's GEM code and the generic SHMEM are almost identical. Replace
the former with SHMEM. The dmabuf support in udl is being replaced
with generic GEM PRIME functions.
The main difference is in the caching flags for mmap pages. By
default, SHMEM always sets (uncached) write combining. In udl's
In preparation of a switch to SHMEM, udl now allocates its GEM
objects via struct drm_driver.gem_create_object. No functional
changes are made.
For SHMEM GEM objects, udl will require the use of a special mmap
function, which we set though the create-object function.
Signed-off-by: Thomas
Udl's GEM implementation is mostly SHMEM and we should attempt to
replace it with the latter.
Patches #1 and #2 update udl to simplify the conversion. In patch #3
the udl code is being replaced by SHMEM. The GEM object's mmap() and
free_object() functions are wrappers around their SHMEM
Simply removes all the obsolete GEM code from udl. No functional
changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/udl/Makefile | 2 +-
drivers/gpu/drm/udl/udl_dmabuf.c | 254 ---
drivers/gpu/drm/udl/udl_drv.h| 29
The flags field in struct udl_gem controls mapping parameters: cached
access for local buffers, write-combined access for imported buffers.
We can drop the field and distinguish both cases by testing whether
struct drm_gem_object.import_attach is NULL.
Signed-off-by: Thomas Zimmermann
Acked-by:
Le mar. 22 oct. 2019 à 10:37, Daniel Vetter a écrit :
>
> On Tue, Oct 08, 2019 at 02:42:54PM +0200, Benjamin Gaignard wrote:
> > Few for_each macro set variables that are never used later which led
> > to generate unused-but-set-variable warnings.
> > Add (void)(foo) inside the macros to remove
On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to
2019. 11. 07. 16:10 keltezéssel, Böszörményi Zoltán írta:
what's the trick to actually enable the UDL device?
With 5.3.8, 5.3.9 or 5.4-rc6 + drm-next and this patchset, I get this:
[long messages]
I didn't mention that the system is 32-bit, using a PAE kernel.
Is it a problem for swiotlb?
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #41 from Robert ---
(In reply to Shmerl from comment #39)
> With kernel 5.4-rc6 I'm now seeing such errors once in 20 minutes or so:
>
I don't see it that often but I also getting it from time to time. I don't use
any patches.
Hi Linus,
Weekly fixes for drm, summary below, amdgpu has a few but they are
pretty scattered fixes, the fbdev one is a build regression fix that
we didn't want to risk leaving out, otherwise a couple of i915, one
radeon and a core atomic fix.
Dave.
The following changes since commit
Hi Böszörményi
Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán:
> Hi,
>
> 2019. 11. 07. 10:43 keltezéssel, Thomas Zimmermann írta:
>> Udl's GEM implementation is mostly SHMEM and we should attempt to
>> replace it with the latter.
>>
>> Patches #1 and #2 update udl to simplify the conversion. In
Hi John
Am 07.11.19 um 23:14 schrieb John Donnelly:
>
>
>> On Nov 7, 2019, at 10:13 AM, John Donnelly
>> wrote:
>>
>>
>>
>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote:
>>>
>>> Hi John
>>>
>>> Am 07.11.19 um 14:12 schrieb John Donnelly:
Hi Thomas ; Thank you for reaching out.
On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
This sample driver creates mdev device that simulate virtio net device
over
On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 08:43:29PM +0800, Jason Wang wrote:
On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
On Wed, Nov 06, 2019 at
On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 08:47:06PM +0800, Jason Wang wrote:
On 2019/11/7 下午8:43, Jason Wang wrote:
On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
On 2019/11/7 下午5:08, Michael S.
Hi Dave & Daniel,
A quiet start. Hopefully stays that way :)
RCU tracking fix and suspend GEM_BUG_ON fix with dependencies.
Regards, Joonas
***
drm-intel-next-fixes-2019-11-07:
One RCU fix and fix for suspend GEM_BUG_ON (with dependencies).
The following changes since commit
From: Ville Syrjälä
Only load the CGM CSC based on the cgm_mode bit like we
do with the gamma/degamma LUTs. And make the function
naming and arguments consistent as well.
TODO: the code to convert the coefficients look totally
bogus. IIRC CHV uses two's complement format but the code
certainly
From: Ville Syrjälä
Some polishings and at least one minor fix for the gamma stuff.
Ville Syrjälä (12):
drm: Inline drm_color_lut_extract()
drm/i915: Polish CHV .load_luts() a bit
drm/i915: Polish CHV CGM CSC loading
drm/i915: Add i9xx_lut_8()
drm/i915: Clean up
Hello,
On Tue, Nov 05, 2019 at 04:08:22PM -0800, Brian Welty wrote:
> I was more interested in hearing your thoughts on whether you like
> the approach to have a set of controls that are consistent with
> some subset of the existing CPU/MEM ones. Any feedback on this?
> Didn't really mean to
On Mon, Nov 04, 2019 at 04:42:49PM +0800, allen wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First: read detailed timing
Hi Laurent,
On Wed, Nov 06, 2019 at 02:56:53PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Nov 06, 2019 at 02:52:25PM +0200, Laurent Pinchart wrote:
> > On Wed, Nov 06, 2019 at 11:46:28AM +0100, Jacopo Mondi wrote:
> > > On Wed, Nov 06, 2019 at 12:02:05PM +0200, Laurent Pinchart
Named 'err_verbosity', currently with only 1 active bit in that
replicates the existing level - print error events once per flip.
Reviewed-by: James Qian Wang (Arm Technology China)
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 4
Hi everyone,
Sending out a v2 of the series since I had missed out a couple of issues
checkpatch caught.
Changes since v1 [https://patchwork.freedesktop.org/series/68325/]:
- Fixed a couple of checkpatch issues in 2/5 and 5/5
v1's cover letter:
This is a smallish series that tries to remove
It's possible to get multiple events in a single frame/flip, so add an
option to print them all.
Reviewed-by: James Qian Wang (Arm Technology China)
Signed-off-by: Mihail Atanassov
---
v2: Clean up continuation line warning from checkpatch.
drivers/gpu/drm/arm/display/komeda/komeda_dev.h
Extra detail (normally off) almost never hurts.
Reviewed-by: James Qian Wang (Arm Technology China)
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 11 +++
drivers/gpu/drm/arm/display/komeda/komeda_event.c | 4
2 files changed, 15
It's potentially useful information when diagnosing error/warn IRQs, so
dump it to dmesg with a drm_info_printer. Hide this extra debug dumping
behind another komeda_dev->err_verbosity bit.
Note that there's not much sense in dumping it for INFO events,
since the VSYNC event will swamp the log.
Now that there's a debugfs node to control the same, remove the
config option.
Reviewed-by: James Qian Wang (Arm Technology China)
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/Kconfig | 6 --
drivers/gpu/drm/arm/display/komeda/Makefile | 5 ++---
From: Christian König
That is needed by at least a cleanup in radeon.
v2: also export ttm_bo_vm_access
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 8 +---
include/drm/ttm/ttm_bo_api.h| 6 ++
2 files changed, 11 insertions(+), 3
From: Christian König
Finally clean up the VMA setup for radeon now that TTM exports the
necessary functions.
No functional change, but only compile tested.
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/radeon/radeon_ttm.c | 29 ++---
1
Hi Jacopo,
On Thu, Nov 07, 2019 at 12:13:35PM +0100, Jacopo Mondi wrote:
> On Wed, Nov 06, 2019 at 02:56:53PM +0200, Laurent Pinchart wrote:
> > On Wed, Nov 06, 2019 at 02:52:25PM +0200, Laurent Pinchart wrote:
> >> On Wed, Nov 06, 2019 at 11:46:28AM +0100, Jacopo Mondi wrote:
> >>> On Wed, Nov
https://bugs.freedesktop.org/show_bug.cgi?id=112221
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Thu, Nov 7, 2019 at 7:03 AM Christian König
wrote:
>
> Hey Alex,
>
> any objections that I merge those two patches through drm-misc-next?
>
> It's a cleanup I wanted to do for years and Thomas finally fixed up TTM
> for this.
Fine with me. Series is:
Acked-by: Alex Deucher
>
> Cheers,
>
https://bugs.freedesktop.org/show_bug.cgi?id=112221
--- Comment #2 from Kai Groner ---
With the 5.4-rc6 kernel I was able to run a suspend/resume cycle 50 times
without anything breaking.
--
You are receiving this mail because:
You are the assignee for the
On Thu, Nov 07, 2019 at 09:40:09PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2019 at 08:47:06PM +0800, Jason Wang wrote:
> > > On 2019/11/7 下午8:43, Jason Wang wrote:
> > > > On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > > > > On Thu, Nov
On Wed, Nov 06, 2019 at 04:21:31PM +0100, Maxime Ripard wrote:
>
> Please resend the whole series rebased on top of either linux-next or
> drm-misc-next.
Here it is. Applies cleanly to both, modulo those patches already in.
Torsten
---
ANX6345 LVTTL->eDP video bridge, driver with
On Thu, Nov 07, 2019 at 09:32:29PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2019 at 08:43:29PM +0800, Jason Wang wrote:
> > > On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > > > On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=112226
--- Comment #1 from Alex Deucher ---
Please attach your dmesg output and xorg log is using X. Please note that
after a GPU reset, in most cases you need to restart your desktop environment
because no desktop environments properly handle the
On Thu, Nov 7, 2019 at 5:06 AM H. Nikolaus Schaller wrote:
>
> The Imagination PVR/SGX GPU is part of several SoC from
> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo
> and others.
>
> With this binding, we describe how the SGX processor is
> interfaced to the SoC (registers,
From: Ville Syrjälä
We have a nice little helper to compute a single LUT entry
for everything except the 8bpc legacy gamma mode. Let's
complete the set.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 12
1 file changed, 8 insertions(+), 4
From: Ville Syrjälä
PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can
represent a value of 1.0 when the maximum we can store in the
software LUT is 0.. Clamp the value so that it gets
saturated to the max the uapi supports.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.
From: Ville Syrjälä
To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 41 ++
1
From: Ville Syrjälä
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 4 ++--
1 file changed, 2
From: Ville Syrjälä
Split i9xx_load_luts_internal() into neat gmch vs. ilk+ chunks.
Avoids at least one branch in the inner loop, and makes life
a bit less confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 98 +-
1 file changed, 57
From: Ville Syrjälä
Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 128 ++---
1 file
From: Ville Syrjälä
We're talking about LUT contents here so let's call the thing
'lut' rather than 'blob_data'. This is the name the load_lut()
code used before already.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 66 +++---
1 file changed,
From: Ville Syrjälä
This thing can get called several thousand times per LUT
so seems like we want to inline it to:
- avoid the function call overhead
- allow constant folding
A quick synthetic test (w/o any hardware interaction) with
a ridiculously large LUT size shows about 50% reduction in
From: Ville Syrjälä
It irks me to use crtc_state_is_legacy_gamma() inside the guts
of the CHV color management code. Let's get rid of it and instead
just consult cgm_mode to figure out if we want to enable the pipe
gamma or the CGM gamma.
Also CHV display engine is based on i965/g4x so we
From: Ville Syrjälä
The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.
Signed-off-by: Ville Syrjälä
---
On 2019-11-07 10:43 a.m., Ville Syrjälä wrote:
> On Thu, Nov 07, 2019 at 03:31:28PM +, Kazlauskas, Nicholas wrote:
>> On 2019-11-07 10:17 a.m., Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> This thing can get called several thousand times per LUT
>>> so seems like we want to inline it
Hey Alex,
any objections that I merge those two patches through drm-misc-next?
It's a cleanup I wanted to do for years and Thomas finally fixed up TTM
for this.
Cheers,
Christian.
Am 07.11.19 um 13:01 schrieb Christian König:
From: Christian König
Finally clean up the VMA setup for
On Thu, Nov 07, 2019 at 01:54:22AM -0800, Joe Perches wrote:
> On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
> > Replace the use of the dev_err macro with the DRM_DEV_ERROR
> > DRM helper macro.
>
> The commit message should show the reason _why_ you are doing
> this instead of just
https://bugs.freedesktop.org/show_bug.cgi?id=108898
Eero Tamminen changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
1 - 100 of 217 matches
Mail list logo
