* 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 has
* 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
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 2).
* 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 :
> >
* 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>;
>
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 =
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
...
> > + default-brightnes
* 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 i
* 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_
* 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
> >
* 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 *
* 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:
> >
* 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...
>
> Yes
* 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
__
* 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 c
* 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:
> +- co
* 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 cor
* 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
* 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
> Ack
* 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 at
* 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 least
* 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 :) I
* 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
* 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
ey nice 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.f
* 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' resolu
* 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
* 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.
> >
* 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
* 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 b
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
* 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 for
ied in the lm3532 tread. 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
Suggested-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 hd
* 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
* 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
> >>
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
Suggested-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/g
* 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 move hdmi
* 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
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 b
t;
> I guess the 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
* 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 nobod
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 b
* 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 =
* 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 (
* 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
* 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 disconnect_lan
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().
flag 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 ch
* 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
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
e function 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
__
bug) 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
* 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.
>
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/dr
* 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
* 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 ne
_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
ap: dss: Acquire 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
* 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 pa
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 at
* 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 cont
* 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
>
* 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 loading
* 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
> >
* 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):
> >
* 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 have
* 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 your
* 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
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
* 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
* 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
> o
* 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
> b/a
* 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
> >&
* Tomi Valkeinen [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"). Reverting
> >
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
dri-
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) single buffering,
> > where the userspace must se
* Daniel Stone [180420 14:41]:
> Hi Tony!
>
> On 20 April 2018 at 15:25, Tony Lindgren wrote:
> > * Daniel Stone [180420 10:21]:
> >> On 20 April 2018 at 08:09, Tomi Valkeinen wrote:
> >> > It's actually not quite clear to me how manual update displays
* 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 quality, as I have not had ti
* Sebastian Reichel [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
___
dri-devel mai
* Sebastian Reichel [180208 18:31]:
> This prepares framedone interrupt handling for
> manual display update support.
>
> Signed-off-by: Sebastian Reichel
Tested-by: Tony Lindgren
___
dri-devel mailing list
dri-devel@lists.freedeskt
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) is broken even with the workaround I
ng 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
> up
hing 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 to add:
Tested-by: Tony Lindgren
* Tomi Valkeinen [171219 10:51]:
> On 11/12/17 17:22, Tony Lindgren wrote:
> > * H. Nikolaus Schaller [171201 07:44]:
> > > Official vendor string is now "tpo" and not "toppoly".
> > >
> > > Requires patch "omapdrm: panel: fix comp
* 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.
> >
> > So they solve differe
* 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 for v4.16
or for the
* H. Nikolaus Schaller [171128 18:35]:
> Hi,
>
> > Am 28.11.2017 um 17:18 schrieb Tony Lindgren :
> >
> > * H. Nikolaus Schaller [171128 16:17]:
> >> Hi Tony,
> >>
> >>> Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
> >>>
* 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 Andrew
> > F. Davis)
> >
* 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 this separately once the
* H. Nikolaus Schaller [171128 16:17]:
> Hi Tony,
>
> > Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
> >
> > * H. Nikolaus Schaller [171128 15:52]:
> >> We can remove the unnecessary "omapdss," prefix because
> >> the omapdrm driver takes
* 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 this is just clean-up, a
* H. Nikolaus Schaller [171128 15:51]:
> > Am 28.11.2017 um 16:10 schrieb Tony Lindgren :
> > OK fine dropping both. Please update the description in both dts
> > patches to make it clear they are needed as a fix. Preferrably
> > with a proper fixes tag.
>
> Well,
* 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 a/arch/arm/boot/dts/omap3-gta04.dtsi
> b/arch/arm/boot/d
* H. Nikolaus Schaller [171128 15:04]:
> Hi Tony,
>
> > Am 28.11.2017 um 15:57 schrieb Tony Lindgren :
> >
> > * H. Nikolaus Schaller [171116 08:53]:
> >> Vendor string is "tpo" and not "toppoly".
> >>
> >> Signed-off-by:
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 =
* Bartlomiej Zolnierkiewicz [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
> > 6c78935777d1 ("video: fbdev: Convert timer
* Tomi Valkeinen [171023 00:34]:
> On 20/10/17 20:09, Tony Lindgren wrote:
>
> > # lsmod
> > Module Size Used by
> > omapdrm69632 0
> > drm_kms_helper163840 1 omapdrm
> > cfbfillrect16384 1 drm_kms_hel
* Tomi Valkeinen [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_keypad
> >
201 - 300 of 360 matches
Mail list logo