>
> On Tue, Dec 17, 2024 at 02:51:47PM +0800, Sandor Yu wrote:
> > Add a new DRM DisplayPort and HDMI bridge driver for Candence
> MHDP8501
> > used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> > standards according embedded Firmware running in the uCPU.
> >
> > For iMX8MQ SOC, the
> Hi,
>
> On Tue, Dec 17, 2024 at 02:51:47PM +0800, Sandor Yu wrote:
> > +static ssize_t firmware_version_show(struct device *dev,
> > +struct device_attribute *attr, char *buf);
> > static
> struct
> > +device_attribute firmware_version = __ATTR_RO(firmware_vers
>
> On Tue, Dec 17, 2024 at 02:51:43PM +0800, Sandor Yu wrote:
> > Cadence MHDP IP includes a firmware. Driver and firmware communicate
> > through a mailbox. The basic mailbox access functions in this patch
> > are derived from the DRM bridge MHDP8546 driver.
> > New mailbox access functions ha
On Fri, Dec 20, 2024 at 10:24 AM Simona Vetter
wrote:
> On Thu, Dec 19, 2024 at 05:09:33PM +0100, Michel Dänzer wrote:
> > On 2024-12-19 10:02, Daniel Stone wrote:
> > >
> > > How this would be used in practice is also way too underdocumented. We
> > > need to document that exact-round-up 64b is
On 12/23/2024, Dmitry Baryshkov wrote:
> On Mon, Dec 23, 2024 at 02:41:40PM +0800, Liu Ying wrote:
>> i.MX8qxp Display Controller(DC) is comprised of three main components that
>> include a blit engine for 2D graphics accelerations, display controller for
>> display output processing, as well as a
The raw edid for B140UAN04.4 panel is:
00 ff ff ff ff ff ff 00 06 af b3 a7 00 00 00 00
0c 22 01 04 a5 1e 13 78 03 cb 55 91 57 5a 91 29
1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 f4 3c 80 b8 70 b0 24 40 10 10
3e 00 2d bc 10 00 00 18 00 00 00 0f 00 00 00 00
00 00 00 00 00 00 0
In this patch, 3 new timings are added into support list.
If you want to have new timings, 1280x720 and 1280x960 on DisplayPort,
your dp-fw should be newer than version, 20240502.
Signed-off-by: Jammy Huang
---
v2:
- Fix build errors.
v3:
- Fix typo.
---
drivers/gpu/drm/ast/ast_dp.c | 9
Implement necessary glue code to let DRM bridge drivers to implement CEC
adapters support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_bridge_connector.c | 95 ++
include/drm/drm_bridge.h | 25 +++
2 files changed, 120 inserti
WHen adding HDMI fields I didn't notice the private: declaration for HPD
fields. Move private fields to the end of the struct drm_bride to have
clear distinction between private and public fields.
Signed-off-by: Dmitry Baryshkov
---
include/drm/drm_bridge.h | 31 ---
Allow HDMI DRM bridges to create CEC notifier. Physical address is
handled automatically by drm_atomic_helper_connector_hdmi_hotplug()
being called from .detect() path.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c| 2 +-
drivers/gpu/drm/display/Kconfig
CEC adapter functions are protected by drm_dev_enter() / _exit(), so it
is safe to keep CEC registered until DRM device is being torn down. Drop
custom CEC unsregistration code and rely on the DRM core to unregister
CEC adapter.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c
ay to implement CEC
handling for HDMI bridges in an easy yet standard way.
Dependencies:
-
https://lore.kernel.org/dri-devel/20241224-drm-bridge-hdmi-connector-v10-0-dc89577cd...@linaro.org/
Notes:
- the patchset was only compile-tested
- being an RFC some of the API functions and structures are
Switch VC4 driver to using CEC helpers code, simplifying hotplug and
registration / cleanup. The existing vc4_hdmi_cec_release() is kept for
now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 92 ---
Let drm_bridge drivers handle CEC adapters in a generic way. Add a set
of helper functions to be called by DRM bridge drivers to report CEC
message-related events.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_cec_helper.c | 37 +++
drivers/gpu/drm/
Call HDMI CEC helpers in order to update physical address of the
adapter.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
b/drivers/gpu/
Add generic CEC helpers to be used by HDMI drivers. Both notifier and
and adapter are supported for registration. Once registered, the driver
can call common set of functions to update physical address, to
invalidate it or to unregister CEC data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/d
As a preparation to adding HDMI CEC helper code, add CEC-related fields
to the struct drm_connector. Include both cec_adapter and cec_notifier,
allowing drivers to select which one to use. The unregister callback
is provided to let drivers unregister CEC-related data in a generic way
without pollut
On Mon, 04 Nov 2024 17:07:38 +0800, Sui Jingfeng wrote:
> Because the of_dma_configure() will returns '-EPROBE_DEFER' if the probe
> procedure of the specific platform IOMMU driver is not finished yet. It
> can also return other error code for various reasons.
>
> Stop pretending that it will al
On Mon, 16 Dec 2024 16:43:11 -0800, Jessica Zhang wrote:
> DPU supports a single writeback session running concurrently with primary
> display when the CWB mux is configured properly. This series enables
> clone mode for DPU driver and adds support for programming the CWB mux
> in cases where the
On Sat, 20 Apr 2024 05:33:00 +0300, Dmitry Baryshkov wrote:
> While testing MDP4 LVDS support I noticed several issues (two are
> related to probe deferral case and last one is a c&p error in LCDC
> part). Fix those issues.
>
>
Applied, thanks!
[1/3] drm/msm: don't clean up priv->kms prematur
On Mon, 16 Dec 2024 09:33:13 +0100, Arnd Bergmann wrote:
> Passing a variable string as a printf style format is potentially
> dangerous that -Wformat-security can warn about if enabled. A new
> instance just got added:
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c: In function 'dpu_kms_mdp_snapsh
On Mon, 16 Dec 2024 00:44:05 +0200, Dmitry Baryshkov wrote:
> - Fix register programming in the dp_audio module
> - Rework most of the register programming functions to be local to the
> calling module rather than accessing everything through huge
> dp_catalog monster.
>
>
Applied, thanks!
On Mon, 02 Dec 2024 19:31:38 -0800, Abhinav Kumar wrote:
> On some MSM chipsets, the display port controller is capable of supporting
> two streams. To drive the second stream, the pixel clock for the corresponding
> stream needs to be enabled. In order to add the bindings for the pixel clock
> f
On Fri, 20 Dec 2024 03:28:28 +0200, Dmitry Baryshkov wrote:
> After checking the DSPP units in the catalog vs the vendor devicetrees,
> link several DSPP units to the corresponding LM units. Each correction
> is submitted separately in order to be able to track and apply / skip
> them separately
On Tue, Dec 24, 2024 at 06:45:07AM +0200, Dmitry Baryshkov wrote:
> On Mon, Dec 16, 2024 at 04:43:17PM -0800, Jessica Zhang wrote:
> > From: Dmitry Baryshkov
> >
> > Up to now the driver has been using encoder to allocate hardware
> > resources. Switch it to use CRTC id in preparation for the nex
On 12/24/2024 10:13 AM, John Harrison wrote:
On 12/23/2024 15:20, Daniele Ceraolo Spurio wrote:
On 12/20/2024 5:19 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Add debug info to help investigate a very rare bug:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13385
S
On Tue, Dec 24, 2024 at 08:22:41PM +0200, Cristian Ciocaltea wrote:
> Bridges having DRM_BRIDGE_OP_HDMI set in their ->ops are supposed to
> rely on the ->supported_formats bitmask to advertise the permitted
> colorspaces, including HDMI_COLORSPACE_YUV420.
>
> However, a new flag ->ycbcr_420_allow
On Tue, Dec 24, 2024 at 08:22:42PM +0200, Cristian Ciocaltea wrote:
> The case of having an HDMI bridge in the pipeline which advertises
> YUV420 capability via its ->supported_formats and a non-HDMI one that
> didn't enable ->ycbcr_420_allowed, is incorrectly handled because
> supported_formats is
On Tue, Dec 24, 2024 at 08:22:44PM +0200, Cristian Ciocaltea wrote:
> Extend HDMI connector output format tests to verify its registration
> succeeds only when the presence of YUV420 in the supported formats
> matches the state of ycbcr_420_allowed flag.
>
> Signed-off-by: Cristian Ciocaltea
> --
gt; reflects the status of the computed connector->ycbcr_420_allowed, which
>> might end up being different than what the HDMI bridge advertised, i.e. the
>> case of having an HDMI bridge in the pipeline advertising YUV420 via
>> supported_formats and a non-HDMI one that didn't enable ycbcr_420_allowed.
>
> Please split it into two patches. I don't have a strong opinion upon the
> first one (I'd change it to dev_warn() maybe), while the second one
> (removing HDMI_COLORSPACE_YUV420 if connector->ycbcr_420_allowed is
> false) is definitely a correct change.
Split done in v4:
https://lore.kernel.org/lkml/20241224-bridge-conn-fmt-prio-v4-2-a9ceb5671...@collabora.com/
Thanks,
Cristian
OLORSPACE_YUV420)))
>> +return -EINVAL;
>> +
>> if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12))
>> return -EINVAL;
>
> The patch looks fine to me, but we need to have unit tests to cover this case.
Unit tests added in v4:
https://lore.kernel.org/lkml/20241224-bridge-conn-fmt-prio-v4-4-a9ceb5671...@collabora.com/
Thanks,
Cristian
Bridges having DRM_BRIDGE_OP_HDMI set in their ->ops are supposed to
rely on the ->supported_formats bitmask to advertise the permitted
colorspaces, including HDMI_COLORSPACE_YUV420.
However, a new flag ->ycbcr_420_allowed has been recently introduced,
which brings the necessity to require redunda
Bridges with DRM_BRIDGE_OP_HDMI set in drm_bridge->ops are expected to
rely on drm_bridge->supported_formats to advertise the supported
colorspaces, including HDMI_COLORSPACE_YUV420.
However, when drm_bridge_connector gets initialised, only
drm_bridge->ycbcr_420_allowed is considered in the proces
The case of having an HDMI bridge in the pipeline which advertises
YUV420 capability via its ->supported_formats and a non-HDMI one that
didn't enable ->ycbcr_420_allowed, is incorrectly handled because
supported_formats is passed as is to the helper initializing the HDMI
connector.
Ensure HDMI_CO
Ensure HDMI connector initialization fails when the presence of
HDMI_COLORSPACE_YUV420 in the given supported_formats bitmask doesn't
match the value of drm_connector->ycbcr_420_allowed.
Suggested-by: Dmitry Baryshkov
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Cristian Ciocaltea
---
drivers/
Extend HDMI connector output format tests to verify its registration
succeeds only when the presence of YUV420 in the supported formats
matches the state of ycbcr_420_allowed flag.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/tests/drm_connector_test.c | 60 +
On 12/23/2024 15:20, Daniele Ceraolo Spurio wrote:
On 12/20/2024 5:19 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Add debug info to help investigate a very rare bug:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13385
Signed-off-by: John Harrison
---
drivers/gpu/drm
On Wed, Oct 16, 2024 at 06:21:16PM -0700, Jessica Zhang wrote:
> The CWB mux has its own registers and set of operations. Add dpu_hw_cwb
> abstraction to allow driver to configure the CWB mux.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/Makefile
On Tue, 24 Dec 2024 21:05:10 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Remove is_cxl_nvdimm_bridge() which has no caller now.
>
> Signed-off-by: Zijun Hu
Reviewed-by: Jonathan Cameron
On Tue, 24 Dec 2024 21:05:09 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Static match_nvdimm_bridge(), as matching function of device_find_child()
> matches a device with device type @cxl_nvdimm_bridge_type, and its task
> can be simplified by the recently introduced API device_match_type().
>
On Tue, 24 Dec 2024 21:05:03 +0800
Zijun Hu wrote:
> From: Zijun Hu
>
> Constify the following API:
> struct device *device_find_child(struct device *dev, void *data,
> int (*match)(struct device *dev, void *data));
> To :
> struct device *device_find_child(struct device *dev, con
> Initialize the pointer with NULL as mtk_drm_of_get_ddp_ep_cid
> function might return before assigning value to next pointer
> but yet further dereference to next can lead to some undefined
> behavior as it may point to some invalid location.
* You may occasionally put more than 62 characters in
On 24/12/2024 10:23, Michal Wilczynski wrote:
>
>
> On 12/24/24 09:53, Krzysztof Kozlowski wrote:
>> On Mon, Dec 23, 2024 at 12:50:59PM -0800, Stephen Boyd wrote:
>>> Quoting Michal Wilczynski (2024-12-23 04:55:35)
The T-Head TH1520 SoC’s AP clock controller now needs two address ranges
On 24/12/2024 10:31, Michal Wilczynski wrote:
>
>
> On 12/23/24 17:09, Krzysztof Kozlowski wrote:
>> On 23/12/2024 13:55, Michal Wilczynski wrote:
>>> + compatible:
>>> +const: thead,th1520-pd
>>> +
>>> + "#power-domain-cells":
>>> +const: 1
>>> +
>>> +additionalProperties: false
>>> +
From: Zijun Hu
cable_match(), as matching function of device_find_child(), matches
a device with device type @typec_cable_dev_type, and its task can be
simplified by the recently introduced API device_match_type().
partner_match() is similar with cable_match() but with a different
device type @t
From: Zijun Hu
Static match_nvdimm_bridge(), as matching function of device_find_child()
matches a device with device type @cxl_nvdimm_bridge_type, and its task
can be simplified by the recently introduced API device_match_type().
Replace match_nvdimm_bridge() usage with device_match_type().
Re
From: Zijun Hu
Remove is_cxl_nvdimm_bridge() which has no caller now.
Signed-off-by: Zijun Hu
---
drivers/cxl/core/pmem.c | 6 --
drivers/cxl/cxl.h | 1 -
2 files changed, 7 deletions(-)
diff --git a/drivers/cxl/core/pmem.c b/drivers/cxl/core/pmem.c
index
0f8166e793e14fc0b1c04ffda7
From: Zijun Hu
Introduce device_match_type() for purposes below:
- Test if a device matches with a specified device type.
- As argument of various device finding APIs to find a device with
specified type.
device_find_child() will use it to simplify operations later.
Reviewed-by: Jonathan Cam
From: Zijun Hu
gpio_sim_dev_match_fwnode() is a simple wrapper of API
device_match_fwnode().
Remove the needless wrapper and use the API instead.
Acked-by: Bartosz Golaszewski
Reviewed-by: Jonathan Cameron
Signed-off-by: Zijun Hu
---
drivers/gpio/gpio-sim.c | 7 +--
1 file changed, 1 in
From: Zijun Hu
static of_slim_match_dev() has same function as API device_match_of_node().
Remove the former and use the later instead.
Reviewed-by: Jonathan Cameron
Signed-off-by: Zijun Hu
---
drivers/slimbus/core.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
From: Zijun Hu
Static match_any() is now exactly same as API device_match_any().
Remove the former and use the later instead.
Reviewed-by: Jonathan Cameron
Signed-off-by: Zijun Hu
---
drivers/base/core.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/base/co
From: Zijun Hu
Constify the following API:
struct device *device_find_child(struct device *dev, void *data,
int (*match)(struct device *dev, void *data));
To :
struct device *device_find_child(struct device *dev, const void *data,
device_match_t ma
From: Zijun Hu
Simplify device_find_child_by_name() implementation by both existing
API device_find_child() and device_match_name().
Reviewed-by: Jonathan Cameron
Signed-off-by: Zijun Hu
---
drivers/base/core.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/
From: Zijun Hu
bool slim_eaddr_equal(struct slim_eaddr *a, struct slim_eaddr *b)
does not modify @*a or @*b.
To prepare for constifying API device_find_child() later.
Constify this comparison function by simply changing its
parameter type to 'const struct slim_eaddr *'.
Reviewed-by: Jonathan C
From: Zijun Hu
fsl_mc_device_match() does not modify caller's inputs.
To prepare for constifying API device_find_child() later.
Constify this comparison function by simply changing its
parameter types to const pointer.
Reviewed-by: Jonathan Cameron
Signed-off-by: Zijun Hu
---
drivers/bus/fs
From: Zijun Hu
Simplify nd_namespace_store() implementation by
using device_find_child_by_name().
Reviewed-by: Alison Schofield
Reviewed-by: Jonathan Cameron
Signed-off-by: Zijun Hu
---
drivers/nvdimm/claim.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers
This patch series is to constify the following API:
struct device *device_find_child(struct device *dev, void *data,
int (*match)(struct device *dev, void *data));
To :
struct device *device_find_child(struct device *dev, const void *data,
device_mat
On 2024/12/24 04:48, Jonathan Cameron wrote:
>> From: Zijun Hu
>>
>> Static match_nvdimm_bridge(), as matching function of device_find_child()
>> matches a device with device type @cxl_nvdimm_bridge_type, and its task
>> can be simplified by the recently introduced API device_match_type().
>>
>> R
On 2024/12/24 04:39, Jonathan Cameron wrote:
> There is a subtle difference. In theory old code could dereference a NULL
> if parent->p == NULL, now it can't. Sounds at most like a harmless change but
> maybe you should mention it.
>
i did not correct parameter checking for device_find_child_by
On 2024/12/24 04:33, Jonathan Cameron wrote:
> On Wed, 11 Dec 2024 08:08:06 +0800
> Zijun Hu wrote:
>
>> From: Zijun Hu
>>
>> Constify the following API:
>> struct device *device_find_child(struct device *dev, void *data,
>> int (*match)(struct device *dev, void *data));
>> To :
>>
On 2024/12/24 04:26, Jonathan Cameron wrote:
> On Wed, 11 Dec 2024 08:08:05 +0800
> Zijun Hu wrote:
>
>> From: Zijun Hu
>>
>> fsl_mc_device_match() does not modify caller's inputs.
>>
>> Constify it by simply changing its parameter types to const pointer.
>>
>> Signed-off-by: Zijun Hu
> Similar
Jason-JH.Lin 於 2024年12月20日 週五 上午2:15寫道：
>
> From: Hsiao Chien Sung
>
> Modify rules for both MT8195 and MT8188.
> Hardware capabilities include color formats and AFBC are
> changed since MT8195, stop using the settings of MT8183.
Acked-by: Chun-Kuang Hu
>
> Acked-by: Rob Herring
> Reviewed-by
AngeloGioacchino Del Regno 於
2024年12月23日 週一 下午7:12寫道：
>
> Il 19/12/24 19:15, Jason-JH.Lin ha scritto:
> > Add compatible strings for the MDP3 OVL hardware components in
> > MediaTek's MT8188 SoC and it is compatible with the existing
> > MT8195 MDP OVL components.
> >
> > Signed-off-by: Jason-JH.L
Hi Jammy,
kernel test robot noticed the following build errors:
[auto build test ERROR on 4bbf9020becbfd8fc2c3da790855b7042fad455b]
url:
https://github.com/intel-lab-lkp/linux/commits/Jammy-Huang/drm-ast-Support-timings-1280x720-1280x960-1600x900/20241224-105552
base
On Tue, Dec 24, 2024 at 10:32:41AM +0100, Lukas Wunner wrote:
> On Tue, Dec 24, 2024 at 10:28:31AM +0100, Lukas Wunner wrote:
> > I did raise a concern about this to the maintainer, but to no avail:
> > https://lore.kernel.org/r/z1kym1-9ka8kg...@wunner.de/
>
> Sorry, wrong link. This is the one I
rk3562 has 1 ARM Mali-G52 GPU,.
Signed-off-by: Kever Yang
---
Changes in v2: None
Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
b/Documentation/devic
This patch set adds rk3562 SoC and its evb support.
Split out patches belong to different subsystem.
Test with GMAC, USB, PCIe, EMMC, SD Card.
This patch set is base on the patche set for rk3576 evb1 support.
Changes in v2:
- Update in sort order
- remove grf in cru
- Update some properties o
On Tue, Dec 24, 2024 at 10:28:31AM +0100, Lukas Wunner wrote:
> I did raise a concern about this to the maintainer, but to no avail:
> https://lore.kernel.org/r/z1kym1-9ka8kg...@wunner.de/
Sorry, wrong link. This is the one I meant to copy-paste... :(
https://lore.kernel.org/r/z0rpxcgdd7r8h...@w
On Thu, Dec 19, 2024 at 04:05:59PM +0800, Damon Ding wrote:
> According to Documentation/devicetree/bindings/display/dp-aux-bus.yaml,
> it is a good way to get panel through the DP AUX bus.
>
> Signed-off-by: Damon Ding
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml| 3 +
On Tue, Dec 24, 2024 at 12:05:19PM +0530, Sumit Garg wrote:
> Restricted memory is a feature enforced by hardware specific firewalls
> where a particular TEE implementation governs which particular block
> of memory is accessible to a particular peripheral or a CPU running in
> a higher privileged
On 12/23/24 17:09, Krzysztof Kozlowski wrote:
> On 23/12/2024 13:55, Michal Wilczynski wrote:
>> + compatible:
>> +const: thead,th1520-pd
>> +
>> + "#power-domain-cells":
>> +const: 1
>> +
>> +additionalProperties: false
>> +
>> +required:
>> + - compatible
>> + - "#power-domain-cell
On 12/24/24 09:53, Krzysztof Kozlowski wrote:
> On Mon, Dec 23, 2024 at 12:50:59PM -0800, Stephen Boyd wrote:
>> Quoting Michal Wilczynski (2024-12-23 04:55:35)
>>> The T-Head TH1520 SoC’s AP clock controller now needs two address ranges
>>> to manage both the Application Processor (AP) and Vide
On 23/12/2024 22:31, Akhil P Oommen wrote:
> On 12/23/2024 5:24 PM, Dmitry Baryshkov wrote:
>> On Mon, Dec 23, 2024 at 12:31:27PM +0100, Konrad Dybcio wrote:
>>> On 4.12.2024 7:18 PM, Akhil P Oommen wrote:
On 11/16/2024 1:17 AM, Dmitry Baryshkov wrote:
> On Fri, 15 Nov 2024 at 19:54, Akhil
Hi Jammy,
kernel test robot noticed the following build errors:
[auto build test ERROR on 4bbf9020becbfd8fc2c3da790855b7042fad455b]
url:
https://github.com/intel-lab-lkp/linux/commits/Jammy-Huang/drm-ast-Support-timings-1280x720-1280x960-1600x900/20241224-105552
base
On Mon, Dec 23, 2024 at 12:50:59PM -0800, Stephen Boyd wrote:
> Quoting Michal Wilczynski (2024-12-23 04:55:35)
> > The T-Head TH1520 SoC’s AP clock controller now needs two address ranges
> > to manage both the Application Processor (AP) and Video Output (VO)
> > subsystem clocks. Update the devic
Il 24/12/24 06:36, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Thu, 2024-12-19 at 12:27 +0100, AngeloGioacchino Del Regno wrote:
External email : Please do not click links or open attachments until you have
verified the sender or the content.
Registers DSI_VM_CMD and DSI_SHADOW_DEBUG start at dif
On 12/24/2024, Dmitry Baryshkov wrote:
> On Tue, 24 Dec 2024 at 08:21, Liu Ying wrote:
>>
>> On 12/23/2024, Dmitry Baryshkov wrote:
>>> On Mon, Dec 23, 2024 at 02:41:37PM +0800, Liu Ying wrote:
i.MX8qxp Display Controller display engine consists of all processing
units that operate in a
78 matches
Mail list logo
