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

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

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

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

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

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

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

[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

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

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

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

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

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

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

* 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

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

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

<    1   2   3   4