> -Original Message-
> From: dri-devel On Behalf Of
> Arun R Murthy
> Sent: Wednesday, January 8, 2025 11:09 AM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org
> Cc: Murthy, Arun R
> Subject: [PATCH v3 1/5] drm/plane: Add new p
From: Aradhya Bhatia
The cdns-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming[0]. Not having that, allows
for a small window before cdns-dsi enable and after cdns-dsi disable
where the previous entity (in this case tidss's videoport) to co
Move the bridge pre_enable call before crtc enable, and the bridge
post_disable call after the crtc disable.
The sequence of enable after this patch will look like:
bridge[n]_pre_enable
...
bridge[1]_pre_enable
crtc_enable
encoder_enable
bridge[1]
From: Aradhya Bhatia
Allow the D-Phy config checks to use mode->clock instead of
mode->crtc_clock during mode_valid checks, like everywhere else in the
driver.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Reviewed-by: Tomi Valkeinen
Signed-off-by: Aradhya Bhatia
Signed-of
From: Aradhya Bhatia
At present, the DSI mode configuration check happens during the
_atomic_enable() phase, which is not really the best place for this.
Moreover, if the mode is not valid, the driver gives a warning and
continues the hardware configuration.
Move the DSI mode configuration check
From: Aradhya Bhatia
Change the existing (and deprecated) bridge hooks, to the bridge
atomic APIs.
Add drm helpers for duplicate_state, destroy_state, and bridge_reset
bridge hooks.
Further add support for the input format negotiation hook.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Tomi Valk
From: Aradhya Bhatia
Add a helper API that can be used by the DSI hosts to find the required
input bus format for the given output dsi pixel format.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Tomi Valkeinen
Signed-off-by: Aradhya Bhatia
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/drm_
From: Aradhya Bhatia
Once the DSI Link and DSI Phy are initialized, the code needs to wait
for Clk and Data Lanes to be ready, before continuing configuration.
This is in accordance with the DSI Start-up procedure, found in the
Technical Reference Manual of Texas Instrument's J721E SoC[0] which
h
From: Aradhya Bhatia
Check for the return value of the phy_mipi_dphy_get_default_config()
call, and incase of an error, return back the same.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Reviewed-by: Tomi Valkeinen
Signed-off-by: Aradhya Bhatia
Signed-off-by: Aradhya Bhat
Hello all,
This series provides some crucial fixes and improvements for the Cadence's DSI
TX (cdns-dsi) controller found commonly in Texas Instruments' J7 family of SoCs
as well as in Sitara AM62P and AM62L SoCs.
Along with that, this series aims to fix the color-shift issue that has been
going o
From: Aradhya Bhatia
The order of init of DSI link and DSI phy is wrong. The DSI link needs
to be configured before the DSI phy is getting configured. Otherwise,
the D-Phy is unable to lock in on the incoming PLL Reference clock[0].
Fix the order of inits.
[0]: See section 12.6.5.7.3 "Start-up
From: Aradhya Bhatia
The driver code doesn't have a de-initialization path as yet, and so it
does not clear the phy_initialized flag while suspending. This is a
problem because after resume the driver looks at this flag to determine
if a Phy re-initialization is required or not. It is in fact req
From: Aradhya Bhatia
Instead of manually finding the next bridge/panel, and maintaining the
panel-bridge (in-case the next entity is a panel), switch to using the
automatically managing devm_drm_of_get_bridge() API.
Drop the drm_panel support completely from the driver while at it.
Reviewed-by:
From: Aradhya Bhatia
Fix the OF node pointer passed to the of_drm_find_bridge() call to find
the next bridge in the display chain.
The code to find the next panel (and create its panel-bridge) works
fine, but to find the next (non-panel) bridge does not.
To find the next bridge in the pipeline,
On Fri, Jan 10, 2025 at 09:31:16AM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2025 at 12:40:28AM +0800, Xu Yilun wrote:
>
> > So then we face with the shared <-> private device conversion in CoCo VM,
> > and in turn shared <-> private MMIO conversion. MMIO region has only one
> > physical bac
I am fine with that as well.
Zhenyu Wang 于 2025年1月11日周六 上午7:26写道：
> On Fri, Jan 10, 2025 at 12:49:27PM +0200, Jani Nikula wrote:
> > On Thu, 09 Jan 2025, Rodrigo Vivi wrote:
> > > On Mon, Jan 06, 2025 at 04:30:20PM +0900, Zhenyu Wang wrote:
> > >> On Sun, Dec 22, 2024 at 12:25:09AM +, Dr. D
On 11 January 2025 01:49:23 EET, Abhinav Kumar
wrote:
>
>
>On 1/9/2025 6:02 PM, Dmitry Baryshkov wrote:
>> On Thu, Jan 09, 2025 at 05:40:23PM -0800, Abhinav Kumar wrote:
>>>
>>>
>>> On 1/5/2025 7:07 PM, Dmitry Baryshkov wrote:
The fix_core_ab_vote is an average bandwidth value, used for ba
patch link:
https://lore.kernel.org/r/20250110023618.66401-3-Wayne.Lin%40amd.com
patch subject: [Patch v3 2/2] drm/dp_mst: Add helper to get port number at
specific LCT from RAD
config: x86_64-randconfig-121-20250111
(https://download.01.org/0day-ci/archive/20250111/20250927.qhx3zcbp-...@intel.
From: Andy Yan
VOP2 on rk3576:
Three video ports:
VP0 Max 4096x2160
VP1 Max 2560x1600
VP2 Max 1920x1080
2 4K Cluster windows with AFBC/RFBC, line RGB and YUV
4 Esmart windows with line RGB/YUV support:
Esmart0/1: 4K
Esmart2/3: 2k, or worked together as a single 4K plane at shared
line buffer mod
From: Andy Yan
In the upcoming VOP of rk3576, a window cannot attach to all Video
Ports, we introduce a possible_vp_mask for every window to indicate
which Video Ports this window can attach to.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casanova
---
(no
From: Andy Yan
The Cluster windows of upcoming VOP on rk3576 also support
linear YUV support, we need to set uv swap bit for it.
As the VOP2_WIN_UV_SWA register defined on rk3568/rk3588 is
0x, so this register will not be touched on these
two platforms.
Signed-off-by: Andy Yan
Tested-b
From: Andy Yan
Add vop found on rk3576, the main difference between rk3576 and the
previous vop is that each VP has its own interrupt line.
Signed-off-by: Andy Yan
---
Changes in v11:
- Remove redundant min/maxItems constraint
Changes in v10:
- Move interrupt-names back to top level
- Add co
From: Andy Yan
In the upcoming VOP for rk3576, every VP has it's own LAYER_SEL
register, and the configuration value of each VP for the same
window maybe different, so extend the layer_sel_id to array,
let it can descption the layer select configuration value for
different VP.
Signed-off-by: And
From: Andy Yan
Patches that have already been merged in drm-misc-next are dropped.
PATCH 1~9 are preparations for rk3576 support
PATCH 10~11 are real support for rk376
I test it with a 1080P/4K HDMI output with modetest and weston
output.
If there are some one want to have a try, I have a tre
From: Heiko Stuebner
Right now vop2_cluster_init() copies the base vop2_cluster_regs
and adapts the reg value with the current window's offset before
adding the fields to the regmap.
This conflicts with the notion of reg_fields being const, see
https://lore.kernel.org/all/20240706-regmap-const-s
From: Andy Yan
In the upcoming VOP of rk3576, a Window cannot attach to all Video Ports,
so make sure all VP find it's suitable primary plane, then register the
remain windows as overlay plane will make code easier.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detle
From: Andy Yan
The VOP interface mux, overlay, background delay cycle configuration
of different SOC are much different. Add platform specific callback
ops to let the core driver look cleaner and more refined.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casa
From: Andy Yan
There is a version number hardcoded in the VOP VERSION_INFO
register, and the version number increments sequentially based
on the production order of the SOC.
So using this version number to distinguish different VOP features
will simplify the code.
Signed-off-by: Andy Yan
Teste
From: Andy Yan
Now these two function share the same logic, the can
be merged as one.
Signed-off-by: Andy Yan
---
(no changes since v1)
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 42 +---
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/rock
From: Andy Yan
This help avoid "exceeds 100 columns" warning from checkpatch
Signed-off-by: Andy Yan
---
(no changes since v1)
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
d
On Fri, Jan 10, 2025 at 12:49:27PM +0200, Jani Nikula wrote:
> On Thu, 09 Jan 2025, Rodrigo Vivi wrote:
> > On Mon, Jan 06, 2025 at 04:30:20PM +0900, Zhenyu Wang wrote:
> >> On Sun, Dec 22, 2024 at 12:25:09AM +, Dr. David Alan Gilbert wrote:
> >> > Note: zhen...@linux.intel.com's address bounc
On Thu, Jan 09, 2025 at 04:10:24PM -0500, Rodrigo Vivi wrote:
> On Mon, Jan 06, 2025 at 04:30:20PM +0900, Zhenyu Wang wrote:
> > On Sun, Dec 22, 2024 at 12:25:09AM +, Dr. David Alan Gilbert wrote:
> > > Note: zhen...@linux.intel.com's address bounces:
> > >
> >
> > yeah, I've left Intel so ca
Hi Damon,
At 2025-01-09 11:27:25, "Damon Ding" wrote:
>Add the necessary DT changes to enable eDP0 on RK3588S EVB1 board:
>- Set pinctrl of pwm12 for backlight
>- Enable edp0/hdptxphy0/vp2
>- Add aux-bus/panel nodes
>
>Signed-off-by: Damon Ding
>
>---
>
>Changes in v2:
>- Remove brightness-leve
On Fri, Jan 10, 2025 at 01:39:51PM +0800, Ao Xu wrote:
> Add devicetree document for S4 HDMI controller
>
> Signed-off-by: Ao Xu
> ---
> Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/Documentation/devicetree/bind
On Thu, Jan 09, 2025 at 04:12:39AM +0530, Akhil P Oommen wrote:
> Update the RPMH level definitions to include TURBO_L5 corner.
>
> Signed-off-by: Akhil P Oommen
> ---
> include/dt-bindings/power/qcom-rpmpd.h | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski
Best regards,
On Thu, Jan 09, 2025 at 04:12:40AM +0530, Akhil P Oommen wrote:
> Document compatible string for the QFPROM on X1E80100 platform.
>
> Signed-off-by: Akhil P Oommen
> ---
This shouldn't be really RFC...
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
36 matches
Mail list logo
