On Fri, Mar 26, 2021 at 04:37:52PM -0400, Lyude Paul wrote:
> This is something that we've wanted for a while now: the ability to
> actually look up the respective drm_device for a given drm_dp_aux struct.
> This will also allow us to transition over to using the drm_dbg_*() helpers
> for debug mes
[Why]
This issue is found when scaling is not equal to one from src to dest.
When issue happens, there are offsets in both axis x and y between
two cursors. Users cannot control APP under such a condition.
[How]
For dual cursors, cursor should be disabled if there is a visible pipe
on top of the c
Hi Marcel,
On Mon, 2021-03-29 at 00:49 +, Marcel Ziswiler wrote:
> Hi Liu
>
> On Tue, 2021-03-23 at 17:09 +0800, Liu Ying wrote:
> > On Tue, 2021-03-23 at 01:03 +, Marcel Ziswiler wrote:
> > > Hi Liu
> > >
> > > Some further discrepancy with them binding examples:
> > >
> > > arch/arm64
On Thu, 25 Mar 2021 12:12:09 -0400
Alex Deucher wrote:
> + dri-devel
>
> I don't think it's currently exposed anywhere.
>
> Alex
>
> On Wed, Mar 24, 2021 at 5:11 AM Werner Sembach
> wrote:
> >
> > Hello,
> >
> > is the information which color mode is currently in used for a display
> > (RGB
On Sat, 27 Mar 2021 11:26:26 +
Paul Cercueil wrote:
> It has two mutually exclusive background planes (same Z level) + one
> overlay plane.
What's the difference between the two background planes?
How will generic userspace know to pick the "right" one?
Thanks,
pq
> Le sam. 27 mars 2021
> On Thu, 25 Mar 2021 12:12:09 -0400
> Alex Deucher wrote:
>
>> + dri-devel
>>
>> I don't think it's currently exposed anywhere.
>>
>> Alex
>>
>> On Wed, Mar 24, 2021 at 5:11 AM Werner Sembach
>> wrote:
>>> Hello,
>>>
>>> is the information which color mode is currently in used for a display
Hi,
I cannot apply this patch. The error is shown below. Which tree do you
use? Can you please move to drm-misc-next?
Applying: drm/ast: Disable fast reset after DRAM initial
error: sha1 information is lacking or useless
(drivers/gpu/drm/ast/ast_drv.h).
error: could not build fake ancestor
P
On Sun, Mar 28, 2021 at 11:24:19PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds support for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
> ---
> since v6
> - Fix Kconfig typo.
> - Remove internal mutex lock.
> - Add the prefix for max brightness.
> - rename init_device_pr
On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> On Fri, Mar 19, 2021 at 2:35 AM Xin Ji wrote:
> >
> > Add HDCP feature, enable HDCP function through chip internal key
> > and downstream's capability.
> >
> > Signed-off-by: Xin Ji
> > ---
> > drivers/gpu/drm/bridge/analogix/anx7625.c
On Sun, Mar 28, 2021 at 11:24:17PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
Reviewed-by: Daniel Thompson
___
dri-devel mailing list
dri-devel@lists.freed
Hi Dave,
Just one cleanup to drop unused header inclusion.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 09d78dde88ef95a27b54a6e450ee700ccabdf39d:
Merge tag 'drm-msm-fixes-2021-02-25' of
https://gitlab.freedesktop.org/drm/msm in
Hi,
Le lun. 29 mars 2021 à 11:15, Pekka Paalanen a
écrit :
On Sat, 27 Mar 2021 11:26:26 +
Paul Cercueil wrote:
It has two mutually exclusive background planes (same Z level) + one
overlay plane.
What's the difference between the two background planes?
How will generic userspace kno
On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
> On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
> > I really don't think these typo patchbomb are that useful. I'm all
> > for fixing typos when working with a subsystem, but I'm not sure these
> > patchbombs help anything.
>
This is a series of patches developed by Jonathan Marek, and picked up
to split them, so that dts fixes can be picked up into stable branch
Add sm8150/sm8250 compatibles to drm/msm and fix the sm8250
display nodes.
v2: do not remove mmcx-supply from dispcc node
v3: remove references to dp_phy (mi
From: Jonathan Marek
The driver already has support for sm8150/sm8250, but the compatibles were
never added.
Also inverse the non-mdp4 condition in add_display_components() to avoid
having to check every new compatible in the condition.
Signed-off-by: Jonathan Marek
Signed-off-by: Dmitry Barys
From: Jonathan Marek
The driver already has support for sm8150/sm8250, but the compatibles were
never added.
Signed-off-by: Jonathan Marek
Acked-by: Rob Herring
[DB: split dt-bindings into separate patch]
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dpu.t
From: Jonathan Marek
- Use sm8250 compatibles instead of sdm845 compatibles
Signed-off-by: Jonathan Marek
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/a
From: Jonathan Marek
Apply these fixes to the newly added sm8250 display ndoes
- Remove "notused" interconnect (which apparently was blindly copied from
my old patches)
- Use dispcc node example from dt-bindings, removing clocks which aren't
documented or used by the driver and fixing the
Hi
Am 25.03.21 um 12:29 schrieb Hans de Goede:
Hi,
On 3/18/21 11:29 AM, Thomas Zimmermann wrote:
This patchset adds support for simple-framebuffer platform devices and
a handover mechanism for native drivers to take-over control of the
hardware.
The new driver, called simpledrm, binds to a si
On 13:48 Mon 29 Mar 2021, Greg KH wrote:
On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
> I really don't think these typo patchbomb are that useful. I'm all
> for fixing typos when working with a subsystem, but I'm not sure
On Sun, 28 Mar 2021 22:00:56 +0200, Daniel Mack wrote:
> This adds documentation for a new ILI9163 based, SPI connected display.
>
> Signed-off-by: Daniel Mack
> ---
> .../display/panel/ilitek,ili9163.yaml | 69 +++
> 1 file changed, 69 insertions(+)
> create mode 100644
On Tue, Mar 16, 2021 at 04:33:01PM +0100, Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range w
On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> follow_pte()")) have lost their callsites of follow_pfn(). All the
> other ones have been switched over
Hello Mikita Lipski,
The patch 04111850cf56: "drm/amd/display: Reuse parsing code of
debugfs write buffer" from Mar 26, 2020, leads to the following
static checker warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:80
parse_write_buffer_into_params()
err
v2 of [1], addressing Ville's review comments, and adding a couple of
extra patches on top.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/87802/
Jani Nikula (8):
drm/edid: make a number of functions, parameters and variables const
drm/displayid: add separate drm_displayid.c
drm/d
If there's no need to change it, it should be const. There's more to be
done, but start off with changes that make follow-up work easier. No
functional changes.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 58 ++---
incl
We'll be adding more DisplayID specific functions going forward, so
start off by splitting out a few functions to a separate file.
We don't bother with exporting the functions; at least for now they
should be needed solely within drm.ko.
No functional changes.
Reviewed-by: Ville Syrjälä
Signed-
Iterating DisplayID blocks across sections (in EDID extensions) is
unnecessarily complicated for the caller. Implement DisplayID iterators
to go through all blocks in all sections.
Usage example:
const struct displayid_block *block;
struct displayid_iter iter;
displayid_i
Neatly reduce displayid boilerplate in code. No functional changes.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_
Neatly reduce displayid boilerplate in code. No functional changes.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/dr
Neatly reduce displayid boilerplate in code. Remove excessive debug
logging while at it, no other functional changes.
The old displayid iterator becomes unused; remove it as well as make
drm_find_displayid_extension() static.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gp
The DisplayID specifications explicitly call out 0 as a valid payload
length for data blocks. The mere presence of a data block, or the
information coded in the block specific data (bits 7:3 in offset 1), may
be enough to convey the necessary information.
Signed-off-by: Jani Nikula
---
drivers/g
Avoid any confusion with High Dynamic Range. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 10 +-
include/drm/drm_displayid.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gp
Show the number of pending waiters in the debugfs status file.
This is useful for testing to verify that waiters do not leak
or accumulate incorrectly.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/debug.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git
This is the first part of the Host1x/TegraDRM UAPI series, split out
into a separate series that should be easier to merge. It contains
a number of Host1x-related cleanups and fixes. In addition to the
previous series there are a couple of new fixes.
Tested on Jetson TX2.
Thanks,
Mikko
Jon Hunte
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen
---
v6:
- Update kerneldoc
---
drivers/gpu/host1x/bus.c | 10 ++
include/linux/host1x.h | 9 -
2 files changed, 14 insert
Syncpoints don't need to be associated with any client,
so remove the property, and expose host1x_syncpt_alloc.
This will allow allocating syncpoints without prior knowledge
of the engine that it will be used with.
Signed-off-by: Mikko Perttunen
---
v6:
* Add kerneldoc
* Return error if a NULL na
Make syncpoint expiration checks always use the same logic used by
the hardware. This ensures that there are no race conditions that
could occur because of the hardware triggering a syncpoint interrupt
and then the driver disagreeing.
One situation where this could occur is if a job incremented a
Move the assignment of the ref out-pointer in host1x_intr_add_action
to happen within the spinlock. With the current arrangement,
it is possible for the waiter to complete before the assignment
has happened, which breaks horribly if the waiter completion
callback tries to use the reference.
In pra
Before this patch, cancelled waiters would only be cleaned up
once their threshold value was reached. Make host1x_intr_put_ref
process the cancellation immediately to fix this.
Signed-off-by: Mikko Perttunen
---
v6:
* Call schedule instead of cpu_relax while waiting for pending
interrupt proces
Add reference counting for allocated syncpoints to allow keeping
them allocated while jobs are referencing them. Additionally,
clean up various places using syncpoint IDs to use host1x_syncpt
pointers instead.
Signed-off-by: Mikko Perttunen
---
v5:
- Remove host1x_syncpt_put in submit code, as jo
With job recovery becoming optional, syncpoints may have a mismatch
between their value and max value when freed. As such, when freeing,
set the max value to the current value of the syncpoint so that it
is in a sane state for the next user.
Signed-off-by: Mikko Perttunen
---
v3:
* Use host1x_syn
On T20-T148 chips, the bootloader can set up a boot splash
screen with DC configured to increment syncpoint 26/27
at VBLANK. Because of this we shouldn't allow these syncpoints
to be allocated until DC has been reset and will no longer
increment them in the background.
As such, on these chips, res
From: Jon Hunter
Syncpoint interrupts are not working as expected on Tegra194. The
problem is that the syncpoint interrupt threshold being used is the
global interrupt threshold and not the virtual interrupt threshold.
Fix this by using the virtual interrupt threshold which aligns with
downstream
https://bugzilla.kernel.org/show_bug.cgi?id=212469
Francesco Minnocci (ascoli.minno...@gmail.com) changed:
What|Removed |Added
CC||ascoli.mi
Hi, Daniel:
Daniel Thompson 於 2021年3月29日 週一 下午6:26寫道：
>
> On Sun, Mar 28, 2021 at 11:24:19PM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Adds support for Richtek RT4831 backlight.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > since v6
> > - Fix Kconfig typo.
> > - Remove internal
From: Colin Ian King
In the case where !sg_dma_len(sgl) breaks out of the do-while loop
on the first iteration, error variable err has not been assigned
any value and will contain garbage. Fix this by ensuring err is
initialized to zero.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixe
On Sat, Mar 27, 2021 at 11:22:14AM +, Paul Cercueil wrote:
> The ingenic-drm driver has two mutually exclusive primary planes
> already; so the fact that a CRTC must have one and only one primary
> plane is an invalid assumption.
I mean, no? It's been documented for a while that a CRTC should
On Monday, March 29th, 2021 at 4:07 PM, Maxime Ripard wrote:
> Since it looks like you have two mutually exclusive planes, just expose
> one and be done with it?
You can expose the other as an overlay. Clever user-space will be able
to figure out that the more advanced plane can be used if the p
On Mon, 29 Mar 2021 13:57:23 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
>
> Signed-off-by: Liu Ying
> ---
> v8->v9:
> * Reference 'interrupts-extended' schema instead of 'interrupts' to require
> an additional interrupt(r_rtram_stall) bec
On Mon, 29 Mar 2021 12:41:00 +0100
Paul Cercueil wrote:
> Hi,
>
> Le lun. 29 mars 2021 à 11:15, Pekka Paalanen a
> écrit :
> > On Sat, 27 Mar 2021 11:26:26 +
> > Paul Cercueil wrote:
> >
> >> It has two mutually exclusive background planes (same Z level) + one
> >> overlay plane.
>
On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> the GPU from wedging and then sometimes wedging the kernel after a
> page fault), but it doesn't have separate pagetables support yet in
> drm/msm so we can't go all
Hi,
On 3/29/21 2:31 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 25.03.21 um 12:29 schrieb Hans de Goede:
>> Hi,
>>
>> On 3/18/21 11:29 AM, Thomas Zimmermann wrote:
>>> This patchset adds support for simple-framebuffer platform devices and
>>> a handover mechanism for native drivers to take-over cont
Hi Maxime,
Le lun. 29 mars 2021 à 16:07, Maxime Ripard a
écrit :
On Sat, Mar 27, 2021 at 11:22:14AM +, Paul Cercueil wrote:
The ingenic-drm driver has two mutually exclusive primary planes
already; so the fact that a CRTC must have one and only one primary
plane is an invalid assumptio
Le lun. 29 mars 2021 à 17:35, Pekka Paalanen a
écrit :
On Mon, 29 Mar 2021 12:41:00 +0100
Paul Cercueil wrote:
Hi,
Le lun. 29 mars 2021 à 11:15, Pekka Paalanen
a
écrit :
> On Sat, 27 Mar 2021 11:26:26 +
> Paul Cercueil wrote:
>
>> It has two mutually exclusive background
On 3/12/21 10:55 AM, Brian Starkey wrote:
(Adding back James again - did you use get_maintainer.pl?)
On Thu, Mar 11, 2021 at 12:08:46PM +, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
When setting up a readback connector that writes data back to memory
rather than to an act
Applied. Thanks!
Alex
On Fri, Mar 26, 2021 at 10:59 AM Harry Wentland wrote:
>
>
>
> On 2021-03-24 4:23 p.m., Alex Deucher wrote:
> > On Wed, Mar 17, 2021 at 11:25 AM Werner Sembach
> > wrote:
> >>
> >> When encoder validation of a display mode fails, retry with less bandwidth
> >> heavy YCbC
Hi Simon,
Le lun. 29 mars 2021 à 14:11, Simon Ser a écrit
:
On Monday, March 29th, 2021 at 4:07 PM, Maxime Ripard
wrote:
Since it looks like you have two mutually exclusive planes, just
expose
one and be done with it?
You can expose the other as an overlay. Clever user-space will be a
Applied. Thanks!
Alex
On Sun, Mar 28, 2021 at 1:35 AM Diego Viola wrote:
>
> Signed-off-by: Diego Viola
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/dri
On Mon, Mar 29, 2021 at 04:15:28PM +0100, Paul Cercueil wrote:
> Hi Maxime,
>
> Le lun. 29 mars 2021 à 16:07, Maxime Ripard a écrit :
> > On Sat, Mar 27, 2021 at 11:22:14AM +, Paul Cercueil wrote:
> > > The ingenic-drm driver has two mutually exclusive primary planes
> > > already; so the f
On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil
wrote:
> Making the second plane an overlay would break the ABI, which is never
> something I'm happy to do; but I'd prefer to do it now than later.
Yeah, I wonder if some user-space depends on this behavior somehow?
> I still have concerns
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the s
The mtk_hdmi does not support creating a bridge with a connector.
Therefore the field 'conn' should be removed from the mtk_hdmi struct.
It is replaced with a pointer curr_conn that points to the current
connector which can be access through the global state.
Signed-off-by: Dafna Hirschfeld
---
https://bugzilla.kernel.org/show_bug.cgi?id=212469
Amir (amirg...@criptext.com) changed:
What|Removed |Added
Kernel Version|5.11.6 |5.11.10
--
You may reply
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
These three patches fix that by adding support for
commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTO
Le lun. 29 mars 2021 à 17:35, Maxime Ripard a
écrit :
On Mon, Mar 29, 2021 at 04:15:28PM +0100, Paul Cercueil wrote:
Hi Maxime,
Le lun. 29 mars 2021 à 16:07, Maxime Ripard a
écrit :
> On Sat, Mar 27, 2021 at 11:22:14AM +, Paul Cercueil wrote:
> > The ingenic-drm driver has two
On Monday, March 29th, 2021 at 5:39 PM, Paul Cercueil
wrote:
> Ok, I read that as "all drivers should provide AT LEAST one primary
> plane per CRTC", and not as "all drivers should provide ONE AND ONLY
> ONE primary plane per CRTC". My bad.
Yeah, it's a little complicated to document, because i
Hi,
On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > > wrote:
> > > >
> > > > On Wed, Mar 17, 2021 at 06:53:04PM -070
Hi,
On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding wrote:
>
> The point remains that unless we describe exactly which panel we're
> dealing with, we ultimately have no way of properly quirking anything if
> we ever have to.
Just to clarify here: with my initial proposal we actually could still
q
Le lun. 29 mars 2021 à 15:42, Simon Ser a écrit
:
On Monday, March 29th, 2021 at 5:39 PM, Paul Cercueil
wrote:
Ok, I read that as "all drivers should provide AT LEAST one primary
plane per CRTC", and not as "all drivers should provide ONE AND ONLY
ONE primary plane per CRTC". My bad.
Le dim. 28 mars 2021 à 1:05, Laurent Pinchart
a écrit :
Hi Paul,
Thank you for the patch.
On Sat, Mar 27, 2021 at 11:57:41AM +, Paul Cercueil wrote:
This performs the same operation as drmm_encoder_alloc(), but
only allocates and returns a struct drm_encoder instance.
v4: Rename m
Applied to mediatek-drm-next [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
Chun-Kuang Hu 於 2021年3月13日 週六 下午5:43寫道：
>
> While updating config, the irq would occur and get the partial
> config, so use variable config
Hi,
On Thu, Mar 25, 2021 at 5:09 PM Rob Herring wrote:
>
> On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > The sc7180-trogdor-pompom board might be attached to any number of a
> > pile of eDP panels. At the moment I'm told that the list might include:
> > - KD KD116N21-30NV-
On Sat, Mar 27, 2021 at 3:28 AM Wan Jiabing wrote:
>
> struct dc_state has been declared at 273rd line.
> Remove the duplicate.
> Delete duplicate blank lines.
Can you split these into separate patches?
Alex
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/gpu/drm/amd/display/dc/dc.h | 10 -
On 2021-03-29 3:54 a.m., Louis Li wrote:
[Why]
This issue is found when scaling is not equal to one from src to dest.
When issue happens, there are offsets in both axis x and y between
two cursors. Users cannot control APP under such a condition.
What's the use case? I don't think we support t
Hi,
A set of two fixes for the IPU plane of the ingenic-drm driver.
Patch [1/2] changes the type of the IPU plane from PRIMARY to OVERLAY,
since there can only be one PRIMARY plane per CRTC.
Patch [2/2] enforces that a full modeset is only performed when the
"sharpness" property is modified.
Ch
It should have been an OVERLAY from the beginning. The documentation
stipulates that there should be an unique PRIMARY plane per CRTC.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +---
Avoid requesting a full modeset if the sharpness property is not
modified, because then we don't actually need it.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 4 +++-
1 file changed, 3 insertion
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
>
> On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> > the GPU from wedging and then sometimes wedging the kernel after a
> > page fault), but it doesn't have s
Free transfer and compression buffers on device removal instead of at
DRM device removal time. This ensures that the usual 2x8MB buffers are
released when the device is unplugged and not kept around should
userspace keep the DRM device fd open.
At least Ubuntu 20.04 doesn't release the DRM device
There'a limit to how big a kmalloc buffer can be, and as memory gets
fragmented it becomes more difficult to get big buffers. The downside of
smaller buffers is that the driver has to split the transfer up which
hampers performance. Compression might also take a hit because of the
splitting.
Solve
On Mon, Mar 29, 2021 at 6:27 AM Xin Ji wrote:
>
> On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji wrote:
> > >
> > > Add HDCP feature, enable HDCP function through chip internal key
> > > and downstream's capability.
> > >
> > > Signed-off-by:
Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than the initial value will be assigned to it. That causes
`start > last + 1` after line 1708. Then
Am 29.03.21 um 20:08 schrieb Xi Ruoyao:
On 2021-03-29 20:04 +0200, Christian König wrote:
Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than the
Hi Stephen,
thanks for the report.
On Mon, Mar 29, 2021 at 09:01:17AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 26 Mar 2021 19:58:38 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-intel-fixes tree, today's linux-next build
> > (htmldocs) produced this warning:
> >
>
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
This is v3 of the series.
Changelog:
v2 -> v3:
* Turn Documentation into yaml format
v3 -> v4:
* Fix reference error in yaml file
v4 -> v5:
* More yaml file documentation fixes
v5 -> v6:
* More yaml file documentation fixes
Daniel Mack (2):
dt-bindings: displ
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
This is v3 of the series.
Changelog:
v2 -> v3:
* Turn Documentation into yaml format
v3 -> v4:
* Fix reference error in yaml file
v4 -> v5:
* More yaml file documentation fixes
v5 -> v6:
* More yaml file documentation fixes
v6 -> v7:
* Fix ordering of p
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
Quoting Dmitry Baryshkov (2021-03-29 05:00:50)
> From: Jonathan Marek
>
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Also inverse the non-mdp4 condition in add_display_components() to avoid
> having to check every new compatible in the condition
Quoting Dmitry Baryshkov (2021-03-29 05:00:49)
> From: Jonathan Marek
>
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Signed-off-by: Jonathan Marek
> Acked-by: Rob Herring
> [DB: split dt-bindings into separate patch]
> Signed-off-by: Dmitry Ba
Quoting Dmitry Baryshkov (2021-03-29 05:00:51)
> From: Jonathan Marek
>
> - Use sm8250 compatibles instead of sdm845 compatibles
>
Does it need the " - " prefix?
> Signed-off-by: Jonathan Marek
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
_
Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
Hi Christian,
I don't think there is any constraint implemented to ensure `num_entries %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`:
/* validate the parameters */
if (saddr & AMDGPU_GPU_PAGE_MASK || offset
On Mon, Mar 29, 2021 at 04:37:21PM +0300, Jani Nikula wrote:
> The DisplayID specifications explicitly call out 0 as a valid payload
> length for data blocks. The mere presence of a data block, or the
> information coded in the block specific data (bits 7:3 in offset 1), may
> be enough to convey t
On Mon, Mar 29, 2021 at 04:37:22PM +0300, Jani Nikula wrote:
> Avoid any confusion with High Dynamic Range. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_displayid.c | 10 +-
> include/drm/drm_displayid.h | 2 +-
> 2
1 - 100 of 177 matches
Mail list logo
