Adds decoder dt-bindings for mt8186.
Signed-off-by: Yunfei Dong
---
.../bindings/media/mediatek,vcodec-subdev-decoder.yaml| 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
Add h264 decode driver to support mt8186. For the architecture
is single core, need to add new interface to decode.
Signed-off-by: Yunfei Dong
---
.../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 164 ++
.../media/platform/mtk-vcodec/vdec_drv_if.c | 5 +-
Firstly, add mt8186 compatible and private data, then add document for
compatible "mediatek,mt8186-vcodec-dec". For mt8186 is single core
architecture, need to add new interface for h264 hardware decoder.
Patche 1 add mt8186 compatible and private data.
Patche 2 add mt8186 compatible document.
Adds MT8186's compatible "mediatek,mt8186-vcodec-dec".
Adds MT8186's device private data mtk_vdec_single_core_pdata.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4
Need to use default pic info when get pic info fail.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
Adds h264 lat and core architecture driver for mt8192,
and the decode mode is frame based for stateless decoder.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 614 ++
Capture queue format type is difference for different platform,
need to calculate capture buffer size according to capture queue
format type in scp.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 2
For vp8 not support 4K, need to disable it.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
Add support for VP9 decoding using the stateless API,
as supported by MT8192. And the drivers is lat and core architecture.
Signed-off-by: Yunfei Dong
Signed-off-by: George Sun
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/media/platform/mtk-vcodec/Makefile|1 +
Mt8192 can use some of common code with mt8183. Moves them to
a new file in order to reuse.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/vdec/vdec_h264_req_common.c| 310 +
.../mtk-vcodec/vdec/vdec_h264_req_common.h|
Needs to use mediatek compressed mode for mt8192 decoder.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 7 ++-
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git
Add support for VP8 decoding using the stateless API,
as supported by MT8192.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 24 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 +
Supported max resolution for different platforms are not the same: 2K
or 4K, getting it according to dec_capability.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 29 +++
.../platform/mtk-vcodec/mtk_vcodec_drv.h |
Supported output and capture format types for mt8192 are different
with mt8183. Needs to get format types according to decoder capability.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 8 +-
.../mtk-vcodec/mtk_vcodec_dec_stateful.c | 13 +-
For lat and core decode in parallel, need to get capture buffer
when core start to decode and put capture buffer to display
list when core decode done.
Signed-off-by: Yunfei Dong
---
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 121 --
.../platform/mtk-vcodec/mtk_vcodec_drv.h
lat thread: output queue \
-> lat hardware -> lat trans buffer
lat trans buffer /
core thread: capture queue \
->core hardware -> capture queue
lat trans buffer /
Lat and core work in different
MT8173 platform use vpu firmware, mt8183/mt8192 will use scp
firmware instead, using chip name is not reasonable to separate
different firmware architecture. Using firmware type is much better.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
Reviewed-by: AngeloGioacchino Del Regno
---
Different capture buffer format has different buffer size, need to get
real buffer size according to buffer type from scp.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 36 ++
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 49 +++
Lock, power and clock are highly coupled operations. Adds vdec
enable/disable hardware helpers and uses them.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 -
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 168 +++---
This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly,
refactor
power/clock/interrupt interfaces for mt8192 is lat and core architecture.
Secondly, add new functions to get frame buffer size and resolution according
to decoder capability from scp side. Then add callback
Quoting Daniel Latypov (2022-01-20 21:25:03)
> On Thu, Jan 20, 2022 at 8:34 PM Stephen Boyd wrote:
> >
> > Quoting Daniel Latypov (2022-01-20 13:56:39)
> > > On Thu, Jan 20, 2022 at 1:31 PM Stephen Boyd wrote:
> > > KUnit doesn't have hard technical limitations in this regard.
> > >
> > > You
ed, 1 insertion(+), 1 deletion(-)
--- linux-next-20220121.orig/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ linux-next-20220121/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -4970,7 +4970,7 @@ uint32_t dc_link_bw_kbps_from_raw_frl_li
return 0;
}
-/**
+/*
* Return PCON's post
On Wed, Jan 12, 2022 at 05:46:05PM +, Biju Das wrote:
> The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
> can operate in DSI mode, with up to four data lanes.
>
> Signed-off-by: Biju Das
> ---
> .../bindings/display/bridge/renesas,dsi.yaml | 143 ++
On Wed, Jan 12, 2022 at 05:46:01PM +, Biju Das wrote:
> Extend the Renesas DU display bindings to support the r9a07g044l RZ/G2L.
>
> Signed-off-by: Biju Das
> ---
> .../bindings/display/renesas,du.yaml | 54 +++
> 1 file changed, 54 insertions(+)
>
> diff --git
Using more guc_ids in the stealing guc id test has no real benefit.
Tearing down lots of contexts all at the same time takes a bit of time
due to the H2G / G2H ping-pong with the GuC. On some slower platforms
this can cause timeous when flushing the test as the GT isn't idle when
this ping-pong is
On Sun, 09 Jan 2022 18:18:13 +0100, David Heidelberg wrote:
> Convert mdp4 binding into yaml format.
>
> Signed-off-by: David Heidelberg
> ---
> .../devicetree/bindings/display/msm/mdp4.txt | 114
> .../devicetree/bindings/display/msm/mdp4.yaml | 124 ++
> 2
On Sun, Jan 09, 2022 at 01:03:47AM +0100, David Heidelberg wrote:
> Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
>
> Other changes:
> - fixed reg-names numbering to match 0..3 instead 0,1,3,4
> - phy part moved into phy/ directory
>
> Signed-off-by: David Heidelberg
> ---
On Sat, Jan 08, 2022 at 08:00:58PM +0100, David Heidelberg wrote:
> Update documentation compatible and checking to comprehend
> both V2 and 6G version bindings.
>
> Following this commit, there will be update for
> compatible string in chipsets dtsi.
>
> Additional changes:
> - switch to
This will be useful to write tests that depends on these formats.
ARGB and XRGB follows the a similar implementation of the former formats.
Just adjusting for 16 bits per channel.
Signed-off-by: Igor Torrente
---
V3: Adapt the handlers to the new format introduced in patch 7 V3.
---
Adds this common format to vkms.
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
Signed-off-by: Igor Torrente
---
V3: Adapt the handlers to the
Add a helper function to validate the connector configuration receive in
the encoder atomic_check by the drivers.
So the drivers don't need do these common validations themselves.
Signed-off-by: Igor Torrente
---
V2: Move the format verification to a new helper at the drm_atomic_helper.c
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
possible inputs. It consists of 16 bits
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_composer`
struct.
This will allow us, in the future, to have different compositing and
Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.
Composer is the code that do the compositing of the planes.
This struct is contains information of the frame that is
being used in the output composition. Thus, vkms_frame_info
is a
The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.
If someday the maximum number of planes increases, this hardcoded value
can be a problem.
This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.
Signed-off-by: Igor Torrente
---
Currently, the memory to the composition frame is being allocated using
the kzmalloc. This comes with the limitation of maximum size of one
page size(which in the x86_64 is 4Kb and 4MB for default and hugepage
respectively).
Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when
`drm_mode_config_init` is deprecated since commit c3b790ea07a1 ("drm: Manage
drm_mode_config_init with drmm_") in favor of `drmm_mode_config_init`. Update
the former to the latter.
Signed-off-by: Igor Torrente
---
V2: Change the code style(Thomas Zimmermann).
V4: Update the commit
Summary
===
This series of patches refactor some vkms components in order to introduce
new formats to the planes and writeback connector.
Now in the blend function, the plane's pixels are converted to ARGB16161616
and then blended together.
The CRC is calculated based on the ARGB1616161616
https://bugzilla.kernel.org/show_bug.cgi?id=215511
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Fri, Jan 21, 2022 at 09:28:46AM +0200, Jani Nikula wrote:
> On Thu, 20 Jan 2022, Matthew Brost wrote:
> > Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
> > set, before CT write / read as this could result in a read across the
> > PCIe bus thus adding latency to every CT
Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
(and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
use dpu_hw_intf directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
the value is NULL, then the function will return 0 instead of a proper
return code. Moreover none of dpu_hw_*_init() functions can return NULL.
So, replace all dpu_rm_init()'s IS_ERR_OR_NULL() calls with IS_ERR().
Move handling of VBIF blocks into dpu_rm. This serves the purpose of
unification of handling of all hardware blocks inside the DPU driver.
This removes hand-coded loops in dpu_vbif (which look for necessary VBIF
instance by looping through the dpu_kms->hw_vbif and comparing
vbif_idx).
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
Then this allocation is passed to RM and then returned to then
dpu_encoder.
So allocate them outside of RM and use them directly.
Signed-off-by: Dmitry Baryshkov
Add missing calls to dpu_hw_dspp_destroy() to free resources allocated
for DSPP hardware blocks.
Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
dpu driver")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8
No code uses lm_max_width from resource manager, so drop it. Instead of
calculating the lm_max_width, code can use max_mixer_width field from
the hw catalog.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
Then this allocation is passed to RM and then returned to then
dpu_encoder. So allocate them outside of RM and use them directly.
While we are at it, drop the
On 07/01/2022 04:27, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-05 15:10:31)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index bf4d72356a12..2301ac114920 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++
[Public]
Applied. Thanks!
From: Wentland, Harry
Sent: Friday, January 21, 2022 2:03 PM
To: Yongzhi Liu ; Li, Sun peng (Leo) ;
Siqueira, Rodrigo ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch ; Lipski, Mikita ;
Applied. Thanks!
Alex
On Fri, Jan 21, 2022 at 6:48 AM Jiapeng Chong
wrote:
>
> Clean the following coccicheck warning:
>
> ./drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c:7035:2-4: WARNING: possible
> condition with no effect (if == else).
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng
On Fri, Jan 21, 2022 at 2:45 AM Christian König
wrote:
>
> Am 21.01.22 um 06:28 schrieb Xin Xiong:
> > This issue takes place in an error path in
> > amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into
> > default case, the function simply returns -EINVAL, forgetting to
> >
Quoting Dmitry Baryshkov (2022-01-20 23:37:45)
> On Fri, 21 Jan 2022 at 07:30, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> > > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > > b/drivers/gpu/drm/msm/msm_io_utils.c
> > > index 7b504617833a..5533c87c7158 100644
Fix request cancellation + add request cancel low level trace point.
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/i915: Add request cancel low level trace point
drm/i915/guc: Cancel requests immediately
drivers/gpu/drm/i915/gt/intel_context.h | 1 +
Change the preemption timeout to the smallest possible value (1 us) when
disabling scheduling to cancel a request and restore it after
cancelation. This not only cancels the request as fast as possible, it
fixes a bug where the preemption timeout is 0 which results in the
schedule disable hanging
Add request cancel trace point guarded by
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINT.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.h | 1 +
drivers/gpu/drm/i915/i915_trace.h | 10 ++
2 files changed, 11 insertions(+)
diff --git
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
Suggested-by:
On 2022-01-21 06:26, Yongzhi Liu wrote:
> [why]
> Resource release is needed on the error handling path
> to prevent memory leak.
>
> [how]
> Fix this by adding kfree on the error handling path.
>
> Signed-off-by: Yongzhi Liu
Reviewed-by: Harry Wentland
Harry
> ---
>
On 1/20/2022 20:31, Matthew Brost wrote:
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT rest when an engine reset failure is received to break
this circular dependency.
v2:
(John Harrison)
+ laurent on this
Hi Suraj
On 1/11/2022 2:17 AM, Kandpal, Suraj wrote:
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct
On Wed, Dec 29, 2021 at 10:19 PM Charles Stevens wrote:
>
>
> Hi All,
> I am working on a platform based on the Renesas RZ/G2 SoC family. This
> chip uses the rcar-du driver for the display. I would like to submit a patch
> to address the fact that the driver does not check/honor the
On Fri, Jan 21, 2022 at 01:54:29PM -0300, Luiz Sampaio wrote:
> The enum led_brightness, which contains the declaration of LED_OFF,
> LED_ON, LED_HALF and LED_FULL is obsolete, as the led class now supports
> max_brightness.
Reviewed-by: Daniel Thompson
BTW it looks like this patch might wants
Hi Jani
On 1/21/2022 1:17 AM, Jani Nikula wrote:
On Thu, 20 Jan 2022, Abhinav Kumar wrote:
Instead of creating an internal encoder for the writeback
connector to satisfy DRM requirements, allow the clients
to pass a real encoder to it by changing the drm_writeback's
encoder to a pointer.
If
On Thu, May 07, 2020 at 11:06:40AM +0200, Thomas Zimmermann wrote:
> Suspending failed because there's no mode if the CRTC is being
> disabled. Early-out in this case. This fixes runtime PM for ast.
>
> v3:
> * fixed commit message
> v2:
> * added Tested-by/Reported-by tags
> *
On 1/21/22 14:24, Alexander Stein wrote:
Am Freitag, 21. Januar 2022, 14:14:01 CET schrieb Marek Vasut:
On 1/21/22 14:12, Alexander Stein wrote:
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm:
Am Freitag, 21. Januar 2022, 14:14:01 CET schrieb Marek Vasut:
> On 1/21/22 14:12, Alexander Stein wrote:
> > Do not deference the NULL pointer if the bridge does not return a
> > bridge state. Assume a fixed format instead.
> >
> > Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the
On 1/21/22 14:12, Alexander Stein wrote:
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Alexander Stein
---
This can
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge
if present")
Signed-off-by: Alexander Stein
---
This can happen if a "ti,sn75lvds83", "lvds-encoder"
On 1/21/22 10:56, Alexander Stein wrote:
Use the dev_err_probe() helper, instead of open-coding the same
operation. This also adds a nice hint in
/sys/kernel/debug/devices_deferred.
Signed-off-by: Alexander Stein
Reviewed-by: Marek Vasut
Thanks
Hi Jagan,
On 21.01.2022 12:40, Jagan Teki wrote:
> On Fri, Jan 21, 2022 at 5:06 PM Marek Szyprowski
> wrote:
>> On 17.01.2022 09:42, Jagan Teki wrote:
>>> Updated series about drm bridge conversion of exynos dsi.
>>>
>>> Previous version can be accessible, here [1].
>>>
>>> Patch 1: connector
On 19/01/2022 11:37, Arunpravin wrote:
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver
On 19/01/2022 11:37, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation
Hi Matthias,
On 1/13/22 17:10, Matthias Brugger wrote:
> Hi Hans,
>
> On 13/01/2022 11:15, Hans Verkuil wrote:
>> On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
>>> Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
Il 12/11/21 11:55, Yong Wu ha scritto:
> After this
On 20/01/2022 16:44, Rob Clark wrote:
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter wrote:
On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but,
Clean the following coccicheck warning:
./drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c:7035:2-4: WARNING: possible
condition with no effect (if == else).
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 5 +
1 file changed, 1
Hi Marek,
On Fri, Jan 21, 2022 at 5:06 PM Marek Szyprowski
wrote:
>
> Hi,
>
> On 17.01.2022 09:42, Jagan Teki wrote:
> > Updated series about drm bridge conversion of exynos dsi.
> >
> > Previous version can be accessible, here [1].
> >
> > Patch 1: connector reset
> >
> > Patch 2: panel_bridge
Hi,
On 17.01.2022 09:42, Jagan Teki wrote:
> Updated series about drm bridge conversion of exynos dsi.
>
> Previous version can be accessible, here [1].
>
> Patch 1: connector reset
>
> Patch 2: panel_bridge API
>
> Patch 3: bridge conversion
>
> Patch 4: atomic functions
>
> Patch 5: DSI init in
Am 21.01.22 um 08:41 schrieb Thomas Hellström (Intel):
On 1/20/22 14:27, Christian König wrote:
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the
[why]
Resource release is needed on the error handling path
to prevent memory leak.
[how]
Fix this by adding kfree on the error handling path.
Signed-off-by: Yongzhi Liu
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 80 --
1 file changed, 60 insertions(+), 20
Am 21.01.22 um 08:31 schrieb Thomas Hellström:
On 1/20/22 14:27, Christian König wrote:
It's not allowed to nest another dma_fence container into a
dma_fence_array
or otherwise we can run into recursion.
Warn about that when we create a dma_fence_array.
Signed-off-by: Christian König
Hi Stepen,
On 1/20/22 04:18, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 15 Oct 2021 20:54:22 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (htmldocs)
>> produced this warning:
>>
>> Documentation/gpu/drm-kms-helpers:451:
>>
Hi Piotr,
On Wed, Jan 19, 2022 at 12:29:49PM +0100, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Sascha Hauer w dniu
> > 20.12.2021, o godz. 12:06:
> >
> >
> > Third round of patches and last one for this year. I hopefully integrated
> > all review feedback. Additionally the
On Fri, 21 Jan 2022, Helge Deller wrote:
> On 1/21/22 10:19, Lee Jones wrote:
> > On Fri, 21 Jan 2022, Jani Nikula wrote:
> >
> >> On Fri, 21 Jan 2022, Daniel Vetter wrote:
> >>> On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
> A first bunch of updates and fixes for the following
On Fri, 21 Jan 2022, Daniel Vetter wrote:
> On Fri, Jan 21, 2022 at 10:19 AM Lee Jones wrote:
> >
> > On Fri, 21 Jan 2022, Jani Nikula wrote:
> >
> > > On Fri, 21 Jan 2022, Daniel Vetter wrote:
> > > > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
> > > >> A first bunch of updates and
Use the dev_err_probe() helper, instead of open-coding the same
operation. This also adds a nice hint in
/sys/kernel/debug/devices_deferred.
Signed-off-by: Alexander Stein
---
Based on next-20220120
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
TE-gpio is optional and if it is not found then gpiod_get_optional()
returns NULL. In such case the code will continue and try to convert NULL
gpiod to irq what in turn fails. The failure is then propagated and driver
is not registered.
Fix this by returning early from
On 1/21/22 10:19, Lee Jones wrote:
> On Fri, 21 Jan 2022, Jani Nikula wrote:
>
>> On Fri, 21 Jan 2022, Daniel Vetter wrote:
>>> On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
A first bunch of updates and fixes for the following fbdev & backlight
drivers:
ocfb, aty128fb,
On Fri, Jan 21, 2022 at 10:19 AM Lee Jones wrote:
>
> On Fri, 21 Jan 2022, Jani Nikula wrote:
>
> > On Fri, 21 Jan 2022, Daniel Vetter wrote:
> > > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
> > >> A first bunch of updates and fixes for the following fbdev & backlight
> > >> drivers:
https://bugzilla.kernel.org/show_bug.cgi?id=215511
Bug ID: 215511
Summary: Dual monitor with amd 5700 causes system to hang at
startup.
Product: Drivers
Version: 2.5
Kernel Version: 5.16.1
Hardware: All
On Thu, 20 Jan 2022, Thomas Zimmermann wrote:
> DRM's DisplayPort helpers moved into the subdirectory dp/. Change
> the documentation accordingly.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper
> module")
> Reported-by: Jani
On Fri, 21 Jan 2022, Jani Nikula wrote:
> On Fri, 21 Jan 2022, Daniel Vetter wrote:
> > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
> >> A first bunch of updates and fixes for the following fbdev & backlight
> >> drivers:
> >> ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings,
On Thu, 20 Jan 2022, Abhinav Kumar wrote:
> Instead of creating an internal encoder for the writeback
> connector to satisfy DRM requirements, allow the clients
> to pass a real encoder to it by changing the drm_writeback's
> encoder to a pointer.
>
> If a real encoder is not passed,
On Fri, 21 Jan 2022, Daniel Vetter wrote:
> On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
>> A first bunch of updates and fixes for the following fbdev & backlight
>> drivers:
>> ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb,
>> lm3630a_bl, omap2, controlfb, matroxfb
On Fri, Jan 21, 2022 at 9:46 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > What I still don't understand: why are you so keen on maintaining an
> > interface that only serves the console? Nothing else uses fbdev these days.
> > Why not improve DRM/userspace to the point where it fits your requirements?
On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote:
>
> The following changes since commit 0c947b893d69231a9add855939da7c66237ab44f:
>
> Merge tag '5.17-rc-part1-smb3-fixes' of
> git://git.samba.org/sfrench/cifs-2.6 (2022-01-17 09:53:21 +0200)
>
> are available in the Git repository at:
>
>
Hi,
> What I still don't understand: why are you so keen on maintaining an
> interface that only serves the console? Nothing else uses fbdev these days.
> Why not improve DRM/userspace to the point where it fits your requirements?
> Long-term, the latter would make a lot more sense.
And note
1 - 100 of 108 matches
Mail list logo
