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:
https://patchwork.kernel.org/patch/7293991/https://patchwork.kernel.org/patch/7294001/https://patchwork.kernel.org/patch/7293981/
The discussion stopped because Tomi lacked the time to work on it.
changes in v4:
- fix dev_err() messages and commit logs following the …
[View More]advices of Pavel
- cosmetic changes (indents, getting rid of "? 1 : 0" in
led_match_led_node())
changes in v3:
- dt binding: don't limit the brightness range to 0-255. Use the range of
the underlying LEDs. as a side-effect, all LEDs must now have the same
range
- driver: Adapt to dt binding update.
- driver: rework probe() for clarity and remove the remaining goto.
changes in v2:
- handle more than one LED.
- don't make the backlight device a child of the LED controller.
- make brightness-levels and default-brightness-level optional
- removed the option to use a GPIO enable.
- removed the option to use a regulator. It should be handled by the LED
core
- don't make any change to the LED core (not needed anymore)
Jean-Jacques Hiblot (2):
leds: Add managed API to get a LED from a device driver
dt-bindings: backlight: Add led-backlight binding
Tomi Valkeinen (2):
leds: Add of_led_get() and led_put()
backlight: add led-backlight driver
.../bindings/leds/backlight/led-backlight.txt | 28 ++
drivers/leds/led-class.c | 92 ++++++
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 268 ++++++++++++++++++
include/linux/leds.h | 6 +
6 files changed, 402 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
create mode 100644 drivers/video/backlight/led_bl.c
--
2.17.1
[View Less]
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such as
x86/PAT: Overlap at 0xd0000000-0xd1000000
x86/PAT: reserve_memtype added [mem 0xd0000000-0xd02fffff], track write-combining, req write-combining, ret write-combining
x86/PAT: free_memtype request [mem 0xd0000000-0xd02fffff]
as reported at [1]. Drivers …
[View More]using VRAM helpers may also see reduced
performance as the mapping operations can create overhead.
In v3 and later of the patch set, this problem is being solved by lazily
unmapping the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap()
only changes a reference counter. VRAM helpers later perform the unmapping
operation when TTM evicts the buffer object from its current location. If
the buffer is never evicted, the existing mapping is reused by later calls
to drm_gem_vram_kmap().
v4:
* lock kmap with ttm_bo_reserve()
* acquire lock only once for vmap()
* warn about stale mappings during buffer cleanup
v3:
* implement lazy unmapping
v2:
* fixed comment typos
[1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html
Thomas Zimmermann (4):
drm/vram: Add kmap ref-counting to GEM VRAM objects
drm/vram: Acquire lock only once per call to vmap()/vunmap()
drm/vram: Add infrastructure for move_notify()
drm/vram: Implement lazy unmapping for GEM VRAM buffers
drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++++++++++++++++++--------
drivers/gpu/drm/drm_vram_mm_helper.c | 12 ++
include/drm/drm_gem_vram_helper.h | 18 ++
include/drm/drm_vram_mm_helper.h | 4 +
4 files changed, 198 insertions(+), 65 deletions(-)
--
2.23.0
[View Less]
The implementation of functions encoder_enable and encoder_disable
make possible to control the pinctrl according to the encoder type.
The pinctrl must be activated only if the encoder type is DPI.
This helps to move the DPI-related pinctrl configuration from
all the panel or bridge to the LTDC dt node.
Reviewed-by: Philippe Cornu <philippe.cornu(a)st.com>
Signed-off-by: Yannick Fertré <yannick.fertre(a)st.com>
---
drivers/gpu/drm/stm/ltdc.c | 35 ++++++++++++++++++++++++++++++++++…
[View More]+
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 3ab4fbf..1c4fde0 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/of_address.h>
#include <linux/of_graph.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/reset.h>
@@ -1040,6 +1041,36 @@ static const struct drm_encoder_funcs ltdc_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
+static void ltdc_encoder_disable(struct drm_encoder *encoder)
+{
+ struct drm_device *ddev = encoder->dev;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ /* Set to sleep state the pinctrl whatever type of encoder */
+ pinctrl_pm_select_sleep_state(ddev->dev);
+}
+
+static void ltdc_encoder_enable(struct drm_encoder *encoder)
+{
+ struct drm_device *ddev = encoder->dev;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ /*
+ * Set to default state the pinctrl only with DPI type.
+ * Others types like DSI, don't need pinctrl due to
+ * internal bridge (the signals do not come out of the chipset).
+ */
+ if (encoder->encoder_type == DRM_MODE_ENCODER_DPI)
+ pinctrl_pm_select_default_state(ddev->dev);
+}
+
+static const struct drm_encoder_helper_funcs ltdc_encoder_helper_funcs = {
+ .disable = ltdc_encoder_disable,
+ .enable = ltdc_encoder_enable,
+};
+
static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge *bridge)
{
struct drm_encoder *encoder;
@@ -1055,6 +1086,8 @@ static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge *bridge)
drm_encoder_init(ddev, encoder, <dc_encoder_funcs,
DRM_MODE_ENCODER_DPI, NULL);
+ drm_encoder_helper_add(encoder, <dc_encoder_helper_funcs);
+
ret = drm_bridge_attach(encoder, bridge, NULL);
if (ret) {
drm_encoder_cleanup(encoder);
@@ -1280,6 +1313,8 @@ int ltdc_load(struct drm_device *ddev)
clk_disable_unprepare(ldev->pixel_clk);
+ pinctrl_pm_select_sleep_state(ddev->dev);
+
pm_runtime_enable(ddev->dev);
return 0;
--
2.7.4
[View Less]
I missed that when extending the lockdep annotations to the
nonblocking case.
I missed this while testing since in the i915 mmu notifiers is hitting
a nice lockdep splat already before the point of going into oom killer
mode :-/
Reported-by: syzbot+aaedc50d99a03250fe1f(a)syzkaller.appspotmail.com
Fixes: d2b219ed03d4 ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end")
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Cc: Daniel Vetter <daniel.vetter(a)intel.com>
Cc: …
[View More]Andrew Morton <akpm(a)linux-foundation.org>
Cc: "Jérôme Glisse" <jglisse(a)redhat.com>
Cc: Ralph Campbell <rcampbell(a)nvidia.com>
Cc: Jason Gunthorpe <jgg(a)ziepe.ca>
Cc: Ira Weiny <ira.weiny(a)intel.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Sean Christopherson <sean.j.christopherson(a)intel.com>
Cc: Jean-Philippe Brucker <jean-philippe(a)linaro.org>
Cc: linux-mm(a)kvack.org
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
---
include/linux/mmu_notifier.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 5a03417e5bf7..4edd98b06834 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -356,13 +356,14 @@ mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
static inline int
mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
{
+ int ret = 0;
lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
- return __mmu_notifier_invalidate_range_start(range);
+ ret = __mmu_notifier_invalidate_range_start(range);
}
lock_map_release(&__mmu_notifier_invalidate_range_start_map);
- return 0;
+ return ret;
}
static inline void
--
2.23.0
[View Less]
From: Yakir Yang <ykk(a)rock-chips.com>
When transmitting IEC60985 linear PCM audio, we configure the
Aduio Sample Channel Status information of all the channel
status bits in the IEC60958 frame.
Refer to 60958-3 page 10 for frequency, original frequency, and
wordlength setting.
This fix the issue that audio does not come out on some monitors
(e.g. LG 22CV241)
Note that these registers are only for interfaces:
I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
(…
[View More]AHBAUDDMA).
For S/PDIF interface this information comes from the stream.
Currently this function dw_hdmi_set_channel_status is only called
from dw-hdmi-i2s-audio in I2S setup.
Signed-off-by: Yakir Yang <ykk(a)rock-chips.com>
Signed-off-by: Cheng-Yi Chiang <cychiang(a)chromium.org>
---
Original patch by Yakir Yang is at
https://lore.kernel.org/patchwork/patch/539653/
Change from v1 to v2:
1. Remove the version check because this will only be called by
dw-hdmi-i2s-audio, and the registers are available in I2S setup.
2. Set these registers in dw_hdmi_i2s_hw_params.
3. Fix the sample width setting so it can use 16 or 24 bits.
.../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++++++
include/drm/bridge/dw_hdmi.h | 2 +
4 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 34d8e837555f..b801a28b0f17 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
}
dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
+ dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
dw_hdmi_set_channel_count(hdmi, hparms->channels);
dw_hdmi_set_channel_allocation(hdmi, hparms->cea.channel_allocation);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bd65d0479683..d1daa369c8ae 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk)
return n;
}
+/*
+ * When transmitting IEC60958 linear PCM audio, these registers allow to
+ * configure the channel status information of all the channel status
+ * bits in the IEC60958 frame. For the moment this configuration is only
+ * used when the I2S audio interface, General Purpose Audio (GPA),
+ * or AHB audio DMA (AHBAUDDMA) interface is active
+ * (for S/PDIF interface this information comes from the stream).
+ */
+void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
+ unsigned int sample_width)
+{
+ u8 aud_schnl_samplerate;
+ u8 aud_schnl_8;
+ u8 word_length_bits;
+
+ switch (hdmi->sample_rate) {
+ case 32000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
+ break;
+ case 44100:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
+ break;
+ case 48000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
+ break;
+ case 88200:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
+ break;
+ case 96000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
+ break;
+ case 176400:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
+ break;
+ case 192000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
+ break;
+ case 768000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
+ break;
+ default:
+ dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
+ hdmi->sample_rate);
+ return;
+ }
+
+ /* set channel status register */
+ hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
+ HDMI_FC_AUDSCHNLS7);
+
+ /*
+ * Set original frequency to be the same as frequency.
+ * Use one-complement value as stated in IEC60958-3 page 13.
+ */
+ aud_schnl_8 = (~aud_schnl_samplerate) <<
+ HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
+
+ /*
+ * Refer to IEC60958-3 page 12. We can accept 16 bits or 24 bits.
+ * Otherwise, set the register to 0t o indicate using default value.
+ */
+ word_length_bits = (sample_width == 16) ? 0x2 :
+ ((sample_width == 24) ? 0xb : 0);
+
+ aud_schnl_8 |= word_length_bits << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
+
+ hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_set_channel_status);
+
static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
unsigned long pixel_clk, unsigned int sample_rate)
{
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index 6988f12d89d9..619ebc1c8354 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -158,6 +158,17 @@
#define HDMI_FC_SPDDEVICEINF 0x1062
#define HDMI_FC_AUDSCONF 0x1063
#define HDMI_FC_AUDSSTAT 0x1064
+#define HDMI_FC_AUDSV 0x1065
+#define HDMI_FC_AUDSU 0x1066
+#define HDMI_FC_AUDSCHNLS0 0x1067
+#define HDMI_FC_AUDSCHNLS1 0x1068
+#define HDMI_FC_AUDSCHNLS2 0x1069
+#define HDMI_FC_AUDSCHNLS3 0x106a
+#define HDMI_FC_AUDSCHNLS4 0x106b
+#define HDMI_FC_AUDSCHNLS5 0x106c
+#define HDMI_FC_AUDSCHNLS6 0x106d
+#define HDMI_FC_AUDSCHNLS7 0x106e
+#define HDMI_FC_AUDSCHNLS8 0x106f
#define HDMI_FC_DATACH0FILL 0x1070
#define HDMI_FC_DATACH1FILL 0x1071
#define HDMI_FC_DATACH2FILL 0x1072
@@ -706,6 +717,15 @@ enum {
/* HDMI_FC_AUDSCHNLS7 field values */
HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4,
HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_88K2 = 0x8,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_32K = 0x3,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_48K = 0x2,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_44K1 = 0x0,
/* HDMI_FC_AUDSCHNLS8 field values */
HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_MASK = 0xf0,
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index cf528c289857..12144d2f80f4 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -156,6 +156,8 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
void dw_hdmi_set_channel_count(struct dw_hdmi *hdmi, unsigned int cnt);
+void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
+ unsigned int sample_width);
void dw_hdmi_set_channel_allocation(struct dw_hdmi *hdmi, unsigned int ca);
void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
--
2.23.0.187.g17f5b7556c-goog
[View Less]
Hello,
This series, whose previous version was named "[PATCH v2 0/4] drm/panel:
Extend panels to report their types" and is available at
https://www.spinics.net/lists/dri-devel/msg224579.html, allows panels to
report their type, in order to create drm_connector instances with
appropriate types in the upper layers.
In patch 1/2 the drm_panel structure receives a new connector_type field
to report its type, set through drm_panel_init(), and all connector
drivers are updated accordingly. The …
[View More]panel-simple driver however only
reports the LVDS connector type for known-to-be-LVDS panels, while all
other leave the field initialised to 0, corresponding to
DRM_MODE_CONNECTOR_Unknown. Panels supported by that driver will need to
be reviewed one by one and their type updated. This was done to avoid
reporting an incorrect type, allowing upper layers to catch
DRM_MODE_CONNECTOR_Unknown and WARN() to trigger an update of the
corresponding panel.
Patch 2/2 then modifies drm_panel_bridge_add() and its devm_ counterpart
to replace the connector type argument with the type reported by the
panel. This can't unfortunately be forced upon all drivers as several of
them hardcode a DRM_MODE_CONNECTOR_Unknown type, and would then change
the connector type reported to userspace, leading to possible breakages.
A new function, drm_panel_bridge_add_typed(), is added with the existing
behaviour of drm_panel_bridge_add() to create a panel bridge with a
forced connector type, and drivers are switched to using that function.
They should then be switched back one by one to drm_panel_bridge_add()
after careful review (and clever handling of the connector type change
issue). The drm_panel_bridge_add_typed() function is marked as
deprecated and should not be used in new code.
During review of v2, the question of whether to introduce a new
DRM_MODE_CONNECTOR_PANEL was raised. This is still being discussed, but
such a change would still need to expose the existing panel types for
backward compatibility, and this series wouldn't hinder this in any way.
I thus believe that we should merge it sooner than later without waiting
for the DRM_MODE_CONNECTOR_PANEL discussion to settle.
The patches are available at
git://linuxtv.org/pinchartl/media.git omapdrm/panels
Laurent Pinchart (2):
drm/panel: Add and fill drm_panel type field
drm/bridge: panel: Infer connector type from panel by default
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 3 +-
drivers/gpu/drm/bridge/cdns-dsi.c | 3 +-
drivers/gpu/drm/bridge/lvds-encoder.c | 3 +-
drivers/gpu/drm/bridge/panel.c | 69 ++++++++++++++++---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 +-
drivers/gpu/drm/drm_panel.c | 5 +-
drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +-
drivers/gpu/drm/mcde/mcde_dsi.c | 4 +-
drivers/gpu/drm/panel/panel-arm-versatile.c | 3 +-
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +-
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 +-
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +-
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 +-
.../gpu/drm/panel/panel-jdi-lt070me05000.c | 3 +-
.../drm/panel/panel-kingdisplay-kd097d04.c | 2 +-
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 3 +-
drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 +-
drivers/gpu/drm/panel/panel-lvds.c | 3 +-
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 3 +-
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 3 +-
.../drm/panel/panel-olimex-lcd-olinuxino.c | 3 +-
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 +-
.../drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
.../drm/panel/panel-panasonic-vvx10f034n00.c | 2 +-
.../drm/panel/panel-raspberrypi-touchscreen.c | 3 +-
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +-
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 +-
.../drm/panel/panel-rocktech-jh057n00900.c | 3 +-
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 +-
.../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 +-
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 +-
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 +-
.../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 +-
.../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 3 +-
.../gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
drivers/gpu/drm/panel/panel-simple.c | 26 ++++++-
drivers/gpu/drm/panel/panel-sitronix-st7701.c | 3 +-
.../gpu/drm/panel/panel-sitronix-st7789v.c | 3 +-
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 3 +-
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 +-
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 3 +-
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 3 +-
drivers/gpu/drm/panel/panel-truly-nt35597.c | 3 +-
drivers/gpu/drm/pl111/pl111_drv.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 +-
drivers/gpu/drm/rockchip/rockchip_rgb.c | 3 +-
drivers/gpu/drm/stm/ltdc.c | 4 +-
drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +-
drivers/gpu/drm/tve200/tve200_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_dpi.c | 3 +-
drivers/gpu/drm/vc4/vc4_dsi.c | 4 +-
include/drm/drm_bridge.h | 11 +--
include/drm/drm_panel.h | 12 +++-
57 files changed, 205 insertions(+), 78 deletions(-)
--
Regards,
Laurent Pinchart
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=110630
--- Comment #8 from Eugene Uzix <uzix.ls+bugsfreedesktop(a)gmail.com> ---
Same issue on
Radeon RX 580
Linux 5.2.0-2-amd64 #1 SMP Debian 5.2.9-1 (2019-08-18)
Actual Debian Sid
X.Org X Server 1.20.4, amdgpu 19.0.1
Openbox + compton
Killing compton does not help.
--
You are receiving this mail because:
You are the assignee for the bug.