Re: [linux-sunxi] [PATCH v3 1/1] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio

On 1/29/20 6:34 PM, Chen-Yu Tsai wrote: On Tue, Jan 28, 2020 at 10:07 PM Stefan Mavrodiev wrote: Add HDMI audio support for the sun4i-hdmi encoder, used on the older Allwinner chips - A10, A20, A31. Most of the code is based on the BSP implementation. In it dditional formats are supported

Re: [PATCH 14/89] clk: bcm: rpi: Make sure the clkdev lookup is removed

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The clkdev lookup created for the cpufreq device is never removed if > there's an issue later in probe or at module removal time. > > Let's convert to the managed variant of the clk_hw_register_clkdev function > to make sure it happens. >

[PATCH v2 2/3] gpu/drm: ingenic: Switch emulated fbdev to 16bpp

The fbdev emulation is only ever used on Ingenic SoCs to run old SDL1 based games at 16bpp (rgb565). Recent applications generally talk to DRM directly, and can request their favourite pixel format; so we can make everybody happy by switching the emulated fbdev to 16bpp. v2: No change

Re: [PATCH 6/7] drm/sun4i: de2: Don't return de2_fmt_info struct

Hi! Dne torek, 25. februar 2020 ob 09:52:18 CET je Chen-Yu Tsai napisal(a): > On Tue, Feb 25, 2020 at 4:35 PM Maxime Ripard wrote: > > Hi, > > > > On Mon, Feb 24, 2020 at 06:39:00PM +0100, Jernej Skrabec wrote: > > > Now that de2_fmt_info contains only DRM <-> HW format mapping, it > > >

Re: RFC: drm/virtio: Dummy virtio GPU

On Tue, Feb 25, 2020 at 2:29 AM Gerd Hoffmann wrote: > > On Mon, Feb 24, 2020 at 03:01:54PM -0800, Lepton Wu wrote: > > Hi, > > > > I'd like to get comments on this before I polish it. This is a > > simple way to get something similar with vkms but it heavily reuse > > the code provided by

Re: [PATCH] drm/omap: Fix drm_handle_vblank() handling for command mode panels

* Tony Lindgren [200225 18:38]: > Only lightly tested so far, please test. Also, I'm not sure if we > should get the id from somewhere for drm_handle_vblank() instead of > just using 0? Also looks like we can now get WARN_ON(omap_crtc->pending) in omap_crtc_arm_event(), so obviously some changes

Re: [PATCH 18/89] clk: bcm: rpi: Rename is_prepared function

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The raspberrypi_fw_pll_is_on function doesn't only apply to PLL > registered in the driver, but any clock exposed by the firmware. > > Since we also implement the is_prepared hook, make the function > consistent with the other function

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

* Sebastian Reichel [200225 23:03]: > Hi, > > On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [200225 02:29]: > > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > > BTW, I think there's also some refcount issue in general where > > >

Re: [PATCH 15/89] clk: bcm: rpi: Create a data structure for the clocks

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > So far the driver has really only been providing a single clock, and stored > both the data associated to that clock in particular with the data > associated to the "controller". > > Since we will change that in the future, let's decouple

Re: [PATCH 07/89] clk: bcm: rpi: Allow the driver to be probed by DT

Hi Maxime, On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The current firmware clock driver for the RaspberryPi can only be probed by > manually registering an associated platform_device. > > While this works fine for cpufreq where the device gets attached a clkdev > lookup, it would

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

* Sebastian Reichel [200225 02:29]: > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > BTW, I think there's also some refcount issue in general where > > the omapdrm related modules cannot be unloaded any longer? > > I wouldn't be too surprised. The dependencies are quite

[PATCHv2.1 45/56] drm/omap: dsi: Register a drm_bridge

In order to integrate with a chain of drm_bridge, the internal DSI output has to expose its operations through the drm_bridge API. Register a bridge at initialisation time to do so and remove the omap_dss_device operations that are now unused. Signed-off-by: Sebastian Reichel --- PATCHv2 ->

[PATCH] drm/omap: Fix drm_handle_vblank() handling for command mode panels

When trying to run weston on droid4 with the updated sgx blobs, the LCD is just black and not updating. Weston also displays the following on startup: Warning: computed repaint delay is insane: -205475 msec Weston runs fine on the HDMI alone though, and the issue was narrowed down to an issue

Re: [PATCH 1/4] drm/msm/dpu: Remove unused function arguments

Quoting Drew Davenport (2020-02-19 09:42:24) > Several functions arguments in the resource manager are unused, so > remove them. > > Signed-off-by: Drew Davenport > --- Reviewed-by: Stephen Boyd > > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 37 ++ > 1 file changed, 14

Re: [PATCH] Initialize ATA before graphics

Hi Paul, You should have also Cc-ed Arjan on this email. [done] On 2/24/20 6:09 AM, Paul Menzel wrote: > From: Arjan van de Ven > Date: Thu, 2 Jun 2016 23:36:32 -0500 > > ATA init is the long pole in the boot process, and its asynchronous. > Move the graphics init after it, so that ATA and

Re: [PATCH] drm/omap: Fix drm_handle_vblank() handling for command mode panels

* Tony Lindgren [200225 22:35]: > * Tony Lindgren [200225 19:53]: > > * Tony Lindgren [200225 18:38]: > > > Only lightly tested so far, please test. Also, I'm not sure if we > > > should get the id from somewhere for drm_handle_vblank() instead of > > > just using 0? > > > > Also looks like we

Re: [PATCH 09/89] clk: bcm: rpi: Use clk_hw_register for pllb_arm

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The pllb_arm clock is defined as a fixed factor clock with the pllb clock > as a parent. However, all its configuration is entirely static, and thus we > don't really need to call clk_hw_register_fixed_factor but can simply call >

Re: [virtio-dev] Re: [PATCH 1/2] virtio: add dma-buf support for exported objects

On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann wrote: > > On Wed, Feb 19, 2020 at 05:06:36PM +0900, David Stevens wrote: > > This change adds a new flavor of dma-bufs that can be used by virtio > > drivers to share exported objects. A virtio dma-buf can be queried by > > virtio drivers to obtain

Re: [PATCH 10/89] clk: bcm: rpi: Remove global pllb_arm clock pointer

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used > anywhere but in the raspberrypi_register_pllb_arm. > > Let's remove it, this will make our lives easier in future patches. > > Cc: Michael Turquette > Cc: Stephen

Re: [PATCH 11/89] clk: bcm: rpi: Make sure pllb_arm is removed

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The pllb_arm clock was created at probe time, but was never removed if > something went wrong later in probe, or if the driver was ever removed from > the system. > > Now that we are using clk_hw_register, we can just use its managed

Re: [PATCH 12/89] clk: bcm: rpi: Remove pllb_arm_lookup global pointer

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The pllb_arm_lookup pointer in the struct raspberrypi_clk is not used for > anything but to store the returned pointer to clkdev_hw_create, and is not > used anywhere else in the driver. > > Let's remove that global pointer from the

Re: [PATCH] drm/omap: Fix drm_handle_vblank() handling for command mode panels

* Tony Lindgren [200225 19:53]: > * Tony Lindgren [200225 18:38]: > > Only lightly tested so far, please test. Also, I'm not sure if we > > should get the id from somewhere for drm_handle_vblank() instead of > > just using 0? > > Also looks like we can now get WARN_ON(omap_crtc->pending) > in

[PATCH v2 3/3] gpu/drm: ingenic: Add option to mmap GEM buffers cached

Ingenic SoCs are most notably used in cheap chinese handheld gaming consoles. There, the games and applications generally render in software directly in the emulated framebuffer using SDL1. Since the emulated framebuffer is mapped as write-combine by default, these applications start to run

[PATCH v2 1/3] gpu/drm: ingenic: Add trick to support 16bpp on 24-bit panels

If the panel interface is 24-bit but our primary plane is 16bpp, configure as if the panel was 18-bit. This tricks permits the display of 16bpp data on a 24-bit panel by wiring each color component to the MSBs of the 24-bit interface. v2: Check bytes-per-pixel count instead of fourcc format

[PATCH v2 3/6] dt-bindings: Add Guangdong Neweast Optoelectronics CO. LTD vendor prefix

Add vendor prefix for Guangdong Neweast Optoelectronics CO. LTD Signed-off-by: Vasily Khoruzhick --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml

[PATCH v2 1/6] drm/bridge: anx6345: Fix getting anx6345 regulators

From: Samuel Holland We don't need to pass '-supply' suffix to devm_regulator_get() Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support") Reviewed-by: Laurent Pinchart Signed-off-by: Samuel Holland Signed-off-by: Vasily Khoruzhick ---

Re: [PATCH v8 0/6] arm/arm64: mediatek: Fix mmsys device probing

Hi CK, On 26/2/20 6:32, CK Hu wrote: [snip] >> >> How do you see move mmsys to drivers/soc/mediatek and instantiate the clk and >> mediatek-drm driver >> >> mmsys: syscon@1400 { >> compatible = "mediatek,mt8173-mmsys", "syscon", "simple-mfd"; >> reg = <0 0x1400 0 0x1000>; >>

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #56 from Frans Skarman (frans.skar...@gmail.com) --- I experienced this issue (black screen after resuming from suspend) for a while on my ryzen 3800x + rx 580 setup. Same issues happened with every kernel i tried. Eventually, I

Re: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote: > Hi Jason, > > Am 26.02.20 um 00:58 schrieb Jason Ekstrand: > > Explicit synchronization is the future. At least, that seems to be what > > most userspace APIs are agreeing on at this point. However, most of our > > Linux APIs

Re: [PATCH] drm/bridge: sii9234: silence warning about regulators during deferred probe

Hi Marek, Thank you for the patch. On Wed, Feb 26, 2020 at 11:13:07AM +0100, Marek Szyprowski wrote: > Don't confuse user with meaningless warning about failure in getting > regulators in case of deferred probe. > > Signed-off-by: Marek Szyprowski Reviewed-by: Laurent Pinchart > --- >

[PATCH v2 4/6] dt-bindings: display: simple: Add NewEast Optoelectronics WJFH116008A compatible

This commit adds compatible for NewEast Optoelectronics WJFH116008A panel to panel-simple binding Reviewed-by: Laurent Pinchart Signed-off-by: Vasily Khoruzhick --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v2 0/6] Add LCD support for Pine64 Pinebook 1080p

Since ANX6345 driver has been merged we can add support for Pinebook LCD This is a follow up on [1] which attempted to add support for all the A64-based Pinebooks. Since patches for 768p were dropped we don't need edp-connector binding discussed in [1] and its earlier versions and we can use

[PATCH v2 5/6] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support

This commit adds support for the NewEast Optoelectronics CO., LTD WJFH116008A 11.6" 1920x1080 TFT LCD panel. Signed-off-by: Vasily Khoruzhick --- drivers/gpu/drm/panel/panel-simple.c | 48 1 file changed, 48 insertions(+) diff --git

[PATCH v2 2/6] drm/bridge: anx6345: don't print error message if regulator is not ready

We don't want to print scary message if devm_regulator_get() returns -EPROBE_DEFER Reviewed-by: Laurent Pinchart Signed-off-by: Vasily Khoruzhick --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH v2 6/6] arm64: allwinner: a64: enable LCD-related hardware for Pinebook

From: Icenowy Zheng Pinebook has an ANX6345 bridge connected to the RGB666 LCD output and eDP panel input. The bridge is controlled via I2C that's connected to R_I2C bus. Enable all this hardware in device tree. Reviewed-by: Laurent Pinchart Signed-off-by: Icenowy Zheng Signed-off-by: Vasily

Re: [PATCH v9 3/5] dt-bindings: display: mediatek: dpi sample data in dual edge support

Hi, Jitao: On Wed, 2020-02-26 at 13:32 +0800, Jitao Shi wrote: > Add property "pclk-sample" to config the dpi sample on falling (0), > rising (1), both falling and rising (2). > Reviewed-by: CK Hu > Signed-off-by: Jitao Shi > --- > .../devicetree/bindings/display/mediatek/mediatek,dpi.txt

Re: [PATCH 03/51] drm: add managed resources tied to drm_device

On Wed, Feb 26, 2020 at 10:21:17AM +0100, Andrzej Hajda wrote: > On 25.02.2020 16:03, Daniel Vetter wrote: > > On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote: > >> Hi Daniel, > >> > >> > >> The patchset looks interesting. > >> > >> > >> On 21.02.2020 22:02, Daniel Vetter wrote: > >>> We

Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth

Hi Iceynow, Torsten asked me to merge your patch via drm-misc-next. I'd add the additional cc and fixes tags that Torsten listed. Are you OK with that? Best regards Thomas Am 22.02.20 um 03:43 schrieb Icenowy Zheng: > > > 于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到: >> On Sat, Feb 22,

Re: [PATCH v9 5/5] drm/mediatek: set dpi pin mode to gpio low to avoid leakage current

Hi, Jitao: On Wed, 2020-02-26 at 13:32 +0800, Jitao Shi wrote: > Config dpi pins mode to output and pull low when dpi is disabled. > Aovid leakage current from some dpi pins (Hsync Vsync DE ... ). > Reviewed-by: CK Hu > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dpi.c |

Re: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

Hi Jason, Am 26.02.20 um 00:58 schrieb Jason Ekstrand: Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit

Re: + dma-buf-free-dmabuf-name-in-dma_buf_release.patch added to -mm tree

On Wed, Feb 26, 2020 at 5:29 AM Sumit Semwal wrote: > > Hello Andrew, > > > On Wed, 26 Feb 2020 at 07:25, Andrew Morton wrote: > > > > > > The patch titled > > Subject: dma-buf: free dmabuf->name in dma_buf_release() > > has been added to the -mm tree. Its filename is > >

[PATCH] drm/bridge: sii9234: silence warning about regulators during deferred probe

Don't confuse user with meaningless warning about failure in getting regulators in case of deferred probe. Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/bridge/sii9234.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/sii9234.c

Re: [PATCH 0/3] Add separate non-KMS state; constify struct drm_driver

On Wed, Feb 26, 2020 at 06:39:08AM +0100, Thomas Zimmermann wrote: > Hi > > Am 25.02.20 um 18:44 schrieb Daniel Vetter: > > On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: > >> This patchset moves legacy, non-KMS driver state from struct drm_driver > >> into struct

Re: [PATCH 16/89] clk: bcm: rpi: Add clock id to data

Hi Maxime, On Tue, 2020-02-25 at 10:54 +0100, Maxime Ripard wrote: > Hi Stefan, > > On Mon, Feb 24, 2020 at 08:25:46PM +0100, Stefan Wahren wrote: > > Hi Maxime, > > > > Am 24.02.20 um 10:06 schrieb Maxime Ripard: > > > The driver has really only supported one clock so far and has hardcoded > >

Re: [PATCH 17/89] clk: bcm: rpi: Pass the clocks data to the firmware function

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The raspberry_clock_property only takes the clock ID as an argument, but > now that we have a clock data structure it makes more sense to just pass > that structure instead. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc:

Re: [PATCH v3 1/4] PM / EM: add devices to Energy Model

Hi Randy, Thank you for taking the time to look into this patch. On 2/22/20 12:42 AM, Randy Dunlap wrote: Hi, One minor nit. Please see inline: On 2/21/20 11:47 AM, Lukasz Luba wrote: Add support of other devices into the Energy Model framework not only the CPUs. Change the interface to be

Re: [PATCH 3/3] drm/panel: add panel driver for Elida KD35T133 panels

On 2/23/20 4:07 PM, Heiko Stuebner wrote: +static int kd35t133_unprepare(struct drm_panel *panel) +{ + struct kd35t133 *ctx = panel_to_kd35t133(panel); + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev); + int ret; + + if (!ctx->prepared) + return

Re: [PATCH 08/89] clk: bcm: rpi: Statically init clk_init_data

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > Instead of declaring the clk_init_data and then calling memset on it, just > initialise properly. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Signed-off-by: Maxime Ripard > --- Acked-by: Nicolas Saenz

Re: [PATCH 16/89] clk: bcm: rpi: Add clock id to data

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > The driver has really only supported one clock so far and has hardcoded the > ID used in communications with the firmware in all the functions > implementing the clock framework hooks. Let's store that in the clock data > structure so that

Re: [PATCH 16/89] clk: bcm: rpi: Add clock id to data

Hi Stefan, On Mon, Feb 24, 2020 at 08:25:46PM +0100, Stefan Wahren wrote: > Hi Maxime, > > Am 24.02.20 um 10:06 schrieb Maxime Ripard: > > The driver has really only supported one clock so far and has hardcoded the > > ID used in communications with the firmware in all the functions > >

Re: [PATCH 13/89] clk: bcm: rpi: Switch to clk_hw_register_clkdev

On Mon, 2020-02-24 at 10:06 +0100, Maxime Ripard wrote: > Since we don't care about retrieving the clk_lookup structure pointer > returned by clkdev_hw_create, we can just use the clk_hw_register_clkdev > function. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org >

Re: [PATCH 2/4] drm/msm/dpu: Refactor rm iterator

Quoting Drew Davenport (2020-02-19 09:42:25) > Make iterator implementation private, and add function to > query resources assigned to an encoder. > > Signed-off-by: Drew Davenport > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c >

[PATCH] dma-buf: free dmabuf->name in dma_buf_release()

dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set it never gets freed. Free it in dma_buf_release(). Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+b2098bc44728a4efb...@syzkaller.appspotmail.com Acked-by: Chenbo Feng Cc: Sumit Semwal Cc: Andrew

Re: [linux-sunxi] [PATCH v3 1/1] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio

On 2/25/20 11:58 AM, Maxime Ripard wrote: On Tue, Feb 25, 2020 at 11:45:28AM +0200, Stefan Mavrodiev wrote: On 1/29/20 6:34 PM, Chen-Yu Tsai wrote: On Tue, Jan 28, 2020 at 10:07 PM Stefan Mavrodiev wrote: Add HDMI audio support for the sun4i-hdmi encoder, used on the older Allwinner chips

[PATCHv2 57/56] dt-bindings: display: panel-dsi-cm: convert to YAML

Convert panel-dsi-cm bindings to YAML and add missing properties while at it. Signed-off-by: Sebastian Reichel --- .../bindings/display/panel/panel-dsi-cm.txt | 31 -- .../bindings/display/panel/panel-dsi-cm.yaml | 97 +++ 2 files changed, 97 insertions(+), 31

Re: [linux-sunxi] [PATCH v3 1/1] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio

On Tue, Feb 25, 2020 at 11:45:28AM +0200, Stefan Mavrodiev wrote: > > On 1/29/20 6:34 PM, Chen-Yu Tsai wrote: > > On Tue, Jan 28, 2020 at 10:07 PM Stefan Mavrodiev wrote: > > > Add HDMI audio support for the sun4i-hdmi encoder, used on > > > the older Allwinner chips - A10, A20, A31. > > > > > >

Re: [PATCH 29/89] dt-bindings: display: Convert VC4 bindings to schemas

Hi Rob, On Mon, Feb 24, 2020 at 12:41:07PM -0600, Rob Herring wrote: > On Mon, 24 Feb 2020 10:06:31 +0100, Maxime Ripard wrote: > > The BCM283x SoCs have a display pipeline composed of several controllers > > with device tree bindings that are supported by Linux. > > > > Now that we have the DT

Re: [PATCH v8 0/6] arm/arm64: mediatek: Fix mmsys device probing

On 24/2/20 6:52, CK Hu wrote: > > Hi, > > On Fri, 2020-02-21 at 18:10 +0100, Enric Balletbo i Serra wrote: >> Hi, >> >> On 21/2/20 12:53, Matthias Brugger wrote: >>> >>> >>> On 21/02/2020 12:37, Enric Balletbo i Serra wrote: Hi CK and Matthias, On 21/2/20 12:11, CK Hu wrote:

Re: [PATCH RFC v3 2/6] drm/sprd: add Unisoc's drm kms master

On Tue, Feb 25, 2020 at 3:38 PM Thomas Zimmermann wrote: > Hi > > Am 23.02.20 um 05:26 schrieb tang pengchuan: > > > > > > On Sun, Feb 23, 2020 at 5:27 AM Sam Ravnborg > > wrote: > > > > Hi Kevin/tang. > > > > Thanks for the quick and detailed feedback. > >

[PATCH libdrm] modetest: call drmModeCrtcSetGamma() only if add_property_optional returns true

gamma is a optional property then also it prints error message, so set gamma only if add_property_optional() returns true. Signed-off-by: Rohit Visavalia --- tests/modetest/modetest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/modetest/modetest.c

Re: [PATCH RFC v3 4/6] drm/sprd: add Unisoc's drm display controller driver

Hi Emil, Thanks for your feedback On Tue, Feb 25, 2020 at 1:35 AM Emil Velikov wrote: > On Fri, 21 Feb 2020 at 11:15, Kevin Tang wrote: > > > > Adds DPU(Display Processor Unit) support for the Unisoc's display > subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality)

Re: [PATCH 03/51] drm: add managed resources tied to drm_device

On 25.02.2020 16:03, Daniel Vetter wrote: > On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote: >> Hi Daniel, >> >> >> The patchset looks interesting. >> >> >> On 21.02.2020 22:02, Daniel Vetter wrote: >>> We have lots of these. And the cleanup code tends to be of dubious >>> quality. The

Re: [PATCH 1/7] dma-buf: add dynamic DMA-buf handling v15

On Wed, Feb 19, 2020 at 01:59:04PM +0100, Christian König wrote: > On the exporter side we add optional explicit pinning callbacks. Which are > called when the importer doesn't implement dynamic handling, move notification > or need the DMA-buf locked in place for its use case. > > On the

[PATCH] drm/exynos: dsi: silence warning about regulators during deferred probe

Don't confuse user with meaningless warning about failure in getting regulators in case of deferred probe. Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c

Re: [PATCH] dt-bindings: arm-smmu: update the list of clocks

On 2/21/2020 2:05 AM, Rob Herring wrote: On Thu, 20 Feb 2020 13:42:22 +0530, Sharat Masetty wrote: This patch adds a clock definition needed for powering on the GPU TBUs and the GPU TCU. Signed-off-by: Sharat Masetty --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 +++ 1

[PATCH v8 23/54] drm/omap: Factor out display type to connector type conversion

Move the code that computes the DRM connector type for the omapdss_device display type to a new omapdss_device_connector_type() function for later reuse. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Acked-by: Sam Ravnborg Tested-by: Sebastian Reichel Reviewed-by: Sebastian

[PATCH v8 06/54] drm/bridge: Improve overview documentation

Clean up the drm_bridge overview documentation, and expand the operations documentation to provide more details on API usage. Signed-off-by: Laurent Pinchart Reviewed-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 6 +- drivers/gpu/drm/drm_bridge.c | 101

[PATCH v8 14/54] drm/bridge: simple-bridge: Add support for the TI OPA362

The TI OPA362 is an analog video amplifier controlled through a GPIO. Add support for it to the simple-bridge driver. Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Reviewed-by: Boris Brezillon Reviewed-by: Maxime Ripard Reviewed-by: Tomi Valkeinen Acked-by: Sam Ravnborg

[PATCH v8 25/54] drm/omap: dss: Fix output next device lookup in DT

The DSS core looks up the next device connected to an output by traversing the OF graph. It currently hardcodes the local port number to 0, which breaks any output with a different port number (SDI on OMAP3 and any DPI output but the first one). Fix this by repurposing the currently unused

[PATCH v8 11/54] drm/bridge: dumb-vga-dac: Rename driver to simple-bridge

The dumb-vga-dac driver can support simple DRM bridges without being limited to VGA DACs. Rename it to simple-bridge. Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Reviewed-by: Boris Brezillon Acked-by: Maxime Ripard Acked-by: Sam Ravnborg Tested-by: Sebastian Reichel

[PATCH v8 13/54] drm/bridge: simple-bridge: Add support for enable GPIO

If an enable GPIO is declared in the firmware, assert it when enabling the bridge and deassert it when disabling it. Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Reviewed-by: Stefan Agner Reviewed-by: Boris Brezillon Reviewed-by: Maxime Ripard Acked-by: Sam Ravnborg Tested-by:

[PATCH v8 18/54] drm/bridge: tfp410: Replace manual connector handling with bridge

Now that a driver is available for display connectors, replace the manual connector handling code with usage of the DRM bridge API. The tfp410 driver doesn't deal with the display connector directly anymore, but still delegates drm_connector operations to the next bridge. This brings us one step

[PATCH v8 01/54] video: hdmi: Change return type of hdmi_avi_infoframe_init() to void

The hdmi_avi_infoframe_init() never needs to return an error, change its return type to void. Signed-off-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Acked-by: Bartlomiej Zolnierkiewicz Reviewed-by: Boris Brezillon Acked-by: Sam Ravnborg Tested-by: Sebastian Reichel Reviewed-by:

[PATCH v8 10/54] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge

The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA DACs that don't require configuration. Other non-VGA bridges fall in a similar category, and would benefit from a common driver. Prepare for this by renaming the internal symbols from dumb-vga-dac to simple-bridge.

[PATCH v8 37/54] drm/omap: venc: Register a drm_bridge

In order to integrate with a chain of drm_bridge, the internal VENC encoder has to expose the mode valid, fixup and set, the enable and disable and the get modes operations through the drm_bridge API. Register a bridge at initialisation time to do so. Most of those operations are removed from the

[PATCH v8 02/54] drm/connector: Add helper to get a connector type name

drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*) to name strings, but doesn't expose it. This leads to drivers having to store a similar map. Add a new drm_get_connector_type_name() helper function that return a name string for a connector type. Signed-off-by: Laurent

[PATCH v8 05/54] drm/bridge: Fix atomic state ops documentation

The drm_bridge_funcs atomic_state_duplicate and atomic_state_destroy operations are erroneously documented as having a default implementation if not implemented in bridge drivers. This isn't correct, fix the documentation. Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon ---

[PATCH v8 09/54] drm/bridge: Extend bridge API to disable connector creation

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 display pipelines where DRM connector operations are split over multiple

[PATCH v8 08/54] drm/bridge: Add interlace_allowed flag to drm_bridge

In preparation for a connector creation helper based on a chain of bridges, add a flag to the drm_bridge structure to report support for interlaced modes. This will be used to set the connector's interlace_allowed flag. Signed-off-by: Laurent Pinchart Tested-by: Sebastian Reichel Reviewed-by:

[PATCH v8 26/54] drm/omap: Add infrastructure to support drm_bridge local to DSS outputs

In order to support drm_bridge-based pipeline, the internal HDMI encoders will need to expose the EDID read operation through the drm_bridge API, and thus to expose a drm_bridge instance corresponding to the encoder. The HDMI encoders are however handled as omap_dss_device instances, which

[PATCH v8 04/54] drm/bridge: Document the drm_encoder.bridge_chain field as private

The drm_encoder.bridge_chain is not meant to be touched manually by drivers. Make this clear in the documentation. Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon --- include/drm/drm_encoder.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] drm/exynos: dsi: silence warning about regulators during deferred probe

On Wed, 26 Feb 2020 at 11:11, Marek Szyprowski wrote: > > Don't confuse user with meaningless warning about failure in getting > regulators in case of deferred probe. You are doing actually more than you explained here. You fixed inaccurate error code (EPROBE_DEFER) being returned in case of

Re: [PATCH v8 00/54] drm/omap: Replace custom display drivers with drm_bridge and drm_panel

On 26/02/2020 13:24, Laurent Pinchart wrote: Hello, This version of the series is there just to make "dim apply" happy, as it needs to get patches from the list. Sorry for the spam :-) Thank you! I have pushed to drm-misc-next. It's been a long journey here, now when we just get Sebastian's

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

On 26/02/2020 01:52, Sebastian Reichel wrote: Well for now let's get Laurent's and my series forward. I think the next step would be to get rid of omap_encoder by moving the encoder init into the DSS output code. Technically we are already merging omapdrm and omapdss, e.g. omap_connector is

[PATCH v8 54/54] drm/omap: dss: Remove unused omap_dss_device operations

The omap_dss_device .pre_enable(), .post_disable() and .set_timings() are not used anymore. Remove them. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/dss/base.c | 26 ---

[PATCH v8 40/54] drm/omap: Remove HPD, detect and EDID omapdss operations

Due to the removal of several omapdrm display drivers, the omapdss HPD, detected and EDID operations are not used anymore. Remove them and all related code. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel ---

[PATCH v8 33/54] drm/omap: hdmi4: Move mode set, enable and disable operations to bridge

Move the omap_dss_device .set_timings(), .enable() and .disable() operations to the drm_bridge functions. As the drm_bridge for the HDMI encoder is unconditionally registered and attached, those operations will be called at the appropriate time. The omapdss device .set_infoframe() and

[PATCH v8 45/54] drm/omap: dpi: Sort includes alphabetically

This makes it easier to quickly locate duplicate includes. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH v8 42/54] drm/omap: venc: Remove omap_dss_device operations

Now that the VENC output is driven fully through the drm_bridge API its omap_dss_device operations are not used anymore. Remove them. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/dss/venc.c

Re: [PATCH] drm/bridge: sii9234: silence warning about regulators during deferred probe

On Wed, 26 Feb 2020 at 11:13, Marek Szyprowski wrote: > > Don't confuse user with meaningless warning about failure in getting > regulators in case of deferred probe. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/bridge/sii9234.c | 3 ++- > 1 file changed, 2 insertions(+), 1

[no subject]

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.gh13...@intel.com> References: <20200219203544.31013-1-ville.syrj...@linux.intel.com> <20200219203544.31013-5-ville.syrj...@linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.com>

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

On 25/02/2020 01:20, Sebastian Reichel wrote: > This updates the existing omapdrm DSI code, so that it uses > common drm_mipi_dsi API and drm_panel. > > The patchset has been tested with Droid 4 using Linux console, X.org and > Weston. The patchset is based on Laurent Pinchartl's patch series [0]

[PATCH v8 03/54] drm/edid: Add flag to drm_display_info to identify HDMI sinks

The drm_display_info structure contains many fields related to HDMI sinks, but none that identifies if a sink compliant with CEA-861 (EDID) shall be treated as an HDMI sink or a DVI sink. Add such a flag, and populate it according to section 8.3.3 ("DVI/HDMI Device Discrimination") of the HDMI

[PATCH v8 38/54] drm/omap: Create connector for bridges

Use the drm_bridge_connector helper to create a connector for pipelines that use drm_bridge. This allows splitting connector operations across multiple bridges when necessary, instead of having the last bridge in the chain creating the connector and handling all connector operations internally.

[PATCH v8 17/54] drm/bridge: panel: Implement bridge connector operations

Implement the newly added bridge connector operations, allowing the usage of drm_bridge_panel with drm_bridge_connector. Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon Reviewed-by: Sam Ravnborg Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel ---

[PATCH v8 34/54] drm/omap: hdmi5: Move mode set, enable and disable operations to bridge

Move the omap_dss_device .set_timings(), .enable() and .disable() operations to the drm_bridge functions. As the drm_bridge for the HDMI encoder is unconditionally registered and attached, those operations will be called at the appropriate time. The omapdss device .set_infoframe() and

[PATCH v8 41/54] drm/omap: hdmi: Remove omap_dss_device operations

Now that the HDMI outputs are driven fully through the drm_bridge API their omap_dss_device operations are not used anymore. Remove them. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel ---

[PATCH v8 19/54] drm/bridge: tfp410: Allow operation without drm_connector

The tfp410 driver can operate as part of a pipeline where the drm_connector is created by the display controller. Enable this mode of operation by skipping creation of a drm_connector internally. Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon Acked-by: Sam Ravnborg Tested-by:

[PATCH v8 30/54] drm/omap: hdmi5: Rework EDID read to isolate data read

In preparation of adding DRM bridge support to the hdmi5 encoder code, rework the EDID read to isolate data read. The hdmi_read_edid() function is the main entry point. It performs all initialisation steps required prior to reading the EDID (such as ensuring the device is powered on), as well as

[PATCH v8 32/54] drm/omap: hdmi5: Register a drm_bridge for EDID read

In order to integrate with a chain of drm_bridge, the internal HDMI5 encoder has to expose the EDID read operation through the drm_bridge API. Register a bridge at initialisation time to do so. For the time being make the next bridge in the chain optional as the HDMI output is still based on

  1   2   3   >