On Mon, Feb 03, 2025 at 04:25:59PM -0800, Abhinav Kumar wrote:
>
>
> On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
> > Setup the HDMI connector on the MSM HDMI outputs. Make use of
> > atomic_check hook and of the provided Infoframe infrastructure.
> >
>
> By atomic_check are you referring to t
On Mon, Feb 03, 2025 at 11:34:00AM -0800, Abhinav Kumar wrote:
>
>
> On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
> > The mode_set callback is deprecated, it doesn't get the
> > drm_bridge_state, just mode-related argumetns. Also Abhinav pointed out
> > that HDMI timings should be programmed aft
On Mon, Feb 03, 2025 at 09:14:26PM +0300, Danila Tikhonov wrote:
> From: Eugene Lepshy
>
> DRM DSC helper has parameters for various bpc values other than 8:
> (8/10/12/14/16).
>
> Remove this guard.
>
> Signed-off-by: Eugene Lepshy
> Signed-off-by: Danila Tikhonov
> ---
> drivers/gpu/drm/
On 2/3/2025 2:57 AM, Abel Vesa wrote:
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
According to the DisplayPort standard, LTTPRs have two
On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
By atomic_check are you referring to the
msm_hdmi_bridge_tmds_char_rate_valid()?
Also please confirm if HDMI audio w
On Mon, 03 Feb 2025 21:14:24 +0300, Danila Tikhonov wrote:
> The Visionox RM692E5 is a 6.55” AMOLED panel used in Nothing Phone (1)
> (sm7325-nothing-spacewar).
>
> Signed-off-by: Danila Tikhonov
> ---
> .../display/panel/visionox,rm692e5.yaml | 77 +++
> 1 file changed,
On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Also Abhinav pointed out
that HDMI timings should be programmed after setting up HDMI PHY and
PLL. Rework the code to program HDMI timings at the
From: Eugene Lepshy
DRM DSC helper has parameters for various bpc values other than 8:
(8/10/12/14/16).
Remove this guard.
Signed-off-by: Eugene Lepshy
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --
From: Eugene Lepshy
Enable the Adreno GPU and configure the Visionox RM692E5 panel.
Signed-off-by: Eugene Lepshy
Co-developed-by: Danila Tikhonov
Signed-off-by: Danila Tikhonov
---
Note:
Depends on
https://lore.kernel.org/linux-arm-msm/20250122-dpu-111-topology-v2-1-505e95964...@somainline.o
The Visionox RM692E5 is a 6.55” AMOLED panel used in Nothing Phone (1)
(sm7325-nothing-spacewar).
Signed-off-by: Danila Tikhonov
---
.../display/panel/visionox,rm692e5.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/dis
From: Eugene Lepshy
Add the driver for Visionox RM692E5 panel support found in Nothing
Phone (1).
Signed-off-by: Eugene Lepshy
Co-developed-by: Danila Tikhonov
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile
This patch series adds support for the Visionox RM692E5 panel, which is
used on the Nothing Phone (1) and then adds it to the DTS.
But before adding to DTS we need to allow all bpc values in DSC code,
because Visionox RM692E5 has a bpc value of 10. Also we need to make sure
that the DSC patch fo
On Mon, Feb 03, 2025 at 06:29:21PM +0100, Krzysztof Kozlowski wrote:
> Add bitfields for PHY_CMN_CLK_CFG0 and PHY_CMN_CLK_CFG1 registers to
> avoid hard-coding bit masks and shifts and make the code a bit more
> readable. While touching the lines in dsi_7nm_pll_save_state()
> resulting cached->pix
On Mon, Feb 03, 2025 at 06:29:18PM +0100, Krzysztof Kozlowski wrote:
> PHY_CMN_CLK_CFG0 register is updated by the PHY driver and by two
> divider clocks from Common Clock Framework:
> devm_clk_hw_register_divider_parent_hw(). Concurrent access by the
> clocks side is protected with spinlock, howe
On Mon, Feb 03, 2025 at 06:29:19PM +0100, Krzysztof Kozlowski wrote:
> PHY_CMN_CLK_CFG1 register is updated by the PHY driver and by a mux
> clock from Common Clock Framework:
> devm_clk_hw_register_mux_parent_hws(). There could be a path leading to
> concurrent and conflicting updates between PHY
On Mon, Feb 03, 2025 at 06:29:20PM +0100, Krzysztof Kozlowski wrote:
> PHY_CMN_CLK_CFG1 register has four fields being used in the driver: DSI
> clock divider, source of bitclk and two for enabling the DSI PHY PLL
> clocks.
>
> dsi_7nm_set_usecase() sets only the source of bitclk, so should leave
Changes in v2:
- Add Fixes tag
- New patch #4
- Link to v1:
https://lore.kernel.org/r/20250131-drm-msm-phy-pll-cfg-reg-v1-0-3b99efeb2...@linaro.org
Calling these improvements, not fixes, because I don't think we ever hit
actual concurrency issue. Although if we ever hit it, it would be very
tric
Add bitfields for PHY_CMN_CLK_CFG0 and PHY_CMN_CLK_CFG1 registers to
avoid hard-coding bit masks and shifts and make the code a bit more
readable. While touching the lines in dsi_7nm_pll_save_state()
resulting cached->pix_clk_div assignment would be too big, so just
combine pix_clk_div and bit_clk
PHY_CMN_CLK_CFG1 register is updated by the PHY driver and by a mux
clock from Common Clock Framework:
devm_clk_hw_register_mux_parent_hws(). There could be a path leading to
concurrent and conflicting updates between PHY driver and clock
framework, e.g. changing the mux and enabling PLL clocks.
PHY_CMN_CLK_CFG1 register has four fields being used in the driver: DSI
clock divider, source of bitclk and two for enabling the DSI PHY PLL
clocks.
dsi_7nm_set_usecase() sets only the source of bitclk, so should leave
all other bits untouched. Use newly introduced
dsi_pll_cmn_clk_cfg1_update() t
PHY_CMN_CLK_CFG0 register is updated by the PHY driver and by two
divider clocks from Common Clock Framework:
devm_clk_hw_register_divider_parent_hw(). Concurrent access by the
clocks side is protected with spinlock, however driver's side in
restoring state is not. Restoring state is called from
On 03/02/2025 15:35, Dmitry Baryshkov wrote:
>>>
>>> PLease add these bits to the corresponding XML file (here and later on)
>>
>>
>> I need some more input from you - I don't know which XML you talk about.
>> Do you think about:
>> drivers/gpu/drm/msm/registers/display/dsi_phy_7nm.xml
>
> Yes
>
On Mon, Feb 03, 2025 at 12:19:04PM +0100, Krzysztof Kozlowski wrote:
> On 31/01/2025 17:25, Dmitry Baryshkov wrote:
> >>
> >> -static void dsi_pll_disable_global_clk(struct dsi_pll_7nm *pll)
> >> +static void dsi_pll_cmn_clk_cfg1_update(struct dsi_pll_7nm *pll, u32 mask,
> >> +
On Mon, Feb 03, 2025 at 12:57:55PM +0200, Abel Vesa wrote:
> Looking at both i915 and nouveau DP drivers, both are setting the first
> LTTPR (if found) in transparent mode first and then in non-transparent
> mode, just like the DP v2.0 specification mentions in section 3.6.6.1.
>
> Being part of t
On 31/01/2025 17:25, Dmitry Baryshkov wrote:
>>
>> -static void dsi_pll_disable_global_clk(struct dsi_pll_7nm *pll)
>> +static void dsi_pll_cmn_clk_cfg1_update(struct dsi_pll_7nm *pll, u32 mask,
>> +u32 val)
>> {
>> +unsigned long flags;
>> u32 data;
On 31/01/2025 17:24, Dmitry Baryshkov wrote:
> On Fri, Jan 31, 2025 at 04:02:49PM +0100, Krzysztof Kozlowski wrote:
>> Calling these improvements, not fixes, because I don't think we ever hit
>> actual concurrency issue. Although if we ever hit it, it would be very
>> tricky to debug and find the
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them, which
is handling the explicit disabling of non-transparent mode and its
disable->enable sequence mentioned in the DP Standard v2.0 section
3.6.6.1.
So use the new
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them, which
is handling the explicit disabling of non-transparent mode and its
disable->enable sequence mentioned in the DP Standard v2.0 section
3.6.6.1.
So use the new
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it re
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it replies to DPCD LTTPR field specific AUX
requests, while passes through all other AUX requests
- transparent - it passes through all AUX requests.
Switching between this two modes is done by the DPT
Looking at both i915 and nouveau DP drivers, both are setting the first
LTTPR (if found) in transparent mode first and then in non-transparent
mode, just like the DP v2.0 specification mentions in section 3.6.6.1.
Being part of the standard, setting the LTTPR in a specific operation mode
can be ea
31 matches
Mail list logo
