On Sat 15 May 14:56 CDT 2021, Dmitry Baryshkov wrote:
> Remove most of remains of downstream usbpd code. Mainline kernel uses
> different approach for managing Type-C / USB-PD, so this remains unused.
> Do not touch usbpd callbacks for now, since they look usefull enough as
> an example of how to
Hi
Am 16.05.21 um 00:14 schrieb Javier Martinez Canillas:
There are drivers that register framebuffer devices very early in the boot
process and make use of the existing framebuffer as setup by the firmware.
If one of those drivers has registered a fbdev, then the fbdev registered
by a DRM
On Sun 11 Apr 19:09 CDT 2021, Dmitry Baryshkov wrote:
> Change huge lookup table to contain just sensible entries. IRQ index is
> now not an index in the table, but just register id (multiplied by 32,
> the amount of IRQs in the register) plus offset in the register. This
> allows us to remove
On Sun 11 Apr 19:09 CDT 2021, Dmitry Baryshkov wrote:
> Always call dpu_hw_intr_clear_intr_status_nolock() from the
> dpu_hw_intr_dispatch_irqs(). This simplifies the callback function
> (which call clears the interrupts anyway) and enforces clearing the hw
> interrupt status.
>
Reviewed-by:
On Sun 11 Apr 19:09 CDT 2021, Dmitry Baryshkov wrote:
> There is little sense in reading interrupt statuses and right after that
> going after the array of statuses to dispatch them. Merge both loops
> into single function doing read and dispatch.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
On Wed 12 May 17:58 CDT 2021, Dmitry Baryshkov wrote:
> On Tue, 11 May 2021 at 07:19, Bjorn Andersson
> wrote:
> >
> > From: Rob Clark
> >
> > Add SC8180x to the hardware catalog, for initial support for the
> > platform. Due to limitations in the DP driver only one of the four DP
> >
Hi Marek,
On Sun, May 16, 2021 at 01:49:11AM +0200, Marek Vasut wrote:
> On 5/15/21 11:48 PM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > Thank you for the patch.
> >
> > On Sat, May 15, 2021 at 10:39:32PM +0200, Marek Vasut wrote:
> >> Add missing spaces to make the diagrams readable,
On 5/15/21 11:48 PM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Sat, May 15, 2021 at 10:39:32PM +0200, Marek Vasut wrote:
Add missing spaces to make the diagrams readable, no functional change.
Looks better indeed. The patch view looks bad though, because of the
Hi Angelo,
On 12/01/2021 22:26, AngeloGioacchino Del Regno wrote:
This patch series brings some fixes to the Qualcomm DPU driver, aim is
to get it prepared for "legacy" SoCs (like MSM8998, SDM630/660) and to
finally get command-mode displays working on this driver.
The series was tested
MERGE_3D blocks are not really handled by resource manager, they are
used by corresponding PP blocks directly, each merge_3d is used by two
known PP blocks. So allocate them outside of RM and use them directly.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c |
>From Dmitry Baryshkov # This line is ignored.
From: Dmitry Baryshkov
Reply-To:
Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code
In-Reply-To:
There is no need to request most of hardware blocks through the resource
manager (RM), since typically there is 1:1 or N:1 relationship between
For each LM there is at max 1 peer LM which can be driven by the same
CTL, so there no need to have a mask instead of just an ID of the peer
LM.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 2 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 +--
No code uses lm_max_width from resource manager, so drop it.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 4
2 files changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
Then this allocation is passed to RM and then returned to then
dpu_encoder.
So allocate them outside of RM and use them directly.
Signed-off-by: Dmitry Baryshkov
Each PINGPONG block is tied to a single LM. No LMs can share single PINGPONG
block. So there is no need to handle PINGPONG blocks through all resource
allocation/deallocation/assignment, just receive PINGPONG block as a part of
LM hardware instance.
Signed-off-by: Dmitry Baryshkov
---
Each DSPP block is tied to a single LM. No LMs can share single DSPP
block. So there is no need to handle DSPP blocks through all resource
allocation/deallocation/assignment, just receive DSPP block as a part of
LM hardware instance.
Signed-off-by: Dmitry Baryshkov
---
There are drivers that register framebuffer devices very early in the boot
process and make use of the existing framebuffer as setup by the firmware.
If one of those drivers has registered a fbdev, then the fbdev registered
by a DRM driver won't be bound to the framebuffer console. To avoid that,
Hi Marek,
Thank you for the patch.
On Sat, May 15, 2021 at 10:39:32PM +0200, Marek Vasut wrote:
> Add missing spaces to make the diagrams readable, no functional change.
Looks better indeed. The patch view looks bad though, because of the
tabs. Maybe you could replace them with spaces, while at
Decoder input LVDS format is a property of the decoder chip or even
its strapping. Add DT property data-mapping the same way lvds-panel
does, to define the LVDS data mapping.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
To:
Decoder input LVDS format is a property of the decoder chip or even
its strapping. Handle data-mapping the same way lvds-panel does. In
case data-mapping is not present, do nothing, since there are still
legacy bindings which do not specify this property.
Signed-off-by: Marek Vasut
Cc: Laurent
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pclk-sample", not
the same as the one used by display timings but rather the same as used by
media, and configure bus flags based on this DT property.
Signed-off-by:
The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
select input pixel data sampling edge. Add DT property "pclk-sample", not
the same as the one used by display timings but rather the same as used by
media, to define the pixel data sampling edge.
Signed-off-by: Marek Vasut
Add missing spaces to make the diagrams readable, no functional change.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
.../devicetree/bindings/display/panel/lvds.yaml | 12
Hi Thomas,
Le sam., mai 15 2021 at 21:42:40 +0200, Thomas Zimmermann
a écrit :
Hi
Am 15.05.21 um 16:53 schrieb Paul Cercueil:
Alloc GEM buffers backed by noncoherent memory on SoCs where it is
actually faster than write-combine.
This dramatically speeds up software rendering on these
Remove most of remains of downstream usbpd code. Mainline kernel uses
different approach for managing Type-C / USB-PD, so this remains unused.
Do not touch usbpd callbacks for now, since they look usefull enough as
an example of how to handle connect/disconnect (to be rewritten into .
Hi
Am 15.05.21 um 16:53 schrieb Paul Cercueil:
Alloc GEM buffers backed by noncoherent memory on SoCs where it is
actually faster than write-combine.
This dramatically speeds up software rendering on these SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
The code does not really use dpu_hw_blk fields, so drop them, making
dpu_hw_blk empty structure.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c| 24 ---
Remove all unused dpu_hw_blk features and functions:
- dpu_hw_blk_get()/_put() and respective refcounting,
- global list of all dpu_hw_blk instances,
- dpu_hw_blk_ops and empty implementation inside each hw_blk subdriver.
This leaves dpu_hw_blk as a placeholder with just type and index.
Use struct dpu_hw_merge_3d pointer in struct dpu_hw_pingpong rather
than using struct dpu_hw_blk. This is the only user of dpu_hw_blk.id,
which will be cleaned in the next patch.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 11 ---
The dpu_hw_blk_destroy() function is empty, so we can drop it now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 2 --
Drop most of "extra" features of dpu_hw_blk.
Changes since v2:
- Include a patch to fix compilation issue with merge3d id handling
Changes since v1:
- Make dpu_hw_blk an empty structure
- Split this into separate patchset
Hi
Am 15.05.21 um 16:53 schrieb Paul Cercueil:
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: -
Am 15.05.21 um 16:53 schrieb Paul Cercueil:
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using
https://bugzilla.kernel.org/show_bug.cgi?id=209457
Marius (marius.andrei...@gmail.com) changed:
What|Removed |Added
CC|
On 10/05/2021 06:16, Zhen Lei wrote:
The error code returned by platform_get_irq() is stored in 'irq', it's
forgotten to be copied to 'ret' before being returned. As a result, the
value 0 of 'ret' is returned incorrectly.
After the above fix is completed, initializing the local variable 'ret'
On 08/05/2021 05:28, Zhen Lei wrote:
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: 7f9743abaa79 ("drm/msm: validate display and event threads")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
Reviewed-by: Dmitry
/n should be \n
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff
On Sat, May 15, 2021 at 9:33 AM Maciej W. Rozycki wrote:
>
> NB I suggest that you request your change to be backported, i.e. post v3
> with:
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: sta...@vger.kernel.org # v2.6.12+
I've applied it to my tree, but let's wait to see that it doesn't
On Sat, 15 May 2021, Maciej W. Rozycki wrote:
> On Sat, 15 May 2021, Tetsuo Handa wrote:
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 3406067985b1..22bb3892f6bd 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++
The pull request you sent on Sat, 15 May 2021 07:02:44 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-05-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/33f85ca44eec7f1ad4be3f3b8d575845b789f1b3
Thank you!
--
Deet-doot-dot, I am a bot.
On Sat, 15 May 2021, Tetsuo Handa wrote:
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 3406067985b1..22bb3892f6bd 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2019,7 +2019,7 @@ static int
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Overall I think it does make sense to resize the text console at any
> > time, even if the visible console (VT) chosen is in the graphics mode,
>
> It might make sense, but only if we call the function to update the
> low-level data.
>
> Not
On 5/15/21 5:09 AM, Robert Foss wrote:
> Hey Randy,
>
> I missed sending out a notification, but this patch was merged into
> drm-misc-next.
>
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=08319adbdde15ef7cee1970336f63461254baa2a
OK, thanks, Robert.
I was mainly asking because the
Alloc GEM buffers backed by noncoherent memory on SoCs where it is
actually faster than write-combine.
This dramatically speeds up software rendering on these SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
v3: The option is now selected per-SoC
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on
Rework of this morning's v3 patchset.
The drm_gem_cma_prime_mmap() function that was added in v3 is now
replaced, instead we pass a "private" parameter to the
__drm_gem_cma_create() function.
Patches 2/3 and 3/3 are unmodified since v3.
Cheers,
-Paul
Paul Cercueil (3):
drm: Add support for
Excuse my novicesness,
i use 2 RX460 on a KGPE-D16 server board to drive 4 displays.
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Baffin [Radeon RX 460/560D / Pro
450/455/460/555/555X/560/560X] (rev cf)
06:00.0 VGA compatible controller: Advanced Micro Devices,
Add suspend / resume hooks for anx7625 driver, that power off the device
on suspend and power on the device on resume if it was previously
powered.
Signed-off-by: Pi-Hsun Shih
---
Changes from v2, v3:
* No change.
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 27 +++
1
Hello everybody,
I'm Igor, I'm participating in the Linux kernel mentorship program and
working to fix some bugs found by the syzbot. I'm currently working on
this bug below:
https://syzkaller.appspot.com/bug?id=071122e4f772c1ec834c7a6facc0b5058d215481
The bug consists of an out-of-bound
From: "libaok...@huawei.com"
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_mstm_cleanup':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1389:6: warning:
variable ‘ret’ set but not used [-Wunused-but-set-variable]
The driver originally use an atomic_t for keep track of the power
status, which makes the driver more complicated than needed, and has
some race condition as it's possible to have the power on and power off
sequence going at the same time.
This patch remove the usage of the atomic_t power_status,
Yes, it does indeed! No flicker anymore. Thanks and cheers!
On 2021-05-14 14:34, Oleksandr Natalenko wrote:
Hello.
On Fri, May 14, 2021 at 10:24:26AM +0200, Thomas Stein wrote:
After upgrading to linux 5.12 the display on my X1 Carbon Gen 2 starts
to
flicker. Well actually it seems to turn
Remove struct msm_dsi_dphy_timing field from the struct msm_dsi_phy.
There is no need to store them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 18 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 10 --
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this manual
setup allows us to drop repeating code and to move registration of hw
clock providers to generic place.
Signed-off-by: Dmitry Baryshkov
---
Instead of fetching shared timing through an extra function call, get
them directly from msm_dsi_phy_enable. This would allow removing phy
timings from the struct msm_dsi_phy in the next patch.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 5 ++---
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 947e1accae3a..b6ed94497e8a
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index
Use of_device_get_match-data() instead of of_match_node().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 454f794af547..2166549382c1
Assign DSI clock source parents to DSI PHY clocks.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 1ea3344ab62c..4e8708cce1cc 100644
This patch series brings back several patches targeting assigning dispcc
clock parents, that were removed from the massive dsi rework patchset
earlier.
Few notes:
- assign-clock-parents is a mandatory proprety according to the current
dsi.txt description.
- There is little point in
Hey Randy,
I missed sending out a notification, but this patch was merged into
drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=08319adbdde15ef7cee1970336f63461254baa2a
On Sat, 15 May 2021 at 07:35, Randy Dunlap wrote:
>
> On 4/19/21 10:54 AM, Randy Dunlap wrote:
> > On
Am 15.05.21 um 11:53 schrieb Dan Carpenter:
The drm_format_info() function returns NULL if the format is
unsupported, but the simplefb_get_validated_format() is expected to
return error pointers. If we propagate teh NULL return then it will
lead to a NULL dereference in the callers. Swap the
The drm_format_info() function returns NULL if the format is
unsupported, but the simplefb_get_validated_format() is expected to
return error pointers. If we propagate teh NULL return then it will
lead to a NULL dereference in the callers. Swap the NULL and trade it
in for an ERR_PTR(-EINVAL).
In the original code if the "ctx = devm_kzalloc()" allocation failed
then we should have called of_node_put(ep); before returning. It's
actually a bit easier to do the allocation first before assigning
ep = of_graph_get_endpoint_by_regs().
Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
This code is passing the wrong variable to PTR_ERR() so it doesn't
return the correct error code.
Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/bridge/ite-it66121.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Thomas,
Le sam., mai 15 2021 at 11:03:34 +0200, Thomas Zimmermann
a écrit :
Hi
Am 14.05.21 um 22:11 schrieb Paul Cercueil:
Having GEM buffers backed by non-coherent memory is interesting in
the
particular case where it is faster to render to a non-coherent buffer
then sync the data
Hi
Am 14.05.21 um 22:11 schrieb Paul Cercueil:
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than
On 2021/05/15 1:19, Tetsuo Handa wrote:
> Even if it turns out to be safe to always call this
> callback, we will need to involve another callback via "struct fb_ops" for
> checking the upper limits from fbcon_resize(). As a result, we will need
> to modify
>
> drivers/tty/vt/vt.c
>
On Fri, May 14, 2021 at 09:34:27AM -0700, Joseph Kogut wrote:
> On Fri, May 14, 2021 at 8:13 AM Joseph Kogut wrote:
> >
> > Hi Dan,
> >
> > On Fri, May 14, 2021 at 6:54 AM Dan Carpenter
> > wrote:
> > >
> > > Hello Joseph Kogut,
> > >
> > > The patch 70556e24e18e: "drm: remove usage of
71 matches
Mail list logo
