bce1 ("drm/fsl-dcu: use common clock framework for pixel clock
divider")
Reported-by: Meng Yi
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b
Hi Meng, hi Mark,
[added Mark Brown to discuss the endian issue]
On 2016-07-15 01:50, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the color
> output values to match the gamut of a particular TFT LCD panel
>
> Signed-off-by: Meng Yi
> ---
> drivers/gpu/drm/fsl-dcu/Kc
On 2016-09-04 19:28, Meng Yi wrote:
> Hi Stefan,
>
>> > + */
>> > +static u32 swap_bytes(u16 var)
>>
>> We certainly don't want a byte swapping function in the driver. I am sure
>> Linux
>> has appropriate functions for that already, however, I am not convinced that
>> we need that at all.
>>
>
On 2016-09-03 03:49, Mark Brown wrote:
> On Fri, Sep 02, 2016 at 02:22:46PM -0700, Stefan Agner wrote:
>> I guess the problem is that regmap_write does byte swapping because
>> ls1021a.dtsi defines the whole DCU register space to be big-endian. So
>> you end up doing byte swa
rent endianness. Check
>> endianness using the device-tree property "big-endian" to determine the
>> location of DIV_RATIO.
>>
>> Cc: stable at vger.kernel.org
>> Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for pixel
>> clock divide
On 2016-07-25 00:08, Wei Yongjun wrote:
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR.
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> Signed-off-by: Wei Yongjun
Applied!
--
Stefan
On 2016-08-21 19:22, Fabio Estevam wrote:
> From: Fabio Estevam
>
> In fsl_dcu_drm_pm_resume() we should disable the previously enabled
> clock (fsl_dev->clk) when enabling fsl_dev->pix_clk fails.
>
> Signed-off-by: Fabio Estevam
Applied, thanks!
--
Stefan
READREG, which according to
documentation:
The READREG bit causes a single transfer to begin at the next frame
blanking period. This bit is cleared when the transfer is complete.
I made a video how that looks:
https://cloud.agner.ch/index.php/s/Yfqa2u7UBEWUT8N
Any ideas?
Stefan Agner (4):
drm/fsl
Add support for overlay plane and a cursor plane. The driver uses
the topmost plane as cursor plane. The DCU IP would have dedicated
cursor support, but that lacks proper color support and hence is
not practical to use for Linux systems.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu
Mask the size and position values to avoid mutual overwriting.
Especially, a negative X position caused the Y position to be
overwritten with 0xfff too. This has been observed when using
a layer as cursor layer.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 8
Use the UPDATE_MODE READREG bit to initiate a register transfer
on flush. This makes sure that we flush all registers only once
for all planes.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 3 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 -
2 files
The IRQ status and mask registers are not "double buffered" according
to the reference manual. Hence, there is no extra transfer/update
write needed when modifying these registers.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4
1 file changed, 4
ce in 2D-ACE is big-endian.
> Workaround:
> Split the DCU regs into "regs", "palette", "gamma" and "cursor".
> Create a second regmap for gamma memory space using little endian.
>
> Suggested-by: Stefan Agner
> Signed-off-by: Meng Yi
>
an registers
> while the rest of the address-space in 2D-ACE is big-endian.
> Workaround:
> Split the DCU regs into "regs", "palette", "gamma" and "cursor".
> Create a second regmap for gamma memory space using little endian.
>
> Sugge
Estevam (1):
drm/fsl-dcu: disable clock on error path
Stefan Agner (1):
drm/fsl-dcu: fix endian issue when using clk_register_divider
Wei Yongjun (1):
drm/fsl-dcu: use PTR_ERR_OR_ZERO() to simplify the code
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 12 ++--
drivers/gpu/d
On 2016-09-13 01:49, Meng Yi wrote:
>> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
>> > b/drivers/gpu/drm/fsl-dcu/Kconfig index 14a72c4..f9c76b1 100644
>> > --- a/drivers/gpu/drm/fsl-dcu/Kconfig
>> > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
>> > @@ -11,3 +11,9 @@ config DRM_FSL_DCU
>> >help
>>
>> https://cloud.agner.ch/index.php/s/Yfqa2u7UBEWUT8N
It would be interesting whether you see that on LS1021a too.
--
Stefan
>>
>> Any ideas?
>>
>> Stefan Agner (4):
>> drm/fsl-dcu: support overlay and cursor planes
>> drm/fsl-dcu: respect pos/siz
On 2016-09-25 23:04, Meng Yi wrote:
>> On Wed, Sep 21, 2016 at 11:10:11AM -0700, Stefan Agner wrote:
>> > On 2016-09-13 01:49, Meng Yi wrote:
>> > >> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
>> > >> > b/drivers/gpu/drm/fsl-dcu/Kconfig index
amma regmap section.
Also, please mention that we did not access the registers after the
first address space yet, hence new device trees would even work with old
kernels. Just new kernel need the new format so we can access the
separate gamma reg space.
>
> Suggested-by: Stefan Agner
> Signed-o
ate a second regmap for gamma memory space using little endian.
> The registers after the first address space are not accessed yet,
> hence new device trees would even work with old kernels. Just new
> kernel need the new format so we can access the separate gamma
> reg space.
>
&
; Signed-off-by: Arnd Bergmann
> Fixes: 2d701449bce1 ("drm/fsl-dcu: use common clock framework for
> pixel clock divider")
Oh right, thx!
Acked-by: Stefan Agner
@Dave, can you pick that up directly or do you prefer a pull request?
--
Stefan
> ---
> drivers/gpu/drm/fsl-dcu/
Hi Meng,
Please use plain text mails on mailing lists.
On 2016-05-03 02:26, Meng Yi wrote:
> Hi,
>
> I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and
> got some log below. And fsl-dcu not works.
>
> Since "drm-next" merged some branch , use git bisect had some pr
ic changes to the first commit
Changes since v1:
- Introduce bus_flags to convey the pixel clock polarity from
panel-simple.c to the driver.
Stefan Agner (2):
drm: introduce bus_flags in drm_display_info
drm/fsl-dcu: use bus_flags for pixel clock polarity
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_
-by: Stefan Agner
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
include/drm/drm_crtc.h | 9 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index ceb2048..77ae07f 100644
--- a/drivers/gpu/drm
ned-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 5 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 4 ++--
drivers/gpu/drm/panel/panel-simple.c | 3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drive
#x27;t direct get
> the panel, save polarity on panel_desc means need more work to
> transmit it to crtc.
>
> Thanks.
>
> On 2016å¹´05æ05æ¥ 13:08, Stefan Agner wrote:
>> Introduce bus_flags to specify display bus properties like signal
>> polarities. This is usefu
On 2016-05-05 03:06, Daniel Vetter wrote:
> On Wed, May 04, 2016 at 10:08:59PM -0700, Stefan Agner wrote:
>> Introduce bus_flags to specify display bus properties like signal
>> polarities. This is useful for parallel display buses, e.g. to
>> specify the pixel clock or
)
Stefan Agner (2):
drm: introduce bus_flags in drm_display_info
drm/fsl-dcu: use bus_flags for pixel clock polarity
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 5 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 4 ++--
drivers
On 2016-05-10 08:07, Philipp Zabel wrote:
> This patch allows panels to set pixel clock and data enable pin polarity
> other than the default of driving data at the rising pixel clock edge and
> active high display enable.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/imx/imx-drm-
y 03, 2016 5:27 PM
> To: 'dri-devel at lists.freedesktop.org'
> ; David Airlie ;
> 'Stefan Agner' ; 'airlied at redhat.com'
>
> Subject: fsl-dcu not works on latest "drm-next"
>
> Hi,
>
>
> I just tested the latest drm-next branch
On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to? What
>> > specifically is the endianess problem y
On 2016-05-27 05:20, Mark Brown wrote:
> On Thu, May 26, 2016 at 10:54:16PM -0700, Stefan Agner wrote:
>> On 2016-05-26 02:11, Alexander Stein wrote:
>
>> > This needs to be a flat cache. See
>> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121
e v1:
> - Introduce bus_flags to convey the pixel clock polarity from
> panel-simple.c to the driver.
>
> Stefan Agner (3):
> drm/fsl-dcu: use mode flags for hsync/vsync polarity
> drm: introduce bus_flags in drm_display_info
> drm/fsl-dcu: use bus_flags fo
On 2016-02-24 03:06, Tomi Valkeinen wrote:
> Hi,
>
> On 24/02/16 01:30, Stefan Agner wrote:
>> Any comments on this?
>>
>> Also added Manfred, Tomi and Boris to CC which previously attended in
>> similar discussions.
>>
>> Previous discussions:
>
On 2015-11-18 18:42, Stefan Agner wrote:
> During testing the DCU DRM driver on the Freescale Vybrid platform
> I came across some (platform independent) bugs and problems which
> this patchset addresses.
>
> Note: To use the driver on Vybrid some platform/device-tree
> enhan
On 2016-02-08 13:57, Stefan Agner wrote:
> The current default configuration is as follows:
> - Invert VSYNC signal (active LOW)
> - Invert HSYNC signal (active LOW)
>
> The mode flags allow to specify the required polarity per
> mode. Furthermore, none of the current
On 2016-02-02 17:06, Stefan Agner wrote:
> The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for
> Vybrid) whereas the register enumeration start from 1 (1-10 for
> LS1021a and 1-9 for Vybrid). The loop started off from 0 for both
> iterations and initialized the numb
u to fetch changes up to f76b9873d7db0afb51f2df389a99284ef484b86f:
drm/fsl-dcu: fix register initialization (2016-02-25 16:13:16 -0800)
Meng Yi (1):
drm: fsl-dcu: Fix no fb check bug
Stefan Agner (9):
MAINTAINERS:
==
> NULL is an error in your driver and must be fixed.
Thanks for this clarification. Ok, I agree the patch is needed despite
my fix then...
Acked-by: Stefan Agner
--
Stefan
Promote myself as new maintainer of the Freescale DCU DRM driver.
Signed-off-by: Stefan Agner
---
This has been previously discussed privately. The original driver
author and maintainer Jianwei does not work for Freescale anymore
and can not carve out spare time to maintain the driver.
As I
On 2016-01-08 01:20, Emil Velikov wrote:
> Hi guys,
>
> Am I loosing the plot here or something feels amiss here ?
>
> On 6 January 2016 at 06:12, Meng Yi wrote:
>> For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check
>> function, if so, return 0.
>>
>> Signed-off-by: Meng
Hi Mark,
I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a
Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following
warning on startup:
[1.327284] [ cut here ]
[1.332010] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755
lockdep_
On 2016-01-14 16:01, Mark Brown wrote:
> On Thu, Jan 14, 2016 at 02:30:50PM -0800, Stefan Agner wrote:
>
>> I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a
>> Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following
>> warning on startup:
On 2016-01-15 08:28, Mark Brown wrote:
> On Thu, Jan 14, 2016 at 05:14:47PM -0800, Stefan Agner wrote:
>
>> On a slightly other topic, I question whether REGCACHE_RBTREE is the
>> right cache type for the DCU DRM driver. The driver has uses a regmap
>> area of 1144 32
Hi Laurent,
On 2020-06-16 03:50, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
>> On 2020-05-30 05:10, Laurent Pinchart wrote:
>> > The DRM simple display pipeline helper only supports a single plane. In
>>
On 2020-06-11 14:23, Bernard Zhao wrote:
> There are three err return values in drm_fbdev_generic_setup.
> In mxsfb_probe we called this function, but didn`t handle the
> return value, this change is to add err handle, maybe make code
> a bit more readable.
This got recently changed, so I guess ch
On 2020-07-18 19:14, Guido Günther wrote:
> Hi,
> On Mon, Mar 23, 2020 at 04:51:05PM +0100, Lucas Stach wrote:
>> Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
>> > In contrast to other display controllers on imx like DCSS and ipuv3
>> > lcdif/mxsfb does not support detiling e.g. vi
On 2020-07-16 19:41, Uwe Kleine-König wrote:
> flags is unused since the driver was introduced in commit 45d59d704080
> ("drm: Add new driver for MXSFB controller").
Applied to drm-misc-next. Thanks.
--
Stefan
>
> Signed-off-by: Uwe Kleine-König
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 +
On 2020-07-26 20:28, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Fri, Jul 17, 2020 at 05:06:55AM +0300, Laurent Pinchart wrote:
>> On Thu, Jul 09, 2020 at 12:25:42PM +0200, Stefan Agner wrote:
>> > On 2020-06-16 03:50, Laurent Pinchart wrote:
>> >> On Thu, Jun
On 2020-07-27 04:06, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
> instance found in the i.MX7 is backward-compatible with the already
> supported LCDC v4, but has extended features amongst which the most
> notable one is a second plane
off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +--
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drive
ding it further in the future as support for more SoCs is added.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> Changes since v1:
>
> - Make description more explicit by mentioning LCDIF and eLCDIF
> - Add i.MX8M
> ---
> drivers/gpu/drm/mxsfb/Kc
On 2020-05-30 05:10, Laurent Pinchart wrote:
> This is a cosmetic change only, no code change is included.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 10 +-
> 1 file changed, 5 insertions(+), 5 dele
vate *mxsfb)
>
> static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
> {
> - struct drm_device *drm = mxsfb->pipe.crtc.dev;
> - struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
> + struct drm_device *drm =
hread, we should add a
default type to avoid warnings for some panels.
Other than that, looks good to me:
Reviewed-by: Stefan Agner
> ---
> Changes since v1:
>
> - Select DRM_PANEL_BRIDGE in Kconfig
> ---
> drivers/gpu/drm/mxsfb/Kconfig | 1 +
> drivers/gpu
On 2020-05-30 05:10, Laurent Pinchart wrote:
> The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
> plane. Support it.
>
> Signed-off-by: Laurent Pinchart
Looks good to me.
Reviewed-by: Stefan Agner
--
Stefan
> ---
> Changes since v1:
>
> - Spl
f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
I guess this could be merge independent of the rest already today.
--
Stefan
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff
On 2020-03-09 20:51, Laurent Pinchart wrote:
> Replace the manual connector implementation based on drm_panel with the
> drm_panel_bridge helper. This simplifies the mxsfb driver by removing
> connector-related code, and standardizing all pipeline control
> operations on bridges.
>
> A hack is nee
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 56 +++---
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
> b/drivers/gpu/drm/mxsfb/
On 2020-03-09 20:51, Laurent Pinchart wrote:
> mxsfb_regs.h defines macros related to register bits. Some of them are
> not used and don't clearly map to any particular register, so their
> purpose isn't known. Remove them.
>
> Signed-off-by: Laurent Pinchart
pply anymore (the bus width can be specified through the
> display_info bus format).
Reviewed-by: Stefan Agner
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 17 +
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 17
On 2020-03-09 20:52, Laurent Pinchart wrote:
> The mxsfb_reset_block() function isn't special, pass it the
> mxsfb_drm_private pointer instead of a pointer to the base address.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/
inchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index be60c4021e2f..722bd9b4f5
On 2020-03-09 20:52, Laurent Pinchart wrote:
> mxsfb_crtc.c defines several macros related to register addresses and
> bit, which duplicates macros from mxsfb_regs.h. Use the macros from
> mxsfb_regs.h instead and remove them.
>
> Signed-off-by: Laurent Pinchart
Reviewed-b
On 2020-03-09 20:52, Laurent Pinchart wrote:
> A fair number of includes are not needed. Drop them, and add a couple of
> required includes that were included indirectly.
>
> Signed-off-by: Laurent Pinchart
Out of curiosity, do you have some kind of tool helping with this?
Reviewe
On 2020-03-09 20:52, Laurent Pinchart wrote:
> The DRM simple display pipeline helper only supports a single plane. In
> order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
> move away from the helper. No new feature is added.
>
> Signed-off-by: Laurent Pinchart
I actually woul
On 2020-03-09 20:52, Laurent Pinchart wrote:
> The mxsfb_crtc.c file doesn't handle just the CRTC, but also the other
> KMS objects. Rename it accordingly.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/Makefile
at now that we no
longer use the simple display pipeline we can and should use the flush
callback).
Otherwise looks good.
Reviewed-by: Stefan Agner
--
Stefan
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 35 ++-
>
sable() as is calls .disable_vblank() manually and is
> used both at probe and remove time.
>
> The clock disabling is also moved to the last step of the
> mxsfb_crtc_atomic_disable() function, to prepare for enabling vblank
> handling.
>
> Signed-off-by: Laurent Pinchart
Loo
On 2020-03-09 20:52, Laurent Pinchart wrote:
> Enable vblank handling when the CRTC is turned on and disable it when it
> is turned off. This requires moving vblank init after the KMS pipeline
> initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs.
>
> Signed-off-by: Laurent Pincha
On 2020-03-09 20:52, Laurent Pinchart wrote:
> The debug0 and ipversion fields of the mxsfb_devdata structure are
> unused. Remove them.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
> drivers/gpu/drm/
On 2020-03-09 20:52, Laurent Pinchart wrote:
> Extend the Kconfig option description by listing the i.MX7 SoCs, as they
> are supported by the same driver.
Can you also add "i.MX8M" to the list since the bindings for this driver
are also used in arch/arm64/boot/dts/freescale/imx8mq.dtsi.
--
Stefa
for support for the additional features.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>
On 2020-03-09 20:52, Laurent Pinchart wrote:
> The mxsfb driver is only used by OF platforms. Drop non-OF support.
Nice cleanup. Actually only supported of anyways due to the
pdev->dev.of_node check.
Reviewed-by: Stefan Agner
--
Stefan
>
> Signed-off-by: Laurent Pinchart
>
see, we specify the supported plane formats when initializing the
primary/overlay plane.
Reviewed-by: Stefan Agner
--
Stefan
> ---
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_k
ate cycle in mxsfb_set_bus_fmt(). Make
> this more efficient by merging them together.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
> ---
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 47 +--
> 1 file changed, 19 insertions(+), 28 deletion
On 2020-03-09 20:52, Laurent Pinchart wrote:
> The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
> plane. Support it.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 16 ++--
> drivers/gpu/drm/m
On 2020-03-23 22:38, Sam Ravnborg wrote:
> Hi Stefan.
>
> On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
>> On 2020-03-09 20:51, Laurent Pinchart wrote:
>> > Replace the manual connector implementation based on drm_panel with the
>> > drm_panel_b
On 2020-03-24 00:08, Stefan Agner wrote:
> On 2020-03-09 20:52, Laurent Pinchart wrote:
>> Enable vblank handling when the CRTC is turned on and disable it when it
>> is turned off. This requires moving vblank init after the KMS pipeline
>> initialisation, otherwise drm_vbla
On 2020-09-08 16:16, Stefan Agner wrote:
> The lcdif IP does not support a framebuffer pitch (stride) other than
> framebuffer width. Check for equality and reject the framebuffer
> otherwise.
>
> This prevents a distorted picture when using 640x800 and running the
> Mesa gr
On 2020-09-11 10:50, Daniel Vetter wrote:
> On Thu, Sep 10, 2020 at 11:24:23AM +0200, Stefan Agner wrote:
>> To improve readability and make it easier to add further optional checks
>> replace the boolean parameters with a single flag bitfield as parameter
>> of drm_atomic_hel
On 2020-09-11 10:52, Daniel Vetter wrote:
> On Thu, Sep 10, 2020 at 11:24:24AM +0200, Stefan Agner wrote:
>> Add flag which checks that the framebuffer size matches the plane size
>> exactly. This is useful for display controller which can't handle
>> framebuffers othe
On 2020-09-11 13:59, Ville Syrjälä wrote:
> On Thu, Sep 10, 2020 at 11:24:24AM +0200, Stefan Agner wrote:
>> Add flag which checks that the framebuffer size matches the plane size
>> exactly. This is useful for display controller which can't handle
>> framebuffers othe
Hi Matthias,
On 2020-08-20 12:58, Matthias Schiffer wrote:
> The PIXCLK needs to be enabled in SCFG before accessing the DCU on LS1021A,
> or the access will hang.
Hm, this seems a rather ad-hoc access to SCFG from the DCU. We do
support a pixel clock in the device tree bindings of fsl-dcu, so id
On 2020-08-13 03:29, Laurent Pinchart wrote:
> Additional compatible strings have been added in DT source for the
> i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
> Most of the upstream DT sources use the fsl,imx28-lcdif compatible
> string, which mostly predates the realizati
P i.MX LCD Interface (LCDIF)
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e3fac23383d2..fe1bda639a39 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11757,7 +11757,7 @@ M:Stefan Agner
> L: dri-devel@lists.freedesktop.org
> S: Supported
> T: git git://anong
On 2020-08-24 01:26, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Fri, Aug 21, 2020 at 04:53:56PM +0200, Stefan Agner wrote:
>> On 2020-08-13 03:29, Laurent Pinchart wrote:
>> > Additional compatible strings have been added in DT source for the
>> > i.MX6SL, i.M
particular resolution to width != stride. Currently
Mesa has no fallback behavior, but rejecting this configuration allows
userspace to handle the issue correctly.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions
On 2020-09-07 20:18, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
>> Hi Stefan,
>>
>> Thank you for the patch.
>>
>> On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
>> > The lcdif IP does not suppo
On 2020-09-08 10:48, Daniel Vetter wrote:
> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 08/09/2020 10:55, Stefan Agner wrote:
>> > On 2020-09-07 20:18, Daniel Vetter wrote:
>> >> On Mon, Sep 07, 2020 at 07:17:12PM +0300
On 2020-09-08 14:33, Laurent Pinchart wrote:
> On Tue, Sep 08, 2020 at 02:29:02PM +0200, Daniel Vetter wrote:
>> On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner wrote:
>> > On 2020-09-08 10:48, Daniel Vetter wrote:
>> >> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Va
particular resolution to width != stride. Currently
Mesa has no fallback behavior, but rejecting this configuration allows
userspace to handle the issue correctly.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 -
1 file changed, 20 insertions(+), 1
particular resolution to width != stride. Currently
Mesa has no fallback behavior, but rejecting this configuration allows
userspace to handle the issue correctly.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller")
Signed-off-by: Stefan Agner
Reviewed-by: Lauren
The plane size must match the CRTC already (enforced by not setting
the CAN_POSTION flag). However, the controller also requires the
framebuffer to be exactly the CRTC size. Make use of the new flag
DRM_PLANE_REQUIRE_MATCHING_FB to match the plane size.
Signed-off-by: Stefan Agner
---
drivers
Add flag which checks that the framebuffer size matches the plane size
exactly. This is useful for display controller which can't handle
framebuffers other than the plane/CRTC size.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/drm_atomic_helper.c | 7 +++
drivers/gp
)
+ drm_atomic_helper_check_plane_state(e1, e2, e3, e4, 0)
)
Signed-off-by: Stefan Agner
---
This implements what has been discussed in the thread of the patch
"drm: mxsfb: check framebuffer pitch":
https://lkml.org/lkml/2020/9/8/1342
Before sending it out to all maintainers I wanted to get conformat
Hi Laurent,
On 2020-03-09 20:51, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
> instance found in the i.MX7 is backward-compatible with the already
> supported LCDC v4, but has extended features amongst which the most
> notable one is a
e_vblank callback we can do
>> the on/off as the first respectively last operation, and it should all
>> work.
>>
>> Signed-off-by: Daniel Vetter
>> Cc: Marek Vasut
>> Cc: Stefan Agner
>> Cc: Shawn Guo
>> Cc: Sascha Hauer
>> Cc: Pengutroni
On 2020-05-28 10:06, Daniel Vetter wrote:
> On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
>>
>> Hi Daniel,
>>
>> On 2020-05-28 07:46, Daniel Vetter wrote:
>> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> >> mxsfb
On 2020-06-02 15:12, Daniel Vetter wrote:
> On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote:
>> Hi Stefan,
>>
>> On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
>> > On 2020-03-09 20:51, Laurent Pinchart wrote:
>> > > Replace
101 - 200 of 459 matches
Mail list logo
