(cc: ainux.w...@gmail.com)
Hi
Am 03.10.21 um 20:09 schrieb Chuck Lever III:
Hi-
After updating one of my test systems to v5.15-rc, I found that it
becomes unresponsive during the later part of the boot process. A
power-on reset is necessary to recover.
I bisected to this commit:
572994bf18ff
commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present") added bus format probing to mxsfb this exposed several issues in the
display stack as used on the Librem 5:
The nwl bridge and the panels didn't bother to set any media bus formats and in
that case mxsfb would no
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially outp
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf
This allows the DSI bridge to detect the correct bus format.
We currently only support MEDIA_BUS_FMT_RGB888_1X24.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703
media-bus-formats.h has them in hexadecimal as well so matching with
that file saves one conversion when debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/
If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
that case.
This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge i
On Fri, 24 Sep 2021, Ville Syrjälä wrote:
> On Tue, Sep 21, 2021 at 06:50:39PM -0700, Matthew Brost wrote:
>> From: Hugh Dickins
>>
>> 5.15-rc1 crashes with blank screen when booting up on two ThinkPads
>> using i915. Bisections converge convincingly, but arrive at different
>> and surprising "
On Sat, 02 Oct 2021, Hugh Dickins wrote:
> On Sat, 2 Oct 2021, Linus Torvalds wrote:
>> On Sat, Oct 2, 2021 at 5:17 AM Steven Rostedt wrote:
>> > On Sat, 2 Oct 2021 03:17:29 -0700 (PDT)
>> > Hugh Dickins wrote:
>> >
>> > > Yes (though bisection doesn't work right on this one): the fix
>> >
>> >
Am Montag, dem 04.10.2021 um 09:27 +0200 schrieb Guido Günther:
> Components further up in the chain might ask us for supported formats.
>
> Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
> output with mxsfb since it can't determine a proper bus format.
>
> We handle the bu
Am Montag, dem 04.10.2021 um 09:27 +0200 schrieb Guido Günther:
> media-bus-formats.h has them in hexadecimal as well so matching with
> that file saves one conversion when debugging.
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +-
>
Am Montag, dem 04.10.2021 um 09:27 +0200 schrieb Guido Günther:
> If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
> that case.
>
> This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
>
On Sat, Oct 02, 2021 at 07:28:02PM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> > On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > > >
On 01/10/2021 16:48, Peter Zijlstra wrote:
On Fri, Oct 01, 2021 at 11:32:16AM +0100, Tvrtko Ursulin wrote:
On 01/10/2021 10:04, Tvrtko Ursulin wrote:
Hi Peter,
On 30/09/2021 19:33, Peter Zijlstra wrote:
On Thu, Sep 30, 2021 at 06:15:47PM +0100, Tvrtko Ursulin wrote:
void set_user_nice
The problem is a bit different.
The callback is on the dependent fence, while we need to signal the
scheduler fence.
Daniel is right that this needs an irq_work struct to handle this properly.
Christian.
Am 01.10.21 um 17:10 schrieb Andrey Grodzovsky:
From what I see here you supposed to hav
Clamp the fbdev surface size of the available maximum height to avoid
failing to init console emulation. An example error is shown below.
bad framebuffer height 2304, should be >= 768 && <= 768
[drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
simple-framebuffer
On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> >
> > Sean, could you revert the whole patch series? I'll have a deeper look into
> > the
> > patch set and come up with a v3 where all these issues will be addressed.
> >
>
> Hi Sean,
On Mon, Oct 04, 2021 at 10:15:06AM +0200, Thomas Zimmermann wrote:
> Clamp the fbdev surface size of the available maximum height to avoid
> failing to init console emulation. An example error is shown below.
>
> bad framebuffer height 2304, should be >= 768 && <= 768
> [drm] Initialized simpl
Hi,
On Mon, Oct 04, 2021 at 09:58:37AM +0200, Lucas Stach wrote:
> Am Montag, dem 04.10.2021 um 09:27 +0200 schrieb Guido Günther:
> > If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
> > returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
> > that case.
>
On Mon, Oct 04, 2021 at 09:12:37AM +0100, Tvrtko Ursulin wrote:
> On 01/10/2021 16:48, Peter Zijlstra wrote:
> > Hmm? That's for normalize_rt_tasks() only, right? Just don't have it
> > call the notifier in that special case (that's a magic sysrq thing
> > anyway).
>
> You mean my talk about task
On Mon, 04 Oct 2021, Ville Syrjälä wrote:
> On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote:
>> On 21/10/02 09:13AM, Fernando Ramos wrote:
>> >
>> > Sean, could you revert the whole patch series? I'll have a deeper look
>> > into the
>> > patch set and come up with a v3 where all
On 27-09-21, 01:40, Dmitry Osipenko wrote:
> This series adds runtime PM support to Tegra drivers and enables core
> voltage scaling for Tegra20/30 SoCs, resolving overheating troubles.
>
> All patches in this series are interdependent and should go via Tegra tree.
So you don't need any OPP chang
On 27-09-21, 01:40, Dmitry Osipenko wrote:
> Elements of the 'names' array are not changed by the code, constify them
> for consistency.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 6 +++---
> include/linux/pm_opp.h | 8
> 2 files changed, 7 insertions(+), 7 dele
The KMS documentation doesn't say much about the meaning of each
content type. Add a reference to the specification defining them.
Signed-off-by: Simon Ser
Cc: Emmanuel Gil Peyrot
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ville Syrjala
Cc: Jani Nikula
---
drivers/gpu/drm/drm_connector.c | 2
On Mon, Oct 04, 2021 at 09:12:50AM +, Simon Ser wrote:
> The KMS documentation doesn't say much about the meaning of each
> content type. Add a reference to the specification defining them.
>
> Signed-off-by: Simon Ser
> Cc: Emmanuel Gil Peyrot
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc
On Monday, October 4th, 2021 at 11:22, Ville Syrjälä
wrote:
> A bit annoying to have to refer to an external spec, but copy pasting
> the whole thing here seems a bit questionable.
Yeah, I'm mostly worried about copyright. We could also invent our own
descriptions (Is that even possible without
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they m
On Sat, Oct 02, 2021 at 11:45:41AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This reverts commit 399190e70816886e2bca1f3f3bc3d9c544af88e7.
>
> This patchset breaks on intel platforms and was previously NACK'd by
> Ville.
>
> Cc: Ville Syrjälä
> Cc: Fernando Ramos
> Signed-off-by: Sean Pau
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences wher
On Tue, Apr 27, 2021 at 10:58:07AM +0200, Daniel Vetter wrote:
> On Mon, Apr 26, 2021 at 08:18:39PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 22, 2021 at 11:
The "digi_port" pointer can't be NULL and we have already dereferenced
it so checking for NULL is not necessary. Delete the check.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
The msm_iommu_new() returns error pointers on failure so check for that
to avoid an Oops.
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/driver
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_r
On Fri, 1 Oct 2021 at 21:00, Dmitry Osipenko wrote:
>
> 01.10.2021 17:55, Ulf Hansson пишет:
> > On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 16:39, Ulf Hansson пишет:
> >>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> Add runtime power manageme
On Tue, Jul 20, 2021 at 03:44:49PM +0200, Daniel Vetter wrote:
> On Thu, Jul 15, 2021 at 09:49:51PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Quite a few places are hand rolling the modeset lock backoff dance.
> > Let's suck that into a helper macro that is easier to use without
In case of a modeset where a mode gets split across mutiple CRTCs
in the driver specific implementation (bigjoiner in i915) we wrongly count
the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
an affected CRTC in atomic_check_only().
This triggers a warning since affected
On 30/09/2021 20:09, Boris Brezillon wrote:
> This should help limit the number of ioctls when submitting multiple
> jobs. The new ioctl also supports syncobj timelines and BO access flags.
>
> v5:
> * Fix typos
> * Add BUILD_BUG_ON() checks to make sure SUBMIT_BATCH_VERSION and
> descriptor siz
On 30/09/2021 20:09, Boris Brezillon wrote:
> Sometimes, all the user wants to do is add a synchronization point.
> Userspace can already do that by submitting a NULL job, but this implies
> submitting something to the GPU when we could simply skip the job and
> signal the done fence directly.
>
>
On Mon, Oct 04, 2021 at 04:36:29AM -0700, Manasi Navare wrote:
> In case of a modeset where a mode gets split across mutiple CRTCs
> in the driver specific implementation (bigjoiner in i915) we wrongly count
> the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
> an affect
In case of a modeset where a mode gets split across mutiple CRTCs
in the driver specific implementation (bigjoiner in i915) we wrongly count
the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
an affected CRTC in atomic_check_only().
This triggers a warning since affected
On Mon, 4 Oct 2021 12:30:42 +0100
Steven Price wrote:
> On 30/09/2021 20:09, Boris Brezillon wrote:
> > Sometimes, all the user wants to do is add a synchronization point.
> > Userspace can already do that by submitting a NULL job, but this implies
> > submitting something to the GPU when we coul
Am 04.10.21 um 12:50 schrieb Tvrtko Ursulin:
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexit
On 04/10/2021 13:24, Boris Brezillon wrote:
> On Mon, 4 Oct 2021 12:30:42 +0100
> Steven Price wrote:
[...]
>>
>> It took me a while to convince myself that the reference counting for
>> the PM reference is correct. Before panfrost_job_hw_submit() always
>> returned with an extra reference, but no
On 01/10/2021 11:05, Christian König wrote:
Just exercising a very minor subset of the functionality, but already
proven useful.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-resv.c | 164 ++
On 04/10/2021 13:59, Christian König wrote:
Am 04.10.21 um 12:50 schrieb Tvrtko Ursulin:
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05,
> On Oct 4, 2021, at 3:07 AM, Thomas Zimmermann wrote:
>
> (cc: ainux.w...@gmail.com)
>
> Hi
>
> Am 03.10.21 um 20:09 schrieb Chuck Lever III:
>> Hi-
>> After updating one of my test systems to v5.15-rc, I found that it
>> becomes unresponsive during the later part of the boot process. A
>> po
The "vbif->features" is type unsigned long but the debugfs file
is treating it as a u32 type. This will work in little endian
systems, but the correct thing is to change the debugfs to use
an unsigned long.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dan Carpenter
---
There are two problems here:
1) The "seqptr" is used uninitalized when we free it at the end.
2) The a6xx_gmu_get_mmio() function returns error pointers. It never
returns true.
Fixes: 64245fc55172 ("drm/msm/a6xx: use AOP-initialized PDC for a650")
Fixes: f8fc924e088e ("drm/msm/a6xx: Fix PDC re
Hi
Am 04.10.21 um 15:34 schrieb Chuck Lever III:
On Oct 4, 2021, at 3:07 AM, Thomas Zimmermann wrote:
(cc: ainux.w...@gmail.com)
Hi
Am 03.10.21 um 20:09 schrieb Chuck Lever III:
Hi-
After updating one of my test systems to v5.15-rc, I found that it
becomes unresponsive during the later pa
> On Oct 4, 2021, at 10:07 AM, Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.10.21 um 15:34 schrieb Chuck Lever III:
>>> On Oct 4, 2021, at 3:07 AM, Thomas Zimmermann wrote:
>>>
>>> (cc: ainux.w...@gmail.com)
>>>
>>> Hi
>>>
>>> Am 03.10.21 um 20:09 schrieb Chuck Lever III:
Hi-
After
On 2021-10-01 15:56, Sean Paul wrote:
> On Wed, Sep 29, 2021 at 03:39:26PM -0400, Mark Yacoub wrote:
>> From: Mark Yacoub
>>
>> [Why]
>> drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
>> sizes. There is no need to check it within amdgpu_dm_atomic_check.
>>
>> [How]
>>
From: Tvrtko Ursulin
Connect i915 with the process nice change notifier so that our scheduling
can react to runtime adjustments, on top of previously added nice value
inheritance at context create time.
To achieve this we use the previously added map of clients per owning
tasks in combination wi
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
A simple hash table of registered clients indexed by the task struct
pointer is kept to be used in a following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_drm_client.c | 31 +++
From: Tvrtko Ursulin
Code added in 71ed60112d5d ("drm/i915: Add kick_backend function to
i915_sched_engine") and ee242ca704d3 ("drm/i915/guc: Implement GuC
priority management") introduced some scheduling related vfuncs which
take integer request priority as argument.
Make them instead take stru
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
04.10.2021 12:11, Viresh Kumar пишет:
> On 27-09-21, 01:40, Dmitry Osipenko wrote:
>> This series adds runtime PM support to Tegra drivers and enables core
>> voltage scaling for Tegra20/30 SoCs, resolving overheating troubles.
>>
>> All patches in this series are interdependent and should go via T
On Fri 01 Oct 18:27 PDT 2021, Dmitry Baryshkov wrote:
> Use clk_bulk_* API instead of hand-coding them. Note, this drops support
> for legacy clk naming (e.g. "iface_clk" instead of just "iface"),
> however all in-kernel device trees were converted long long ago. The
> warning is present there sin
From: Tvrtko Ursulin
Implement a simple notifier chain via which interested parties can track
when process nice value changes. Simple because it is global so each user
would have to track which tasks it is interested in.
First intended use case are GPU drivers using task nice as priority hint
wh
From: Tvrtko Ursulin
This is a somewhat early sketch of one of my ideas intended for early feedback
from the core scheduler experts. First and last two patches in the series are
the most interesting ones for people outside of i915. (Note I did not copy
everyone on all patches but just the cover l
From: Tvrtko Ursulin
Introduce the concept of context nice value which matches the process
nice.
We do this by extending the struct i915_sched_attr and add a helper
(i915_sched_attr_priority) to be used to convert to effective priority
when used by backend code and for priority sorting.
Context
I see my confusion, we hang all unsubmitted jobs on the last submitted
to HW job.
Yea, in this case indeed rescheduling to a different thread context will
avoid the splat but
the schedule work cannot be done for each dependency signalling but
rather they way we do
for ttm_bo_delayed_delete with
On 24/09/2021 23:34, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using sha
Hi,
On 10/4/21 5:22 PM, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 06:36:13PM +0200, Hans de Goede wrote:
>> Add 2 drm_connector privacy-screen helper functions:
>>
>> 1. drm_connector_attach_privacy_screen_provider(), this function creates
>> and attaches the standard privacy-screen propertie
Hi Douglas,
On Tue, Sep 14, 2021 at 10:23 PM Douglas Anderson wrote:
> A future change wants to be able to read just block 0 of the EDID, so
> break it out of drm_do_get_edid() into a sub-function.
>
> This is intended to be a no-op change--just code movement.
>
> Signed-off-by: Douglas Anderson
On Sat, Oct 02, 2021 at 06:36:17PM +0200, Hans de Goede wrote:
> The upcoming privacy-screen support adds another check for
> deferring probe till some other drivers have bound first.
>
> Factor out the current vga_switcheroo_client_probe_defer() check
> into an intel_modeset_probe_defer() helper,
On Mon, Oct 04, 2021 at 12:41:00PM +0300, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 11:45:41AM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > This reverts commit 399190e70816886e2bca1f3f3bc3d9c544af88e7.
> >
> > This patchset breaks on intel platforms and was previously NACK'd by
> > V
04.10.2021 14:01, Ulf Hansson пишет:
> On Fri, 1 Oct 2021 at 21:00, Dmitry Osipenko wrote:
>>
>> 01.10.2021 17:55, Ulf Hansson пишет:
>>> On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko wrote:
01.10.2021 16:39, Ulf Hansson пишет:
> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
Hi,
On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> Changes in v2:
>> - Call drm_connector_update_privacy_screen() from
>> intel
On Sat, Oct 02, 2021 at 06:36:13PM +0200, Hans de Goede wrote:
> Add 2 drm_connector privacy-screen helper functions:
>
> 1. drm_connector_attach_privacy_screen_provider(), this function creates
> and attaches the standard privacy-screen properties and registers a
> generic notifier for generating
On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> Add support for eDP panels with a built-in privacy screen using the
> new drm_privacy_screen class.
>
> Changes in v2:
> - Call drm_connector_update_privacy_screen() from
> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead
On 10/2/2021 1:02 AM, Rob Clark wrote:
From: Rob Clark
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c
In the commit bac9c2948224 ("drm/edid: Break out reading block 0 of
the EDID") I broke out reading the base block of the EDID to its own
function. Unfortunately, when I did that I messed up the handling when
drm_edid_is_zero() indicated that we had an EDID that was all 0x00 or
when we went through
Hi,
On Mon, Oct 4, 2021 at 8:42 AM Geert Uytterhoeven wrote:
>
> > - if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > + edid = (u8 *)drm_do_get_edid_base_block(get_edid_block, data,
> > + &connector->edid_corrupt,
> > +
On Fri, 24 Sep 2021 14:35:12 +0200, Geert Uytterhoeven wrote:
> make dtbs_check:
>
> arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dt.yaml: bridge@2c:
> reg:0:0: 45 was expected
>
> According to the datasheet, the I2C address can be either 0x2c or 0x2d,
> depending on the ADDR control inp
Hi Doug,
On Mon, Oct 4, 2021 at 6:26 PM Doug Anderson wrote:
> On Mon, Oct 4, 2021 at 8:42 AM Geert Uytterhoeven
> wrote:
> > > - if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > > + edid = (u8 *)drm_do_get_edid_base_block(get_edid_block, data,
> > > +
Hi Douglas,
On Mon, Oct 4, 2021 at 6:22 PM Douglas Anderson wrote:
> In the commit bac9c2948224 ("drm/edid: Break out reading block 0 of
> the EDID") I broke out reading the base block of the EDID to its own
> function. Unfortunately, when I did that I messed up the handling when
> drm_edid_is_ze
On Fri, 24 Sep 2021 14:44:48 -0700, Justin Chen wrote:
> The ASP 2.0 Ethernet controller uses a brcm unimac.
>
> Signed-off-by: Justin Chen
> Signed-off-by: Florian Fainelli
> ---
> Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by:
On Sat, 25 Sep 2021 12:31:33 +0200, Raffaele Tranquillini wrote:
> This add the bindings for the JDI FHD_R63452 1080x1920 5.2" LCD DSI
> panel used on the Xiaomi Mi 5 smartphone.
>
> Signed-off-by: Raffaele Tranquillini
> ---
> .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2
On Sun, 26 Sep 2021 03:10:04 +0300, Dmitry Baryshkov wrote:
> Add devicetree bindings for the Sharp LS060T1SX01 6.0" FullHD panel
> using NT35695 driver. This panel can be found i.e. in the Dragonboard
> Display Adapter bundle.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../display/panel/sharp,
On Mon, 27 Sep 2021 23:45:03 +0200, David Heidelberg wrote:
> Both hardware and driver can communicate DDC over i2c bus.
>
> Fixes warnings as:
> arch/arm/boot/dts/tegra20-paz00.dt.yaml: panel: 'ddc-i2c-bus' does not match
> any of the regexes: 'pinctrl-[0-9]+'
> From schema:
> /home/runne
On Tue, 28 Sep 2021 10:57:03 +0800, tommy-huang wrote:
> Add ast2600-gfx description for gfx driver.
>
> Signed-off-by: tommy-huang
> ---
> Documentation/devicetree/bindings/gpu/aspeed-gfx.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
On Tue, 28 Sep 2021 18:49:27 +0530, Sireesh Kodali wrote:
> SoCs based on the MSM8953 platform use the 14nm DSI PHY driver
>
> Signed-off-by: Sireesh Kodali
> ---
> Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
On Tue, 14 Sep 2021, Nathan Chancellor wrote:
> i915 enables a wider set of warnings with '-Wall -Wextra' then disables
> several with cc-disable-warning. If an unknown flag gets added to
> KBUILD_CFLAGS when building with clang, all subsequent calls to
> cc-{disable-warning,option} will fail, mea
On Mon, Oct 04, 2021 at 06:02:21PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> > On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> >> Add support for eDP panels with a built-in privacy screen using the
> >> new drm_privacy_screen class.
> >>
> >>
This patchset fixes WLED's handling of enabled-strings: besides some
cleanup it is now actually possible to specify a non-contiguous array of
enabled strings (not necessarily starting at zero) and the values from
DT are now validated to prevent possible unexpected out-of-bounds
register and array e
The kernel already provides appropriate primitives to perform endianness
conversion which should be used in favour of manual bit-wrangling.
Signed-off-by: Marijn Suijten
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/video/backlight/qcom-wled.c | 25 +++--
1 file chang
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 +1 exists for a deficiency in the DT parsing code,
and is simply omit
The previous commit improves num_strings parsing to not go over the
maximum of 3 strings for wled3 anymore. Likewise this default index for
a hypothetical 4th string is invalid and could access registers that are
not mapped to the desired purpose.
Removing this value gets rid of undesired confusio
of_property_read_u32_array takes the number of elements to read as last
argument. This does not always need to be 4 (sizeof(u32)) but should
instead be the size of the array in DT as read just above with
of_property_count_elems_of_size.
To not make such an error go unnoticed again the driver now b
DT-bindings do not specify num-strings as mandatory property, yet it is
required to be specified even if enabled-strings is used. The length of
that property-array should already be enough to determine exactly which
and how many strings to enable.
Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restr
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
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/video/backlight/qcom-
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 array represent indices of the LED strings
that are to be enabled and disa
Remove redundant spaces inside for loop conditions. No other double
spaces were found that are not part of indentation with `[^\s] `.
Signed-off-by: Marijn Suijten
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/video/backlight/qcom-wled.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
Only wled 3 sets a sensible default that allows operating this driver
with just qcom,num-strings in the DT; wled 4 and 5 require
qcom,enabled-strings to be provided otherwise enabled_strings remains
zero-initialized, resuling in every string-specific register write
(currently only the setup and con
Following the previous commit using enabled_strings in set_brightness,
enabled_strings is now also used in the autodetection path for
consistent behaviour: when a list of strings is specified in DT only
those strings will be probed for autodetection, analogous to how the
number of strings that need
Hi Dave and Daniel,
Here goes an accumulated pull request. A special highlight to
the ADL-P (XE_LPD) and DG2 display support preparation and on
a big clean-up in the display portion of the driver.
Here goes drm-intel-next-2021-10-04:
Cross-subsystem Changes:
- fbdev/efifb: Release PCI device's r
1 - 100 of 174 matches
Mail list logo
