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
---
(no changes since v1)
drivers/gpu/drm/drm_edid.c | 62 +++
EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.
We'd like to use this panel ID in panel-simple to identify which panel
is hooked
The "logicpd_type_28" panel data was splitting up the
mitsubishi_aa070mc01 panel data. Reorganize it so that the panel descs
and modes are kept together.
This is a no-op code-cleanup change, found by code inspection.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- ("Reorder logicpd_type_28
The panel-simple driver handles way too much. Let's start trying to
get a handle on it by splitting out the eDP panels. This patch does
this:
1. Start by copying simple-panel verbatim over to a new driver,
simple-panel-edp.
2. Rename "panel_simple" to "panel_edp" in the new driver.
3. Keep only
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we split the PANEL_SIMPLE driver in 2. By default let's
give everyone who had the old driver enabled the new driver too. If
folks want to opt-out of one or the other they always can later.
Signed-off-by: Douglas Anderson
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we split the PANEL_SIMPLE driver in 2. By default let's
give everyone who had the old driver enabled the new driver too. If
folks want to opt-out of one or the other they always can later.
Signed-off-by: Douglas Anderson
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we split the PANEL_SIMPLE driver in 2. Let's enable the
new config.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/
Not all panels in panel-simple were marked what type of panel they
were. I searched through ARM/ARM64 Chromebooks or Chromebook-related
reference boards that I was aware of and found some panels that needed
to be moved. I also skimmed for panels that had no mode and were "big"
since it's quite rare
All of the "HPD" handling added to panel-simple recently was for eDP
panels. Remove it from panel-simple now that panel-simple-edp handles
eDP panels. The "prepare_to_enable" delay only makes sense in the
context of HPD, so remove it too. No non-eDP panels used it anyway.
Signed-off-by: Douglas An
In the case where we can read an EDID for a panel the only part of the
panel description that can't be found directly from the EDID is the
description of the delays. Let's break the delay structure out so that
we can specify just the delays for panels that are detected by EDID.
This is simple code
Now that the eDP panel driver only handles eDP panels we can make
better sense of the delays here. Let's describe them in terms of the
standard eDP timing diagram from the eDP spec.
As part of this, it becomes pretty clear that some eDP panels have too
long of a "hpd_reliable_delay". This used to
Now that the delays are named / described with eDP-centric names, it
becomes clear that we should really specify the "hpd_reliable" and
"hpd_absent" separately without taking the other into account. Let's
fix it.
This should be a no-op change and just adjust how we specify
things. The actual delay
While cleaning up the descriptions of the delay for eDP panels I
realized that we'd have a bug if any panels need the
"prepare_to_enable" but HPD handling isn't happening in the panel
driver. Let's put in a stopgap to at least make us not violate
timings. This is not perfectly optimal but trying to
The simple-panel driver is for panels that are not hot-pluggable at
runtime. Let's keep our cached EDID around until driver unload.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- ("Don't re-read the EDID every time") moved to eDP only patch.
drivers/gpu/drm/panel/panel-simple-edp.c | 6 +
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce
generic eDP panels") we can actually support probing eDP panels at
runtime instead of hardcoding what panel is connected. Add support to
the panel-simple-edp driver for this.
We'll implement a solution like this:
* We'll read in
Ideally the final composition format would have enough precision for
all of the planes. I think it'd make sense to use ARGB16161616 if the
primary plane uses ARGB and an overlay plane uses ARGB16161616.
To simplify the code, maybe it's fine to always use ARGB16161616 for
the output, and add ge
Hi Douglas,
Le mer., sept. 1 2021 at 13:19:26 -0700, Douglas Anderson
a écrit :
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we split the PANEL_SIMPLE driver in 2. By default let's
give everyone who had the old driver enabled the new driver too. If
folks want to
On Wed, Sep 1, 2021 at 2:50 AM Christian König
wrote:
>
> Am 01.09.21 um 02:46 schrieb Monk Liu:
> > issue:
> > in cleanup_job the cancle_delayed_work will cancel a TO timer
> > even the its corresponding job is still running.
> >
> > fix:
> > do not cancel the timer in cleanup_job, instead do the
On Wed, Sep 1, 2021 at 1:20 PM Douglas Anderson wrote:
>
> In the patch ("drm/panel-simple-edp: Split eDP panels out of
> panel-simple") we split the PANEL_SIMPLE driver in 2. By default let's
> give everyone who had the old driver enabled the new driver too. If
> folks want to opt-out of one or t
Hi Dave, Daniel,
Fixes for 5.15.
The following changes since commit 8f0284f190e6a0aa09015090568c03f18288231a:
Merge tag 'amd-drm-next-5.15-2021-08-27' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-08-30 09:06:03
+1000)
are available in the Git repository at:
https://g
Hi Masahiro,
On Fri, 20 Aug 2021 15:23:34 +0900 Masahiro Yamada wrote:
>
> On Fri, Aug 20, 2021 at 11:33 AM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > In file included from drivers/gp
Actually - did some more thinking, and I think we shouldn't try to make
changes like this until we actually know what the problem is here. I could try
to figure out what the actual race conditions I was facing before with trying
to add/destroy connectors based on PDT, but we still don't even actual
Hi Geert,
On 23/06/2021 13:53, Geert Uytterhoeven wrote:
> Hi Kieran,
>
> On Wed, Jun 23, 2021 at 1:11 AM Kieran Bingham
> wrote:
>> From: Kieran Bingham
>>
>> Extend the Renesas DU display bindings to support the r8a779a0 V3U.
>>
>> Signed-off-by: Kieran Bingham
>
> Thanks for your patch!
>
Hi ,
On Mon, 23 Aug 2021 17:50:27 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the hmm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'i915_ttm_tt_get_st':
> drivers/gpu/drm/i915/gem/i915_gem_ttm.
Hi Kieran,
On Wed, Sep 01, 2021 at 11:01:11PM +0100, Kieran Bingham wrote:
> On 23/06/2021 13:53, Geert Uytterhoeven wrote:
> > On Wed, Jun 23, 2021 at 1:11 AM Kieran Bingham wrote:
> >> From: Kieran Bingham
> >>
> >> Extend the Renesas DU display bindings to support the r8a779a0 V3U.
> >>
> >> S
On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote:
>
> Am 2021-09-01 um 4:29 a.m. schrieb Christoph Hellwig:
> > On Mon, Aug 30, 2021 at 01:04:43PM -0400, Felix Kuehling wrote:
> driver code is not really involved in updating the CPU mappings. Maybe
> it's something we need
On 2021-09-01 6:03 p.m., Dave Chinner wrote:
On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote:
Am 2021-09-01 um 4:29 a.m. schrieb Christoph Hellwig:
On Mon, Aug 30, 2021 at 01:04:43PM -0400, Felix Kuehling wrote:
driver code is not really involved in updating the CPU mappings. Ma
Hi,
On Wed, Sep 1, 2021 at 2:12 PM Olof Johansson wrote:
>
> On Wed, Sep 1, 2021 at 1:20 PM Douglas Anderson wrote:
> >
> > In the patch ("drm/panel-simple-edp: Split eDP panels out of
> > panel-simple") we split the PANEL_SIMPLE driver in 2. By default let's
> > give everyone who had the old dr
Hi Laurent,
On 01/09/2021 23:13, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Wed, Sep 01, 2021 at 11:01:11PM +0100, Kieran Bingham wrote:
>> On 23/06/2021 13:53, Geert Uytterhoeven wrote:
>>> On Wed, Jun 23, 2021 at 1:11 AM Kieran Bingham wrote:
From: Kieran Bingham
Extend the Ren
From: Kieran Bingham
Extend the Renesas DU display bindings to support the r8a779a0 V3U.
Reviewed-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
v2:
- Collected Laurent's tag
- Remove clock-names requirement
- Specify only a single clock
.../bindings/display/renesas,du.yaml
From: Kieran Bingham
Sort the DU outputs alphabetically, with the exception of the final
entry which is there as a sentinal.
Reviewed-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
v2:
- Collect tag
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 ++--
1 file changed, 2 insertions(+), 2
The R-Car DU as found on the D3, E3, and V3U do not have support
for an external synchronisation method.
In these cases, the dsysr cached register should not be initialised
in DSYSR_TVM_TVSYNC, but instead should be left clear to configure as
DSYSR_TVM_MASTER by default.
Reviewed-by: Laurent Pinc
From: Kieran Bingham
Extend the rcar_du_device_info structure and rcar_du_output enum to
support DSI outputs and utilise these additions to provide support for
the R8A779A0 V3U platform.
While the DIDSR register field is now named "DSI/CSI-2-TX-IF0 Dot Clock
Select" the existing define LVDS0 is
Not all platforms require both per-crtc IRQ and per-crtc clock
management. In preparation for suppporting such platforms, split the
feature macro to be able to specify both features independently.
The other features are incremented accordingly, to keep the two crtc
features adjacent.
Signed-off-b
The DIDSR fields named LDCS were incorrectly defined as LCDS.
Both the Gen2 and Gen3 documentation refer to the fields as the "LVDS
Dot Clock Select".
Correct the definitions.
Signed-off-by: Kieran Bingham
---
v2:
- New patch
drivers/gpu/drm/rcar-du/rcar_du_group.c | 4 ++--
drivers/gpu/drm/
Daniel Vetter pointed out that locking in the GuC submission code was
overly complicated, let's clean this up a bit before introducing more
features in the GuC submission backend.
Also fix some CI failures, port fixes from our internal tree, and add a
few more selftests for coverage.
Lastly, add
From: Matthew Brost
Prior to this patch the blocked context counter was cleared on
init_sched_state (used during registering a context & resets) which is
incorrect. This state needs to be persistent or the counter can read the
incorrect value resulting in scheduling never getting enabled again.
From: Matthew Brost
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da7
From: Matthew Brost
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
Cc: Daniel Vetter
Cc: Michal Wajdeczko
---
drivers/gpu/dr
From: Matthew Brost
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been u
From: Matthew Brost
If the context is reset as a result of the request cancellation the
context reset G2H is received after schedule disable done G2H which is
the wrong order. The schedule disable done G2H release the waiting
request cancellation code which resubmits the context. This races
with
From: Matthew Brost
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for n
From: Matthew Brost
Propagating errors to dependent fences is broken and can lead to
errors from one client ending up in another. In 3761baae908a (Revert
"drm/i915: Propagate errors on awaiting already signaled fences"), we
attempted to get rid of fence error propagation but missed the case
adde
From: Matthew Brost
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submi
From: Matthew Brost
When the GuC does a media reset, it copies a golden context state back
into the corrupted context's state. The address of the golden context
and the size of the engine state restore are passed in via the GuC ADS.
The i915 had a bug where it passed in the whole size of the gold
From: Matthew Brost
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel
From: Matthew Brost
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
v2:
(Daniele)
- Add helper for unblock
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ce
From: Matthew Brost
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple se
From: Matthew Brost
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
v2:
(kernel test robo )
- Add __maybe_unused to sched_state_is_init()
v3: rebase after the unused code path removal has
From: Matthew Brost
A context can get destroyed after cancelling a request, if a context or
GT reset occurs, so take a reference to context when cancelling a
request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spu
From: Matthew Brost
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gp
From: Matthew Brost
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went h
From: Matthew Brost
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_en
From: Matthew Brost
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
(Daniel Vetter)
- Correct put / get accounting in xa_for_loops
v3:
(Checkpatch)
- Extra new line
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Bros
From: Matthew Brost
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked/g
v2:
(Daniele)
- s/blocked_fence/blocked/g
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/g
From: Matthew Brost
Error captures can now be done in a work queue processing G2H messages.
These messages need to be completely done being processed in the reset
path, to avoid races in the missing G2H cleanup, which create a
dependency on memory allocations and dma fences (i915_requests).
Reque
From: Matthew Brost
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running. No need to call the IRQ handler directly
either as the scrubbing code can deal with any missing G2H.
Fix
From: Matthew Brost
Now that we have locking hierarchy of sched_engine->lock ->
ce->guc_state everything from guc_active can be moved into guc_state and
protected the guc_state.lock.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c
From: Matthew Brost
To make ownership of locking clear move fields (guc_id, guc_id_ref,
guc_id_link) to sub structure guc_id in intel_context.
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/i
From: Matthew Brost
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
v3:
- Fixup a few kernel doc comments (Daniele)
v4 (Daniele):
- Implement doc suggestions from
From: Matthew Brost
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
v2:
(Daniele)
- set CONTEXT_SET_INIT
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraol
On Wed, Sep 01, 2021 at 07:07:34PM -0400, Felix Kuehling wrote:
> On 2021-09-01 6:03 p.m., Dave Chinner wrote:
> > On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote:
> > > Am 2021-09-01 um 4:29 a.m. schrieb Christoph Hellwig:
> > > > On Mon, Aug 30, 2021 at 01:04:43PM -0400, Felix Kueh
Hi all,
On Mon, 26 Jul 2021 17:38:14 +0100 Mark Brown wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/firmware/Makefile
>
> between commit:
>
> b42000e4b874 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as
> a permenent module")
>
> from t
uang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: linux...@lists.infradead.org
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_module.c |4
1 file changed, 4 insertions(+)
--- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_
radead.org
---
drivers/gpu/drm/r128/ati_pcigart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20210901.orig/drivers/gpu/drm/r128/ati_pcigart.c
+++ linux-next-20210901/drivers/gpu/drm/r128/ati_pcigart.c
@@ -214,7 +214,7 @@ int drm_ati_pcigart_init(struct drm_devi
}
> Missing documentation :-)
Ack.
> > +static inline int drm_fixed_16_16(s32 mult, s32 div)
>
> You should return a s32.
Ack.
> The function name isn't very explicit, and departs from the naming
> scheme of other functions in the same file. As fixed-point numbers are
> stored in a s64 for the d
On Wed, Sep 01, 2021 at 09:35:40PM -0400, Alyssa Rosenzweig wrote:
> > Missing documentation :-)
>
> Ack.
>
> > > +static inline int drm_fixed_16_16(s32 mult, s32 div)
> >
> > You should return a s32.
>
> Ack.
>
> > The function name isn't very explicit, and departs from the naming
> > scheme
Quoting Marijn Suijten (2021-09-01 01:49:10)
> Hi Stephen,
>
> On 2021-08-31 22:35:12, Stephen Boyd wrote:
> > Quoting Marijn Suijten (2021-08-30 16:10:26)
> > >
> > > I'm 95% sure this shouldn't cause any problems given current DTs and
> > > their history, but that's probably not enough. This m
Quoting Marijn Suijten (2021-09-01 01:57:15)
> On 2021-08-31 22:35:56, Stephen Boyd wrote:
> > Quoting Marijn Suijten (2021-08-30 11:24:45)
> > > The DSI PHY/PLL was relying on a global "xo" clock to be found, but the
> > > real clock is named "xo_board" in the DT. The standard nowadays is to
> >
[AMD Official Use Only]
>>>
I'm not sure I can add much to help this along, I'm sure Alex has some internal
training,
Once your driver is upstream, it belongs to upstream, you can maintain it, but
you no longer control it 100%, it's a tradeoff, it's not one companies always
understand.
Usually
+++
1 file changed, 4 insertions(+)
--- linux-next-20210901.orig/drivers/gpu/drm/ttm/ttm_module.c
+++ linux-next-20210901/drivers/gpu/drm/ttm/ttm_module.c
@@ -53,6 +53,9 @@ pgprot_t ttm_prot_from_caching(enum ttm_
if (caching == ttm_cached)
return tmp;
+#ifdef CONFIG_UML
+ tmp
On Wed, 2021-09-01 at 14:17 +0200, Dafna Hirschfeld wrote:
Hi Dafna,
Thanks for your suggestion.
> Hi
>
> On 01.09.21 10:32, Yunfei Dong wrote:
> > There are just one core thread, in order to separeate different
> > hardware, using codec type to separeate it in scp driver.
>
> this code seems to
This adds a driver for the LG.Philips SW43101 FHD (1080x1920) 58Hz OLED DSI
video mode panel, found on the Xiaomi Mi Note 2.
Yassine Oudjana (2):
drm/panel: Add driver for LG.Philips SW43101 DSI video mode panel
dt-bindings: display: Add binding for LG.Philips SW43101
.../display/panel/lgphi
On Thu, Sep 2, 2021 at 2:02 PM Dongliang Mu wrote:
>
> [ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ]
>
> A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
> or yres setting in struct fb_var_screeninfo will result in a
> KASAN: vmalloc-out-of-bounds failure in bitfill_a
Add a driver for the LG.Philips SW43101 FHD (1080x1920) OLED DSI video mode
panel.
This driver has been generated using linux-mdss-dsi-panel-driver-generator.
Signed-off-by: Yassine Oudjana
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile
[ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ]
A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
or yres setting in struct fb_var_screeninfo will result in a
KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as
the margins are being cleared. The margins are clea
Add a device tree binding for LG.Philips SW43101.
Signed-off-by: Yassine Oudjana
---
.../display/panel/lgphilips,sw43101.yaml | 52 +++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/lgphilips,sw43101.yaml
diff --git
a
[ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ]
A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
or yres setting in struct fb_var_screeninfo will result in a
KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as
the margins are being cleared. The margins are clea
101 - 178 of 178 matches
Mail list logo
