Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
Hi
Am 06.03.20 um 04:42 schrieb Tian Tao:
> using the load and unload function provided by drm framework instead of
> doing the same work in the hibmc_pci_probe and do some code cleanup.
>
> Signed-off-by: Tian Tao
> Signed-off-by: Gong junjie
> ---
>
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
On Thu, Mar 05, 2020 at 05:11:57PM +0100, Karol Herbst wrote:
> 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
> >
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
devfreq, and provides OPP table with 2 sets of voltages.
TODO: This is incomplete as we'll need add support for setting
a pair of voltages as well. I also realized that the out-of-tree
driver has complex logic to ensure voltage delta
On Fri, Mar 06, 2020 at 02:42:55AM +0800, Liviu Dudau wrote:
> On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
> > 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
Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
v5:
- Rename "2d" power domain to "core2"
v4:
- Add power-domain-names description
(kept Alyssa's reviewed-by as the change is minor)
v3:
Hi!
Follow-up on the v4: https://patchwork.kernel.org/cover/11369777/, some
of the core patches got merged already (thanks Rob!).
The main purpose of this series is to upstream the dts change and the
binding document, but I wanted to see how far I could probe the GPU, to
check that the binding
Add a basic GPU node for mt8183.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1411
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
---
v5:
- Change power domain name from 2d to core2.
v4:
- Add power domain names.
v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power
On Tue, Jan 07, 2020 at 10:53:19PM +0100, Arnd Bergmann wrote:
> Without this, we get a couple of warnings when CONFIG_PM
> is disabled:
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12: error:
> 'komeda_rt_pm_resume' defined but not used [-Werror=unused-function]
> static int
On Fri, Mar 6, 2020 at 10:34 AM Nick Fan wrote:
>
> Sorry for my late reply.
> I have checked internally.
> The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
> domain.
>
> If the naming too confusing, we can change this name to
> MT8183_POWER_DOMAIN_MFG_CORE2 for consistency.
Hi Linus,
Weekly fixes round, looks like a few people woke up, got a bunch of
fixes across the drivers. Bit bigger than I'd like but they all seem
fine and hopefully it quiets down now.
sun4i, kirin, mediatek and exynos on the ARM side.
virtio-gpu and core have some mmap fixes, and there is a
Am Samstag, 29. Februar 2020, 16:15:06 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner
>
> Panel driver for the KD35T133 display from Elida, used for example
> in the rk3326-based Odroid Go Advance handheld.
>
> changes in v3:
> - add missing return value assignment (Francesco)
> - re-sort
This patch adds defines for the detailed monitor
range flags as per the EDID specification.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Signed-off-by: Manasi Navare
---
include/drm/drm_edid.h | 5 +
1 file changed, 5
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
Am Samstag, 29. Februar 2020, 16:15:05 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner
>
> The KD35T133 is a 3.5" 320x480 DSI display used in the RK3326-based
> Odroid Go Advance handheld device.
>
> Signed-off-by: Heiko Stuebner
> Reviewed-by: Sam Ravnborg
applied to drm-misc-next with
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied
On Mon, Mar 2, 2020 at 2:57 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-03-02 1:17 a.m., Mario Kleiner wrote:
> > Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
> > events at vsartup for DCN")' introduces a new way of pageflip
> > completion handling for DCN, and some trouble.
> >
>
Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
Quoting Enric Balletbo i Serra (2020-03-02 03:01:25)
> The mmsys system controller is not only a pure clock controller, so
> update the binding documentation to reflect that apart from providing
> clocks, it also provides routing and miscellaneous control registers.
>
> Signed-off-by: Enric
Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
> From: Matthias Brugger
>
> There is no strong reason for this to use CLK_OF_DECLARE instead of
> being a platform driver.
Cool.
> Plus, this driver provides clocks but also
> a shared register space for the mediatek-drm and the
On 2020-03-05 14:37, Ho, Kenny wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
>
> I believe bo->tbo.mem.mem_type is of uint32_t type and not an enum, is the
> index lookup method safe? (i.e., how do you deal with the possibility of
> having value TTM_PL_PRIV or above or are
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Changes in v4:
-Added to the set
Changes in v5:
-None
---
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
Changes in v5:
-Added to the set
---
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable
From: Sean Paul
Hello friends,
Another version of HDCP over MST rebased on -tip (pls stop refactoring
stuff!).
I've also added a couple of fixes to fix bugs found when I did some testing
I on a non-CrOS laptop.
PTAL,
Sean
Sean Paul (16):
drm/i915: Fix sha_text population code
drm/i915:
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
On Thu, 2020-03-05 at 13:52 -0500, Lyude Paul wrote:
> On Thu, 2020-03-05 at 20:29 +0200, Ville Syrjälä wrote:
> > On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> > > 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
[AMD Official Use Only - Internal Distribution Only]
I believe bo->tbo.mem.mem_type is of uint32_t type and not an enum, is the
index lookup method safe? (i.e., how do you deal with the possibility of having
value TTM_PL_PRIV or above or are you suggesting those are not possible for
this
On 2020-03-05 08:29, Nirmoy Das wrote:
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6
On 2020-03-05 08:29, Nirmoy Das wrote:
> Calculate GPU offset in radeon_bo_gpu_offset without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-and-tested-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_object.h | 16
On 2020-03-05 08:29, Nirmoy Das wrote:
> GPU address should belong to driver not in memory management.
> This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
>
> Signed-off-by: Nirmoy Das
> Acked-by: Huang Rui
> Reviewed-by: Christian König
> ---
>
Hi Dave, Daniel,
Fixes for 5.6.
The following changes since commit 70b8ea1ab1d3ff3ad5c7491bf8995c912506da6c:
Merge tag 'mediatek-drm-fixes-5.6' of
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes (2020-03-05
12:59:44 +1000)
are available in the Git repository at:
On Thu, 2020-03-05 at 20:29 +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> > 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
On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
> 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:
>
>
On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> 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
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
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
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
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
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
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
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
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.
>
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
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 +++--
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
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
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
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
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 +++-
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
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 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
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
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
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
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 ++--
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
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
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 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 +++--
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
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
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 |
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
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
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
---
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
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
>> ---
>>
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 {
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
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 --
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
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
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
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
1 - 100 of 158 matches
Mail list logo
