Hi, Sam:
You could apply this patch into drm-misc-next by yourself, thanks.
Regards,
CK
On Fri, 2019-07-19 at 09:30 +0800, CK Hu wrote:
> On Thu, 2019-07-18 at 18:15 +0200, Sam Ravnborg wrote:
> > Do not rely on including drm.h from drm_file.h,
> > as the include in drm_file.h will be dropped.
On Thu, 2019-07-18 at 18:15 +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
Acked-by: CK Hu
> Signed-off-by: Sam Ravnborg
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #57 from Hadet ---
Created attachment 144821
--> https://bugs.freedesktop.org/attachment.cgi?id=144821=edit
Dmesg after crash
I spoke too soon it's happening on Wayland now too just a lot less frequently
--
You are receiving
On Thu, Jul 18, 2019 at 12:22:33PM -0700, Brendan Higgins wrote:
> On Thu, Jul 18, 2019 at 10:50 AM Stephen Boyd wrote:
> >
> > Quoting Brendan Higgins (2019-07-16 11:52:01)
> > > On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote:
[...]
> > Do you have a link to those earlier patches?
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=204227
--- Comment #1 from dolohow (dolo...@outlook.com) ---
Created attachment 283825
--> https://bugzilla.kernel.org/attachment.cgi?id=283825=edit
lspci
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=204227
Bug ID: 204227
Summary: Visual artefacts and crash from suspend on amdgpu
Product: Drivers
Version: 2.5
Kernel Version: 5.2.1
Hardware: x86-64
OS: Linux
The DDC/CI protocol involves sending a multi-byte request to the
display via I2C, which is typically followed by a multi-byte
response. The internal I2C controller only allows single byte
reads/writes or reads of 8 sequential bytes, hence DDC/CI is not
supported when the internal I2C controller is
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #28 from tempel.jul...@gmail.com ---
Situation is still unchanged with latest drm-next-5.4-wip kernel branch from a
few minutes ago. :(
--
You are receiving this mail because:
You are the assignee for the
Hi Dave, Daniel,
Fixes for 5.3, mostly for Navi.
The following changes since commit 7f963d9f69bf28d639013630da30d7a4c95edd5d:
drm/amdgpu/navi10: add uclk activity sensor (2019-07-09 17:43:36 -0500)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
Quoting Rob Clark (2019-06-30 05:47:22)
> From: Rob Clark
>
> Recently splats like this started showing up:
>
>WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
> __iommu_dma_unmap+0xb8/0xc0
>Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
> cfg80211
Use my kernel.org address instead of the bootlin one.
Signed-off-by: Maxime Ripard
---
.mailmap| 2 ++
MAINTAINERS | 10 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/.mailmap b/.mailmap
index 0fef932de3db..509d258a9e77 100644
--- a/.mailmap
+++ b/.mailmap
@@
On Thu, Jul 18, 2019 at 10:50 AM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-07-16 11:52:01)
> > On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote:
> > >
> >
> > > The only hypothetical case where this can't be done is a complicated
> > > assertion or expectation that does more than
Configuring backlight trigger from dts results in backlight off during
boot. Machine looks dead upon boot, which is not good.
Fix that by enabling LED on trigger activation.
Signed-off-by: Pavel Machek
diff --git a/drivers/leds/trigger/ledtrig-backlight.c
On Tue, Jul 09, 2019 at 09:58:08PM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c:
> In function komeda_plane_atomic_duplicate_state:
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c:161:35:
> warning: variable
On Thu, Jul 18, 2019 at 06:15:07PM +0200, Sam Ravnborg wrote:
> drm_file used drm_magic_t from uapi/drm/drm.h.
> This is a simple unsigned int.
> Just opencode it as such to break the dependency from this header file
> to uapi.
>
> Signed-off-by: Sam Ravnborg
Passes my build tests, thanks for
On Thu, Jul 18, 2019 at 08:11:35PM +0200, Sam Ravnborg wrote:
> Hi Sean.
> >
> > Any plans for the other users of DRM_WRITE()? It seems like it'd be
> > trivial
> > to fix it up for via and mga. I don't really have any background on
> > drm_os_linux.h, but it doesn't seem like it'd be that much
On 2019-07-16 02:07, Daniel Vetter wrote:
On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote:
Hello All,
drm_mode_modeinfo::flags is a 32 bit field currently used to
describe the properties of a connector mode. I see the least order
22 bits
are already in
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #62 from Chris ---
Just wanted to say that on Kernel 5.2rc7, BIOS F.21 I'm able to boot with
raven_dmcu.bin in /lib/firmware/amdgpu. I also updated raven_dmcu.bin from the
linux firmware git. Not sure which part helped though or all
Hi Sean.
>
> Any plans for the other users of DRM_WRITE()? It seems like it'd be trivial
> to fix it up for via and mga. I don't really have any background on
> drm_os_linux.h, but it doesn't seem like it'd be that much more effort to just
> remove the whole thing.
During the drmP.h removal I
On Thu, Jul 18, 2019 at 06:15:05PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David
On Thu, Jul 18, 2019 at 06:15:06PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc:
On Thu, Jul 18, 2019 at 06:15:04PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David
On Thu, Jul 18, 2019 at 06:15:03PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David
On Thu, Jul 18, 2019 at 06:15:01PM +0200, Sam Ravnborg wrote:
> DRM_WAIT_ON() is from the deprecated drm_os_linux header and
> the modern replacement is the wait_event_*.
>
> The return values differ, so a conversion is needed to
> keep the original interface towards userspace.
> Introduced a
On Thu, Jul 18, 2019 at 06:15:02PM +0200, Sam Ravnborg wrote:
> Do not rely on including drm.h from drm_file.h,
> as the include in drm_file.h will be dropped.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David
Quoting Brendan Higgins (2019-07-16 11:52:01)
> On Tue, Jul 16, 2019 at 10:50 AM Stephen Boyd wrote:
> >
>
> > The only hypothetical case where this can't be done is a complicated
> > assertion or expectation that does more than one check and can't be
> > written as a function that dumps out
On Thu, Jul 18, 2019 at 06:15:00PM +0200, Sam Ravnborg wrote:
> The drm_os_linux.h header is deprecated.
> Just opencode the sole DRM_WRITE32().
Any plans for the other users of DRM_WRITE()? It seems like it'd be trivial
to fix it up for via and mga. I don't really have any background on
On Thu, Jul 18, 2019 at 06:14:58PM +0200, Sam Ravnborg wrote:
> drm_print.h used DRM_NAME - thus adding a dependency from
> include/drm/drm_print.h => uapi/drm/drm.h
>
> Hardcode the name "drm" to break this dependency.
> The idea is that there shall be a minimal dependency
> between
On Thu, Jul 18, 2019 at 06:14:59PM +0200, Sam Ravnborg wrote:
> drm_vblank.h included uapi/drm/drm.h.
> It turns out this include was not required - delete it.
>
> Note: uapi/drm/drm.h is included indirect via drm_file.h,
> but there are no dependencies in drm_vblank.h so the removal
> is legit.
On Thu, Jul 18, 2019 at 06:14:57PM +0200, Sam Ravnborg wrote:
> From: Jani Nikula
>
> Fix build warning if drm_panel.h is built with CONFIG_OF=n or
> CONFIG_DRM_PANEL=n and included without the prerequisite err.h:
>
> ./include/drm/drm_panel.h: In function ‘of_drm_find_panel’:
>
On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>
> On 17/07/2019 19:33, Rob Herring wrote:
> > Executable buffers have an alignment restriction that they can't cross
> > 16MB boundary as the GPU program counter is 24-bits. This restriction is
> > currently not handled and we just get lucky.
On Sun, Jul 07, 2019 at 09:19:02PM +0300, Laurent Pinchart wrote:
> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
>
> - It prevents supporting more complex
Quoting Sam Ravnborg (2019-07-18 17:14:58)
> drm_print.h used DRM_NAME - thus adding a dependency from
> include/drm/drm_print.h => uapi/drm/drm.h
>
> Hardcode the name "drm" to break this dependency.
> The idea is that there shall be a minimal dependency
> between include/drm/* and uapi/*
>
>
From: Ville Syrjälä
crtc_state->limited_color_range only applies to RGB output but
we're currently setting it even for YCbCr output. That will
lead to conflicting MSA and PIPECONF settings which can mess
up the image. Let's make sure limited_color_range stays unset
with YCbCr output.
Also WARN
On Wed, Jun 12, 2019 at 11:13:10AM +0200, Andrzej Hajda wrote:
> On 04.06.2019 14:23, Torsten Duwe wrote:
> > +
> > +static void anx6345_poweron(struct anx6345 *anx6345)
> > +{
> > + int err;
> > +
> > + /* Ensure reset is asserted before starting power on sequence */
> > +
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #9 from rol...@rptd.ch ---
I get two config attempts. This is the second one. Do you see anything out of
place here?
meson --buildtype plain --libdir lib64 --localstatedir /var/lib --prefix /usr
--sysconfdir /etc --wrap-mode
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lionel Landwerlin
Cc: Chunming Zhou
Cc: Christian König
---
drm_file used drm_magic_t from uapi/drm/drm.h.
This is a simple unsigned int.
Just opencode it as such to break the dependency from this header file
to uapi.
Signed-off-by: Sam Ravnborg
Suggested-by: Daniel Vetter
Cc: Sean Paul
Cc: Liviu Dudau
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc:
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: CK Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
---
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Christian König
Cc: Noralf Trønnes
Cc: Chris Wilson
Cc: Eric Anholt
---
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Thomas Zimmermann
Cc: Rob Herring
---
Do not rely on including drm.h from drm_file.h,
as the include in drm_file.h will be dropped.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Thomas Zimmermann
Cc: Rob Herring
---
DRM_WAIT_ON() is from the deprecated drm_os_linux header and
the modern replacement is the wait_event_*.
The return values differ, so a conversion is needed to
keep the original interface towards userspace.
Introduced a switch/case to make code obvious and to allow
different debug prints
The drm_os_linux.h header is deprecated.
Just opencode the sole DRM_WRITE32().
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/ati_pcigart.c | 10 ++
1 file changed, 6 insertions(+), 4
drm_vblank.h included uapi/drm/drm.h.
It turns out this include was not required - delete it.
Note: uapi/drm/drm.h is included indirect via drm_file.h,
but there are no dependencies in drm_vblank.h so the removal
is legit.
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Vetter
Cc: Maarten
From: Jani Nikula
Fix build warning if drm_panel.h is built with CONFIG_OF=n or
CONFIG_DRM_PANEL=n and included without the prerequisite err.h:
./include/drm/drm_panel.h: In function ‘of_drm_find_panel’:
./include/drm/drm_panel.h:203:9: error: implicit declaration of function
‘ERR_PTR’
drm_print.h used DRM_NAME - thus adding a dependency from
include/drm/drm_print.h => uapi/drm/drm.h
Hardcode the name "drm" to break this dependency.
The idea is that there shall be a minimal dependency
between include/drm/* and uapi/*
Signed-off-by: Sam Ravnborg
Suggested-by: Daniel Vetter
First patch from Jani fixes so drm_print.h is self-contained.
Next two patches are trivial removal of uapi dependencies.
ati_pcigart is fixed to drop use of drm_os_linux.h
drm_vblank is likewise fixed to drop use of drm_os_linux.h
This was a non-trivial conversion, *review requested!*
The
On Sun, Jun 30, 2019 at 05:47:22AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Recently splats like this started showing up:
>
>WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
> __iommu_dma_unmap+0xb8/0xc0
>Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211
DRM_WAIT_ON() is a reliec from the past and is discouraged.
Use the standard wait_event_*() as replacement.
Be carefull to keep the same return values.
via_dma_blit_sync() changed -EINTR to -EAGAIN.
Moved this to via_dmablit_sync() so return value is
adjusted only once.
Signed-off-by: Sam
The DRM_READ, DRM_WRITE macros comes from the deprecated drm_os_linux.h
header file. Remove their use to remove this dependency.
Replace the use of the macros with open coded variants.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike
Replace DRM_WAIT_ON() with wait_event_interruptible().
While replacing be careful to keep same return value semantics.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
---
Replace DRM_WAIT_ON() with wait_event_interruptible().
Be careful to keep same return value semantics
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
---
This is some janitorial updates to the via driver
that is required to get rid of deprecated headers
in the drm subsystem.
The first three patches are trivial, where
the dependencies on drmP.h and drm_os_linux are dropped.
The remaining three patches drop use of DRM_WAIT_ON().
They are replaced
Added the necessary header files to make this header file
self-contained.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/gpu/drm/via/via_drv.h | 6 +-
1 file
Drop use of the deprecated drmP.h header.
While touching the files divide include files in blocks
and sort the files alphabetically.
Signed-off-by: Sam Ravnborg
Cc: Kevin Brace
Cc: Thomas Hellstrom
Cc: "Gustavo A. R. Silva"
Cc: Mike Marshall
Cc: Ira Weiny
Cc: Daniel Vetter
Cc: Emil Velikov
On Thu, Jul 18, 2019 at 5:17 PM Dmitry Torokhov
wrote:
> On Thu, Jul 18, 2019 at 6:13 PM Arnd Bergmann wrote:
> > On Thu, Jul 18, 2019 at 4:56 PM Andrzej Hajda wrote:
> > > On 18.07.2019 16:21, Arnd Bergmann wrote:
> > > > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda
> > > > wrote:
> > > >>
On Thu, Jul 18, 2019 at 02:17:37PM +0100, Liviu Dudau wrote:
> On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China)
> wrote:
/snip
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index
On Thu, Jul 18, 2019 at 6:13 PM Arnd Bergmann wrote:
>
> On Thu, Jul 18, 2019 at 4:56 PM Andrzej Hajda wrote:
> > On 18.07.2019 16:21, Arnd Bergmann wrote:
> > > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
> > >> Hi Arnd,
> > >>
> > >> On 18.07.2019 15:42, Arnd Bergmann wrote:
> > >>>
Hi team,
I am Guest-Maarten this week and next! Not exactly a quiet last PR for the merge
window, but I think this is right in line with how things have gone over the
rest
of 5.3. Although there's more volume than we'd like, I don't think there's
anything here that is contraversial.
So, welcome
On Thu, Jul 18, 2019 at 4:56 PM Andrzej Hajda wrote:
> On 18.07.2019 16:21, Arnd Bergmann wrote:
> > On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
> >> Hi Arnd,
> >>
> >> On 18.07.2019 15:42, Arnd Bergmann wrote:
> >>> Using 'imply' causes a new problem, as it allows the case of
> >>>
On 18.07.2019 16:21, Arnd Bergmann wrote:
> On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
>> Hi Arnd,
>>
>> On 18.07.2019 15:42, Arnd Bergmann wrote:
>>> Using 'imply' causes a new problem, as it allows the case of
>>> CONFIG_INPUT=m with RC_CORE=y, which fails to link:
>>>
>>>
From: Ville Syrjälä
Make intel_get_crtc_ycbcr_config() simpler and rename it
to bdw_get_pipemisc_output_format() to better reflect what
it does.
Also toss in some comments to document that the 4:2:0 PIPECONF
bits are glk+ only. They are mbz on earlier platforms so reading
them unconditionally
From: Ville Syrjälä
Looks like we're currently setting the MSA to xvYCC BT.709 instead
of the YCbCr BT.601 claimed by the comment. But even that comment
is wrong since we configure the CSC matrix to BT.709.
Let's remove the bogus statement from the comment and fix the
MSA to indicate YCbCr
From: Ville Syrjälä
On HSW the pipe colorspace is configured via PIPECONF
(as opposed to PIPEMISC in BDW+). Let's configure+readout
that stuff correctly.
Enablling YCbCr 4:4:4 output will now be a simple matter of
setting crtc_state->output_format appropriately in the encoder
.compute_config().
From: Ville Syrjälä
On ILK-IVB the pipe colorspace is configured via PIPECONF
(as opposed to PIPEMISC in BDW+). Let's configure+readout
that stuff correctly.
Enablling YCbCr 4:4:4 output will now be a simple matter of
setting crtc_state->output_format appropriately in the encoder
From: Ville Syrjälä
Add definitions for the MSA (Main Stream Attribute) MISC bits. On
some hardware you can program these directly into a register.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_dp_helper.h | 42 +
1 file changed, 42 insertions(+)
diff
From: Ville Syrjälä
Add comments to explain the ilk pipe csc operation a bit better.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git
From: Ville Syrjälä
crtc_state->limited_color_range only applies to RGB output but
we're currently setting it even for YCbCr output. That will
lead to conflicting MSA and PIPECONF settings which can mess
up the image. Let's make sure limited_color_range stays unset
with YCbCr output.
Also WARN
From: Ville Syrjälä
Since HSW the PIPECONF progressive vs. interlaced selection is done
with just two bits instead of the earlier three. Let's not look at the
extra bit on HSW+. Also gen2 doesn't support interlaced displays at all.
This is actually fine as is currently because the extra bit is
From: Ville Syrjälä
I was playing around with YCbCr 4:4:4 output and noticed several
things wrong in our code. So I fixed it all and tossed in the
prep work for YCbCr 4:4:4 output on ilk+.
Ville Syrjälä (12):
drm/dp: Add definitons for MSA MISC bits
drm/i915: Fix HSW+ DP MSA YCbCr
From: Ville Syrjälä
Prepare the pipe csc for YCbCr output on ilk/snb. The main difference
to IVB+ is the lack of explicit post offsets, and instead we must
configure the CSC info RGB->YUV mode (which takes care of offsetting
Cb/Cr properly) and enable the "black screen offset" bit to add the
From: Ville Syrjälä
Now that we have standard defines for the MSA MISC bits lets use
them on HSW+ where we program these directly into the TRANS_MSA_MISC
register.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +-
From: Ville Syrjälä
Pull the code for computing the limited color range
setting into a small helper. We'll add a bit more to it
later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +++
1 file changed, 20 insertions(+), 10 deletions(-)
From: Ville Syrjälä
We're configuring the AVI infoframe quantization range bits as if
we're always transmitting RGB pixels. Let's fix this so that we
correctly indicate limited range YCC quantization range when
transmitting YCbCr instead.
Signed-off-by: Ville Syrjälä
---
在 2019/7/18 22:08, Lionel Landwerlin 写道:
> On 18/07/2019 16:02, Chunming Zhou wrote:
>> 在 2019/7/18 19:31, Lionel Landwerlin 写道:
>>> On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
on syncobj,
then return non-block
On Thu, Jul 18, 2019 at 4:16 PM Andrzej Hajda wrote:
>
> Hi Arnd,
>
> On 18.07.2019 15:42, Arnd Bergmann wrote:
> > Using 'imply' causes a new problem, as it allows the case of
> > CONFIG_INPUT=m with RC_CORE=y, which fails to link:
> >
> > drivers/media/rc/rc-main.o: In function `ir_do_keyup':
>
Hi Arnd,
On 18.07.2019 15:42, Arnd Bergmann wrote:
> Using 'imply' causes a new problem, as it allows the case of
> CONFIG_INPUT=m with RC_CORE=y, which fails to link:
>
> drivers/media/rc/rc-main.o: In function `ir_do_keyup':
> rc-main.c:(.text+0x2b4): undefined reference to `input_event'
>
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #61 from Talha Khan ---
(In reply to Michael Eagle from comment #60)
> Created attachment 144787 [details]
> attachment-8612-0.html
>
> I am seeing reports with old BIOS, such as F.19.
> I have a 15-cp0001na
>
On 18/07/2019 16:02, Chunming Zhou wrote:
在 2019/7/18 19:31, Lionel Landwerlin 写道:
On 18/07/2019 14:13, Chunming Zhou wrote:
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
on syncobj,
then return non-block error code to user sapce.
Signed-off-by: Chunming Zhou
---
On Thu, Jul 18, 2019 at 5:11 AM Timur Kristóf wrote:
>
> On Fri, 2019-07-05 at 09:36 -0400, Alex Deucher wrote:
> > On Thu, Jul 4, 2019 at 6:55 AM Michel Dänzer
> > wrote:
> > > On 2019-07-03 1:04 p.m., Timur Kristóf wrote:
> > > > > > There may be other factors, yes. I can't offer a good
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #56 from Sylvain BERTRAND ---
Playing dota2 vulkan or GL?
I guess it's vulkan: and there I don't know how vulkan deal with multiple WSIs,
and how dota2 selects the one it will use.
The idea is to clearly identify the code paths
Playing dota2 vulkan or GL?
I guess it's vulkan: and there I don't know how vulkan deal with multiple WSIs,
and how dota2 selects the one it will use.
The idea is to clearly identify the code paths which would be "buggy".
(my custom distro is x11 native)
That said, I don't know the status of
Using 'imply' causes a new problem, as it allows the case of
CONFIG_INPUT=m with RC_CORE=y, which fails to link:
drivers/media/rc/rc-main.o: In function `ir_do_keyup':
rc-main.c:(.text+0x2b4): undefined reference to `input_event'
drivers/media/rc/rc-main.o: In function `rc_repeat':
在 2019/7/18 21:15, Zhou, David(ChunMing) 写道:
> 在 2019/7/18 21:10, Chris Wilson 写道:
>> Quoting Chunming Zhou (2019-07-18 14:04:09)
>>> 在 2019/7/18 19:18, Chris Wilson 写道:
Quoting Chunming Zhou (2019-07-18 12:13:39)
> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
Quoting Chunming Zhou (2019-07-18 14:15:49)
>
> 在 2019/7/18 21:10, Chris Wilson 写道:
> > Quoting Chunming Zhou (2019-07-18 14:04:09)
> >> 在 2019/7/18 19:18, Chris Wilson 写道:
> >>> Quoting Chunming Zhou (2019-07-18 12:13:39)
> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying
On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
> This series aims to add a led-backlight driver, similar to pwm-backlight,
> but using a LED class device underneath.
>
> A few years ago (2015), Tomi Valkeinen posted a series implementing a
> backlight driver on top of a LED device:
>
On Thu, Jun 27, 2019 at 04:10:36AM +0100, Lowry Li (Arm Technology China) wrote:
> Adds to print the event message when error happens and the same event
> will not be printed until next vsync.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> drivers/gpu/drm/arm/display/komeda/Makefile
在 2019/7/18 21:10, Chris Wilson 写道:
> Quoting Chunming Zhou (2019-07-18 14:04:09)
>> 在 2019/7/18 19:18, Chris Wilson 写道:
>>> Quoting Chunming Zhou (2019-07-18 12:13:39)
if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
syncobj,
then return non-block error
Quoting Chunming Zhou (2019-07-18 14:04:09)
>
> 在 2019/7/18 19:18, Chris Wilson 写道:
> > Quoting Chunming Zhou (2019-07-18 12:13:39)
> >> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
> >> syncobj,
> >> then return non-block error code to user sapce.
> > Block device
在 2019/7/18 19:18, Chris Wilson 写道:
> Quoting Chunming Zhou (2019-07-18 12:13:39)
>> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
>> syncobj,
>> then return non-block error code to user sapce.
> Block device required?
Yes, if WAIT_FOR_SUBMIT is set, then that will
在 2019/7/18 19:31, Lionel Landwerlin 写道:
> On 18/07/2019 14:13, Chunming Zhou wrote:
>> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence
>> on syncobj,
>> then return non-block error code to user sapce.
>>
>> Signed-off-by: Chunming Zhou
>> ---
>>
On Wed, Jul 17, 2019 at 9:08 PM Frederick Lawler wrote:
>
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
>
>
On Wed, Jul 17, 2019 at 9:08 PM Frederick Lawler wrote:
>
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
>
>
Cc devicet...@vger.kernel.org list - Rob once informed us this gets
higher priority in his queue this way.
On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> .../bindings/leds/backlight/led-backlight.txt | 28
Den 17.07.2019 22.46, skrev David Lechner:
> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>> tinydrm_display_pipe_init() has only one user now, so move it to
>> mipi-dbi.
>>
>> Changes:
>> - Remove drm_connector_helper_funcs.detect, it's always connected.
>> - Store the connector and mode in
Den 17.07.2019 22.09, skrev David Lechner:
> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>> The tinydrm helper is going away so move it into the only user mipi-dbi.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/tinydrm/mipi-dbi.c | 15 ---
>>
Den 17.07.2019 21.48, skrev David Lechner:
> On 7/17/19 6:58 AM, Noralf Trønnes wrote:
>> This is only used by mipi-dbi drivers so move it there.
>>
>> The reason this isn't moved to the SPI subsystem is that it will in a
>> later patch pass a dummy rx buffer for SPI controllers that need this.
Den 17.07.2019 22.37, skrev Hans de Goede:
> Hi Noralf,
>
> Thank you for the review.
>
> On 17-07-19 17:24, Noralf Trønnes wrote:
>>
>>
>> Den 12.07.2019 20.53, skrev Hans de Goede:
>>> Add a modesetting driver for Grain Media GM12U320 based devices
>>> (primarily Acer C120 projector, but
Am 18.07.2019 um 10:09 schrieb Daniel Vetter:
Not really harmful not to, but also not harm in grabbing the lock. And
this shuts up a new WARNING I introduced in commit ddde3c18b700 ("vt:
More locking checks").
Reported-by: Jens Remus
Cc: linux-ker...@vger.kernel.org
Cc:
101 - 200 of 220 matches
Mail list logo
