Am 30.07.24 um 19:36 schrieb Nikita Zhandarovich:
On 7/29/24 11:12, Christian König wrote:
Am 29.07.24 um 20:04 schrieb Christian König:
Am 29.07.24 um 19:26 schrieb Nikita Zhandarovich:
Hi,
On 7/29/24 02:23, Christian König wrote:
Am 26.07.24 um 14:52 schrieb Alex Deucher:
On Fri, Jul 26,
[+amd-glx, +lkml, +dri-devel]
On 27.07.24 18:52, serg.parti...@gmail.com wrote:
>
> After updating from 6.8.9 to 6.9.1 I noticed a bug on my HP Envy x360
> with AMD Ryzen 5 4500U.
>
> [...]
> After waking up from sleep brightness is set to max level, ignoring
> previous value.
>
> With the help
The current udmabuf_folio contains a list_head and the corresponding
folio pointer, with a size of 24 bytes. udmabuf_folio uses kmalloc to
allocate memory.
However, kmalloc is a public pool, starting from 64 bytes. This means
that each udmabuf_folio allocation will waste 40 bytes.
Considering tha
On 07/30/2024, Krzysztof Kozlowski wrote:
> On 30/07/2024 11:42, Liu Ying wrote:
>> On 07/30/2024, Krzysztof Kozlowski wrote:
>>> On 30/07/2024 08:55, Liu Ying wrote:
On 07/28/2024, Dmitry Baryshkov wrote:
> On Fri, Jul 12, 2024 at 05:32:34PM GMT, Liu Ying wrote:
>> i.MX8qxp Display Co
[Public]
Thanks for the help Kevin! It looks good to me.
Regards,
Wayne Lin
> -Original Message-
> From: Kevin Holm
> Sent: Wednesday, July 31, 2024 2:54 AM
> To: sta...@vger.kernel.org
> Cc: regressi...@lists.linux.dev; amd-...@lists.freedesktop.org; ML dri-devel
> ; LKML ; Lin,
> Wayn
The struct assertion is failed because sparse cannot parse
`#pragma pack(push, 1)` and `#pragma pack(pop)` correctly.
GCC's output is still 1-byte-aligned. No harm to memory layout.
The error can be filtered out by sparse-diff, but sometimes
multiple lines queezed into one, making the sparse-diff
The current udmabuf_folio contains a list_head and the corresponding
folio pointer, with a size of 24 bytes. udmabuf_folio uses kmalloc to
allocate memory.
However, kmalloc is a public pool, starting from 64 bytes. This means
that each udmabuf_folio allocation will waste 40 bytes.
Considering tha
On Wed, Jul 31, 2024 at 8:59 AM Andrew Morton wrote:
>
> On Mon, 29 Jul 2024 10:37:08 +0800 Yafang Shao wrote:
>
> > Is it appropriate for you to apply this to the mm tree?
>
> There are a couple of minor conflicts against current 6.11-rc1 which
> you'd best check. So please redo this against cu
在 2024/7/30 21:11, Christian König 写道:
Am 30.07.24 um 13:36 schrieb Huan Yang:
Either drop the whole approach or change udmabuf to do what you
want to do.
OK, if so, do I need to send a patch to make dma-buf support sendfile?
Well the udmabuf approach doesn't need to use sendfile, so no.
在 2024/7/31 1:19, T.J. Mercier 写道:
On Tue, Jul 30, 2024 at 1:14 AM Huan Yang wrote:
在 2024/7/30 16:03, Christian König 写道:
Am 30.07.24 um 09:57 schrieb Huan Yang:
Background
Some user may need load file into dma-buf, current way is:
1. allocate a dma-buf, get dma-buf fd
2. mma
On Tue, Jul 30, 2024 at 02:36:13PM -1000, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 30, 2024 at 05:31:17PM -0700, Matthew Brost wrote:
> > +#define alloc_ordered_workqueue_lockdep_map(fmt, flags, lockdep_map,
> > args...) \
> > + alloc_workqueue_lockdep_map(fmt, WQ_UNBOUND | __WQ_ORDERED |
On Mon, 29 Jul 2024 10:37:08 +0800 Yafang Shao wrote:
> Is it appropriate for you to apply this to the mm tree?
There are a couple of minor conflicts against current 6.11-rc1 which
you'd best check. So please redo this against current mainline?
Hello,
On Tue, Jul 30, 2024 at 05:31:17PM -0700, Matthew Brost wrote:
> +#define alloc_ordered_workqueue_lockdep_map(fmt, flags, lockdep_map,
> args...)\
> + alloc_workqueue_lockdep_map(fmt, WQ_UNBOUND | __WQ_ORDERED | (flags),
> 1, lockdep_map, ##args)
> +#endif
alloc_ordered_workq
Now that drm sched uses a single lockdep map for all submit_wq, drop the
GuC submit_wq pool hack.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_guc_submit.c | 60 +-
drivers/gpu/drm/xe/xe_guc_types.h | 7
2 files changed, 1 insertion(+), 66 deletions(-
Add an interface for a user-defined workqueue lockdep map, which is
helpful when multiple workqueues are created for the same purpose. This
also helps avoid leaking lockdep maps on each workqueue creation.
Implement a new internal workqueue flag, __WQ_USER_OWNED_LOCKDEP, to
indicate that the user
Will help enable user-defined lockdep maps for workqueues.
Cc: Tejun Heo
Cc: Lai Jiangshan
Signed-off-by: Matthew Brost
---
kernel/workqueue.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 3fba
Will help enable user-defined lockdep maps for workqueues.
Cc: Tejun Heo
Cc: Lai Jiangshan
Signed-off-by: Matthew Brost
---
kernel/workqueue.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c9bdd6a23a2b..b3fa4d
Avoid leaking a lockdep map on each drm sched creation and destruction
by using a single lockdep map for all drm sched allocated submit_wq.
v2:
- Use alloc_ordered_workqueue_lockdep_map (Tejun)
Cc: Luben Tuikov
Cc: Christian König
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sc
By default, each DRM scheduler instance creates an ordered workqueue for
submission, and each workqueue creation allocates a new lockdep map.
This becomes problematic when a DRM scheduler is created for every user
queue (e.g., in DRM drivers with firmware schedulers like Xe) due to the
limited numb
On 7/30/2024 4:34 PM, Dmitry Baryshkov wrote:
On Wed, 31 Jul 2024 at 01:27, Bjorn Andersson wrote:
On Tue, Jul 30, 2024 at 11:58:19PM +0300, Dmitry Baryshkov wrote:
Hi Abhinav,
On Tue, 30 Jul 2024 at 22:50, Abhinav Kumar wrote:
Hardware document indicates that widebus is recommended on
On Wed, 31 Jul 2024 at 01:27, Bjorn Andersson wrote:
>
> On Tue, Jul 30, 2024 at 11:58:19PM +0300, Dmitry Baryshkov wrote:
> > Hi Abhinav,
> >
> > On Tue, 30 Jul 2024 at 22:50, Abhinav Kumar
> > wrote:
> > >
> > > Hardware document indicates that widebus is recommended on DP on all
> > > MDSS ch
On Tue, Jul 30, 2024 at 12:56:17PM -1000, Tejun Heo wrote:
> On Tue, Jul 30, 2024 at 10:53:38PM +, Matthew Brost wrote:
> > I didn't want to change the export alloc_workqueue() arguments so I went
> > with this approach. Are you suggesting export a new function
> > alloc_workqueue_lockdep_map()
On Tue, Jul 30, 2024 at 10:53:38PM +, Matthew Brost wrote:
> I didn't want to change the export alloc_workqueue() arguments so I went
> with this approach. Are you suggesting export a new function
> alloc_workqueue_lockdep_map() which will share an internal
> implementation with the existing al
On Tue, Jul 30, 2024 at 12:34:08PM -1000, Tejun Heo wrote:
> Hello, Matthew.
>
> On Tue, Jul 30, 2024 at 03:17:40PM -0700, Matthew Brost wrote:
> > +/**
> > + * wq_init_user_lockdep_map - init user lockdep map for workqueue
> > + * @wq: workqueue to init lockdep map for
> > + * @lockdep_map: lockd
Hi Dave and Sima,
Early drm-xe-next pull request for 6.12. Main reason for being much
earlier than usual is to have the additional SIMD16 EU reported as it's
a needed UAPI for Lunar Lake and Battlemage. It's sitting in drm-xe-next
for a few weeks and userspace already testing with it.
There's al
Hello, Matthew.
On Tue, Jul 30, 2024 at 03:17:40PM -0700, Matthew Brost wrote:
> +/**
> + * wq_init_user_lockdep_map - init user lockdep map for workqueue
> + * @wq: workqueue to init lockdep map for
> + * @lockdep_map: lockdep map to use for workqueue
> + *
> + * Initialize workqueue with a user
On Tue, Jul 30, 2024 at 11:58:19PM +0300, Dmitry Baryshkov wrote:
> Hi Abhinav,
>
> On Tue, 30 Jul 2024 at 22:50, Abhinav Kumar wrote:
> >
> > Hardware document indicates that widebus is recommended on DP on all
> > MDSS chipsets starting version 5.x.x and above.
> >
> > Follow the guideline and
Avoid leaking a lockdep map on each drm sched creation and destruction
by using a single lockdep map for all drm sched allocated submit_wq.
Cc: Luben Tuikov
Cc: Christian König
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/scheduler/sched_main.c | 12 +++-
1 file changed, 11 inserti
Now that drm sched uses a single lockdep map for all submit_wq, drop the
GuC submit_wq pool hack.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_guc_submit.c | 60 +-
drivers/gpu/drm/xe/xe_guc_types.h | 7
2 files changed, 1 insertion(+), 66 deletions(-
Add an interface for a user-defined workqueue lockdep map, which is
helpful when multiple workqueues are created for the same purpose. This
also helps avoid leaking lockdep maps on each workqueue creation.
Implement a new workqueue flag, WQ_USER_OWNED_LOCKDEP, to indicate that
the user will set up
By default, each DRM scheduler instance creates an ordered workqueue for
submission, and each workqueue creation allocates a new lockdep map.
This becomes problematic when a DRM scheduler is created for every user
queue (e.g., in DRM drivers with firmware schedulers like Xe) due to the
limited numb
Hello Laurent Pinchart,
Commit 3cbd0c587b12 ("drm/omap: gem: Replace struct_mutex usage with
omap_obj private lock") from May 26, 2018 (linux-next), leads to the
following Smatch static checker warning:
drivers/gpu/drm/omapdrm/omap_gem.c:1435 omap_gem_new_dmabuf()
warn: 'omap_obj'
On Mon, Jul 29, 2024 at 02:54:58PM GMT, Ashutosh Dixit wrote:
On Mon, 29 Jul 2024 06:21:20 -0700, Lucas De Marchi wrote:
Hi Lucas,
Reviewed-by: Lucas De Marchi
That fixes the build, but question to Ashutosh: it's odd to tie the
format to a bspec. What happens on next platform if the HW ch
Hi Abhinav,
On Tue, 30 Jul 2024 at 22:50, Abhinav Kumar wrote:
>
> Hardware document indicates that widebus is recommended on DP on all
> MDSS chipsets starting version 5.x.x and above.
>
> Follow the guideline and mark widebus support on all relevant
> chipsets for DP.
>
> Fixes: 766f705204a0 ("
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT A
On Fri, 2024-07-05 at 11:38 +0200, Christoph Fritz wrote:
> Enable the transmission of an EoTp (end of transmission packet) by
> default. EoTp should be enabled anyway because it is a Linux
> necessity
> that can be disabled by a dsi mod_flag if needed.
>
> EoTp signals the end of an HS transmissi
On 7/13/2024 3:55 PM, Dmitry Baryshkov wrote:
On Thu, Jul 11, 2024 at 03:48:50PM GMT, Abhinav Kumar wrote:
Hardware document indicates that widebus is recommended on DP on all
MDSS chipsets starting version 5.x.x and above.
Follow the guideline and mark widebus support on all relevant
chipse
Hardware document indicates that widebus is recommended on DP on all
MDSS chipsets starting version 5.x.x and above.
Follow the guideline and mark widebus support on all relevant
chipsets for DP.
Fixes: 766f705204a0 ("drm/msm/dp: Remove now unused connector_type from desc")
Fixes: 1b2d98bdd7b7 ("
From: Wayne Lin
[ Upstream commit fa57924c76d995e87ca3533ec60d1d5e55769a27 ]
[Why]
dm_dp_mst_is_port_support_mode() is a bit not following the original design
rule and cause
light up issue with multiple 4k monitors after mst dsc hub.
[How]
Refactor function dm_dp_mst_is_port_support_mode() a b
Hello everyone,
Hello, my name is Priyansu Rout I am from India. I am right now in my
second year of B. Tech in Computer Science and Engineering. I have been
developing in blockchain projects and now I would like to get experience in
X. Org, especially on the kernel level.
I am very much interest
>> …
>>> +++ b/drivers/gpu/drm/loongson/loongson_drv.h
>>> @@ -0,0 +1,108 @@
>> …
>>> +#ifndef __LOONGSON_DRV_H__
>>> +#define __LOONGSON_DRV_H__
>> …
>>
>> I suggest to omit leading underscores from such identifiers.
…
> I suggest add this rules to the checkpatch.pl script,
…
I hope that you woul
On 7/29/2024 1:08 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2024-07-29 11:28:35)
Thanks for the feedback.
Your change looks valid. We can use this and drop the max_t usage.
Let me push this with your Suggested-by credits.
You can take my
Signed-off-by: Stephen Boyd
and either squ
Hi,
On 2024/7/29 15:15, Markus Elfring wrote:
…
the driver is loaded, drm/loongson driver still need to wait all of
needs to wait on …?
…
design. Therefore, add a dummy driver for the GPU, …
Is there a need to reconsider the categorisation
Fix the dp_panel_get_supported_bpp() API to return the minimum
supported bpp correctly for relevant cases and use this API
to correct the behavior of DP driver which hard-codes the max supported
bpp to 30.
This is incorrect because the number of lanes and max data rate
supported by the lanes need
Hi,
On 2024/7/29 14:40, Markus Elfring wrote:
…
+++ b/drivers/gpu/drm/loongson/loongson_drv.h
@@ -0,0 +1,108 @@
…
+#ifndef __LOONGSON_DRV_H__
+#define __LOONGSON_DRV_H__
…
I suggest to omit leading underscores from such identifiers.
https://wiki.sei.cmu.edu/confluence/display/c/DCL37-C.+Do
Hi,
On 2024/7/29 15:37, Markus Elfring wrote:
…
+++ b/drivers/gpu/drm/loongson/loongson_drv.c
@@ -0,0 +1,298 @@
…
+static int loongson_drm_driver_probe(struct platform_device *pdev)
+{
…
+ dev_info(&pdev->dev, "probed\n");
…
+}
…
Do you find such information really relevant?
T
On 7/29/24 11:12, Christian König wrote:
> Am 29.07.24 um 20:04 schrieb Christian König:
>> Am 29.07.24 um 19:26 schrieb Nikita Zhandarovich:
>>> Hi,
>>>
>>> On 7/29/24 02:23, Christian König wrote:
Am 26.07.24 um 14:52 schrieb Alex Deucher:
> On Fri, Jul 26, 2024 at 3:05 AM Christian K
6.10-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc upstream.
DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be sp
On Tue, Jul 30, 2024 at 1:14 AM Huan Yang wrote:
>
>
> 在 2024/7/30 16:03, Christian König 写道:
> > Am 30.07.24 um 09:57 schrieb Huan Yang:
> >> Background
> >>
> >> Some user may need load file into dma-buf, current way is:
> >>1. allocate a dma-buf, get dma-buf fd
> >>2. mmap dma-buf
6.10-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 5207c393d3e7dda9aff813d6b3e2264370d241be upstream.
The caching mode for buffer objects with VRAM as a possible
placement was forced to write-combined, regardless of pla
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc upstream.
DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be spe
On Tue, 30 Jul 2024 02:26:05 +, Mina Almasry wrote:
> Add netdev_rx_queue_restart() function to netdev_rx_queue.h
Can you say more? As far as I understand, we just release the buffer
submitted to the rx ring and get a new page pool.
But I personally feel that the interface here is a bit too
Le lundi 29 juillet 2024 à 04:16 +0200, Marek Vasut a écrit :
> On 7/24/24 6:08 PM, Nicolas Dufresne wrote:
> > Hi Marek,
>
> Hi,
>
> > Le mercredi 24 juillet 2024 à 02:19 +0200, Marek Vasut a écrit :
> > > Introduce dedicated memory-to-memory IPUv3 VDI deinterlacer driver.
> > > Currently the IP
With -Werror:
In function ‘r100_cp_init_microcode’,
inlined from ‘r100_cp_init’ at drivers/gpu/drm/radeon/r100.c:1136:7:
include/linux/printk.h:465:44: error: ‘%s’ directive argument is null
[-Werror=format-overflow=]
465 | #define printk(fmt, ...) printk_index_wrap(_printk,
TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
Like the TFP410, the TDP158 can be set up in 2 different ways:
1) hard-coding its configuration settings using pin-strapping resistors
2) placing it on an I2C bus, and defer set-up until run-time
The mode is selected by pin 8 = I
TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
It supports DVI 1.0, HDMI 1.4b and 2.0b.
It supports 4 TMDS channels, HPD, and a DDC interface.
It supports dual power supply rails (1.1V on VDD, 3.3V on VCC)
for power reduction. Several methods of power management are
implemented
TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
It supports DVI 1.0, HDMI 1.4b and 2.0b.
It supports 4 TMDS channels, HPD, and a DDC interface.
It supports dual power supply rails (1.1V on VDD, 3.3V on VCC)
for power reduction. Several methods of power management are
implemented
On Sun, 28 Jul 2024 13:41:52 +0200, Stefan Wahren wrote:
> Add suspend/resume support for the VC4 HDMI component in order
> to handle suspend to idle properly. Since the HDMI power domain
> is powered down during suspend, this makes connector status polling
> pointless.
>
>
> [ ... ]
Acked-by: M
On Sun, 28 Jul 2024 13:41:50 +0200, Stefan Wahren wrote:
> The commit 0f5251339eda ("drm/vc4: hdmi: Make sure the controller is
> powered in detect") introduced the necessary power management handling
> to avoid register access while controller is powered down.
> Unfortunately it just print a warni
Am 30.07.24 um 13:36 schrieb Huan Yang:
Either drop the whole approach or change udmabuf to do what you
want to do.
OK, if so, do I need to send a patch to make dma-buf support sendfile?
Well the udmabuf approach doesn't need to use sendfile, so no.
Get it, I'll not send again.
About udmabu
Comment in suspend says TOP is put in suspend, but the register
poke following is actually de-asserting the reset, like in init.
It is doing the opposite of what the comment says.
Align the comment with what the code is doing for now and add
a FIXME note to sort this out later
Signed-off-by: Jer
Poking the HHI syscon is a way to setup clocks behind CCF's back.
Drop these poke and let CCF handle this using DT assigned-clocks.
HHI is a collection of Amlogic devices, such as clocks, reset,
power domains and phys.
This is another step to get rid of HHI access in Amlogic display drivers
and p
This prepares the migration to regmap usage.
To properly setup regmap, the APB needs to be in working order.
This is easier handled if the resets are not mixed with hw init.
More checks are required to determine if the resets are needed
on resume or not. Add a note for this.
Signed-off-by: Jerom
The Amlogic mixes direct register access and regmap ones, with several
custom helpers. Using a single API makes rework and maintenance easier.
Convert the Amlogic phy driver to regmap and use it to have more consistent
access to the registers in the driver, with less custom helpers. Add
register b
The HDMI phy has a power domain properly set in DT.
Writing the power controller register directly from the hdmi driver is
incorrect. The power domain framework should be used for that.
HHI is a collection of Amlogic devices, such as clocks, reset,
power domains and phys.
This is another step to
Using several string comparisons with if/else if/else clauses
is fairly inefficient and does not scale well.
Use matched data to tweak the driver depending on the matched
SoC instead.
Signed-off-by: Jerome Brunet
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 209 +-
1 file
Poking the HHI syscon is a way to setup clocks behind CCF's back.
Also, 2 drm code paths, the encoder and the hdmi-phy, are racing to do the
same setup of the HDMI system clock.
This clock is used is used by the HDMI phy and should not be set by the
encoder, so drop those HHI pokes from vclk.
Sig
The Amlogic HDMI phy driver is not doing anything with the clocks
besides enabling on probe. CCF provides generic helpers to do that.
Use the generic clock helpers rather than using a custom one to get and
enable clocks.
Signed-off-by: Jerome Brunet
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 3
This relocates register pokes of the HDMI VPU encoder out of the
HDMI phy driver. As far as HDMI is concerned, the sequence in which
the setup is done remains mostly the same.
This was tested with modetest, cycling through the following resolutions:
#0 3840x2160 60.00
#1 3840x2160 59.94
#2 3
This patchset is a clean up of the Amlogic HDMI phy driver.
It is part of an effort to remove the use HHI syscon from the driver
and properly use frameworks, such as PD and clocks, instead of going
for an incorrectly global register region.
When this is done, it should be easier to remove the usa
On Mon, 29 Jul 2024, Nikita Zhandarovich wrote:
> On the off chance that clock value ends up being too high (by means
> of skl_ddi_calculate_wrpll() having benn called with big enough
> value of crtc_state->port_clock * 1000), one possible consequence
> may be that the result will not be able to f
Am 30.07.24 um 10:36 schrieb Daniel Vetter:
In the end you have a really nice circle dependency.
Maybe a follow up, so for arb robustness or vk context where we want the
context to die and refuse to accept any more jobs: We can get at that
error somehow? I think that's really the only worry I ha
在 2024/7/30 17:05, Huan Yang 写道:
在 2024/7/30 16:56, Daniel Vetter 写道:
[? daniel.vet...@ffwll.ch ?
https://aka.ms/LearnAboutSenderIdentification?]
On Tue, Jul 30, 2024 at 03:57:44PM +0800, Huan Yang wrote:
UDMA-BUF step:
1. memfd_create
2. open file(buffer/
On 7/28/24 08:41, Stefan Wahren wrote:
The commit 0f5251339eda ("drm/vc4: hdmi: Make sure the controller is
powered in detect") introduced the necessary power management handling
to avoid register access while controller is powered down.
Unfortunately it just print a warning if pm_runtime_resume_
在 2024/7/30 18:43, Christian König 写道:
Am 30.07.24 um 10:46 schrieb Huan Yang:
在 2024/7/30 16:37, Christian König 写道:
Am 30.07.24 um 10:14 schrieb Huan Yang:
在 2024/7/30 16:03, Christian König 写道:
Am 30.07.24 um 09:57 schrieb Huan Yang:
Background
Some user may need load file into dm
On Mon, Jul 1, 2024 at 8:20 PM Dmitry Baryshkov
wrote:
>
> There are no in-kernel DTs that use Lontium LT9611UXC bridge and still
> require creation of the drm_connector by the bridge on attachment.
> Drop support for !DRM_BRIDGE_ATTACH_NO_CONNECTOR by the driver.
>
> Signed-off-by: Dmitry Baryshk
在 2024/7/30 18:42, Christian König 写道:
Am 30.07.24 um 11:05 schrieb Huan Yang:
在 2024/7/30 16:56, Daniel Vetter 写道:
[? daniel.vet...@ffwll.ch ?
https://aka.ms/LearnAboutSenderIdentification?]
On Tue, Jul 30, 2024 at 03:57:44PM +0800, Huan Yang wrote:
UDMA-BUF s
On 7/28/24 10:00, Stefan Wahren wrote:
Common pattern of handling deferred probe can be simplified with
dev_err_probe() and devm_clk_get_optional(). This results in much
less code.
Signed-off-by: Stefan Wahren
---
drivers/gpu/drm/vc4/vc4_v3d.c | 13 ++---
1 file changed, 2 insertions
On 7/28/24 08:41, Stefan Wahren wrote:
DRM_ERROR() has been deprecated in favor of pr_err(). However, we
should prefer to use drm_err() whenever possible so we get device-
specific output with the error message. In error case of kcalloc,
we can simply drop DRM_ERROR(), because kcalloc already log
On Fri, 26 Jul 2024, Imre Deak wrote:
> Hi all,
>
> On Mon, Jul 22, 2024 at 01:19:52PM -0400, Lyude Paul wrote:
>> For patches 1-3:
>>
>> Reviewed-by: Lyude Paul
>>
>> Thanks!
>
> Thanks Lyude for the review.
>
> Thomas, Maxim, Maarten, could you ack merging these 3 DRM core patches
> through t
Hi Piotr,
On 7/30/24 05:20, Piotr Zalewski wrote:
Hi Andy
On Monday, July 29th, 2024 at 4:35 AM, Andy Yan wrote:
+
+static void vop2_crtc_gamma_set(struct vop2 *vop2, struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct drm_crtc_state *state = crtc->state;
+ struct vop2_vid
Am 30.07.24 um 10:46 schrieb Huan Yang:
在 2024/7/30 16:37, Christian König 写道:
Am 30.07.24 um 10:14 schrieb Huan Yang:
在 2024/7/30 16:03, Christian König 写道:
Am 30.07.24 um 09:57 schrieb Huan Yang:
Background
Some user may need load file into dma-buf, current way is:
1. allocate a dm
Am 30.07.24 um 11:05 schrieb Huan Yang:
在 2024/7/30 16:56, Daniel Vetter 写道:
[? daniel.vet...@ffwll.ch ?
https://aka.ms/LearnAboutSenderIdentification?]
On Tue, Jul 30, 2024 at 03:57:44PM +0800, Huan Yang wrote:
UDMA-BUF step:
1. memfd_create
2. open file(bu
On Tue, Jul 30, 2024 at 11:30:01AM GMT, Maxime Ripard wrote:
> On Tue, Jul 30, 2024 at 11:46:24AM GMT, Dmitry Baryshkov wrote:
> > On Tue, 30 Jul 2024 at 11:27, Maxime Ripard wrote:
> > >
> > > On Wed, Jul 24, 2024 at 07:59:21PM GMT, Marc Gonzalez wrote:
> > > > On 15/07/2024 16:40, Maxime Ripard
This is a note to let you know that I've just added the patch titled
drm/udl: Remove DRM_CONNECTOR_POLL_HPD
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-udl-remove-d
This is a note to let you know that I've just added the patch titled
drm/udl: Remove DRM_CONNECTOR_POLL_HPD
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-udl-remove-
On 30/07/2024 11:42, Liu Ying wrote:
> On 07/30/2024, Krzysztof Kozlowski wrote:
>> On 30/07/2024 08:55, Liu Ying wrote:
>>> On 07/28/2024, Dmitry Baryshkov wrote:
On Fri, Jul 12, 2024 at 05:32:34PM GMT, Liu Ying wrote:
> i.MX8qxp Display Controller pixel engine consists of all processing
Hi all,
On Mon, 15 Jul 2024 14:13:37 +0200 Maarten Lankhorst
wrote:
>
> Den 2024-07-15 kl. 06:21, skrev Golani, Mitulkumar Ajitkumar:
> >
> > On 15-07-2024 04:42, Stephen Rothwell wrote:
> >>
> >> On Wed, 12 Jun 2024 14:11:10 +1000 Stephen Rothwell
> >> wrote:
> >>> After merging the drm-i
This is a note to let you know that I've just added the patch titled
drm/udl: Remove DRM_CONNECTOR_POLL_HPD
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-udl-remove-d
On 30/07/2024 11:30, Maxime Ripard wrote:
> On Tue, Jul 30, 2024 at 11:46:24AM GMT, Dmitry Baryshkov wrote:
>> On Tue, 30 Jul 2024 at 11:27, Maxime Ripard wrote:
>>> On Wed, Jul 24, 2024 at 07:59:21PM GMT, Marc Gonzalez wrote:
On 15/07/2024 16:40, Maxime Ripard wrote:
> On Thu, Jul 04, 20
On 07/30/2024, Krzysztof Kozlowski wrote:
> On 30/07/2024 08:55, Liu Ying wrote:
>> On 07/28/2024, Dmitry Baryshkov wrote:
>>> On Fri, Jul 12, 2024 at 05:32:34PM GMT, Liu Ying wrote:
i.MX8qxp Display Controller pixel engine consists of all processing
units that operate in the AXI bus cloc
On Tue, Jul 30, 2024 at 11:46:24AM GMT, Dmitry Baryshkov wrote:
> On Tue, 30 Jul 2024 at 11:27, Maxime Ripard wrote:
> >
> > On Wed, Jul 24, 2024 at 07:59:21PM GMT, Marc Gonzalez wrote:
> > > On 15/07/2024 16:40, Maxime Ripard wrote:
> > > > On Thu, Jul 04, 2024 at 07:04:41PM GMT, Marc Gonzalez wr
[Public]
Thanks, Greg.
Will do.
Regards,
Wayne Lin
> -Original Message-
> From: Greg KH
> Sent: Tuesday, July 30, 2024 2:21 PM
> To: Lin, Wayne
> Cc: ke...@holm.dev; Linux regressions mailing list
> ; Deucher, Alexander
> ; Wu, Hersen ;
> sta...@vger.kernel.org; LKML ; ML dri-devel
> ;
在 2024/7/30 16:56, Daniel Vetter 写道:
[? daniel.vet...@ffwll.ch ?
https://aka.ms/LearnAboutSenderIdentification?]
On Tue, Jul 30, 2024 at 03:57:44PM +0800, Huan Yang wrote:
UDMA-BUF step:
1. memfd_create
2. open file(buffer/direct)
3. udmabuf create
4.
On Tue, Jul 30, 2024 at 03:57:44PM +0800, Huan Yang wrote:
> UDMA-BUF step:
> 1. memfd_create
> 2. open file(buffer/direct)
> 3. udmabuf create
> 4. mmap memfd
> 5. read file into memfd vaddr
Yeah this is really slow and the worst way to do it. You absolutely want
to start _all_ the io b
I merged this patch into drm-misc-fixes.
Am 17.07.24 um 16:24 schrieb Thomas Zimmermann:
Power up the ASTDP connector for connection status detection if the
connector is not active. Keep it powered if a display is attached.
This fixes a bug where the connector does not come back after
disconnec
On Tue, 30 Jul 2024 at 11:27, Maxime Ripard wrote:
>
> On Wed, Jul 24, 2024 at 07:59:21PM GMT, Marc Gonzalez wrote:
> > On 15/07/2024 16:40, Maxime Ripard wrote:
> > > On Thu, Jul 04, 2024 at 07:04:41PM GMT, Marc Gonzalez wrote:
> > >> On 01/07/2024 15:50, Maxime Ripard wrote:
> > >>
> > >>> The i
在 2024/7/30 16:37, Christian König 写道:
Am 30.07.24 um 10:14 schrieb Huan Yang:
在 2024/7/30 16:03, Christian König 写道:
Am 30.07.24 um 09:57 schrieb Huan Yang:
Background
Some user may need load file into dma-buf, current way is:
1. allocate a dma-buf, get dma-buf fd
2. mmap dma-buf
On Wed, Jul 24, 2024 at 07:28:41PM GMT, Marc Gonzalez wrote:
> On 24/07/2024 19:25, Dmitry Baryshkov wrote:
> > On Wed, Jul 24, 2024 at 07:18:39PM GMT, Marc Gonzalez wrote:
> >> On 15/07/2024 16:42, Maxime Ripard wrote:
> >>> On Mon, Jul 08, 2024 at 11:29:46PM GMT, Dmitry Baryshkov wrote:
> On
On 07/28/2024, Dmitry Baryshkov wrote:
> On Wed, Jul 24, 2024 at 05:29:31PM GMT, Liu Ying wrote:
>> Hi,
>>
>> This patch series aims to add Freescale i.MX8qxp Display Controller support.
>>
>> The controller is comprised of three main components that include a blit
>> engine for 2D graphics acceler
1 - 100 of 126 matches
Mail list logo
