This fixes a problem found on the MacBookPro 2017 Retina panel.
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbp
Hi Inki,
On 05.03.2020 09:01, Inki Dae wrote:
> Hi Marek,
>
> 20. 3. 2. 오후 11:27에 Marek Szyprowski 이(가) 쓴 글:
>> Store the IOMMU mapping created by device core of each Exynos DRM
>> sub-device and restore it when Exynos DRM driver is unbound. This fixes
>> IOMMU initialization failure for the secon
From: Chandan Uddaraju
Add bindings for Snapdragon DisplayPort and
display-port PLL driver.
Changes in V2:
Provide details about sel-gpio
Changes in V4:
Provide details about max dp lanes
Change the commit text
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
---
.../devicetree/bin
On Tue, Mar 03, 2020 at 10:04:56PM -0500, Jonathan Marek wrote:
> If I have time to kill over the weekend I'll do a new rebase of my Nexus 5
> patches (my last rebase was back in August on 5.2, and the panel was working
> correctly at 60Hz back then).
That would be great if you have time to look a
is_color_space_conversion() is a misnomer. It checks not only if color
space conversion is needed, but also if format conversion is needed.
This is actually desired behaviour because result of this function
determines if CSC block should be enabled or not (CSC block can also do
format conversion).
Hi Emil,
Thanks for your feedback
On Tue, Mar 3, 2020 at 2:29 AM Emil Velikov
wrote:
> Hi Kevin,
>
> There's a few small suggestions, although overall the driver looks a lot
> better.
>
> On Thu, 27 Feb 2020 at 08:14, Kevin Tang wrote:
>
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/dpu/Make
On Wed, 4 Mar 2020 at 17:28, Xinliang Liu wrote:
>
> On Wed, 4 Mar 2020 at 00:32, John Stultz wrote:
> >
> > This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592.
> >
> > With the commit ff57c6513820 ("drm: kirin: Fix for hikey620
> > display offset problem") we added support for handling
komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when
CONFIG_PM is enabled. Having it disabled triggers the following warning
at compile time:
linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12:
warning: ‘komeda_rt_pm_resume’ defined but not used [-Wunused-function]
st
CEA 861 standard requestis that RGB quantization range is "limited" for
CEA modes. Support that by adding CSC matrix which downscales values.
This allows proper color reproduction on TV and PC monitor at the same
time. In future, override property can be added, like "Broadcast RGB"
in i915 driver.
Currently, WLED driver supports only WLED4 peripherals that is present
on pmi8998 and pm660L. This patch series converts the existing WLED4
bindings from .txt to .yaml format and adds the support for WLED5 peripheral
that is present on PM8150L.
PM8150L WLED supports the following.
- Two modul
Add support for WLED5 peripheral that is present on PM8150L PMICs.
PM8150L WLED supports the following.
- Two modulators and each sink can use any of the modulator
- Multiple CABC selection options
- Multiple brightness width selection (12 bits to 15 bits)
Signed-off-by: Kiran Gunda
The msm DSI driver does predate the addition of those fields and doesn't
use them at all.
Seems like it would be a bit of a hack too, since the frequency we want
to use is not the "real limits of the hardware"..
On 3/4/20 4:10 AM, Linus Walleij wrote:
On Mon, Mar 2, 2020 at 9:49 PM Jonathan
On Fri, Feb 28, 2020 at 12:50 AM Rob Herring wrote:
> On Wed, Feb 26, 2020 at 3:46 AM Kevin Tang wrote:
> >
> > From: Kevin Tang
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that comprise the
> > graphics subsystem
On Wed, 4 Mar 2020 at 00:32, John Stultz wrote:
>
> This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592.
>
> With the commit ff57c6513820 ("drm: kirin: Fix for hikey620
> display offset problem") we added support for handling LDI
> overflows by resetting the hardware.
>
> However, its bee
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the Snapdragon Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DE
Hi Ville, hi Christoph,
On 03.03.20 14:13, Christoph Fritz wrote:
On Mon, 2020-03-02 at 22:34 +0200, Ville Syrjala wrote:
From: Ville Syrjälä
The currently listed dotclock disagrees with the currently
listed vrefresh rate. Change the dotclock to match the vrefresh.
Someone tell me which (if
From: Jonas Karlman
Setting scan mode to "none" confuses some TVs like LG B8, which randomly
change overscan percentage over time. Digital outputs like HDMI and DVI,
handled by this controller, don't really need overscan, so we can always
set scan mode to underscan. Actually, this is exactly what
On 3/4/20 5:07 PM, Emil Velikov wrote:
> On Mon, 3 Feb 2020 at 08:11, Benjamin Gaignard
> wrote:
>> Fix kernel doc comments to avoid warnings when compiling with W=1.
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> drivers/gpu/drm/drm_context.c | 145
>> ++-
Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
renamed include/linux/reservation.h to include/linux/dma-resv.h, but
missed the reference in the MAINTAINERS entry.
Since then, ./scripts/get_maintainer.pl --self-test complains:
warning: no file matches F: include/linux/res
On Tue, Mar 03, 2020 at 09:27:50PM -0500, Jonathan Marek wrote:
> modetest should be printing "freq: 60.0Hz", so definitely something wrong
> there. Though I guess you have another problem since I would expect the
> patch to drop it to 30 and not 13.5.
So I reverted the following three commits rel
Hi CK,
Thanks for your comment.
On Wed, 2020-03-04 at 11:05 +0800, CK Hu wrote:
> Hi, Dennis:
>
> On Tue, 2020-03-03 at 18:58 +0800, Dennis YC Hsieh wrote:
> > Add clear parameter to let client decide if
> > event should be clear to 0 after GCE receive it.
> >
> > Signed-off-by: Dennis YC Hsieh
From: Chandan Uddaraju
The constant N value (0x8000) is used by multiple DP
drivers. Define this value in header file and use this
in the existing i915 display driver.
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
include/dr
This series fixes multiple issues I found out.
Patch 1 fixes reporting colorimetry in AVI frame.
Patch 2 sets scan mode to underscan which is in line with most other
hdmi drivers.
Patch 3 aligns RGB quantization to CEA 861 standard.
Patch 4 reworks is_color_space_conversion(). Now it checks only if
Convert the qcom-wled bindings from .txt to .yaml format.
Signed-off-by: Kiran Gunda
---
.../bindings/leds/backlight/qcom-wled.txt | 154 -
.../bindings/leds/backlight/qcom-wled.yaml | 184 +
2 files changed, 184 insertions(+), 154 deletions(-
There is a memory leak which left some objects not freed. The reference
counter of mapping: 'mapping->kref' was 2 when calling
arm_iommu_detach_device(), so the release_iommu_mapping() won't be called.
Since the old mapping structure is not going to be used any more (because
it is detached and new
CTA-861-F explicitly states that for RGB colorspace colorimetry should
be set to "none". Fix that.
Acked-by: Laurent Pinchart
Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and
encodings")
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 ++
These patches add support for Display-Port driver on SnapDragon hardware. It
adds
DP driver and DP PLL driver files along with the needed device-tree bindings.
The block diagram of DP driver is shown below:
+-+
|DRM FRAMEWORK|
+
Hi CK,
Thanks for your comment.
On Wed, 2020-03-04 at 10:57 +0800, CK Hu wrote:
> Hi, Dennis:
>
> On Tue, 2020-03-03 at 18:58 +0800, Dennis YC Hsieh wrote:
> > Add jump function so that client can jump to any address which
> > contains instruction.
> >
> > Signed-off-by: Dennis YC Hsieh
> > --
On Wed, Mar 4, 2020 at 4:32 PM Jani Nikula wrote:
>
> On Sat, 29 Feb 2020, Mario Kleiner wrote:
> > This fixes a problem found on the MacBookPro 2017 Retina panel.
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link settings at boot which support enough
> >
Certain laptops now come with panels that have integrated privacy
screens on them. This patch adds support for such panels by adding
a privacy-screen property to the intel_connector for the panel, that
the userspace can then use to control and check the status.
Identifying the presence of privacy
Certain laptops now come with panels that have integrated privacy
screens on them. This patch adds support for such panels by adding
a privacy-screen property to the intel_connector for the panel, that
the userspace can then use to control and check the status.
Identifying the presence of privacy
On Thu, 05 Mar 2020, Mario Kleiner wrote:
> This fixes a problem found on the MacBookPro 2017 Retina panel.
>
> The panel reports 10 bpc color depth in its EDID, and the
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
> but t
On Thu, 05 Mar 2020, Jani Nikula wrote:
> On Thu, 05 Mar 2020, Mario Kleiner wrote:
>> This fixes a problem found on the MacBookPro 2017 Retina panel.
>>
>> The panel reports 10 bpc color depth in its EDID, and the
>> firmware chooses link settings at boot which support enough
>> bandwidth for 10
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Change the struct drm_device * local variable from drm_dev to dev
> per the feedback received here:
> https://lkml.org/lkml/2020/1/24/1143
>
> Signed-off-by: Rajat Jain
Reviewed-by: Jani Nikula
> ---
> v6: Initial patch (v6 to match other patches in the
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Lookup and attach ACPI nodes for intel connectors. The lookup is done
> in compliance with ACPI Spec 6.3
> https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> (Ref: Pages 1119 - 1123).
>
> This can be useful for any connector specific
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to control and check t
On Wed, 04 Mar 2020, Rajat Jain wrote:
> Change the struct drm_device * local variable from drm_dev to dev
> per the feedback received here:
> https://lkml.org/lkml/2020/1/24/1143
I don't know what's up with the two identical (or similar) threads here,
but I replied in the thread starting at [1].
drm-misc-fixes-2020-03-05:
Fixes for v5.6.rc5:
- Fix memory leak
- Fix resource id creation race in virtio.
- Various mmap fixes.
- Fix fence leak in ttm_buffer_object_transfer().
- Fixes for sun4i VI layer format support.
- kirin: Revert "Fix for hikey620 display offset problem"
The following chan
Hi Dave & Daniel -
drm-intel-fixes-2020-03-05:
drm/i915 fixes for v5.6-rc5:
- Break up long lists of object reclaim with cond_resched()
- PSR probe fix
- TGL workarounds
- Selftest return value fix
- Drop timeline mutex while waiting for retirement
- Wait for OA configuration completion before wr
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
Hi Gustavo,
I've adjusted the subject a bit to match the style of the other etnaviv
driver commits and applied this to the etnaviv/next branch.
Regards,
Lucas
On Do, 2020-03-05 at 04:51 -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extensi
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By ma
Hi Lucas,
On 3/5/20 05:17, Lucas Stach wrote:
> Hi Gustavo,
>
> I've adjusted the subject a bit to match the style of the other etnaviv
> driver commits and applied this to the etnaviv/next branch.
>
Great. Thanks a lot for that. :)
--
Gustavo
> Regards,
> Lucas
>
> On Do, 2020-03-05 at 04:51
On Thu, 05 Mar 2020, "Gustavo A. R. Silva" wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Re
The max connector argument for drm_fb_helper_init() isn't used anymore
hence remove it.
All the drm_fb_helper_init() calls are modified with below sementic
patch.
@@
expression E1, E2, E3;
@@
- drm_fb_helper_init(E1,E2, E3)
+ drm_fb_helper_init(E1,E2)
Signed-off-by: Pankaj Bharadiya
Reviewed-
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Re
This series addresses below drm_fb_helper tasks from
Documentation/gpu/todo.rst.
- The max connector argument for drm_fb_helper_init() isn't used
anymore and can be removed.
- The helper doesn't keep an array of connectors anymore so these can
be removed: drm_fb_helper_single_add_all_connecto
drm_fb_helper_single_add_all_connectors(),
drm_fb_helper_add_one_connector()
and drm_fb_helper_remove_one_connector() don't keep an array of
connectors anymore and are just dummy. Now we have no callers to these
functions hence remove them.
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Laurent Pin
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Emil Velikov
Re
drm_fb_helper_{add,remove}_one_connector() and
drm_fb_helper_single_add_all_connectors() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
This removal is
drm_fb_helper tasks are completed now hence remove them from
todo list.
Changes since v1:
* remove entire drm_fb_helper tasks from todo list. Daniel's
"64914da24ea9 drm/fbdev-helper: don't force restores" already fixes
first one (Daniel)
Signed-off-by: Pankaj Bharadiya
Reviewed-by: Laurent P
Am 04.03.20 um 17:41 schrieb Jason Ekstrand:
On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand wrote:
On Wed, Mar 4, 2020 at 2:34 AM Christian König wrote:
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König
wrote:
[SNIP]
For reference see what dance i
On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> It's next to impossible for us to do connector probing on topologies
> without occasionally racing with userspace, since creating a connector
> itself causes a hotplug event which we have to send before probing the
> available PBN of a c
Am 05.03.20 um 14:29 schrieb Nirmoy Das:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Looks like this is the only patch without an rb or at least acked-by.
Can anybody comment or at least throw a quick tested-by on it?
With that done I would say I would pick
Am 05.03.20 um 14:29 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/tt
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 9 -
> 1 file changed, 8 insertio
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
Hi
Am 05.03.20 um 15:07 schrieb Gerd Hoffmann:
> On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
>> Calculate GEM VRAM bo's offset within vram-helper without depending on
>> bo->offset.
>>
>> Signed-off-by: Nirmoy Das
>> Reviewed-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_gem_v
On 3/5/20 3:07 PM, Gerd Hoffmann wrote:
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9
Am 05.03.20 um 15:35 schrieb Nirmoy:
On 3/5/20 3:07 PM, Gerd Hoffmann wrote:
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/d
On Thu, Mar 5, 2020 at 7:06 AM Christian König wrote:
>
> Am 04.03.20 um 17:41 schrieb Jason Ekstrand:
> > On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand wrote:
> >> On Wed, Mar 4, 2020 at 2:34 AM Christian König
> >> wrote:
> >>> Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
> On Thu, Feb
The gma500 driver uses empty implementations for some of its encoders.
Replace the code with the generic simple encoder. As a side effect, the
patch also removes an indirection in the encoder setup for Medfield.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 14
The atmel-hlcdc driver uses an empty implementation for its encoder.
Replace the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gp
The kirin driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon
The rockchip driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++--
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +++--
drivers/gpu/drm/
The shmobile driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sh
The fsl-dcu driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/fs
The vc4 driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_dpi.c | 8 ++--
drivers/gpu/drm/vc4/vc4_dsi.c | 15 +++
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 --
The writeback code uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_writeback.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b
The zte driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/zte/zx_hdmi.c | 8 ++--
drivers/gpu/drm/zte/zx_tvenc.c | 8 ++--
drivers/gpu/drm/zte/zx_vga.c | 8 ++--
3 files change
The exynos driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/exynos/exynos_dp.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_ds
The tidss driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_encoder.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_e
The virtgpu driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virt
The rcar-du driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rc
The ingenic driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 +++-
drivers/gpu/drm/sun4i/sun4i_lvds.c | 12 +++-
drivers/gpu/drm/sun4i/sun4i_r
The imx driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 8 ++--
drivers/gpu/drm/imx/imx-drm-core.c | 6 --
drivers/gpu/drm/imx/imx-drm.h | 1 -
The arc driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/arc/arcpgu_hdmi.c | 10 +++---
drivers/gpu/drm/arc/arcpgu_sim.c | 8 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
A call to drm_simple_encoder_init() initializes an encoder without
further functionality. It only provides the destroy callback to
cleanup the encoder's state. Only few drivers implement more
sophisticated encoders than that. Most drivers implement such a
simple encoder and can use drm_simple_encod
The tilcdc driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 +++---
drivers/gpu/drm/tilcdc/tilcdc_panel.c| 8 ++--
2 files changed, 5 insertions(+)
The ingenic driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingen
The tegra driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tegra/drm.h| 2 --
drivers/gpu/drm/tegra/dsi.c| 10 +++---
drivers/gpu/drm/tegra/hdmi.c | 9 +++--
drivers/gpu/
The vkms driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vkms/vkms_output.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
The mediatak driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
2 files changed, 6 insertions(+)
The tda998x driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998
On Wed, Mar 4, 2020 at 10:33 AM Mika Westerberg
wrote:
>
> Hi,
>
> On Tue, Mar 03, 2020 at 11:10:52AM +0100, Karol Herbst wrote:
> > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> > states.
>
> I think it is good to explain bit more here why this fix is needed.
>
i
Hi Lyude,
On 3/4/20 11:36 PM, Lyude Paul wrote:
AMD's patch series for adding DSC support to the MST helpers
unfortunately introduced a few regressions into the kernel that I didn't
get around to fixing until just now. I would have reverted the changes
earlier, but seeing as that would have reve
On Thu, Mar 5, 2020 at 8:00 AM Thomas Zimmermann wrote:
>
> The vc4 driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
Acked-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
From: Monk Liu
[ Upstream commit 4829f89855f1d3a3d8014e74cceab51b421503db ]
fix system memory leak
v2:
fix coding style
Signed-off-by: Monk Liu
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 +-
1 fil
From: Monk Liu
[ Upstream commit 4829f89855f1d3a3d8014e74cceab51b421503db ]
fix system memory leak
v2:
fix coding style
Signed-off-by: Monk Liu
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 +-
1 fil
On Wed, Feb 19, 2020 at 6:00 AM Lin, Wayne wrote:
>
> [AMD Public Use]
>
>
>
> > -Original Message-
> > From: Sean Paul
> > Sent: Wednesday, February 19, 2020 1:15 AM
> > To: Lin, Wayne
> > Cc: Sean Paul ; dri-devel@lists.freedesktop.org;
> > ly...@redhat.com; Sean Paul ; Maarten Lankhor
On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > It's next to impossible for us to do connector probing on topologies
> > without occasionally racing with userspace, since creating a connector
> > itself causes a hotplug event
On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra
wrote:
>
> Hi Vasily,
CC: Icenowy and Ondrej
>
> Would you mind to check which firmware version is running the anx7688 in
> PinePhone, I think should be easy to check with i2c-tools.
Icenowy, Ondrej, can you guys please check anx7688 firmware
1 - 100 of 158 matches
Mail list logo
