On Thu, Jul 7, 2022 at 5:37 AM Javier Martinez Canillas
wrote:
>
> Hello Ezequiel,
>
> Thanks a lot for your patch.
>
> On 7/6/22 20:41, Ezequiel Garcia wrote:
> > Fix small typo which causes the mask for the 'precharge1' setting
> > to be used with the &
Fix small typo which causes the mask for the 'precharge1' setting
to be used with the 'precharge2' value.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.
Hi Yunfei,
On Tue, 16 Nov 2021 at 08:42, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Thanks for you suggestion.
> On Sun, 2021-11-14 at 19:04 -0300, Ezequiel Garcia wrote:
> > Hi Yunfei,
> >
> > On Thu, 11 Nov 2021 at 01:15, Yunfei Dong
> > wrot
Hi Yunfei,
On Thu, 11 Nov 2021 at 01:15, Yunfei Dong wrote:
>
> This series adds support for multi hardware decode into mtk-vcodec, by first
> adding use
> of_platform_populate to manage each hardware information: interrupt, clock,
> register
> bases and power. Secondly add core work queue to d
Yunfei,
On Thu, 11 Nov 2021 at 01:15, Yunfei Dong wrote:
>
> Adds decoder dt-bindings for mt8192.
>
> Signed-off-by: Yunfei Dong
> ---
> .../media/mediatek,vcodec-subdev-decoder.yaml | 261 ++
> 1 file changed, 261 insertions(+)
> create mode 100644
> Documentation/devicetree/
Hi Yunfei,
On Tue, 12 Oct 2021 at 22:17, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Thanks for your feedback,
>
> The driver can work well now according to your advice with
> of_platform_populate interface.
>
> In order to separate parent node with children node, parent node is
> master
Hi Yunfei,
On Mon, Oct 11, 2021 at 03:02:43PM +0800, Yunfei Dong wrote:
> 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.
>
Avoid the kthread API and instead go with the wo
On Sun, 26 Sept 2021 at 05:27, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Could you please help to give some feedback when you are free for iommu
> limitation?
>
How about you work on the architecture I originally suggested?
As the saying goes, talk is cheap, show us the code.
So let's
On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote:
>
> 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 me
-rM=8...@mail.gmail.com/
> Cc: Ezequiel Garcia
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Daniel Vetter
> ---
> MAINTAINERS | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ac58d0032a
On Sun, 22 Aug 2021 at 13:50, Daniel Vetter wrote:
>
> On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia
> wrote:
> >
> > +danvet
> >
> > Hi,
> >
> > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote:
> > >
> > > This series adds sup
On Fri, 20 Aug 2021 at 04:59, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Thanks for your detail feedback.
>
> On Thu, 2021-08-19 at 11:10 -0300, Ezequiel Garcia wrote:
> > On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com
> > wrote:
> > >
&g
On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Thanks for your suggestion.
>
> On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia wrote:
> > +danvet
> >
> > Hi,
> >
> > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong
+danvet
Hi,
On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote:
>
> 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
Hi Alex,
On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote:
> Hi Ezequiel,
>
> Am 26.06.21 um 02:46 schrieb Ezequiel Garcia:
> > (Adding Nicolas)
> >
> > Hi Alex,
> >
> > On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
> > > Hi Ezequiel,
&g
Hi Alex,
On Fri, 2021-06-25 at 00:39 +0200, Alex Bee wrote:
> Hi Ezequiel,
>
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > From: Paul Kocialkowski
> >
> > The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> > to the RK3399 (Han
Hey Dafna,
Thanks a lot for reviewing this.
On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote:
> Hi,
>
> On 24.06.21 21:26, Ezequiel Garcia wrote:
> > From: Paul Kocialkowski
> >
> > The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2
(Adding Nicolas)
Hi Alex,
On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote:
> Hi Ezequiel,
>
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > Given H.264 support for VDPU2 was just added, let's enable it.
> > For now, this is only enabled on platform that don'
From: Jonas Karlman
Rockchip VDPU2 core is present on RK3328, RK3326/PX30, RK3399
and others. It's similar to Hantro G1, but it's not compatible with it.
Signed-off-by: Jonas Karlman
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/Makefile | 1 +
drive
The hantro_variant.init() function is there for platforms
to perform hardware-specific initialization, such as
clock rate bumping.
Not all platforms require it, so make it optional.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro.h | 4 ++--
drivers/staging
Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on platform that don't have
an RKVDEC core, such as RK3328.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/rockchip_vpu_hw.c| 26 ++-
1 file changed, 25 insert
Add a hantro_h264_get_ref_nbr() helper function to get the reference
picture numbers. This will be used by the Rockchip VDPU2 H.264 driver.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_g1_h264_dec.c | 14 ++
drivers/staging/media/hantro/hantro_h264.c
From: Paul Kocialkowski
The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2)
and an encoder (VEPU2).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++
1 file changed, 3 insertions(+)
diff
From: Paul Kocialkowski
The PX30 has a VPU (both decoder and encoder) with a dedicated IOMMU.
Describe these two entities in device-tree.
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 23 +++
1 file changed
The Odroid Go Advance panel is rotated, so let's reflect this
in the device tree.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
b/arch/arm64/boo
On Thu, 2021-06-24 at 20:37 +0200, Heiko Stübner wrote:
> Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia:
> > The Odroid Go Advance panel is rotated, so let's reflect this
> > in the device tree.
> >
> > Signed-off-by: Ezequiel Garcia
>
Getting the next src/dst buffer is relatively expensive
so avoid doing it multiple times.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 17 -
.../staging/media/hantro/hantro_g1_vp8_dec.c | 18 +-
.../media/hantro
From: Paul Kocialkowski
The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c | 1 +
drivers/staging
In order to reuse these bitmaps, move this process to
struct hantro_h264_dec_hw_ctx. This will be used by
the Rockchip VDPU2 H.264 driver.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 17 ++---
drivers/staging/media/hantro/hantro_h264.c
When the VP8 decoders can't find a reference frame,
the driver falls back to the current output frame.
This will probably produce some undesirable results,
leading to frame corruption, but shouldn't cause
noisy warnings.
Signed-off-by: Ezequiel Garcia
Acked-by: Nicolas Dufresne
--
Parse the device tree rotation specifier, and set a DRM
connector orientation property. The property can then be read
by compositors to apply hardware plane rotation or a GPU transform.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
1 file changed
res=9, errors=54)
[1]
https://lore.kernel.org/linux-media/he1pr06mb40119de07d38060f531d1070ac...@he1pr06mb4011.eurprd06.prod.outlook.com/
[2] https://lore.kernel.org/patchwork/cover/1361795/
Ezequiel Garcia (8):
drm/panel: kd35t133: Add panel orientation support
arm64: dts: rockchip: Add
Hi Neil,
On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote:
>
> Hi,
>
> On 21/04/2021 07:28, Nicolas Boichat wrote:
> > Hi!
> >
> > This is just a rebase of the v11, untested (but it seems like
> > Neil Armstrong recently tested it), with small changes in
> > binding and dts. v11 cover follows:
("drm/bridge/synopsys: dsi: add support for
non-continuous HS clock")
Cc: sta...@vger.kernel.org # 5.10+
With this fix, my Odroid Go2 has display.
Tested-by: Ezequiel Garcia
Thanks,
Ezequiel
> Signed-off-by: Heiko Stuebner
> ---
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 +
On Fri, 19 Feb 2021 at 00:14, Chris Morgan wrote:
>
> This fixes an issue with the panel not working after
> commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for
> non-continuous HS clock").
> With this change the panel inits successfully and displays an image.
>
> Signed-off-by: Chris
(Now with Heiko's address fixed)
On Sat, 13 Feb 2021 at 10:53, Ezequiel Garcia
wrote:
>
> Hi Chris,
>
> I'm hijacking this discussion a bit.
>
> I recently tried to boot maline on my Odroid GOA, which I managed to do,
> except the display wasn't displaying an
Hi Chris,
I'm hijacking this discussion a bit.
I recently tried to boot maline on my Odroid GOA, which I managed to do,
except the display wasn't displaying anything :-)
Everything looks good on a quick look, the Inno PHY driver is here,
and there's a DRM card registered with the right mode 320x
Hello everyone,
(Adding some Hantro developers)
On Fri, 9 Oct 2020 at 19:15, Daniel Vetter wrote:
>
> On Fri, Oct 09, 2020 at 07:57:52PM +0800, kuhanh.murugasen.krish...@intel.com
> wrote:
> > From: "Murugasen Krishnan, Kuhanh"
> >
> > This is a new DRM media codec driver for Intel's Keem Bay
On Thu, 10 Sep 2020 at 04:54, H. Nikolaus Schaller wrote:
>
> Hi Ezequiel,
>
> > Am 27.08.2020 um 09:21 schrieb H. Nikolaus Schaller :
> >
> > Hi Ezequiel,
> >
> >> Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia
> >> :
> >>
> >
* Ezequiel Garcia
* James Jones
* John Reitan
* Laura Abbott
* Laurent Pinchart
* Sumit Semwal
* Robert Beckett
# Replacing subsystem memory allocators with dma-buf heaps
* Laurent: we should not have subsystem implement their own allocator.
Using heaps could be a good idea.
* Laura: Wary to
Hi Paul,
On Thu, 27 Aug 2020 at 09:04, Paul Cercueil wrote:
>
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
>
> Fi
Hi Leon, Shuah,
Thanks for the fix. I had this issue pending to fix,
but have been lazy about it, I appreciate you are taking care of it!
On Sat, 7 Mar 2020 at 11:03, Leon He wrote:
>
> From: Leon He
>
> There are two errors in the dmabuf-heap selftest:
> 1. The 'char name[5]' was not initializ
On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller wrote:
>
> Hi Ezequiel,
>
> > Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia
> > :
> >
> > On Fri, 21 Aug 2020 at 19:24, Paul Cercueil wrote:
> >>
> >>
> >>
> >> Le sam. 2
On Fri, 21 Aug 2020 at 19:24, Paul Cercueil wrote:
>
>
>
> Le sam. 22 août 2020 à 0:11, Paul Boddie a
> écrit :
> > On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> >> On Thu, 20 Aug 2020 at 19:49, Paul Boddie
> >> wrote:
> >>
On Thu, 20 Aug 2020 at 19:49, Paul Boddie wrote:
>
> On Thursday, 20 August 2020 10:19:45 CEST H. Nikolaus Schaller wrote:
> >
> > Yes, it works!!!
>
> It still doesn't work for me. I still get "Input not supported" from my
> monitor. It is a DVI monitor connected via a HDMI adapter, but EDID prob
On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote:
> On 8/17/20 8:18 AM, Brian Starkey wrote:
> > Hi Ezequiel,
> >
> > On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote:
> > > This heap is basically a wrapper around DMA-API dma_alloc_attrs,
&g
Hi Brian,
Thanks a lot for reviewing this patch.
I'm happy my humble proof-of-concept
is able to spark some interest and raise
some questions.
On Mon, 2020-08-17 at 16:18 +0100, Brian Starkey wrote:
> Hi Ezequiel,
>
> On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia w
Hi John,
Thanks a ton for taking the time
to go thru this.
On Mon, 2020-08-17 at 21:13 -0700, John Stultz wrote:
> On Sun, Aug 16, 2020 at 10:23 AM Ezequiel Garcia
> wrote:
> > This heap is basically a wrapper around DMA-API dma_alloc_attrs,
> > which will allocate memor
On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller wrote:
>
> Hi Ezequiel,
>
> > Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia
> > :
> >
> > Hello,
> >
> > First of all, I'd like to thank everyone for the great work
> > on ingenic-drm. The
Hello,
First of all, I'd like to thank everyone for the great work
on ingenic-drm. The driver is in very good shape
and a pleasure to work with.
Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5",
from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1,
and then run weston o
rrect or even
a good idea, but just submitting it to start a discussion on DMA-BUF
heap discovery and negotiation.
Given Plumbers is just a couple weeks from now, I've submitted
a BoF proposal to discuss this, as perhaps it would make
sense to discuss this live?
Not-signed-off-by: Ezequ
Hi Neil,
On Wed, 2020-07-01 at 09:35 +0300, Adrian Ratiu wrote:
> Hi Neil,
>
> On Mon, 29 Jun 2020, Neil Armstrong
> wrote:
> > Hi Adrian,
> >
> > On 09/06/2020 19:49, Adrian Ratiu wrote:
> > > [Re-submitting to cc dri-devel, sorry about the noise] Hello
> > > all, v9 cleanly applies on t
ding a dma-heap name getter, and then setting
dma_buf_export_info.exp_name.
Signed-off-by: Ezequiel Garcia
---
drivers/dma-buf/dma-heap.c | 5 +
drivers/dma-buf/heaps/heap-helpers.c | 1 +
include/linux/dma-heap.h | 2 ++
3 files changed, 8 insertions(+)
diff --git a/d
On Fri, 14 Aug 2020 at 23:20, John Stultz wrote:
>
> On Fri, Aug 14, 2020 at 7:25 AM Ezequiel Garcia
> wrote:
> >
> > Currently the heap helper uses DEFINE_DMA_BUF_EXPORT_INFO,
> > which uses KBUILD_MODNAME for the dma_buf_export_info.exp_name.
> >
> &
Hi John,
Thanks for the patch.
On Fri, 14 Aug 2020 at 03:25, John Stultz wrote:
>
> This adds a heap that allocates non-contiguous buffers that are
> marked as writecombined, so they are not cached by the CPU.
>
What's the rationale for exposing the memory
attribute as a new heap, instead of ju
On Tue, 28 Apr 2020 at 09:47, Hillf Danton wrote:
>
>
> Sun, 26 Apr 2020 20:48:12 -0700
> > syzbot found the following crash on:
> >
> > HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log
+e3372a2afe1e7ef04...@syzkaller.appspotmail.com
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/vkms/vkms_drv.h | 5 -
drivers/gpu/drm/vkms/vkms_gem.c | 11 ++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
=====
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug
======
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of t
Hello Fabio, Adrian:
On Mon, 2020-03-30 at 08:49 -0300, Fabio Estevam wrote:
> Hi Adrian,
>
> On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu
> wrote:
> > This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> > controller which is embedded in i.MX 6 SoCs.
> >
> > Based on following
On Tue, 2020-03-31 at 00:31 +0300, Adrian Ratiu wrote:
> On Mon, 30 Mar 2020, Ezequiel Garcia
> wrote:
> > Hello Fabio, Adrian:
> >
> > On Mon, 2020-03-30 at 08:49 -0300, Fabio Estevam wrote:
> > > Hi Adrian, On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu
On Wed, 2020-02-26 at 07:40 -0800, Randy Dunlap wrote:
> On 2/26/20 2:54 AM, Enric Balletbo i Serra wrote:
> > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> > index 2114b563478c..dcd6481a14d0 100644
> > --- a/drivers/soc/mediatek/Kconfig
> > +++ b/drivers/soc/mediatek/K
On Wed, 2020-01-22 at 09:04 +0100, Daniel Vetter wrote:
> On Sat, Dec 14, 2019 at 01:20:49PM -0300, Ezequiel Garcia wrote:
> > It's not entirely obvious why these messages have
> > "info" severity. In any case, add a proper driver prefix
> > to give the use
-by: Mark Yao
Signed-off-by: Douglas Anderson
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 11
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 21 +++
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 13 +
include/uapi/drm/rockchip_drm.h
Hi everyone,
Any feedback here?
At least this one should be pretty straightforward
to merge, so I'm not sure it deserves a 6-month delay.
If anyone can take a look, I'd appreciate it.
Thanks!
Ezequiel
On Mon, 2019-07-22 at 13:08 -0300, Ezequiel Garcia wrote:
> When a mode is se
On Sat, 2019-12-14 at 13:20 -0300, Ezequiel Garcia wrote:
> It's not entirely obvious why these messages have
> "info" severity. In any case, add a proper driver prefix
> to give the user a bit of context of where they are coming from.
>
> Signed-off-by: Ezequiel
On Sat, 2019-12-14 at 01:59 -0300, Ezequiel Garcia wrote:
> Currently, the interrupt lines requested by Panfrost
> use unmeaningful names, which adds some obscurity
> to interrupt introspection (i.e. any tool based
> on procfs' interrupts file).
>
> In order to improve this
component_bind_all will call component_unbind without
calling drm_mode_config_cleanup, if any component fails to bind.
As mentioned above, this is problematic in the DRM framework.
Thanks!
Ezequiel
Ezequiel Garcia (5):
component: Add an API to cleanup before unbind
drm/rockchip: Fix the device unbind
ll to the connector
.destroy hook, where it belongs.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/roc
of driver-specific (i.e. vop-specific) resources.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 56 -
1 file changed, 20 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip
se non-DRM resources.
Arguably, this could be viewed as Very Ugly. However, it handles
this complex case, making it possible to fix the current
unbind crashes that some DRM drivers suffer from,
in a non-invasive way, keeping the DRM resource handling model.
Signed-off-by: Ezequiel Garcia
---
dr
Remove drm_connector_unregister() since it should be
used only by drivers that call drm_dev_register
explicitly.
Also, call the DRM cleanups directly, instead of
(ab)using the destroy hooks, for readability reasons.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8
In order to cleanup the configuration, destroying the components
in the pipeline, the components must be present.
Therefore, cleanup the config first, and unbind the components
later.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 20
1
Hi Enric,
Note that this series is marked as v22, but it's really the 23th.
Some minor comments below, it's looking really now.
Reviewed-by: Ezequiel Garcia
On Mon, 2019-12-23 at 15:35 +0100, Enric Balletbo i Serra wrote:
> From: Jitao Shi
>
> This patch adds drm_bridge dr
Hi Enric, Rob,
On Mon, 2019-12-23 at 15:35 +0100, Enric Balletbo i Serra wrote:
> From: Jitao Shi
>
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
> Acked-by: Rob Herring
> Reviewed-by: Philipp Zabel
> Signed-off-by: Ulrich Hecht
On Wed, 2019-12-18 at 16:21 +0100, Enric Balletbo i Serra wrote:
> Hi Ezequiel,
>
> Many thanks for the review, I am just preparing the next version to send.
>
[..]
> > > +
> > > +#define PAGE1_VSTART 0x6b
> > > +#define PAGE2_SPI_CFG3 0x82
> > > +#define I2C_TO_SPI_RESET 0x
Hi John,
On Mon, 2019-12-16 at 17:23 +, John Garry wrote:
> Hi all,
>
> Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE causes many warns on a system
> with the HIBMC hw:
>
> [ 27.788806] WARNING: CPU: 24 PID: 1 at
> drivers/gpu/drm/drm_gem_vram_helper.c:564 bo_driver_move_notify+0x8c/0x98
A t
On Mon, 2019-12-16 at 14:58 +0100, Enric Balletbo i Serra wrote:
> From: Jitao Shi
>
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: Daniel Kurtz
> Reviewed-by: Enric Balletbo i Serra
> [uli: followed API changes, removed FW u
Hi Adrian,
Thanks for the patch. This is nice consolidation work.
I'm Ccing Heiko for the Rockchip part.
See below for some comments.
On Mon, 2019-12-02 at 21:33 +0200, AdrianAdrian Ratiu wrote:
> Convert the common bridge code and the two rockchip & stm drivers
> which currently use it to the r
It's not entirely obvious why these messages have
"info" severity. In any case, add a proper driver prefix
to give the user a bit of context of where they are coming from.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 ++
driv
d-off-by: Ezequiel Garcia
---
v2:
* Use consistent naming, as suggested by Alyssa, Neil and Robin.
drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
3 files changed, 6 insertions(+), 4 deletions(-)
Hey everyone,
Thanks for the quick comments.
(Feedback for kernel patches on the same day, am I dreaming??)
On Fri, 2019-12-13 at 13:46 +, Robin Murphy wrote:
> On 13/12/2019 1:18 pm, Neil Armstrong wrote:
> > Hi,
> >
> > On 13/12/2019 13:39, Ezequiel Garcia wrote:
sible.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu
On Sun, 2019-11-24 at 08:32 +0100, Boris Brezillon wrote:
> On Sun, 24 Nov 2019 09:46:41 +0900
> Ezequiel Garcia wrote:
>
> > Hi Boris, Neil,
> >
> > On Wed, 2019-10-23 at 17:44 +0200, Boris Brezillon wrote:
> > > This patch series aims at adding support for
Hi Boris, Neil,
On Wed, 2019-10-23 at 17:44 +0200, Boris Brezillon wrote:
> This patch series aims at adding support for runtime bus-format
> negotiation between all elements of the
> 'encoder -> bridges -> connector/display' section of the pipeline.
>
> In order to support that, we need drm brid
Hello Andrzej,
Thanks a lot for the patch.
Reviewed-by: Ezequiel Garcia
On Thu, 2019-11-21 at 18:22 +0100, Andrzej Pietrasiewicz wrote:
> This patch adds support for afbc handling. afbc is a compressed format
> which reduces the necessary memory bandwidth.
>
> Co-developed-
Hi Andrzej,
Thanks for the series. It's certainly going well.
Please see some minor comments below.
On Thu, 2019-11-21 at 18:22 +0100, Andrzej Pietrasiewicz wrote:
> These are useful for other users of afbc, e.g. rockchip.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/Makef
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v4:
* None.
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg
latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.
The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.
Signed-off-by: Ezequiel Garcia
---
Changes from v4:
* Cleaned-up gamma_set implementation
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v4:
* None.
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug
New iteration, seems that we are finally converging.
For this v5, we are only doing some changes on
the gamma_set implementation. As a result, the code
is more readable. See the changelog in patch 2 for more
information.
Thanks!
Ezequiel Garcia (3):
dt-bindings: display: rockchip: document
Hello Sean,
Thanks for the thourough review.
On Wed, 9 Oct 2019 at 15:01, Sean Paul wrote:
>
> On Tue, Oct 08, 2019 at 08:00:37PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separat
latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.
The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.
Signed-off-by: Ezequiel Garcia
---
Changes from v3:
* Move to atomic_enable and
: Reapply color transformation after
resume" is now dropped.
Also, I dropped Reviewed-bys tags on patch 2, given
the implementation is a bit different now.
Thanks!
Ezequiel Garcia (3):
dt-bindings: display: rockchip: document VOP gamma LUT address
drm/rockchip: Add optional support for CRTC
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug.
---
.../devicetree
On Tue, 2019-10-08 at 16:03 -0400, Sean Paul wrote:
> On Tue, Oct 08, 2019 at 04:33:35PM -0300, Ezequiel Garcia wrote:
> > On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> > > Hello Sean,
> > >
> > > On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote
On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> Hello Sean,
>
> On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> > On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
Hello Sean,
On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> > which nee
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
arch/arm/boot/dts
1 - 100 of 237 matches
Mail list logo
