le 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 = pgprot_
[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
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
> >
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
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
> 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
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
}
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_module.c
+
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
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
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
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
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 +-
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
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.
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).
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
---
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
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
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
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
---
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
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
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
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
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
---
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
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
---
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
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
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
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
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
---
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:
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.
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
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 ++--
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.
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
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
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(+),
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
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
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
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.
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
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.
> >>
> >>
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':
>
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!
>
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
eDP panels generally contain almost everything needed to control them
in their EDID. This comes from their DP heritage were a computer needs
to be able to properly control pretty much any DP display that's
plugged into it.
The one big issue with eDP panels and the reason that we need a panel
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be
Hi,
I'm working to add new plane formats to vkms. But I don't know what
should be the behavior in the situation that we received multiple planes
with different formats from the users-space.
For example, if the user chooses:
- DRM_FORMAT_ARGB16161616 to the primary plane
- DRM_FORMAT_ARGB
Hi Rob,
On Dienstag, 31. August 2021 23:30:15 CEST Rob Herring wrote:
> On Sat, Aug 28, 2021 at 01:02:05PM +0200, Luca Weiss wrote:
> > Document all formats currently present in include/linux/platform_data/
> > simplefb.h
> >
> > Signed-off-by: Luca Weiss
> > ---
> >
> >
On Wed, Sep 1, 2021 at 2:33 PM Linus Torvalds
wrote:
>
> On Wed, Sep 1, 2021 at 10:57 AM Linus Torvalds
> wrote:
> >
> > No worries. I enjoyed seeing the AMD code-names in the conflicts, they
> > are using positively kernel-level naming.
>
> Oh, I spoke too soon.
>
> The conflict in
On Thu, 2 Sept 2021 at 01:20, Alex Deucher wrote:
>
> On Wed, Sep 1, 2021 at 6:19 AM Liu, Monk wrote:
> >
> > [AMD Official Use Only]
> >
> > Daniel
> >
> > From the link you share it looks you(or someone else) have quite a bunch
> > patches that changes DRM_SCHED or even amdgpu, by that case
The pull request you sent on Tue, 31 Aug 2021 15:53:10 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-08-31-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/477f70cd2a67904e04c2c2b9bd0fa2e95222f2f6
Thank you!
--
Deet-doot-dot, I am a bot.
On Wed, Sep 1, 2021 at 10:57 AM Linus Torvalds
wrote:
>
> No worries. I enjoyed seeing the AMD code-names in the conflicts, they
> are using positively kernel-level naming.
Oh, I spoke too soon.
The conflict in amdgpu_ras_eeprom.c is trivial to fix up, but the
*code* is garbage.
It does this
Hi Alyssa,
Thank you for the patch.
On Wed, Sep 01, 2021 at 01:54:27PM -0400, Alyssa Rosenzweig wrote:
> This constructs a fixed 16.16 rational, useful to specify the minimum
> and maximum scaling in drm_atomic_helper_check_plane_state. It is
> open-coded as a macro in multiple drivers, so let's
Add yaml binding for msm8998 dpu1 support.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/display/msm/dpu-msm8998.yaml | 220 ++
1 file changed, 220 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
diff --git
Bringup functionality for MSM8998 in the DPU, driver which is mostly
the same as SDM845 (just a few variations).
Signed-off-by: AngeloGioacchino Del Regno
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 335 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
The enum dpu_clk_ctrl_type misses DPU_CLK_CTRL_DMA{2,3} even though
this driver does actually handle both, if present: add the two in
preparation for adding support for SoCs having them.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
1 file
On Mon, Aug 30, 2021 at 10:53 PM Dave Airlie wrote:
>
> There are a bunch of conflicts with your tree, but none of them seem
> too serious, but I might have missed something.
No worries. I enjoyed seeing the AMD code-names in the conflicts, they
are using positively kernel-level naming.
That
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/zte/zx_plane.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-rockc...@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-arm-...@vger.kernel.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 8
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-amlo...@lists.infradead.org
---
drivers/gpu/drm/meson/meson_overlay.c | 7 +++
drivers/gpu/drm/meson/meson_plane.c | 5 ++---
2
This constructs a fixed 16.16 rational, useful to specify the minimum
and maximum scaling in drm_atomic_helper_check_plane_state. It is
open-coded as a macro in multiple drivers, so let's share the helper.
Signed-off-by: Alyssa Rosenzweig
---
include/drm/drm_fixed.h | 5 +
1 file changed, 5
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always
checking if the relative CTL is started by waiting for an interrupt
to fire: it is fine to do that, but then sometimes we call this
function while the CTL is up and has never been put down, but that
interrupt gets raised only when
Add a function that returns whether the requested CTL is active or not:
this will be used in a later commit to fix command mode panel issues.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7
This adds support for the BOE BF060Y8M-AJ0 5.99" AMOLED module
that can be found in some F(x)Tec Pro1 and Elephone U1 devices.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
Document the boe,bf060y8m-aj0 panel.
Signed-off-by: AngeloGioacchino Del Regno
---
.../display/panel/boe,bf060y8m-aj0.yaml | 81 +++
1 file changed, 81 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
diff --git
Add a driver for panels using the Novatek NT35950 Display Driver IC,
including support for the Sharp LS055D1SX04, found in some Sony Xperia
Z5 Premium and XZ Premium smartphones.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panel/Kconfig | 11 +
The nt35950 IC from Novatek is a Driver IC used to drive MIPI-DSI panels,
with Static RAM for content retention in command mode and also supports
video mode with VESA Frame Buffer Compression or Display Stream Compression
on single, or dual dsi port(s).
This DDIC is also capable of upscaling an
Add a virtual hardware or vblank-less mode as a module
to enable VKMS to emulate virtual hardware drivers. This means
no vertical blanking events occur and pageflips are completed
arbitrarily and when required for updating the frame.
Add a new drm_crtc_funcs struct, vkms_vblankless_crtc_funcs and
Add a new function vkms_composer_common(). The actual plane
composition work has been moved to the helper function,
vkms_composer_common() which is called by vkms_composer_worker()
and will be called in the implementation of virtual_hw mode
as well.
Signed-off-by: Sumera Priyadarsini
---
Changes
This patchset adds support for emulating virtual hardware with VKMS.
The virtual hardware mode can be enabled by using the following command
while loading the module:
sudo modprobe vkms enable_virtual_hw=1
The first patch is prep work for adding virtual_hw mode and refactors
the plane
On 22/08/2021 01:39, Laurent Pinchart wrote:
> Improve the debugging and error messages printing when initializing
> encoders by replacing the output number by the output name, printing the
> bridge OF node name, and the error code of failed operations.
>
> While at it, move the related
On Wed, 1 Sept 2021 at 03:21, wrote:
>
> From: Daniele Ceraolo Spurio
>
> The firmware binary has to be loaded from lmem and the recommendation is
> to put all other objects in there as well. Note that we don't fall back
> to system memory if the allocation in lmem fails because all objects are
1 - 100 of 173 matches
Mail list logo
