Hi Daniel, Dave,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2021-11-18:
A infoframe corruption fix for nouveau, a wrong free function usage fix
for GEM CMA helpers, a Kconfig dependency fix for sun4i, two fixes for
drm/scheduler refcounting and a probing fix for efifb.
The
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip-vop2.yaml | 114 ++
1 file changed, 114
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 65
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index
Hi Sascha Hauer,
On 2021/11/17 下午10:33, Sascha Hauer wrote:
This series adds initial graphics support for the Rockchip RK356[68]
SoCs. Graphics support is based around the VOP2 controller which
replaces the VOP controller found on earlier Rockchip SoCs. The driver
has been tested with HDMI
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 +++
1 file changed, 24 insertions(+)
On Wed, Nov 17, 2021 at 07:05:33PM +0100, Nicolas Frattaroli wrote:
> On Mittwoch, 17. November 2021 15:33:47 CET Sascha Hauer wrote:
> > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> > It replaces the VOP unit found in the older Rockchip SoCs.
> >
> > This driver has
There are cases in which a SoC allows many different routes between
components, but not all of them make sense for a board. With this patch
we allow standard status = "disabled" properties for ports. With this
a SoC level dtsi file can describe all possible ports and only the ones
that make sense
From: Benjamin Gaignard
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Link:
On Wed, Nov 17, 2021 at 03:40:26PM +0100, Heiko Stübner wrote:
> Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer:
> > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > the VOP driver optional.
> >
> > Signed-off-by: Sascha Hauer
> > ---
> >
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip,dw-hdmi.yaml| 6 ++
From: Benjamin Gaignard
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
This version of the HDMI hardware block needs a new clock to provide
the phy reference clock: hclk. As this is the third clock the driver
uses it is switched to devm_clk_bulk_get_optional() to simplify the
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 52
1 file changed, 52
With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.
Signed-off-by: Sascha Hauer
---
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm64/configs/defconfig| 1 +
drivers/gpu/drm/rockchip/Kconfig| 7 +++
On Wed, Nov 17, 2021 at 08:54:37AM -0600, Rob Herring wrote:
> On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
> >
> > This series adds initial graphics support for the Rockchip RK356[68]
> > SoCs. Graphics support is based around the VOP2 controller which
> > replaces the VOP controller
The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
1 file changed,
> -Original Message-
> From: Paul Cercueil
> Sent: Mittwoch, 17. November 2021 13:50
> To: Daniel Vetter
> Cc: Jonathan Cameron ; Hennerich, Michael
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Christian König
> ;
This series adds initial graphics support for the Rockchip RK356[68]
SoCs. Graphics support is based around the VOP2 controller which
replaces the VOP controller found on earlier Rockchip SoCs. The driver
has been tested with HDMI support included in this series and MIPI-DSI
which is not included
There are cases in which a SoC allows many different routes between
components, but not all of them make sense for a board. With this patch
we allow standard status = "disabled" properties for ports. With this
a SoC level dtsi file can describe all possible ports and only the ones
that make sense
On Tuesday, 16 November 2021 6:30:18 AM AEDT Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one
On Tuesday, 16 November 2021 6:30:23 AM AEDT Alex Sierra wrote:
> In order to configure device coherent in test_hmm, two module parameters
> should be passed, which correspond to the SP start address of each
> device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
> private device
Hi, Matthew
Finally got some time to look at this more in-depth, please see below.
On Mon, 2021-11-15 at 17:16 +, Matthew Auld wrote:
> On 14/11/2021 11:12, Thomas Hellström wrote:
> > Don't wait sync while migrating, but rather make the GPU blit await
> > the
> > dependencies and add a
Am 18.11.21 um 04:09 schrieb Rob Clark:
On Wed, Nov 17, 2021 at 5:23 PM Steev Klimaszewski wrote:
On 11/17/21 1:27 AM, Christian König wrote:
Am 16.11.21 um 19:30 schrieb Amit Pundir:
On Tue, 16 Nov 2021 at 21:21, Rob Clark wrote:
From: Rob Clark
drm_sched_job_add_dependency() could
On Wed, 2021-11-17 at 19:49 +0100, Thomas Hellström wrote:
>
> On 11/17/21 15:20, Matthew Auld wrote:
> > In intel_context_do_pin_ww, when calling into the pre_pin
> > hook(which is
> > passed the ww context) it could in theory return -EDEADLK(which is
> > very
> > likely with debug kernels),
On Tuesday, 16 November 2021 6:30:19 AM AEDT Alex Sierra wrote:
> This case is used to migrate pages from device memory, back to system
> memory. Device coherent type memory is cache coherent from device and CPU
> point of view.
>
> Signed-off-by: Alex Sierra
> ---
> v2:
> condition added when
https://bugzilla.kernel.org/show_bug.cgi?id=214991
--- Comment #2 from Jian-Hong Pan (j...@endlessos.org) ---
Created attachment 299625
--> https://bugzilla.kernel.org/attachment.cgi?id=299625=edit
Full dmesg log with the v2 patch series "drm/vc4: kms: Misc fixes for HVS
commits"
Maxime sent
Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道：
>
> Hi,
>
> The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to
> atomic helpers") introduced a number of issues in corner cases, most of them
> showing themselves in the form of either a vblank timeout or use-after-free
> error.
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Acked-by: Tzung-Bi Shih
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Acked-by: Tzung-Bi Shih
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git
On Thu, Nov 18, 2021 at 12:52:14PM +0800, Tzung-Bi Shih wrote:
> On Thu, Nov 18, 2021 at 11:11 AM Xin Ji wrote:
> > @@ -1098,9 +1098,18 @@ static void anx7625_init_gpio(struct anx7625_data
> > *platform)
> > /* Gpio for chip power enable */
> > platform->pdata.gpio_p_on =
> >
Hi Dave, Daniel,
Fixes for 5.16.
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.16-2021-11-17
for you to
Exports a DMA buf fd of a given KFD buffer handle. This is intended for
the new upstreamable RDMA solution coming to UCX and libfabric.
The corresponding user mode change (Thunk API and kfdtest) is here:
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commits/fxkamd/dmabuf
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix Kuehling
---
On Mon, Nov 15, 2021 at 12:40 PM Claudio Suarez wrote:
>
> On Mon, Nov 15, 2021 at 12:24:26PM +0200, Jani Nikula wrote:
> > On Sun, 14 Nov 2021, Claudio Suarez wrote:
> > > On Sat, Nov 13, 2021 at 09:39:46PM +0100, Sam Ravnborg wrote:
> > >> Hi Claudio,
> > >>
> > >> On Sat, Nov 13, 2021 at
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git
On Wed, Nov 17, 2021 at 5:23 PM Steev Klimaszewski wrote:
>
>
> On 11/17/21 1:27 AM, Christian König wrote:
> > Am 16.11.21 um 19:30 schrieb Amit Pundir:
> >> On Tue, 16 Nov 2021 at 21:21, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> drm_sched_job_add_dependency() could drop the last ref,
On Wed, Nov 17, 2021 at 04:47:20PM +0300, Dan Carpenter wrote:
> Hello Xin Ji,
>
> The patch 8bdfc5dae4e3: "drm/bridge: anx7625: Add anx7625 MIPI
> DSI/DPI to DP" from Sep 18, 2020, leads to the following Smatch
> static checker warning:
>
> drivers/gpu/drm/bridge/analogix/anx7625.c:1050
This patch try to fix coccicheck warning:
./drivers/gpu/drm/kmb/kmb_drv.c:519:2-8: ERROR: missing put_device; call
of_find_device_by_node on line 506, but without a corresponding object release
within this function.
./drivers/gpu/drm/kmb/kmb_drv.c:522:2-8: ERROR: missing put_device; call
Greetings,
I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
board and while I've been able to get the MIPI DSI display and
backlight working I still can't seem to figure out the touch
controller.
It's supposed to have an FT5406 controller on it without an interrupt
so I added
On 11/17/21 1:27 AM, Christian König wrote:
Am 16.11.21 um 19:30 schrieb Amit Pundir:
On Tue, 16 Nov 2021 at 21:21, Rob Clark wrote:
From: Rob Clark
drm_sched_job_add_dependency() could drop the last ref, so we need
to do
the dma_fence_get() first.
It fixed the splats I saw on RB5
Hi, Jason:
For this series except [v6,3/6] drm/mediatek: Detect CMDQ execution
timeout (I pick v5), applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
jason-jh.lin 於 2021年10月28日 週四
Hi, Fei:
Fei Shao 於 2021年10月28日 週四 上午11:19寫道：
>
> Hi Chun-Kuang,
>
> On Thu, Oct 28, 2021 at 7:47 AM Chun-Kuang Hu wrote:
> >
> > Hi, Fei:
> >
> > Fei Shao 於 2021年10月27日 週三 下午5:32寫道：
> > >
> > > Hi Jason,
> > >
> > > On Wed, Oct 27, 2021 at 10:19 AM jason-jh.lin
> > > wrote:
> > > >
> > > >
From: Chris Wilson
While the power consumption is proportional to the frequency, there is
also a static draw for active gates. The longer we are able to powergate
(rc6), the lower the static draw. Thus there is a sweetspot in the
frequency/power curve where we run at higher frequency in order to
From: Chris Wilson
Currently, we inspect each engine individually and measure the occupancy
of that engine over the last evaluation interval. If that exceeds our
busyness thresholds, we decide to increase the GPU frequency. However,
under a load balancer, we should consider the occupancy of
From: Chris Wilson
Everytime we come to the end of a virtual engine's context, re-randomise
it's siblings[]. As we schedule the siblings' tasklets in the order they
are in the array, earlier entries are executed first (when idle) and so
will be preferred when scheduling the next virtual request.
Switch from tgl to adl, sees one particular media decode pipeline fit
into a single vcs engine on adl, whereas it took two on tgl. However, it
was observed that the power consumtpion for adl remained higher than for
tgl. One contibution is that each engine is treated individually for rps
A variety of applications have found it useful to listen to
user-initiated input events to make decisions within a DRM driver, given
that input events are often the first sign that we're going to start
doing latency-sensitive activities:
* Panel self-refresh: software-directed self-refresh
To improve panel self-refresh exit latency, we speculatively start
exiting when we
receive input events. Occasionally, this may lead to false positives,
but most of the time we get a head start on coming out of PSR. Depending
on how userspace takes to produce a new frame in response to the event,
A variety of applications have found it useful to listen to
user-initiated input events to make decisions within a DRM driver, given
that input events are often the first sign that we're going to start
doing latency-sensitive activities:
* Panel self-refresh: software-directed self-refresh
Applied. Thanks!
On Mon, Nov 15, 2021 at 3:10 AM Yang Li wrote:
>
> Clang static analysis reports this error
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
> Dereference of null pointer [clang-analyzer-core.NullDereference]
> if
>
Applied. Thanks!
On Mon, Nov 15, 2021 at 8:48 PM Bernard Zhao wrote:
>
> This change is to cleanup the code a bit.
>
> Signed-off-by: Bernard Zhao
> ---
> .../drm/amd/display/dc/dcn10/dcn10_resource.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git
Applied. Thanks!
On Tue, Nov 16, 2021 at 4:19 AM Christian König
wrote:
>
> Am 16.11.21 um 02:34 schrieb Bernard Zhao:
> > In function dc_sink_destruct, kfree will check pointer, no need
> > to check again.
> > This change is to cleanup the code a bit.
> >
> > Signed-off-by: Bernard Zhao
>
>
Applied. Thanks!
Alex
On Mon, Nov 15, 2021 at 10:56 AM Felix Kuehling wrote:
>
> Am 2021-11-14 um 9:58 p.m. schrieb Bernard Zhao:
> > In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed
> > There is a potential memleak if not call kobject_put.
> >
> > Signed-off-by: Bernard Zhao
Applied. Thanks!
Alex
On Mon, Nov 15, 2021 at 7:09 AM Bernard Zhao wrote:
>
> This change is to cleanup the code style a bit.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
>
Applied thanks. If you want to make the numbering more sequential,
please also update the other dce files if you make that change.
Alex
On Mon, Nov 15, 2021 at 2:14 AM Bernard Zhao wrote:
>
> This change is to remove useless break after return.
>
> Signed-off-by: Bernard Zhao
> ---
>
Hi Arunpravin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-intel/for-linux-next v5.16-rc1]
[cannot apply to drm-tip/drm-tip next-2027]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 11/16/21 11:58 PM, Arnd Bergmann wrote:
On Wed, Nov 17, 2021 at 7:27 AM Randy Dunlap wrote:
When CONFIG_DRM_KMS_HELPER=m and CONFIG_DRM_PANEL_EDP=y,
there is a build error in gpu/drm/panel/panel-edp.o:
arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-edp.o: in function
On 16/11/2021 20:18, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
On Wed, Nov 17, 2021 at 10:51:39AM -0800, Matt Roper wrote:
> On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > > From: Matt Atwood
> > >
> > > Extend existing workaround 1409120013 to DG2.
> >
> > I don't see this
On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > From: Matt Atwood
> >
> > Extend existing workaround 1409120013 to DG2.
>
> I don't see this listed for DG2.
>
> >
> > Cc: José Roberto de Souza
> > Signed-off-by:
On Wed, Nov 17, 2021 at 08:43:19PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> > From: Matt Atwood
> >
> > Extend existing workaround 1409120013 to DG2.
>
> I don't see this listed for DG2.
This seems to be problem with the DG2 query since for
On 11/17/21 15:20, Matthew Auld wrote:
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then
On Tue, Nov 16, 2021 at 09:48:18AM -0800, Matt Roper wrote:
> From: Matt Atwood
>
> Extend existing workaround 1409120013 to DG2.
I don't see this listed for DG2.
>
> Cc: José Roberto de Souza
> Signed-off-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c
On 16/11/2021 20:18, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation
On Mittwoch, 17. November 2021 15:33:47 CET Sascha Hauer wrote:
> The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> It replaces the VOP unit found in the older Rockchip SoCs.
>
> This driver has been derived from the downstream Rockchip Kernel and
> heavily modified:
>
> -
On 16/11/2021 20:18, Arunpravin wrote:
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header
Quoting Doug Anderson (2021-11-17 16:49:43)
> Hi,
>
> On Wed, Nov 17, 2021 at 8:32 AM Kieran Bingham
> wrote:
> >
> > The edp_panel_entry members 'delay' and 'name' are documented, but
> > without the correct syntax for kernel doc.
> >
> > This generates the following warnings:
> >
> >
Hi Christian,
I will make this a separate module.
Thanks,
Arun
On 17/11/21 1:33 pm, Christian König wrote:
> I've looked a bit more into this and I think we should just follow
> Thomas Zimmermann's idea to make this a separate module.
>
> Otherwise we just have the code around all the time
Hi,
On Wed, Nov 17, 2021 at 8:32 AM Kieran Bingham
wrote:
>
> The edp_panel_entry members 'delay' and 'name' are documented, but
> without the correct syntax for kernel doc.
>
> This generates the following warnings:
>
> drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or
Hi Rajat,
On 11/17/21 15:28, Rajat Jain wrote:
> +Heikki Krogerus
>
> Hello Hans, Heikki,
>
> I have a question below, which isn't really a problem, but more of an
> attempt to understand the current code and its limitations.
>
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote:
>>
>> On
https://bugzilla.kernel.org/show_bug.cgi?id=214859
spassw...@web.de changed:
What|Removed |Added
CC||spassw...@web.de
--- Comment #8 from
https://bugzilla.kernel.org/show_bug.cgi?id=214901
spassw...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=214921
spassw...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Roman,
On 17.11.2021 15:26, Li, Roman wrote:
> [Public]
>
> Hi Samuel,
>
> Can you please try: https://patchwork.freedesktop.org/patch/463485/ ?
Yup, that did the trick. Works as before. Thank you very much.
Samuel
>
> Thanks,
> Roman
>
> > -Original Message-
> > From: Samuel
Hi Rajat,
On 11/17/21 15:13, Rajat Jain wrote:
> Hello Hans,
>
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote:
>>
>> Add X86 specific arch init code, which fills the privacy-screen lookup
>> table by checking for various vendor specific ACPI interfaces for
>> controlling the
The edp_panel_entry members 'delay' and 'name' are documented, but
without the correct syntax for kernel doc.
This generates the following warnings:
drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member
'delay' not described in 'edp_panel_entry'
Hi Rajat,
On 11/17/21 14:59, Rajat Jain wrote:
> Hello Hans,
>
> I'm working on my platform's privacy-screen support based on your
> patches, and had some (I know late) questions. Would be great if you
> could please help answer. Please see inline.
>
> On Tue, Oct 5, 2021 at 1:25 PM Hans de
On Wed, 17 Nov 2021 15:33:42 +0100, Sascha Hauer wrote:
> The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
> The binding differs slightly from the existing VOP binding, so add a new
> binding file for it.
>
> Signed-off-by: Sascha Hauer
> ---
>
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
On 17/11/2021 23.56, Thomas Zimmermann wrote:
Hi
Am 17.11.21 um 15:22 schrieb Hector Martin:
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by:
[Public]
Hi Samuel,
Can you please try: https://patchwork.freedesktop.org/patch/463485/ ?
Thanks,
Roman
> -Original Message-
> From: Samuel Čavoj
> Sent: Tuesday, November 16, 2021 8:33 AM
> To: Alex Deucher
> Cc: Deucher, Alexander ; Li, Sun peng (Leo)
> ; Li, Roman ; Maling list -
Hi Sascha,
On 11/17/21 3:33 PM, Sascha Hauer wrote:
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 24
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> This enabled the VOP2 display controller along with hdmi and the
> required port routes which is enough to get a picture out of the
> hdmi port of the board.
>
> Signed-off-by: Sascha Hauer
> ---
> .../boot/dts/rockchip/rk3568-evb1-v10.dts
Am Mittwoch, 17. November 2021, 15:50:54 CET schrieb Sascha Hauer:
> On Wed, Nov 17, 2021 at 03:40:26PM +0100, Heiko Stübner wrote:
> > Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer:
> > > With upcoming VOP2 support VOP won't be the only choice anymore, so make
> > > the VOP
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> Add support for the HDMI port found on RK3568.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 65
> 1 file changed, 65 insertions(+)
>
> diff --git
This is the format used by the bootloader framebuffer on Apple ARM64
platforms, and is already supported by simplefb. This avoids regressing
on these platforms when simpledrm is enabled and replaces simplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.
Signed-off-by: Hector
This matches the simplefb behavior; these nodes are not matched by the
standard OF machinery. This fixes a regression when simpledrm replaces
simeplefb.
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 17 +
1 file changed, 17 insertions(+)
diff --git
Hi DRM folks,
This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.
This avoids breaking the bootloader-provided framebuffer console
Hi
Am 17.11.21 um 15:22 schrieb Hector Martin:
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
Thanks for your patch, but you're
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote:
>
> This series adds initial graphics support for the Rockchip RK356[68]
> SoCs. Graphics support is based around the VOP2 controller which
> replaces the VOP controller found on earlier Rockchip SoCs. The driver
> has been tested with HDMI
The bind hooks will modify their controller registers, so simplefb is
going to be unusable anyway. Let's avoid any transient state where it
could still be in the system but no longer functionnal.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 8
1 file changed, 4
Add the firmware phandle to the vc4 node so that we can send it the
message that we're done with the firmware display.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
been made, simplefb has been unregistered and the KMS driver is entirely
in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was
using to maintain simplefb functional.
Signed-off-by:
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the
firmware the kernel is in charge of the display now and the firmware can
free whatever resources it was using.
Signed-off-by: Maxime Ripard
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
1 file changed, 1 insertion(+)
The firmware can free all the resources it was using to run the display
engine that won't be needed once the kernel has taken over.
Thus, we need a phandle to the firmware DT node to be able to send that
message when relevant.
Signed-off-by: Maxime Ripard
---
Hi,
The VC4 driver has had limited support to disable the HDMI controllers and
pixelvalves at boot if the firmware has enabled them.
However, this proved to be limited, and a bit unreliable so a new firmware
command has been introduced some time ago to make it free all its resources and
disable
Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer:
> With upcoming VOP2 support VOP won't be the only choice anymore, so make
> the VOP driver optional.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> arch/arm64/configs/defconfig
The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2
Quoting Andi Shyti (2021-11-17 13:34:56)
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 089fb4658b216..0bbf8c0c42eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git
1 - 100 of 169 matches
Mail list logo
