The Rockchip RGB CRTC output driver attempts to avoid probing Rockchip
subdrivers to see if they're a connected panel or bridge. However part
of its checks assumes that if no OF platform device is found then it
can't be a valid bridge or panel. This causes issues with I2C controlled
bridges that ha
From: zuoqilin
Change 'befor' to 'before'.
Signed-off-by: zuoqilin
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f94025e..45187ff 100644
--- a
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
include/drm/gpu_scheduler.h:304: warning: Function parameter or member '_score'
not described in 'drm_gpu_scheduler'
Introduced by commit
f2f12eb9c32b ("drm/scheduler: provide scheduler score exter
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 Team,
I didn't receive the reviewer's message from maintainers on panfrost driver for
several days.
Due to this
On Wed, Mar 17, 2021 at 8:22 AM Christoph Hellwig wrote:
> On Tue, Mar 16, 2021 at 04:52:44PM +0100, Daniel Vetter wrote:
> > My understanding is mostly, but with some objections. And I kinda
> > don't want to let this die in a bikeshed and then not getting rid of
> > follow_pfn as a result. There
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 look all good to me, so for
> > > > 23-53: Reviewed-by: Roland Sch
https://bugzilla.kernel.org/show_bug.cgi?id=212293
--- Comment #7 from Sefa Eyeoglu (cont...@scrumplex.net) ---
I submitted a patch here:
https://lists.freedesktop.org/archives/amd-gfx/2021-March/060754.html
--
You may reply to this email to add a comment.
You are receiving this mail because:
Y
On 14/03/2021 17:13, Dario Binacchi wrote:
As reported by TI spruh73x RM, the LCD pixel clock (LCD_PCLK) frequency
is obtained by dividing LCD_CLK, the LCD controller reference clock,
for CLKDIV:
LCD_PCLK = LCD_CLK / CLKDIV
where CLKDIV must be greater than 1.
Therefore LCD_CLK must be set to
This fixes the following sparse warnings:
drivers/gpu/drm/gma500/psb_drv.c:303:56: warning: Using plain integer as
NULL pointer
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
+Rohit
On 3/17/21 4:00 AM, quanyang.wang wrote:
> Hi Laurent,
>
> On 3/17/21 4:32 AM, Laurent Pinchart wrote:
>> Hi Quanyang,
>>
>> Thank you for the patch.
>>
>> On Wed, Mar 10, 2021 at 12:59:45PM +0800, quanyang.w...@windriver.com
>> wrote:
>>> From: Quanyang Wang
>>>
>>> The Runtime PM subsys
From: tangchunyou
already prints an error.
Signed-off-by: tangchunyou
---
drivers/gpu/drm/mediatek/mtk_cec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c
b/drivers/gpu/drm/mediatek/mtk_cec.c
index cb29b64..332a4df 100644
--- a/drive
s/refence-count/reference-count/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 20d22e41d7ce..2bfc724e8e41 100644
--- a/drivers/gpu/drm/drm_drv.c
+++
On Sun, 14 Mar 2021, Marijn Suijten wrote:
> From: Obeida Shamoun
>
> WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset.
> Therefore, use the sink address as base instead of the ctrl address.
>
> This fixes the sync toggle on wled4, which can be observed by the fact
> that adj
Hi Rob,
On 2021-03-16 22:46, Rob Clark wrote:
...
> >
> > When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped
> > into the CPU and with what attributes? Rob said "writecombine for
> > everything" -- does that mean ioremap_wc() / MEMREMAP_WC?
>
> Currently userspace asks
From: tangchunyou
disable,delete disable and return 0
Signed-off-by: tangchunyou
---
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c
b/drivers/gpu/drm/nouveau/nvkm/sub
From: tangchunyou
1.the type of mipi_dsi_create_packet id int
2.u32 can not < 0
Signed-off-by: tangchunyou
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 8e11
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 common LVDS PHY
> implementation practices. The set of parameters
> should cov
https://bugzilla.kernel.org/show_bug.cgi?id=212311
Bug ID: 212311
Summary: amdgpu DCN callis sleeping function in illegal context
Product: Drivers
Version: 2.5
Kernel Version: 5.11.0
Hardware: All
OS: Linux
Tr
https://bugzilla.kernel.org/show_bug.cgi?id=212311
--- Comment #1 from Nirmoy (nirmoy.ai...@gmail.com) ---
DCN also calls into SMU which can sleep because of mutex_lock(&smu->mutex)
[6.547189] amdgpu :44:00.0: amdgpu: SMU is initialized successfully!
[6.547217] BUG: sleeping function
Hi Rohit,
On 3/17/21 7:17 PM, Rohit Visavalia wrote:
Hi Quanyang & Laurent,
I tested this patch(which moves pm_runtime_get_sync at the very beginning of
the function zynqmp_disp_crtc_atomic_enable), i don't see any behavior change
with patch, means with patch also DP display is not getting up
Hi,
On 17/03/2021 11:48, ChunyouTang wrote:
From: tangchunyou
1.the type of mipi_dsi_create_packet id int
2.u32 can not < 0
Signed-off-by: tangchunyou
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.
On Tue, Mar 16, 2021 at 06:06:40PM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2021-03-03 00:45:27)
> > Hi Stephen,
> >
> > On Tue, Mar 02, 2021 at 03:18:58PM -0800, Stephen Boyd wrote:
> > > Quoting Maxime Ripard (2021-02-25 07:59:02)
> > > > Some devices might need to access the current
Hi Quanyang & Laurent,
I tested this patch(which moves pm_runtime_get_sync at the very beginning of
the function zynqmp_disp_crtc_atomic_enable), i don't see any behavior change
with patch, means with patch also DP display is not getting up and it is
required to resolution change to make it up.
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
Restructure MSM DSI PHY drivers. What started as an attempt to grok the
overcomplicated PHY drivers, has lead up to the idea of merging PHY and
PLL code, reducing abstractions, code duplication, dropping dead code,
etc.
The patches were mainly tested on RB5 (sm8250, 7nm) and DB410c (apq8016,
28nm-
Add devm_clk_hw_register_mux() - devres-managed version of
clk_hw_register_mux().
Signed-off-by: Dmitry Baryshkov
---
drivers/clk/clk-mux.c| 35 +++
include/linux/clk-provider.h | 13 +
2 files changed, 48 insertions(+)
diff --git a/drivers/cl
Add devm_clk_hw_register_divider() - devres version of
clk_hw_register_divider().
Signed-off-by: Dmitry Baryshkov
---
include/linux/clk-provider.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 3eb15e0262f5
Move all PLL-related callbacks into struct msm_dsi_phy_cfg. This limits
the amount of data in the struct msm_dsi_pll.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 14 +--
drivers/gpu/drm/msm/dsi/phy/dsi
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 +
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 ++
drivers/gpu/drm/
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 1006
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
---
drivers/gpu/dr
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 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy
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
drivers/gpu/dr
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 ---
driv
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
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 1006
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
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 | 36
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 -
drivers/gpu/drm/msm/dsi/phy/dsi_ph
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 +++
drivers/gpu/drm/msm/d
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 a/drivers/gpu/dr
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 ++
drivers/gpu/drm/msm/dsi
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
---
dri
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
drivers/gpu/drm/msm/dsi/phy/ds
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
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 +++---
drivers/g
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: Dmit
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
---
drivers/gpu/drm/msm/
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 on
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 Te
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 o
[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)
; dri-dev
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 of
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 i
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
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 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 alre
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 | 2
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 w
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 +---
driver
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
---
drivers/gpu
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 w
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 c
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 --
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 +++-
drivers
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(-)
d
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 switc
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 +++
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
st
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: Maxim
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 +++---
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 hdcp_confi
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
a/Documentation/devicetree/bindings/display/bridge/cdns
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 +
.../drm/bridge/cadence/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 BPC
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
b/drivers/gpu/drm/amd/amdgpu/amdgpu
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 point
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, 50
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: R
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 b/drivers/gpu/dr
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
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.
- Adde
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
---
drivers/gpu/drm/tegra/d
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
https://bugzilla.kernel.org/show_bug.cgi?id=212077
Bat Malin (bat_ma...@abv.bg) changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolutio
https://bugzilla.kernel.org/show_bug.cgi?id=212077
Bat Malin (bat_ma...@abv.bg) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolutio
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&action=edit
Picture of memory status (new)
--
You may reply to this email to add a comment.
You are recei
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&action=edit
Dmesg (new)
--
You may reply to this email to add a comment.
You are receiving this mail beca
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
>
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
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 l
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 commit,
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
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.
- Retur
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 dma_fence_arr
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
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 a/drivers/gpu/drm/nouveau/dispnv
1 - 100 of 133 matches
Mail list logo
