Am 05.09.2018 um 05:36 schrieb zhoucm1:
On 2018年09月04日 17:20, Christian König wrote:
Am 04.09.2018 um 11:00 schrieb zhoucm1:
On 2018年09月04日 16:42, Christian König wrote:
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb
Hi,
> >>> As explained before, that would break radeon userspace on big endian
> >>> hosts.
> >>
> >> We last discussed this about a year ago, so I hope you'll forgive my
> >> lapse in memory...
> >>
> >> There's userspace that uses ADDFB2 with DRM_FORMAT_XRGB but
> >> expects it to be host
https://bugzilla.kernel.org/show_bug.cgi?id=201015
--- Comment #1 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
Created attachment 278311
--> https://bugzilla.kernel.org/attachment.cgi?id=278311&action=edit
dmesg, multiple suspend-resume cycles with 1 monitor, then attached 2nd
monitor, r
https://bugzilla.kernel.org/show_bug.cgi?id=201015
Bug ID: 201015
Summary: [amdgpu] BUG: unable to handle kernel NULL pointer
dereference on resume with 2 monitors (vega)
Product: Drivers
Version: 2.5
Kernel Version: 4.19-rc2
Add fourcc variants in host byte order. With these at hand we don't
need #ifdefs in drivers which support framebuffers in cpu endianess.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fourcc.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/drm/drm_fourcc.h
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a
Patch series adds some convinience #defines for host byteoder drm
formats. It fixes drm_mode_addfb() behavior on bigendian machines. For
bug compatibility reasons a mode_config quirk activates the fix.
bochs and virtio-gpu drivers are updated to use the new #defines, set
the new driver feature fl
framebuffer_check() expects that drm_get_format_info() will not fail if
the __drm_format_info() call was successful. That'll work only in case
both are called with the same pixel_format value, so masking out the
DRM_FORMAT_BIG_ENDIAN flag isn't a good idea.
Signed-off-by: Gerd Hoffmann
---
driv
Userspace on big endian machhines typically expects the ADDFB ioctl
returns a big endian framebuffer. drm_mode_addfb() will call
drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_*
values though, which is wrong. This patch fixes that.
Drivers (both kernel and xorg) have quirks in p
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the d
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_drv.h | 1 -
include/drm/drm_mode_config.h | 1 +
drivers/gpu/drm/drm_framebuffer.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/d
Currently, the DDC signals are controlled by the DWC HDMI I2C
master to be used for HDMI (DVI on the Apalis Evaluation Board).
However, the Apalis Evaluation board also allows to route the Apalis
DDC I2C to the LVDS or the VGA connector. By default, the signal
is routed to DVI (HDMI), and therefor
A bridge might require specific settings for the pixel data on
the bus. Copy the bus flags from the bridge timings if a bridge
is in use.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/imx/parallel-display.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/imx/parallel
The Apalis iMX6 modules use a simple DAC using resistor ladders
to convert parallel RGB to VGA. Add support for this output using
the dump VGA driver.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/imx6q-apalis-eval.dts | 28 +
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 52
Support boards with a passive RGB to VGA bridge which require a low
active data-enable polarity.
Signed-off-by: Stefan Agner
---
Alternatively a new dt binding could be introduced for dumb VGA bridges
requiring low active data enable... However, also other polarities might
need a specific polarit
Allow to specify the data-enable polarity required by a dumb VGA
DAC converting parallel RGB to VGA.
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/display/bridge/dumb-vga-dac.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/brid
The DRM bus flags convey additional information on pixel data on
the bus. All current available bus flags might be of interest for
a bridge. Remove the sampling_edge field and use bus_flags.
In the case at hand a dumb VGA bridge needs a specific data enable
polarity (DRM_BUS_FLAG_DE_LOW).
Signed-
On 2018年09月04日 17:20, Christian König wrote:
Am 04.09.2018 um 11:00 schrieb zhoucm1:
On 2018年09月04日 16:42, Christian König wrote:
Am 04.09.2018 um 10:27 schrieb zhoucm1:
On 2018年09月04日 16:05, Christian König wrote:
Am 04.09.2018 um 09:53 schrieb zhoucm1:
[SNIP]
How about this idea:
1
Hi Bjorn and Linus
Thanks for the comments.
Based on this, since we want to remove the dev/phone dependency but
retain the driver + panel dependency on the compatible string, while
addressing Philip's comments, I shall rename the string as
"truly,nt35597-2K-display".
Let me know if there ar
On 2018-08-29 10:49, Sean Paul wrote:
From: Sean Paul
The atomic_check is a bit too aggressive with respect to planes which
leave the active area. This caused a bunch of log spew when the cursor
got to the edge of the screen and stopped it from going all the way.
This patch removes the conserv
On 2018-08-31 09:08, Sean Paul wrote:
On Tue, Aug 28, 2018 at 05:40:01PM -0700, Jeykumar Sankaran wrote:
Strip down the support for topology enums. It
can be replaced with simple hw count checks.
Changes in v4:
...
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_enc
On 2018-08-31 07:56, Sean Paul wrote:
On Tue, Aug 28, 2018 at 05:39:59PM -0700, Jeykumar Sankaran wrote:
Prep changes for state based resource management.
Moves all the hw block tracking for the crtc to the state
object.
Changes in v4...
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/d
On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom wrote:
>
> On 09/03/2018 06:33 PM, Daniel Vetter wrote:
> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
> >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
> >>> On 08/31/2018 05:27 PM, Emil Velikov wrote:
> On 31 August 201
On Tue, Sep 04, 2018 at 09:53:19PM +0100, Chris Wilson wrote:
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
>
> Signed-off-by: Chris Wilson
> Cc:
On Tue, Sep 04, 2018 at 09:36:01PM +0200, Bas Nieuwenhuizen wrote:
> On Tue, Sep 4, 2018 at 9:28 PM Daniel Vetter wrote:
> >
> > On Tue, Sep 4, 2018 at 8:31 PM, Bas Nieuwenhuizen
> > wrote:
> > > On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
> > >>
> > >> On Tue, Sep 4, 2018 at 7:57 PM, Ba
"crtc->helper_private" is not initialized by the QXL driver and thus the
"crtc_funcs->disable" call would crash (resulting in suspend failure).
Fix this by converting the suspend/resume functions to use the
drm_mode_config_helper_* helpers.
Tested system sleep with QEMU 3.0 using "echo mem > /sys/
Since this is handling user provided bpp and depth, we need to sanity
check and propagate the EINVAL back rather than assume what the insane
client intended and fill the logs with DRM_ERROR.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
So I am presuming that r.pixel_forma
On 4 September 2018 at 13:19, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 06:38:44PM +0100, Emil Velikov wrote:
>> On 3 September 2018 at 17:54, Daniel Vetter wrote:
>>
>> > -Hide legacy cruft better
>> > -
>> > -
>> > -Way back DRM supported only drivers which shadow-a
On Mon, Sep 03, 2018 at 06:54:31PM +0200, Daniel Vetter wrote:
> This leaves all the commit/check and state handling in drm_atomic.c,
> while pulling all the uapi glue and the huge ioctl itself into a
> seprate file.
>
> This seems to almost perfectly split the rather big drm_atomic.c file
> into
https://bugs.freedesktop.org/show_bug.cgi?id=107781
--- Comment #8 from Alex Findler ---
med@sorceress:~ 0> uname -av
Linux sorceress 4.18.5med+ #1 SMP Tue Sep 4 17:42:26 CEST 2018 x86_64 x86_64
x86_64 GNU/Linux
So far, so good. I booted with these kernel options:
resume=/dev/mapper/fedora_lin
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #40 from djip.per...@free.fr ---
Created attachment 141452
--> https://bugs.freedesktop.org/attachment.cgi?id=141452&action=edit
dmesg from kernel 4.18.5 with patch 141163
on AMD Kabini A6-1450...
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #39 from djip.per...@free.fr ---
test last patch with kernel 4.18.5...
It works...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-d
On Tue, Mar 27, 2018 at 5:15 PM, Thomas Hellstrom wrote:
> On 03/27/2018 05:08 PM, Ville Syrjälä wrote:
>>
>> On Tue, Mar 27, 2018 at 04:26:17PM +0200, Thomas Hellstrom wrote:
>>>
>>> Use the correct helper and also return early on helper
>>> success rather than on helper failure.
>>>
>>> Also exp
On Tue, Sep 4, 2018 at 9:28 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 8:31 PM, Bas Nieuwenhuizen
> wrote:
> > On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
> >>
> >> On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
> >> wrote:
> >> > On Tue, Sep 4, 2018 at 7:48 PM Christian Köni
On Tue, Sep 4, 2018 at 8:31 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
>> wrote:
>> > On Tue, Sep 4, 2018 at 7:48 PM Christian König
>> > wrote:
>> >>
>> >> Am 04.09.2018 um 18:37 schrieb Daniel Vett
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #9 from Alan W. Irwin ---
We (there are two of us using this machine) just got yet another kernel lockup
(no remote access possible with ssh, direct keyboard not working), but this is
a case when we were remotely accessing this box w
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #8 from Alan W. Irwin ---
Created attachment 141451
--> https://bugs.freedesktop.org/attachment.cgi?id=141451&action=edit
tarball containing kern.log, syslog, and dmesg output
--
You are receiving this mail because:
You are the a
On Tue, Sep 4, 2018 at 9:05 PM, Mikulas Patocka wrote:
>
>
> On Tue, 4 Sep 2018, Daniel Vetter wrote:
>
>> With kms you need logind or someone like that who orchestrates the vt
>> switching and makes sure you can read/write other people's stuff.
>
> BTW. I'm just wondering how is this 'master mode
On Tue, 4 Sep 2018, Daniel Vetter wrote:
> With kms you need logind or someone like that who orchestrates the vt
> switching and makes sure you can read/write other people's stuff.
BTW. I'm just wondering how is this 'master mode' security working at all.
The user start Xserver under the user'
https://bugs.freedesktop.org/show_bug.cgi?id=104362
--- Comment #8 from Andrey Grodzovsky ---
We can try and check the gfx command buffer for latest commands and CUs status
-
Clone and build our open source register analyzer from here -
https://cgit.freedesktop.org/amd/umr/
After hang happens
Quoting Daniel Vetter (2018-09-04 14:08:12)
> On Tue, Sep 04, 2018 at 12:57:19PM +0100, Chris Wilson wrote:
> > The ioctl arguments are under control of the user and as such we should
> > resist any temptation to flood the kernel logs with their errors.
> > Relegate the DRM_ERROR to a DRM_DEBUG so
On Tue, 4 Sep 2018, Daniel Vetter wrote:
> On Tue, Sep 4, 2018 at 7:04 PM, Mikulas Patocka wrote:
> >
> >
> > On Tue, 4 Sep 2018, Daniel Vetter wrote:
> >
> >> On Tue, Sep 4, 2018 at 1:41 AM, Dave Airlie wrote:
> >> >>
> >> >> I've seen that you dropped this patch:
> >> >> https://patchwork.ke
On Tue, Sep 4, 2018 at 8:27 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
> wrote:
> > On Tue, Sep 4, 2018 at 7:48 PM Christian König
> > wrote:
> >>
> >> Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
> >> > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
> >> >
https://bugs.freedesktop.org/show_bug.cgi?id=105046
--- Comment #19 from Michael Zapf ---
On my office PC with 4K monitor, the issue is now also gone. That is, I have no
more evidence of that resolution reset on any of my computers.
--
You are receiving this mail because:
You are the assignee f
On Tue, Sep 4, 2018 at 7:57 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 7:48 PM Christian König
> wrote:
>>
>> Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
>> > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
>> > wrote:
>> >> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
>>
On Tue, Sep 4, 2018 at 7:04 PM, Mikulas Patocka wrote:
>
>
> On Tue, 4 Sep 2018, Daniel Vetter wrote:
>
>> On Tue, Sep 4, 2018 at 1:41 AM, Dave Airlie wrote:
>> >>
>> >> I've seen that you dropped this patch:
>> >> https://patchwork.kernel.org/patch/10445393/
>> >>
>> >> Is that patch correct or
https://bugs.freedesktop.org/show_bug.cgi?id=107213
--- Comment #12 from Sylvain BERTRAND ---
May be different then, because my bug
https://bugs.freedesktop.org/show_bug.cgi?id=107784 is with git userspace no
older than a few days, and displayport is broken whatever the screen
resolution.
I did m
May be different then, because my bug
https://bugs.freedesktop.org/show_bug.cgi?id=107784 is with git userspace no
older than a few days, and displayport is broken whatever the screen resolution.
I did manually bisect the kernel and found the faulty commit though, I guess
the guys in amd are now lo
Am 04.09.2018 um 20:00 schrieb Bas Nieuwenhuizen:
On Tue, Sep 4, 2018 at 7:57 PM Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 7:48 PM Christian König
wrote:
Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 4:43
On Tue, Sep 4, 2018 at 7:57 PM Bas Nieuwenhuizen
wrote:
>
> On Tue, Sep 4, 2018 at 7:48 PM Christian König
> wrote:
> >
> > Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
> > > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
> > > wrote:
> > >> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrot
On Tue, Sep 4, 2018 at 7:48 PM Christian König
wrote:
>
> Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
> > On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
> > wrote:
> >> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
> >>> On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
> >>> wrote:
Am 04.09.2018 um 18:37 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
wrote:
On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 0
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #49 from Andrey Grodzovsky ---
(In reply to CheatCodesOfLife from comment #48)
> Created attachment 141425 [details]
> logs and trace
>
> Hi,
>
> I have applied the patch, ran through the process and attached the logs. The
> file d
https://bugs.freedesktop.org/show_bug.cgi?id=107826
qnerd changed:
What|Removed |Added
Summary|amdgpu-pro ubuntu 18.30:|amdgpu-pro 18.30: Missing
|Mi
https://bugs.freedesktop.org/show_bug.cgi?id=107826
Bug ID: 107826
Summary: amdgpu-pro ubuntu 18.30: Missing xserver modesetting
package (--px install)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Tue, 4 Sep 2018, Daniel Vetter wrote:
> On Tue, Sep 4, 2018 at 1:41 AM, Dave Airlie wrote:
> >>
> >> I've seen that you dropped this patch:
> >> https://patchwork.kernel.org/patch/10445393/
> >>
> >> Is that patch correct or incorrect? In case it is incorrect, do you have
> >> an idea how sh
On Tue, Sep 4, 2018 at 5:52 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
>> wrote:
>> > On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
>> >>
>> >> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nie
https://bugs.freedesktop.org/show_bug.cgi?id=107825
Bug ID: 107825
Summary: *ERROR* Couldn't read Speaker Allocation Data Block:
-2
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: N
On Tue, Sep 4, 2018 at 4:43 PM Daniel Vetter wrote:
>
> On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
> wrote:
> > On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
> >>
> >> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
> >> > On Tue, Sep 4, 2018 at 2:26 PM Daniel Vet
Hi Evan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 6abc0c8f8cf3e0c47707b01f027f9f9b9aa75646
commit: d617d4d73043bc4cbc316a7a1b4370fa5bc26a31 [99/258] drm/amd/powerplay:
new interfaces for overdrive vega20 sclk and mclk
c
Hi Jernej,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on sunxi/sunxi/for-next]
[also build test WARNING on v4.19-rc2 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Jernej,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on sunxi/sunxi/for-next]
[also build test WARNING on v4.19-rc2 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Michał,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc2 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
From: Colin Ian King
Don't populate the array vsoff on the stack but instead make it
static. Makes the object code smaller by 67 bytes:
Before:
textdata bss dec hex filename
5753 112 0586516e9 .../nouveau/nvkm/subdev/bios/dp.o
After:
textdata b
On Tue, Sep 4, 2018 at 11:02 AM, Michel Dänzer wrote:
> On 2018-09-04 3:05 p.m., Ilia Mirkin wrote:
>> On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
>>> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 12:
Hi Daniel,
FYI, the error/warning still remains.
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 1b18cb66428cffa748719cf900b2decac3690029
commit: 7928ca5cc786fdc0269342f1b9e22c2af939b989 [144/320] RFC: debugobjects:
capture stack traces at _init() time
config: m68k-allyesconfig
On 2018-09-04 3:05 p.m., Ilia Mirkin wrote:
> On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
>> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
>>> On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
> Userspace on big en
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #5 from Jan Burgmeier ---
Created attachment 141447
--> https://bugs.freedesktop.org/attachment.cgi?id=141447&action=edit
dmesg after setting mode to auto
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #4 from Jan Burgmeier ---
Created attachment 141446
--> https://bugs.freedesktop.org/attachment.cgi?id=141446&action=edit
dmesg after setting mode to 1400x1050
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #3 from Jan Burgmeier ---
Created attachment 141445
--> https://bugs.freedesktop.org/attachment.cgi?id=141445&action=edit
xrandr output
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Laurent, Geert,
On Tue, Sep 04, 2018 at 04:32:32PM +0200, Geert Uytterhoeven wrote:
> On Tue, Sep 4, 2018 at 2:10 PM Laurent Pinchart
> wrote:
> > From: Takeshi Kihara
> >
> > Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> > tree.
> >
> > Signed-off-by: Takeshi Kih
On Tue, Sep 4, 2018 at 3:33 PM, Bas Nieuwenhuizen
wrote:
> On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
>>
>> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
>> > On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
>> > >
>> > > On Tue, Sep 04, 2018 at 12:44:19PM +0200,
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #2 from Jan Burgmeier ---
Created attachment 141444
--> https://bugs.freedesktop.org/attachment.cgi?id=141444&action=edit
/proc/cpuinfo
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107823
Bug ID: 107823
Summary: [amdgpu/displayport] Blackscreen on native resolution
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #1 from Jan Burgmeier ---
Created attachment 141443
--> https://bugs.freedesktop.org/attachment.cgi?id=141443&action=edit
lspci -vv output
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugzilla.kernel.org/show_bug.cgi?id=200531
Barry G (ba...@grussling.com) changed:
What|Removed |Added
CC||ba...@grussling.com
--- C
On Tue, Sep 4, 2018 at 2:10 PM Laurent Pinchart
wrote:
> From: Takeshi Kihara
>
> Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> tree.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
My
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytte
Hi Laurent,
On Tue, Sep 4, 2018 at 2:10 PM Laurent Pinchart
wrote:
> The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> in the other R-Car Gen3 family members:
>
> - The LVDS PLL architecture is more complex and requires computing PLL
> parameters manually.
> - The PLL us
On Tue, Sep 4, 2018 at 3:45 PM, Thomas Hellstrom wrote:
> On 09/03/2018 06:54 PM, Daniel Vetter wrote:
>>
>> 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.
On Tue, Sep 04, 2018 at 03:52:51PM +0200, Maarten Lankhorst wrote:
> Op 04-09-18 om 15:50 schreef Ville Syrjälä:
> > On Tue, Sep 04, 2018 at 02:47:51PM +0200, Maarten Lankhorst wrote:
> >> Op 30-08-18 om 16:24 schreef Stanislav Lisovskiy:
> >>> PLANE_CTL_FORMAT_AYUV is already supported, according
On Tue, 4 Sep 2018 13:30:30 +0200
Pavel Machek wrote:
> I'd say this is still quite valueable, and it might be worth fixing,
> rather then removing completely.
I agree. Perhaps we should have a 00-DESCRIPTION file in each
directory, and each file could start with a:
DESCRIPTION:
and then the
Op 04-09-18 om 15:50 schreef Ville Syrjälä:
> On Tue, Sep 04, 2018 at 02:47:51PM +0200, Maarten Lankhorst wrote:
>> Op 30-08-18 om 16:24 schreef Stanislav Lisovskiy:
>>> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
>>> specification.
>>>
>>> v2: Edited commit message, removed r
On Tue, Sep 04, 2018 at 02:47:51PM +0200, Maarten Lankhorst wrote:
> Op 30-08-18 om 16:24 schreef Stanislav Lisovskiy:
> > PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> > specification.
> >
> > v2: Edited commit message, removed redundant whitespaces.
> >
> > v3: Fixed fallthr
On 09/03/2018 06:54 PM, Daniel Vetter wrote:
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 cl
On Thu, Aug 30, 2018 at 01:09:37PM +0200, Heiko Stuebner wrote:
> The rk3188 has 2 vops not using iommus which only output directly
> to a rgb interface per vop. So all other output modes like hdmi
> are provided by external brige chips.
>
> Signed-off-by: Heiko Stuebner
> ---
> This depends on S
On Tue, Sep 4, 2018 at 3:04 PM Daniel Vetter wrote:
>
> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
> > On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
> > >
> > > On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> > > > Am 04.09.2018 um 12:15 schrieb Da
On Tuesday, 2018-09-04 14:49:07 +0200, Daniel Vetter wrote:
> Looks much neater on the gitlab UI, e.g. on my personal libdrm fork:
>
> https://gitlab.freedesktop.org/danvet/drm
>
> Signed-off-by: Daniel Vetter
Acked-by: Eric Engestrom
> ---
> CONTRIBUTING => CONTRIBUTING.rst | 0
> README =>
Am 04.09.2018 um 15:17 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 3:12 PM, Christian König
wrote:
Am 04.09.2018 um 15:03 schrieb Daniel Vetter:
On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 1
On Tue, Sep 4, 2018 at 3:12 PM, Christian König
wrote:
> Am 04.09.2018 um 15:03 schrieb Daniel Vetter:
>>
>> On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
>>>
>>> On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 6abc0c8f8cf3e0c47707b01f027f9f9b9aa75646
commit: dd73043534515c1b8bf31f78f0e9945f5d95e0e6 [165/258] drm/amd/display:
implement DPMS DTN test v2
config: i386-randconfig-j3-201835 (attached as .config)
compiler: gcc-4.9
Am 04.09.2018 um 15:03 schrieb Daniel Vetter:
On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Hi,
On Tue, 4 Se
On Tue, Sep 04, 2018 at 12:57:19PM +0100, Chris Wilson wrote:
> The ioctl arguments are under control of the user and as such we should
> resist any temptation to flood the kernel logs with their errors.
> Relegate the DRM_ERROR to a DRM_DEBUG so the user has to opt into
> hearing of their own mist
On Tue, Sep 04, 2018 at 09:45:05AM +0530, Souptick Joarder wrote:
> We have introduce new return type vm_fault_t for
> fault handler. Update the document for the same.
>
> Signed-off-by: Souptick Joarder
> ---
> v2: Revert spaces added in v1
Thanks, applied to drm-misc-next.
-Daniel
>
> Docum
On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
>> On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
>>> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
Userspace on big endian machhines typically expects the ADDFB ioctl
>
Am 04.09.2018 um 14:26 schrieb Daniel Vetter:
On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Hi,
On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
wrote:
+/* The chip this is c
On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:
> On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter wrote:
> >
> > On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> > > Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > > > Hi,
> > > >
> > > > On Tue, 4 Sep 2018 at 11:
Am 04.09.2018 um 14:22 schrieb Daniel Stone:
Hi,
On Tue, 4 Sep 2018 at 11:44, Christian König
wrote:
Am 04.09.2018 um 12:15 schrieb Daniel Stone:
Right. The conclusion, after people went through and started sorting
out the kinds of formats for which they would _actually_ export real
colour bu
Looks much neater on the gitlab UI, e.g. on my personal libdrm fork:
https://gitlab.freedesktop.org/danvet/drm
Signed-off-by: Daniel Vetter
---
CONTRIBUTING => CONTRIBUTING.rst | 0
README => README.rst | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename CONTRIBUTING => CO
Op 30-08-18 om 16:24 schreef Stanislav Lisovskiy:
> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> specification.
>
> v2: Edited commit message, removed redundant whitespaces.
>
> v3: Fixed fallthrough logic for the format switch cases.
>
> v4: Yet again fixed fallthrough logic
On Tue, Sep 04, 2018 at 10:02:40AM +0100, Eric Engestrom wrote:
> On Tuesday, 2018-09-04 16:24:44 +1000, Dave Airlie wrote:
> > On Mon, 3 Sep 2018 at 18:47, Daniel Vetter wrote:
> > >
> > > I picked up a bunch of the pieces from wayland's version:
> > >
> > > https://gitlab.freedesktop.org/wayland
1 - 100 of 181 matches
Mail list logo
