These registers might change their value without any host write operation.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index
Use the register names from the datasheet. No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
This is the single register which clears its value upon read operation.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index
Sort the list by the starting address to ease adding new entries.
No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
Using ranges it is easier to add more register where writing is not allowed,
especially for sequences of registers.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
While at it, also add missing register definitions. HDCP registers are
skipped as they are not named, range 0x0980 - 0x09ac.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 87 ---
1 file changed, 81 insertions(+), 6 deletions(-)
diff --git
0x0510 is bigger than 0x50c, order them accordingly.
No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
Hi,
this series improves the regmap usage by cleaning up current usage as well as
adding more registers to the list of volatile registers. SYSSTAT is added
to the list of precious registers as it is cleared upon read.
This series is based on [1].
Changes in v2:
* Patch 3: Use more symbolic names
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> Lets rename the existing wb2_formats array wb2_formats_rgb to indicate
> that it has only RGB formats and can be used on any chipset having a WB
> block.
>
> Introduce a new wb2_formats_rgb_yuv array to the catalog to
> indicate support for
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> Reserve CDM blocks for writeback if the format of the output fb
> is YUV. At the moment, the reservation is done only for writeback
> but can easily be extended by relaxing the checks once other
> interfaces are ready to output YUV.
>
>
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by
> the writeback encoder to setup the CDM block.
>
> Currently, this is defined and used within the writeback's physical
> encoder layer however, the function can be modified
On Mon, 11 Dec 2023 at 23:48, Abhinav Kumar wrote:
>
>
>
> On 12/11/2023 1:42 PM, Dmitry Baryshkov wrote:
> > On Mon, 11 Dec 2023 at 23:32, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
> >>> On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar
> >>>
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> Since the type and usage of CSC matrices is spanning across DPU
> lets introduce a helper to the dpu_hw_util to return the CSC
> corresponding to the request type. This will help to add more
> supported CSC types such as the RGB to YUV one
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> In preparation for adding more formats to dpu writeback add
> format validation to it to fail any unsupported formats.
>
> changes in v3:
> - rebase on top of msm-next
> - replace drm_atomic_helper_check_wb_encoder_state()
On Tue, 12 Dec 2023 at 02:03, Kuogee Hsieh wrote:
>
>
> On 12/11/2023 1:30 PM, Dmitry Baryshkov wrote:
> > On Mon, 11 Dec 2023 at 20:38, Kuogee Hsieh wrote:
> >> A DCE (Display Compression Engine) contains two DSC hard slice
> >> encoders. Each DCE start with even DSC encoder index followed by
>
On Tue, 12 Dec 2023 at 02:30, Abhinav Kumar wrote:
>
>
>
> On 12/2/2023 4:31 PM, Dmitry Baryshkov wrote:
> > I was not able to test it on my own, this is a call for testing for the
> > owners of these platforms. The git version of modetest now fully
> > supports writeback.
> >
> > Use libdrm >=
Hello Uwe Kleine-König,
2023년 12월 7일 (목) 오후 5:03, Uwe Kleine-König
님이 작성:
>
> Hello Inki,
>
> On Thu, Dec 07, 2023 at 11:37:44AM +0900, 대인기/Tizen Platform Lab(SR)/삼성전자
> wrote:
> > Hello Uwe Kleine-König,
> >
> > > -Original Message-
> > > From: Uwe Kleine-König
> > > Sent: Wednesday,
Hi Dave and Daniel,
Just one fixup to shutdown relevant issue and two cleanups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit a2f8994c1001cfa48483a3afa3550016a3ab0a3e:
Merge tag 'exynos-drm-next-for-v6.7-rc5' of
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
Fixes:
Create a new MediaTek CMA heap from the CMA reserved buffer.
In this heap, When the first allocating buffer, use cma_alloc to prepare
whole the CMA range, then send its range to TEE to protect and manage.
For the later allocating, we just adds the cma_used_size.
When SVP done, cma_release will
Add TEE service call for MediaTek heap. We have a limited number of
hardware entries to protect memory, therefore we cannot protect memory
arbitrarily, then our secure memory management is actually inside OPTEE.
The kernel just tells the TEE what size I want and the TEE will return a
"secure
Add a Mediatek secure heap which uses TEE service call to protect
buffer. Currently this secure heap is NULL, Prepare for the later patch.
Mainly there are two changes:
a) Add a heap_init ops since TEE probe late than secure heap, thus
initialize the heap when we require the buffer the first
Add the dma_ops for this secure heap. For secure buffer, cache_ops/mmap
are not allowed, thus return EPERM for them.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 103
1 file changed, 103 insertions(+)
diff --git
Add "struct secure_heap_ops". For the secure memory, totally there are
two steps:
a) memory_alloc: Allocate the buffer in kernel;
b) secure_the_memory: Secure/Proect that buffer.
The memory_alloc is mandatory while secure_the_memory is optinal since
it may be part of memory_alloc.
Signed-off-by:
Add a binding for describing the dynamic secure reserved memory range. The
memory range also will be defined in the TEE firmware. It means the TEE
will be configured with the same address/size that is being set in this
DT node. Regarding to the detail TEE command, Please search
Initialize a secure heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 6 +++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 67 +
This patchset is for secure video playback and enables other potential
uses in the future. The 'secure dma-heap' will be used to allocate dma_buf
objects that reference memory in the secure world that is inaccessible/
unmappable by the non-secure (i.e.kernel/userspace) world. That memory
will be
For aux reads, the value `msg->size` indicates the size of the buffer
provided by `msg->buffer`. We should never in any circumstances write
more bytes to the buffer since it may overflow the buffer.
In the ti-sn65dsi86 driver there is one code path that reads the
transfer length from hardware.
While testing, I happened to notice a random crash that looked like:
Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
(allocated on the stack) to the aux->transfer()
On 12/2/2023 4:31 PM, Dmitry Baryshkov wrote:
I was not able to test it on my own, this is a call for testing for the
owners of these platforms. The git version of modetest now fully
supports writeback.
Use libdrm >= 2.4.117, run modetest -ac to determine the writeback
connector, cat
Phillip Susi writes:
> And it works, but 6.7-rc5 does not, even though it includes that patch.
> Here's the syslog from the attempt. I'll start bisecting again.
I checked out the patch that got merged upstream and it also fails. I
looked at the two commits, and I see what happened. Your
Now that CDM block support has been added to DPU lets also add its
entry to the DPU snapshot to help debugging.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git
Lets rename the existing wb2_formats array wb2_formats_rgb to indicate
that it has only RGB formats and can be used on any chipset having a WB
block.
Introduce a new wb2_formats_rgb_yuv array to the catalog to
indicate support for YUV formats to writeback in addition to RGB.
Chipsets which have
Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by
the writeback encoder to setup the CDM block.
Currently, this is defined and used within the writeback's physical
encoder layer however, the function can be modified to be used to setup
the CDM block even for non-writeback
Add CDM blocks to the sm8250 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- re-use the cdm definition from sc7280
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 +
1 file
CDM block will need its own logic to program the flush and active
bits in the dpu_hw_ctl layer.
Make necessary changes in dpu_hw_ctl to support CDM programming.
changes in v3:
- drop unused cdm_active as reported by kbot
- retained the R-b as its a trivial change
changes in v2:
Reserve CDM blocks for writeback if the format of the output fb
is YUV. At the moment, the reservation is done only for writeback
but can easily be extended by relaxing the checks once other
interfaces are ready to output YUV.
changes in v3:
- squash CDM disable during encoder cleanup
To setup and enable CDM block for the writeback pipeline, lets
add the pieces together to set the active bits and the flush
bits for the CDM block.
changes in v2:
- passed the cdm idx to update_pending_flush_cdm()
(have retained the R-b as its a minor change)
Signed-off-by:
Add the RM APIs necessary to initialize and allocate CDM
blocks to be used by the rest of the DPU pipeline.
changes in v2:
- treat cdm_init() failure as fatal
- fixed the commit text
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
Even though there is usually only one CDM block, it can be
used by either HDMI, DisplayPort OR Writeback interfaces.
Hence its allocation needs to be tracked properly by the
resource manager to ensure appropriate availability of the
block.
changes in v2:
- move needs_cdm to topology
For YUV cases, setting the required format bits was missed
out in the register programming. Lets fix it now in preparation
of adding YUV formats support for writeback.
changes in v2:
- dropped the fixes tag as its not a fix but adding
new functionality
Signed-off-by: Abhinav Kumar
CDM block comes with its own set of registers and operations
which can be done. In-line with other hardware blocks, this
change adds the dpu_hw_cdm abstraction for the CDM block.
changes in v3:
- fix commit text from sub-blk to blk for CDM
- fix kbot issue for missing static for
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v3:
- change the comment from sub-blk to clk for CDM
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm to dpu_hw_catalog from the sc7280
Since the type and usage of CSC matrices is spanning across DPU
lets introduce a helper to the dpu_hw_util to return the CSC
corresponding to the request type. This will help to add more
supported CSC types such as the RGB to YUV one which is used in
the case of CDM.
changes in v3:
- drop
dpu_encoder_phys_wb_setup_cdp() is not programming the chroma down
prefetch block. Its setting up the display ctl path for writeback.
Hence rename it to dpu_encoder_phys_wb_setup_ctl() to match what its
actually doing.
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
In preparation for adding more formats to dpu writeback add
format validation to it to fail any unsupported formats.
changes in v3:
- rebase on top of msm-next
- replace drm_atomic_helper_check_wb_encoder_state() with
drm_atomic_helper_check_wb_connector_state() due to
Chroma Down Sampling (CDM) block is a hardware block in the DPU pipeline
which among other things has a CSC block that can convert RGB input
from the DPU to YUV data.
This block can be used with either HDMI, DP or writeback interface.
In this series, lets first add the support for CDM block to
On 12/11/2023 1:30 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 20:38, Kuogee Hsieh wrote:
A DCE (Display Compression Engine) contains two DSC hard slice
encoders. Each DCE start with even DSC encoder index followed by
"starts". But it will not be correct. The DCE doesn't start with
On Fri, Dec 8, 2023 at 4:48 PM Chris Morgan wrote:
> From: Chris Morgan
>
> The Powkiddy RG-ARC is a series of 2 handheld devices, each with a 4
> inch 480x640 display. Add support for the display.
>
> Signed-off-by: Chris Morgan
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Dec 8, 2023 at 4:48 PM Chris Morgan wrote:
> From: Chris Morgan
>
> The AVCL register, according to the datasheet, comes in increments
> of -0.2v between -4.4v (represented by 0x0) to -5.0v (represented
> by 0x3). The current calculation is done by adding the defined
> AVCL value in mV
On 2023-12-11 04:50, Christian König wrote:
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how to do this, maybe Alex knows of hand.
Since the buffers are cleared on creation, is
On Mon, Dec 11, 2023 at 2:09 PM Marijn Suijten
wrote:
>
> On 2023-12-11 10:19:55, Rob Clark wrote:
> > From: Rob Clark
> >
> > When we start getting these, we get a *lot*. So ratelimit it to not
> > flood dmesg.
> >
> > Signed-off-by: Rob Clark
> > ---
> >
> > dpu should probably stop rolling
Add a simple test that checks whether the action is indeed called right
away and that it is not called on the final drm_dev_put().
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 29
1 file changed, 29 insertions(+)
diff --git
It simplifies the process of extending the test suite with additional
test cases without unnecessary duplication.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 51 +---
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git
Similar to devres equivalent, it allows to call the "release" action
directly and remove the resource from the managed resources list.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_managed.c | 39 +++
include/drm/drm_managed.h | 4
2 files
On 2023-12-11 10:19:55, Rob Clark wrote:
> From: Rob Clark
>
> When we start getting these, we get a *lot*. So ratelimit it to not
> flood dmesg.
>
> Signed-off-by: Rob Clark
> ---
>
> dpu should probably stop rolling it's own trace macros, but that would
> be a larger cleanup.
That would
Upcoming Intel Xe driver will need to have a more fine-grained control
over DRM managed actions - namely, the ability to release a given
action, triggering it manually at a different point in time than the
final drm_dev_put().
This series adds a drmm_release_action function (which is similar to
On 10/12/2023 00:21, Dmitry Baryshkov wrote:
> Add compatible string for the DisplayPort controller found on the
> Qualcomm SM8150 platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On 12/11/2023 1:42 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 23:32, Abhinav Kumar wrote:
On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar wrote:
On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
On Fri, 8 Dec 2023 at 07:07, Abhinav
On Mon, 11 Dec 2023 at 23:32, Abhinav Kumar wrote:
>
>
>
> On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
> > On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
> >>> On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar
> >>> wrote:
On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar wrote:
On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar wrote:
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback
On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar wrote:
>
>
>
> On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
> > On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar
> > wrote:
> >>
> >> Add CDM blocks to the sc7280 dpu_hw_catalog to support
> >> YUV format output from writeback block.
> >>
> >> changes in
On Mon, 11 Dec 2023 at 20:38, Kuogee Hsieh wrote:
>
> A DCE (Display Compression Engine) contains two DSC hard slice
> encoders. Each DCE start with even DSC encoder index followed by
"starts". But it will not be correct. The DCE doesn't start with the
DSC encoder. DCE consists of two DSC
On 12/11/2023 6:54 AM, Dmitry Baryshkov wrote:
The drmm handler will perform drm_encoder_cleanup() for us. Moreover if
we call drm_encoder_cleanup() manually, the drmm_encoder_alloc_release()
will spawn warnings at drivers/gpu/drm/drm_encoder.c:214. Drop these
extra drm_encoder_cleanup()
On 11/6/2023 4:43 PM, Dmitry Baryshkov wrote:
The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the
next bridge is not (yet) available. However returning -EPROBE_DEFER from
msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from
component_bind, which can easily
On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar wrote:
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm
On 10/12/2023 00:21, Dmitry Baryshkov wrote:
> Add compatible string for the DisplayPort controller found on the
> Qualcomm SM8150 platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
i.MX8MQ does not have an LCDIF power domain, so pass only
"fsl,imx8mq-lcdif" as compatible string to fix the following
dt-schema warning:
imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is a required property
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
i.MX8MQ does not have an LCDIF power domain, so allow passing only
"fsl,imx8mq-lcdif" as compatible string to fix the following
dt-schema warning:
imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is a required
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
However, i.MX8MQ does not have an LCDIF power domain.
imx8mq.dtsi has the following compatible string:
compatible = "fsl,imx8mq-lcdif", "fsl,imx6sx-lcdif";
which causes the following dt-schema warning:
imx8mq-evk.dtb:
On 12/11/23 02:30, Mina Almasry wrote:
On Sat, Dec 9, 2023 at 7:05 PM Pavel Begunkov wrote:
On 12/8/23 23:25, Mina Almasry wrote:
On Fri, Dec 8, 2023 at 2:56 PM Pavel Begunkov wrote:
On 12/8/23 00:52, Mina Almasry wrote:
...
+ if (pool->p.queue)
+ binding =
Thanks for catching this.
Reviewed-by: Alex Hung
On 2023-12-08 02:58, Harshit Mogalapalli wrote:
'wb_info' needs to be freed on error paths or it would leak the memory.
Smatch pointed this out.
Fixes: c81e13b929df ("drm/amd/display: Hande writeback request from userspace")
Signed-off-by:
A DCE (Display Compression Engine) contains two DSC hard slice
encoders. Each DCE start with even DSC encoder index followed by
an odd DSC encoder index. Each encoder can work independently.
But Only two DSC encoders from same DCE can be paired to work
together to support merge mode. In addition,
On 12/11/2023 10:19 AM, Rob Clark wrote:
From: Rob Clark
When we start getting these, we get a *lot*. So ratelimit it to not
flood dmesg.
Signed-off-by: Rob Clark
---
dpu should probably stop rolling it's own trace macros, but that would
be a larger cleanup.
On Mon, 2023-12-11 at 09:52 +0100, Boris Brezillon wrote:
> Hi,
>
> On Sun, 10 Dec 2023 13:58:51 +0900
> Tatsuyuki Ishi wrote:
>
> > > On Dec 5, 2023, at 2:32, Boris Brezillon
> > > wrote:
> > >
> > > Hello,
> > >
> > > This is the 3rd version of the kernel driver for Mali CSF-based
> > >
From: Rob Clark
When we start getting these, we get a *lot*. So ratelimit it to not
flood dmesg.
Signed-off-by: Rob Clark
---
dpu should probably stop rolling it's own trace macros, but that would
be a larger cleanup.
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 -
On Mon, Dec 11, 2023 at 3:51 AM Yunsheng Lin wrote:
>
> On 2023/12/11 12:04, Mina Almasry wrote:
> > On Sun, Dec 10, 2023 at 6:26 PM Mina Almasry wrote:
> >>
> >> On Sun, Dec 10, 2023 at 6:04 PM Yunsheng Lin
> >> wrote:
> >>>
> >>> On 2023/12/9 0:05, Mina Almasry wrote:
> On Fri, Dec 8,
On Tue, Nov 07, 2023 at 02:43:33AM +0200, Dmitry Baryshkov wrote:
> The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the
> next bridge is not (yet) available. However returning -EPROBE_DEFER from
> msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from
>
https://bugzilla.kernel.org/show_bug.cgi?id=218250
--- Comment #4 from Jaime Pérez (19.jaime...@gmail.com) ---
Created attachment 305589
--> https://bugzilla.kernel.org/attachment.cgi?id=305589=edit
dmesg wo commit
--
You may reply to this email to add a comment.
You are receiving this mail
On Wed, Sep 20, 2023 at 12:10 PM Lucas Stach wrote:
>
> 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 LCDIF. The block
> just needs to be
On Mon, Dec 4, 2023 at 6:33 AM Keith Zhao wrote:
>
> add hdmi driver as encoder and connect
>
> Signed-off-by: Keith Zhao
> ---
> drivers/gpu/drm/verisilicon/Kconfig | 8 +
> drivers/gpu/drm/verisilicon/Makefile| 1 +
> drivers/gpu/drm/verisilicon/starfive_hdmi.c | 849
On Thu, Dec 7, 2023 at 8:17 AM Dario Binacchi
wrote:
>
> From: Michael Trimarchi
>
> The GPM1790A0 panel is based on the Ilitek ILI9805 Controller.
> Add a driver for it.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
>
> ---
>
> (no changes since v4)
>
> Changes in v4:
>
On Mon, Dec 11, 2023 at 4:50 AM Christian König
wrote:
>
> Am 08.12.23 um 20:53 schrieb Alex Deucher:
>
> [SNIP]
>
> You also need a functionality which resets all cleared blocks to
> uncleared after suspend/resume.
>
> No idea how to do this, maybe Alex knows of hand.
>
> Since the buffers are
On 7.11.2023 01:43, Dmitry Baryshkov wrote:
> The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the
> next bridge is not (yet) available. However returning -EPROBE_DEFER from
> msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from
> component_bind, which can
On 04/12/2023 17:33, Boris Brezillon wrote:
> This is the piece of software interacting with the FW scheduler, and
> taking care of some scheduling aspects when the FW comes short of slots
> scheduling slots. Indeed, the FW only expose a few slots, and the kernel
> has to give all submission
Hi,
On Sat, Dec 9, 2023 at 7:31 AM Uwe Kleine-König
wrote:
>
> It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
> let the auxiliary device be the parent of the pwm device.
>
> Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get()
> isn't affected by this
On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland
wrote:
>
> Hi Arnd,
>
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
> > On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
> >> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> >>> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
>
On Mon, 11 Dec 2023 at 16:54, Dmitry Baryshkov
wrote:
>
> The drmm handler will perform drm_encoder_cleanup() for us. Moreover if
> we call drm_encoder_cleanup() manually, the drmm_encoder_alloc_release()
> will spawn warnings at drivers/gpu/drm/drm_encoder.c:214. Drop these
> extra
Hi Alex,
On 2023-12-11 9:17 AM, Alex Deucher wrote:
> On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland
> wrote:
>>
>> Hi Arnd,
>>
>> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> On
Expand Combo USB+DP QMP PHY device node with the OF ports required to
support USB-C / DisplayPort switching.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git
Expand first USB host controller device node with the OF ports required
to support USB-C / DisplayPort switching.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git
Enable the USB-C related functionality for the USB-C port on this board.
This includes OTG, PowerDelivery and DP AltMode. Also enable the
DisplayPort itself.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 124 +++-
1 file changed, 123
The SM8150-HDK uses two different regulators to power up SuperSpeed USB
PHYs. The L5A regulator is used for the second USB host, while the first
(OTG) USB host uses different regulator, L18A. Fix the regulator for the
usb_1 QMPPHY and (to remove possible confusion) drop the
usb_ss_dp_core_1/_2
Add required-opps property to the display clock controller. This makes
it cast minimal vote on the MMCX lane and prevents further 'clock stuck'
errors when enabling the display.
Fixes: 2ef3bb17c45c ("arm64: dts: qcom: sm8150: Add DISPCC node")
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry
Add device tree node for the DisplayPort controller and link it to the
display controller interface.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 87
1 file changed, 87 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
Add DSI outputs and link them to the onboard Lontium LT9611 DSI-to-HDMI
bridge, enabling HDMI output on this board. While adding the display
resources, also drop the headless ("amd,imageon") compat string from the
GPU node, since the board now has output.
Signed-off-by: Dmitry Baryshkov
---
Add compatible string for the DisplayPort controller found on the
Qualcomm SM8150 platform.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Enable display output on the SM8150 HDK device. This includes HDMI
output through the onboard DSI-HDMI bridge and DP output on the USB-C
port.
Changes since v1
- Dropped irrelevant stats patch
- Fixed endpoint stye (Konrad)
- Changed SVID from u32 to 16-bits value (Konrad)
Dmitry Baryshkov (8):
mmit b85ea95d086471afb4ad062012a4d73cd328fa86:
Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git
tags/mediatek-drm-fixes-20231211
for you to fetch change
1 - 100 of 207 matches
Mail list logo
