I'm just looking over the userptr handling in both drivers, and of
course they've chosen different ways to represent things. Again this
is a divergence that is just going to get more annoying over time and
eventually I'd like to make hmm/userptr driver independent as much as
possible, so we get
On Tue, 2024-02-06 at 14:21 -0600, Lucas De Marchi wrote:
> On Tue, Feb 06, 2024 at 01:39:28PM +0100, Thomas Hellström wrote:
> > Hi
> >
> > On Tue, 2024-02-06 at 12:28 +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the drm-misc tree, today's linux-next build (x86_64
> >
Hi Neil,
On 05/02/24 4:41 pm, neil.armstr...@linaro.org wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the content is safe
>
> Hi,
>
> On 05/02/2024 12:06, Dharma Balasubiramani wrote:
>> Add a new LVDS controller driver for sam9x7 which does the following:
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ac139fc7db67968e5061715508b5fc4aa7c40c56 Add linux-next specific
files for 20240206
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402061900.rtuydlo6-...@intel.com
https
Hi all,
After merging the drm tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
nonexisting document 'gpu/rfc/xe'
Introduced by commit
d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
--
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+
Hi Rob
This is v2 of replace of_graph_get_next_endpoint()
We should get rid of or minimize of_graph_get_next_endpoint() in
its current form. In general, drivers should be asking for a specific
port number because their function is fixed in the binding.
Hi all,
On Tue, 6 Feb 2024 12:28:22 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
drivers/gpu/drm/xe/xe_bo.c:41:10: error: 'struct ttm_placement' has no member
named 'num_busy_placement'; did you mean
From: Hsiao Chien Sung
This series is based on mediatek-drm-next branch of
kernel/git/chunkuang.hu/linux.git.
Changes in v2:
- Refined the filtering formula
- Add the .mode_valid hook to the hardware that causes the limitation
Hsiao Chien Sung (1):
drm/mediatek: Filter modes according to
From: Hsiao Chien Sung
We found a stability issue on MT8188 when connecting an external monitor
in 2560x1440@144Hz mode. Checked with the designer, there is a function
called "prefetch" which is working during VBP (triggered by VSYNC).
If the duration of VBP is too short, the throughput
On 6/2/24 23:41, Mario Limonciello wrote:
> On 2/6/2024 08:21, Daniel Vetter wrote:
>> On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel van Vugt wrote:
>>> Until now, deferred console takeover only meant defer until there is
>>> output. But that risks stepping on the toes of userspace splash
Hi Laurent, Hans
> >> From DT point of view, in general, drivers should be asking for a
> >> specific port number because their function is fixed in the binding.
> >>
> >> of_graph_get_next_endpoint() doesn't match to this concept.
> >>
> >> Simply replace
> >>
> >>-
Two separate build warnings were reported. One from an
uninitialized variable, and the other from returning 0
instead of NULL from a pointer.
Fixes: 059c53e877ca ("drm/bridge: imx: add driver for HDMI TX Parallel Video
Interface")
Reported-by: nat...@kernel.org
Reported-by: kernel test robot
Hello,
syzbot found the following issue on:
HEAD commit:021533194476 Kconfig: Disable -Wstringop-overflow for GCC ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10a82db018
kernel config: https://syzkaller.appspot.com/x/.config?x=457249c250b93697
Hi Laurent
Thank you for the review
> > From DT point of view, in general, drivers should be asking for a
> > specific port number because their function is fixed in the binding.
> >
> > of_graph_get_next_endpoint() doesn't match to this concept.
> >
> > Simply replace
> >
> > -
Hi Laurent
Thank you for your review
> > diff --git a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
> > b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
> > index 686ca8753ba2..3f8bea2e3934 100644
> > --- a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
> > +++
On Tue, Jan 23, 2024 at 12:28:45PM +0200, Imre Deak wrote:
> Compute the BW required through a DP tunnel on links with such tunnels
> detected and add the corresponding atomic state during a modeset.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16
On Tue, Jan 23, 2024 at 12:28:42PM +0200, Imre Deak wrote:
> Add support to enable the DP tunnel BW allocation mode. Follow-up
> patches will call the required helpers added here to prepare for a
> modeset on a link with DP tunnels, the last change in the patchset
> actually enabling BWA.
>
>
On Tue, 6 Feb 2024 09:45:18 +0530 Anshuman Khandual
wrote:
> cma_get_name() just returns cma->name without any additional transformation
> unlike other helpers such as cma_get_base() and cma_get_size(). This helper
> is not worth the additional indirection, and can be dropped after replacing
>
We found a regression in v5.10 on real-time server, using the
rt-kernel and the mgag200 driver. It's some really specialized
workload, with <10us latency expectation on isolated core.
After the v5.10, the real time tasks missed their <10us latency
when something prints on the screen (fbcon or
Hi everyone! As I'm sure a number of you are aware, since Nvidia's release of
the GSP firmware a lot of things have changed for nouveau. In particular, the
interfaces which we use for controlling the hardware from nouveau have changed
pretty dramatically in many areas as a result of going through
So the issue is that SVGA_3D_CMD_DX_PRED_COPY_REGION between 2
surfaces that are the size of the mode fails. Technically for this to
work the filter will have to be 1/2 of graphics mem. I was just lucky
that the next mode in the list was already less than 1/2. 3/4 is not
actually going to work.
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 17/19] drm/i915/dp: Call intel_dp_sync_state() always for DDI
> DP encoders
>
> A
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 15/19] drm/i915/dp: Allocate/free DP tunnel BW in the encoder
> enable/disable hooks
>
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 14/19] drm/i915/dp: Compute DP tunel BW during encoder state
> computation
>
>
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 13/19] drm/i915/dp: Account for tunnel BW limit in
> intel_dp_max_link_data_rate()
>
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 09/19] drm/i915/dp: Add intel_dp_max_link_data_rate()
>
> Add
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 08/19] drm/i915/dp: Factor out intel_dp_read_dprx_caps()
>
> Factor out a function to
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 07/19] drm/i915/dp: Factor out intel_dp_update_sink_caps()
>
> Factor out a function
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 06/19] drm/i915/dp: Export
> intel_dp_max_common_rate/lane_count()
>
> Export
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 05/19] drm/i915/dp: Factor out intel_dp_config_required_rate()
>
> Factor out
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Tuesday, January 23, 2024 3:59 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH 04/19] drm/i915/dp: Use drm_dp_max_dprx_data_rate()
>
> Instead of
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Friday, January 26, 2024 6:58 PM
> To: Ville Syrjälä
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 01/19] drm/dp: Add drm_dp_max_dprx_data_rate()
>
> On Fri, Jan 26,
On Tue, Feb 06, 2024 at 01:39:28PM +0100, Thomas Hellström wrote:
Hi
On Tue, 2024-02-06 at 12:28 +1100, Stephen Rothwell wrote:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
a78a8da51b36 ("drm/ttm: replace busy
From: Markus Elfring
Date: Tue, 6 Feb 2024 20:43:10 +0100
A wrapper function is available since the commit
7945f929f1a77a1c8887a97ca07f87626858ff42
("drivers: provide devm_platform_ioremap_resource()").
* Thus reuse existing functionality instead of keeping duplicate source code.
* Delete a
vhost and VIRTIO-related parts:
Reviewed-by: Stefan Hajnoczi
On Wed, 22 Nov 2023 at 07:50, Christian Brauner wrote:
>
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
> function only ever passed 1 as a
On Fri, Feb 2, 2024 at 5:09 PM Mario Limonciello
wrote:
>
> On 2/2/2024 10:07, Rafael J. Wysocki wrote:
> > On Thu, Feb 1, 2024 at 11:11 PM Mario Limonciello
> > wrote:
> >>
> >> The ACPI specification allows for an EDID to be up to 512 bytes but
> >> the _DDC EDID fetching code will only try up
From: Markus Elfring
Date: Tue, 6 Feb 2024 20:22:56 +0100
A wrapper function is available since the commit
7945f929f1a77a1c8887a97ca07f87626858ff42
("drivers: provide devm_platform_ioremap_resource()").
* Thus reuse existing functionality instead of keeping duplicate source code.
* Delete a
On 21.01.2024 20:40, Adam Skladowski wrote:
> Add the nodes describing the apps and gpu iommu and its context banks
> that are found on msm8976 SoCs.
>
> Signed-off-by: Adam Skladowski
> ---
> arch/arm64/boot/dts/qcom/msm8976.dtsi | 80 +++
> 1 file changed, 80
From: Markus Elfring
Date: Tue, 6 Feb 2024 19:51:25 +0100
A wrapper function is available since the commit
7945f929f1a77a1c8887a97ca07f87626858ff42
("drivers: provide devm_platform_ioremap_resource()").
* Thus reuse existing functionality instead of keeping duplicate source code.
* Delete a
On Tue, Feb 06, 2024 at 12:50:16PM -0600, Adam Ford wrote:
> On Tue, Feb 6, 2024 at 11:06 AM Nathan Chancellor wrote:
> >
> > Hi all,
> >
> > On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> > > From: Lucas Stach
> > >
> > > This IP block is found in the HDMI subsystem of the i.MX8MP
On Tue, Feb 6, 2024 at 11:06 AM Nathan Chancellor wrote:
>
> Hi all,
>
> On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> > From: Lucas Stach
> >
> > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> > full timing generator and can switch between different
Am 06.02.24 um 15:29 schrieb Daniel Vetter:
On Fri, Feb 02, 2024 at 03:40:03PM -0800, Greg Kroah-Hartman wrote:
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote:
Removing an amdgpu device that still has user space references allocated
to it causes undefined behaviour.
Then fix
On 02/02/24 16:45, Pekka Paalanen wrote:
> On Fri, 2 Feb 2024 17:07:34 +0100
> Miquel Raynal wrote:
>
>> Hi Pekka,
>
> Hi Miquel,
>
> I'm happy to see no hard feelings below. I know I may be blunt at
> times.
>
> Another thing coming to my mind is that I suppose there is no
> agreed
Dne ponedeljek, 05. februar 2024 ob 21:34:04 CET je Frank Oltmanns napisal(a):
>
> On 2024-02-05 at 18:56:09 +0100, Jernej Škrabec
> wrote:
> > Dne ponedeljek, 05. februar 2024 ob 16:22:26 CET je Frank Oltmanns
> > napisal(a):
> >> According to the Allwinner User Manual, the Allwinner A64
Dne ponedeljek, 05. februar 2024 ob 16:22:25 CET je Frank Oltmanns napisal(a):
> The Allwinner A64 manual lists the following constraints for the
> PLL-MIPI clock:
> - M/N <= 3
> - (PLL_VIDEO0)/M >= 24MHz
>
> Use these constraints.
>
> Signed-off-by: Frank Oltmanns
Reviewed-by: Jernej
Dne ponedeljek, 05. februar 2024 ob 18:50:27 CET je Frank Oltmanns napisal(a):
> Hi Jernej,
>
> On 2024-02-05 at 18:45:27 +0100, Jernej Škrabec
> wrote:
> > Dne ponedeljek, 05. februar 2024 ob 16:22:24 CET je Frank Oltmanns
> > napisal(a):
> >> The Allwinner A64 manual lists the following
On 2/5/2024 1:26 AM, Raphael Gallais-Pou wrote:
Push horizontal front porch and vertical back porch blanking limit.
This allows to get a 60 fps sharp.
Signed-off-by: Raphael Gallais-Pou
Hi Raphael,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
On Sat, 3 Feb 2024 10:52:50 -0600
Adam Ford wrote:
> From: Lucas Stach
>
> Add a simple wrapper driver for the DWC HDMI bridge driver that
> implements the few bits that are necessary to abstract the i.MX8MP
> SoC integration.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Laurent Pinchart
On Sat, 3 Feb 2024 10:52:49 -0600
Adam Ford wrote:
> From: Lucas Stach
>
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Adam Ford
[...]
> +examples:
> + - |
>
Hi Adam,
On Sat, 3 Feb 2024 10:52:47 -0600
Adam Ford wrote:
> From: Lucas Stach
>
> Add binding for the i.MX8MP HDMI parallel video interface block.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Conor Dooley
> Signed-off-by: Adam Ford
Reviewed-by: Luca
On Sat, 3 Feb 2024 10:52:42 -0600
Adam Ford wrote:
> From: Lucas Stach
>
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Adam Ford
> Tested-by: Alexander Stein
[...]
> +#define PHY_REG_33 0x84
>
On Sat, 3 Feb 2024 10:52:41 -0600
Adam Ford wrote:
> From: Lucas Stach
>
> Add a DT binding for the HDMI PHY found on the i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Adam Ford
> Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Luca Ceresoli
--
Luca Ceresoli, Bootlin
Because we need this function to create virtial child.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 33 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 9
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git
The component helper functions are the glue, which is used to bind multiple
GPU cores to a virtual master platform device. Which is fine and works well
for the SoCs who contains multiple GPU cores.
The problem is that usperspace programs (such as X server and Mesa) will
search the PCIe device to
In the etnaviv_pdev_probe() and the etnaviv_gpu_platform_probe() function,
the value of '>dev' has been cached to a local auto variable (which
is named as 'dev'), but part of caller functions use 'dev' as argument,
but the rest use '>dev'. To keep it consistent, use 'dev' uniformly.
Both the instance of struct drm_device and the instance of struct
etnaviv_drm_private are intended to be shared by all GPU cores. They
both have only one instance across drm/etnaviv, therefore, embed struct
drm_device into struct etnaviv_drm_private, and use container_of() to
retrieve pointer for
In the etnaviv_gem_vmap_impl(), update the page property from writecombine
to PAGE_KERNEL on cached mapping. Previously, it use writecombine page
property to vmap cached buffer unconditionally. Many modern CPUs choose to
define the peripheral devices as DMA coherent by default, to be specific,
the
This patch adds PCI driver wrapper on the top of what drm/etnaviv already
have, with the expectation that to keep component framework untoughed and
to preserve code sharing.
drm/etnaviv use the component framework to bind multiple GPU cores to a
virtual master platform device, the virtual master
Because the current implementation is DT-based, this only works when the
host platform has the DT support. The problem is that some host platforms
does not provide DT-based clocks drivers, as a result, the driver rage
quit. For example, the X86-64 and LoongArch desktop platform.
Typically, PLL
There are a lot of data members in the struct etnaviv_drm_private, which
are intended to be shared by all GPU cores. Introduces two dedicated helper
functions for the purpose of construction and destruction.
After applied this patch, the error handling of the etnaviv_bind() gets
simplified a lot.
On 2/5/2024 1:06 AM, Raphael Gallais-Pou wrote:
DISPLAY_FLAGS_SYNC_POSEDGE is missing in the flags on the default
timings. When overriding the default mode with one described in the
device tree, the mode does not get acked because of this missing flag.
Moreover since the panel is driven by
Hi all,
On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> From: Lucas Stach
>
> This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> full timing generator and can switch between different video sources. On
> the i.MX8MP however the only supported source is the
Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.
Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop
CONFIG_DRM_AMD_DC_HDCP") there are two
Clean up a typo in pr_err() erroneously printing NI MC 'rdev->mc_fw->size'
during SMC firmware load. Log 'rdev->smc_fw->size' instead.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 6596afd48af4 ("drm/radeon/kms: add dpm support for btc (v3)")
Hi
Am 02.02.24 um 19:00 schrieb Sui Jingfeng:
Hi,
On 2024/2/2 19:58, Thomas Zimmermann wrote:
+static inline void __screen_info_set_lfb_base(struct screen_info
*si, u64 lfb_base)
+{
+ si->lfb_base = lfb_base & GENMASK_ULL(31, 0);
+ si->ext_lfb_base = (lfb_base & GENMASK_ULL(63, 32))
After falling through the switch statement to default case 'repr' is
initialized with NULL, which will lead to incorrect dereference of
'!repr[n]' in the following loop.
Fix it with the help of an additional check for NULL.
Found by Linux Verification Center (linuxtesting.org) with static
Hi Morimoto-san,
Thank you for the patch.
On Tue, Feb 06, 2024 at 02:55:45AM +, Kuninori Morimoto wrote:
> From DT point of view, in general, drivers should be asking for a
> specific port number because their function is fixed in the binding.
>
> of_graph_get_next_endpoint() doesn't match
Hi Morimoto-san,
Thank you for the patch.
On Tue, Feb 06, 2024 at 02:55:38AM +, Kuninori Morimoto wrote:
> From DT point of view, in general, drivers should be asking for a
> specific port number because their function is fixed in the binding.
>
> of_graph_get_next_endpoint() doesn't match
Il 06/02/24 15:47, Alexandre Mergnat ha scritto:
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Change magic numerical masks with usage of the GENMASK() macro
to improve readability.
While at it, also fix the DSI_PS_SEL mask to include all bits instead
of just a subset of them.
This
On Tue, Feb 06, 2024 at 02:57:08PM +0800, Shengyang Chen wrote:
> From: Keith Zhao
>
> Add compatible to support dsi bridge on StarFive JH7110 SoC
>
> Signed-off-by: Keith Zhao
> Signed-off-by: Shengyang Chen
Reviewed-by: Conor Dooley
Cheers,
Conor.
signature.asc
Description: PGP
On 2/6/2024 08:21, Daniel Vetter wrote:
On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel van Vugt wrote:
Until now, deferred console takeover only meant defer until there is
output. But that risks stepping on the toes of userspace splash screens,
as console messages may appear before the splash
Il 05/02/24 06:50, mac.shen ha scritto:
Add HDCP2.x feature for DisplayPort.
When userspace request the kernel protect future content communicated
over the link with Content_Protection property, the feature will do
HDCP2.x authentication if the sink support HDCP2.X.
Changes in v2:
- remove
Il 05/02/24 06:50, mac.shen ha scritto:
Add tee client application which will be used for
HDCP 1.x and 2.x authentication in DisplayPort.
Changes in v2:
- remove ca folder, and change file name with lower case
- refine the tci_t structure to make the data to tee can
through this structure
-
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Instead of open coding, use the mipi_dsi_pixel_format_to_bpp() helper
function from drm_mipi_dsi.h in mtk_dsi_poweron() and for validation
in mtk_dsi_bridge_mode_valid().
Note that this function changes the
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
All entries fit in 82 columns, which is acceptable: compress all of
the mtk_dsi_of_match[] entries to a single line for each.
While at it, also add the usual sentinel comment to the last entry.
--
Regards,
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Most of the functions that are called in the probe callback are
devm managed, or all but mipi_dsi_host_register(): simplify the probe
function's error paths with dev_err_probe() and remove the lonely
instance
Issue IP reset before shutdown in order to
complete all upstream requests to the SOC.
Without this DevTLB is complaining about
incomplete transactions and NPU cannot resume from
suspend.
This problem is only happening on recent IFWI
releases.
IP reset in rare corner cases can mess up PCI
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Registering the dsi host with its ops before getting dsi->regs is
simply wrong: even though there's nothing (for now) asynchronously
calling those ops before the end of the probe function, installing
ops that are using iospace(s) and
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
In mtk_dsi_phy_timconfig(), we're dividing the `data_rate` variable,
expressed in Hz to retrieve a value in MHz: instead of open-coding,
use the HZ_PER_MHZ definition, available in linux/units.h.
--
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Instead of open coding bitshifting for various register fields,
use the bitfield macro FIELD_PREP(): this allows to enhance the
human readability, decrease likeliness of mistakes (and register
field
On Sun, Feb 04, 2024 at 10:24:46AM +0100, Dmitry Baryshkov wrote:
> On Sat, 3 Feb 2024 at 22:20, Ricardo B. Marliere wrote:
> >
> > Now that the driver core can properly handle constant struct bus_type,
> > move the dp_aux_bus_type variable to be a constant structure as well,
> > placing it into
On Wed, 31 Jan 2024 at 02:31, Zack Rusin wrote:
> On Tue, Jan 30, 2024 at 6:50 PM Daniel Stone wrote:
> > The entire model we have is that basis timing flows backwards. The
> > 'hardware' gives us a deadline, KMS angles to meet that with a small
> > margin, the compositor angles to meet that
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Function mtk_dsi_ps_control() is a subset of mtk_dsi_ps_control_vact():
merge the two in one mtk_dsi_ps_control() function by adding one
function parameter `config_vact` which, when true, writes the VACT
On 2/6/24 14:41, Laurent Pinchart wrote:
> Hi Morimoto-san,
>
> (Adding Krzysztof Hałasa)
>
> Thank you for the patch.
>
> On Tue, Feb 06, 2024 at 02:55:27AM +, Kuninori Morimoto wrote:
>> From DT point of view, in general, drivers should be asking for a
>> specific port number because
On Tue, Feb 06, 2024 at 12:33:16PM +0100, Raphael Gallais-Pou wrote:
> Add "st,stm32mp25-lvds" compatible.
>
> Signed-off-by: Raphael Gallais-Pou
Reviewed-by: Conor Dooley
Thanks,
Conor.
signature.asc
Description: PGP signature
Reviewed-by: Alexandre Mergnat
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
The register bits definitions for RGB666 formats are wrong in multiple
ways: first, in the DSI_PS_SEL bits region, the Packed 18-bits RGB666
format is selected with bit 1, while the Loosely Packed one is bit
On 06/02/2024 13:07, AngeloGioacchino Del Regno wrote:
Change magic numerical masks with usage of the GENMASK() macro
to improve readability.
While at it, also fix the DSI_PS_SEL mask to include all bits instead
of just a subset of them.
This commit brings no functional changes.
Applied. Thanks!
On Mon, Feb 5, 2024 at 5:08 PM Nathan Chancellor wrote:
>
> After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y
> and CONFIG_WERROR=y enabled) has a few new instances of
> -Wframe-larger-than for the mode support and system configuration
> functions:
>
>
>
On Fri, Feb 02, 2024 at 03:40:03PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote:
> > Removing an amdgpu device that still has user space references allocated
> > to it causes undefined behaviour.
>
> Then fix that please. There should not be
On Tue, Feb 06, 2024 at 06:10:51PM +0800, Daniel van Vugt wrote:
> Until now, deferred console takeover only meant defer until there is
> output. But that risks stepping on the toes of userspace splash screens,
> as console messages may appear before the splash screen. So check the
> command line
On Thu, Feb 01, 2024 at 10:42:56PM -0800, Shradha Gupta wrote:
> This patchset consists of sanity checks before enabling/disabling
> output polling to make sure we do not call polling enable and disable
> functions when polling for the device is not initialized or is now
> uninitialized(by
On Tue, Feb 06, 2024 at 02:28:35PM +0100, Christian König wrote:
> Am 31.01.24 um 10:07 schrieb Daniel Vetter:
> > On Tue, Jan 30, 2024 at 02:09:45PM +0100, Christian König wrote:
> > > Am 30.01.24 um 11:40 schrieb Daniel Vetter:
> > > > On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil
On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote:
> On 2/5/24 22:08, Dave Airlie wrote:
> > On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote:
> > >
> > > On 1/29/24 02:50, Dave Airlie wrote:
> > > > From: Dave Airlie
> > > >
> > > > This should break the deadlock between the
On Mon, Feb 05, 2024 at 05:02:58PM +1000, Dave Airlie wrote:
> On Mon, 6 Nov 2023 at 20:47, Jocelyn Falempe wrote:
> >
> > On 23/10/2023 10:30, Jocelyn Falempe wrote:
> > > On 20/10/2023 14:06, Thomas Zimmermann wrote:
> > >> (cc'ing lkml for feedback)
> > >>
> > >> Hi Jocelyn
> > >>
> > >> Am
On Fri, Jan 26, 2024 at 09:57:26AM +0100, Yannic Moog wrote:
> Enable the i.MX8MP LDB driver used for display support of the i.MX8MP
> LVDS interface.
>
> Signed-off-by: Yannic Moog
Applied, thanks!
1 - 100 of 164 matches
Mail list logo
