Re: [PATCH] omap2+: add drm device

* Rob Clark rob.cl...@linaro.org [120305 08:24]: From: Andy Gross andy.gr...@ti.com Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod. --- a/arch/arm/plat-omap/common.c +++

Re: [PATCH] omap2+: add drm device

* Gross, Andy andy.gr...@ti.com [120619 14:17]: Tony, Please queue this patch at your earliest convenience. We had some discussion on the splitting out of the DMM/Tiler driver from the omapdrm driver. There might be some interest in leveraging the Tiler for omapfb. However, we agreed

[PATCH v4 5/8] ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC node

* Jyri Sarha [160915 02:44]: > Tony, > The functional changes are now merged. But let's not merge this bbb dts > patch just yet, so we do not cause a conflict with the other bbb hdmi > audio dts change[1] that slipped into tda998x pull request. The patch > can very well wait until v4.10 if

[PATCH 0/3] ARM: dts: am335x-* Add blue-and-red-wiring propery to lcdc nodes

* Jyri Sarha [160916 04:50]: > These patches complete the am335x LCDC color errata fix[1]. The > functional patches are now queued for v4.9. > > The patch for am335x-boneblack.dts is delayed until v4.10 or v4.9-rc > phase to avoid conflickt with BBB HDMI audio DTS patch that slipped > into

[PATCH 0/3] ARM: dts: am335x-* Add blue-and-red-wiring propery to lcdc nodes

* Jyri Sarha [160919 00:31]: > On 09/16/16 18:02, Tony Lindgren wrote: > > * Jyri Sarha [160916 04:50]: > >> > These patches complete the am335x LCDC color errata fix[1]. The > >> > functional patches are now queued for v4.9. > >> > > >>

[PATCH] ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC node

* Jyri Sarha [161117 12:14]: > Add blue-and-red-wiring -property to LCDC node. Also adds comments on > how to get support 24 bit RGB mode. After this patch am335x-boneblack > support RGB565, BGR888, and XBGR color formats. See details in >

[PATCH v2 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

* Tomi Valkeinen [160602 05:28]: > > Tony, can you have a look at the arch/arm parts here and give your ack > if they're fine? They should be quite small and display specific, so I > don't see much chance for conflict there. Looks good to me, but these are going to conflict with the board-*.c

[PATCH v2 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

* Tomi Valkeinen [160603 03:53]: > > > On 02/06/16 18:23, Tony Lindgren wrote: > > * Tomi Valkeinen [160602 05:28]: > >> > >> Tony, can you have a look at the arch/arm parts here and give your ack > >> if they're fine? They should be quite small and

[PATCH v3 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

* Peter Ujfalusi [160603 06:10]: > On 06/03/16 14:03, Peter Ujfalusi wrote: > > > > I have prepared two branches on top of v4.7-rc1: > > [1] https://github.com/omap-audio/linux-audio.git > > peter/for-4.8_omapdss_part1 > > > > containing: > > ARM: OMAP: rx51-video: Do not set TV

[GIT PULL] foundation for omapdrm header clean-up series for 4.8

* Peter Ujfalusi [160607 06:41]: > Hi Tony, Tomi > > as you have requested I have created the immutable branch containing the > mach-omap2 touching patches only from the omapdss header cleanup. > > As I have mentioned in the v3 cover letter I have the other branch > containing the whole series:

[PATCH 02/23] ARM: dts: n950: add display support

* Tony Lindgren [160412 13:53]: > * Sebastian Reichel [160324 17:16]: > > On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote: > > > > I _think_, that your HW team decided to cover the first and the > > > > last few pixels of the 864 display with pla

[PATCH v3 0/8] drm/tilcdc: Address LCDC rev 2 color errata + other fixes

* Jyri Sarha [160831 06:19]: > ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC > node > ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node > ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes > ARM: dts: am335x-evmsk: Add

[PATCH v3 0/8] drm/tilcdc: Address LCDC rev 2 color errata + other fixes

* Jyri Sarha [160831 11:49]: > On 08/31/16 21:04, Tony Lindgren wrote: > > * Jyri Sarha [160831 06:19]: > >> ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC > >> node > >> ARM: dts: am335x-evm: Add blue-and-red-wiring -property

[PATCH/RFC 0/7] Remove the omapdrm device from platform code

* Laurent Pinchart [161213 15:38]: > The series will be annoying to merge given how interleaved the ARM and driver > patches are. The easiest solution would be to merge everything through the ARM > tree (as the risk of conflict on the DRM side is low), in which case some > patches could be

OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

Hi, * Dan Carpenter [151223 23:29]: > [ It's weird that I'm just now getting this warning from 2014... Oh > well, looks legit. -dan ] Sorry for the delay on this one, got distracted few times with other bugs to deal with. This seems like a valid warning yeah. Tomi, do we really need two

OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

* Tomi Valkeinen [160113 23:45]: > On 14/01/16 01:22, Tony Lindgren wrote: > > Tomi, do we really need two copies of the the same panels > > files in kernel? > > > > For example: > > > > $ find . -name panel-sharp-ls037v7dw01.c > > ./drivers/gpu/d

[PATCH v2 5/8] ARM: dts: am33xx: Add external clock provider

* Jyri Sarha [140818 14:49]: > Add external clock provider for am33xx devices. Please send all the .dts and defconfig changes separately so I can pick them up and we don't get pointless merge conflicts. Regards, TOny > Signed-off-by: Jyri Sarha > --- > arch/arm/boot/dts/am33xx.dtsi | 10

[PATCH] omap2+: add drm device

* Rob Clark [120305 08:24]: > From: Andy Gross > > Register OMAP DRM/KMS platform device, and reserve a CMA region for > the device to use for buffer allocation. DMM is split into a > separate device using hwmod. > --- a/arch/arm/plat-omap/common.c > +++ b/arch/arm/plat-omap/common.c > @@

[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

* Jyri Sarha [150306 07:37]: > Use new binding for the external tda19988 HDMI encoder. Can this be merged separately after the driver code is merged with things still working? Otherwise we can have glitches with the output working and have dependencies between kernel branches. Regards, Tony

[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

* Jyri Sarha [150306 07:57]: > On 03/06/15 17:36, Tony Lindgren wrote: > >* Jyri Sarha [150306 07:37]: > >>Use new binding for the external tda19988 HDMI encoder. > > > >Can this be merged separately after the driver code is > >merged with things st

[PATCH 02/23] ARM: dts: n950: add display support

* Sebastian Reichel [160324 17:16]: > On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote: > > > I _think_, that your HW team decided to cover the first and the > > > last few pixels of the 864 display with plastic. So technically > > > it's a 864 display, but effectively it's 854.

[PATCH v5 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

* Jyri Sarha [150508 04:29]: > Use new binding for the external tda19988 HDMI encoder. Applying this into omap-for-v4.3/dt thanks. Tony

[PATCH] omap2+: add drm device

* Gross, Andy [120619 14:17]: > Tony, > > Please queue this patch at your earliest convenience. > > We had some discussion on the splitting out of the DMM/Tiler driver > from the omapdrm driver. There might be some interest in leveraging > the Tiler for omapfb. However, we agreed this can be

[PATCH] drm: omapdrm: Fix oops on rmmod

[] (platform_unregister_drivers+0x24/0x30) [] (platform_unregister_drivers) from [] (SyS_delete_module+0x150/0x218) [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x1c) Fix the issue by checking get_vblank_counter() before trying to call it. Signed-off-by: Tony Lindgren <t...@atomide.

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

* Sebastian Reichel [170304 16:45]: > Add basic panel support for the Nokia N950. It must be tweaked a > little bit later, since the panel was built into the device > upside-down. Also the first 5 and the last 5 pixels are covered > by plastic. This one seems safe to apply

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

* Tomi Valkeinen <tomi.valkei...@ti.com> [170324 08:01]: > On 24/03/17 16:29, Tony Lindgren wrote: > > * Sebastian Reichel <s...@kernel.org> [170304 16:45]: > >> Add basic panel support for the Nokia N950. It must be tweaked a > >> little bit later, si

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

* Tomi Valkeinen <tomi.valkei...@ti.com> [170324 08:22]: > On 24/03/17 17:12, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkei...@ti.com> [170324 08:01]: > >> On 24/03/17 16:29, Tony Lindgren wrote: > >>> * Sebastian Reichel <s...@kernel.org>

Re: [PATCHv2 03/10] Revert "drm: omapdrm: Remove manual update display support"

* Tomi Valkeinen <tomi.valkei...@ti.com> [170320 09:38]: > On 20/03/17 18:14, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkei...@ti.com> [170320 04:10]: > >> On 05/03/17 02:43, Sebastian Reichel wrote: > >>> This reverts commit 5a35876e2830511cb8

Re: [PATCHv2 03/10] Revert "drm: omapdrm: Remove manual update display support"

* Tomi Valkeinen [170320 04:10]: > On 05/03/17 02:43, Sebastian Reichel wrote: > > This reverts commit 5a35876e2830511cb8110667fc426c6a6165a593. > > > > Revert the removal of manual update display support in > > preparation for DSI command mode panels. > > I think it's

Re: drm_modeset_lock oops in next

* Maarten Lankhorst <maarten.lankho...@linux.intel.com> [170408 01:55]: > Hey, > > Op 07-04-17 om 17:56 schreef Tony Lindgren: > > Hi, > > > > Looks like current next now oopses at least for omapdrm > > when starting X. Reverting commit d20afeb3e2f9 (&quo

Re: [PATCHv2 04/10] drm: omapdrm: crtc: save framedone callback from dss

* Sebastian Reichel <s...@kernel.org> [170304 16:45]: > Save the framedone callback supplied by dss for later > usage. > > Signed-off-by: Sebastian Reichel <s...@kernel.org> Tested-by: Tony Lindgren <t...@atomide.com>

Re: [PATCHv2 02/10] drm: omapdrm: panel-dsi-cm: add regulator support

* Sebastian Reichel <s...@kernel.org> [170304 16:45]: > The N950's display requires two regulators. Also needed for droid 4: Tested-by: Tony Lindgren <t...@atomide.com> ___ dri-devel mailing list dri-devel@lists.freede

Re: [PATCHv2 05/10] drm: omapdrm: crtc: detect manually updated displays

* Sebastian Reichel <s...@kernel.org> [170304 16:45]: > Signed-off-by: Sebastian Reichel <s...@kernel.org> > [t...@atomide.com: rebased on event_lock changes] So for this feel free to add: Tested-by: Tony Lindgren <t...@atomide.com> Signed-off-by: Tony Li

Re: [PATCHv2 09/10] drm: omapdrm: crtc: get manual mode displays working

* Sebastian Reichel <s...@kernel.org> [170304 16:45]: > From: Tony Lindgren <t...@atomide.com> > > With manual mode displays we need to flush the panel manually. > > Let's add flushing so we get Tomi's fbtest, kmstest, kmstest --flip, > and X and wayland working. &

drm_modeset_lock oops in next

Hi, Looks like current next now oopses at least for omapdrm when starting X. Reverting commit d20afeb3e2f9 ("Merge remote-tracking branch 'drm-misc/for-linux-next'") makes things work again. Any ideas what might be causing the oops below? Regards, Tony 8< -- Internal

Re: [PATCH] drm: Only take cursor locks when the cursor plane exists

* Daniel Vetter <daniel.vet...@ffwll.ch> [170407 09:50]: > I thought I've fixed this, but maybe not. Anyway, clearly broken, and > easy fix. > > Cc: Tony Lindgren <t...@atomide.com> > Reported-by: Tony Lindgren <t...@atomide.com> > Fixes: b95ff0319a82 (&q

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

* Jyri Sarha [170627 02:47]: > There is no real volume on HDMI audio output as it is a digital > interface, but it should be possible to provide some volume control > using TV's volume trough CEC. OK great! Tony ___ dri-devel mailing

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

* Hans Verkuil <hverk...@xs4all.nl> [170627 01:39]: > On 26/06/17 13:07, Tony Lindgren wrote: > > Tomi, > > > > * Tomi Valkeinen <tomi.valkei...@ti.com> [170428 04:15]: > >> On 14/04/17 13:25, Hans Verkuil wrote: > >>> From: Hans Verkuil <h

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

* Hans Verkuil <hverk...@xs4all.nl> [170627 02:27]: > On 27/06/17 11:14, Tony Lindgren wrote: > > Adding Jyri to Cc, hopefully the CEC support allows also setting the > > HDMI audio volume level on devices implementing it? Or am I too > > optimistic? :) > > I'm

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

* Aaro Koskinen [170629 11:50]: > Is it just me or do other OMAP users fail to see omapdrm changes being > posted to linux-omap for testing or review purposes? Yeah Cc:ing linux-omap in addition to the drm list is a good idea. Hopefully we get few more people to review

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

* Sebastian Reichel <s...@kernel.org> [170428 11:29]: > Hi, > > On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkei...@ti.com> [170428 04:15]: > > > On 14/04/17 13:25, Hans Verkuil wrote: > > >

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

* Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > Change to PIN_INPUT so it can be used by the new CEC support. ... >

Re: [PATCH v3 01/35] ARM: OMAP2+: Register SoC device attributes from machine .init()

(void) > > static void __init __maybe_unused omap_common_late_init(void) > > { > > omap2_common_pm_late_init(); > > - omap_soc_device_init(); > > } > > > > #ifdef CONFIG_SOC_OMAP2420 > > > > Tony, how does this look? C

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

display support, > but I started from scratch without reverting the > removal of manual display update support. Works for me: Tested-by: Tony Lindgren <t...@atomide.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen <tomi.valkei...@ti.com> [170511 01:37]: > On 10/05/17 21:29, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkei...@ti.com> [170510 10:44]: > >> > >> > >> On 10/05/17 19:46, Tony Lindgren wrote: > >>> * Tomi Valkeine

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen <tomi.valkei...@ti.com> [170510 10:44]: > > > On 10/05/17 19:46, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkei...@ti.com> [170510 00:26]: > >> On 09/05/17 18:05, Sebastian Reichel wrote: > >> > >>> patch 10:

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen [170510 00:26]: > On 09/05/17 18:05, Sebastian Reichel wrote: > > > patch 10: > > I think dsi pin muxing should be done by providing pinmux > > info via DT. > > Unfortunately there's no pinmux driver for the kind of register we have > for DSI. At least

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen <tomi.valkei...@ti.com> [170509 04:56]: > On 08/05/17 20:07, Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinch...@ideasonboard.com> [170508 04:36]: > >> The next step is to remove the omapdss platform driver (for the virtual > >&

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Tomi Valkeinen <tomi.valkei...@ti.com> [170512 00:32]: > On 11/05/17 17:16, Tony Lindgren wrote: > > >> pinctrl-single doesn't allow to freely set the bits, but requires the > >> pins to have similar bit structure (function-mask). In CONTROL_DSIPHY, > &g

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

Tomi, * Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil > > > > The CEC pin was always pulled up, making it impossible to use it. ... > Tony, can you queue this? It's safe to apply separately from

Re: [PATCH 0/3] drm/omap: misc fixes

* Tomi Valkeinen [170613 02:06]: > Hi, > > Here's three fixes for omapdrm: > > - fix synclost flood on omap3 > - fix analog tv-out videomode check > - fix DSI PLL setup > > Tony, Aaro, Nikolaus, can you see if these fix the issues you're seeing? Seems to get rid of the

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

* Tony Lindgren <t...@atomide.com> [170428 11:57]: > The pull seems to be enabled in the Android kernel too: > > # rwmem -s16 0x4a10009a > 0x4a10009a = 0x0118 > > So needs to be tested, what's the simplest test to check the CEC? So on droid 4, with the internal pull

Re: [PATCH v2 26/28] ARM: OMAP2+: Remove unused omapdrm platform device

OK to merge via the drm patches as long as things have been properly tested to not cause regressions: Acked-by: Tony Lindgren <t...@atomide.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform code

* Laurent Pinchart [170508 04:36]: > The next step is to remove the omapdss platform driver (for the virtual > omapdss platform device, also known as core code, not to be confused with the > omapdss_dss driver for the DSS hardware device). Patches 21/28 to 23/28

Re: [PATCH v2 27/28] ARM: OMAP2+: Don't register omapdss device for omapdrm

er. > > Signed-off-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> This too: Acked-by: Tony Lindgren <t...@atomide.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_kms_helper cycle detected build error in next

* Tony Lindgren <t...@atomide.com> [171013 07:59]: > Hi Tomi, > > Looks like today's next build fails if omapdrm is enabled as modules > with: > > depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper > depmod: ERROR: Found 2 modules in depende

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

* Tomi Valkeinen [171012 01:46]: > On 29/09/17 16:26, Sebastian Reichel wrote: > > Hi Tomi & Laurent, > > > > ping? > > I've been having quick glances at this every now and then, but I'm not > sure what to do with the series. > > We have one work item that more or less

Re: drm_kms_helper cycle detected build error in next

0 Helsinki. > > > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > > > > > On 13/10/17 18:09, Tony Lindgren wrote: > > > > > >>> Looks like today's next build fails if omapdrm is enabled as modules > > >>> with: >

Re: drm_kms_helper cycle detected build error in next

* Daniel Vetter <dan...@ffwll.ch> [171017 05:09]: > On Mon, Oct 16, 2017 at 07:35:24AM -0700, Tony Lindgren wrote: > > > > Meanwhile, can you guys provide few more clues which patch to pick > > for the rest of us? > > > > Something like patch subject l

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

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 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 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

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 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 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 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

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: [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: 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

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: 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

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

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

Hi Tomi, Looks like omapdrm won't show anything with current Linux next based on my test with 900: modprobe twl4030_keypad modprobe tsc2005 modprobe omapdss modprobe panel_sony_acx565akm modprobe omapdrm echo 255 > /sys/class/backlight/acx565akm/brightness echo 0 > /sys/class/graphics/fb0/blank

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: [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: [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: 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: 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: [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: [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: [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: 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 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 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 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: 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: 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

* 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

* 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: [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

[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

  1   2   3   4   >