: cf87f46fd34d6c19283d9625a7822f20d90b64a4
patch link:
https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v3-2-0a728ad45010%40gmail.com
patch subject: [PATCH v3 2/2] drm/msm/a6xx: request memory region
config: i386-buildonly-randconfig-003-20240513
(https://download.01.org/0day-ci/archive/20240513
The Performance Counters enum used to identify the index of each
performance counter and provide the total number of performance
counters (V3D_PERFCNT_NUM). But, this enum is only valid for V3D 4.2,
not for V3D 7.1.
As we implemented a new flexible structure to retrieve performance
counters
V3D_PERFCNT_NUM represents the maximum number of performance counters
for V3D 4.2, but not for V3D 7.1. This means that, if we use
V3D_PERFCNT_NUM, we might go out-of-bounds on V3D 7.1.
Therefore, use the number of performance counters on V3D 7.1 as the
maximum number of counters. This will allow
Userspace usually needs some information about the performance counters
available. Although we could replicate this information in the kernel
and user-space, let's use the kernel as the "single source of truth" to
avoid issues in the future (e.g. list of performance counters is updated
in
The maximum number of performance counters can change from version to
version and it's important for userspace to know this value, as it needs
to use the counters for performance queries. Therefore, expose the
maximum number of performance counters to userspace as a parameter.
Signed-off-by:
Currently, even though V3D 7.1 has 93 performance counters, it is not
possible to create counters bigger than 87, as
`v3d_perfmon_create_ioctl()` understands that counters bigger than 87
are invalid.
Therefore, create a device variable to expose the maximum
number of counters for a given V3D
This series has the intention to address two issues with Performance Counters
on V3D:
1. Update the number of Performance Counters for V3D 7.1
V3D 7.1 has 93 performance counters, while V3D 4.2 has only 87. Although the
series [1] enabled support for V3D 7.1, it didn’t replace the
Add name, category and description for each one of the 93 performance
counters available on V3D.
Note that V3D 4.2 has 87 performance counters, while V3D 7.1 has 93.
Therefore, there are two performance counters arrays. The index of the
performance counter for each V3D version is represented by
: cf87f46fd34d6c19283d9625a7822f20d90b64a4
patch link:
https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v3-2-0a728ad45010%40gmail.com
patch subject: [PATCH v3 2/2] drm/msm/a6xx: request memory region
config: i386-buildonly-randconfig-001-20240513
(https://download.01.org/0day-ci/archive/20240513/202405130618
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:30:27PM +0800, Sui Jingfeng wrote:
> In the cdns_mhdp_connector_init() function, the check on the existence
> of bridge->encoder is not necessary, as it has already been done in the
> drm_bridge_attach() function. A
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:38:20PM +0800, Sui Jingfeng wrote:
> In the ge_b850v3_lvds_create_connector function, the check on the existence
> of bridge->encoder is not necessary, as it has already been done in the
> drm_bridge_attach() function. A
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:47:13PM +0800, Sui Jingfeng wrote:
> In the dw_mipi_dsi_bridge_attach() function, the check on the existence
> of bridge->encoder is not necessary, as it has already been done in the
> drm_bridge_attach() function. A
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:55:49PM +0800, Sui Jingfeng wrote:
> In the lt9611uxc_connector_init() function, the check on the existence
> of bridge->encoder is not necessary, as it has already been done in the
> drm_bridge_attach() function. A
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:23:08PM +0800, Sui Jingfeng wrote:
> In the adv7511_connector_init() function, the check on the existence
> of bridge->encoder is not necessary, as it has already been done in the
> drm_bridge_attach() function. And the chec
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 11:08:16PM +0800, Sui Jingfeng wrote:
> The check on the existence of bridge->encoder on the implementation layer
> of drm bridge driver is not necessary, as it has already been done in the
> drm_bridge_attach() function. It i
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 11:22:22PM +0800, Sui Jingfeng wrote:
> The check on the existence of bridge->encoder on the implementation layer
> of drm bridge driver is not necessary, as it has already been done in the
> drm_bridge_attach() function. It i
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:10:56PM +0800, Sui Jingfeng wrote:
> In it6505_bridge_attach(), the check on the existence of bridge->encoder
> has already been done in the implementation of drm_bridge_attach(). And
> it is done before the bridge-&g
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 10:03:16PM +0800, Sui Jingfeng wrote:
> In panel_bridge_attach(), the check on the existence of bridge->encoder
> has already been done in the implementation of drm_bridge_attach(). And
> it is done before the bridge->fun
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 09:42:50PM +0800, Sui Jingfeng wrote:
> In ptn3460_bridge_attach(), the check on the existence of bridge->encoder
> has already been done in the implementation of drm_bridge_attach(). The
> driver won't go further if bri
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 09:24:23PM +0800, Sui Jingfeng wrote:
> In the tfp410_attach(), the check on the existence of bridge->encoder has
> already been done in the implementation of drm_bridge_attach() function.
> The driver won't go further if bri
Hi Sui,
Thank you for the patch.
On Sat, May 11, 2024 at 08:42:38PM +0800, Sui Jingfeng wrote:
> Because the check on the non-existence (encoder == NULL) has already been
> done in the implementation of drm_bridge_attach() function, and
> drm_bridge_attach() is called earlier. The dri
Hi Aradhya,
Thank you for the patch.
On Sun, May 12, 2024 at 01:00:53AM +0530, Aradhya Bhatia wrote:
> Add devicetree binding schema for AM625 OLDI Transmitters.
>
> Signed-off-by: Aradhya Bhatia
> ---
> .../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
Hi Aradhya,
Thank you for the patch.
On Sun, May 12, 2024 at 01:00:52AM +0530, Aradhya Bhatia wrote:
> Reduce tab size from 8 spaces to 4 spaces to make the bindings
> consistent, and easy to expand.
>
> Signed-off-by: Aradhya Bhatia
Reviewed-by: Laurent Pinchart
> ---
Hello Aradhya,
On Sun, May 12, 2024 at 08:53:12PM +0530, Aradhya Bhatia wrote:
> On 12/05/24 17:18, Francesco Dolcini wrote:
> > On Sun, May 12, 2024 at 01:00:55AM +0530, Aradhya Bhatia wrote:
> >> Up till now, the OLDI support in tidss was integrated within the tidss
> >> dispc.
> >> This was
@intel.com; Leon Weiß ; sta...@vger.kernel.org; dri-devel@lists.freedesktop.org; amd-
g...@lists.freedesktop.org; intel-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/mst: Fix NULL pointer dereference at
drm_dp_add_payload_part2
On 5/9/2024 07:43, Linux regression tracking (Thorsten Leemh
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.
To allow more efficient access to the GuC log, which could benefit
our CI systems, expose raw binary
It is preferable to use the xe_map layer instead of directly
accessing iosys_map, so add a wrapper for the recently added
iosys_map_read_from() function.
Signed-off-by: Michal Wajdeczko
Cc: Lucas De Marchi
---
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
It allows to copy data from iosys_map into the user memory,
regardless whether iosys_map points to memory or I/O memory.
Signed-off-by: Michal Wajdeczko
---
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Lucas De Marchi
---
include/linux/iosys-map.h | 24
It's similar to simple_read_from_buffer() but instead allows to
copy data from the I/O memory in PAGE_SIZE chunks.
Signed-off-by: Michal Wajdeczko
---
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Lucas De Marchi
---
fs/libfs.c | 50
We already provide the content of the GuC log in debugsfs, but it
is in a text format where each log dword is printed as hexadecimal
number, which does not scale well with large GuC log buffers.
Cc: linux-fsde...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Michal Wajdeczko (4):
libfs:
From: Noralf Trønnes
This prepares for supporting other pixel formats than RGB565.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_mipi_dbi.c | 14 ++
include/drm/drm_mipi_dbi.h | 5 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the
From: Noralf Trønnes
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is
From: Noralf Trønnes
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some
From: Noralf Trønnes
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I have
Hi Francesco,
On 12/05/24 17:18, Francesco Dolcini wrote:
> Hello Aradhya, thanks for you patch, I should be able to test your patch on my
> hardware in the coming days.
That's appreciated. Thank you! =)
>
> On Sun, May 12, 2024 at 01:00:55AM +0530, Aradhya Bhatia wrote:
&g
Hello Aradhya, thanks for you patch, I should be able to test your patch on my
hardware in the coming days.
On Sun, May 12, 2024 at 01:00:55AM +0530, Aradhya Bhatia wrote:
> Up till now, the OLDI support in tidss was integrated within the tidss dispc.
> This was fine till the OLDI w
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Kiarash Hajian
---
Changes in v4:
-
4.205720] rockchip-drm display-subsystem:
[drm:drm_atomic_helper_connector_hdmi_check] RGB output format not supported
with 8 bpc
[4.205747] rockchip-drm display-subsystem:
[drm:drm_atomic_helper_connector_hdmi_check] Failed. No Format Supported for
that bpc count.
[4.205772] rockchip-dr
Hi Maxime,
At 2024-05-07 21:17:45, "Maxime Ripard" wrote:
>The new HDMI connector infrastructure allows to remove some boilerplate,
>especially to generate infoframes. Let's switch to it.
>
>Reviewed-by: Heiko Stuebner
>Acked-by: Heiko Stuebner
>Signed-off-by: Maxime Ripard
>---
>
Hi Daniel,
On 5/8/2024 2:11 PM, Daniel Vetter wrote:
On Wed, May 08, 2024 at 12:27:20PM +0530, Arunpravin Paneer Selvam wrote:
Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback
Problem statement: During the system boot time, an application request
for the bulk volume of cleared range bias memory when the clear_avail
is zero, we dont fallback into normal allocation method as we had an
unnecessary clear_avail check which prevents the fallback method leads
to fb allocation
Allocate cleared blocks in the bias range when the DRM
buddy's clear avail is zero. This will validate the bias
range allocation in scenarios like system boot when no
cleared blocks are available and exercise the fallback
path too. The resulting blocks should always be dirty.
Signed-off-by:
>
> Signed-off-by: Kiarash Hajian
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 --
> 1 file changed, 18 deletions(-)
In my opinion, this patch is better be squashed into the first patch.
Though I'd leave a final word here to Rob and Konrad.
BTW: for some re
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Kiarash Hajian
---
The devm_iounmap function is being used unnecessarily,
managed resource mechanisms (devres) are handling resource cleanup automatically
This commit removes the calls to devm_iounmap and relies on devres
Signed-off-by: Kiarash Hajian
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18
Signed-off-by: Kiarash Hajian
---
Changes in v3:
- Remove redundant devm_iounmap calls, relying on devres for automatic resource
cleanup.
Changes in v2:
- update the subject prefix to "drm/msm/a6xx:", to match the majority of other
changes to this file.
---
Kiarash Hajian (2):
I think
roundup(x, 1 << n)
is more readable.
On 5/11/2024 3:32 PM, Dmitry Baryshkov wrote:
The drm/msm driver had adopted using Python3 script to generate register
header files instead of shipping pre-generated header files. Document
the minimal Python version supported by the script. Per request by Jon
Hunter, the script is required to
Use newer mipi_dsi_*_multi() functions in order to simplify and cleanup
panel's prepare() and unprepare() functions.
Reviewed-by: Douglas Anderson
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 95 +---
1 file changed, 37
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code.
Reviewed-by: Douglas Anderson
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 48 ++-
1 file changed, 11 insertions(+), 37
Remove conditional code and use mipi_dsi_dcs_nop_multi() wrapper to
simplify driver code.
Reviewed-by: Douglas Anderson
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code.
Reviewed-by: Douglas Anderson
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 81 ++
1 file changed, 19 insertions(+), 62
Follow the pattern of mipi_dsi_dcs_*_multi() and wrap several existing
MIPI DSI functions to use the context for processing. This simplifies
and streamlines driver code to use simpler code pattern.
Note, msleep function is also wrapped in this way as it is frequently
called inbetween other
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to
simplify driver's init/exit code. This also includes passing context to
the init_sequence() function instead of passing the DSI device.
Reviewed-by: Douglas Anderson
Signed-off-by: Dmitry Baryshkov
---
Follow the example of mipi_dsi_generic_write_multi(),
mipi_dsi_dcs_write_buffer_multi(), mipi_dsi_generic_write_seq_multi()
and mipi_dsi_dcs_write_seq_multi(). Define _multi variants for several
other common MIPI DSI functions and use these functions in the panel
code.
This series also includes a
Add missing error handling for the mipi_dsi_ functions that actually
return error code instead of silently ignoring it.
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Reviewed-by: Douglas Anderson
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c |
The drm/msm driver had adopted using Python3 script to generate register
header files instead of shipping pre-generated header files. Document
the minimal Python version supported by the script. Per request by Jon
Hunter, the script is required to be compatible with Python 3.5.
Python is
g managed
> devres-function.
>
> Signed-off-by: Kiarash Hajian
> ---
> Changes in v2:
> - update the subject prefix to "drm/msm/a6xx:", to match the majority of
> other changes to this file.
Same comment as I posted for v1 of the patch.
> ---
> drivers/gp
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Kiarash Hajian
---
Changes in v2:
-
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Kiarash Hajian
---
On Sat, 11 May 2024 at 22:35, Kiarash Hajian
wrote:
>
> The driver's memory regions are currently just ioremap()ed, but not
> reserved through a request. That's not a bug, but having the request is
> a little more robust.
>
> Implement the region-request through the corresponding managed
>
Reduce tab size from 8 spaces to 4 spaces to make the bindings
consistent, and easy to expand.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am65x-dss.yaml | 54 +--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git
support the new LVDS
configurations.
Signed-off-by: Aradhya Bhatia
---
Note:
The OLDI configuration should happen before the video-port configuration takes
place in tidss_crtc_atomic_enable hook. I have posted a patch allowing DRM
bridges to get enabled before the CRTC of that bridge is enabled
Hello all,
This patch series add support for the dual OLDI TXes supported in Texas
Instruments' AM62x and AM62Px family of SoCs. The OLDI TXes support single-lvds,
lvds-clone, and dual-lvds modes. These have now been represented through DRM
bridges within TI-DSS.
The OLDI configuration should
The DSS in AM625 SoC has 2 OLDI TXes. Refer the OLDI schema to add the
properties.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am65x-dss.yaml | 136 +-
1 file changed, 135 insertions(+), 1 deletion(-)
diff --git
Add devicetree binding schema for AM625 OLDI Transmitters.
Signed-off-by: Aradhya Bhatia
---
.../bindings/display/ti/ti,am625-oldi.yaml| 153 ++
MAINTAINERS | 1 +
2 files changed, 154 insertions(+)
create mode 100644
Replace "slab_priorities" with "slab_dependencies" in the error handler to
avoid memory leak.
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jiasheng Jiang
Replace "slab_priorities" with "slab_dependencies" in the error handler
to avoid memory leak.
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
1 file changed, 1
From: Christian Brauner
> Sent: 10 May 2024 11:55
>
> > For the uapi issue you describe below my take would be that we should just
> > try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe
> > I'm biased from the gpu world, where we've been hammering it in that
> > "O_CLOEXEC or
Convert 19.13 fixed point to integer */
>> in_pos_rounded = in_pos_aligned / 8192U;
>
> Oh, these seems to be better to use either ALIGN*(), or PFN_*() / PAGE_*()
> families of macros. What the semantic of 8192 is?
>
As Laurent mentioned, it looks like the fract
Hi Jani,
Thanks for the quick review.
On 10/05/24 20:45, Jani Nikula wrote:
[...]
> Moreover, I think the naming of round_up() and round_down() should have
> reflected the fact that they operate on powers of 2. It's unfortunate
> that the difference to roundup() and rounddown() is just the
ined.
>
Sorry I did not understand this comment, if you are talking about
existing macros round_up & round_down they either round "up" and round
"down" to specified power of 2 as specified here [1].
whereas the macros introduced in this patch round to "nearest&
Hi Andy,
Thanks for the quick review.
On 10/05/24 20:40, Andy Shevchenko wrote:
> On Fri, May 10, 2024 at 12:10:01AM +0530, Devarsh Thakkar wrote:
>> If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
>> (V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
>>
The cdsn-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming.
Since tidss's videoport starts streaming via crtc enable hooks, we need
cdns-dsi to be up and running before that. Hence, use the early_enable
and late_disable hooks to get pass the
Allow the DCS Write FIFO in the cdns-dsi controller to reset before any
DCS packet is transmitted to the DSI sink device.
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Change the existing (and deparacated) 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.
Signed-off-by: Aradhya Bhatia
---
Add support for mode_fixup for the tidss CRTC.
Some bridges like the cdns-dsi consume the crtc_* timing parameters for
programming the blanking values. Allow for the normal timing parameters
to get copied to crtc_* timing params.
Signed-off-by: Aradhya Bhatia
---
Update the Phy initialized state to "not initialized" when the driver
(and the hardware by extension) gets suspended. This will allow the Phy
to get initialized again after resume.
Fix the OF node that gets passed to find the next available bridge in
the display pipeline.
Fix the order of DSI
With the existing pre_enable and enable function hooks, the order of
enable of display elements looks as follows,
crtc_enable -> bridge[n]_pre_enable -> ... -> bridge[1]_pre_enable ->
encoder_enable -> bridge[1]_enable -> ... -> bridge[n]_enable
and vice versa for the disable.
Some bridges need
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 AM62P.
The cdns-dsi bridge consumes the crtc_* timing parameters for programming the
timing parameters. A patch
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
houses this DSI TX
Maybe the format is incorrect. I would like to use
"jiashengjiangc...@outlook.com" to resend my patch.
-Jiasheng
From: Jiasheng Jiang
Sent: Saturday, May 11, 2024 3:40
To: jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
The check on the existence of bridge->encoder on the implementation layer
of drm bridge driver is not necessary, as it has already been done in the
drm_bridge_attach() function. It is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when various an_bridge_attach()
The check on the existence of bridge->encoder on the implementation layer
of drm bridge driver is not necessary, as it has already been done in the
drm_bridge_attach() function. It is guaranteed that the .encoder member
of the drm_bridge instance is not NULL when various imx_xxx_bridge_attach()
> +static inline
> +unsigned long vmware_hypercall3(unsigned long cmd, unsigned long in1,
> + uint32_t *out1, uint32_t *out2)
nit: u32 is preferred over uint32_t.
Likewise elsewhere in this patch-set.
...
> /*
> - * The high bandwidth in call. The low word of edx is presume
In the lt9611uxc_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been done in the
drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder
In the dw_mipi_dsi_bridge_attach() function, the check on the existence
of bridge->encoder is not necessary, as it has already been done in the
drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder
In the ge_b850v3_lvds_create_connector function, the check on the existence
of bridge->encoder is not necessary, as it has already been done in the
drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the
In the cdns_mhdp_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been done in the
drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder
In the adv7511_connector_init() function, the check on the existence
of bridge->encoder is not necessary, as it has already been done in the
drm_bridge_attach() function. And the check on the drm bridge core
happens before check in the implementation. Hence, it is guaranteed that
the .encoder
In it6505_bridge_attach(), the check on the existence of bridge->encoder
has already been done in the implementation of drm_bridge_attach(). And
it is done before the bridge->funcs->attach function hook is called. Hence,
it is guaranteed that the .encoder member of the struct drm_bridge is not
In panel_bridge_attach(), the check on the existence of bridge->encoder
has already been done in the implementation of drm_bridge_attach(). And
it is done before the bridge->funcs->attach hook is called. Hence, it is
guaranteed that the .encoder member of the struct drm_bridge is not NULL
when the
In ptn3460_bridge_attach(), the check on the existence of bridge->encoder
has already been done in the implementation of drm_bridge_attach(). The
driver won't go further if bridge->encoder is NULL and the driver will quit
even if drm_bridge_attach() fails for some reasons. Thereforei, there is
no
In the tfp410_attach(), the check on the existence of bridge->encoder has
already been done in the implementation of drm_bridge_attach() function.
The driver won't go further if bridge->encoder is NULL and the driver will
quit even if drm_bridge_attach() fails for some reasons.
Therefore there is
On Thu, May 09, 2024 at 11:42:51AM +0200, Krzysztof Kozlowski wrote:
> Samsung AMS495QA01 panel is a SPI device, so it should reference
> spi-peripheral-props.yaml schema to allow and validate the SPI device
> properties.
>
> Fixes: 92be07c65b22 ("dt-bindings: display: panel: Add Samsung
On Thu, May 09, 2024 at 11:42:52AM +0200, Krzysztof Kozlowski wrote:
> SPI-attached devices could have more than one chip-select, thus their
> bindings are supposed to constrain the 'reg' property to match hardware.
> Add missing 'reg' constrain for SPI-attached display panels.
>
> Signed-off-by:
On Thu, May 09, 2024 at 11:42:53AM +0200, Krzysztof Kozlowski wrote:
> DSI-attached devices could respond to more than one virtual channel
> number, thus their bindings are supposed to constrain the 'reg' property
> to match hardware. Add missing 'reg' constrain for DSI-attached display
> panels,
Because the check on the non-existence (encoder == NULL) has already been
done in the implementation of drm_bridge_attach() function, and
drm_bridge_attach() is called earlier. The driver won't get to check point
even if drm_bridge_attach() fails for some reasons, as it will clear the
Baryshkov
Thanks for fixing this.
This one should also be backported (e.g. as the patch that can trigger
this probably also should be backported to 6.8 [1]):
Cc: sta...@vger.kernel.org # 6.8
Reviewed-by: Johan Hovold
Johan
[1]
https://lore.kernel.org/r/20240424-qc-pmic-typec-hpd-split-v4-1-f7e10d147...@linaro.org
701 - 800 of 352880 matches
Mail list logo
