On Wed, Sep 1, 2021 at 3:15 AM Tetsuo Handa
wrote:
> syzbot is reporting page fault at vga16fb_fillrect() [1], for
> vga16fb_check_var() is failing to detect multiplication overflow.
>
> if (vxres * vyres > maxmem) {
> vyres = maxmem / vxres;
> if (vyres < yres)
> return -ENOMEM;
>
Am 31.08.21 um 15:18 schrieb Daniel Vetter:
On Tue, Aug 31, 2021 at 01:21:07PM +0200, Christian König wrote:
More flexible than the busy placements.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 8 +++-
include/drm/ttm/ttm_placement.h | 6 ++
2 files changed,
The seqno-fence was removed, cleanup the kerneldoc include as well.
Signed-off-by: Christian König
Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence")
---
Documentation/driver-api/dma-buf.rst | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documenta
Hi Monk,
On Wed, Sep 1, 2021 at 3:23 AM Liu, Monk wrote:
>
> [AMD Official Use Only]
>
>
> Hi Daniel/Christian/Andrey
>
>
>
> It looks the voice from you three are spread over those email floods to me,
> the feature we are working on (diagnostic TDR scheme) is pending there for
> more than 6 mo
This series adds support for multi hardware decode into mtk-vcodec, by first
adding component framework to manage each hardware information: interrupt,
clock, register bases and power. Secondly add core thread to deal with core
hardware message, at the same time, add msg queue for different hardwar
Vdec and venc can use the same function to wake up interrupt event.
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 9 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 8
drivers/media/platform/mtk-vco
Different platform may has different numbers of register bases. Gets the
numbers of register bases from DT (sizeof(u32) * 4 bytes for each).
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 37 ++-
1 file changed, 28 insert
Decoder will use component framework to manage hardware, it is big
difference with encoder.
Reviewed-by: Rob Herring
Signed-off-by: Yunfei Dong
---
.../media/mediatek,vcodec-decoder.yaml| 175 +
.../media/mediatek,vcodec-encoder.yaml| 185 ++
.../b
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 22 --
Uses component framework to manage each hardware information which
includes irq/power/clk. The hardware includes LAT0, LAT1 and CORE.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcod
Separates different architecture for hardware: pure_sin_core
and lat_sin_core. MT8183 is pure single core. Uses .hw_arch to
distinguish.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 1 +
dr
Adds irq interface for multi hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 33 +--
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 25 ++
.../platform/mtk-vcodec/mtk_vcod
Generalizes power and clock on/off interfaces to support different hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 4 +
.../platform/mtk-vcodec/
For lat and core architecture, lat thread will send message to core
thread when lat decode done. Core hardware will use the message
from lat to decode, then free message to lat thread when decode done.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../plat
Core thread:
1. Gets lat_buf from core msg queue.
2. Proceeds core decode.
3. Puts the lat_buf back to lat msg queue.
Both H264 and VP9 rely on the core thread.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 12 +++
.../platform/mtk-vcodec/mtk_vcodec_drv.h
For add new hardware, not only need to lock lat hardware, also
need to lock core hardware in case of different instance start
to decoder at the same time.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++--
drivers/media/platform/mtk-vcodec/mtk_vcodec_
Add core dec and dec end ipi msg: AP_IPIMSG_DEC_CORE/AP_IPIMSG_DEC_CORE_END.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 4
.../media/platform/mtk-vcodec/vdec_vpu_if.c| 12
.../media/platform/mtk-vcodec/vdec_vpu_if.h| 18
Adds decoder dt-bindings for mt8192.
Signed-off-by: Yunfei Dong
---
v6: add decoder block diagram for Laurent's comments.
This patch depends on "Mediatek MT8192 clock support"[1].
The definition of decoder clocks are in mt8192-clk.h, and this patch already in
clk tree[1].
[1]https://git.kerne
There are just one core thread, in order to separeate different
hardware, using codec type to separeate it in scp driver.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 ---
.../media/p
Use the dma_set_mask_and_coherent helper to set vdec
DMA bit mask to support 34bits iova space(16GB) that
the mt8192 iommu HW support.
Whole the iova range separate to 0~4G/4G~8G/8G~12G/12G~16G,
regarding which iova range VDEC actually locate, it
depends on the dma-ranges property of vdec dtsi nod
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 might also impact
> > DTs that have not yet been upstreamed,
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
> > never use global clock names anymore but require the
On 8/31/21 2:35 PM, Daniel Vetter wrote:
> On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
[snip]
>>
>> We talked about a drmcon with Peter Robinson as well but then decided that a
>> way to disable CONFIG_FB but still having the DRM fbdev emulation could be a
>> interme
The Advantech IDK-2121WR Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam
The Advantech IDK-2121WR Device Tree binding uses most of the panel-lvds
binding, aside from a requirement on the data-mapping and the
definition of the dual link binding.
The LVDS dual link binding applies to any panel with a dual-link setup,
and thus could be made generic, and we can move the da
The Innolux EE101IA-01D Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Ma
The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply
property. However, neither the existing device trees using that binding,
nor the driver were actually using that property which is also redundant
with power-supply. Let's just drop it.
Cc: dri-devel@lists.freedesktop.org
Cc: L
The Mitsubishi AA140XD12 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bin
The Mitsubishi AA104XD12 Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam
The Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply
property. However, neither the existing device trees using that binding,
nor the driver were actually using that property which is also redundant
with power-supply. Let's just drop it.
Cc: dri-devel@lists.freedesktop.org
Cc: L
The Mitsubishi AA121TD01 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bin
The Mitsubishi AA121TD01 Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam
A few panel-lvds compatibles were never documented. Let's add them.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/panel/lvds.yaml | 2 ++
1 file changed, 2 insertions(+)
The Solomon Goldentek Display GKTW70SDAE4SE Device Tree binding doesn't
really add any useful content that is not already present in the
panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent
On Tue, Aug 31, 2021 at 09:59:03PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Applied, thanks
Maxime
signature.asc
Description: PGP signature
On Tue, Aug 31, 2021 at 09:57:39PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Applied, thanks
Maxime
signature.asc
Description: PGP signature
On Wed, Sep 01, 2021 at 11:13:01AM +0800, Chen-Yu Tsai wrote:
> On Wed, Sep 1, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> >
> > Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
> > recommendation of having arguments enclosed in parenthesis. While that
> > didn't change anything for
Hi, Jason,
A quick question below:
On 7/23/21 7:21 PM, Jason Ekstrand wrote:
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also lo
[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 before they are
>merged to kernel tree I'm wondering if any AMD develop reviewed them ?
They looks to me somehow conflicting wi
[AMD Official Use Only]
>> For me your project exists since a few weeks at most, because that is when
>> your team showed up on dri-devel. That you already spent 6 months on this
>> within amd, on a code area that very much affects shared code, without
>> kicking of any thread on dri-devel isn'
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
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
Reviewed-by: Rob Herring
---
.../bindings/display/ilitek,ili9163.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/
This is v9 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
On 31/08/2021 14:57, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
On Tue, Aug 31, 2021 at 03:43:19PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Acked-by: Liviu Dudau
Many thanks,
Liviu
> ---
> drivers/gpu/drm
On 31/08/2021 08:54, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +---
>
Am 01.09.21 um 13:20 schrieb Gal Pressman:
On 24/08/2021 20:32, Jason Gunthorpe wrote:
On Tue, Aug 24, 2021 at 10:27:23AM -0700, John Hubbard wrote:
On 8/24/21 2:32 AM, Christian König wrote:
Am 24.08.21 um 11:06 schrieb Gal Pressman:
On 23/08/2021 13:43, Christian König wrote:
Am 21.08.2
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/v3d/v3d_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/v3d
On 31/08/2021 14:35, Boris Brezillon wrote:
> The labels are misleading. Even though they are all prefixed with 'fail_'
> the success case also takes that path, and we should definitely not
> cleanup the job if it's been queued. While at it, let's rename those
> labels so we don't do the same mista
Hi guys,
while it is in most cases technically possible to not have a reference to the
dma_fence when adding a callback it is usually a good idea to make sure to
always have a reference anyway.
Otherwise we can indeed see cases where this doesn't really work as intended
like for example in the
This callback is pretty much deprecated and should not be used by new
implementations.
Clarify that in the documentation as well.
Signed-off-by: Christian König
---
include/linux/dma-fence.h | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/linux/dma-fence.
That the caller doesn't need to keep a reference is rather
risky and not defensive at all.
Especially dma_buf_poll got that horrible wrong, so better
remove that sentence and also clarify that the callback
might be called in atomic or interrupt context.
Signed-off-by: Christian König
---
driver
Hi,
On Tue, Aug 31, 2021 at 11:30 AM Jani Nikula wrote:
>
> On Tue, 17 Aug 2021, Anisse Astier wrote:
> > The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> > used for the embedded display. Add support for using it via by adding
> > the EDID to the list of available modes on
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 relate to the vpu driver not the scp driver.
Is there a corresponding code added to the vpu driver that test the
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #41 from kolAflash (kolafl...@kolahilft.de) ---
I can confirm Jeromes result.
Bug is gone with pci=noats.
(Debian-11 kernel 5.10.0-8-amd64)
I ran 50 suspend/standby rounds.
Also I used the notebook for 2 days and suspended it multipl
On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote:
> 01.07.2021 21:14, Thierry Reding пишет:
> > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote:
> >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote:
> >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Her
Hi Daniel,
>
> I think for a substantial improvement here in robustness what you really
> want is
> - kmscon in userspace
> - disable FB layer
> - ideally also disable console/vt layer in the kernel
> - have a minimal emergency/boot-up log thing in drm, patches for that
> floated around a few t
Hi Daniel,
On Wed, Sep 01, 2021 at 12:30:38PM +0200, Daniel Mack wrote:
> This is v9 of the series.
>
> Changelog:
>
> v2 -> v3:
> * Turn Documentation into yaml format
...
> Daniel Mack (2):
> dt-bindings: display: add bindings for newhaven,1.8-128160EF
> drm/tiny: add driver for ne
Hi Christian,
On Wed, 1 Sept 2021 at 13:30, Christian König
wrote:
>
> The seqno-fence was removed, cleanup the kerneldoc include as well.
>
> Signed-off-by: Christian König
> Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence")
Thanks for fixing; LGTM, please feel free to add my
Acked-by: Sumit Se
For the drivers/net/wireguard part,
Reviewed-by: Jason A. Donenfeld
drm/panfrost: Dual licence the Mali GPU headers in GPL-2 and MIT.
Signed-off-by: Ruslan Bukin
diff --git a/drivers/gpu/drm/panfrost/panfrost_features.h
b/drivers/gpu/drm/panfrost/panfrost_features.h
index 5056777c7744..23c4973c377f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_feat
On Mon, Aug 2, 2021 at 3:47 PM Yongqiang Niu wrote:
>
> Change since v5:
> -rebase on linux 5.14-rc1
>
> Yongqiang Niu (3):
> dt-binding: gce: add gce header file for mt8192
> arm64: dts: mt8192: add gce node
> mailbox: cmdq: add mt8192 support
Looks like all the driver parts are in -next,
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 before they are
> merged to kernel tree I'm wondering if any AMD devel
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 to do in the migration helpers.
>>> It looks like I'm totally misundersta
On Tue, Aug 31, 2021 at 03:01:51PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> > > +}
> > > +
> > > +void intel_pxp_invalidate(struct intel_pxp *pxp)
> > > +{
> > > + struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
> > > + struct i915_gem_context *ctx, *cn;
> > > +
> > > + /* ban all context
Hi Sam,
On 9/1/21 4:20 PM, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Wed, Sep 01, 2021 at 12:30:38PM +0200, Daniel Mack wrote:
>> This is v9 of the series.
>>
>> Changelog:
>>
>> v2 -> v3:
>> * Turn Documentation into yaml format
>
> ...
>
>> Daniel Mack (2):
>> dt-bindings: display: add b
On Fri, Aug 27, 2021 at 06:27:35PM -0700, Daniele Ceraolo Spurio wrote:
> From: Anshuman Gupta
>
> When protected sufaces has flipped and pxp session is disabled,
> display black pixels by using plane color CTM correction.
>
> v2:
> - Display black pixels in async flip too.
>
> v3:
> - Removed
This is v10 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
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
Reviewed-by: Rob Herring
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display
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
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9
On Fri, Aug 27, 2021 at 06:27:34PM -0700, Daniele Ceraolo Spurio wrote:
> From: Anshuman Gupta
>
> Add support to enable/disable PLANE_SURF Decryption Request bit.
> It requires only to enable plane decryption support when following
> condition met.
> 1. PXP session is enabled.
> 2. Buffer object
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
>
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 rcar_du_ou
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 comp
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
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
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 inp
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 +
drivers/gpu/drm
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
a/D
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 +
.../gpu/drm/
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 +
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
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
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 fi
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-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
---
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 b/dri
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 sai
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
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 +
drivers/g
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 a/Do
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
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 (f
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.
https://
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 be
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 amdgpu_ras_ee
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
> > ---
> >
> > .../bindings/display/s
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
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 specified
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
drive
1 - 100 of 178 matches
Mail list logo
