From: Dave Airlie
I'm pretty sure this optimisation is actually not a great idea,
and is racy with other things waiting for fences.
Just nuke it, there should be no need to do fence waits in a
busy CPU loop.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released
Use 'supported' instead of 'support'. 'support' makes no sense in this
context.
Signed-off-by: Baruch Siach
---
v2: Add commit log message (Christian König)
---
Documentation/driver-api/dma-buf.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Add the newly added LVDS controller for the SAM9X7 SoC to the existing
MAINTAINERS entry.
Signed-off-by: Dharma Balasubiramani
Reviewed-by: Neil Armstrong
Acked-by: Nicolas Ferre
---
Changelog
v5 -> v6
- Correct the file name sam9x7-lvds.yaml -> sam9x75-lvds.yaml.
v4 -> v5
v3 -> v4
- No
Enable LVDS serializer support for display pipeline.
Signed-off-by: Dharma Balasubiramani
Acked-by: Hari Prasath Gujulan Elango
Acked-by: Nicolas Ferre
---
Changelog
v4 -> v5
v3 -> v4
v2 -> v3
- No Changes.
---
arch/arm/configs/at91_dt_defconfig | 1 +
1 file changed, 1 insertion(+)
diff
This patch series introduces LVDS controller support for the SAM9X75 SoC. The
LVDS controller is designed to work with Microchip's sam9x7 series
System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling
capabilities.
Patch series Changelog:
- Include configs: at91: Enable LVDS
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
Differential Signaling (LVDS) Controller found on some Microchip's sam9x7
series System-on-Chip (SoC) devices. This binding will be used to define
the properties and configuration for the LVDS Controller in DT.
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display
On Tue, Apr 16, 2024 at 12:07:25PM +0200, Thomas Hellström wrote:
> The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock
> was dropped and simply restarting the iteration meant we'd likely
> hit the same error again on the same resource. Now that we can
> restart the iteration even if
./drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c: vmwgfx_vkms.h is included more than
once.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8772
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On Tue, Apr 16, 2024 at 12:07:22PM +0200, Thomas Hellström wrote:
> To be able to handle list unlocking while traversing the LRU
> list, we want the iterators not only to point to the next
> position of the list traversal, but to insert themselves as
> list nodes at that point to work around the
In V3D, the conclusion of a job is indicated by a IRQ. When a job
finishes, then we update the local and the global GPU stats of that
queue. But, while the GPU stats are being updated, a user might be
reading the stats from sysfs or fdinfo.
For example, on `gpu_stats_show()`, we could think about
Given a set of GPU stats, that is, a `struct v3d_stats` related to a
queue in a given context, create a function that can update this set
of GPU stats.
Signed-off-by: Maíra Canal
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Jose Maria Casanova Crespo
---
drivers/gpu/drm/v3d/v3d_sched.c | 17
This will make it easier to instantiate the GPU stats variables and it
will create a structure where we can store all the variables that refer
to GPU stats.
Note that, when we created the struct `v3d_stats`, we renamed
`jobs_sent` to `jobs_completed`. This better express the semantics of
the
The first version of this series had the intention to fix two major
issues with the GPU stats:
1. We were incrementing `enabled_ns` twice by the end of each job.
2. There is a race-condition between the IRQ handler and the users
The first of the issues was already addressed and the fix was
Currently, we manually perform all operations to update the GPU stats
variables. Apart from the code repetition, this is very prone to errors,
as we can see on commit 35f4f8c9fc97 ("drm/v3d: Don't increment
`enabled_ns` twice").
Therefore, create two functions to manage updating all GPU stats
Hi Dharma,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.9-rc4 next-20240416]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
When configuring the timing of DSI hosts (interfaces) in
dsi_timing_setup() all values written to registers are taking bonded
DSI into account by dividing the original mode width by 2 (half the
data is sent over each of the two DSI hosts), but the full width
instead of the interface width is
When dual-DSI (bonded DSI) was added in commit ed9976a09b48
("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints
were not updated, leading to print the original mode->clock rather
than the adjusted (typically the mode clock divided by two, though more
recently also adjusted for
Ordering issues here cause an uninitalized (default STANDALONE)
usecase to be programmed (which appears to be a MUX) in some cases
when msm_dsi_host_register() is called, leading to the slave PLL in
bonded-DSI mode to source from a clock parent (dsi1vco) that is off.
This should seemingly not be
This comment one line down references a single, "same CTL" that controls
two interfaces, so the comment should clearly describe two interfaces
used with a single active CTL and not "two CTLs".
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
All other functions in dpu_hw_intf name the "self" parameter `intf`,
except dpu_hw_intf_setup_timing_engine() and the recently added
dpu_hw_intf_program_intf_cmd_cfg(). Clean that up for consistency.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 14
Just like the active interface and writeback block in ctl_intf_cfg_v1(),
and later the rest of the blocks in followup active-CTL fixes or
reworks, multiple calls to this function should enable additional DSC
blocks instead of overwriting the blocks that are enabled.
This pattern is observed in an
As we can clearly see in a downstream kernel [1], flushing the slave INTF
is skipped /only if/ the PPSPLIT topology is active.
However, when DPU was originally submitted to mainline PPSPLIT was no
longer part of it (seems to have been ripped out before submission), but
this clause was incorrectly
| 14 +++---
drivers/gpu/drm/msm/dsi/dsi_manager.c| 15 +++
6 files changed, 32 insertions(+), 25 deletions(-)
---
base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e
change-id: 20240416-drm-msm-initial-dualpipe-dsc-fixes-3f0715b03bf4
Best regards,
--
Marijn Suijten
For the upcoming changes we need a cleaner way to build the list
of uabi engines.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
just sending this patch to unburden the coming series from this
single patch inherited from a previously sent series.
Andi
Le 15/04/24 - 15:00, Pekka Paalanen a écrit :
> On Tue, 09 Apr 2024 12:04:07 +0200
> Louis Chauvet wrote:
>
> > Let's provide more details about the drm_format_info structure because
> > its content may not be straightforward for someone not used to video
> > formats and drm internals.
> >
> >
Le 15/04/24 - 21:28, Bagas Sanjaya a écrit :
> On Tue, Apr 09, 2024 at 12:04:06PM +0200, Louis Chauvet wrote:
> > @@ -266,8 +257,41 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property);
> > *
> > * Rotation is the specified amount in degrees in counter clockwise
> > direction,
> > * the X and
Le 15/04/24 - 14:36, Pekka Paalanen a écrit :
> On Tue, 09 Apr 2024 12:04:06 +0200
> Louis Chauvet wrote:
>
> > The expected behavior of the rotation property was not very clear. Add
> > more examples to explain what is the expected result.
> >
> > Signed-off-by: Louis Chauvet
> > ---
> >
Add a function to get the AUX device of the parent of an MST port, used
by a follow-up i915 patch in the patchset.
v2: Move drm_dp_mst_aux_for_parent() forward declaration to this patch
(Ankit)
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Acked-by: Maarten
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA
monitor results in a blank screen, at least on MTL platforms on UHBR
link rates with some (<30) uncompressed bpp values. Enabling compression
fixes the problem, so do that for now. Windows enables DSC always if the
sink supports
Factor out a function to check if an MST port is logical, used by a
follow-up i915 patch in the patchset.
v2: Move drm_dp_mst_aux_for_parent() forward declaration to the next
patch. (Ankit)
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Acked-by: Maarten
Factor out a function to check for UHBR channel coding support used by a
follow-up patch in the patchset.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Reviewed-by: Manasi Navare
Acked-by: Maarten Lankhorst
Signed-off-by: Imre Deak
---
Fix the calculation of the DSC line buffer depth. This is limited both
by the source's and sink's maximum line buffer depth, but the former one
was not taken into account. On all Intel platform's the source's maximum
buffer depth is 13, so the overall limit is simply the minimum of the
On Sun, Mar 31, 2024 at 11:28:57PM +0300, Dmitry Baryshkov wrote:
> The IPUv3 DRM i.MX driver contains several codepaths for different
> usescases: both LDB and paralllel-display drivers handle next-bridge,
> panel and the legacy display-timings DT node on their own.
>
> Drop unused ddc-i2c-bus
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 66e4190e92ce0e4a50b2f6be0e5f5b2e47e072f4 Add linux-next specific
files for 20240416
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404161933.izfqz32k-...@intel.com
https
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-xe/drm-xe-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.9-rc4 next-20240416]
[cannot apply to drm-misc/drm-misc-next drm/drm-next drm-exynos
On Thu, Apr 11, 2024 at 12:55:29PM -0400, Golani, Mitulkumar Ajitkumar wrote:
>
>
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Wednesday, April 10, 2024 9:49 PM
> > To: Golani, Mitulkumar Ajitkumar ;
> > tzimmerm...@suse.de; mrip...@kernel.org;
> >
On Mon, Mar 4, 2024 at 6:49 PM Adam Ford wrote:
>
> The DSI to HDMI bridge supports hot-plut-detect, but the
> driver didn't previously support a shared IRQ GPIO. With
> the driver updated, the interrupt can be added to the bridge.
>
> Signed-off-by: Adam Ford
> Reviewed-by: Laurent Pinchart
On 4/16/24 2:00 PM, Marijn Suijten wrote:
> Hi Randy,
>
> [..]
>
>> Do you see differences in the generated html for these changes?
>
> I have not yet generated the HTML locally to test this patch, but will surely
> do
> if that's a requirement.
>
>> " somestruct" and "" should both be OK
Hi Randy,
[..]
> Do you see differences in the generated html for these changes?
I have not yet generated the HTML locally to test this patch, but will surely do
if that's a requirement.
> " somestruct" and "" should both be OK AFAIK, although
> Documentation/doc-guide/kernel-doc.rst seems to
On 2024-04-16 20:30:49, David Wronek wrote:
> Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
> Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
>
> Signed-off-by: David Wronek
> ---
> drivers/gpu/drm/panel/Kconfig | 14 +
>
nk_event() for more
>* complex case. In case the hardware lacks vblank support entirely,
> - * drivers can set drm_crtc_state.no_vblank in
> + * drivers can set _crtc_state.no_vblank in
>* drm_simple_display_pipe_funcs.check and let DRM's
>* atomic helper fake
Program live video input format according to selected media bus format.
In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
almost certainly supports a single media bus format as its output. Expect
this to be delivered via the new bridge atomic state. Program DPSUB
registers
Add optional drm_crtc_helper_funcs.select_output_bus_format callback. This
callback allows to negotiate compatible media bus format on the link
between CRTC and connected DRM encoder or DRM bridge chain. A good usage
example is the CRTC implemented as FPGA soft IP. This kind of CRTC will
most
Avoid usage of global zynqmp_dpsub.dma_enabled flag in DPSUB layer
context. This flag signals whether the driver runs in DRM CRTC or DRM
bridge mode, assuming that all display layers share the same live or
non-live mode of operation. Using per-layer mode instead of global flag
will simplify future
DPSUB in bridge mode supports multiple input media bus formats.
Announce the list of supported input media bus formats via
drm_bridge.atomic_get_input_bus_fmts callback. Introduce a set of live
input formats supported by DPSUB. Add safeguards to format list functions
to prevent their misuse in
Set layer mode of operation (live or dma-based) during layer creation.
Each DPSUB layer mode of operation is defined by corresponding DT node port
connection, so it is possible to assign it during layer object creation.
Previously it was set in layer enable functions, although it is too late
as
Add a helper function capturing the first connected live display layer
discovery logic.
Signed-off-by: Anatoliy Klymenko
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git
Update live format defines to match DPSUB AV_BUF_LIVE_VID_CONFIG register
layout. These defines were never referenced before, so no other changes
required.
Reviewed-by: Laurent Pinchart
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 8
1 file changed, 4
Implement live video input format setting for ZynqMP DPSUB.
ZynqMP DPSUB can operate in 2 modes: DMA-based and live.
In the live mode, DPSUB receives a live video signal from FPGA-based CRTC.
DPSUB acts as a DRM encoder bridge in such a scenario. To properly tune
into the incoming video signal,
Le 16/04/2024 à 20:30, David Wronek a écrit :
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
On 2024-04-15 19:50:49, Dmitry Baryshkov wrote:
> On Mon, Apr 15, 20
[...]
> > +static int rm69380_on(struct rm69380_panel *ctx)
[...]
> ret = mipi_dsi_dcs_set_display_brightness_large(dsi, 0x7ff);
Downstream may send this here, but why? As far as I've observed, update_status
also sets
On Thu, 04 Apr 2024 13:07:58 +0300, Dmitry Baryshkov wrote:
> While taking a glance at the novatek-nt36672e driver I stumbled upon a
> call to unregister the DSI device for the panel, although it was not the
> panel driver that registered the device.
>
> Remove this call and a similar call from
On Tue, Apr 16, 2024 at 08:30:49PM +0200, David Wronek wrote:
> Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
> Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
>
> Signed-off-by: David Wronek
> ---
> drivers/gpu/drm/panel/Kconfig |
On 09/04/2024 10:02, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and
*/
---
base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e
change-id: 20240416-drm-no_vblank-kdoc-link-fea1b53008a3
Best regards,
--
Marijn Suijten
reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240416-raydium-rm69380-driver-v3-1-21600ac4c...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran
On Tue, Apr 16, 2024 at 12:02:10PM -0700, Dixit, Ashutosh wrote:
> On Tue, 16 Apr 2024 11:55:20 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private
> > > *i915)
> > >
> > > void i915_hwmon_unregister(struct
On Mon, Apr 15, 2024 at 10:52:15AM GMT, Lu Yao wrote:
ACPI_WMI is a subitem of X86_PLATFORM_DEVICES. And X86_PLATFORM_DEVICES
is not selected in the current Kconfig, and may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for ACPI_WMI
Depends on [n]: X86_PLATFORM_DEVICES
On Tue, 16 Apr 2024 11:55:20 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> >
> > void i915_hwmon_unregister(struct drm_i915_private *i915)
> > {
> > - fetch_and_zero(>hwmon);
> > + struct i915_hwmon *hwmon =
On Mon, Apr 15, 2024 at 03:36:12PM -0700, Ashutosh Dixit wrote:
> When both hwmon and hwmon drvdata (on which hwmon depends) are device
> managed resources, the expectation, on device unbind, is that hwmon will be
> released before drvdata. However, in i915 there are two separate code
> paths,
Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
Add a dt-binding for it.
Signed-off-by: David Wronek
---
Note:
Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
dual-link schema")
---
.../bindings/display/panel/raydium,rm69380.yaml| 91
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
This patch adds support the 2560x1600@90Hz dual DSI command mode panel by
EDO in combination with a Raydium RM69380 driver IC.
This driver IC can be found in the following devices:
* Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel
* Lenovo Tab P11 Pro (TB-J706F) with EDO panel
* Robo &
On 15/04/2024 05:14, Jacobe Zang wrote:
This add Khadas TS050 V2 Panel and make it compatible with old one.
Controller of V2 panel is "Himax HX8399-C" and the old panel is "NT35596".
In driver file, the only different between them is the timing squence.
Signed-off-by: Jacobe Zang
---
On 15/04/2024 23:49, Nícolas F. R. A. Prado wrote:
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Douglas Anderson
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-edp.c | 17 ++---
1 file changed, 10
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-samsung-atna33xc20.c | 13 -
1 file changed, 8
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 15 ---
1 file changed, 8 insertions(+), 7
On 4/16/24 10:21, Conor Dooley wrote:
On Tue, Apr 16, 2024 at 07:13:51AM -0300, Maíra Canal wrote:
On 4/16/24 02:30, Stefan Wahren wrote:
Hi Maíra,
Am 16.04.24 um 03:02 schrieb Maíra Canal:
On 4/15/24 13:54, Andre Przywara wrote:
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
W dniu 2024-04-15 19:55, Christophe JAILLET napisał(a):
Le 15/04/2024 à 18:10, David Wronek a écrit :
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro
2021.
Signed-off-by: David Wronek
---
On Tue, Apr 16, 2024 at 07:13:51AM -0300, Maíra Canal wrote:
> On 4/16/24 02:30, Stefan Wahren wrote:
> > Hi Maíra,
> >
> > Am 16.04.24 um 03:02 schrieb Maíra Canal:
> > > On 4/15/24 13:54, Andre Przywara wrote:
> > > > On Mon, 15 Apr 2024 13:00:39 -0300
> > > > Maíra Canal wrote:
> > > >
> > >
I would argue 'restricted' is the proper name since that was what was
settled on for the dma-buf code. :) But you are definitely right
that this memory is not encrypted.
On Tue, Apr 16, 2024 at 7:09 AM Nicolas Dufresne wrote:
>
> Hi,
>
> Le mercredi 03 avril 2024 à 18:26 +0800, Shawn Sung a
On Tue, Apr 16, 2024 at 10:09:46AM +0200, Janusz Krzysztofik wrote:
> Hi Rodrigo,
>
> On Tuesday, 16 April 2024 03:16:31 CEST Rodrigo Vivi wrote:
> > On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> > > We defer actually closing, unbinding and destroying a VMA until next idle
On 4/10/24 10:02, Thomas Zimmermann wrote:
Implement fbdev emulation with fbdev-shmem. Avoids the overhead of
fbdev-generic's additional shadow buffering. No functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Maíra Canal
Best Regards,
- Maíra
Cc: Rodrigo Siqueira
Cc: Melissa
Enable this feature for the i350-evk HDMI connector support.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index fce98a150014..1df337882835 100644
---
MIPI DSI:
- Add "vsys_lcm_reg" regulator support and setup the "mt6357_vsim1_reg",
to power the pannel plugged to the DSI connector.
- Setup the Display Parallel Interface.
- Add the startek kd070fhfid015 pannel support.
HDMI:
- Add HDMI connector support.
- Add the "ite,it66121" HDMI bridge
From: Fabien Parent
Add DRM support for MT8365 SoC.
Signed-off-by: Fabien Parent
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 ++
1 file changed, 30 insertions(+)
diff --git
Add a compatible string for MediaTek Genio 350 MT8365's display PWM
block: this is the same as MT8183.
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Uwe Kleine-König
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 +
1 file changed, 1
Currently, mtk_dsi_lane_ready (which setup the DSI lane) is triggered
before mtk_dsi_poweron. lanes_ready flag toggle to true during
mtk_dsi_lane_ready function, and the DSI module is set up during
mtk_dsi_poweron.
Later, during panel driver init, mtk_dsi_lane_ready is triggered but does
nothing
Document the Display Serial Interface on MT8365, which is compatible
with that of the MT8183.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
- Add compatibles and platform data into the Mediatek DPI driver.
- Fix the DPI0 parent clock to be consistent.
This SoC is compatible with the mt8183 calculate factor.
Signed-off-by: Alexandre Mergnat
---
drivers/clk/mediatek/clk-mt8365-mm.c | 2 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 18
- Add aliases for each display components to help display drivers.
- Add the Display Pulse Width Modulation (DISP_PWM) to provide PWM signals
for the LED driver of mobile LCM.
- Add the MIPI Display Serial Interface (DSI) PHY support. (up to 4-lane
output)
- Add the display mutex support.
-
Document the display Gamma on MT8365, which is compatible
with that of the MT8183.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Document the display Data Path Read DMA on MT8365, which is compatible
with that of the MT8183.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Fabien Parent
DPI is part of the display / multimedia block in MediaTek SoCs, and
always have a power-domain (at least in the upstream device-trees).
Add the power-domains property to the binding documentation.
Signed-off-by: Fabien Parent
Signed-off-by: Alexandre Mergnat
---
According to the Mediatek MT8365 datasheet, the display PWM block has
a power domain.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git
Add dt-binding documentation of dpi for MediaTek MT8365 SoC.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
Document the display Overlay on MT8365, which is compatible
with that of the MT8192.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Document the display Color Correction on MT8365, which is compatible
with that of the MT8183.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
Document the display Color on MT8365, which is compatible
with that of the MT8173.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Document the display Dither on MT8365, which is compatible
with that of the MT8183.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Document the display Adaptive Ambient Light on MT8365, which is compatible
with that of the MT8183.
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
The purpose of this series is to add the display support for the mt8365-evk.
This is the list of HWs / IPs support added:
- Connectors (HW):
- HDMI
- MIPI DSI (Mobile Industry Processor Interface Display Serial Interface)
- HDMI bridge (it66121)
- DSI pannel (startek,kd070fhfid015)
- SoC
On 16/04/2024 14:12, Thomas Zimmermann wrote:
Hi
Am 16.04.24 um 11:05 schrieb Jocelyn Falempe:
The parameter name is 'sb' and not 'drm_scanout_buffer'.
It fixes the following warnings:
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function
parameter 'drm_scanout_buffer'
On 24/10/2023 11:12, AngeloGioacchino Del Regno wrote:
Il 23/10/23 16:40, amerg...@baylibre.com ha scritto:
From: Fabien Parent
MT8365 requires an additional clock for DPI. Add support for that
additional clock.
Signed-off-by: Fabien Parent
Signed-off-by: Alexandre Mergnat
I'm not
On 2024-04-16 04:01, Pekka Paalanen wrote:
> On Mon, 15 Apr 2024 18:33:39 -0400
> Leo Li wrote:
>
>> On 2024-04-15 04:19, Pekka Paalanen wrote:
>>> On Fri, 12 Apr 2024 16:14:28 -0400
>>> Leo Li wrote:
>>>
On 2024-04-12 11:31, Alex Deucher wrote:
> On Fri, Apr 12, 2024 at 11:08
On Tue, Mar 26, 2024 at 04:40:23PM +0100, Maxime Ripard wrote:
> HDMI controller drivers will need to figure out the RGB range they need
> to configure based on a mode and property values. Let's expose that in
> the HDMI connector state so drivers can just use that value.
>
> Reviewed-by: Dave
1 - 100 of 204 matches
Mail list logo
