Re: [PATCH 1/5] DRM: add i.MX IPUv3 base driver

Hi Sascha, On Tue, Jun 7, 2011 at 7:45 AM, Sascha Hauer s.ha...@pengutronix.de wrote: ... +static int __init imx_ipu_init(void) +{ +       int32_t ret; + +       ret = platform_driver_register(imx_ipu_driver); +       return 0; Did you intend to return ret here instead? Regards, Fabio

Re: [PATCH, RFC] i.MX DRM support

of the driver without breaking officially supported features. What do you think about this? +1 on this. Thanks for your hard work on this, Sascha. Regards, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org http

Building DRM for i.MX fails with linux-next 20130212

, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Building DRM for i.MX fails with linux-next 20130212

Dave/Bjorn, On Tue, Feb 12, 2013 at 3:50 PM, Fabio Estevam feste...@gmail.com wrote: Hi, Building imx_v6_v7_defconfig on linux-next 20130212 gives me the following build error: CC drivers/gpu/drm/drm_pci.o drivers/gpu/drm/drm_pci.c: In function ‘drm_pcie_get_speed_cap_mask

[PATCH] drm: drm_drv: Only call drm_agp_clear() in __OS_HAS_AGP case

From: Fabio Estevam fabio.este...@freescale.com Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) causes the following link error on ARM (imx_v6_v7_defconfig): drivers/built-in.o: In function `drm_lastclose': :(.text+0x588a0): undefined reference to `drm_agp_clear' make

Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks

On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying ying@freescale.com wrote: diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 5a90a72..90e923e 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt

[PATCH] drm: mxsfb: Implement drm_panel handling

eline and drm_panel_disable(), followed by drm_panel_unprepare() while switching off the display pipeline." So do as suggested, so that the 'power-supply' regulator can be functional. Reported-by: Breno Lima <breno.l...@nxp.com> Suggested-by: Thierry Reding <thierry.red...@gmail.com>

Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G

properly? Yes, that is correct. It also needs the other patch I sent yesterday that allows the power-supply regulator to work. I was able to test it on a imx6sx-sdb board, so: Tested-by: Fabio Estevam <fabio.este...@nxp.com> ___ dri-devel mailing list dri-devel@

[PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

From: Fabio Estevam <fabio.este...@nxp.com> Currently the framebuffer content is displayed with incorrect offsets in both the vertical and horizontal directions. The fbdev version of the driver does not show this problem. Breno Lima dumped the eLCDIF controller registers on both t

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

Hi Philipp, On Tue, Feb 7, 2017 at 2:45 PM, Philipp Zabel wrote: > I've applied this to the fixes branch, since the current device trees > don't have the regulator set. I have sent a patch providing the dac-supply regulator for imx53-qsb:

[PATCH v2] drm/imx: imx-tve: Do not set the regulator voltage

from 2.75V. Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") Cc: <sta...@vger.kernel.org> # 4.8+ Suggested-by: Lucas Stach <l.st...@pengutronix.de> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Changes since v1:

[PATCH] drm/imx: imx-tve: Do not set the regulator voltage

from 2.75V. Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") Cc: <sta...@vger.kernel.org> # 4.8+ Suggested-by: Lucas Stach <l.st...@pengutronix.de> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/gpu/drm/imx/

Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G

On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: > Except I have no way of knowing whether: a) you omitted a supply > because you don't (yet) care, b) the panel has a single supply and you > are using power-supply or c) the panel has multiple supplies and your > binding is

Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima wrote: > Hi, > > I'm trying to use the Seiko 43WVF1G panel (Datasheet link: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS driver > on > the i.MX6SX SabreSD. Applying the patch below removes the

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

On Sun, Feb 5, 2017 at 10:01 PM, Fabio Estevam <feste...@gmail.com> wrote: > > The tda998x_probe() returns success, but tda998x_bind() is never called. > > I am trying to understand what needs to be done in > drivers/gpu/drm/mxsfb/ so that it can bind the tda998

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

On Wed, Feb 8, 2017 at 7:52 AM, Philipp Zabel wrote: > Good point, I suppose what the driver should really do is warn if the > voltage not set correctly? Yes, I can do as suggested. Will prepare a patch. Thanks ___ dri-devel

Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G

Hi Rob, On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote: > No power supply(ies) for this panel? power-supply is mentioned in simple-panel.txt. >> +This binding is compatible with the simple-panel binding, which is specified >> +in simple-panel.txt in this directory. and

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

Hi Rob, On Sat, Feb 4, 2017 at 1:36 AM, Rob Herring wrote: > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c > b/drivers/gpu/drm/mxsfb/mxsfb_out.c > index fa8d17399407..f7d729aa09bd 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c > @@

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

On Sun, Feb 5, 2017 at 8:25 PM, Rob Herring wrote: > Did the bridge driver probe? This function just checks lists of > registered panels and bridges. The tda998x_probe() returns success, but tda998x_bind() is never called. I am trying to understand what needs to be done in

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

Hi Philipp, On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam <feste...@gmail.com> wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by > regulator_set_voltage()") exposes the following probe

Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.

On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima wrote: > - The image is displaced even when using the same timing values in > the datasheet. Managed to fix this framebuffer displacement problem. Will submit a patch soon. ___

Re: Warning at drivers/gpu/drm/drm_atomic_helper.c

On Sun, Jan 22, 2017 at 12:26 PM, Fabio Estevam <feste...@gmail.com> wrote: > On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam <feste...@gmail.com> wrote: >> Hi, >> >> Stopping kmscube application on mx6q through CTRL + C sometimes leads >> to the followin

Warning at drivers/gpu/drm/drm_atomic_helper.c

/0x24) [ 3940.071813] r7: r6: r5:c0146894 r4:ef0f7000 [ 3940.077578] ---[ end trace a2c0d89dc638cc35 ]--- Any ideas on how to fix it? Thanks, Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https

Re: Warning at drivers/gpu/drm/drm_atomic_helper.c

On Mon, Jan 23, 2017 at 1:15 AM, Marek Vasut wrote: > IMHO this will no longer handle the fences correctly and you'll see > rendering artifacts sometimes. Ok, for 4.9.x stable we cannot apply your 782ea2a493ba90800 ("drm/imx: Switch to drm_fb_cma_prepare_fb() helper") as it

Re: Warning at drivers/gpu/drm/drm_atomic_helper.c

Hi Lucas, On Wed, Jan 25, 2017 at 8:43 AM, Lucas Stach wrote: > This only fixes the issue, as with this change we never attach fences to > the plane state. I've looked into this issue a bit and if I'm not > mistaken, this should still be reproducible with 4.10-rc.

Re: Warning at drivers/gpu/drm/drm_atomic_helper.c

On Wed, Jan 25, 2017 at 9:30 AM, Lucas Stach wrote: > Kernel 4.10 just moves the fence attach to the plane state. It has > nothing to do with the used commit function. The issue going away if you > change that on kernel 4.9 is a red herring. > > In any case, can you try

Re: Warning at drivers/gpu/drm/drm_atomic_helper.c

On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam <feste...@gmail.com> wrote: > Hi, > > Stopping kmscube application on mx6q through CTRL + C sometimes leads > to the following kernel warning: > > ^C[ 3939.785516] [ cut here ] > [ 3939.7903

Re: [PATCH] drm/atomic: clear out fence when duplicating state

he kernel warning on 4.9.x. I can now stop kmscube several times without getting any kernel warning: Tested-by: Fabio Estevam <fabio.este...@nxp.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix the .fault functions

ation from incompatible pointer type [-Werror=incompatible-pointer-types] drivers/gpu/drm/omapdrm/omap_gem.c:531:5: error: conflicting types for 'omap_gem_fault' Fix the conversion in some drm drivers. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- This build failure is from lin

Re: imxdrm issue on Hummingboard with LVDS enabled

Hi Russell, On Sun, Feb 12, 2017 at 11:18 AM, Russell King - ARM Linux wrote: > Hi, > > Here's another issue with imxdrm. I got this while trying to reproduce > Dan's problem by enabling the lvds output using the patch below > originally from Fabio, but updated a bit.

[PATCH v4 0/4] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v4

Hi Philipp, On Thu, Aug 25, 2016 at 11:17 AM, Tim Harvey wrote: > Philipp, > > Have you had a chance to review this last series of Steve's submitted > last week? We are down to 4 patches in gpu/ipu-v3 needed in order to > get his IMX5/6 capture driver into staging and the sooner we do that >

[PATCH RESEND] drm/fsl-dcu: disable clock on error path

From: Fabio Estevam <fabio.este...@nxp.com> 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 --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 +- 1 file changed, 5 inse

[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite

On Mon, Sep 19, 2016 at 4:02 PM, Randy Li wrote: > + vcc_sys_lcd: sys-lcd { > + compatible = "regulator-fixed"; > + regulator-name = "vcc_5v"; > + regulator-min-microvolt = <500>; > + regulator-max-microvolt = <500>; > +

[PATCH] README: Fix typos and grammar

Signed-off-by: Fabio Estevam --- README | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README b/README index 603a1c1..15b3064 100644 --- a/README +++ b/README @@ -1,7 +1,7 @@ libdrm - userspace library for drm This is libdrm, a userspace library for accessing

Etnaviv driver does bind with 4.9-rc1

However, with 4.9-rc1 none of these log messages appear: root at imx6qsabresd:~# dmesg | grep etnaviv root at imx6qsabresd:~# For some reason etnaviv_gpu_bind() is never getting called. I haven't debugged this yet. If anyone has some ideas, please let me know. Thanks, Fabio Estevam

Etnaviv driver does bind with 4.9-rc1

Hi Lucas, On Mon, Oct 17, 2016 at 1:12 PM, Lucas Stach wrote: > This is the same issue you already fixed yourself in patch "ARM: imx: > gpc: Initialize all power domains" ;) Oh, you are right :-) I wasn't even using etnaviv when I created such patch. Just applied it against 4.9-rc1 and it

[PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

From: Fabio Estevam <fabio.este...@nxp.com> Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by regulator_set_voltage()") exposes the following probe issue: 63ff.tve supply dac not found, using dummy regulator imx-drm display-subsystem: failed to bind 6

[PATCH] drm/imx: imx-tve: Remove unused variable

'ret' is never used in tve_enable/tve_disable(), so just remove it. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/imx-tve.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c index 3b602ee..8f8aa4a

libdrm-armada repository

Hi Joshua, On Tue, Aug 2, 2016 at 8:09 PM, Joshua Clayton wrote: > Greetings Russell, > I'm publishing an etnaviv yocto layer on github. Cool! Could you please let us know when this layer becomes available? Thanks

[PATCH 1/3] drm/etnaviv: check for errors when enabling clocks

clk_prepare_enable() may fail, so we should better check for its return value and propagate it in the case of failure. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 30 -- 1 file changed, 24 insertions(+), 6 deletions(-) diff --git

[PATCH 2/3] drm/etnaviv: remove unneeded 'fail' label

In the etnaviv_gpu_platform_probe() error path the 'fail' label is used to just return the error code. This can be simplified by returning the error code immediately, so get rid of the unneeded 'fail' label. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12

[PATCH 3/3] drm/etnaviv: remove unneeded variable initialization

There is no need to initialize variable 'err' with 0 because it will be properly assigned later on. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu

[PATCH 1/2] drm/fsl-dcu: Remove unneeded NULL check

devm_ioremap_resource() performs NULL check for the 'res' argument, so remove the unneeded check. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl

[PATCH 2/2] drm/fsl-dcu: Propagate the real error code

In case of platform_get_irq() failure, let's propagate the real error code, instead of a 'fake' one. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b

Question regarding clocks in the DW-HDMI DT bindings

ree binding matches the ones listed at the i.MX6Q Reference Manual - Table 33-1. HDMI Clocks Regards, Fabio Estevam

Question regarding clocks in the DW-HDMI DT bindings

On Thu, Nov 24, 2016 at 8:16 PM, Vladimir Zapolskiy wrote: > correct, for your convenience the table is copied below: > > Clock name | Clock Root | Description > ---++--- > iahbclk | ahb_clk_root | Bus clock >

[PATCH] drm: dw_hdmi: Remove non-standard "gpr" property

From: Fabio Estevam <fabio.este...@nxp.com> The "gpr" property is i.MX specific and is documented at Documentation/devicetree/bindings/display/imx/hdmi.txt, so remove such non-standard property from the common binding doc. Suggested-by: Vladimir Zapolskiy Signed-off-b

Question regarding clocks in the DW-HDMI DT bindings

Hi Vladimir, On Thu, Nov 24, 2016 at 8:16 PM, Vladimir Zapolskiy wrote: > By the way while we're discussing DW HDMI bindings specific to iMX, > I would recommend to remove utterly hackish and iMX only "gpr" > property from the example in bindings/display/bridge/dw_hdmi.txt What if we get rid

Question regarding clocks in the DW-HDMI DT bindings

Hi Laurent, On Thu, Nov 24, 2016 at 9:26 PM, Laurent Pinchart wrote: > Another question I have about the bus clock (CC'ing the devicetree mailing > list as well as the clock maintainers) is whether it should be made optional. > The clock is obviously mandatory from a hardware point of view

Question regarding clocks in the DW-HDMI DT bindings

Hi Vladimir, On Fri, Nov 25, 2016 at 11:00 AM, Vladimir Zapolskiy wrote: > according to the DTSI files in the vanilla kernel DW HDMI IP is found > only on iMX6Q/D and iMX6DL/iMX6S SoCs (but please double check it), > so this approach should work ideally. After thinking more about this I think

Question regarding clocks in the DW-HDMI DT bindings

On Fri, Nov 25, 2016 at 1:22 PM, Laurent Pinchart wrote: >> I got the clock name from I.MX6Q TRM, I also checked the name again >> with Rockchip IC design team now, hope to get some new information soon. > > Thank you. While at it, could you ask them which version of the DW HDMI IP > used in the

[PATCH] drm/imx: check the value returned by regulator_set_voltage()

regulator_set_voltage() may fail, so we better check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/imx-tve.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx

[PATCH RESEND] drm/imx: check the value returned by regulator_set_voltage()

From: Fabio Estevam <fabio.este...@nxp.com> regulator_set_voltage() may fail, so we better check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/imx-tve.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/d

[PATCH 1/3] drm/imx: check the value returned by regulator_set_voltage()

From: Fabio Estevam <fabio.este...@nxp.com> regulator_set_voltage() may fail, so we better check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/imx-tve.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/d

[PATCH 2/3] drm/imx: fix the error message

From: Fabio Estevam <fabio.este...@nxp.com> The error message should say "hsync" instead of "vsync" as we have just checked the "fsl,hsync-pin" property. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/imx-tve.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 3/3] drm/imx: remove unneeded 'or' operation

From: Fabio Estevam <fabio.este...@nxp.com> There is no need for doing an extra 'or' operation when reading the return value from of_property_read_u32(). Just do a simple read instead. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/imx/imx-tve.c | 2 +- 1 file changed, 1 insertion

[PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

Hi Russell, On Tue, Jun 28, 2016 at 3:10 PM, Russell King - ARM Linux wrote: > I believe the iMX6 uses the Synopsis HDMI 3D Phy. Would it be possible > if someone can check whether this is relevant to any of the iMX6 targets > too please? I asked NXP engineer and I was told: "In MX6DQ HDMI

[PATCH] drm/fsl-dcu: disable clock on error path

From: Fabio Estevam <fabio.este...@nxp.com> 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 --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 +- 1 file changed, 5 inse

[alsa-devel] [PATCH 0/9] dw-hdmi audio support

On Tue, Jan 5, 2016 at 1:40 PM, Jean-Michel Hautbois wrote: > What is the status of this series ? > I would like to use audio output in HDMI on my i.MX6 board, but I > don't know if you have some pending WIP on this ? This series is in mainline since 4.4-rc1.

[PATCH] etnaviv: etnaviv_drv: Remove owner assignment from platform_driver

This platform_driver does not need to set an owner as it will be populated by the driver core. Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu

[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain

On Thu, Jan 7, 2016 at 12:47 PM, Tomeu Vizoso wrote: > On 10 November 2015 at 10:33, Daniel Kurtz wrote: > [snip] >> >> The problem appears to be that: >> * On boot, platform_drv_probe() calls dev_pm_domain_attach() before >> drv->probe(); thus, it calls dev_pm_domain_attach() while the device

[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain

On Mon, Jan 11, 2016 at 12:45 PM, Rafael J. Wysocki wrote: > OK, so does the appended patch help? Yes, thanks. I do not see the warnings after 'reboot' with your patch applied: Tested-by: Fabio Estevam

[PATCH] Revert "drm/imx: Remove of_node assignment from ipuv3-crtc driver probe"

Commit 407c9eba789767 ("drm/imx: Remove of_node assignment from ipuv3-crtc driver probe") causes the IPU to be non-functional, so better to revert it to avoid such regression. This reverts commit 407c9eba789767feb68b42eb2d65db68584e06c0. Cc: # 4.4.x Signed-off-by: Fabio Estevam --

[PATCH] Revert "drm/imx: Remove of_node assignment from ipuv3-crtc driver probe"

Hi Philipp, On Wed, May 18, 2016 at 5:38 AM, Philipp Zabel wrote: > Could you also test https://patchwork.kernel.org/patch/9081661/ ? With this patch applied I still do not get HDMI working on a mx6q sabresd board. Thanks

[PATCH v2] drm/imx: Match imx-ipuv3-crtc components using device node in platform data

gainst the > pdata->of_node instead of dev->of_node in imx-drm-core to work around > this problem. > > Cc: # 4.4.x > Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading") > Signed-off-by: Philipp Zabel Thanks, Philipp. With this patch HDMI is functional again: Tested-by: Fabio Estevam

[PATCH] gpu: ipu-v3: display support on the aristainetos2 board broken

Hi Heiko, On Fri, May 20, 2016 at 8:15 AM, Heiko Schocher wrote: > commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading") > breaks the aristainetos2 board with the "lg,lg4573" panel. > > This reverts the above commit. > > Signed-off-by: Heiko Schocher > > --- > Any hint, how

[PATCH 2/5] arm/dts/imx6q-b850v3: Configure IPU assignment order

On Mon, May 30, 2016 at 1:39 PM, Peter Senna Tschudin wrote: > Configure the IPU assignment order to assign one IPU per external > display. A single IPU can drive multiple external displays but there are > resolution restrictions. After this patch the GPU is capalbe of driving two I think you

[PATCH 5/5] arm/dts/imx6q-b850v3: Use GE B850v3 LVDS/DP++ Bridge

On Mon, May 30, 2016 at 1:39 PM, Peter Senna Tschudin wrote: > +_i2c2 { > + status = "okay"; > + clock-frequency = <10>; > + > + b850v3_lvds_dp_bridge { > + compatible = "ge,b850v3_lvds_dp"; > + #address-cells = <1>; > + #size-cells

[PATCH 1/2] drm/fsl-dcu: remove unneeded 'ret' assignment

From: Fabio Estevam <fabio.este...@nxp.com> When devm_kzalloc() fails there is no need to assign an error code to the 'ret' variable as it will not be used after jumping to the 'err_node_put' label, so just remove the assignment. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/f

[PATCH 2/2] drm/fsl-dcu: check for clk_prepare_enable() error

From: Fabio Estevam <fabio.este...@nxp.com> clk_prepare_enable() may fail, so we should better check its return value. Also place the of_node_put() function right after clk_prepare_enable(), in order to avoid calling of_node_put() twice in case clk_prepare_enable() fails. Signed-off-by:

[PATCH 2/2] drm/fsl-dcu: check for clk_prepare_enable() error

On Wed, Dec 28, 2016 at 4:38 PM, Gabriel Krisman Bertazi wrote: > This leaks tcon if clk_prepare_enable fails. No, it does not as tcon is allocated via devm_kzalloc().

[PATCH] drm: fixes when bridge mode_fixup is null.

On Wed, Feb 10, 2016 at 9:03 AM, Carlos Palminha wrote: > Avoid drivers to copy/past code to implement functions that will only return > true. > --- You missed your Signed-off-by.

[PATCH] drm: drm_pci: Include "drm_internal.h"

From: Fabio Estevam <fabio.este...@freescale.com> Include "drm_internal.h" to fix the following sparse warnings: drivers/gpu/drm/drm_pci.c:146:5: warning: symbol 'drm_pci_set_unique' was not declared. Should it be static? drivers/gpu/drm/drm_pci.c:216:5: warning: symbol '

[PATCH RESEND] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig

From: Fabio Estevam <fabio.este...@freescale.com> SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry. Signed-off-by: Fabio Estevam --- drivers/gpu/ipu-v3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/Kconfig b/d

[PATCH] drm/bridge: dw-hdmi: Staticize dw_hdmi_bridge_funcs

From: Fabio Estevam <fabio.este...@freescale.com> Staticize dw_hdmi_bridge_funcs to fix the following sparse warning: drivers/gpu/drm/bridge/dw_hdmi.c:1458:25: warning: symbol 'dw_hdmi_bridge_funcs' was not declared. Should it be static? Signed-off-by: Fabio Estevam --- drivers/g

[PATCH] imx-drm: imx-hdmi: move memory and resource allocation into probe function

Philipp, On Wed, May 14, 2014 at 6:24 PM, Philipp Zabel wrote: > Move memory allocation and resource acquisition from the bind function into > the probe function. This calls the devres managed functions once instead of > possibly multiple times in the bind function and avoids leaking memory (as

[PATCH] fix compilation of imx-hdmi

re > > Fix it by using the one in linux/hdmi.h > > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Sachin has also sent the same fix: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-January/045167.html Regards, Fabio Estevam

[PATCH 8/8] drm/tilcdc: panel: Add support for enable GPIO

On Fri, Jul 11, 2014 at 11:18 AM, Ezequiel Garcia wrote: > In order to support the "enable GPIO" available in many panel devices, > this commit adds a proper devicetree binding. > > By providing an enable GPIO in the devicetree, the driver can now turn > off and on the panel device, and/or the

[PATCH] imx-drm: imx-drm-core: Convert to drm_is_master()

From: Fabio Estevam <fabio.este...@freescale.com> Since commit fe32c9f34b9e ("drm: drop redundant drm_file->is_master") we should use drm_is_master, otherwise the following build error is seen: drivers/staging/imx-drm/imx-drm-core.c: In function 'imx_drm_driver_preclose': driv

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

Russell, On Fri, Jun 6, 2014 at 10:56 AM, Russell King wrote: > The initial state at boot is assumed to be disconnected, and we hope > to receive an interrupt to update the status. Let's be more explicit > about the current state - reading the PHY status register

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux wrote: > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This > should report the current state of the hotplug detection. /sys/class/drm/card0-HDMI-A-1/status returns the correct state for HDMI cable connection. >

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 11:33 AM, Shawn Guo wrote: > On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote: >> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux >> wrote: >> >> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 2:49 PM, Russell King - ARM Linux wrote: > On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote: >> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux >> wrote: >> >> > Please check the status in /sys/class/drm/card0-HDMI

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote: >> I wonder if the problem is that HDMI and LVDS are interfering with each >> other wrt the required pixel clock, and LVDS is winning. If we have >> HDMI enabled, many HDMI sinks will only work if we set one of their

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 3:38 PM, Fabio Estevam wrote: > On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote: >>> I wonder if the problem is that HDMI and LVDS are interfering with each >>> other wrt the required pixel clock, and LVDS is winning. If we have >>>

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux wrote: > Right, so the problem isn't at the HDMI level, but at the DI level... so > that's where we need to debug what's being setup. I left some debugging > in ipu-di.c - could you try enabling that please? Sure, will capture the logs

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux wrote: > Right, so the problem isn't at the HDMI level, but at the DI level... so > that's where we need to debug what's being setup. I left some debugging > in ipu-di.c - could you try enabling that please? Booting the kernel with the

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Tue, Jun 10, 2014 at 9:58 AM, Fabio Estevam wrote: > On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux > wrote: > >> Right, so the problem isn't at the HDMI level, but at the DI level... so >> that's where we need to debug what's being setup. I left some deb

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Tue, Jun 10, 2014 at 2:04 PM, Russell King - ARM Linux wrote: > This diagram is drawn from the code in clk-imx6.c, and it does not > agree with what is in the SoC manuals - this is the representation > redrawn from the manuals: > The difference is, there is no clock gate between the LDB

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

Hi Tim, On Tue, Jun 10, 2014 at 3:54 PM, Tim Harvey wrote: > Fabio, > > I'm following along with this thread as I see the same thing you do on > our Ventana boards that support both LVDS and HDMI: without > hot-plugging the HDMI connector I get not HDMI out simply by having > the LVDS node

[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux wrote: > The problem here is that we need more inteligence from CCF in order to > do that - we need it to be able to reprogram the dividers so that the > IPU DI0 clock remains at 148.5MHz while increasing the output of > pll5_video_div

[PATCH] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig

From: Fabio Estevam <fabio.este...@freescale.com> SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry. Signed-off-by: Fabio Estevam --- drivers/gpu/ipu-v3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/Kconfig b/d

[PATCH] gpu: ipu-v3: ipu-di: Print the generated pixelclock error

: Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz imx-ipuv3 240.ipu: Want 6500Hz IPU 26400Hz DI 6499Hz using DI, 6499Hz, error 0.9% Signed-off-by: Fabio Estevam --- drivers/gpu/ipu-v3/ipu-di.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git

[PATCH 00/72] staging imx-drm new features and fixes

Hi Steve, On Fri, Oct 31, 2014 at 10:19 PM, Steve Longerbeam wrote: > Hi Fabio, Yes I forgot to mention that in the cover letter: > > git at github.com:slongerbeam/drm-next.git > > Branch is imx-drm-mentor. Just tried it here. There were some dtb file build issues and I just removed the dtb's

[PATCH 00/72] staging imx-drm new features and fixes

On Mon, Nov 3, 2014 at 11:12 AM, Fabio Estevam wrote: > Hi Steve, > > On Fri, Oct 31, 2014 at 10:19 PM, Steve Longerbeam > wrote: > >> Hi Fabio, Yes I forgot to mention that in the cover letter: >> >> git at github.com:slongerbeam/drm-next.git >> >

[PATCH 00/72] staging imx-drm new features and fixes

On Mon, Nov 3, 2014 at 11:12 AM, Fabio Estevam wrote: > Hi Steve, > > On Fri, Oct 31, 2014 at 10:19 PM, Steve Longerbeam > wrote: > >> Hi Fabio, Yes I forgot to mention that in the cover letter: >> >> git at github.com:slongerbeam/drm-next.git >> >

[PATCH 00/72] staging imx-drm new features and fixes

On Mon, Nov 3, 2014 at 11:20 AM, Fabio Estevam wrote: > On Mon, Nov 3, 2014 at 11:12 AM, Fabio Estevam wrote: >> Hi Steve, >> >> On Fri, Oct 31, 2014 at 10:19 PM, Steve Longerbeam >> wrote: >> >>> Hi Fabio, Yes I forgot to mention that in the cover let

[PATCH 00/72] staging imx-drm new features and fixes

On Mon, Nov 3, 2014 at 4:59 PM, Steve Longerbeam wrote: >> Steve, what's the status of getting this driver out of staging? What is >> left to do, and who is doing the work? > > Hi Greg, you should also talk with the original authors (Sascha and > Philipp at Pengutronix), but in my experience,

[PATCH 05/72] ARM: i.MX6: select pll3_usb_otg for ldb_di for rev 1.0 chip

On Mon, Nov 3, 2014 at 5:17 PM, Steve Longerbeam wrote: > Internally we are using Freescale's workaround patch for this problem, > but it has a lot of issues, most of which is that it needs to be incorporated > into the clk API so that the workaround would be applied whenever the > LDB parent

[PATCH 00/72] staging imx-drm new features and fixes

Hi Steve, On Mon, Nov 3, 2014 at 8:41 PM, Steve Longerbeam wrote: > Hi Fabio, which panel? The Hannstar or the 1024x600 Okaya 7" > panel? I am using the Hannstar. > > I have noticed wrong colors using the Okaya panel as well, and it > is fixed by switching to "jeida" 24-bit interface in the

  1   2   3   4   5   6   >