Re: [PATCH 1/3] ARM: dts: am437x-gp/epos-evm: fix panel compatible

* Laurent Pinchart [191202 13:02]: > Hi Tomi, > > Thank you for the patch. > > On Thu, Nov 14, 2019 at 11:39:48AM +0200, Tomi Valkeinen wrote: > > The LCD panel on AM4 GP EVMs and ePOS boards seems to be > > osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly > > the panel

Re: [PATCH 2/3] ARM: dts: am437x-gp/epos-evm: drop unused panel timings

* Laurent Pinchart [191202 13:05]: > Hi Tomi, > > Thank you for the patch. > > On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote: > > panel-simple now handled panel osd070t1718-19ts, and we no longer need > > the panel timings in the DT file. So remove them. > > Should you in that

Re: [PATCH 0/3] drm/omap: fix am4 evm lcd

Hi * Tomi Valkeinen [191127 12:59]: > Hi Tony, Thierry, Laurent, > > Any thoughts on the below points? > I think yet another option is to write some omap boot time quirks code, > which looks at the DT data, and changes the panel compatible string (for 1), > and removes the timings node (for

Re: [PATCH v3 8/8] MIPS: DTS: jz4780: add sgx gpu node

* H. Nikolaus Schaller [191124 18:00]: > Hi Paul, Tony, > > > Am 24.11.2019 um 18:48 schrieb Tony Lindgren : > > > > * Paul Cercueil [191124 12:58]: > >> Le dim., nov. 24, 2019 at 12:40, H. Nikolaus Schaller > >> a > >> écrit : > >

Re: [PATCH v3 8/8] MIPS: DTS: jz4780: add sgx gpu node

* Paul Cercueil [191124 12:58]: > Le dim., nov. 24, 2019 at 12:40, H. Nikolaus Schaller a > écrit : > > and add interrupt and clocks. ... > > --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi > > +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi > > @@ -46,6 +46,17 @@ > > #clock-cells = <1>; >

Re: [PATCH v10 6/6] backlight: add led-backlight driver

Hi, * Jean-Jacques Hiblot [700101 00:00]: > From: Tomi Valkeinen > > This patch adds a led-backlight driver (led_bl), which is similar to > pwm_bl except the driver uses a LED class driver to adjust the > brightness in the HW. Multiple LEDs can be used for a single backlight. ... > + ret

Re: [PATCH v10 5/6] dt-bindings: backlight: Add led-backlight binding

Hi, * Rob Herring [700101 00:00]: > On Wed, Oct 09, 2019 at 10:51:26AM +0200, Jean-Jacques Hiblot wrote: > > Add DT binding for led-backlight. ... > > new file mode 100644 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml ... > > +

Re: [RFCv1 33/42] drm/omap: dsi: use atomic helper for dirtyfb

* Tomi Valkeinen [191119 15:56]: > Afaik, Weston and X both handle page flips and/or dirtying the fb, so they > should work. Are there applications that do not work, and cannot be made to > work, except the few SGX test apps? I'm not sure sure yet what all it affects, I'll do some more tests on

Re: [RFCv1 33/42] drm/omap: dsi: use atomic helper for dirtyfb

* Tomi Valkeinen [191119 05:42]: > On 19/11/2019 01:05, Tony Lindgren wrote: > > * Sebastian Reichel [191117 07:11]: > > > We can simply use the atomic helper for > > > handling the dirtyfb callback. > > ... > > > --- a/drivers/gpu/drm/omapdrm/omap_

Re: [RFCv1 33/42] drm/omap: dsi: use atomic helper for dirtyfb

* Tomi Valkeinen [191119 14:54]: > On 19/11/2019 16:32, Tony Lindgren wrote: > > > > We haven't had omap_gem_op_finish() in the kernel for some years now... > > > > > > Shouldn't a normal page flip, or if doing single-buffering, using the > > > d

Re: [RFCv1 33/42] drm/omap: dsi: use atomic helper for dirtyfb

* Sebastian Reichel [191117 07:11]: > We can simply use the atomic helper for > handling the dirtyfb callback. ... > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c > -void omap_crtc_flush(struct drm_crtc *crtc) > +static void omap_crtc_flush(struct drm_crtc

Re: [RFCv1 11/42] ARM: dts: omap: add channel to DSI panels

* Sebastian Reichel [191118 15:03]: > On Mon, Nov 18, 2019 at 03:37:12PM +0100, H. Nikolaus Schaller wrote: > > > Am 18.11.2019 um 15:33 schrieb Sebastian Reichel > > > : > > > On Mon, Nov 18, 2019 at 03:05:07PM +0200, Tomi Valkeinen wrote: > > >> On 17/11/2019 04:39, Sebastian Reichel wrote: >

Re: [PATCH v2 1/8] RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs

* H. Nikolaus Schaller [191107 16:56]: > > Am 07.11.2019 um 15:35 schrieb Rob Herring : > > On Thu, Nov 7, 2019 at 5:06 AM H. Nikolaus Schaller > > wrote: > >> Clock, Reset and power management should be handled > >> by a parent node or elsewhere. > > > > That's probably TI specific... > >

Re: [PATCH v2 1/8] RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs

* H. Nikolaus Schaller [191107 11:07]: > +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530", > "img,sgx5" I did a quick probe test for the module and am4 is the same as am335x, so please also add this for the next version: "ti,am4-sgx530-125" Regards, Tony

Re: [PATCH v2 1/8] RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs

* H. Nikolaus Schaller [191107 11:07]: > +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530", > "img,sgx5" This should be without the x, maybe use the earliest one here for "ti,am3352-sgx530-125" like we have for "ti,am3352-uart". We could use "ti,am3-sgx530-125" but that

Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings

* H. Nikolaus Schaller [191018 18:47]: > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt > @@ -0,0 +1,76 @@ > +Imagination PVR/SGX GPU > + > +Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered by > this binding. > + > +Required properties: > +-

Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings

* H. Nikolaus Schaller [191022 15:12]: > Hm. How should that work? Some SoC have the sgx544 as single > core and others as dual core. This imho does not fit into > the "img,sgx544-$revision" scheme which could be matched to. Well don't you have then just two separate child nodes, one for each

Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings

* H. Nikolaus Schaller [191021 18:08]: > > > Am 21.10.2019 um 19:25 schrieb Tony Lindgren : > > > > * H. Nikolaus Schaller [191021 15:46]: > >>> Am 21.10.2019 um 17:07 schrieb Rob Herring : > >>> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schall

Re: [PATCH V5 3/3] ARM: logicpd-torpedo-37xx-devkit-28: Reference new DRM panel

* Adam Ford [191016 06:53]: > With the removal of the panel-dpi from the omap drivers, the > LCD no longer works. This patch points the device tree to > a newly created panel named "logicpd,type28" > > Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver") > > Signed-off-by: Adam Ford >

Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings

* H. Nikolaus Schaller [191021 15:46]: > > Am 21.10.2019 um 17:07 schrieb Rob Herring : > > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller > > wrote: > >> +Optional properties: > >> +- timer: the timer to be used by the driver. > > > > Needs a better description and vendor prefix

Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings

* H. Nikolaus Schaller [191021 15:46]: > > Am 21.10.2019 um 17:07 schrieb Rob Herring : > > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller > > wrote: > >> +- reg: Physical base addresses and lengths of the register areas. > > > > How many? > > I assume there is only one. At

Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var

* Tomi Valkeinen [191011 10:25]: > On 10/10/2019 16:24, Tony Lindgren wrote: > > > Hmm so what register does this clock actually change? > > > > I'm seeing an increase of few tens of extra mW, which means at > > least one day of standby time less for me :) It doe

Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var

* Tomi Valkeinen [191010 06:48]: > On 08/10/2019 17:21, Tony Lindgren wrote: > > * Tomi Valkeinen [191008 14:17]: > > > On 08/10/2019 17:13, Tony Lindgren wrote: > > > > * Tomi Valkeinen [190930 10:38]: > > > > > If use_mclk is fals

Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var

* Tomi Valkeinen [191008 14:17]: > On 08/10/2019 17:13, Tony Lindgren wrote: > > * Tomi Valkeinen [190930 10:38]: > > > If use_mclk is false, mclk_mode is written to a register without > > > initialization. This doesn't cause any ill effects as the written value >

Re: [PATCHv2 7/7] drm/omap: hdmi4: fix use of uninitialized var

ce catch. Based on a quick test looks like this fixes an issue where power consumption stays higher after using HDMI. Would be nice to have merged in the v5.4-rc series: Tested-by: Tony Lindgren ___ dri-devel mailing list dri-devel@lists.freede

Re: [PATCH] ARM: dts: am4372: Set memory bandwidth limit for DISPC

* Tomi Valkeinen [190930 01:55]: > From: Peter Ujfalusi > > Set memory bandwidth limit to filter out resolutions above 720p@60Hz to > avoid underflow errors due to the bandwidth needs of higher resolutions. > > am43xx can not provide enough bandwidth to DISPC to correctly handle > 'high'

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

* Tony Lindgren [190530 05:47]: > * Tony Lindgren [190529 08:11]: > > * Tomi Valkeinen [190529 07:06]: > > > On 28/05/2019 13:18, Tony Lindgren wrote: > > > > > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my > > > &g

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

* Tony Lindgren [190529 08:11]: > * Tomi Valkeinen [190529 07:06]: > > On 28/05/2019 13:18, Tony Lindgren wrote: > > > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my > > > > kernel > > > > config. > > >

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

* Tomi Valkeinen [190529 07:06]: > On 28/05/2019 13:18, Tony Lindgren wrote: > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel > > > config. > > > > Strange that this is not affecting other x15? I think timer12 would

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

* Tomi Valkeinen [190528 10:05]: > On 28/05/2019 12:39, Tony Lindgren wrote: > > Hi, > > > > * Tomi Valkeinen [190528 09:19]: > > > On 27/05/2019 14:21, Tony Lindgren wrote: > > > > > > > > Looks good to me. For some reason I can't boot 5

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

Hi, * Tomi Valkeinen [190528 09:19]: > On 27/05/2019 14:21, Tony Lindgren wrote: > > >> Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I > >> haven't > >> been able to test yet. I'll pick the series up in any case, and I'll test > >

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

* Tomi Valkeinen [190527 10:51]: > Hi, > > On 23/05/2019 23:07, Sebastian Reichel wrote: > > Hi, > > > > Here is another round of the DSI command mode panel patchset > > integrating the feedback from PATCHv5. The patches are based > > on v5.2-rc1 tag. It does not contain the patches required

Re: [PATCHv6 4/4] drm/omap: add support for manually updated displays

read. So as far as I'm concerned, we're good to go: Tested-by: Tony Lindgren ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2] omapdrm: hdmi4_cec: Fix CEC clock handling for PM

by: Hans Verkuil Cc: Hans Verkuil Cc: Jyri Sarha Cc: Laurent Pinchart Signed-off-by: Tony Lindgren --- Changes since v1: - Move clock enable to happen after the whole disable section rather than add a pointless test for enable as noted by Hans - Move clock enable to happen after hdmi4_core_e

Re: [PATCH] omapdrm: hdmi4_cec: Fix CEC clock handling for PM

* Hans Verkuil [190326 06:36]: > On 3/26/19 12:47 AM, Tony Lindgren wrote: > > @@ -169,12 +169,19 @@ static int hdmi_cec_adap_enable(struct cec_adapter > > *adap, bool enable) > > struct hdmi_core_data *core = cec_get_drvdata(adap); > > int temp, err

Re: CEC blocks idle on omap4

* Hans Verkuil [190325 16:12]: > On 3/25/19 4:55 PM, Laurent Pinchart wrote: > >> The reality is that HDMI CEC and HDMI video are really independent of > >> one another. So I wonder if it isn't better to explain the downsides > >> of enabling CEC for the omap4 in the CONFIG_OMAP4_DSS_HDMI_CEC >

CEC blocks idle on omap4

Hi Hans, Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention idle on omap4 if selected. Should we maybe move hdmi4_cec_init() to hdmi_display_enable() and hdmi4_cec_uninit() to hdmi_display_disable()? Or add some enable/disable calls in addtion to the init and uninit calls that can

[PATCH] omapdrm: hdmi4_cec: Fix CEC clock handling for PM

by: Hans Verkuil Cc: Hans Verkuil Cc: Jyri Sarha Cc: Laurent Pinchart Signed-off-by: Tony Lindgren --- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c b/drivers/gpu/drm/oma

Re: CEC blocks idle on omap4

* Hans Verkuil [190325 15:52]: > Hi Tony, > > On 3/25/19 4:32 PM, Tony Lindgren wrote: > > Hi Hans, > > > > Looks like CONFIG_OMAP4_DSS_HDMI_CEC=y blocks SoC core retention > > idle on omap4 if selected. > > > > Should we maybe

Re: CEC blocks idle on omap4

* Hans Verkuil [190325 16:28]: > On 3/25/19 5:21 PM, Tony Lindgren wrote: > > * Hans Verkuil [190325 16:12]: > >> On 3/25/19 4:55 PM, Laurent Pinchart wrote: > >>>> The reality is that HDMI CEC and HDMI video are really independent of > >>>> one an

Regression in Linux next with dma cma changes

Hi, Looks like commit d222e42e8816 ("dma-contiguous: do not allocate a single page from CMA area") caused a regression at least for omap dss where we now get the following error on init: omapdss_dispc 58001000.dispc: dispc_errata_i734_wa_init: dma_alloc_writecombine failed Any ideas what might

Re: [PATCH] Revert "dma-contiguous: do not allocate a single page from CMA area"

question is whether to add alloc_page()/free_page() fallbacks to > those call sites, or stuff them directly into the CMA helpers here. Well if you come up with some test patch, I can easily test it :) > > Would you please test and verify? Thanks! Yes this revert works for me: Tested-by:

Re: [PATCHv2] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

* Tomi Valkeinen [190208 09:11]: > Looks fine to me and works on panda. I'll queue this to the next merge > window (I presume no rush to get this into the current -rcs, it's a bit > late). OK good to hear panda works too, my panda is in my rack.. This one has been broken for a long time and

[PATCHv2] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

renumbering of the error path for dsi_display_init_dsi(). Suggested-by: Tomi Valkeinen Signed-off-by: Tony Lindgren --- Changes since v1: - Updated with Tomi's suggested changes to not break DVI with regulator_enable() made conditional for dsi_display_init_dsi() - Updated comments to better

Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

* Tomi Valkeinen [190207 09:07]: > On 06/02/2019 18:29, Tony Lindgren wrote: > > > OK. Looks good to me otherwise. > > > > So I guess we should fix. Do you want me to post it all > > as a single patch after some testing? > > Yes please =

Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

* Tomi Valkeinen [190206 09:13]: > On 05/02/2019 19:58, Tony Lindgren wrote: > > * Tomi Valkeinen [190205 11:07]: > >> Yep... So there's the DSI internal code which needs to deal with ulps > >> and disconnect_lanes, and then the external interface to the DSI PLL (so &g

Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

* Tomi Valkeinen [190206 16:09]: > On 06/02/2019 18:00, Tony Lindgren wrote: > > > OK I'll give it a try. Based on a quick glance, we need to still > > check for enabled regulator to avoid unpaired calls. > > > >> static int dsi_dump_dsi_clocks(struct seq_

Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

* Tomi Valkeinen [190205 11:07]: > Yep... So there's the DSI internal code which needs to deal with ulps > and disconnect_lanes, and then the external interface to the DSI PLL (so > that DPI can use DSI PLL) without ulps/disconnect. > > I think your patch breaks this latter one, as

Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

Hi, * Tomi Valkeinen [190204 09:57]: > On 31/01/2019 05:32, Tony Lindgren wrote: > > Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not > > paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves > > But it is paired with dsi_pll_uninit().

[PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls

lag and making the current dsi_pll_uninit() into dsi_pll_disable(). This way we can just call dss_pll_disable() from dsi_display_uninit_dsi() and the code becomes a bit easier to follow. Signed-off-by: Tony Lindgren --- drivers/gpu/drm/omapdrm/dss/dsi.c | 18 -- 1 file changed

Re: [PATCH] fbdev: omap2: no need to check return value of debugfs_create functions

* Greg Kroah-Hartman [190122 15:28]: > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. Acked-by: Tony

Re: [PATCH] drm/omap: sharp ls037v7dw01: restore optional GPIOs

GPIOs that could be specified in DT to satisfy this. > > Switch the driver to use the devm_gpiod_get_index_optional() rather > than devm_gpiod_get_index() to conform to its binding documentation. > > Fixes: ca8c67dafdb7 ("fbdev: omap2: improve usage of g

Re: [PATCHv5 4/6] drm/omap: fix incorrect union usage

ction is inlined and HDMI type has already been checked. > > Fixes: 83910ad3f51fb ("drm/omap: Move most omap_dss_driver operations to > omap_dss_device_ops") > Signed-off-by: Sebastian Reichel Works for me: Tested-by: Tony Lindgren ___ dri

Re: [PATCHv4 0/6] omapdrm: DSI command mode panel support

and for automatic > display rotation. They should get their own series, once this > patchset has landed. Great, works for me: Tested-by: Tony Lindgren ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/omap: dsi: Fix missing of_platform_depopulate()

* Laurent Pinchart [181107 05:30]: > Hi Tony, > > Thank you for the patch. > > On Tuesday, 6 November 2018 17:28:02 EET Tony Lindgren wrote: > > We're missing a call to of_platform_depopulate() on errors for dsi. > > Looks like dss is already doing this. > >

[PATCH] drm/omap: dsi: Fix missing of_platform_depopulate()

We're missing a call to of_platform_depopulate() on errors for dsi. Looks like dss is already doing this. Signed-off-by: Tony Lindgren --- drivers/gpu/drm/omapdrm/dss/dsi.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers

Re: [PATCH 0/3] omapdrm: Fix runtime PM issues at module load and unload time

* Laurent Pinchart [181105 15:14]: > Hi Tony, > > On Thursday, 1 November 2018 18:17:43 EET Laurent Pinchart wrote: > > On Thursday, 1 November 2018 17:58:56 EET Tony Lindgren wrote: > > > * Laurent Pinchart [181101 12:13]: > > >> On Thursday, 1 November 20

Re: [PATCH v2 2/4] drm/omap: hdmi4: Ensure the device is active during bind

* Laurent Pinchart [181105 15:10]: > The bind function performs hardware access (in hdmi4_cec_init()) and > thus requires the device to be active. Ensure this by surrounding the > bind function by hdmi_runtime_get() and hdmi_runtime_put() calls. > > Fixes: 27d624527d99 ("drm/omap: dss: Acquire

Re: [PATCH v2 3/4] drm/omap: dsi: Ensure the device is active during probe

_put() calls. > > Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind > to probe") > Signed-off-by: Laurent Pinchart Acked-by: Tony Lindgren ___ dri-devel mailing list dri-devel@lists.freedesktop.org htt

Re: [PATCH v2 1/4] drm/omap: Populate DSS children in omapdss driver

cquire next dssdev at probe time") > Signed-off-by: Laurent Pinchart Please merge this together with the DSS fixes: Acked-by: Tony Lindgren ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC/PATCH] drm/omap: Move DISPC runtime PM handling to omapdrm

* Laurent Pinchart [181105 19:23]: > This patch applies on top of the "[PATCH v2 0/4] omapdrm: Fix runtime PM > issues at module load and unload time" series. It demonstrates what I > think is the proper long term fix for the issue addressed by patch 4/4. > Due to its nature, I don't think this

Re: [PATCH 0/3] omapdrm: Fix runtime PM issues at module load and unload time

Hi, * Laurent Pinchart [181101 12:13]: > On Thursday, 1 November 2018 13:47:40 EET Tomi Valkeinen wrote: > > We do dispc_runtime_get/put in the HDMI driver's suspend/resume too, so > > don't we need similar hack (as you add in dsi.c) there also? > > We would if we had to access HDMI registers

Re: omap4: support for manually updated display

* Tony Lindgren [181022 16:31]: > * Tomi Valkeinen [181022 08:14]: > > On 20/10/18 03:38, Tony Lindgren wrote: > > > * Sebastian Reichel [181019 15:58]: > > >> I uploaded my current status here. It's not based on the newest > > >> -next, but contains

Re: omap4: support for manually updated display

* Tomi Valkeinen [181022 08:14]: > On 20/10/18 03:38, Tony Lindgren wrote: > > * Sebastian Reichel [181019 15:58]: > >> I uploaded my current status here. It's not based on the newest > >> -next, but contains the interesting patches from Laurent. Also > >&

Re: omap4: support for manually updated display

* Sebastian Reichel [181019 15:58]: > I uploaded my current status here. It's not based on the newest > -next, but contains the interesting patches from Laurent. Also > the last few patches are not yet cleaned up, sorry for the mess. Way to go, thanks :) Here's a quick fix for issues with

Re: omap4: support for manually updated display

* Pavel Machek [181018 22:15]: > Hi! > > > > I want to make it clear that I don't want to claim any privilege in > > > getting > > > patches merged first. I am however worried that, without an easy way to > > > test > > > DSI support, and without enough time to focus on it, I would break >

Re: [PATCH v3 0/3] ARM: OMAP1: ams-delta: Complete driver gpiod migration

* Janusz Krzysztofik [180919 18:13]: > On Monday, September 10, 2018 12:56:02 AM CEST Janusz Krzysztofik wrote: > > > > This is a follow up of initial submission of a series consisted of > > 6 changes, 3 of which have been already applied or reworkeed. > > > > > > Janusz Krzysztofik (3): > >

Re: omap4: support for manually updated display

* Laurent Pinchart [180910 12:28]: > On Monday, 10 September 2018 14:59:23 EEST Tomi Valkeinen wrote: > > A large omapdrm change set from Laurent was merged into drm-next, and > > I'm certain they conflict with this series. Laurent also has continued > > that work, and while those new patches

Re: 4.19-rc1 on droid 4: screen not updating

* Pavel Machek [180827 10:55]: > Hi! > > With Sebastian's patches, display works on Droid 4 in v4.18. Hmm care to post your v4.18 patches somewhere too for people? I'd have to look around for them since I've been using Linux next for past few months. Also, do you have v4.19-rc1 versions of

Re: [PATCH v2 2/3 v4] mtd: rawnand: ams-delta: use GPIO lookup table

* Miquel Raynal [180718 07:24]: > Hi Janusz, Tony > > Janusz Krzysztofik wrote on Wed, 18 Jul 2018 > 01:14:47 +0200: > > > Now as Amstrad Delta board - the only user of this driver - provides > > GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and > > use the table to locate

Re: [PATCH] omapfb: rename omap2 module to omap2fb.ko

t; > The solution is to rename one of the two modules, so for consistency with > the directory naming I decided to rename the omap2 version to omap2fb.ko. Sounds good to me: Acked-by: Tony Lindgren ___ dri-devel mailing list dri-devel@lists.f

Re: [RFC PATCHv2 0/9] drm/tidss: new display driver for TI's DSS6 & DSS7

* Tomi Valkeinen [180619 08:29]: > On 19/06/18 09:24, Tony Lindgren wrote: > > * Tomi Valkeinen [180618 13:25]: > >> Hi, > >> > >> > >> This is a new D

Re: [RFC PATCHv2 0/9] drm/tidss: new display driver for TI's DSS6 & DSS7

* Tomi Valkeinen [180618 13:25]: > Hi, > > > This is a new DRM driver for Texas Instruments' Keystone K2G and AM6 > SoCs. > > K2G has DSS6 IP, which is related to the OMAP DSS IPs handled by the >

Re: [RFC PATCHv2 8/9] ARM: dts: keystone-k2g: add DSS node

* Tomi Valkeinen [180618 13:26]: > Add DSS node to k2g.dtsi. > > Signed-off-by: Tomi Valkeinen > Cc: devicet...@vger.kernel.org > --- > arch/arm/boot/dts/keystone-k2g.dtsi | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi >

Re: [RFC PATCHv2 8/9] ARM: dts: keystone-k2g: add DSS node

* Tomi Valkeinen [180619 07:12]: > On 19/06/18 09:19, Tony Lindgren wrote: > > * Tomi Valkeinen [180618 13:26]: > >> Add DSS node to k2g.dtsi. > >> > >> Signed-off-by: Tomi Valkeinen > >> Cc: devicet...@vger.kernel.org > >&

Re: omapdrm regression in v4.17-rc series

* Tomi Valkeinen <tomi.valkei...@ti.com> [180524 08:00]: > > On 24/05/18 01:03, Tony Lindgren wrote: > > Hi all, > > > > I bisected the n900 LCD issue to commit 24aac6011f70 ("drm: omapdrm: > > sdi: Allocate the sdi private data structure dynamically&q

omapdrm regression in v4.17-rc series

Hi all, I bisected the n900 LCD issue to commit 24aac6011f70 ("drm: omapdrm: sdi: Allocate the sdi private data structure dynamically"). Reverting this patch makes LCD work for me again on n900. Any ideas? Regards, Tony ___ dri-devel mailing list

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

Hi, * Daniel Stone [180420 10:21]: > Hi Tomi, > > On 20 April 2018 at 08:09, Tomi Valkeinen wrote: > > It's actually not quite clear to me how manual update displays work with > > DRM... > > > > As far as I see, we have essentially two cases: 1)

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

* Daniel Stone <dan...@fooishbar.org> [180420 14:41]: > Hi Tony! > > On 20 April 2018 at 15:25, Tony Lindgren <t...@atomide.com> wrote: > > * Daniel Stone <dan...@fooishbar.org> [180420 10:21]: > >> On 20 April 2018 at 08:09, Tomi Valkeinen <tomi.

Re: DRI3 WSEGL plugin for TI SGX

* Tomi Valkeinen [180416 07:51]: > Hi All, > > I have implemented a WSEGL plugin library for Imagination's PVR driver > for SGX, which allows using SGX via DRI3. In other words, it is one > piece in the puzzle of using SGX with X11. > > The project is not production

Re: [PATCHv2 2/8] drm/omap: add manual update detection helper

* Sebastian Reichel <sebastian.reic...@collabora.co.uk> [180208 18:31]: > In preparation for manually updated display support, such as DSI > command mode panels, this adds a simple helper to see if a connector > is manually updated. Tested-by: Tony Lindgren &l

Re: [PATCHv2 1/8] drm/omap: add framedone interrupt support

* Sebastian Reichel <sebastian.reic...@collabora.co.uk> [180208 18:31]: > This prepares framedone interrupt handling for > manual display update support. > > Signed-off-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk> Tested-by: Tony Li

Re: [PATCHv2 0/8] omapdrm: DSI command mode panel support

Tomi, * Sebastian Reichel [180208 10:31]: > Hi, > > These are the remaining patches from my previous patchset to get > Droid 4 (omap4) display working. The patches have been rebased to > current master branch from Torvalds (581e400ff935). Since N950 > (omap3)

Re: [PATCHv2 3/8] drm/omap: add support for manually updated displays

full refresh. Display > will be refreshed when something calls the dirty > callback, such as libdrm's drmModeDirtyFB(). > > This is currently being implemented for the kernel > console and for Xorg. Weston currently does not > implement this and is known not to work on manually > upda

Re: [PATCHv2 0/8] omapdrm: DSI command mode panel support

ting driver > * No updates send when nothing needs to be sent > * Orientation DRM property is attached to the DSI panel Great, still works for me :) Seems like the dts change is safe to merge along with the driver changes once no more comments. For patches 1 - 7, please feel free

Re: [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

* Tomi Valkeinen <tomi.valkei...@ti.com> [171219 10:51]: > On 11/12/17 17:22, Tony Lindgren wrote: > > * H. Nikolaus Schaller <h...@goldelico.com> [171201 07:44]: > > > Official vendor string is now "tpo" and not "toppoly". > > > > &g

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

* Tomi Valkeinen [171201 02:03]: > On 01/12/17 11:48, H. Nikolaus Schaller wrote: > > > Just a note: there is no toppoly->tpo change for *this* panel and > > Pandora board. Just omapdss removal. > > > > The GTA04 needs a toppoly->tpo change but no omapdss, removal. > > >

Re: [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

* H. Nikolaus Schaller [171201 07:44]: > Official vendor string is now "tpo" and not "toppoly". > > Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1" > so that the driver understands both. Tomi, so what's the plan with the dependency patch, is that

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

* H. Nikolaus Schaller <h...@goldelico.com> [171128 18:35]: > Hi, > > > Am 28.11.2017 um 17:18 schrieb Tony Lindgren <t...@atomide.com>: > > > > * H. Nikolaus Schaller <h...@goldelico.com> [171128 16:17]: > >> Hi Tony, > >> > >

Re: [PATCH v3 0/4] Fixes for omapdrm on OpenPandora and GTA04

* Tomi Valkeinen [171130 10:56]: > On 28/11/17 17:48, H. Nikolaus Schaller wrote: > > Changes V3: > > * stay compatible with old DTB files which still use "toppoly" (suggested > > by Tomi Valkeinen) > > * replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE (suggested by

Re: [PATCH v3 3/4] DTS: GTA04: fix panel compatibility string

* H. Nikolaus Schaller [171128 15:52]: > Official vendor string is now "tpo" and not "toppoly". > > Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1" This is not a fix then, this is a clean up as you change the compatible earlier. Please resend

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

* H. Nikolaus Schaller <h...@goldelico.com> [171128 16:17]: > Hi Tony, > > > Am 28.11.2017 um 17:04 schrieb Tony Lindgren <t...@atomide.com>: > > > > * H. Nikolaus Schaller <h...@goldelico.com> [171128 15:52]: > >> We can remove the unnecessar

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

* H. Nikolaus Schaller [171128 15:52]: > We can remove the unnecessary "omapdss," prefix because > the omapdrm driver takes care of it when matching with > the driver table. So is this needed as a fix or is this another clean-up? So is this is really needed as a fix? If

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

* H. Nikolaus Schaller <h...@goldelico.com> [171128 15:51]: > > Am 28.11.2017 um 16:10 schrieb Tony Lindgren <t...@atomide.com>: > > OK fine dropping both. Please update the description in both dts > > patches to make it clear they are needed as a fix. Preferrab

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

* H. Nikolaus Schaller [171116 08:53]: > Vendor string is "tpo" and not "toppoly". > > Signed-off-by: H. Nikolaus Schaller > --- > arch/arm/boot/dts/omap3-gta04.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

* H. Nikolaus Schaller <h...@goldelico.com> [171128 15:04]: > Hi Tony, > > > Am 28.11.2017 um 15:57 schrieb Tony Lindgren <t...@atomide.com>: > > > > * H. Nikolaus Schaller <h...@goldelico.com> [171116 08:53]: > >> Vendor string is "tpo&q

Regression in Linux next-20171113 with fbdev timer conversion

Hi, Looks like next-20171113 now has a NULL pointe dereference with commit 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()"). See the error below, any ideas? Regards, Tony 8< -- Unable to handle kernel NULL pointer dereference at virtual address 0214 pgd =

Re: Regression in Linux next-20171113 with fbdev timer conversion

* Bartlomiej Zolnierkiewicz <b.zolnier...@samsung.com> [171113 17:26]: > > On Monday, November 13, 2017 09:07:14 AM Tony Lindgren wrote: > > Hi, > > Hi Tony, > > > Looks like next-20171113 now has a NULL pointe dereference with commit > > 6c78935777d

Re: No /dev/fb0 created for omapdrm in current Linux next

* Tomi Valkeinen <tomi.valkei...@ti.com> [171023 00:34]: > On 20/10/17 20:09, Tony Lindgren wrote: > > > # lsmod > > Module Size Used by > > omapdrm69632 0 > > drm_kms_helper163840 1 omapdrm > > cfbf

Re: No /dev/fb0 created for omapdrm in current Linux next

* Tomi Valkeinen <tomi.valkei...@ti.com> [171019 23:13]: > On 19/10/17 19:30, Tony Lindgren wrote: > > Hi Tomi, > > > > Looks like omapdrm won't show anything with current Linux next based > > on my test with 900: > > > > modprobe twl4030_key

<    1   2   3   4   >