On Wed, 2021-11-10 at 14:06 +0100, Guillaume Ranquet wrote:
> From: Markus Schneider-Pargmann
>
> This is a new driver that supports the integrated DisplayPort phy for
> mediatek SoCs, especially the mt8195. The phy is integrated into the
> DisplayPort controller and will be created by the
Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with
offset and len.
Change-Id: I03d2d2e10e48d32aa83c31abade57e0931e1be49
Signed-off-by: Jianqun Xu
---
drivers/dma-buf/dma-buf.c| 42
include/uapi/linux/dma-buf.h | 8 +++
2 files
Applied. Thanks!
Alex
On Fri, Nov 12, 2021 at 1:17 AM wrote:
>
> From: Ye Guojin
>
> This was found by coccicheck:
> ./drivers/gpu/drm/amd/display/dc/core/dc_resource.c, 2516, 7-9, WARNING
> possible condition with no effect (if == else)
>
> hdmi_info.bits.YQ0_YQ1 is always
On 11/6/2021 9:25 AM, Bjorn Andersson wrote:
On Fri 05 Nov 16:22 CDT 2021, Kuogee Hsieh wrote:
Currently the msm_dp_*** functions implement the same sequence which would
happen when drm_bridge is used. hence get rid of this intermediate layer
and align with the drm_bridge usage to avoid
Applied. Thanks!
Alex
On Thu, Nov 11, 2021 at 5:09 AM Christian König
wrote:
>
>
>
> Am 11.11.21 um 11:03 schrieb Jiapeng Chong:
> > Eliminate the follow smatch warning:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:622
> > dmub_srv_cmd_execute() warn: inconsistent
Applied. Thanks!
On Wed, Nov 10, 2021 at 10:54 PM hongao wrote:
>
> amdgpu_connector_vga_get_modes missed function amdgpu_get_native_mode
> which assign amdgpu_encoder->native_mode with *preferred_mode result in
> amdgpu_encoder->native_mode.clock always be 0. That will cause
>
Acked-by: Lyude Paul
On Wed, 2021-11-10 at 14:31 +0100, Karol Herbst wrote:
> Some side notes on this. Atm we do want to use gitlab for bug tracking and
> merge requests. But due to the nature of the current linux kernel
> development, we can only do so for nouveau internal changes.
>
>
On Thu, Nov 04, 2021 at 11:04:29PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
>
While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.
On 2021-11-12 13:35:03, Marijn Suijten wrote:
> On 2021-11-12 12:08:39, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> > > When not specifying num-strings in the DT the default is used, but +1 is
> > > added to it which turns WLED3 into 4 and WLED4/5
On 10/21/21 11:15, Lucas De Marchi wrote:
Last user of PAGE_KERNEL_IO is the i915 driver. While removing it from
there as we seek to bring the driver to other architectures, Daniel
suggested that we could finish the cleanup and remove it altogether,
through the tip tree. So here I'm sending both
On Thu, Nov 11, 2021 at 06:52:22PM -0800, Umesh Nerlige Ramappa wrote:
> Irrespective of the backend for request submissions, busyness for an
> engine with an active context is calculated using:
>
> busyness = total + (current_time - context_switch_in_time)
>
> In execlists mode of operation,
12.11.2021 23:26, Lyude Paul пишет:
>> BTW, I see now that DPAUX I2C transfer helper may access
>> aux->drm_device. Hence v1 patch isn't correct anyways.
>
> JFYI - unless I'm misunderstanding you, the aux->drm_dev accesses in the DPAUX
> i2c transfer functions are just from the various
The pull request you sent on Fri, 12 Nov 2021 13:25:30 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-11-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/304ac8032d3fa2d37750969cd4b8d5736a1829d9
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 2021-11-12 at 17:32 +0300, Dmitry Osipenko wrote:
> 12.11.2021 13:52, Thierry Reding пишет:
> > On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
> > > 09.11.2021 17:17, Dmitry Osipenko пишет:
> > > > 09.11.2021 17:08, Dmitry Osipenko пишет:
> > > > > > +static void
On 11/12/21 12:09 PM, Lucas De Marchi wrote:
> The intention was to merge this through the tip tree. Although now I'm
> not sure. Options:
>
> 1) take the first patch through the drm-intel tree and apply the
> second patch later
> 2) take everything through the drm tree
> 3)
On Thu, Nov 11, 2021 at 7:25 PM Dave Airlie wrote:
>
> I missed a drm-misc-next pull for the main pull last week. It wasn't
> that major and isn't the bulk of this at all. This has a bunch of
> fixes all over, a lot for amdgpu and i915.
Ugh.
The i915 conflict was trivial, but made me aware of
On Fri, Nov 12, 2021 at 08:04:03PM +0100, Peter Zijlstra wrote:
On Thu, Oct 21, 2021 at 11:15:09AM -0700, Lucas De Marchi wrote:
Last user of PAGE_KERNEL_IO is the i915 driver. While removing it from
there as we seek to bring the driver to other architectures, Daniel
suggested that we could
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Antoni (56turtl...@gmail.com) changed:
What|Removed |Added
CC||56turtl...@gmail.com
---
On Thu, Oct 21, 2021 at 11:15:09AM -0700, Lucas De Marchi wrote:
> Last user of PAGE_KERNEL_IO is the i915 driver. While removing it from
> there as we seek to bring the driver to other architectures, Daniel
> suggested that we could finish the cleanup and remove it altogether,
> through the tip
On Fri, Nov 12, 2021 at 02:13:50PM +, Tvrtko Ursulin wrote:
>
> On 11/11/2021 16:49, Matthew Brost wrote:
> > On Mon, Nov 01, 2021 at 10:35:09AM +, Tvrtko Ursulin wrote:
> > >
> > > On 27/10/2021 21:10, Matthew Brost wrote:
> > > > On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison
On Fri, 12 Nov 2021 12:32:23 -0500
Jason Baron wrote:
> Ok, it looks like Vincent's patch defines a dyndbg event and then uses
> 'trace_dyndbg()' to output to the 'main' log. So all dynamic output to
> the 'main' ftrace buffer goes through that event if I understand it
> correctly. Here's a
[ Resending since my previous reply didn't reach the mailing lists. ]
On 11/11/21 5:55 AM, Jakub Kicinski wrote:
> On Wed, 10 Nov 2021 21:19:53 -0800 Joe Perches wrote:
>> On Wed, 2021-11-10 at 17:39 -0800, Jakub Kicinski wrote:
>>> On Wed, 10 Nov 2021 12:09:06 -0800 Srivatsa S. Bhat wrote:
On 11/12/21 12:07 PM, Steven Rostedt wrote:
> On Fri, 12 Nov 2021 10:08:41 -0500
> Jason Baron wrote:
>
>>> A key difference between that patchset and this patch (besides that
>>> small fact that I used +x instead of +T) was that my patchset allowed
>>> the dyndbg trace to be emitted to the
On Fri, 12 Nov 2021 10:08:41 -0500
Jason Baron wrote:
> > A key difference between that patchset and this patch (besides that
> > small fact that I used +x instead of +T) was that my patchset allowed
> > the dyndbg trace to be emitted to the main buffer and did not force them
> > to be in an
On Thu, Nov 11, 2021 at 12:39:28PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 11, 2021 at 12:11:20PM +0100, Javier Martinez Canillas wrote:
> > The efifb and simplefb drivers just render to a pre-allocated frame buffer
> > and rely on the display hardware being initialized before the kernel
On 2021-11-12 16:03, Christian König wrote:
> Am 12.11.21 um 15:30 schrieb Michel Dänzer:
>> On 2021-11-12 15:29, Michel Dänzer wrote:
>>> On 2021-11-12 13:47, Christian König wrote:
Anyway this unfortunately turned out to be work for Harray and Nicholas.
In detail it's about this bug
On Thu, 11 Nov 2021 23:10:16 -0800, Vinay Belgaumkar wrote:
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index 4e1d3cd29164..22c1c12369f2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++
On Thu, Nov 11, 2021 at 12:36:47PM +0100, Christian König wrote:
> Am 01.11.21 um 10:41 schrieb Tvrtko Ursulin:
> >
> > On 28/10/2021 16:30, Daniel Vetter wrote:
> > > On Thu, Oct 28, 2021 at 10:41:38AM +0200, Christian König wrote:
> > > > Am 21.10.21 um 13:13 schrieb Tvrtko Ursulin:
> > > > >
Pre-HSW platforms don't use the gt SSEU structures; this means that
calling intel_sseu_get_subslices() on slice 0 for these platforms will
trip a GEM_BUG_ON(slice >= sseu->max_slices) warning.
Let's move the DSS lookup for a DG2 workaround into a helper function
that will only get called after
On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
>> Sean Paul proposed, in:
>> https://urldefense.com/v3/__https://patchwork.freedesktop.org/series/78133/__;!!GjvTz_vk!HcKnMRByYkIdyF1apqQjlN5aBIomzJR1an3YWXM6KXs0EftVMQdrewRA8Dki4A$
>>
On 11/11/2021 13:06, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Trying to capture uninitialised engines when we wedged on init ends in
tears. Skip that together with uC capture, since failure to initialise the
latter can actually be one of the reasons for wedging on init.
v2:
* Use
Hi Paul
Am 12.11.21 um 16:26 schrieb Paul Cercueil:
Hi Thomas,
I never received the original patch and I can't find it online either?
It was posted a while ago [1] and got lost. I remember that you had a
problem with your email setup. Maybe that's why you didn't see it.
Anyway:
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then we need to be mindful of having to
restart
From: Maarten Lankhorst
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c
From: Maarten Lankhorst
This allows us to finally get rid of all the assumptions that vma->obj
is NULL.
Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew
Hi Thomas,
I never received the original patch and I can't find it online either?
Anyway:
Acked-by: Paul Cercueil
Cheers,
-Paul
Le ven., nov. 12 2021 at 16:05:47 +0100, Thomas Zimmermann
a écrit :
Ping for review.
Am 08.07.21 um 19:51 schrieb Thomas Zimmermann:
The GEM CMA helpers
On Fri, Nov 12, 2021 at 03:19:17PM +0100, Marijn Suijten wrote:
> On 2021-11-12 13:23:36, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:45:22PM +0100, Marijn Suijten wrote:
> > > On 2021-11-12 12:12:38, Daniel Thompson wrote:
> > > > On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten
Ping for review.
Am 08.07.21 um 19:51 schrieb Thomas Zimmermann:
The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage
with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this
with a call to dma_free_noncoherent(). Writecombining storage is still
released
Am 12.11.21 um 15:30 schrieb Michel Dänzer:
On 2021-11-12 15:29, Michel Dänzer wrote:
On 2021-11-12 13:47, Christian König wrote:
Anyway this unfortunately turned out to be work for Harray and Nicholas. In
detail it's about this bug report here:
On Thu, Nov 11, 2021 at 04:10:41PM -0500, Harry Wentland wrote:
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Ville Syrjälä
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland
> >> Cc: Shankar, Uma ;
On Thu, Nov 11, 2021 at 08:57:26AM -0600, Rob Herring wrote:
> On Wed, 10 Nov 2021 20:43:28 +0100, H. Nikolaus Schaller wrote:
> > From: Sam Ravnborg
> >
> > Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
> > Based on .txt binding from Zubair Lutfullah Kakakhel
> >
> > We also
12.11.2021 13:52, Thierry Reding пишет:
> On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
>> 09.11.2021 17:17, Dmitry Osipenko пишет:
>>> 09.11.2021 17:08, Dmitry Osipenko пишет:
> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
> +{
> + struct drm_device
On 2021-11-12 15:29, Michel Dänzer wrote:
> On 2021-11-12 13:47, Christian König wrote:
>>
>> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
>> detail it's about this bug report here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=214621
>>
>> Lang was able to
On 2021-11-12 13:47, Christian König wrote:
>
> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
> detail it's about this bug report here:
> https://bugzilla.kernel.org/show_bug.cgi?id=214621
>
> Lang was able to reproduce the issue and narrow it down to the pin in
On 2021-11-12 13:23:36, Daniel Thompson wrote:
> On Fri, Nov 12, 2021 at 01:45:22PM +0100, Marijn Suijten wrote:
> > On 2021-11-12 12:12:38, Daniel Thompson wrote:
> > > On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> > > > The length of qcom,enabled-strings as property array is
Fix the compiler warning
drivers/char/agp/ati-agp.c: In function 'ati_create_page_map':
drivers/char/agp/ati-agp.c:58:16: warning: variable 'err' set but not used
[-Wunused-but-set-variable]
58 | int i, err = 0;
by returing the error to the caller.
Signed-off-by: Thomas
Fix compiler warnings
drivers/char/agp/backend.c:68: warning: Function parameter or member 'pdev'
not described in 'agp_backend_acquire'
drivers/char/agp/backend.c:93: warning: Function parameter or member 'bridge'
not described in 'agp_backend_release'
by adding the necessary
Fix the compiler warning
drivers/char/agp/sworks-agp.c: In function 'serverworks_configure':
drivers/char/agp/sworks-agp.c:265:37: warning: variable 'current_size' set
but not used [-Wunused-but-set-variable]
265 | struct aper_size_info_lvl2 *current_size;
by removing the
Fix the compiler warning
drivers/char/agp/nvidia-agp.c: In function 'nvidia_tlbflush':
drivers/char/agp/nvidia-agp.c:264:22: warning: variable 'temp' set but not
used [-Wunused-but-set-variable]
264 | u32 wbc_reg, temp;
by removing the unused variable. The affected readl() is
Fix compiler warnings like
drivers/char/agp/frontend.c:46:20: warning: no previous prototype for
'agp_find_mem_by_key' [-Wmissing-prototypes]
46 | struct agp_memory *agp_find_mem_by_key(int key)
by including the compat_ioctl.h in the source file.
Signed-off-by: Thomas Zimmermann
---
Fix the compiler warning
drivers/char/agp/via-agp.c: In function 'via_configure_agp3':
drivers/char/agp/via-agp.c:131:35: warning: variable 'current_size' set but
not used [-Wunused-but-set-variable]
131 | struct aper_size_info_16 *current_size;
by removing the variable.
Trivial coding-style fix.
Signed-off-by: Thomas Zimmermann
---
drivers/char/agp/ati-agp.c| 2 +-
drivers/char/agp/frontend.c | 2 +-
drivers/char/agp/sworks-agp.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
Fix a number of compiler warnings in the AGP drivers. No functional
changes.
Thomas Zimmermann (7):
agp: Remove trailing whitespaces
agp: Include "compat_ioctl.h" where necessary
agp: Documentation fixes
agp/ati: Return error from ati_create_page_map()
agp/nvidia: Ignore value returned
On 11/11/2021 16:49, Matthew Brost wrote:
On Mon, Nov 01, 2021 at 10:35:09AM +, Tvrtko Ursulin wrote:
On 27/10/2021 21:10, Matthew Brost wrote:
On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison wrote:
On 10/27/2021 12:17, Matthew Brost wrote:
On Tue, Oct 26, 2021 at 02:58:00PM
On 12/11/2021 00:58, Lu Baolu wrote:
On 11/11/21 11:18 PM, Tvrtko Ursulin wrote:
On 10/11/2021 14:37, Robin Murphy wrote:
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On
On Wed, 15 Sep 2021, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the read-only array states on the stack but instead it
> static. Also makes the object code smaller.
Finally pushed, sorry for the delay.
BR,
Jani.
>
> Signed-off-by: Colin Ian King
> ---
>
On Fri, 12 Nov 2021, Javier Martinez Canillas wrote:
> This relationship was only for historical reasons and the nomodeset option
> should be available even on platforms that don't enable CONFIG_VGA_CONSOLE.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
>
On 12/11/2021 00:53, Lu Baolu wrote:
On 11/11/21 11:06 PM, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi
The message printed when nomodeset is present in the kernel command line
makes it look as if the parameter must never be used and it's a bad idea.
But there are valid reasons to use this parameter and the message should
not imply otherwise. Change the text to be more accurate and restrained.
The nomodeset kernel command line parameter is not documented. Its name
is quite vague and is not intuitive what's the behaviour when it is set.
Document in kernel-parameters.txt what actually happens when nomodeset
is used. That way, users could know if they want to enable this option.
The nomodeset kernel parameter handler already prints a message that the
DRM drivers will be disabled, so there's no need for drivers to do that.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Acked-by: Jani Nikula
Acked-by: Pekka Paalanen
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it.
Let's move the vgacon_text_force()
It is already handled by the console.h macro since a stub inline function
is defined for vgacon_text_force() if CONFIG_VGA_CONSOLE is not set.
There's no need to have ifdefery in the driver when calling the function.
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Acked-by:
This relationship was only for historical reasons and the nomodeset option
should be available even on platforms that don't enable CONFIG_VGA_CONSOLE.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Acked-by: Jani Nikula
Acked-by: Pekka
There is a lot of historical baggage on this parameter. It is defined in
the vgacon driver as nomodeset, but its set function is called text_mode()
and the value queried with a function named vgacon_text_force().
All this implies that it's about forcing text mode for VGA, yet it is not
used in
On 20/10/2021 14:39, Neil Armstrong wrote:
> This serie finnally reworks the drm/meson driver by extracting the encoders
> in their own file and moves to bridge-only callbacks.
>
> This permits passing the ATTACH_NO_CONNECTOR bridge attach flag and finally
> use the CVBS & HDMI display-connector
On Fri, Nov 12, 2021 at 01:45:22PM +0100, Marijn Suijten wrote:
> On 2021-11-12 12:12:38, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> > > The length of qcom,enabled-strings as property array is enough to
> > > determine the number of strings to be
On Fri, Nov 12, 2021 at 01:35:01PM +0100, Marijn Suijten wrote:
> On 2021-11-12 12:08:39, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> > > + if (string_len > 0) {
> > > + dev_warn(dev, "qcom,num-strings and
> > >
Hi Pekka,
On Thu, Nov 11, 2021 at 11:37 AM Pekka Paalanen wrote:
>
> On Thu, 11 Nov 2021 11:07:21 -0300
> Igor Torrente wrote:
>
> > Hi Pekka,
> >
> > On Thu, Nov 11, 2021 at 6:33 AM Pekka Paalanen wrote:
> > >
> > > On Wed, 10 Nov 2021 13:56:54 -0300
> > > Igor Torrente wrote:
> > >
> > > >
Hi guys,
Am 10.11.21 um 14:26 schrieb Daniel Vetter:
[SNIP]
stack depot, not stuff it into a string. stack depot is a lot more
efficient and capturing backtraces, since it de-dupes and hashes and all
you need is a pointer iirc. linux/stackdepot.h for interface, I think we
recently gained a few
On 2021-11-12 12:12:38, Daniel Thompson wrote:
> On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> > The length of qcom,enabled-strings as property array is enough to
> > determine the number of strings to be enabled, without needing to set
> > qcom,num-strings to override the
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #20 from Christian König (christian.koe...@amd.com) ---
Nice work Lang, question is now only how to fix it?
We probably need to assign this bug to Harry and Nicholas.
--
You may reply to this email to add a comment.
You are
On 2021-11-12 12:08:39, Daniel Thompson wrote:
> On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> > When not specifying num-strings in the DT the default is used, but +1 is
> > added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
> > of 3 and 4 respectively,
On Fri, Nov 12, 2021 at 01:27:02AM +0100, Marijn Suijten wrote:
> The hardware is capable of controlling any non-contiguous sequence of
> LEDs specified in the DT using qcom,enabled-strings as u32
> array, and this also follows from the DT-bindings documentation. The
> numbers specified in this
On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> The length of qcom,enabled-strings as property array is enough to
> determine the number of strings to be enabled, without needing to set
> qcom,num-strings to override the default number of strings when less
> than the default
On Fri, 12 Nov 2021 12:20:14 +0100
Javier Martinez Canillas wrote:
> On 11/12/21 11:57, Thomas Zimmermann wrote:
>
> [snip]
>
> >>>
> >>> This is what HW-specific drivers want to query in their init/probing
> >>> code. The actual semantics of this decision is hidden from the driver.
> >>> It's
On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> When not specifying num-strings in the DT the default is used, but +1 is
> added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
> of 3 and 4 respectively, causing out-of-bounds reads and register
> read/writes.
This issue was not catched by CI, because of series of unfortunate events.
Before, CI has rebooted without module blocklist, and CI catched boot-time
dmesg correctly and marked it as 'ci@boot' test with failure if there was a
taint.
I've been doing changes to make blocklisting i915 possible and
On Fri, Nov 12, 2021 at 01:26:54AM +0100, Marijn Suijten wrote:
> The strings passed in DT may possibly cause out-of-bounds register
> accesses and should be validated before use.
>
> Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
> Signed-off-by: Marijn Suijten
>
edid_read() was assumed to return 0 on success. After
7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
the function can return >= 0 for successful case. Fix the g_edid_break
condition in sp_tx_edid_read().
Fixes: 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from
Hi
Am 12.11.21 um 12:20 schrieb Javier Martinez Canillas:
On 11/12/21 11:57, Thomas Zimmermann wrote:
[snip]
This is what HW-specific drivers want to query in their init/probing
code. The actual semantics of this decision is hidden from the driver.
It's also easier to read than the other
On 11/12/21 11:57, Thomas Zimmermann wrote:
[snip]
>>>
>>> This is what HW-specific drivers want to query in their init/probing
>>> code. The actual semantics of this decision is hidden from the driver.
>>> It's also easier to read than the other name IMHO
>>
>> Ok, but what is a "native
On Tue, Nov 02, 2021 at 03:25:10PM -0700, Matt Roper wrote:
> Bspec: 54077,68173,54833
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 278 +++-
> drivers/gpu/drm/i915/i915_reg.h | 94 +--
>
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Lang Yu from comment #18)
> Hi all,
>
> I reproduced the issue. Thanks for Erhard F.'s work!
>
> The problem is the pinned BO of last call to
>
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.
meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it from the _pm to _clk.
No functional change.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong
After this patchset, mtk_vcodec_release_dec_pm has only one line.
then remove that function. Use pm_runtime_disable directly instead.
For symmetry, move the pm_runtime_enable out from
mtk_vcodec_init_dec_pm, then mtk_vcodec_init_dec_pm only operate for
the clocks, rename it from the _pm to _clk.
Hi
Am 12.11.21 um 11:22 schrieb Pekka Paalanen:
On Fri, 12 Nov 2021 11:09:13 +0100
Thomas Zimmermann wrote:
Hi
Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
Hello Pekka,
On 11/12/21 09:56, Pekka Paalanen wrote:
[snip]
Hi,
these ideas make sense to me, so FWIW,
Acked-by:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should
1 - 100 of 127 matches
Mail list logo
