Hi Dave, Daniel,
Fixes for 5.12.
The following changes since commit 4042160c2e5433e0759782c402292a90b5bf458d:
drm/nouveau: fix dma syncing for loops (v2) (2021-03-12 11:21:47 +1000)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On Wed, Feb 24, 2021 at 2:14 PM Hsin-Yi Wang wrote:
>
> When suspending the driver, anx7625_power_standby() will be called to
> turn off reset-gpios and enable-gpios. However, power supplies are not
> disabled. To save power, the driver can get the power supply regulators
> and turn off them in
From: zuoqilin
Remove unneeded variable: "rc".
Signed-off-by: zuoqilin
---
drivers/gpu/drm/msm/dp/dp_panel.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 9cc8166..8cb3d01 100644
---
On 3/17/21 21:47, Chunyou Tang wrote:
> I think "if (info == NULL)" is more intuitive,and there have many
> compare likes "if (info == NULL)" in this file.
In that case, all those instances should be changed to if (!foo), instead.
--
Gustavo
___
From: tangchunyou
modify 'if (addrp == NULL)' to 'if (!addr)
Signed-off-by: tangchunyou
---
drivers/video/fbdev/offb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index cd1042f..52d86e3 100644
---
On Wed, Mar 17, 2021 at 10:37 PM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dwb_cm.c:220:65-70:
> WARNING: conversion to bool not needed here.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Applied. Thanks. In
On Tue, Mar 16, 2021 at 4:09 AM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c:721:65-70: WARNING:
> conversion to bool not needed here.
>
> ./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c:1139:67-72: WARNING:
> conversion
On 3/17/21 21:33, ChunyouTang wrote:
> From: tangchunyou
>
> modify 0 to NULL,info is a pointer,it should be
>
> compared with NULL,not 0
>
> Signed-off-by: tangchunyou
> ---
> drivers/video/fbdev/offb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Hi,Gustavo
On Wed, 17 Mar 2021 20:54:41 -0500
"Gustavo A. R. Silva" wrote:
> On 3/17/21 21:47, Chunyou Tang wrote:
>
> > I think "if (info == NULL)" is more intuitive,and there have many
> > compare likes "if (info == NULL)" in this file.
>
> In that case, all those instances should be
HI,Gustavo
On Wed, 17 Mar 2021 20:41:15 -0500
"Gustavo A. R. Silva" wrote:
> On 3/17/21 21:33, ChunyouTang wrote:
> > From: tangchunyou
> >
> > modify 0 to NULL,info is a pointer,it should be
> >
> > compared with NULL,not 0
> >
> > Signed-off-by: tangchunyou
> > ---
> >
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dwb_cm.c:220:65-70:
WARNING: conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dwb_cm.c | 2 +-
1 file changed, 1
From: tangchunyou
modify 0 to NULL,info is a pointer,it should be
compared with NULL,not 0
Signed-off-by: tangchunyou
---
drivers/video/fbdev/offb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index
Hi Vinod,
On Wed, 2021-03-17 at 15:52 +0530, Vinod Koul wrote:
> On 08-03-21, 11:52, Liu Ying wrote:
> > This patch allows LVDS PHYs to be configured through
> > the generic functions and through a custom structure
> > added to the generic union.
> >
> > The parameters added here are based on
On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke wrote:
>
> On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > The sc7180-trogdor-pompom board might be attached to any number of a
> > pile of eDP panels. At the moment I'm told that the list might include:
> > - KD
Hi all,
On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/display/intel_sprite.c
>
> between commit:
>
> 92f1d09ca4ed ("drm: Switch to %p4cc format modifier")
>
> from the drm tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/omapdrm/dss/dsi.c
between commit:
690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero")
from the drm-misc-fixes tree and commit:
bbd13d6a7b2e ("drm/omap: dsi: fix unreachable code
Hi Parshuram,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linux/master linus/master v5.12-rc3 next-20210317]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
cdns-mhdp8546-hdcp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c
index
Hi, Jitao:
Jitao Shi 於 2021年2月1日 週一 上午11:48寫道：
>
> Some panels or bridges require customized hs_da_trail time.
> So add a property in devicetree for this panels and bridges.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
> 1 file changed, 9
Hi Stephen,
Reviving a bit of an old thread, for a question.
On Mon, Nov 02, 2020 at 10:11:43AM -0800, Stephen Boyd wrote:
> Use the DDC connection to read the EDID from the eDP panel instead of
> relying on the panel to tell us the modes.
>
> Reviewed-by: Douglas Anderson
> Reviewed-by:
This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
has never been used by any real userspace.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 94 ++-
It's never been used by any real userspace. It's used by IGT as a
short-cut for sharing VMs and other stuff between contexts.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 217 +---
include/uapi/drm/i915_drm.h
From: Ashutosh Dixit
The rationale for this change is roughly as follows:
1. The functionality can be done entirely in userspace with a
combination of mmap + memcpy
2. The only reason anyone in userspace is still using it is because
someone implemented bo_subdata that way in libdrm
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations. The older i965
driver in Mesa
libdrm has supported the newer execbuffer2 ioctl and using it by default
when it exists since libdrm commit b50964027bef which landed Mar 2, 2010.
The i915 and i965 drivers in Mesa at the time both used libdrm and so
did the Intel X11 back-end. The SNA back-end for X11 has always used
These patches clean up some of our uAPI mess in i915. The first patch
drops legacy execbuffer support which hasn't been used in 10 years. The
next two drop some legacy ioctls on new platforms. The last two drop APIs
which have never been used by userspace and shouldn't have landed in i915
in
On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> The sc7180-trogdor-pompom board might be attached to any number of a
> pile of eDP panels. At the moment I'm told that the list might include:
> - KD KD116N21-30NV-A010
> - KD KD116N09-30NH-A016
> - Starry 2081116HHD028001-51D
> -
When it comes to gamma or degamma luts, nouveau will actually skip the
calculation of certain LUTs depending on the head and plane states. For
instance, when the head is disabled we don't perform any error checking on
the gamma LUT, and likewise if no planes are present and enabled in our
atomic
Since this is used in the atomic check, we should use the right debug macro
for it.
Signed-off-by: Lyude Paul
Cc: Martin Peres
Cc: Jeremy Cline
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating the
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
-
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
On Tue, Mar 16, 2021 at 11:46:38PM +, Daniel Stone wrote:
> On Tue, 16 Mar 2021 at 21:35, Daniel Vetter wrote:
>
> > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen
> > wrote:
> > > On Mon, 8 Mar 2021 16:52:58 -0800
> > > "Navare, Manasi" wrote:
> > > > Hmm well after the actual real
On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
>
> On Thu, 11 Mar 2021, Lee Jones wrote:
>
> > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> >
> > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote:
> > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote:
> > > >
> > > > > The vmwgfx ones
Hi Parshuram,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linux/master linus/master v5.12-rc3 next-20210317]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi,
On Wed, Mar 17, 2021 at 9:40 AM Rob Clark wrote:
>
> From: Rob Clark
>
> We have seen a couple cases where low memory situations cause something
> bad to happen, followed by a flood of these messages obscuring the root
> cause. Lets ratelimit the dmesg spam so that next time it happens we
https://bugzilla.kernel.org/show_bug.cgi?id=212077
--- Comment #11 from Bat Malin (bat_ma...@abv.bg) ---
Created attachment 295907
--> https://bugzilla.kernel.org/attachment.cgi?id=295907=edit
Dmesg (new)
--
You may reply to this email to add a comment.
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=212077
--- Comment #10 from Bat Malin (bat_ma...@abv.bg) ---
Created attachment 295905
--> https://bugzilla.kernel.org/attachment.cgi?id=295905=edit
Picture of memory status (new)
--
You may reply to this email to add a comment.
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=212077
Bat Malin (bat_ma...@abv.bg) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bugzilla.kernel.org/show_bug.cgi?id=212077
Bat Malin (bat_ma...@abv.bg) changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The Memory
It's useful to know the total number of underflow events and currently
the debug stats are getting reset each time CRTC is being disabled. Let's
account the overall number of events that doesn't get a reset.
Reviewed-by: Michał Mirosław
Signed-off-by: Dmitry Osipenko
---
This series adds memory bandwidth management to the NVIDIA Tegra DRM driver,
which is done using interconnect framework. It fixes display corruption that
happens due to insufficient memory bandwidth.
Changelog:
v16: - Implemented suggestions that were given by Michał Mirosław to v15.
-
15.03.2021 01:11, Michał Mirosław пишет:
> On Thu, Mar 11, 2021 at 08:22:55PM +0300, Dmitry Osipenko wrote:
>> It's useful to know the total number of underflow events and currently
>> the debug stats are getting reset each time CRTC is being disabled. Let's
>> account the overall number of events
On 3/17/21 1:52 AM, Bhaskar Chowdhury wrote:
>
> s/refence-count/reference-count/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/gpu/drm/drm_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c
From: Rob Clark
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't loose the kernel traces leading up to this.
Signed-off-by:
On 29/01/2021 10:22, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Add mtk mutex support for MT8183 SoC.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: CK Hu
> ---
> drivers/soc/mediatek/mtk-mutex.c | 50
> 1 file changed,
On Mon, Mar 1, 2021 at 1:41 PM Dmitry Baryshkov
wrote:
>
> if GPU components have failed to bind, shutdown callback would fail with
> the following backtrace. Add safeguard check to stop that oops from
> happening and allow the board to reboot.
>
> [ 66.617046] Unable to handle kernel NULL
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
On 17/03/2021 16:43, Maxime Ripard wrote:
> The atomic_get_output_bus_fmts bridge callback is there to list the
> available formats for output by decreasing order of preference.
>
> On HDMI controllers, we have a fairly static list that will depend on
> what the HDMI sink is capable of and the
This patch enable HDCP in MHDP driver.
Signed-off-by: Parshuram Thombare
Reviewed-by: Robert Foss
---
drivers/gpu/drm/bridge/cadence/Makefile | 2 +-
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 113 +++-
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 21 +
Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
Signed-off-by: Parshuram Thombare
---
.../display/bridge/cdns,mhdp8546.yaml | 24 +++
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git
This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver.
Changes since v1:
- Move sapb reg block right after apb reg block
- Corresponding changes in binding and example
Changes since v2:
- Revert reg resource sequence in binding and
use resource mapping by name
- Remove
In order to implement a fallback mechanism to YUV422 when the pixel rate
is too high, let's move the pixel rate computation to a function of its
own that will be shared across two functions.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 36 +++---
When using the modes that need the highest pixel rate we support (such
as 4k at 60Hz), using a 10 or 12 bpc output will put us over the limit
of what we can achieve.
In such a case, let's force our output to be YUV422 so that we can go
back down under the required clock rate.
Signed-off-by:
In order to support a YUV output, we're going to need to have access to
the bridge state in the vc4_hdmi_set_avi_infoframe function. Since we
also need the connector state in that function, let's pass the full
atomic state.
While we're at it, since all those functions actually need the vc4_hdmi
The HDMI controllers in the BCM2711 support YUV444 and YUV420 outputs,
let's add support for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 73 +++--
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 +++
drivers/gpu/drm/vc4/vc4_regs.h | 16
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
depends on whether we're using an RGB or YUV output. Let's move that
configuration to the CSC setup.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12 ++--
1 file
The vc4_set_crtc_possible_masks is meant to run over all the encoders
and then set their possible_crtcs mask to their associated pixelvalve.
However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into
a CRTC of its own"), the TXP has been turned to a CRTC and encoder of
its own, and
The limited_rgb_range field in the vc4_hdmi_encoder structure is used to
tell whether we're supposed to output with a full or limited RGB range.
This is redundant with the new helper we introduced, so let's convert to
that helper and drop that field.
Signed-off-by: Maxime Ripard
---
Converting the HDMI controller to a bridge seems like the preferred way
to support an YUV output, so let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 37 ++-
drivers/gpu/drm/vc4/vc4_drv.c | 15 +++--
drivers/gpu/drm/vc4/vc4_drv.h | 27 +---
The CSC callbacks takes a boolean as an argument to tell whether we're
using the full range or limited range RGB.
However, with the upcoming YUV support, the logic will be a bit more
complex. In order to address this, let's make the callbacks take the
entire mode, and call our new helper to tell
The atomic_get_output_bus_fmts bridge callback is there to list the
available formats for output by decreasing order of preference.
On HDMI controllers, we have a fairly static list that will depend on
what the HDMI sink is capable of and the BPC our controller can output.
The dw-hdmi driver
Due to a FIFO that cannot be flushed between the pixelvalve and the HDMI
controllers on BCM2711, we need to carefully disable both at boot time
if they were left enabled by the firmware.
However, at the time we're running that code, the struct drm_connector
encoder pointer isn't set yet, and thus
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 141 +-
1 file changed, 28 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index d010c9c525d9..39b380453183 100644
The new bridge rework to support the input and output formats introduced
some boilerplate code that will need to be shared across drivers.
Since dw-hdmi is the only driver so far, let's introduce those helpers
based on that code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Makefile |
Hi,
Here's an attempt at support the HDMI YUV output on the BCM2711 SoC found on
the RaspberryPi4.
I took the same approach than what dw-hdmi did already, turning a bunch of
functions found in that driver into helpers since they were fairly generic.
However, it feels a bit clunky overall and
The current code does a binary or on the possible_crtcs variable of the
TXP encoder, while we want to set it to that value instead.
Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
1 file changed, 1
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.
On some setups, while the monitor and the gpu support display modes with
pixel clocks
[AMD Official Use Only - Internal Distribution Only]
Hi，Andrey，
Good catch，I will expore this corner case and give feedback soon～
Best，
Jack
From: Grodzovsky, Andrey
Sent: Wednesday, March 17, 2021 10:50:59 PM
To: Christian König ; Zhang, Jack (Jian)
;
On Wed, Mar 17, 2021 at 09:41:46AM -0500, Jason Ekstrand wrote:
> I should probably have said that the reviews are on v5 and it's very
> different in v6 so they should probably be considered dropped until
> re-confirmed.
You're checking relocation_count early in do_execbuffer() so imo there's
no
I actually have a race condition concern here - see bellow -
On 2021-03-17 3:43 a.m., Christian König wrote:
I was hoping Andrey would take a look since I'm really busy with other
work right now.
Regards,
Christian.
Am 17.03.21 um 07:46 schrieb Zhang, Jack (Jian):
Hi, Andrey/Crhistian and
I should probably have said that the reviews are on v5 and it's very
different in v6 so they should probably be considered dropped until
re-confirmed.
On Wed, Mar 17, 2021 at 9:39 AM Jason Ekstrand wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running
All PHY drivers would map dsi_pll area. Some PHY drivers would also
map dsi_phy area again (a leftover from old PHY/PLL separation). Move
all ioremaps to the common dsi_phy driver code and drop individual
ioremapped areas from PHY drivers.
Signed-off-by: Dmitry Baryshkov
---
With the current upstream driver the msm_dsi_phy_type enum does not make
much sense: all DSI PHYs are probed using the dt bindings, the phy type
is not passed between drivers. Use quirks in phy individual PHY drivers
to differentiate minor harware differences and drop the enum.
Signed-off-by:
Drop duplicate fields pdev and id from dsi_pll_Nnm instances. Reuse
those fields from the provided msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 72 +--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 54 +++---
Phy driver already knows the source PLL id basing on the set usecase and
the current PLL id. Stop passing it to the phy_enable call. As a
reminder, dsi manager will always use DSI 0 as a clock master in a slave
mode, so PLL 0 is always a clocksource for DSI 0 and it is always a
clocksource for DSI
Replace PLL accessor functions (pll_read/pll_write*) with the DSI PHY
accessors, reducing duplication.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 24 +--
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 124
The src_truthtable config is not used for some of phys, which use other
means of configuring the master/slave usecases. Inline this function
with the goal of removing src_pll_id argument in the next commit.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 17
The 7nm, 10nm and 14nm drivers would store interim data used during
VCO/PLL rate setting in the global dsi_pll_Nnm structure. Move this data
structures to the onstack storage. While we are at it, drop
unused/static 'config' data, unused config fields, etc.
Signed-off-by: Dmitry Baryshkov
---
All MSM DSI PHYs provide two clocks: byte and pixel ones.
Register/unregister provided clocks from the generic place, removing
boilerplate code from all MSM DSI PHY drivers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 23 ++
Use devm_of_clk_add_hw_provider() to register provided clocks. This
allows dropping the remove function alltogether.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git
Make save_state/restore callbacks accept struct msm_dsi_phy rather than
struct msm_dsi_pll. This moves them to struct msm_dsi_phy_ops, allowing
us to drop struct msm_dsi_pll_ops.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 12 +++
Use devres-enabled version of clock registration functions. This lets us
remove dsi_pll destroy callbacks completely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 4 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 -
Drop the struct msm_dsi_pll abstraction, by including vco's clk_hw
directly into struct msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 8 --
drivers/gpu/drm/msm/Makefile | 2 -
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h |
10nm and 7nm already do not use these helpers, as they handle setting
slave DSI clocks after enabling VCO. Modify the rest of PHY drivers to
remove unnecessary indirection and drop enable_seq/disable_seq PLL
callbacks.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
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
Morph msm_dsi_pll_save/restore_state() into msm_dsi_phy_save/restore_state(),
thus removing last bits of knowledge about msm_dsi_pll from dsi_manager.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 18 ++-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 6
DSI PHY init callback would either map dsi_phy_regulator or dsi_phy_lane
depending on the PHY type. Replace those callbacks with configuration
options governing mapping those regions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 42 ---
Only 28nm PHY requires sleeping during the VCO rate setting procedure.
Rewrite sleeping for 28nm and drop vco_delay from the rest of PHYs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 3 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4
msm_dsi_pll_set_usecase() function is not used outside of individual DSI
PHY drivers, so drop it in favour of calling the the respective
set_usecase functions directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 7 ---
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
---
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
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 10 ++
The only PLL using multiple enable sequences is the 28nm PLL, which just
does the single step in the loop. Push that support back into the PLL
code.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 3 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c| 23
1 - 100 of 130 matches
Mail list logo
