[Bug 59332] Problems building 32bit Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=59332 Matt Turner changed: What|Removed |Added Assignee|idr at freedesktop.org |dri-devel at lists.freedesktop ||.org CC||tstellar at gmail.com Component|glsl-compiler |Drivers/Gallium/r600 --- Comment #5 from Matt Turner --- (In reply to comment #3) > I notice in the glsl directory the Makefile has CFLAGS and CFLAGS_FOR_BUILD > and the same for CXX too the FOR_BUILD ones don't have -m32 and I think > could be causing some of the issues I'm seeing Actually, that doesn't seem related. Looks like this is yet another problem with 32-bit LLVM. I wonder if Tom's seen this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/03d675f2/attachment.html>
BUG: circular locking dependency detected
On Wed, Jan 30, 2013 at 11:19 PM, Russell King wrote: > So... what you seem to be telling me is that 3.9 is going to be a > release which issues lockdep complaints when the console blanks, and > you think that's acceptable? > > Adding Linus and Andrew so they're aware of this issue... Linus was the guy who shot down the patches for 3.9 since one of the earlier iterations caused instant deadlocks - I've been pushing them to merge them ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
BUG: circular locking dependency detected
On Wed, Jan 30, 2013 at 10:52 PM, Russell King wrote: > Also adding Greg and Daniel to this as Daniel introduced the lockdep > checking. > > This looks extremely horrid to be to solve - the paths are rather deep > where the dependency occurs. The two paths between the locks are: > > console_lock+0x5c/0x70 > register_con_driver+0x44/0x150 > take_over_console+0x24/0x3b4 > fbcon_takeover+0x70/0xd4 > fbcon_event_notify+0x7c8/0x818 > notifier_call_chain+0x4c/0x8c > __blocking_notifier_call_chain+0x50/0x68 > blocking_notifier_call_chain+0x20/0x28 > > and > > __blocking_notifier_call_chain+0x34/0x68 > blocking_notifier_call_chain+0x20/0x28 > fb_notifier_call_chain+0x20/0x28 > fb_blank+0x40/0xac > fbcon_blank+0x1f4/0x29c > do_blank_screen+0x1b8/0x270 > console_callback+0x74/0x138 You want Dave Airlie's pile of locking reworks, which fixes all currently known offenders around console_lock and fb_notifier. Patches won't go into 3.9 since it took a few rounds until they did not cause regression by making these deadlocks easier to hit. http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes Long term solution would be to abolish the fb_notifier, at least for the purpose of linking fbdevs up with the fbcon and just replace those with direct function calls. But that requires that we no longer allow fbdev drivers and the fbcon to be loaded in any arbitrary order. Or just force fbcon to be built-in if enabled, imo the sane choice (no one's bothering with config_vt=m either, after all). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/2] [media] s5p-g2d: Add DT based discovery support
Hi Sachin, On 01/25/2013 10:55 AM, Sachin Kamat wrote: > This patch adds device tree based discovery support to G2D driver > > Signed-off-by: Sachin Kamat > --- > drivers/media/platform/s5p-g2d/g2d.c | 17 - > 1 files changed, 16 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/platform/s5p-g2d/g2d.c > b/drivers/media/platform/s5p-g2d/g2d.c > index 7e41529..210e142 100644 > --- a/drivers/media/platform/s5p-g2d/g2d.c > +++ b/drivers/media/platform/s5p-g2d/g2d.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -796,7 +797,8 @@ static int g2d_probe(struct platform_device *pdev) > } > > def_frame.stride = (def_frame.width * def_frame.fmt->depth)>> 3; > - dev->variant = g2d_get_drv_data(pdev); > + if (!pdev->dev.of_node) > + dev->variant = g2d_get_drv_data(pdev); Don' you need something like: else { of_id = of_match_node(exynos_g2d_match, pdev->dev.of_node); if (!of_id) return -ENODEV; dev->variant = (struct g2d_variant *)of_id->data; } ? Otherwise dev->variant is left uninitialized...? > return 0; > > @@ -844,6 +846,18 @@ static struct g2d_variant g2d_drvdata_v4x = { > .hw_rev = TYPE_G2D_4X, /* Revision 4.1 for Exynos4X12 and Exynos5 */ > }; > > +static const struct of_device_id exynos_g2d_match[] = { > + { > + .compatible = "samsung,g2d-v3", > + .data =_drvdata_v3x, > + }, { > + .compatible = "samsung,g2d-v41", > + .data =_drvdata_v4x, Didn't you consider adding "exynos" to these compatible strings ? I'm afraid g2d may be too generic. > + }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, exynos_g2d_match); > + > static struct platform_device_id g2d_driver_ids[] = { > { > .name = "s5p-g2d", > @@ -863,6 +877,7 @@ static struct platform_driver g2d_pdrv = { > .driver = { > .name = G2D_NAME, > .owner = THIS_MODULE, > + .of_match_table = of_match_ptr(exynos_g2d_match), of_match_ptr() could be dropped, since exynos_g2d_match[] is always compiled in. -- Thanks, Sylwester
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #11 from Alex Deucher --- this looks like it may be a duplicate of bug 59431. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/2729326f/attachment.html>
BUG: circular locking dependency detected
On Wed, Jan 30, 2013 at 11:07:16PM +0100, Daniel Vetter wrote: > On Wed, Jan 30, 2013 at 10:52 PM, Russell King > wrote: > > Also adding Greg and Daniel to this as Daniel introduced the lockdep > > checking. > > > > This looks extremely horrid to be to solve - the paths are rather deep > > where the dependency occurs. The two paths between the locks are: > > > > console_lock+0x5c/0x70 > > register_con_driver+0x44/0x150 > > take_over_console+0x24/0x3b4 > > fbcon_takeover+0x70/0xd4 > > fbcon_event_notify+0x7c8/0x818 > > notifier_call_chain+0x4c/0x8c > > __blocking_notifier_call_chain+0x50/0x68 > > blocking_notifier_call_chain+0x20/0x28 > > > > and > > > > __blocking_notifier_call_chain+0x34/0x68 > > blocking_notifier_call_chain+0x20/0x28 > > fb_notifier_call_chain+0x20/0x28 > > fb_blank+0x40/0xac > > fbcon_blank+0x1f4/0x29c > > do_blank_screen+0x1b8/0x270 > > console_callback+0x74/0x138 > > You want Dave Airlie's pile of locking reworks, which fixes all > currently known offenders around console_lock and fb_notifier. Patches > won't go into 3.9 since it took a few rounds until they did not cause > regression by making these deadlocks easier to hit. > > http://cgit.freedesktop.org/~airlied/linux/log/?h=fbcon-locking-fixes > > Long term solution would be to abolish the fb_notifier, at least for > the purpose of linking fbdevs up with the fbcon and just replace those > with direct function calls. But that requires that we no longer allow > fbdev drivers and the fbcon to be loaded in any arbitrary order. Or > just force fbcon to be built-in if enabled, imo the sane choice (no > one's bothering with config_vt=m either, after all). So... what you seem to be telling me is that 3.9 is going to be a release which issues lockdep complaints when the console blanks, and you think that's acceptable? Adding Linus and Andrew so they're aware of this issue... -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
[Bug 57567] 3.7 radeonfb broken on efivga screens
https://bugs.freedesktop.org/show_bug.cgi?id=57567 --- Comment #10 from Vladimir --- Some news which makes it easier to isolate the bug ubuntu updated kernel to 3.5.0-22 and bug appeared on this kernel 3.5.0-21 - no bug looks like they added some upstream changes. here is list of changes 21 to 22 from their deb pkg for kernel - http://pastebin.com/4uUWUtLV -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/64334f67/attachment.html>
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 01/30/2013 09:50 AM, Inki Dae wrote: >> +static const struct of_device_id exynos_g2d_match[] = { >> + { .compatible = "samsung,g2d-v41" }, > > not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d > driver shoud support for all Exynos SoCs. How about using > "samsung,exynos5-g2d" instead and adding a new property 'version' to > identify ip version more surely? With this, we could know which SoC > and its g2d ip version. The version property could have '0x14' or > others. And please add descriptions to dt document. Err no. Are you suggesting using "samsung,exynos5-g2d" compatible string for Exynos4 specific IPs ? This would not be correct, and you still can match the driver with multiple different revisions of the IP and associate any required driver's private data with each corresponding compatible property. Perhaps it would make more sense to include the SoCs name in the compatible string, e.g. "samsung,exynos-g2d-v41", but appending revision of the IP seems acceptable to me. The revisions appear to be well documented and it's more or less clear which one corresponds to which SoC. -- Thanks, Sylwester
[PATCH v2] drm/exynos: Get HDMI version from device tree
On 01/30/2013 06:16 PM, Inki Dae wrote: > 2013/1/30 Sylwester Nawrocki : >> Hi, >> >> >> On 01/08/2013 11:56 PM, Stephen Warren wrote: >>> >>> On 01/08/2013 01:16 PM, Sean Paul wrote: Add a property to the hdmi node so we can specify the HDMI version in the device tree instead of just defaulting to v1.4 with the existence of the dt node. >>> >>> >>> I guess this seems OK to me if required, although I'd certainly like to >>> see someone familiar with the Exynos HW confirm whether this should be >>> driven purely by DT compatible value for the HDMI IP block instead though. >> >> >> I think the supported HDMI standard is something that could well be derived >> from the compatible property. The IP supporting v1.3 and v1.4 will be >> significantly different, so this would anyway already need to be reflected >> in the compatible property. The only issue I see here is that people tend >> to make the compatible string overly generic, so it is hardly usable for >> anything but matching an IP with its driver. For instance for exynos5 we >> have now (Documentation/devicetree/bindings/drm/exynos/hdmi.txt): >> >> compatible = "samsung,exynos5-hdmi"; >> >> For Exynos4 series there were already some patches proposed [1], but I >> believe >> this isn't a clean solution. Instead of things like: >> >> compatible = "samsung,exynos4-hdmi13"; >> compatible = "samsung,exynos4-hdmi14"; >> >> I would much more like to see the SoC version embedded in the compatible >> string, e.g. >> > > Hi Sylwester. long time no see. > > I think that if we use the SoC version embedded in the compatible > string then each driver shoud aware of the ip version to the SoC to The driver only needs to be aware of one SoC version for each IP version. So with Sylwester's proposal: >> compatible = "samsung,exynos4210-hdmi"; /* among others it carries an >> information this IP supports >> HDMI v1.3 */ >> >> compatible = "samsung,exynos4212-hdmi"; /* HDMI v1.4, IIRC */ The driver woulud only ever have to know about those two compatible values (unless further incompatible HW revisions exist); any other SoC would be listed as being compatible with one of those two strings (but in addition to the specific value for the specific SoC, e.g. compatible = "samsung,exynox5xxx-hdmi", "samsung,exynos4212-hdmi"). > use version specific feature so I think it's better to use it without > the SoC version embedded in the compatible string like this, > compatible = "samsung,exynos4-hdmi" > version = "0x104" or "0x103" That would be quite non-typical. > With this, all each driver to do is to check version property and set > version specific feature properly. And we have some dtsi file to can > be used commonly. > > For example, > exynos4.dtsi : have all Exynos4 series SoCs common properties and also > use common compatible string. > exynos4412.dtsi, exynos4212.dtsi and so on: have Exynos42xx specific > properties. So the hdmi version string could be used here as "version > = "0x104" or "0x103" > exynos4412-board.dts: have board specific properties. > > compatible = "samsung,exynos5-hdmi" is reasonable to me. > any opinions?
[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 --- Comment #5 from Jerome Glisse --- Can you try dumping the bios when booting with kms disable and nothing bind to the gpu -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/53e63661/attachment.html>
[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2
https://bugs.freedesktop.org/show_bug.cgi?id=60034 --- Comment #5 from Andy Furniss --- (In reply to comment #4) > Please update mesa again a bunch of fixes were push. Make sure you have up > to : > e1598cb642334c809e6ec219d793e7bc85a213de I am still seeing it on current head. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/83702e18/attachment-0001.html>
[PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
2013/1/25 Sachin Kamat : > From: Ajay Kumar > > This patch adds device tree match table for Exynos G2D controller. > > Signed-off-by: Ajay Kumar > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 ++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > index ddcfb5d..d24b170 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev) > > static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume); > > +#ifdef CONFIG_OF > +static const struct of_device_id exynos_g2d_match[] = { > + { .compatible = "samsung,g2d-v41" }, not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d driver shoud support for all Exynos SoCs. How about using "samsung,exynos5-g2d" instead and adding a new property 'version' to identify ip version more surely? With this, we could know which SoC and its g2d ip version. The version property could have '0x14' or others. And please add descriptions to dt document. > + {}, > +}; > +MODULE_DEVICE_TABLE(of, exynos_g2d_match); > +#endif > + > struct platform_driver g2d_driver = { > .probe = g2d_probe, > .remove = g2d_remove, > @@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = { > .name = "s5p-g2d", > .owner = THIS_MODULE, > .pm = _pm_ops, > + .of_match_table = of_match_ptr(exynos_g2d_match), > }, > }; > -- > 1.7.4.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy
https://bugs.freedesktop.org/show_bug.cgi?id=59903 --- Comment #8 from Michel D?nzer --- (In reply to comment #6) > * with "echo 2 > /sys/module/drm/parameters/debug" nothing special in dmesg Hmm, so maybe the EBUSY error is coming from this code in drm_mode_page_flip_ioctl(): if (crtc->fb == NULL) { /* The framebuffer is currently unbound, presumably * due to a hotplug event, that userspace has not * yet discovered. */ ret = -EBUSY; goto out; } What does xrandr --current say when the problem occurs? After that, does running xrandr without arguments make any difference? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/60578c92/attachment.html>
[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2
https://bugs.freedesktop.org/show_bug.cgi?id=60034 --- Comment #4 from Jerome Glisse --- Please update mesa again a bunch of fixes were push. Make sure you have up to : e1598cb642334c809e6ec219d793e7bc85a213de -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/c19d35cb/attachment.html>
[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugzilla.kernel.org/show_bug.cgi?id=49981 J?r?me Glisse changed: What|Removed |Added CC||glisse at freedesktop.org --- Comment #6 from J?r?me Glisse 2013-01-30 17:22:36 --- It's not completely a kernel bug. It's userspace asking insane things to kernel. This mesa patch should avoid the issue most of the time : http://people.freedesktop.org/~glisse/0001-r600g-add-cs-memory-usage-accounting-and-limit-it.patch If you are using a recent mesa with gnome you will probably want this cogl patch too : http://people.freedesktop.org/~glisse/0001-glx-do-not-use-multisample-visual-config-for-front-o.patch And for kernel i am working on better handling of memory fragmentation. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[ANNOUNCE] xf86-video-ati 7.1.0
If I learned anything from the libdrm mess that was 2.4.41 (sorry about that!), it is that people check things like md5sums, imo which should really no longer be included in the release announcements. :-) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (5): bump verion post release radeon: add new SI pci id radeon: fix ring count in R300PrepareTexturedVideo exa/Xv: fix coordinate limits on AVIVO IGPs radeon/r200: program RE_WIDTH_HEIGHT properly Dave Airlie (1): radeon: fix damage reporting for slave pixmaps Ilija Hadzic (3): video: add option to include disabled CRTCs in best CRTC search DRI2: change signature of radeon_dri2_drawable_crtc DRI2: limit the swap rate when CRTC is in DPMS-off state Jerome Glisse (2): radeon: avoid segfault when pixmap exceed GPU capabilities radeon: avoid copying over itself ddx fb Maarten Lankhorst (1): radeon: bump version for release Michel D?nzer (11): Remove dead code flagged by gcc -Wunused-but-set-variable. Remove unused local variable 'path'. Remove local variables total_size_bytes. Remove dead option definitions. glamor: Release the drawable after passing to glamor_push_pixels glamor: Enable full 2D acceleration for SI as well. Drop support for X servers older than 1.7. DRI2: Properly use buffer depth passed in by client. DRI2/r[345]xx: 16 bit depth buffers use square micro tiling. Make CRTC shadow pixmaps usable by glamor. Make radeon_glamor_create_textured_pixmap() return TRUE without USE_GLAMOR. git tag: xf86-video-ati-7.1.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.bz2 MD5: a799371aa8a64ac8f9535963d5135e9a xf86-video-ati-7.1.0.tar.bz2 SHA1: f94730e5ffc5f75fa3126579bed0222fe8330653 xf86-video-ati-7.1.0.tar.bz2 SHA256: c8ae44051fcb331625217f98c09a3aa69f493052b69d62c03f41fed0bfe610cd xf86-video-ati-7.1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.gz MD5: 8a2694537b1fc6ff85b2aee1c00a0eb9 xf86-video-ati-7.1.0.tar.gz SHA1: 88b94a7503e813f8a12066dbda8d9642934f5a08 xf86-video-ati-7.1.0.tar.gz SHA256: 187230127739de179118e54205dd5c17fdb1e04cfbee1f9a63fde0030f39fcb0 xf86-video-ati-7.1.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRCUcZAAoJEP5VjHKmcBPDDVsP/RrdCI07QVxDANrNqKiUlScI B7kMYcB4phNn/SiFKElrxikpdrHddHtRdnXs4RzG+0gb6CVGDD48xY1MZNrJRBEY Lm+g1IKXU2w1LMqj9q3dMasNe73Msws5iRMy31n5NtVNNehcneibLR8Na7vkc30t bAsCP6Z0kOtrlxbVsEvUbQw4JIWQIBSzWflB1hqsWQKbLEGKC9TUKWNr+ZnoPBCm 5dPYSe/vrTeaC2RvdYGsyMLcyO4D2g67uvDmRvAlE9/VWj7eTLS8QAIy2kSliHbJ 7z2F+VDRjbBYGhIsa7neWzsdA85guSFhQj5+ToLcBNn9YXSxP7MWKJ0fPoaWPTxG wroTd14/HOCwH7a0w34SdHyB+kblTu9iOVi+DWsJ7YHs5yg/HGeB1c10OtejaZH5 cLiM4Wq1TNUuzX+DFq4JHdOwX9KM8pqyy7yPOvLOik1B7gbljmP6bJEv7NUnhNdT cY7WOgmvlNcbuY41YI6gY8XMjP4OyEC2cK+za6THEiLL+foj3CpdBcacnMopGTbs E4HgmzG+wXX1QBXe1y7iNz5B+y/dGNMJsM9yv2POoDZ2OTpnBczOmzGq2lJ7oxGA /6P66eiKt1NH4CGvojzqTbTc2gJ+KQtmSJtVt2+l+m/iwHInaGbgEtAbCDVK833Y R7KTbofGO9xkOAwBFRZr =AnY7 -END PGP SIGNATURE-
[RFC PATCH 4/4] video: display: Add Samsung s6e8ax0 display panel driver
This patch adds Common Display Framework driver for Samsung s6e8ax0 MIPI DSI display panel. Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park --- drivers/video/display/Kconfig |3 + drivers/video/display/Makefile|1 + drivers/video/display/panel-s6e8ax0.c | 1027 + include/video/panel-s6e8ax0.h | 41 ++ 4 files changed, 1072 insertions(+) create mode 100644 drivers/video/display/panel-s6e8ax0.c create mode 100644 include/video/panel-s6e8ax0.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index b14527a..f19ec04 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -5,6 +5,9 @@ menuconfig DISPLAY_CORE if DISPLAY_CORE +config DISPLAY_PANEL_S6E8AX0 + tristate "S6E8AX0 DSI video mode panel" + select OF_VIDEOMODE config DISPLAY_SOURCE_EXYNOS_DSI tristate "Samsung SoC MIPI DSI Master" diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 40a283a..0f7fdc2 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o +obj-$(CONFIG_DISPLAY_PANEL_S6E8AX0) += panel-s6e8ax0.o obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o diff --git a/drivers/video/display/panel-s6e8ax0.c b/drivers/video/display/panel-s6e8ax0.c new file mode 100644 index 000..4c09fe2 --- /dev/null +++ b/drivers/video/display/panel-s6e8ax0.c @@ -0,0 +1,1027 @@ +/* linux/drivers/video/exynos/s6e8ax0.c + * + * MIPI-DSI based s6e8ax0 AMOLED lcd 4.65 inch panel driver. + * + * Inki Dae, + * Donghwa Lee, + * Tomasz Figa, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define LDI_MTP_LENGTH 24 +#define DSIM_PM_STABLE_TIME10 +#define MIN_BRIGHTNESS 0 +#define MAX_BRIGHTNESS 24 +#define GAMMA_TABLE_COUNT 26 + +struct s6e8ax0 { + struct display_entity entity; + struct device *dev; + + struct s6e8ax0_platform_data *pdata; + struct backlight_device *bd; + struct lcd_device *ld; + struct regulator_bulk_data supplies[2]; + + bool enabled; + unsigned int id; + unsigned int gamma; + unsigned int acl_enable; + unsigned int cur_acl; + int power; + + unsigned int reset_gpio; +}; + +#define to_panel(p)container_of(p, struct s6e8ax0, entity) + +static const unsigned char s6e8ax0_22_gamma_30[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf, + 0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0, + 0x00, 0x61, 0x00, 0x5a, 0x00, 0x74, +}; + +static const unsigned char s6e8ax0_22_gamma_50[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xe8, 0x1f, 0xf7, 0xad, 0xc0, + 0xb5, 0xc4, 0xdc, 0xc4, 0x9e, 0xc6, 0x9c, 0xbb, 0xd8, 0xbb, + 0x00, 0x70, 0x00, 0x68, 0x00, 0x86, +}; + +static const unsigned char s6e8ax0_22_gamma_60[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xde, 0x1f, 0xef, 0xad, 0xc4, + 0xb3, 0xc3, 0xdd, 0xc4, 0x9e, 0xc6, 0x9c, 0xbc, 0xd6, 0xba, + 0x00, 0x75, 0x00, 0x6e, 0x00, 0x8d, +}; + +static const unsigned char s6e8ax0_22_gamma_70[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xd8, 0x1f, 0xe7, 0xaf, 0xc8, + 0xb4, 0xc4, 0xdd, 0xc3, 0x9d, 0xc6, 0x9c, 0xbb, 0xd6, 0xb9, + 0x00, 0x7a, 0x00, 0x72, 0x00, 0x93, +}; + +static const unsigned char s6e8ax0_22_gamma_80[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xc9, 0x1f, 0xde, 0xae, 0xc9, + 0xb1, 0xc3, 0xdd, 0xc2, 0x9d, 0xc5, 0x9b, 0xbc, 0xd6, 0xbb, + 0x00, 0x7f, 0x00, 0x77, 0x00, 0x99, +}; + +static const unsigned char s6e8ax0_22_gamma_90[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xc7, 0x1f, 0xd9, 0xb0, 0xcc, + 0xb2, 0xc3, 0xdc, 0xc1, 0x9c, 0xc6, 0x9c, 0xbc, 0xd4, 0xb9, + 0x00, 0x83, 0x00, 0x7b, 0x00, 0x9e, +}; + +static const unsigned char s6e8ax0_22_gamma_100[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xbd, 0x80, 0xcd, 0xba, 0xce, + 0xb3, 0xc4, 0xde, 0xc3, 0x9c, 0xc4, 0x9, 0xb8, 0xd3, 0xb6, + 0x00, 0x88, 0x00, 0x80, 0x00, 0xa5, +}; + +static const unsigned char s6e8ax0_22_gamma_120[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xb9, 0x95, 0xc8, 0xb1, 0xcf, + 0xb2, 0xc6, 0xdf, 0xc5, 0x9b, 0xc3, 0x99, 0xb6, 0xd2, 0xb6, + 0x00, 0x8f, 0x00, 0x86, 0x00, 0xac, +}; + +static const unsigned char s6e8ax0_22_gamma_130[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xb7, 0xa0, 0xc7, 0xb1, 0xd0, + 0xb2, 0xc4, 0xdd, 0xc3, 0x9a, 0xc3, 0x98, 0xb6, 0xd0, 0xb4, + 0x00, 0x92, 0x00, 0x8a, 0x00, 0xb1, +}; +
[RFC PATCH 3/4] video: display: Add exynos-dsi video source driver
This patch adds new driver for DSI master block available in Samsung Exynos SoCs. The driver is designed and written specifically for Common Display Framework. Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park --- drivers/video/display/Kconfig |3 + drivers/video/display/Makefile|1 + drivers/video/display/source-exynos_dsi.c | 1313 + include/video/exynos_dsi.h| 41 + 4 files changed, 1358 insertions(+) create mode 100644 drivers/video/display/source-exynos_dsi.c create mode 100644 include/video/exynos_dsi.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 477192d..b14527a 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -6,5 +6,8 @@ menuconfig DISPLAY_CORE if DISPLAY_CORE +config DISPLAY_SOURCE_EXYNOS_DSI + tristate "Samsung SoC MIPI DSI Master" + endif # DISPLAY_CORE diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index bd93496..40a283a 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o +obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o diff --git a/drivers/video/display/source-exynos_dsi.c b/drivers/video/display/source-exynos_dsi.c new file mode 100644 index 000..30b15bf --- /dev/null +++ b/drivers/video/display/source-exynos_dsi.c @@ -0,0 +1,1313 @@ +/* + * Samsung SoC MIPI DSI Master driver. + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd + * + * Contacts: Tomasz Figa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define DSIM_STATUS_REG0x0 /* Status register */ +#define DSIM_SWRST_REG 0x4 /* Software reset register */ +#define DSIM_CLKCTRL_REG 0x8 /* Clock control register */ +#define DSIM_TIMEOUT_REG 0xc /* Time out register */ +#define DSIM_CONFIG_REG0x10/* Configuration register */ +#define DSIM_ESCMODE_REG 0x14/* Escape mode register */ + +/* Main display image resolution register */ +#define DSIM_MDRESOL_REG 0x18 +#define DSIM_MVPORCH_REG 0x1c/* Main display Vporch register */ +#define DSIM_MHPORCH_REG 0x20/* Main display Hporch register */ +#define DSIM_MSYNC_REG 0x24/* Main display sync area register */ + +/* Sub display image resolution register */ +#define DSIM_SDRESOL_REG 0x28 +#define DSIM_INTSRC_REG0x2c/* Interrupt source register */ +#define DSIM_INTMSK_REG0x30/* Interrupt mask register */ +#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register */ +#define DSIM_PAYLOAD_REG 0x38/* Payload FIFO register */ +#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */ +#define DSIM_FIFOTHLD_REG 0x40/* FIFO threshold level register */ +#define DSIM_FIFOCTRL_REG 0x44/* FIFO status and control register */ + +/* FIFO memory AC characteristic register */ +#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */ +#define DSIM_PLLTMR_REG0x50/* PLL timer register */ +#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */ +#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */ + +/* DSIM_STATUS */ +#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0) +#define DSIM_STOP_STATE_CLK(1 << 8) +#define DSIM_TX_READY_HS_CLK (1 << 10) +#define DSIM_PLL_STABLE(1 << 31) + +/* DSIM_SWRST */ +#define DSIM_FUNCRST (1 << 16) +#define DSIM_SWRST (1 << 0) + +/* DSIM_TIMEOUT */ +#define DSIM_LPDR_TOUT(x) ((x) << 0) +#define DSIM_BTA_TOUT(x) ((x) << 16) + +/* DSIM_CLKCTRL */ +#define DSIM_ESC_PRESCALER(x) (((x) & 0x) << 0) +#define DSIM_ESC_PRESCALER_MASK(0x << 0) +#define DSIM_LANE_ESC_CLK_EN_CLK (1 << 19) +#define DSIM_LANE_ESC_CLK_EN_DATA(x) (((x) & 0xf) << 20) +#define DSIM_LANE_ESC_CLK_EN_DATA_MASK (0xf << 20) +#define DSIM_BYTE_CLKEN(1 << 24) +#define DSIM_BYTE_CLK_SRC(x) (((x) & 0x3) << 25) +#define DSIM_BYTE_CLK_SRC_MASK (0x3 << 25) +#define DSIM_PLL_BYPASS(1 << 27) +#define DSIM_ESC_CLKEN (1 << 28) +#define DSIM_TX_REQUEST_HSCLK (1 << 31) + +/* DSIM_CONFIG */ +#define DSIM_LANE_EN_CLK (1 << 0) +#define DSIM_LANE_EN(x)
[RFC PATCH 2/4] video: add makefile & kconfig
Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park --- drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/video/display/Kconfig | 10 ++ drivers/video/display/Makefile | 1 + 4 files changed, 13 insertions(+) create mode 100644 drivers/video/display/Kconfig create mode 100644 drivers/video/display/Makefile diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 68f17ee..800e98c 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2444,6 +2444,7 @@ source "drivers/video/omap/Kconfig" source "drivers/video/omap2/Kconfig" source "drivers/video/exynos/Kconfig" source "drivers/video/backlight/Kconfig" +source "drivers/video/display/Kconfig" if VT source "drivers/video/console/Kconfig" diff --git a/drivers/video/Makefile b/drivers/video/Makefile index f592f3b..4a091d4 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -14,6 +14,7 @@ fb-objs := $(fb-y) obj-$(CONFIG_VT) += console/ obj-$(CONFIG_LOGO) += logo/ obj-y+= backlight/ +obj-y+= display/ obj-$(CONFIG_EXYNOS_VIDEO) += exynos/ diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig new file mode 100644 index 000..477192d --- /dev/null +++ b/drivers/video/display/Kconfig @@ -0,0 +1,10 @@ +menuconfig DISPLAY_CORE + tristate "Display Core" + ---help--- + Support common display framework for graphics devices. + +if DISPLAY_CORE + + + +endif # DISPLAY_CORE diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile new file mode 100644 index 000..bd93496 --- /dev/null +++ b/drivers/video/display/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_DISPLAY_CORE) += display-core.o -- 1.8.1
[RFC PATCH 1/4] video: add display-core
Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park --- drivers/video/display/display-core.c | 295 +++ include/video/display.h | 230 +++ 2 files changed, 525 insertions(+) create mode 100644 drivers/video/display/display-core.c create mode 100644 include/video/display.h diff --git a/drivers/video/display/display-core.c b/drivers/video/display/display-core.c new file mode 100644 index 000..ed49384 --- /dev/null +++ b/drivers/video/display/display-core.c @@ -0,0 +1,295 @@ +/* + * Display Core + * + * Copyright (C) 2012 Renesas Solutions Corp. + * + * Contacts: Laurent Pinchart + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +static struct video_source *video_source_bind(struct display_entity *entity); +static void video_source_unbind(struct display_entity *entity); + +/* - + * Display Entity + */ + +static LIST_HEAD(display_entity_list); +static DEFINE_MUTEX(display_entity_mutex); + +struct display_entity *display_entity_get_first(void) +{ + /* FIXME: Don't we need some locking here? */ + + if (list_empty(_entity_list)) + return NULL; + + return list_first_entry(_entity_list, struct display_entity, + list); +} +EXPORT_SYMBOL(display_entity_get_first); + +int display_entity_set_state(struct display_entity *entity, +enum display_entity_state state) +{ + int ret; + + if (entity->state == state) + return 0; + + if (!entity->ops || !entity->ops->set_state) + return 0; + + ret = entity->ops->set_state(entity, state); + if (ret < 0) + return ret; + + entity->state = state; + return 0; +} +EXPORT_SYMBOL_GPL(display_entity_set_state); + +int display_entity_get_modes(struct display_entity *entity, +const struct videomode **modes) +{ + if (!entity->ops || !entity->ops->get_modes) + return 0; + + return entity->ops->get_modes(entity, modes); +} +EXPORT_SYMBOL_GPL(display_entity_get_modes); + +int display_entity_get_size(struct display_entity *entity, + unsigned int *width, unsigned int *height) +{ + if (!entity->ops || !entity->ops->get_size) + return -EOPNOTSUPP; + + return entity->ops->get_size(entity, width, height); +} +EXPORT_SYMBOL_GPL(display_entity_get_size); + +int display_entity_get_params(struct display_entity *entity, + struct display_entity_interface_params *params) +{ + if (!entity->ops || !entity->ops->get_params) + return -EOPNOTSUPP; + + return entity->ops->get_params(entity, params); +} +EXPORT_SYMBOL_GPL(display_entity_get_params); + +static void display_entity_release(struct kref *ref) +{ + struct display_entity *entity = + container_of(ref, struct display_entity, ref); + + if (entity->release) + entity->release(entity); +} + +struct display_entity *display_entity_get(struct display_entity *entity) +{ + if (entity == NULL) + return NULL; + + kref_get(>ref); + return entity; +} +EXPORT_SYMBOL_GPL(display_entity_get); + +void display_entity_put(struct display_entity *entity) +{ + kref_put(>ref, display_entity_release); +} +EXPORT_SYMBOL_GPL(display_entity_put); + +int __must_check __display_entity_register(struct display_entity *entity, + struct module *owner) +{ + struct video_source *src; + + kref_init(>ref); + entity->owner = owner; + entity->state = DISPLAY_ENTITY_STATE_OFF; + entity->source = NULL; + + src = video_source_bind(entity); + if (!src) + return -EPROBE_DEFER; + + mutex_lock(_entity_mutex); + list_add(>list, _entity_list); + mutex_unlock(_entity_mutex); + + return 0; +} +EXPORT_SYMBOL_GPL(__display_entity_register); + +void display_entity_unregister(struct display_entity *entity) +{ + video_source_unbind(entity); + + mutex_lock(_entity_mutex); + + list_del(>list); + mutex_unlock(_entity_mutex); + + display_entity_put(entity); +} +EXPORT_SYMBOL_GPL(display_entity_unregister); + +/* - + * Video Source + */ + +static LIST_HEAD(video_source_list); +static DEFINE_MUTEX(video_source_mutex); + +static void video_source_release(struct kref *ref) +{ + struct video_source *src = + container_of(ref, struct video_source, ref); + + if (src->release) +
[RFC PATCH 0/4] Common Display Framework-TF
Hi, After pretty long time of trying to adapt Exynos-specific DSI display support to Common Display Framework I'm ready to show some preliminary RFC patches. This series shows some ideas for CDF that came to my mind during my work, some changes based on comments received by Tomi's edition of CDF and also preliminarys version of Exynos DSI (video source part only, still with some FIXMEs) and Samsung S6E8AX0 DSI panel drivers. It is heavily based on Tomi's work which can be found here: http://thread.gmane.org/gmane.comp.video.dri.devel/78227 The code might be a bit hacky in places, as I wanted to get it to a kind of complete and working state first. However I hope that some of the ideas might useful for further works. So, here comes the TF edition of Common Clock Framework. Changes done to Tomi's edition of CDF: - Replaced set_operation_mode, set_pixel_format and set_size video source operations with get_params display entity operation, as it was originally in Laurent's version. We have discussed this matter on the mailing list and decided that it would be better to have the source ask the sink for its parameter structure and do whatever appropriate with it. - Defined a preliminary set of DSI bus parameters. Following parameters are defined: 1. Pixel format used for video data transmission. 2. Mode flags (several bit flags ORed together): a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command mode), following DSI_MODE_VIDEO_* flags are relevant only if this flag is set. b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed to sync events) d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode detection e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data j) DSI_MODE_EOT_PACKET - entity needs EoT packets 3. Bit (serial) clock frequency in HS mode. 4. Escape mode clock frequency. 5. Mask of used data lanes (each bit represents single lane). 6. Command allow area in video mode - amount of lines after transmitting video data when generic commands are accepted. Feel free to suggest anything missing or wrong, as the list of parameters is based merely on what was used in original Exynos MIPI DSIM driver. - Redesigned source-entity matching. Now each source has name string and integer id and each entity has source name and source id. In addition, they can have of_node specified, which is used for Device Tree-based matching. The matching procedure is as follows: 1. Matching takes place when display entity registers. a) If there is of_node specified for the entity then "video-source" phandle of this node is being parsed and list of registered sources is traversed in search of a source with of_node received from parsing the phandle. b) Otherwise the matching key is a pair of source name and id. 2. If no matching source is found, display_entity_register returns -EPROBE_DEFER error which causes the entity driver to defer its probe until the source registers. 3. Otherwise an optional bind operation of video source is called, sink field of source and source field of entity are set and the matching ends successfully. - Some initial concept of source-entity cross-locking. Only video source is protected at the moment, as I still have to think a bit about locking the entity in a way where removing it by user request is still possible. - Dropped any panels and chips that I can't test. They are irrelevant for this series, so there is no point in including them. - Added Exynos DSI video source driver. This is a new driver for the DSI controller found in Exynos SoCs. It still needs some work, but in current state can be considered an example of DSI video source implementation for my version of CDF. - Added Samsung S6E8AX0 DSI panel driver. This is the old Exynos-specific driver, just migrated to CDF and with some hacks to provide control over entity state to userspace using lcd device. However it can be used to demonstrate video source ops in use. Feel free to comment as much as you can. Tomasz Figa (4): video: add display-core video: add makefile & kconfig video: display: Add exynos-dsi video source driver video: display: Add Samsung s6e8ax0 display panel driver drivers/video/Kconfig |1 + drivers/video/Makefile|1 + drivers/video/display/Kconfig | 16
[PATCH 9/9] drm/i915: Hook PSR functionality
PSR must be enabled after transcoder and port are running. And it is only available for HSW. v2: move enable/disable to intel_ddi Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index feb7a4a..1dba035d 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1306,6 +1306,7 @@ static void intel_enable_ddi(struct intel_encoder *intel_encoder) struct intel_dp *intel_dp = enc_to_intel_dp(encoder); ironlake_edp_backlight_on(intel_dp); + intel_edp_enable_psr(intel_dp); } } @@ -1318,6 +1319,7 @@ static void intel_disable_ddi(struct intel_encoder *intel_encoder) struct intel_dp *intel_dp = enc_to_intel_dp(encoder); ironlake_edp_backlight_off(intel_dp); + intel_edp_disable_psr(intel_dp); } } -- 1.7.11.7
[PATCH 8/9] drm/i915: Added debugfs support for PSR Status
From: Shobhit KumarAdded support for PSR entry counter and performance counters Signed-off-by: Shobhit Kumar v2: Add psr enabled yes/no info Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_debugfs.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 90a6fc5..11d2896 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1659,6 +1659,39 @@ static int i915_dpio_info(struct seq_file *m, void *data) return 0; } +static int i915_edp_psr_status(struct seq_file *m, void *data) +{ + struct drm_info_node *node = (struct drm_info_node *) m->private; + struct drm_device *dev = node->minor->dev; + struct drm_i915_private *dev_priv = dev->dev_private; + int count; + u32 psrctl, psrstat, psrperf; + + /* Bit 31 gives the PSR enabled */ + psrctl = I915_READ(EDP_PSR_CTL); + seq_printf(m, "PSR Enabled: %s\n", + yesno(psrctl & EDP_PSR_ENABLE)); + + /* Bits 19:16 gives the PSR entry count */ + psrstat = I915_READ(EDP_PSR_STATUS_CTL); + count = ((psrstat >> 16) & 0xf); + + /* Format the PSR Entry Count only for now. +* TBD: Other status information +*/ + seq_printf(m, "EDP_PSR_ENTRY_COUNT: %u\n", count); + + /* Current PSR state */ + count = ((psrstat >> 29) & 0x7); + seq_printf(m, "EDP_PSR_CURRENT_STATE: 0x%x\n", count); + + /* Perfromance counter bit 23:0 */ + psrperf = (I915_READ(EDP_PSR_PERF_CNT)) & 0xff; + seq_printf(m, "EDP_PSR_PERF_COUNTER: %u\n", psrperf); + + return 0; +} + static ssize_t i915_wedged_read(struct file *filp, char __user *ubuf, @@ -2228,6 +2261,7 @@ static struct drm_info_list i915_debugfs_list[] = { {"i915_swizzle_info", i915_swizzle_info, 0}, {"i915_ppgtt_info", i915_ppgtt_info, 0}, {"i915_dpio", i915_dpio_info, 0}, + {"i915_edp_psr_status", i915_edp_psr_status, 0}, }; #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list) -- 1.7.11.7
[PATCH 7/9] drm/i915: Enable/Disable PSR on HSW
From: Shobhit KumarAdded eDP PSR enable functionality. This includes setting the PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config, enabling PSR in the sink via DPCD register and finally enabling PSR on the host. PSR works only in LPSP mode, so put the PIPE_DDI in DDIA always on This patch is heavily based on initial PSR code by Sateesh Kavuri but is quite different in implementation. Makes use of VBT parsed data and also the code has been cleaned up. Credits-by: Sateesh Kavuri Signed-off-by: Shobhit Kumar v2: fix getting base.crtc from intel_dp and fix DDI_EDP_INPUT_A_ON entry v3: Add eDP PSR registers here only when they are really used and use HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder) Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 24 ++ drivers/gpu/drm/i915/intel_ddi.c | 6 +- drivers/gpu/drm/i915/intel_dp.c | 172 +++ drivers/gpu/drm/i915/intel_drv.h | 3 + 4 files changed, 204 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 10732dc..6f87d5b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1563,6 +1563,30 @@ #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B) #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B) +/* HSW eDP PSR registers */ +#define EDP_PSR_CTL0x64800 +#define EDP_PSR_ENABLE (1<<31) +#define EDP_PSR_LINK_DISABLE (0<<27) +#define EDP_PSR_LINK_STANDBY (1<<27) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0<<25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25) +#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20 +#define EDP_PSR_SKIP_AUX_EXIT(1<<12) +#define EDP_PSR_TP1_TP2_SEL (0<<11) +#define EDP_PSR_TP1_TP3_SEL (1<<11) +#define EDP_PSR_TP2_TP3_TIME_500us (0<<8) +#define EDP_PSR_TP2_TP3_TIME_100us (1<<8) +#define EDP_PSR_TP2_TP3_TIME_2500us (2<<8) +#define EDP_PSR_TP2_TP3_TIME_0us (3<<8) +#define EDP_PSR_TP1_TIME_500us (0<<4) +#define EDP_PSR_TP1_TIME_100us (1<<4) +#define EDP_PSR_TP1_TIME_2500us (2<<4) +#define EDP_PSR_TP1_TIME_0us (3<<4) +#define EDP_PSR_IDLE_FRAME_SHIFT 0 + #define EDP_PSR_AUX_CTL0x64810 #define EDP_PSR_AUX_DATA1 0x64814 #define EDP_PSR_AUX_DATA2 0x64818 diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 2e904a5..feb7a4a 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -985,9 +985,13 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc) temp |= TRANS_DDI_PHSYNC; if (cpu_transcoder == TRANSCODER_EDP) { + struct intel_dp *intel_dp = enc_to_intel_dp(encoder); switch (pipe) { case PIPE_A: - temp |= TRANS_DDI_EDP_INPUT_A_ONOFF; + if (intel_dp->psr_dpcd[0] & 0x1) + temp |= TRANS_DDI_EDP_INPUT_A_ON; + else + temp |= TRANS_DDI_EDP_INPUT_A_ONOFF; break; case PIPE_B: temp |= TRANS_DDI_EDP_INPUT_B_ONOFF; diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index fe83e05..d136890 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp *intel_dp) return intel_dig_port->base.base.dev; } +static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp) +{ + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); + + return intel_dig_port->base.base.crtc; +} + static struct intel_dp *intel_attached_dp(struct drm_connector *connector) { return enc_to_intel_dp(_attached_encoder(connector)->base); @@ -1489,6 +1496,171 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp) intel_dp->psr_setup = 1; } +static bool +intel_edp_is_psr_enabled(struct intel_dp* intel_dp) +{ + struct drm_device *dev = intel_dp_to_dev(intel_dp); + struct drm_i915_private *dev_priv = dev->dev_private; + return (I915_READ(EDP_PSR_CTL) & (1<<31)) ? true : false; +} + + +static void +intel_edp_psr_enable_src(struct intel_dp *intel_dp) +{ + struct drm_device *dev = intel_dp_to_dev(intel_dp); + struct drm_i915_private *dev_priv = dev->dev_private; + uint32_t max_sleep_time = 0x1f; + uint32_t
[PATCH 6/9] drm/i915: VBT Parsing for the PSR Feature Block for HSW
From: Shobhit KumarParse and store useful information in i915_dev_private Signed-off-by: Shobhit Kumar v2: Add to new vbt struct and call them psr_* Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 7 +++ drivers/gpu/drm/i915/intel_bios.c | 30 ++ drivers/gpu/drm/i915/intel_bios.h | 20 +++- 3 files changed, 56 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index e22f6bd..b5f1842 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -689,6 +689,13 @@ struct intel_vbt_data { int edp_bpp; struct edp_power_seq edp_pps; + /* eDP PSR*/ + u8 psr_full_link_state; + u8 psr_wait_lines; + u8 psr_idle_frames; + u16 psr_wakeup_tp1; + u16 psr_wakeup_tp2_tp3; + int crt_ddc_pin; int child_dev_num; diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index e145151..2a3fa8b 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -381,6 +381,35 @@ parse_general_definitions(struct drm_i915_private *dev_priv, } } + +static void +parse_edp_psr(struct drm_i915_private *dev_priv, struct bdb_header *bdb) +{ + struct bdb_psr_features *psr; + struct bdb_lvds_options *lvds_opts; + int index = 0; + lvds_opts = find_section(bdb, BDB_LVDS_OPTIONS); + if (!lvds_opts) { + DRM_DEBUG_KMS("No LVDS Options block found.\n"); + return; + } + + index = lvds_opts->panel_type; + + psr = find_section(bdb, BDB_PSR_FEATURES); + if (!psr) { + DRM_DEBUG_KMS("No PSR feature block found.\n"); + return; + } + + dev_priv->vbt.psr_full_link_state = psr[index].link_disable; + dev_priv->vbt.psr_wait_lines = psr[index].wait_lines; + dev_priv->vbt.psr_idle_frames = psr[index].idle_frames; + dev_priv->vbt.psr_wakeup_tp1 = psr[index].wakeup_tp1; + dev_priv->vbt.psr_wakeup_tp2_tp3 = psr[index].wakeup_tp2; +} + + static void parse_sdvo_device_mapping(struct drm_i915_private *dev_priv, struct bdb_header *bdb) @@ -740,6 +769,7 @@ intel_parse_bios(struct drm_device *dev) parse_device_mapping(dev_priv, bdb); parse_driver_features(dev_priv, bdb); parse_edp(dev_priv, bdb); + parse_edp_psr(dev_priv, bdb); if (bios) pci_unmap_rom(pdev, bios); diff --git a/drivers/gpu/drm/i915/intel_bios.h b/drivers/gpu/drm/i915/intel_bios.h index 36e57f9..c1d39de 100644 --- a/drivers/gpu/drm/i915/intel_bios.h +++ b/drivers/gpu/drm/i915/intel_bios.h @@ -80,7 +80,7 @@ struct vbios_data { #define BDB_EXT_MMIO_REGS6 #define BDB_SWF_IO 7 #define BDB_SWF_MMIO 8 -#define BDB_DOT_CLOCK_TABLE 9 +#define BDB_PSR_FEATURES 9 #define BDB_MODE_REMOVAL_TABLE 10 #define BDB_CHILD_DEVICE_TABLE 11 #define BDB_DRIVER_FEATURES 12 @@ -263,6 +263,24 @@ struct bdb_lvds_options { u8 rsvd4; } __attribute__((packed)); +struct bdb_psr_features { + /* psr_enable byte */ + u8 link_disable:1; + u8 require_aux:1; + u8 rsvd1:6; + + /* panel wait times */ + u8 idle_frames:4; + u8 wait_lines:3; + u8 rsvd2:1; + + /* TP1 wakeup time */ + u16 wakeup_tp1; + + /* TP2 wakeup time */ + u16 wakeup_tp2; +} __attribute__((packed)); + /* LFP pointer table contains entries to the struct below */ struct bdb_lvds_lfp_data_ptr { u16 fp_timing_offset; /* offsets are from start of bdb */ -- 1.7.11.7
[PATCH 5/9] drm/i915: Setup EDP PSR AUX Registers
From: Shobhit KumarSigned-off-by: Shobhit Kumar v2: Created aux_clock_divider function to avoid duplicated code. Unfortunatelly dp_aux_ch and psr_aux_ch aren't so similar to reuse full code. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 13 ++ drivers/gpu/drm/i915/intel_dp.c | 89 +++- drivers/gpu/drm/i915/intel_drv.h | 1 + 3 files changed, 83 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 7bb3134..10732dc 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1563,6 +1563,19 @@ #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B) #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B) +#define EDP_PSR_AUX_CTL0x64810 +#define EDP_PSR_AUX_DATA1 0x64814 +#define EDP_PSR_AUX_DATA2 0x64818 +#define EDP_PSR_AUX_DATA3 0x6481c +#define EDP_PSR_AUX_DATA4 0x64820 +#define EDP_PSR_AUX_DATA5 0x64824 +#define EDP_PSR_STATUS_CTL 0x64840 +#define EDP_PSR_STATUS_MASK (7<<29) +#define EDP_PSR_PERF_CNT 0x64844 +#define EDP_PSR_DEBUG_CTL 0x64860 +#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26) +#define EDP_PSR_DEBUG_MASK_HPD (1<<25) + /* VGA port control */ #define ADPA 0x61100 #define PCH_ADPA0xe1100 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index aeb0ef1..fe83e05 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -364,6 +364,34 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq) return status; } +static uint32_t get_aux_clock_divider(struct intel_dp *intel_dp) +{ + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); + struct drm_device *dev = intel_dig_port->base.base.dev; + struct drm_i915_private *dev_priv = dev->dev_private; + + /* The clock divider is based off the hrawclk, +* and would like to run at 2MHz. So, take the +* hrawclk value and divide by 2 and use that +* +* Note that PCH attached eDP panels should use a 125MHz input +* clock divider. +*/ + if (is_cpu_edp(intel_dp)) { + if (HAS_DDI(dev)) + return intel_ddi_get_cdclk_freq(dev_priv) >> 1; + else if (IS_VALLEYVIEW(dev)) + return 100; + else if (IS_GEN6(dev) || IS_GEN7(dev)) + return 200; /* SNB & IVB eDP input clock at 400Mhz */ + else + return 225; /* eDP input clock at 450Mhz */ + } else if (HAS_PCH_SPLIT(dev)) + return DIV_ROUND_UP(intel_pch_rawclk(dev), 2); + else + return intel_hrawclk(dev) / 2; +} + static int intel_dp_aux_ch(struct intel_dp *intel_dp, uint8_t *send, int send_bytes, @@ -411,26 +439,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, } intel_dp_check_edp(intel_dp); - /* The clock divider is based off the hrawclk, -* and would like to run at 2MHz. So, take the -* hrawclk value and divide by 2 and use that -* -* Note that PCH attached eDP panels should use a 125MHz input -* clock divider. -*/ - if (is_cpu_edp(intel_dp)) { - if (HAS_DDI(dev)) - aux_clock_divider = intel_ddi_get_cdclk_freq(dev_priv) >> 1; - else if (IS_VALLEYVIEW(dev)) - aux_clock_divider = 100; - else if (IS_GEN6(dev) || IS_GEN7(dev)) - aux_clock_divider = 200; /* SNB & IVB eDP input clock at 400Mhz */ - else - aux_clock_divider = 225; /* eDP input clock at 450Mhz */ - } else if (HAS_PCH_SPLIT(dev)) - aux_clock_divider = DIV_ROUND_UP(intel_pch_rawclk(dev), 2); - else - aux_clock_divider = intel_hrawclk(dev) / 2; + aux_clock_divider = get_aux_clock_divider(intel_dp); if (IS_GEN6(dev)) precharge = 3; @@ -1440,6 +1449,46 @@ static bool is_edp_psr(struct intel_dp *intel_dp) return (is_edp(intel_dp) && (intel_dp->psr_dpcd[0] & 0x1)); } +static void intel_edp_psr_setup(struct intel_dp *intel_dp) +{ + struct drm_device *dev = intel_dp_to_dev(intel_dp); + struct drm_i915_private *dev_priv = dev->dev_private; + uint32_t aux_clock_divider; + int precharge = 0x3; + int msg_size = 5; /* Header(4) + Message(1) */ + + /* No need to setup if already done as these setting are persistent +* until power states are entered */ + if (intel_dp->psr_setup) + return; + + /* Setup AUX registers */ + /* Write command on DPCD
[PATCH 4/9] drm/i915: Read the EDP DPCD and PSR Capability
From: Shobhit KumarSigned-off-by: Shobhit Kumar v2: reuse of just created is_edp_psr and put it at right place. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 12 drivers/gpu/drm/i915/intel_drv.h | 1 + 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index cbd3236..aeb0ef1 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1435,6 +1435,11 @@ static void intel_post_disable_dp(struct intel_encoder *encoder) } } +static bool is_edp_psr(struct intel_dp *intel_dp) +{ + return (is_edp(intel_dp) && (intel_dp->psr_dpcd[0] & 0x1)); +} + static void intel_enable_dp(struct intel_encoder *encoder) { struct intel_dp *intel_dp = enc_to_intel_dp(>base); @@ -2111,6 +2116,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) if (intel_dp->dpcd[DP_DPCD_REV] == 0) return false; /* DPCD not present */ + /* Check if the panel supports PSR */ + memset(intel_dp->psr_dpcd, 0, EDP_PSR_RECEIVER_CAP_SIZE); + intel_dp_aux_native_read_retry(intel_dp, DP_PSR_SUPPORT, + intel_dp->psr_dpcd, + sizeof(intel_dp->psr_dpcd)); + if (is_edp_psr(intel_dp)) + DRM_DEBUG_KMS("Detected EDP PSR Panel.\n"); if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) return true; /* native DP sink */ diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index aeff0d1..d4b3bac 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -371,6 +371,7 @@ struct intel_dp { uint8_t link_bw; uint8_t lane_count; uint8_t dpcd[DP_RECEIVER_CAP_SIZE]; + uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE]; uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS]; struct i2c_adapter adapter; struct i2c_algo_dp_aux_data algo; -- 1.7.11.7
[PATCH 3/9] drm/i915: Added SDP and VSC structures for handling PSR for eDP
From: Shobhit KumarSigned-off-by: Sateesh Kavuri v2: Modified and corrected the structures to be more in line for kernel coding guidelines and rebased the code on Paulo's DP patchset Signed-off-by: Shobhit Kumar v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE v4: moving them to include/drm/drm_dp_helper.h and also already icluding EDP_PSR_RECEIVER_CAP_SIZE to add everything needed for PSR at once at drm_dp_helper.h Signed-off-by: Rodrigo Vivi --- include/drm/drm_dp_helper.h | 29 + 1 file changed, 29 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index e8e1417..e9b7c4b 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -343,12 +343,41 @@ u8 drm_dp_get_adjust_request_pre_emphasis(u8 link_status[DP_LINK_STATUS_SIZE], int lane); #define DP_RECEIVER_CAP_SIZE 0xf +#define EDP_PSR_RECEIVER_CAP_SIZE 2 + void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]); void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]); u8 drm_dp_link_rate_to_bw_code(int link_rate); int drm_dp_bw_code_to_link_rate(u8 link_bw); +/* SDP header as per eDP 1.3 spec, section 3.6 */ +struct edp_sdp_header { + u8 id; + u8 type; + u8 revision : 5;/* Bits 0:4 */ + u8 rsvd1: 3;/* Bits 5:7 */ + u8 valid_payload_bytes : 5; /* Bits 0:4 */ + u8 rsvd2 : 3; /* Bits 5:7 */ +} __attribute__((packed)); + +/* SDP VSC header as per eDP 1.3 spec, section 3.6 */ +struct edp_vsc_psr { + struct edp_sdp_header sdp_header; + u8 unused; + u8 psr_state : 1; /* Bit 0 */ + u8 update_rfb : 1; /* Bit 1 */ + u8 valid_crc : 1; /* Bit 2 */ + u8 reserved1 : 5; /* Bits 3:7 */ + u8 crc_r_lower; + u8 crc_r_higher; + u8 crc_g_lower; + u8 crc_g_higher; + u8 crc_b_lower; + u8 crc_b_higher; + u8 reserved2[24]; +} __attribute__((packed)); + static inline int drm_dp_max_link_rate(u8 dpcd[DP_RECEIVER_CAP_SIZE]) { -- 1.7.11.7
[PATCH 2/9] drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe
While old platforms had 3 transcoders and 3 pipes (1:1), HSW has 4 transcoders and 3 pipes. To avoid future mistakes transcoders must be used here instead of pipes even though it is working right now by coincidence. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 16 drivers/gpu/drm/i915/intel_hdmi.c | 12 ++-- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 2521617..7bb3134 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3742,14 +3742,14 @@ #define HSW_VIDEO_DIP_VSC_ECC_B0x61344 #define HSW_VIDEO_DIP_GCP_B0x61210 -#define HSW_TVIDEO_DIP_CTL(pipe) \ -_PIPE(pipe, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B) -#define HSW_TVIDEO_DIP_AVI_DATA(pipe) \ -_PIPE(pipe, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B) -#define HSW_TVIDEO_DIP_SPD_DATA(pipe) \ -_PIPE(pipe, HSW_VIDEO_DIP_SPD_DATA_A, HSW_VIDEO_DIP_SPD_DATA_B) -#define HSW_TVIDEO_DIP_GCP(pipe) \ - _PIPE(pipe, HSW_VIDEO_DIP_GCP_A, HSW_VIDEO_DIP_GCP_B) +#define HSW_TVIDEO_DIP_CTL(trans) \ +_TRANSCODER(trans, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B) +#define HSW_TVIDEO_DIP_AVI_DATA(trans) \ +_TRANSCODER(trans, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B) +#define HSW_TVIDEO_DIP_SPD_DATA(trans) \ +_TRANSCODER(trans, HSW_VIDEO_DIP_SPD_DATA_A, HSW_VIDEO_DIP_SPD_DATA_B) +#define HSW_TVIDEO_DIP_GCP(trans) \ + _TRANSCODER(trans, HSW_VIDEO_DIP_GCP_A, HSW_VIDEO_DIP_GCP_B) #define _TRANS_HTOTAL_B 0xe1000 #define _TRANS_HBLANK_B 0xe1004 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index d53b731..ab95e05 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -120,13 +120,13 @@ static u32 hsw_infoframe_enable(struct dip_infoframe *frame) } } -static u32 hsw_infoframe_data_reg(struct dip_infoframe *frame, enum pipe pipe) +static u32 hsw_infoframe_data_reg(struct dip_infoframe *frame, enum transcoder cpu_transcoder) { switch (frame->type) { case DIP_TYPE_AVI: - return HSW_TVIDEO_DIP_AVI_DATA(pipe); + return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder); case DIP_TYPE_SPD: - return HSW_TVIDEO_DIP_SPD_DATA(pipe); + return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder); default: DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type); return 0; @@ -293,8 +293,8 @@ static void hsw_write_infoframe(struct drm_encoder *encoder, struct drm_device *dev = encoder->dev; struct drm_i915_private *dev_priv = dev->dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc); - u32 ctl_reg = HSW_TVIDEO_DIP_CTL(intel_crtc->pipe); - u32 data_reg = hsw_infoframe_data_reg(frame, intel_crtc->pipe); + u32 ctl_reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder); + u32 data_reg = hsw_infoframe_data_reg(frame, intel_crtc->cpu_transcoder); unsigned int i, len = DIP_HEADER_SIZE + frame->len; u32 val = I915_READ(ctl_reg); @@ -566,7 +566,7 @@ static void hsw_set_infoframes(struct drm_encoder *encoder, struct drm_i915_private *dev_priv = encoder->dev->dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc); struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder); - u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->pipe); + u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder); u32 val = I915_READ(reg); assert_hdmi_port_disabled(intel_hdmi); -- 1.7.11.7
[PATCH 1/9] drm/i915: Organize VBT stuff inside drm_i915_private
drm_i915_private is getting bigger and bigger when adding new vbt stuff. So, the better way of getting drm_i915_private organized is to create an special structure for vbt stuff. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_dma.c | 8 +-- drivers/gpu/drm/i915/i915_drv.h | 56 +++-- drivers/gpu/drm/i915/intel_bios.c| 96 ++-- drivers/gpu/drm/i915/intel_crt.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 16 +++--- drivers/gpu/drm/i915/intel_dp.c | 12 ++--- drivers/gpu/drm/i915/intel_lvds.c| 20 drivers/gpu/drm/i915/intel_sdvo.c| 6 +-- drivers/gpu/drm/i915/intel_tv.c | 8 +-- 9 files changed, 116 insertions(+), 110 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3f70178..e43711f 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1714,10 +1714,10 @@ int i915_driver_unload(struct drm_device *dev) * free the memory space allocated for the child device * config parsed from VBT */ - if (dev_priv->child_dev && dev_priv->child_dev_num) { - kfree(dev_priv->child_dev); - dev_priv->child_dev = NULL; - dev_priv->child_dev_num = 0; + if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) { + kfree(dev_priv->vbt.child_dev); + dev_priv->vbt.child_dev = NULL; + dev_priv->vbt.child_dev_num = 0; } vga_switcheroo_unregister_client(dev->pdev); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 3189034..e22f6bd 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -665,6 +665,36 @@ struct intel_l3_parity { struct work_struct error_work; }; +struct intel_vbt_data { + struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */ + struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */ + + /* Feature bits */ + unsigned int int_tv_support:1; + unsigned int lvds_dither:1; + unsigned int lvds_vbt:1; + unsigned int int_crt_support:1; + unsigned int lvds_use_ssc:1; + unsigned int display_clock_mode:1; + int lvds_ssc_freq; + unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */ + + /* eDP */ + int edp_rate; + int edp_lanes; + int edp_preemphasis; + int edp_vswing; + bool edp_initialized; + bool edp_support; + int edp_bpp; + struct edp_power_seq edp_pps; + + int crt_ddc_pin; + + int child_dev_num; + struct child_device_config *child_dev; +}; + typedef struct drm_i915_private { struct drm_device *dev; struct kmem_cache *slab; @@ -745,6 +775,7 @@ typedef struct drm_i915_private { struct intel_fbc_work *fbc_work; struct intel_opregion opregion; + struct intel_vbt_data vbt; /* overlay */ struct intel_overlay *overlay; @@ -753,32 +784,9 @@ typedef struct drm_i915_private { /* LVDS info */ int backlight_level; /* restore backlight to this value */ bool backlight_enabled; - struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */ - struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */ - /* Feature bits from the VBIOS */ - unsigned int int_tv_support:1; - unsigned int lvds_dither:1; - unsigned int lvds_vbt:1; - unsigned int int_crt_support:1; - unsigned int lvds_use_ssc:1; - unsigned int display_clock_mode:1; - int lvds_ssc_freq; - unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */ - struct { - int rate; - int lanes; - int preemphasis; - int vswing; - - bool initialized; - bool support; - int bpp; - struct edp_power_seq pps; - } edp; bool no_aux_handshake; - int crt_ddc_pin; struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 965 */ int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */ int num_fence_regs; /* 8 on pre-965, 16 otherwise */ @@ -928,8 +936,6 @@ typedef struct drm_i915_private { /* indicates the reduced downclock for LVDS*/ int lvds_downclock; u16 orig_clock; - int child_dev_num; - struct child_device_config *child_dev; bool mchbar_need_disable; diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 55ffba1..e145151 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -212,7 +212,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv, if (!lvds_options) return; -
[PATCH 0/9] Enable eDP PSR functionality at HSW - v2
PSR is an eDP feature that allows power saving even with static image at eDP screen. v2: Main differences in this v2: - Created vbt struct to get i915 dev_priv more organized and to avoid adding more stuff into it. - migrated hsw macros to use transcoder instead of pipes than I could address eDP - remove patch that was only adding edp psr registers and added them on demand v1: Shobit Kumar has implemented this patch series some time ago, but had no eDP panel with PSR capability to test them. I could test and verify that this series fully identify PSR capability and enables it at HSW. I also verified that it saves from 0.5-1W but only when in blank screen. It seems it is not really entering in sleeping mode with static image at eDP screen yet. Please accept this series as the first part of PSR enabling while we continue working to improve its functionality. Rodrigo Vivi (3): drm/i915: Organize VBT stuff inside drm_i915_private drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe drm/i915: Hook PSR functionality Shobhit Kumar (6): drm/i915: Added SDP and VSC structures for handling PSR for eDP drm/i915: Read the EDP DPCD and PSR Capability drm/i915: Setup EDP PSR AUX Registers drm/i915: VBT Parsing for the PSR Feature Block for HSW drm/i915: Enable/Disable PSR on HSW drm/i915: Added debugfs support for PSR Status drivers/gpu/drm/i915/i915_debugfs.c | 34 + drivers/gpu/drm/i915/i915_dma.c | 8 +- drivers/gpu/drm/i915/i915_drv.h | 63 +--- drivers/gpu/drm/i915/i915_reg.h | 53 ++- drivers/gpu/drm/i915/intel_bios.c| 126 ++-- drivers/gpu/drm/i915/intel_bios.h| 20 ++- drivers/gpu/drm/i915/intel_crt.c | 4 +- drivers/gpu/drm/i915/intel_ddi.c | 8 +- drivers/gpu/drm/i915/intel_display.c | 16 +- drivers/gpu/drm/i915/intel_dp.c | 285 +++ drivers/gpu/drm/i915/intel_drv.h | 5 + drivers/gpu/drm/i915/intel_hdmi.c| 12 +- drivers/gpu/drm/i915/intel_lvds.c| 20 +-- drivers/gpu/drm/i915/intel_sdvo.c| 6 +- drivers/gpu/drm/i915/intel_tv.c | 8 +- include/drm/drm_dp_helper.h | 29 16 files changed, 551 insertions(+), 146 deletions(-) -- 1.7.11.7
[PATCH 1/2] drm/exynos: add support for dt based search to exynos4 hdmi
Hi Rahul, Could you add descriptions to dt document file? For this, you can refer to the below link, https://patchwork.kernel.org/patch/1948061/ Thanks, Inki Dae 2013/1/25 Rahul Sharma : > Signed-off-by: Rahul Sharma > --- > drivers/gpu/drm/exynos/exynos_ddc.c | 2 ++ > drivers/gpu/drm/exynos/exynos_hdmi.c| 6 ++ > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 2 ++ > 3 files changed, 10 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c > b/drivers/gpu/drm/exynos/exynos_ddc.c > index 4e9b5ba..7680809 100644 > --- a/drivers/gpu/drm/exynos/exynos_ddc.c > +++ b/drivers/gpu/drm/exynos/exynos_ddc.c > @@ -53,6 +53,8 @@ static struct of_device_id hdmiddc_match_types[] = { > { > .compatible = "samsung,exynos5-hdmiddc", > }, { > + .compatible = "samsung,exynos4-hdmiddc", > + }, { > /* end node */ > } > }; > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index fbab3c4..202b65f 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -2418,6 +2418,12 @@ static struct platform_device_id hdmi_driver_types[] = > { > #ifdef CONFIG_OF > static struct of_device_id hdmi_match_types[] = { > { > + .compatible = "samsung,exynos4-hdmi", > + .data = (void *)HDMI_TYPE13, > + }, { > + .compatible = "samsung,exynos4-hdmi14", > + .data = (void *)HDMI_TYPE14, > + }, { > .compatible = "samsung,exynos5-hdmi", > .data = (void *)HDMI_TYPE14, > }, { > diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c > b/drivers/gpu/drm/exynos/exynos_hdmiphy.c > index ea49d13..2e33f90 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c > @@ -51,6 +51,8 @@ static struct of_device_id hdmiphy_match_types[] = { > { > .compatible = "samsung,exynos5-hdmiphy", > }, { > + .compatible = "samsung,exynos4-hdmiphy", > + }, { > /* end node */ > } > }; > -- > 1.8.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos: Get HDMI version from device tree
2013/1/30 Sean Paul : > On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren > wrote: >> On 01/08/2013 01:16 PM, Sean Paul wrote: >>> Add a property to the hdmi node so we can specify the HDMI version in >>> the device tree instead of just defaulting to v1.4 with the existence of >>> the dt node. >> >> I guess this seems OK to me if required, although I'd certainly like to >> see someone familiar with the Exynos HW confirm whether this should be >> driven purely by DT compatible value for the HDMI IP block instead though. > > +inki > > Inki, does this seem reasonable to you? > Looks good to me. At least it's better than old one. I'll apply it if there is no any opinion. And one more thing, Exynos hdmi controller has no version info register so we need such thing. But in case of Mixer controller, it has the version info register so we could support all mixer controllers of Exynos SoC checking that register. So if you are planning on such thing for Mixer also then I'd recommend you to consider checking that register. Thanks, Inki Dae > > Sean > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon modeset crashes on A4-3400 HD6410D
On Tue, Jan 29, 2013 at 1:09 PM, Mikko Tiihonen wrote: > Hi, > > I have a A4-3400 CPU that I bought half a year ago. I've tried once month, > but Fedora has never succeeded in booting in graphical mode. > > Some time ago a finally built some custom kernels to figure out why. I > created a bug to Fedora bug, but it has not progressed. > > Analysis: > The radeon module startup fails with division by zero in > r6xx_remap_render_backend because the first RB is not enabled and the code > assuming that enabled RBs must be all the first ones of the valid range. > > > Longer version: > > In r600.c:r6xx_remap_render_backend > > The function contains only one divide: > > u32 r6xx_remap_render_backend(struct radeon_device *rdev, > u32 tiling_pipe_num, > u32 max_rb_num, > u32 total_max_rb_num, > u32 disabled_rb_mask) > { > u32 rendering_pipe_num, rb_num_width, req_rb_num; > ... > /* mask out the RBs that don't exist on that asic */ > disabled_rb_mask |= (0xff << max_rb_num) & 0xff; > > rendering_pipe_num = 1 << tiling_pipe_num; > req_rb_num = total_max_rb_num - > r600_count_pipe_bits(disabled_rb_mask); > BUG_ON(rendering_pipe_num < req_rb_num); > > pipe_rb_ratio = rendering_pipe_num / req_rb_num; > > I added a printk to see what actual parameters are passed in: > > tiling_pipe_num=2, max_rb_num=1, total_max_rb_num=8, disabled_rb_mask=253 > > Using those to calculate the divide by zero comes from: > > disabled_rb_mask |= 254; -> 255 > req_rb_num = 8 - 8; > > > Quick fix for stable kernel series: > > The attached fix activates only in the division by zero case and instead of > failing uses the given disabled_rb_mask. This is guaranteed to be regression > free and actually allows me to load the radeon driver successfully. It does > help with cards that currently work, but for which some usable RBs are > disabled due to the eager masking. > > > Proper fix would propably be to find out think why the disabled_rb_mask is > masked the way it is, were there bugs in other places for which it is a > workaround. I can see two possible modifictions: > 1) only mask bits exceeding total_max_rb_num instead of the max_rb_num since > the one enabled RB on A4-3400 can propably be any one of the 8 possible > values. > 2) or activate the current code only if there are more than max_rb_num zero > bits in the given disabled_rb_mask Looks good. I've gone ahead and applied your patch for safety sake and I also added a patch to set up the RBs correctly on your board. Please test the attached patches. Thanks! Alex -- next part -- A non-text attachment was scrubbed... Name: 0002-drm-radeon-protect-against-div-by-0-in-backend-setup.patch Type: text/x-patch Size: 1480 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a3d49f5b/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-backend-map-setup-on-1-RB-sumo-boards.patch Type: text/x-patch Size: 1682 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a3d49f5b/attachment-0001.bin>
[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=60028 --- Comment #9 from Michel D?nzer --- (In reply to comment #8) > Would it be good for me to bisect Mesa? If Mesa commit 6532eb17baff6e61b427f29e076883f8941ae664 (where code depending on DRM minor 26 was first introduced) doesn't leak, yes please. BTW, does setting the environment variable R600_HYPERZ=0 for the leaking process(es) work around the problem? > The testing I have done so far was assuming the problem was in the kernel, > [...] The fact that the memory is reclaimed on process exit makes that unlikely. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/c8235d78/attachment.html>
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 Alex Deucher changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=59690 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/c7fca45a/attachment.html>
[PATCH 4/5] drm/tegra: Implement VBLANK support
On Wed, Jan 30, 2013 at 9:34 AM, Thierry Reding wrote: > On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote: >> On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding >> wrote: >> > Implement support for the VBLANK IOCTL. Note that Tegra is somewhat >> > special in this case because it doesn't use the generic IRQ support >> > provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one >> > interrupt handler for each display controller. >> > >> > While at it, clean up the way that interrupts are enabled to ensure >> > that the VBLANK interrupt only gets enabled when required. >> > >> > Signed-off-by: Thierry Reding >> > --- >> >> Sorry Thierry, but is this a useful feature? Are applications really >> making use of it? Because it means that that an IRQ will have to >> trigger every 16.67ms when it is taken, which means the device can't >> sleep. (probably OK because it should go back to idle when the app >> lets go of the vblank). But worse, for one-shot panels there is no >> continuous vblank. I've been doing weird hacks to run a timer when the >> smart panel is idle to trick applications into thinking they have a >> vblank pulse. But really I think the whole feature of a vblank pulse >> is pretty lame and I wish it would die. Were you going to use it for >> something specific, or just adding it for completeness? > > This is mainly added for completeness. I know that on Tegra we can do a > lot better by using syncpoints, but applications such as Weston (in > general applications that use the generic DRM API) rely on this to sync > rendering with VBLANK. > > I don't think there's another way to achieve the same thing. And as you > already mentioned, this is only enabled when an application actively > uses it, in which case the device won't sleep anyway. I think driving animations with the vblank signal is nice, but we kinda only need that with the pageflip support. Unfortunately the current drm code is a bit a mess in that area, so pageflips force you to enable the vblank interrupt for otherwise the timestamp'ed pageflip completion events won't work. Recent intel hw has pageflip timestamp registers, so we don't really need that. And I guess other hw is similar. So we probably should clean up and untangle the infrastructure a bit around the drm vblank support code. Another issue is that the vblank ioctl itself doesn't deal with modeset crtc ids, so adding a new interface for that would be good. Otoh most kms clients don't really use it, but only care about pageflips. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #4 from Wojciech Pyczak --- Created attachment 73929 --> https://bugs.freedesktop.org/attachment.cgi?id=73929=edit In-game screenshot (bad rendering) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/84b0944b/attachment.html>
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #3 from Wojciech Pyczak --- Created attachment 73928 --> https://bugs.freedesktop.org/attachment.cgi?id=73928=edit In-game screenshot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/1e9f7ad8/attachment.html>
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #2 from Wojciech Pyczak --- Created attachment 73927 --> https://bugs.freedesktop.org/attachment.cgi?id=73927=edit Login screen (bad rendering) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/424d74f7/attachment.html>
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #1 from Wojciech Pyczak --- Created attachment 73926 --> https://bugs.freedesktop.org/attachment.cgi?id=73926=edit Login screen -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/77c91b6f/attachment.html>
[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=60028 --- Comment #8 from Dave Witbrodt --- (In reply to comment #7) > This is indeed more likely an issue in Mesa than in the kernel. The commit > you bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause > the Mesa code to use different code paths. In my two attempted manual reverts, I didn't know what effect the code in radeon_drv.c actually had. When looking at later DRM changes (after the one identified by the bisection) I saw that the value of KMS_DRIVER_MINOR was incremented further, so I thought I should leave the value unchanged. > Does current Mesa Git still leak? After updating/merging to the current HEAD (commit 02b6da1e of Jan. 29), I built new Mesa packages and installed them. I am currently relying the last kernel from my local tree which does not leak, so I rebooted to the kernel I had built that is most current with the upstream DRM changes: stable 3.7.4 + many commits from drm-next/drm-fixes up to commit 014b3440 of Jan. 21 in drm-fixes. Yes, it still leaks. Would it be good for me to bisect Mesa? I would use my most up-to-date kernel, try to find an older version of Mesa which does not leak, and then identify the first patch to Mesa which causes the leaking. The testing I have done so far was assuming the problem was in the kernel, but I was planning to look at Mesa as well. I decided to report the bug before continuing, hoping for some guidance from the experts. If there really is a memory leak caused by the kernel DRI, then I would like to help get it fixed before 3.8 is released; or, if there is a problem in Mesa I would like to help get it fixed for 9.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a62882a7/attachment-0001.html>
[Bug 60073] New: [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 Priority: medium Bug ID: 60073 Assignee: dri-devel at lists.freedesktop.org Summary: [bisected] Bad rendering in Path of Exile Severity: normal Classification: Unclassified OS: Linux (All) Reporter: nissarin at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Hardware: Radeon 6850 Software: 64bit Gentoo, game running via Wine (32bit), git versions of libdrm, xf86-video-ati, kernel version 3.7(ish) and latest 3.8 rc + drm-next branch The issue is affecting light effects, spell effects, etc. (see screenshots). Bisecting leads to this commit: commit 3b51d71c8544ee198008bbf3545bf3def6e9e77f Author: Jordan Justen Date: Fri Dec 28 11:00:50 2012 -0800 copyteximage: check that sRGB usage is valid for GLES3 / GL Reviewed-by: Ian Romanick Signed-off-by: Jordan Justen There is already one bug report mentioning this commit [1], not sure if it's the same issue. Besides PoE, I also encontered similar problem in StarCraft2, I didn't checked if it's the same problem, text/fonts on the loading screen shows the same "corruption", however the game also hangs the GPU, so bisecting it might be a bit problematic. [1] https://bugs.freedesktop.org/show_bug.cgi?id=59690 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a530ed2a/attachment-0001.html>
[git pull] fbcon locking fixes.
On Mon, Jan 28, 2013 at 1:45 PM, Maarten Lankhorst wrote: >> There was a path going into set_con2fb_path if an fb driver was >> already registered, I just pushed the locking out further on anyone >> going in there. >> >> it boots on my EFI macbook here. >> > I cherry picked those patches to my tree, and the full series no longer > triggers a lockdep warning. > It also no longer locks up during modprobing or vga-switcheroo either. > > Tested-by: Maarten Lankhorst QA reported spurious failures in some kms_flip tests and lockdep splats, somehow both are fixed with the locking. I'm a bit confused how these issues could cause failures in the flip tests, but alas: Tested-by: Lu Hua (for all three patches). -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd
Hi Vikas, Changelog mentioning differences between v1 and v2 is generally preferred as it will help the reviewers. On 30 January 2013 12:00, Vikas Sajjan wrote: > This patch adds display-timing node parsing to drm fimd, this depends on > the display helper patchset at > http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html > > It also adds pinctrl support for drm fimd. > > patch is based on branch "exynos-drm-next" at > http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > Is tested on Exynos5250 and Exynos4412 by applying dependent patches available > at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html > > Vikas Sajjan (1): > video: drm: exynos: Adds display-timing node parsing using video > helper function > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 > +++--- > 1 file changed, 35 insertions(+), 3 deletions(-) > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- With warm regards, Sachin
[PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 30, 2013 at 12:14:36PM +0100, Thierry Reding wrote: > On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrj?l? wrote: > > On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote: > > > On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: > > > > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding > > > > wrote: > > > > > drm_events_release() should be enough to clean up the events, but I > > > > > suspect the reason why Laurent put that code in was that the drm_crtc > > > > > private data still has a reference to the event and needs to clear it. > > > > > Otherwise the next page flip won't be scheduled because .page_flip() > > > > > would return -EBUSY. > > > > > > > > Hm, indeed we seem to have a nice bug in most drivers there :( > > > > > > I think I may just recently have run into this bug on Intel hardware. > > > Although perhaps I just used this wrongly. > > > > > > Just for the fun of it I wanted to implement Conway's Game of Life on > > > top of DRM/KMS. So I use two dumb buffer objects to alternately render > > > to. Then I wanted to use page-flipping to synchronize with VBLANK. > > > > > > So the sequence is basically: > > > > > > while (!done) { > > > grid_tick(grid); > > > grid_draw(grid, screen); > > > screen_flip(screen); > > > grid_swap(grid); > > > } > > > > > > Where screen_flip() chooses the framebuffer and passes it to > > > drmModePageFlip() like so: > > > > > > int fb = screen->fb[screen->current]; > > > > > > drmModePageFlip(screen->fd, screen->crtc, fb, > > > DRM_MODE_PAGE_FLIP_EVENT, screen); > > > > > > This runs for about 3 seconds and then hangs, so the display is no > > > longer updated. I've also verified that the same happens on Radeon. > > > But maybe I am mistaken and this isn't the proper programming sequence? > > > > You asked for page flip events. Do you actually handle them in your code? > > Duh. No I wasn't =) I suppose some queue must be running full if the > event isn't handled by calling drmHandleEvent(). Okay, this now works > properly with page-flipping. Just in case anybody's interested, the code is here: https://gitorious.org/thierryreding/kmslife Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/a1f2e6d7/attachment-0001.pgp>
[PATCH 2/7] mutex: add support for reservation style locks
Op 30-01-13 02:07, Rob Clark schreef: > On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst > wrote: > Hi Maarten, > > This is a nice looking extension to avoid re-implementing a mutex in > TTM/reservation code.. ofc, probably someone more familiar with mutex > code should probably review, but probably a bit of explanation about > what and why would be helpful. > >> mutex_reserve_lock, and mutex_reserve_lock_interruptible: >> Lock a buffer with a reservation_id set. reservation_id must not be set to >> 0, >> since this is a special value that means no reservation_id. >> >> Normally if reservation_id is not set, or is older than the reservation_id >> that's >> currently set on the mutex, the behavior will be to wait normally. >> >> However, if the reservation_id is newer than the current reservation_id, >> -EAGAIN >> will be returned, and this function must unreserve all other mutexes and >> then redo >> a blocking lock with normal mutex calls to prevent a deadlock, then call >> mutex_locked_set_reservation on successful locking to set the >> reservation_id inside >> the lock. > It might be a bit more clear to write up how this works from the > perspective of the user of ticket_mutex, separately from the internal > implementation first, and then how it works internally? Ie, the > mutex_set_reservation_fastpath() call is internal to the > implementation of ticket_mutex, but -EAGAIN is something the caller of > ticket_mutex shall deal with. This might give a clearer picture of > how TTM / reservation uses this to prevent deadlock, so those less > familiar with TTM could better understand. > > Well, here is an attempt to start a write-up, which should perhaps > eventually be folded into Documentation/ticket-mutex-design.txt. But > hopefully a better explanation of the problem and the solution will > encourage some review of the ticket_mutex changes. > > == > Basic problem statement: > - --- - > GPU's do operations that commonly involve many buffers. Those buffers > can be shared across contexts/processes, exist in different memory > domains (for example VRAM vs system memory), and so on. And with > PRIME / dmabuf, they can even be shared across devices. So there are > a handful of situations where the driver needs to wait for buffers to > become ready. If you think about this in terms of waiting on a buffer > mutex for it to become available, this presents a problem because > there is no way to guarantee that buffers appear in a execbuf/batch in > the same order in all contexts. That is directly under control of > userspace, and a result of the sequence of GL calls that an > application makes. Which results in the potential for deadlock. The > problem gets more complex when you consider that the kernel may need > to migrate the buffer(s) into VRAM before the GPU operates on the > buffer(s), which main in turn require evicting some other buffers (and > you don't want to evict other buffers which are already queued up to > the GPU), but for a simplified understanding of the problem you can > ignore this. > > The algorithm that TTM came up with for dealing with this problem is > quite simple. For each group of buffers (execbuf) that need to be > locked, the caller would be assigned a unique reservation_id, from a > global counter. In case of deadlock in the process of locking all the > buffers associated with a execbuf, the one with the lowest > reservation_id wins, and the one with the higher reservation_id > unlocks all of the buffers that it has already locked, and then tries > again. > > Originally TTM implemented this algorithm on top of an event-queue and > atomic-ops, but Maarten Lankhorst realized that by merging this with > the mutex code we could take advantage of the existing mutex fast-path > code and result in a simpler solution, and so ticket_mutex was born. > (Well, there where also some additional complexities with the original > implementation when you start adding in cross-device buffer sharing > for PRIME.. Maarten could probably better explain.) > > How it is used: > --- -- -- - > > A very simplified version: > > int submit_execbuf(execbuf) > { > /* acquiring locks, before queuing up to GPU: */ > seqno = assign_global_seqno(); You also need to make a 'lock' type for seqno, and lock it for lockdep purposes. This will be a virtual lock that will only exist in lockdep, but it's needed for proper lockdep annotation. See reservation_ticket_init/fini. It's also important that seqno must not be 0, ever. > retry: > for (buf in execbuf->buffers) { > ret = mutex_reserve_lock(>lock, seqno); The lockdep class for this lock must be the same for all reservations, and for maximum lockdep usability you want all the buf->lock lockdep class for all objects across all devices to be the same too. The __ticket_mutex_init in reservation_object_init does just that for you. :-) >
[PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrj?l? wrote: > On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote: > > On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: > > > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding > > > wrote: > > > > drm_events_release() should be enough to clean up the events, but I > > > > suspect the reason why Laurent put that code in was that the drm_crtc > > > > private data still has a reference to the event and needs to clear it. > > > > Otherwise the next page flip won't be scheduled because .page_flip() > > > > would return -EBUSY. > > > > > > Hm, indeed we seem to have a nice bug in most drivers there :( > > > > I think I may just recently have run into this bug on Intel hardware. > > Although perhaps I just used this wrongly. > > > > Just for the fun of it I wanted to implement Conway's Game of Life on > > top of DRM/KMS. So I use two dumb buffer objects to alternately render > > to. Then I wanted to use page-flipping to synchronize with VBLANK. > > > > So the sequence is basically: > > > > while (!done) { > > grid_tick(grid); > > grid_draw(grid, screen); > > screen_flip(screen); > > grid_swap(grid); > > } > > > > Where screen_flip() chooses the framebuffer and passes it to > > drmModePageFlip() like so: > > > > int fb = screen->fb[screen->current]; > > > > drmModePageFlip(screen->fd, screen->crtc, fb, > > DRM_MODE_PAGE_FLIP_EVENT, screen); > > > > This runs for about 3 seconds and then hangs, so the display is no > > longer updated. I've also verified that the same happens on Radeon. > > But maybe I am mistaken and this isn't the proper programming sequence? > > You asked for page flip events. Do you actually handle them in your code? Duh. No I wasn't =) I suppose some queue must be running full if the event isn't handled by calling drmHandleEvent(). Okay, this now works properly with page-flipping. Thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/4df62937/attachment.pgp>
[PATCH 2/7] mutex: add support for reservation style locks
On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark wrote: > == > Basic problem statement: > - --- - > GPU's do operations that commonly involve many buffers. Those buffers > can be shared across contexts/processes, exist in different memory > domains (for example VRAM vs system memory), and so on. And with > PRIME / dmabuf, they can even be shared across devices. So there are > a handful of situations where the driver needs to wait for buffers to > become ready. If you think about this in terms of waiting on a buffer > mutex for it to become available, this presents a problem because > there is no way to guarantee that buffers appear in a execbuf/batch in > the same order in all contexts. That is directly under control of > userspace, and a result of the sequence of GL calls that an > application makes. Which results in the potential for deadlock. The > problem gets more complex when you consider that the kernel may need > to migrate the buffer(s) into VRAM before the GPU operates on the > buffer(s), which main in turn require evicting some other buffers (and > you don't want to evict other buffers which are already queued up to > the GPU), but for a simplified understanding of the problem you can > ignore this. > > The algorithm that TTM came up with for dealing with this problem is > quite simple. For each group of buffers (execbuf) that need to be > locked, the caller would be assigned a unique reservation_id, from a > global counter. In case of deadlock in the process of locking all the > buffers associated with a execbuf, the one with the lowest > reservation_id wins, and the one with the higher reservation_id > unlocks all of the buffers that it has already locked, and then tries > again. > > Originally TTM implemented this algorithm on top of an event-queue and > atomic-ops, but Maarten Lankhorst realized that by merging this with > the mutex code we could take advantage of the existing mutex fast-path > code and result in a simpler solution, and so ticket_mutex was born. > (Well, there where also some additional complexities with the original > implementation when you start adding in cross-device buffer sharing > for PRIME.. Maarten could probably better explain.) I think the motivational writeup above is really nice, but the example code below is a bit wrong > How it is used: > --- -- -- - > > A very simplified version: > > int submit_execbuf(execbuf) > { > /* acquiring locks, before queuing up to GPU: */ > seqno = assign_global_seqno(); > retry: > for (buf in execbuf->buffers) { > ret = mutex_reserve_lock(>lock, seqno); > switch (ret) { > case 0: > /* we got the lock */ > break; > case -EAGAIN: > /* someone with a lower seqno, so unreserve and try again: */ > for (buf2 in reverse order starting before buf in > execbuf->buffers) > mutex_unreserve_unlock(>lock); > goto retry; > default: > goto err; > } > } > > /* now everything is good to go, submit job to GPU: */ > ... > } > > int finish_execbuf(execbuf) > { > /* when GPU is finished: */ > for (buf in execbuf->buffers) > mutex_unreserve_unlock(>lock); > } > == Since gpu command submission is all asnyc (hopefully at least) we don't unlock once it completes, but right away after the commands are submitted. Otherwise you wouldn't be able to submit new execbufs using the same buffer objects (and besides, holding locks while going back out to userspace is evil). The trick is to add a fence object for async operation (essentially a waitqueue on steriods to support gpu->gpu direct signalling). And updating fences for a given execbuf needs to happen atomically for all buffers, for otherwise userspace could trick the kernel into creating a circular fence chain. This wouldn't deadlock the kernel, since everything is async, but it'll nicely deadlock the gpus involved. Hence why we need ticketing locks to get dma_buf fences off the ground. Maybe wait for Maarten's feedback, then update your motivational blurb a bit? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
This patch adds display-timing node parsing using video helper function Signed-off-by: Leela Krishna Amudala Signed-off-by: Vikas Sajjan --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index bf0d9ba..94729ed 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device *pdev) struct exynos_drm_subdrv *subdrv; struct exynos_drm_fimd_pdata *pdata; struct exynos_drm_panel_info *panel; + struct fb_videomode *fbmode; + struct device *disp_dev = >dev; + struct pinctrl *pctrl; struct resource *res; int win; int ret = -EINVAL; DRM_DEBUG_KMS("%s\n", __FILE__); - pdata = pdev->dev.platform_data; - if (!pdata) { - dev_err(dev, "no platform data specified\n"); + if (pdev->dev.of_node) { + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) { + DRM_ERROR("memory allocation for pdata failed\n"); + return -ENOMEM; + } + + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL); + if (!fbmode) { + DRM_ERROR("memory allocation for fbmode failed\n"); + return -ENOMEM; + } + + ret = of_get_fb_videomode(disp_dev->of_node, fbmode, -1); + if (ret) { + DRM_ERROR("failed to get fb_videomode\n"); + return -EINVAL; + } + pdata->panel.timing = (struct fb_videomode) *fbmode; + + } else { + pdata = pdev->dev.platform_data; + if (!pdata) { + DRM_ERROR("no platform data specified\n"); + return -EINVAL; + } + } + + pctrl = devm_pinctrl_get_select_default(dev); + if (IS_ERR(pctrl)) { + DRM_ERROR("no pinctrl data provided.\n"); return -EINVAL; } -- 1.7.9.5
[PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd
This patch adds display-timing node parsing to drm fimd, this depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. patch is based on branch "exynos-drm-next" at http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Is tested on Exynos5250 and Exynos4412 by applying dependent patches available at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html Vikas Sajjan (1): video: drm: exynos: Adds display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) -- 1.7.9.5
[PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote: > On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: > > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding > > wrote: > > > drm_events_release() should be enough to clean up the events, but I > > > suspect the reason why Laurent put that code in was that the drm_crtc > > > private data still has a reference to the event and needs to clear it. > > > Otherwise the next page flip won't be scheduled because .page_flip() > > > would return -EBUSY. > > > > Hm, indeed we seem to have a nice bug in most drivers there :( > > I think I may just recently have run into this bug on Intel hardware. > Although perhaps I just used this wrongly. > > Just for the fun of it I wanted to implement Conway's Game of Life on > top of DRM/KMS. So I use two dumb buffer objects to alternately render > to. Then I wanted to use page-flipping to synchronize with VBLANK. > > So the sequence is basically: > > while (!done) { > grid_tick(grid); > grid_draw(grid, screen); > screen_flip(screen); > grid_swap(grid); > } > > Where screen_flip() chooses the framebuffer and passes it to > drmModePageFlip() like so: > > int fb = screen->fb[screen->current]; > > drmModePageFlip(screen->fd, screen->crtc, fb, > DRM_MODE_PAGE_FLIP_EVENT, screen); > > This runs for about 3 seconds and then hangs, so the display is no > longer updated. I've also verified that the same happens on Radeon. > But maybe I am mistaken and this isn't the proper programming sequence? You asked for page flip events. Do you actually handle them in your code? -- Ville Syrj?l? Intel OTC
A patch referencing this bug report has been merged...
Hi Florian, all - First, thanks for your work on adding the bugzilla comments when patches referencing bugs get merged. I find it useful. Recently however there was a comment about a commit referencing a commit referencing the bug report. Turns out the comment was missing one level of indirection, it was really about a commit referencing a commit referencing a commit referencing the bug [1]. Do we really need go that far, or is that a bug in your scripts? I think three levels of indirection is more noise than signal; two might be still be okay. What do others think? BR, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56
[PATCH 0/1] Adds display-timing node parsing to exynos drm fimd
Hello Sean, This patch set will be abandoned and your comments will be addressed in reply to http://lists.freedesktop.org/archives/dri-devel/2013-January/034080.html Thanks, Leela Krishna Amudala. On Tue, Jan 29, 2013 at 1:42 PM, Leela Krishna Amudala wrote: > This patch adds display-timing node parsing to drm fimd, this depends on > the display helper patchset at > http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html > > Patch is based on branch "exynos-drm-next" at > http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/ > > It is tested on Exynos5250 and Exynos4412 board by applying dependent patches > available at > http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html > > Leela Krishna Amudala (1): > video: drm: exynos: Adds display-timing node parsing using video > helper function > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 31 +++ > 1 file changed, 27 insertions(+), 4 deletions(-) > > -- > 1.8.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
On Wed, Jan 30, 2013 at 1:30 AM, Vikas Sajjan wrote: > This patch adds display-timing node parsing using video helper function > > Signed-off-by: Leela Krishna Amudala > Signed-off-by: Vikas Sajjan > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 > +++--- > 1 file changed, 35 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index bf0d9ba..94729ed 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device > *pdev) > struct exynos_drm_subdrv *subdrv; > struct exynos_drm_fimd_pdata *pdata; > struct exynos_drm_panel_info *panel; > + struct fb_videomode *fbmode; > + struct device *disp_dev = >dev; Isn't this the same as dev (maybe I'm missing some dependent patch)? > + struct pinctrl *pctrl; > struct resource *res; > int win; > int ret = -EINVAL; > > DRM_DEBUG_KMS("%s\n", __FILE__); > > - pdata = pdev->dev.platform_data; > - if (!pdata) { > - dev_err(dev, "no platform data specified\n"); > + if (pdev->dev.of_node) { > + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); > + if (!pdata) { > + DRM_ERROR("memory allocation for pdata failed\n"); > + return -ENOMEM; > + } > + > + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL); > + if (!fbmode) { > + DRM_ERROR("memory allocation for fbmode failed\n"); > + return -ENOMEM; > + } > + > + ret = of_get_fb_videomode(disp_dev->of_node, fbmode, -1); > + if (ret) { > + DRM_ERROR("failed to get fb_videomode\n"); > + return -EINVAL; > + } > + pdata->panel.timing = (struct fb_videomode) *fbmode; > + > + } else { > + pdata = pdev->dev.platform_data; > + if (!pdata) { > + DRM_ERROR("no platform data specified\n"); > + return -EINVAL; > + } > + } > + > + pctrl = devm_pinctrl_get_select_default(dev); > + if (IS_ERR(pctrl)) { Will this work for exynos5? AFAICT, there's no pinctrl setup for it. Sean > + DRM_ERROR("no pinctrl data provided.\n"); > return -EINVAL; > } > > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: > On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding > wrote: > > drm_events_release() should be enough to clean up the events, but I > > suspect the reason why Laurent put that code in was that the drm_crtc > > private data still has a reference to the event and needs to clear it. > > Otherwise the next page flip won't be scheduled because .page_flip() > > would return -EBUSY. > > Hm, indeed we seem to have a nice bug in most drivers there :( I think I may just recently have run into this bug on Intel hardware. Although perhaps I just used this wrongly. Just for the fun of it I wanted to implement Conway's Game of Life on top of DRM/KMS. So I use two dumb buffer objects to alternately render to. Then I wanted to use page-flipping to synchronize with VBLANK. So the sequence is basically: while (!done) { grid_tick(grid); grid_draw(grid, screen); screen_flip(screen); grid_swap(grid); } Where screen_flip() chooses the framebuffer and passes it to drmModePageFlip() like so: int fb = screen->fb[screen->current]; drmModePageFlip(screen->fd, screen->crtc, fb, DRM_MODE_PAGE_FLIP_EVENT, screen); This runs for about 3 seconds and then hangs, so the display is no longer updated. I've also verified that the same happens on Radeon. But maybe I am mistaken and this isn't the proper programming sequence? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/7794ee9c/attachment.pgp>
[PATCH] drm: avoid "mono_time_offset may be used uninitialized"
On 01/29/2013 05:09 PM, Stephen Warren wrote: > From: Stephen Warren > > Silence the following: > drivers/gpu/drm/drm_irq.c: In function > 'drm_calc_vbltimestamp_from_scanoutpos': > drivers/gpu/drm/drm_irq.c:583:24: warning: 'mono_time_offset.tv64' may be > used uninitialized in this function FYI, I found that I see this warning with gcc-4.5.3, but not with gcc-4.7.2 or gcc-4.6.3. Hence, you might decide you don't care about this patch.
[PATCH 4/5] drm/tegra: Implement VBLANK support
On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote: > On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding > wrote: > > Implement support for the VBLANK IOCTL. Note that Tegra is somewhat > > special in this case because it doesn't use the generic IRQ support > > provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one > > interrupt handler for each display controller. > > > > While at it, clean up the way that interrupts are enabled to ensure > > that the VBLANK interrupt only gets enabled when required. > > > > Signed-off-by: Thierry Reding > > --- > > Sorry Thierry, but is this a useful feature? Are applications really > making use of it? Because it means that that an IRQ will have to > trigger every 16.67ms when it is taken, which means the device can't > sleep. (probably OK because it should go back to idle when the app > lets go of the vblank). But worse, for one-shot panels there is no > continuous vblank. I've been doing weird hacks to run a timer when the > smart panel is idle to trick applications into thinking they have a > vblank pulse. But really I think the whole feature of a vblank pulse > is pretty lame and I wish it would die. Were you going to use it for > something specific, or just adding it for completeness? This is mainly added for completeness. I know that on Tegra we can do a lot better by using syncpoints, but applications such as Weston (in general applications that use the generic DRM API) rely on this to sync rendering with VBLANK. I don't think there's another way to achieve the same thing. And as you already mentioned, this is only enabled when an application actively uses it, in which case the device won't sleep anyway. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/988c0841/attachment.pgp>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #44 from Thomas Rohloff --- And it crashed again, too. :( -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/2afca0da/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #43 from Thomas Rohloff --- And again I was to fast with this. I started another game and the dmesg spam was there again. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/ac5e1c67/attachment.html>
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #42 from Thomas Rohloff --- I updated m kernel to 3.8-rc5 and mesa to http://cgit.freedesktop.org/mesa/mesa/commit/?id=952e6e9f3b0eb179f67345f00e5a7f1dbaa7bdd5 (can't go higher cause of https://bugs.freedesktop.org/show_bug.cgi?id=60038 ) + disabled huge pages in the kernel and now things are different. First of the message spam seems to be gone completely and second the GPU doesn't crash anymore. At one time the image froze but switching to console and back solved this. I'll look if it continues like that and later on re-enable huge pages to see what happens then. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130130/ea577b9a/attachment.html>
[PATCH 2/7] mutex: add support for reservation style locks
On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter wrote: > On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark wrote: >> == >> Basic problem statement: >> - --- - >> GPU's do operations that commonly involve many buffers. Those buffers >> can be shared across contexts/processes, exist in different memory >> domains (for example VRAM vs system memory), and so on. And with >> PRIME / dmabuf, they can even be shared across devices. So there are >> a handful of situations where the driver needs to wait for buffers to >> become ready. If you think about this in terms of waiting on a buffer >> mutex for it to become available, this presents a problem because >> there is no way to guarantee that buffers appear in a execbuf/batch in >> the same order in all contexts. That is directly under control of >> userspace, and a result of the sequence of GL calls that an >> application makes. Which results in the potential for deadlock. The >> problem gets more complex when you consider that the kernel may need >> to migrate the buffer(s) into VRAM before the GPU operates on the >> buffer(s), which main in turn require evicting some other buffers (and >> you don't want to evict other buffers which are already queued up to >> the GPU), but for a simplified understanding of the problem you can >> ignore this. >> >> The algorithm that TTM came up with for dealing with this problem is >> quite simple. For each group of buffers (execbuf) that need to be >> locked, the caller would be assigned a unique reservation_id, from a >> global counter. In case of deadlock in the process of locking all the >> buffers associated with a execbuf, the one with the lowest >> reservation_id wins, and the one with the higher reservation_id >> unlocks all of the buffers that it has already locked, and then tries >> again. >> >> Originally TTM implemented this algorithm on top of an event-queue and >> atomic-ops, but Maarten Lankhorst realized that by merging this with >> the mutex code we could take advantage of the existing mutex fast-path >> code and result in a simpler solution, and so ticket_mutex was born. >> (Well, there where also some additional complexities with the original >> implementation when you start adding in cross-device buffer sharing >> for PRIME.. Maarten could probably better explain.) > > I think the motivational writeup above is really nice, but the example > code below is a bit wrong > >> How it is used: >> --- -- -- - >> >> A very simplified version: >> >> int submit_execbuf(execbuf) >> { >> /* acquiring locks, before queuing up to GPU: */ >> seqno = assign_global_seqno(); >> retry: >> for (buf in execbuf->buffers) { >> ret = mutex_reserve_lock(>lock, seqno); >> switch (ret) { >> case 0: >> /* we got the lock */ >> break; >> case -EAGAIN: >> /* someone with a lower seqno, so unreserve and try again: */ >> for (buf2 in reverse order starting before buf in >> execbuf->buffers) >> mutex_unreserve_unlock(>lock); >> goto retry; >> default: >> goto err; >> } >> } >> >> /* now everything is good to go, submit job to GPU: */ >> ... >> } >> >> int finish_execbuf(execbuf) >> { >> /* when GPU is finished: */ >> for (buf in execbuf->buffers) >> mutex_unreserve_unlock(>lock); >> } >> == > > Since gpu command submission is all asnyc (hopefully at least) we > don't unlock once it completes, but right away after the commands are > submitted. Otherwise you wouldn't be able to submit new execbufs using > the same buffer objects (and besides, holding locks while going back > out to userspace is evil). right.. but I was trying to simplify the explanation for non-gpu folk.. maybe that was an over-simplification ;-) BR, -R > The trick is to add a fence object for async operation (essentially a > waitqueue on steriods to support gpu->gpu direct signalling). And > updating fences for a given execbuf needs to happen atomically for all > buffers, for otherwise userspace could trick the kernel into creating > a circular fence chain. This wouldn't deadlock the kernel, since > everything is async, but it'll nicely deadlock the gpus involved. > Hence why we need ticketing locks to get dma_buf fences off the > ground. > > Maybe wait for Maarten's feedback, then update your motivational blurb a bit? > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugzilla.kernel.org/show_bug.cgi?id=49981 D. Hugh Redelmeier changed: What|Removed |Added CC||hugh at mimosa.com --- Comment #5 from D. Hugh Redelmeier 2013-01-30 03:15:26 --- For what it is worth (probably not much), I'm getting this message on Fedora 17 x86-64 with all updates. Fedora kernel 3.7.3-101.fc17.x86_64. Standard Gnome desktop. The video card is an ATI Radeon HD 3600 XT Symptoms: - with a lot of windows on desktop, sometimes creating a new window yields an illegible window with horizontal striations. It doesn't exactly stay within boundaries but doesn't take over whole screen. - When I look at the dock (if that's what it is called in Gnome 3, the image of the application has striations too - dmesg shows: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! - /var/log/Xorg.0.log shows a bunch of messages like these: [ 97766.969] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x6e5f750] [ 97767.076] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x6e5f750] width 2560 pitch 10240 (/4 2560) [ 97773.012] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x97ce6d0] [ 97773.112] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x97ce6d0] width 2560 pitch 10240 (/4 2560) [ 97773.117] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0xb91b610] [ 97773.213] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0xb91b610] width 2560 pitch 10240 (/4 2560) [ 97773.217] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x6a33d50] [ 97773.313] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x6a33d50] width 2560 pitch 10240 (/4 2560) [ 97773.319] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0xb91b610] [ 97773.414] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0xb91b610] width 2560 pitch 10240 (/4 2560) [ 97773.420] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x97ce5b0] [ 97773.514] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x97ce5b0] width 2560 pitch 10240 (/4 2560) [ 9.063] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x928f370] [ 9.142] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x928f370] width 2560 pitch 10240 (/4 2560) [ 9.925] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x8be3b80] [ 9.945] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x8be3b80] width 2560 pitch 10240 (/4 2560) [ 97778.781] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x97d9520] [ 97778.798] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x97d9520] width 2560 pitch 10240 (/4 2560) [ 97780.516] (II) RADEON(0): radeon_dri2_schedule_flip:665 fevent[0x8bf1aa0] [ 97780.520] (II) RADEON(0): radeon_dri2_flip_event_handler:1069 fevent[0x8bf1aa0] width 2560 pitch 10240 (/4 2560) - I can close the window and get back to using the desktop. But once this has happened, it will happen again quite a lot. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board
https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #20 from Fernando Chaves 2013-01-30 02:08:38 --- Well... Same thing with EFI boot. Video still slow. I think I should use a VGA card for a while (or forever). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[git pull] drm fixes
Hi Linus, from LCA request, intel, radeon and exynos fixes, nothing too major or wierd, one dmar fix and a radeon cursor corruption, along with misc exynos fixes. Dave. The following changes since commit 014b34409fb2015f63663b6cafdf557fdf289628: ttm: on move memory failure don't leave a node dangling (2013-01-21 13:45:23 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 483674325f64a37c7696edb12ce6ad3e535421bc: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel (2013-01-26 18:17:39 +1000) Arnd Bergmann (2): drm/exynos: don't include plat/gpio-cfg.h drm/exynos: fimd and ipp are broken on multiplatform Chris Wilson (2): drm/i915: Disable AsyncFlip performance optimisations drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits Daniel Vetter (2): iommu/intel: disable DMAR for g4x integrated gfx drm/i915: dump UTS_RELEASE into the error_state Dave Airlie (3): Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-next Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel Ilija Hadzic (1): drm/radeon: fix a rare case of double kfree Inki Dae (2): drm/exynos: free sg object if dma_map_sg is failed drm/exynos: consider DMA_NONE flag to dmabuf import Jerome Glisse (1): drm/radeon: fix cursor corruption on DCE6 and newer Michel D?nzer (1): drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts. Rahul Sharma (1): drm/exynos: let drm handle edid allocations Sachin Kamat (4): drm/exynos: Make g2d_userptr_get_dma_addr static drm/exynos: Make ipp_handle_cmd_work static drm/exynos: Add missing static specifiers in exynos_drm_rotator.c drm/exynos: Make 'drm_hdmi_get_edid' static Sean Paul (2): drm/exynos: Replace mdelay with usleep_range drm/exynos: Remove "internal" interrupt handling Seung-Woo Kim (1): drm/exynos: added validation of edid for vidi connection Shirish S (1): drm/exynos: add check for the device power status xueminsu (1): radeon_display: Use pointer return error codes drivers/gpu/drm/exynos/Kconfig| 4 +- drivers/gpu/drm/exynos/exynos_drm_connector.c | 33 --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c| 24 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 4 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 26 +++--- drivers/gpu/drm/exynos/exynos_hdmi.c | 121 -- drivers/gpu/drm/exynos/exynos_mixer.c | 9 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 24 +++-- drivers/gpu/drm/radeon/ni.c | 8 +- drivers/gpu/drm/radeon/r600.c | 8 +- drivers/gpu/drm/radeon/radeon_cs.c| 2 + drivers/gpu/drm/radeon/radeon_cursor.c| 3 +- drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/iommu/intel-iommu.c | 21 +++-- 21 files changed, 155 insertions(+), 158 deletions(-)
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #42 from Thomas Rohloff v10la...@myway.de --- I updated m kernel to 3.8-rc5 and mesa to http://cgit.freedesktop.org/mesa/mesa/commit/?id=952e6e9f3b0eb179f67345f00e5a7f1dbaa7bdd5 (can't go higher cause of https://bugs.freedesktop.org/show_bug.cgi?id=60038 ) + disabled huge pages in the kernel and now things are different. First of the message spam seems to be gone completely and second the GPU doesn't crash anymore. At one time the image froze but switching to console and back solved this. I'll look if it continues like that and later on re-enable huge pages to see what happens then. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
2013/1/25 Sachin Kamat sachin.ka...@linaro.org: From: Ajay Kumar ajaykumar...@samsung.com This patch adds device tree match table for Exynos G2D controller. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c index ddcfb5d..d24b170 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c @@ -19,6 +19,7 @@ #include linux/workqueue.h #include linux/dma-mapping.h #include linux/dma-attrs.h +#include linux/of.h #include drm/drmP.h #include drm/exynos_drm.h @@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume); +#ifdef CONFIG_OF +static const struct of_device_id exynos_g2d_match[] = { + { .compatible = samsung,g2d-v41 }, not only Exynos5 and also Exyno4 has the g2d gpu and drm-based g2d driver shoud support for all Exynos SoCs. How about using samsung,exynos5-g2d instead and adding a new property 'version' to identify ip version more surely? With this, we could know which SoC and its g2d ip version. The version property could have '0x14' or others. And please add descriptions to dt document. + {}, +}; +MODULE_DEVICE_TABLE(of, exynos_g2d_match); +#endif + struct platform_driver g2d_driver = { .probe = g2d_probe, .remove = g2d_remove, @@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = { .name = s5p-g2d, .owner = THIS_MODULE, .pm = g2d_pm_ops, + .of_match_table = of_match_ptr(exynos_g2d_match), }, }; -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
A patch referencing this bug report has been merged...
Hi Florian, all - First, thanks for your work on adding the bugzilla comments when patches referencing bugs get merged. I find it useful. Recently however there was a comment about a commit referencing a commit referencing the bug report. Turns out the comment was missing one level of indirection, it was really about a commit referencing a commit referencing a commit referencing the bug [1]. Do we really need go that far, or is that a bug in your scripts? I think three levels of indirection is more noise than signal; two might be still be okay. What do others think? BR, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #43 from Thomas Rohloff v10la...@myway.de --- And again I was to fast with this. I started another game and the dmesg spam was there again. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.8-rc2: lockdep warning in nouveau driver
On Wed, 2013-01-09 at 12:45 +0100, Arend van Spriel wrote: Maybe this one is already known, but I did not find a post about it. So here it is. Regards, Arend [snip] [9.589986] = [9.595365] [ INFO: possible recursive locking detected ] [9.600745] 3.8.0-rc2-wl-testing-lockdep-2-ga524cf0 #1 Not tainted [9.607248] - [9.612626] modprobe/163 is trying to acquire lock: [9.617486] (subdev-mutex){+.+.+.}, at: [f8929c12] nv50_fb_vram_new+0x92/0x230 [nouveau] [9.626052] [9.626052] but task is already holding lock: [9.631865] (subdev-mutex){+.+.+.}, at: [f8936505] nv50_disp_data_ctor+0x55/0xc0 [nouveau] [9.640593] [9.640593] other info that might help us debug this: [9.647096] Possible unsafe locking scenario: [9.647096] [9.652995]CPU0 [9.655430] [9.657867] lock(subdev-mutex); [9.661365] lock(subdev-mutex); [9.664863] [9.664863] *** DEADLOCK *** [9.664863] [9.670762] May be due to missing lock nesting notation Same. [5.995881] = [5.995886] [ INFO: possible recursive locking detected ] [5.995892] 3.8.0-next-20130125+ttypatch-xeon+lockdep #20130125+ttypatch Not tainted [5.995898] - [5.995904] modprobe/275 is trying to acquire lock: [5.995909] (subdev-mutex){+.+.+.}, at: [a00d10b8] nouveau_instobj_create_+0x48/0x90 [nouveau] [5.995955] [5.995955] but task is already holding lock: [5.995961] (subdev-mutex){+.+.+.}, at: [a00da3b5] nv50_disp_data_ctor+0x65/0xd0 [nouveau] [5.995989] [5.995989] other info that might help us debug this: [5.995995] Possible unsafe locking scenario: [5.995995] [5.996001]CPU0 [5.996004] [5.996005] lock(subdev-mutex); [5.996005] lock(subdev-mutex); [5.996005] [5.996005] *** DEADLOCK *** Regards, Peter Hurley ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] x86, efi: remove attribute check from setup_efi_pci
On Tue, 2013-01-29 at 17:52 +0100, Maarten Lankhorst wrote: It looks like the original commit that copied the rom contents from efi always copied the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160 (x86, efi: correct precedence of operators in setup_efi_pci) broke that. This resulted in macbook pro's no longer finding the rom images, and thus not being able to use the radeon card any more. The solution is to just remove the check for now, and always copy the rom if available. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Applied, thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon modeset crashes on A4-3400 HD6410D
Hi, I have a A4-3400 CPU that I bought half a year ago. I've tried once month, but Fedora has never succeeded in booting in graphical mode. Some time ago a finally built some custom kernels to figure out why. I created a bug to Fedora bughttps://bugzilla.redhat.com/show_bug.cgi?id=892233, but it has not progressed. Analysis: The radeon module startup fails with division by zero in r6xx_remap_render_backend because the first RB is not enabled and the code assuming that enabled RBs must be all the first ones of the valid range. Longer version: In r600.c:r6xx_remap_render_backend The function contains only one divide: u32 r6xx_remap_render_backend(struct radeon_device *rdev, u32 tiling_pipe_num, u32 max_rb_num, u32 total_max_rb_num, u32 disabled_rb_mask) { u32 rendering_pipe_num, rb_num_width, req_rb_num; ... /* mask out the RBs that don't exist on that asic */ disabled_rb_mask |= (0xff max_rb_num) 0xff; rendering_pipe_num = 1 tiling_pipe_num; req_rb_num = total_max_rb_num - r600_count_pipe_bits(disabled_rb_mask); BUG_ON(rendering_pipe_num req_rb_num); pipe_rb_ratio = rendering_pipe_num / req_rb_num; I added a printk to see what actual parameters are passed in: tiling_pipe_num=2, max_rb_num=1, total_max_rb_num=8, disabled_rb_mask=253 Using those to calculate the divide by zero comes from: disabled_rb_mask |= 254; - 255 req_rb_num = 8 - 8; Quick fix for stable kernel series: The attached fix activates only in the division by zero case and instead of failing uses the given disabled_rb_mask. This is guaranteed to be regression free and actually allows me to load the radeon driver successfully. It does help with cards that currently work, but for which some usable RBs are disabled due to the eager masking. Proper fix would propably be to find out think why the disabled_rb_mask is masked the way it is, were there bugs in other places for which it is a workaround. I can see two possible modifictions: 1) only mask bits exceeding total_max_rb_num instead of the max_rb_numsince the one enabled RB on A4-3400 can propably be any one of the 8 possible values. 2) or activate the current code only if there are more than max_rb_num zero bits in the given disabled_rb_mask -Mikko r600-division-by-zero.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos: Get HDMI version from device tree
Hi, On 01/08/2013 11:56 PM, Stephen Warren wrote: On 01/08/2013 01:16 PM, Sean Paul wrote: Add a property to the hdmi node so we can specify the HDMI version in the device tree instead of just defaulting to v1.4 with the existence of the dt node. I guess this seems OK to me if required, although I'd certainly like to see someone familiar with the Exynos HW confirm whether this should be driven purely by DT compatible value for the HDMI IP block instead though. I think the supported HDMI standard is something that could well be derived from the compatible property. The IP supporting v1.3 and v1.4 will be significantly different, so this would anyway already need to be reflected in the compatible property. The only issue I see here is that people tend to make the compatible string overly generic, so it is hardly usable for anything but matching an IP with its driver. For instance for exynos5 we have now (Documentation/devicetree/bindings/drm/exynos/hdmi.txt): compatible = samsung,exynos5-hdmi; For Exynos4 series there were already some patches proposed [1], but I believe this isn't a clean solution. Instead of things like: compatible = samsung,exynos4-hdmi13; compatible = samsung,exynos4-hdmi14; I would much more like to see the SoC version embedded in the compatible string, e.g. compatible = samsung,exynos4210-hdmi; /* among others it carries an information this IP supports HDMI v1.3 */ compatible = samsung,exynos4212-hdmi; /* HDMI v1.4, IIRC */ [1] http://www.spinics.net/lists/linux-samsung-soc/msg15289.html -- Thanks, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd
This patch adds display-timing node parsing to drm fimd, this depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. patch is based on branch exynos-drm-next at http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Is tested on Exynos5250 and Exynos4412 by applying dependent patches available at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html Vikas Sajjan (1): video: drm: exynos: Adds display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
This patch adds display-timing node parsing using video helper function Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index bf0d9ba..94729ed 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -19,6 +19,7 @@ #include linux/clk.h #include linux/of_device.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h #include video/samsung_fimd.h #include drm/exynos_drm.h @@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device *pdev) struct exynos_drm_subdrv *subdrv; struct exynos_drm_fimd_pdata *pdata; struct exynos_drm_panel_info *panel; + struct fb_videomode *fbmode; + struct device *disp_dev = pdev-dev; + struct pinctrl *pctrl; struct resource *res; int win; int ret = -EINVAL; DRM_DEBUG_KMS(%s\n, __FILE__); - pdata = pdev-dev.platform_data; - if (!pdata) { - dev_err(dev, no platform data specified\n); + if (pdev-dev.of_node) { + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) { + DRM_ERROR(memory allocation for pdata failed\n); + return -ENOMEM; + } + + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL); + if (!fbmode) { + DRM_ERROR(memory allocation for fbmode failed\n); + return -ENOMEM; + } + + ret = of_get_fb_videomode(disp_dev-of_node, fbmode, -1); + if (ret) { + DRM_ERROR(failed to get fb_videomode\n); + return -EINVAL; + } + pdata-panel.timing = (struct fb_videomode) *fbmode; + + } else { + pdata = pdev-dev.platform_data; + if (!pdata) { + DRM_ERROR(no platform data specified\n); + return -EINVAL; + } + } + + pctrl = devm_pinctrl_get_select_default(dev); + if (IS_ERR(pctrl)) { + DRM_ERROR(no pinctrl data provided.\n); return -EINVAL; } -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/1] Adds display-timing node parsing to exynos drm fimd
Hi Vikas, Changelog mentioning differences between v1 and v2 is generally preferred as it will help the reviewers. On 30 January 2013 12:00, Vikas Sajjan vikas.saj...@linaro.org wrote: This patch adds display-timing node parsing to drm fimd, this depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. patch is based on branch exynos-drm-next at http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Is tested on Exynos5250 and Exynos4412 by applying dependent patches available at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html Vikas Sajjan (1): video: drm: exynos: Adds display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- With warm regards, Sachin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #44 from Thomas Rohloff v10la...@myway.de --- And it crashed again, too. :( -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding thierry.red...@avionic-design.de wrote: drm_events_release() should be enough to clean up the events, but I suspect the reason why Laurent put that code in was that the drm_crtc private data still has a reference to the event and needs to clear it. Otherwise the next page flip won't be scheduled because .page_flip() would return -EBUSY. Hm, indeed we seem to have a nice bug in most drivers there :( I think I may just recently have run into this bug on Intel hardware. Although perhaps I just used this wrongly. Just for the fun of it I wanted to implement Conway's Game of Life on top of DRM/KMS. So I use two dumb buffer objects to alternately render to. Then I wanted to use page-flipping to synchronize with VBLANK. So the sequence is basically: while (!done) { grid_tick(grid); grid_draw(grid, screen); screen_flip(screen); grid_swap(grid); } Where screen_flip() chooses the framebuffer and passes it to drmModePageFlip() like so: int fb = screen-fb[screen-current]; drmModePageFlip(screen-fd, screen-crtc, fb, DRM_MODE_PAGE_FLIP_EVENT, screen); This runs for about 3 seconds and then hangs, so the display is no longer updated. I've also verified that the same happens on Radeon. But maybe I am mistaken and this isn't the proper programming sequence? Thierry pgpSsVy333CT_.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote: On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding thierry.red...@avionic-design.de wrote: drm_events_release() should be enough to clean up the events, but I suspect the reason why Laurent put that code in was that the drm_crtc private data still has a reference to the event and needs to clear it. Otherwise the next page flip won't be scheduled because .page_flip() would return -EBUSY. Hm, indeed we seem to have a nice bug in most drivers there :( I think I may just recently have run into this bug on Intel hardware. Although perhaps I just used this wrongly. Just for the fun of it I wanted to implement Conway's Game of Life on top of DRM/KMS. So I use two dumb buffer objects to alternately render to. Then I wanted to use page-flipping to synchronize with VBLANK. So the sequence is basically: while (!done) { grid_tick(grid); grid_draw(grid, screen); screen_flip(screen); grid_swap(grid); } Where screen_flip() chooses the framebuffer and passes it to drmModePageFlip() like so: int fb = screen-fb[screen-current]; drmModePageFlip(screen-fd, screen-crtc, fb, DRM_MODE_PAGE_FLIP_EVENT, screen); This runs for about 3 seconds and then hangs, so the display is no longer updated. I've also verified that the same happens on Radeon. But maybe I am mistaken and this isn't the proper programming sequence? You asked for page flip events. Do you actually handle them in your code? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] mutex: add support for reservation style locks
On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark robdcl...@gmail.com wrote: == Basic problem statement: - --- - GPU's do operations that commonly involve many buffers. Those buffers can be shared across contexts/processes, exist in different memory domains (for example VRAM vs system memory), and so on. And with PRIME / dmabuf, they can even be shared across devices. So there are a handful of situations where the driver needs to wait for buffers to become ready. If you think about this in terms of waiting on a buffer mutex for it to become available, this presents a problem because there is no way to guarantee that buffers appear in a execbuf/batch in the same order in all contexts. That is directly under control of userspace, and a result of the sequence of GL calls that an application makes. Which results in the potential for deadlock. The problem gets more complex when you consider that the kernel may need to migrate the buffer(s) into VRAM before the GPU operates on the buffer(s), which main in turn require evicting some other buffers (and you don't want to evict other buffers which are already queued up to the GPU), but for a simplified understanding of the problem you can ignore this. The algorithm that TTM came up with for dealing with this problem is quite simple. For each group of buffers (execbuf) that need to be locked, the caller would be assigned a unique reservation_id, from a global counter. In case of deadlock in the process of locking all the buffers associated with a execbuf, the one with the lowest reservation_id wins, and the one with the higher reservation_id unlocks all of the buffers that it has already locked, and then tries again. Originally TTM implemented this algorithm on top of an event-queue and atomic-ops, but Maarten Lankhorst realized that by merging this with the mutex code we could take advantage of the existing mutex fast-path code and result in a simpler solution, and so ticket_mutex was born. (Well, there where also some additional complexities with the original implementation when you start adding in cross-device buffer sharing for PRIME.. Maarten could probably better explain.) I think the motivational writeup above is really nice, but the example code below is a bit wrong How it is used: --- -- -- - A very simplified version: int submit_execbuf(execbuf) { /* acquiring locks, before queuing up to GPU: */ seqno = assign_global_seqno(); retry: for (buf in execbuf-buffers) { ret = mutex_reserve_lock(buf-lock, seqno); switch (ret) { case 0: /* we got the lock */ break; case -EAGAIN: /* someone with a lower seqno, so unreserve and try again: */ for (buf2 in reverse order starting before buf in execbuf-buffers) mutex_unreserve_unlock(buf2-lock); goto retry; default: goto err; } } /* now everything is good to go, submit job to GPU: */ ... } int finish_execbuf(execbuf) { /* when GPU is finished: */ for (buf in execbuf-buffers) mutex_unreserve_unlock(buf-lock); } == Since gpu command submission is all asnyc (hopefully at least) we don't unlock once it completes, but right away after the commands are submitted. Otherwise you wouldn't be able to submit new execbufs using the same buffer objects (and besides, holding locks while going back out to userspace is evil). The trick is to add a fence object for async operation (essentially a waitqueue on steriods to support gpu-gpu direct signalling). And updating fences for a given execbuf needs to happen atomically for all buffers, for otherwise userspace could trick the kernel into creating a circular fence chain. This wouldn't deadlock the kernel, since everything is async, but it'll nicely deadlock the gpus involved. Hence why we need ticketing locks to get dma_buf fences off the ground. Maybe wait for Maarten's feedback, then update your motivational blurb a bit? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrjälä wrote: On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote: On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding thierry.red...@avionic-design.de wrote: drm_events_release() should be enough to clean up the events, but I suspect the reason why Laurent put that code in was that the drm_crtc private data still has a reference to the event and needs to clear it. Otherwise the next page flip won't be scheduled because .page_flip() would return -EBUSY. Hm, indeed we seem to have a nice bug in most drivers there :( I think I may just recently have run into this bug on Intel hardware. Although perhaps I just used this wrongly. Just for the fun of it I wanted to implement Conway's Game of Life on top of DRM/KMS. So I use two dumb buffer objects to alternately render to. Then I wanted to use page-flipping to synchronize with VBLANK. So the sequence is basically: while (!done) { grid_tick(grid); grid_draw(grid, screen); screen_flip(screen); grid_swap(grid); } Where screen_flip() chooses the framebuffer and passes it to drmModePageFlip() like so: int fb = screen-fb[screen-current]; drmModePageFlip(screen-fd, screen-crtc, fb, DRM_MODE_PAGE_FLIP_EVENT, screen); This runs for about 3 seconds and then hangs, so the display is no longer updated. I've also verified that the same happens on Radeon. But maybe I am mistaken and this isn't the proper programming sequence? You asked for page flip events. Do you actually handle them in your code? Duh. No I wasn't =) I suppose some queue must be running full if the event isn't handled by calling drmHandleEvent(). Okay, this now works properly with page-flipping. Thanks. Thierry pgphCMXmEGqmv.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] mutex: add support for reservation style locks
Op 30-01-13 02:07, Rob Clark schreef: On Tue, Jan 15, 2013 at 6:33 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Hi Maarten, This is a nice looking extension to avoid re-implementing a mutex in TTM/reservation code.. ofc, probably someone more familiar with mutex code should probably review, but probably a bit of explanation about what and why would be helpful. mutex_reserve_lock, and mutex_reserve_lock_interruptible: Lock a buffer with a reservation_id set. reservation_id must not be set to 0, since this is a special value that means no reservation_id. Normally if reservation_id is not set, or is older than the reservation_id that's currently set on the mutex, the behavior will be to wait normally. However, if the reservation_id is newer than the current reservation_id, -EAGAIN will be returned, and this function must unreserve all other mutexes and then redo a blocking lock with normal mutex calls to prevent a deadlock, then call mutex_locked_set_reservation on successful locking to set the reservation_id inside the lock. It might be a bit more clear to write up how this works from the perspective of the user of ticket_mutex, separately from the internal implementation first, and then how it works internally? Ie, the mutex_set_reservation_fastpath() call is internal to the implementation of ticket_mutex, but -EAGAIN is something the caller of ticket_mutex shall deal with. This might give a clearer picture of how TTM / reservation uses this to prevent deadlock, so those less familiar with TTM could better understand. Well, here is an attempt to start a write-up, which should perhaps eventually be folded into Documentation/ticket-mutex-design.txt. But hopefully a better explanation of the problem and the solution will encourage some review of the ticket_mutex changes. == Basic problem statement: - --- - GPU's do operations that commonly involve many buffers. Those buffers can be shared across contexts/processes, exist in different memory domains (for example VRAM vs system memory), and so on. And with PRIME / dmabuf, they can even be shared across devices. So there are a handful of situations where the driver needs to wait for buffers to become ready. If you think about this in terms of waiting on a buffer mutex for it to become available, this presents a problem because there is no way to guarantee that buffers appear in a execbuf/batch in the same order in all contexts. That is directly under control of userspace, and a result of the sequence of GL calls that an application makes. Which results in the potential for deadlock. The problem gets more complex when you consider that the kernel may need to migrate the buffer(s) into VRAM before the GPU operates on the buffer(s), which main in turn require evicting some other buffers (and you don't want to evict other buffers which are already queued up to the GPU), but for a simplified understanding of the problem you can ignore this. The algorithm that TTM came up with for dealing with this problem is quite simple. For each group of buffers (execbuf) that need to be locked, the caller would be assigned a unique reservation_id, from a global counter. In case of deadlock in the process of locking all the buffers associated with a execbuf, the one with the lowest reservation_id wins, and the one with the higher reservation_id unlocks all of the buffers that it has already locked, and then tries again. Originally TTM implemented this algorithm on top of an event-queue and atomic-ops, but Maarten Lankhorst realized that by merging this with the mutex code we could take advantage of the existing mutex fast-path code and result in a simpler solution, and so ticket_mutex was born. (Well, there where also some additional complexities with the original implementation when you start adding in cross-device buffer sharing for PRIME.. Maarten could probably better explain.) How it is used: --- -- -- - A very simplified version: int submit_execbuf(execbuf) { /* acquiring locks, before queuing up to GPU: */ seqno = assign_global_seqno(); You also need to make a 'lock' type for seqno, and lock it for lockdep purposes. This will be a virtual lock that will only exist in lockdep, but it's needed for proper lockdep annotation. See reservation_ticket_init/fini. It's also important that seqno must not be 0, ever. retry: for (buf in execbuf-buffers) { ret = mutex_reserve_lock(buf-lock, seqno); The lockdep class for this lock must be the same for all reservations, and for maximum lockdep usability you want all the buf-lock lockdep class for all objects across all devices to be the same too. The __ticket_mutex_init in reservation_object_init does just that for you. :-) switch (ret) { case 0: /* we got the lock */
Re: [PATCH 5/5] drm/tegra: Implement page-flipping support
On Wed, Jan 30, 2013 at 12:14:36PM +0100, Thierry Reding wrote: On Wed, Jan 30, 2013 at 11:42:40AM +0200, Ville Syrjälä wrote: On Wed, Jan 30, 2013 at 10:32:47AM +0100, Thierry Reding wrote: On Wed, Jan 16, 2013 at 01:36:17PM +0100, Daniel Vetter wrote: On Wed, Jan 16, 2013 at 11:01 AM, Thierry Reding thierry.red...@avionic-design.de wrote: drm_events_release() should be enough to clean up the events, but I suspect the reason why Laurent put that code in was that the drm_crtc private data still has a reference to the event and needs to clear it. Otherwise the next page flip won't be scheduled because .page_flip() would return -EBUSY. Hm, indeed we seem to have a nice bug in most drivers there :( I think I may just recently have run into this bug on Intel hardware. Although perhaps I just used this wrongly. Just for the fun of it I wanted to implement Conway's Game of Life on top of DRM/KMS. So I use two dumb buffer objects to alternately render to. Then I wanted to use page-flipping to synchronize with VBLANK. So the sequence is basically: while (!done) { grid_tick(grid); grid_draw(grid, screen); screen_flip(screen); grid_swap(grid); } Where screen_flip() chooses the framebuffer and passes it to drmModePageFlip() like so: int fb = screen-fb[screen-current]; drmModePageFlip(screen-fd, screen-crtc, fb, DRM_MODE_PAGE_FLIP_EVENT, screen); This runs for about 3 seconds and then hangs, so the display is no longer updated. I've also verified that the same happens on Radeon. But maybe I am mistaken and this isn't the proper programming sequence? You asked for page flip events. Do you actually handle them in your code? Duh. No I wasn't =) I suppose some queue must be running full if the event isn't handled by calling drmHandleEvent(). Okay, this now works properly with page-flipping. Just in case anybody's interested, the code is here: https://gitorious.org/thierryreding/kmslife Thierry pgp1HxCZd4c51.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] mutex: add support for reservation style locks
On Wed, Jan 30, 2013 at 5:08 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jan 30, 2013 at 2:07 AM, Rob Clark robdcl...@gmail.com wrote: == Basic problem statement: - --- - GPU's do operations that commonly involve many buffers. Those buffers can be shared across contexts/processes, exist in different memory domains (for example VRAM vs system memory), and so on. And with PRIME / dmabuf, they can even be shared across devices. So there are a handful of situations where the driver needs to wait for buffers to become ready. If you think about this in terms of waiting on a buffer mutex for it to become available, this presents a problem because there is no way to guarantee that buffers appear in a execbuf/batch in the same order in all contexts. That is directly under control of userspace, and a result of the sequence of GL calls that an application makes. Which results in the potential for deadlock. The problem gets more complex when you consider that the kernel may need to migrate the buffer(s) into VRAM before the GPU operates on the buffer(s), which main in turn require evicting some other buffers (and you don't want to evict other buffers which are already queued up to the GPU), but for a simplified understanding of the problem you can ignore this. The algorithm that TTM came up with for dealing with this problem is quite simple. For each group of buffers (execbuf) that need to be locked, the caller would be assigned a unique reservation_id, from a global counter. In case of deadlock in the process of locking all the buffers associated with a execbuf, the one with the lowest reservation_id wins, and the one with the higher reservation_id unlocks all of the buffers that it has already locked, and then tries again. Originally TTM implemented this algorithm on top of an event-queue and atomic-ops, but Maarten Lankhorst realized that by merging this with the mutex code we could take advantage of the existing mutex fast-path code and result in a simpler solution, and so ticket_mutex was born. (Well, there where also some additional complexities with the original implementation when you start adding in cross-device buffer sharing for PRIME.. Maarten could probably better explain.) I think the motivational writeup above is really nice, but the example code below is a bit wrong How it is used: --- -- -- - A very simplified version: int submit_execbuf(execbuf) { /* acquiring locks, before queuing up to GPU: */ seqno = assign_global_seqno(); retry: for (buf in execbuf-buffers) { ret = mutex_reserve_lock(buf-lock, seqno); switch (ret) { case 0: /* we got the lock */ break; case -EAGAIN: /* someone with a lower seqno, so unreserve and try again: */ for (buf2 in reverse order starting before buf in execbuf-buffers) mutex_unreserve_unlock(buf2-lock); goto retry; default: goto err; } } /* now everything is good to go, submit job to GPU: */ ... } int finish_execbuf(execbuf) { /* when GPU is finished: */ for (buf in execbuf-buffers) mutex_unreserve_unlock(buf-lock); } == Since gpu command submission is all asnyc (hopefully at least) we don't unlock once it completes, but right away after the commands are submitted. Otherwise you wouldn't be able to submit new execbufs using the same buffer objects (and besides, holding locks while going back out to userspace is evil). right.. but I was trying to simplify the explanation for non-gpu folk.. maybe that was an over-simplification ;-) BR, -R The trick is to add a fence object for async operation (essentially a waitqueue on steriods to support gpu-gpu direct signalling). And updating fences for a given execbuf needs to happen atomically for all buffers, for otherwise userspace could trick the kernel into creating a circular fence chain. This wouldn't deadlock the kernel, since everything is async, but it'll nicely deadlock the gpus involved. Hence why we need ticketing locks to get dma_buf fences off the ground. Maybe wait for Maarten's feedback, then update your motivational blurb a bit? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] fbcon locking fixes.
On Mon, Jan 28, 2013 at 1:45 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: There was a path going into set_con2fb_path if an fb driver was already registered, I just pushed the locking out further on anyone going in there. it boots on my EFI macbook here. I cherry picked those patches to my tree, and the full series no longer triggers a lockdep warning. It also no longer locks up during modprobing or vga-switcheroo either. Tested-by: Maarten Lankhorst maarten.lankho...@canonical.com QA reported spurious failures in some kms_flip tests and lockdep splats, somehow both are fixed with the locking. I'm a bit confused how these issues could cause failures in the flip tests, but alas: Tested-by: Lu Hua huax...@intel.com (for all three patches). -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/tegra: Implement VBLANK support
On Wed, Jan 30, 2013 at 9:34 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote: On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding thierry.red...@avionic-design.de wrote: Implement support for the VBLANK IOCTL. Note that Tegra is somewhat special in this case because it doesn't use the generic IRQ support provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one interrupt handler for each display controller. While at it, clean up the way that interrupts are enabled to ensure that the VBLANK interrupt only gets enabled when required. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Sorry Thierry, but is this a useful feature? Are applications really making use of it? Because it means that that an IRQ will have to trigger every 16.67ms when it is taken, which means the device can't sleep. (probably OK because it should go back to idle when the app lets go of the vblank). But worse, for one-shot panels there is no continuous vblank. I've been doing weird hacks to run a timer when the smart panel is idle to trick applications into thinking they have a vblank pulse. But really I think the whole feature of a vblank pulse is pretty lame and I wish it would die. Were you going to use it for something specific, or just adding it for completeness? This is mainly added for completeness. I know that on Tegra we can do a lot better by using syncpoints, but applications such as Weston (in general applications that use the generic DRM API) rely on this to sync rendering with VBLANK. I don't think there's another way to achieve the same thing. And as you already mentioned, this is only enabled when an application actively uses it, in which case the device won't sleep anyway. I think driving animations with the vblank signal is nice, but we kinda only need that with the pageflip support. Unfortunately the current drm code is a bit a mess in that area, so pageflips force you to enable the vblank interrupt for otherwise the timestamp'ed pageflip completion events won't work. Recent intel hw has pageflip timestamp registers, so we don't really need that. And I guess other hw is similar. So we probably should clean up and untangle the infrastructure a bit around the drm vblank support code. Another issue is that the vblank ioctl itself doesn't deal with modeset crtc ids, so adding a new interface for that would be good. Otoh most kms clients don't really use it, but only care about pageflips. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=60028 --- Comment #8 from Dave Witbrodt dawit...@sbcglobal.net --- (In reply to comment #7) This is indeed more likely an issue in Mesa than in the kernel. The commit you bisected also bumps KMS_DRIVER_MINOR in radeon_drv.c, which may cause the Mesa code to use different code paths. In my two attempted manual reverts, I didn't know what effect the code in radeon_drv.c actually had. When looking at later DRM changes (after the one identified by the bisection) I saw that the value of KMS_DRIVER_MINOR was incremented further, so I thought I should leave the value unchanged. Does current Mesa Git still leak? After updating/merging to the current HEAD (commit 02b6da1e of Jan. 29), I built new Mesa packages and installed them. I am currently relying the last kernel from my local tree which does not leak, so I rebooted to the kernel I had built that is most current with the upstream DRM changes: stable 3.7.4 + many commits from drm-next/drm-fixes up to commit 014b3440 of Jan. 21 in drm-fixes. Yes, it still leaks. Would it be good for me to bisect Mesa? I would use my most up-to-date kernel, try to find an older version of Mesa which does not leak, and then identify the first patch to Mesa which causes the leaking. The testing I have done so far was assuming the problem was in the kernel, but I was planning to look at Mesa as well. I decided to report the bug before continuing, hoping for some guidance from the experts. If there really is a memory leak caused by the kernel DRI, then I would like to help get it fixed before 3.8 is released; or, if there is a problem in Mesa I would like to help get it fixed for 9.1. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60073] New: [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 Priority: medium Bug ID: 60073 Assignee: dri-devel@lists.freedesktop.org Summary: [bisected] Bad rendering in Path of Exile Severity: normal Classification: Unclassified OS: Linux (All) Reporter: nissa...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Hardware: Radeon 6850 Software: 64bit Gentoo, game running via Wine (32bit), git versions of libdrm, xf86-video-ati, kernel version 3.7(ish) and latest 3.8 rc + drm-next branch The issue is affecting light effects, spell effects, etc. (see screenshots). Bisecting leads to this commit: commit 3b51d71c8544ee198008bbf3545bf3def6e9e77f Author: Jordan Justen jordan.l.jus...@intel.com Date: Fri Dec 28 11:00:50 2012 -0800 copyteximage: check that sRGB usage is valid for GLES3 / GL Reviewed-by: Ian Romanick ian.d.roman...@intel.com Signed-off-by: Jordan Justen jordan.l.jus...@intel.com There is already one bug report mentioning this commit [1], not sure if it's the same issue. Besides PoE, I also encontered similar problem in StarCraft2, I didn't checked if it's the same problem, text/fonts on the loading screen shows the same corruption, however the game also hangs the GPU, so bisecting it might be a bit problematic. [1] https://bugs.freedesktop.org/show_bug.cgi?id=59690 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #1 from Wojciech Pyczak nissa...@gmail.com --- Created attachment 73926 -- https://bugs.freedesktop.org/attachment.cgi?id=73926action=edit Login screen -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #2 from Wojciech Pyczak nissa...@gmail.com --- Created attachment 73927 -- https://bugs.freedesktop.org/attachment.cgi?id=73927action=edit Login screen (bad rendering) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #3 from Wojciech Pyczak nissa...@gmail.com --- Created attachment 73928 -- https://bugs.freedesktop.org/attachment.cgi?id=73928action=edit In-game screenshot -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=60028 --- Comment #9 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #8) Would it be good for me to bisect Mesa? If Mesa commit 6532eb17baff6e61b427f29e076883f8941ae664 (where code depending on DRM minor 26 was first introduced) doesn't leak, yes please. BTW, does setting the environment variable R600_HYPERZ=0 for the leaking process(es) work around the problem? The testing I have done so far was assuming the problem was in the kernel, [...] The fact that the memory is reclaimed on process exit makes that unlikely. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/4] Common Display Framework-TF
Hi, After pretty long time of trying to adapt Exynos-specific DSI display support to Common Display Framework I'm ready to show some preliminary RFC patches. This series shows some ideas for CDF that came to my mind during my work, some changes based on comments received by Tomi's edition of CDF and also preliminarys version of Exynos DSI (video source part only, still with some FIXMEs) and Samsung S6E8AX0 DSI panel drivers. It is heavily based on Tomi's work which can be found here: http://thread.gmane.org/gmane.comp.video.dri.devel/78227 The code might be a bit hacky in places, as I wanted to get it to a kind of complete and working state first. However I hope that some of the ideas might useful for further works. So, here comes the TF edition of Common Clock Framework. Changes done to Tomi's edition of CDF: - Replaced set_operation_mode, set_pixel_format and set_size video source operations with get_params display entity operation, as it was originally in Laurent's version. We have discussed this matter on the mailing list and decided that it would be better to have the source ask the sink for its parameter structure and do whatever appropriate with it. - Defined a preliminary set of DSI bus parameters. Following parameters are defined: 1. Pixel format used for video data transmission. 2. Mode flags (several bit flags ORed together): a) DSI_MODE_VIDEO - entity uses video mode (as opposed to command mode), following DSI_MODE_VIDEO_* flags are relevant only if this flag is set. b) DSI_MODE_VIDEO_BURST - entity uses burst transfer for video data c) DSI_MODE_VIDEO_SYNC_PULSE - entity uses sync pulses (as opposed to sync events) d) DSI_MODE_VIDEO_AUTO_VERT - entity uses automatic video mode detection e) DSI_MODE_VIDEO_HSE - entity needs horizontal sync end packets f) DSI_MODE_VIDEO_HFP - entity needs horizontal front porch area g) DSI_MODE_VIDEO_HBP - entity needs horizontal back porch area h) DSI_MODE_VIDEO_HSA - entity needs horizontal sync active area i) DSI_MODE_VSYNC_FLUSH - vertical sync pulse flushes video data j) DSI_MODE_EOT_PACKET - entity needs EoT packets 3. Bit (serial) clock frequency in HS mode. 4. Escape mode clock frequency. 5. Mask of used data lanes (each bit represents single lane). 6. Command allow area in video mode - amount of lines after transmitting video data when generic commands are accepted. Feel free to suggest anything missing or wrong, as the list of parameters is based merely on what was used in original Exynos MIPI DSIM driver. - Redesigned source-entity matching. Now each source has name string and integer id and each entity has source name and source id. In addition, they can have of_node specified, which is used for Device Tree-based matching. The matching procedure is as follows: 1. Matching takes place when display entity registers. a) If there is of_node specified for the entity then video-source phandle of this node is being parsed and list of registered sources is traversed in search of a source with of_node received from parsing the phandle. b) Otherwise the matching key is a pair of source name and id. 2. If no matching source is found, display_entity_register returns -EPROBE_DEFER error which causes the entity driver to defer its probe until the source registers. 3. Otherwise an optional bind operation of video source is called, sink field of source and source field of entity are set and the matching ends successfully. - Some initial concept of source-entity cross-locking. Only video source is protected at the moment, as I still have to think a bit about locking the entity in a way where removing it by user request is still possible. - Dropped any panels and chips that I can't test. They are irrelevant for this series, so there is no point in including them. - Added Exynos DSI video source driver. This is a new driver for the DSI controller found in Exynos SoCs. It still needs some work, but in current state can be considered an example of DSI video source implementation for my version of CDF. - Added Samsung S6E8AX0 DSI panel driver. This is the old Exynos-specific driver, just migrated to CDF and with some hacks to provide control over entity state to userspace using lcd device. However it can be used to demonstrate video source ops in use. Feel free to comment as much as you can. Tomasz Figa (4): video: add display-core video: add makefile kconfig video: display: Add exynos-dsi video source driver video: display: Add Samsung s6e8ax0 display panel driver drivers/video/Kconfig |1 + drivers/video/Makefile|1 + drivers/video/display/Kconfig | 16 +
[RFC PATCH 3/4] video: display: Add exynos-dsi video source driver
This patch adds new driver for DSI master block available in Samsung Exynos SoCs. The driver is designed and written specifically for Common Display Framework. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/video/display/Kconfig |3 + drivers/video/display/Makefile|1 + drivers/video/display/source-exynos_dsi.c | 1313 + include/video/exynos_dsi.h| 41 + 4 files changed, 1358 insertions(+) create mode 100644 drivers/video/display/source-exynos_dsi.c create mode 100644 include/video/exynos_dsi.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 477192d..b14527a 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -6,5 +6,8 @@ menuconfig DISPLAY_CORE if DISPLAY_CORE +config DISPLAY_SOURCE_EXYNOS_DSI + tristate Samsung SoC MIPI DSI Master + endif # DISPLAY_CORE diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index bd93496..40a283a 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o +obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o diff --git a/drivers/video/display/source-exynos_dsi.c b/drivers/video/display/source-exynos_dsi.c new file mode 100644 index 000..30b15bf --- /dev/null +++ b/drivers/video/display/source-exynos_dsi.c @@ -0,0 +1,1313 @@ +/* + * Samsung SoC MIPI DSI Master driver. + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd + * + * Contacts: Tomasz Figa t.f...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include linux/clk.h +#include linux/completion.h +#include linux/delay.h +#include linux/errno.h +#include linux/fb.h +#include linux/interrupt.h +#include linux/io.h +#include linux/irq.h +#include linux/kernel.h +#include linux/list.h +#include linux/memory.h +#include linux/mm.h +#include linux/module.h +#include linux/of.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/regulator/consumer.h +#include linux/spinlock.h +#include linux/videomode.h +#include linux/wait.h + +#include video/display.h +#include video/exynos_dsi.h +#include video/mipi_display.h + +#define DSIM_STATUS_REG0x0 /* Status register */ +#define DSIM_SWRST_REG 0x4 /* Software reset register */ +#define DSIM_CLKCTRL_REG 0x8 /* Clock control register */ +#define DSIM_TIMEOUT_REG 0xc /* Time out register */ +#define DSIM_CONFIG_REG0x10/* Configuration register */ +#define DSIM_ESCMODE_REG 0x14/* Escape mode register */ + +/* Main display image resolution register */ +#define DSIM_MDRESOL_REG 0x18 +#define DSIM_MVPORCH_REG 0x1c/* Main display Vporch register */ +#define DSIM_MHPORCH_REG 0x20/* Main display Hporch register */ +#define DSIM_MSYNC_REG 0x24/* Main display sync area register */ + +/* Sub display image resolution register */ +#define DSIM_SDRESOL_REG 0x28 +#define DSIM_INTSRC_REG0x2c/* Interrupt source register */ +#define DSIM_INTMSK_REG0x30/* Interrupt mask register */ +#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register */ +#define DSIM_PAYLOAD_REG 0x38/* Payload FIFO register */ +#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */ +#define DSIM_FIFOTHLD_REG 0x40/* FIFO threshold level register */ +#define DSIM_FIFOCTRL_REG 0x44/* FIFO status and control register */ + +/* FIFO memory AC characteristic register */ +#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */ +#define DSIM_PLLTMR_REG0x50/* PLL timer register */ +#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */ +#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */ + +/* DSIM_STATUS */ +#define DSIM_STOP_STATE_DAT(x) (((x) 0xf) 0) +#define DSIM_STOP_STATE_CLK(1 8) +#define DSIM_TX_READY_HS_CLK (1 10) +#define DSIM_PLL_STABLE(1 31) + +/* DSIM_SWRST */ +#define DSIM_FUNCRST (1 16) +#define DSIM_SWRST (1 0) + +/* DSIM_TIMEOUT */ +#define DSIM_LPDR_TOUT(x) ((x) 0) +#define DSIM_BTA_TOUT(x) ((x) 16) + +/* DSIM_CLKCTRL */ +#define DSIM_ESC_PRESCALER(x) (((x) 0x) 0) +#define DSIM_ESC_PRESCALER_MASK(0x 0) +#define DSIM_LANE_ESC_CLK_EN_CLK (1 19) +#define DSIM_LANE_ESC_CLK_EN_DATA(x) (((x) 0xf) 20) +#define DSIM_LANE_ESC_CLK_EN_DATA_MASK (0xf 20) +#define DSIM_BYTE_CLKEN(1 24) +#define
[RFC PATCH 4/4] video: display: Add Samsung s6e8ax0 display panel driver
This patch adds Common Display Framework driver for Samsung s6e8ax0 MIPI DSI display panel. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/video/display/Kconfig |3 + drivers/video/display/Makefile|1 + drivers/video/display/panel-s6e8ax0.c | 1027 + include/video/panel-s6e8ax0.h | 41 ++ 4 files changed, 1072 insertions(+) create mode 100644 drivers/video/display/panel-s6e8ax0.c create mode 100644 include/video/panel-s6e8ax0.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index b14527a..f19ec04 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -5,6 +5,9 @@ menuconfig DISPLAY_CORE if DISPLAY_CORE +config DISPLAY_PANEL_S6E8AX0 + tristate S6E8AX0 DSI video mode panel + select OF_VIDEOMODE config DISPLAY_SOURCE_EXYNOS_DSI tristate Samsung SoC MIPI DSI Master diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 40a283a..0f7fdc2 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o +obj-$(CONFIG_DISPLAY_PANEL_S6E8AX0) += panel-s6e8ax0.o obj-$(CONFIG_DISPLAY_SOURCE_EXYNOS_DSI) += source-exynos_dsi.o diff --git a/drivers/video/display/panel-s6e8ax0.c b/drivers/video/display/panel-s6e8ax0.c new file mode 100644 index 000..4c09fe2 --- /dev/null +++ b/drivers/video/display/panel-s6e8ax0.c @@ -0,0 +1,1027 @@ +/* linux/drivers/video/exynos/s6e8ax0.c + * + * MIPI-DSI based s6e8ax0 AMOLED lcd 4.65 inch panel driver. + * + * Inki Dae, inki@samsung.com + * Donghwa Lee, dh09@samsung.com + * Tomasz Figa, t.f...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/kernel.h +#include linux/errno.h +#include linux/mutex.h +#include linux/wait.h +#include linux/ctype.h +#include linux/io.h +#include linux/delay.h +#include linux/irq.h +#include linux/interrupt.h + +#include linux/fb.h +#include linux/gpio.h +#include linux/lcd.h +#include linux/of.h +#include linux/of_gpio.h +#include linux/of_videomode.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/backlight.h +#include linux/regulator/consumer.h + +#include video/display.h +#include video/mipi_display.h +#include video/panel-s6e8ax0.h + +#define LDI_MTP_LENGTH 24 +#define DSIM_PM_STABLE_TIME10 +#define MIN_BRIGHTNESS 0 +#define MAX_BRIGHTNESS 24 +#define GAMMA_TABLE_COUNT 26 + +struct s6e8ax0 { + struct display_entity entity; + struct device *dev; + + struct s6e8ax0_platform_data *pdata; + struct backlight_device *bd; + struct lcd_device *ld; + struct regulator_bulk_data supplies[2]; + + bool enabled; + unsigned int id; + unsigned int gamma; + unsigned int acl_enable; + unsigned int cur_acl; + int power; + + unsigned int reset_gpio; +}; + +#define to_panel(p)container_of(p, struct s6e8ax0, entity) + +static const unsigned char s6e8ax0_22_gamma_30[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf, + 0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0, + 0x00, 0x61, 0x00, 0x5a, 0x00, 0x74, +}; + +static const unsigned char s6e8ax0_22_gamma_50[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xe8, 0x1f, 0xf7, 0xad, 0xc0, + 0xb5, 0xc4, 0xdc, 0xc4, 0x9e, 0xc6, 0x9c, 0xbb, 0xd8, 0xbb, + 0x00, 0x70, 0x00, 0x68, 0x00, 0x86, +}; + +static const unsigned char s6e8ax0_22_gamma_60[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xde, 0x1f, 0xef, 0xad, 0xc4, + 0xb3, 0xc3, 0xdd, 0xc4, 0x9e, 0xc6, 0x9c, 0xbc, 0xd6, 0xba, + 0x00, 0x75, 0x00, 0x6e, 0x00, 0x8d, +}; + +static const unsigned char s6e8ax0_22_gamma_70[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xd8, 0x1f, 0xe7, 0xaf, 0xc8, + 0xb4, 0xc4, 0xdd, 0xc3, 0x9d, 0xc6, 0x9c, 0xbb, 0xd6, 0xb9, + 0x00, 0x7a, 0x00, 0x72, 0x00, 0x93, +}; + +static const unsigned char s6e8ax0_22_gamma_80[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xc9, 0x1f, 0xde, 0xae, 0xc9, + 0xb1, 0xc3, 0xdd, 0xc2, 0x9d, 0xc5, 0x9b, 0xbc, 0xd6, 0xbb, + 0x00, 0x7f, 0x00, 0x77, 0x00, 0x99, +}; + +static const unsigned char s6e8ax0_22_gamma_90[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xc7, 0x1f, 0xd9, 0xb0, 0xcc, + 0xb2, 0xc3, 0xdc, 0xc1, 0x9c, 0xc6, 0x9c, 0xbc, 0xd4, 0xb9, + 0x00, 0x83, 0x00, 0x7b, 0x00, 0x9e, +}; + +static const unsigned char s6e8ax0_22_gamma_100[] = { + 0xfa, 0x01, 0x60, 0x10, 0x60, 0xbd, 0x80, 0xcd, 0xba, 0xce, + 0xb3, 0xc4, 0xde, 0xc3, 0x9c, 0xc4, 0x9, 0xb8, 0xd3, 0xb6, + 0x00, 0x88, 0x00, 0x80, 0x00, 0xa5, +}; + +static const unsigned char
Re: [PATCH v2 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
On Wed, Jan 30, 2013 at 1:30 AM, Vikas Sajjan vikas.saj...@linaro.org wrote: This patch adds display-timing node parsing using video helper function Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index bf0d9ba..94729ed 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -19,6 +19,7 @@ #include linux/clk.h #include linux/of_device.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h #include video/samsung_fimd.h #include drm/exynos_drm.h @@ -905,15 +906,46 @@ static int __devinit fimd_probe(struct platform_device *pdev) struct exynos_drm_subdrv *subdrv; struct exynos_drm_fimd_pdata *pdata; struct exynos_drm_panel_info *panel; + struct fb_videomode *fbmode; + struct device *disp_dev = pdev-dev; Isn't this the same as dev (maybe I'm missing some dependent patch)? + struct pinctrl *pctrl; struct resource *res; int win; int ret = -EINVAL; DRM_DEBUG_KMS(%s\n, __FILE__); - pdata = pdev-dev.platform_data; - if (!pdata) { - dev_err(dev, no platform data specified\n); + if (pdev-dev.of_node) { + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) { + DRM_ERROR(memory allocation for pdata failed\n); + return -ENOMEM; + } + + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL); + if (!fbmode) { + DRM_ERROR(memory allocation for fbmode failed\n); + return -ENOMEM; + } + + ret = of_get_fb_videomode(disp_dev-of_node, fbmode, -1); + if (ret) { + DRM_ERROR(failed to get fb_videomode\n); + return -EINVAL; + } + pdata-panel.timing = (struct fb_videomode) *fbmode; + + } else { + pdata = pdev-dev.platform_data; + if (!pdata) { + DRM_ERROR(no platform data specified\n); + return -EINVAL; + } + } + + pctrl = devm_pinctrl_get_select_default(dev); + if (IS_ERR(pctrl)) { Will this work for exynos5? AFAICT, there's no pinctrl setup for it. Sean + DRM_ERROR(no pinctrl data provided.\n); return -EINVAL; } -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] xf86-video-ati 7.1.0
If I learned anything from the libdrm mess that was 2.4.41 (sorry about that!), it is that people check things like md5sums, imo which should really no longer be included in the release announcements. :-) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (5): bump verion post release radeon: add new SI pci id radeon: fix ring count in R300PrepareTexturedVideo exa/Xv: fix coordinate limits on AVIVO IGPs radeon/r200: program RE_WIDTH_HEIGHT properly Dave Airlie (1): radeon: fix damage reporting for slave pixmaps Ilija Hadzic (3): video: add option to include disabled CRTCs in best CRTC search DRI2: change signature of radeon_dri2_drawable_crtc DRI2: limit the swap rate when CRTC is in DPMS-off state Jerome Glisse (2): radeon: avoid segfault when pixmap exceed GPU capabilities radeon: avoid copying over itself ddx fb Maarten Lankhorst (1): radeon: bump version for release Michel Dänzer (11): Remove dead code flagged by gcc -Wunused-but-set-variable. Remove unused local variable 'path'. Remove local variables total_size_bytes. Remove dead option definitions. glamor: Release the drawable after passing to glamor_push_pixels glamor: Enable full 2D acceleration for SI as well. Drop support for X servers older than 1.7. DRI2: Properly use buffer depth passed in by client. DRI2/r[345]xx: 16 bit depth buffers use square micro tiling. Make CRTC shadow pixmaps usable by glamor. Make radeon_glamor_create_textured_pixmap() return TRUE without USE_GLAMOR. git tag: xf86-video-ati-7.1.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.bz2 MD5: a799371aa8a64ac8f9535963d5135e9a xf86-video-ati-7.1.0.tar.bz2 SHA1: f94730e5ffc5f75fa3126579bed0222fe8330653 xf86-video-ati-7.1.0.tar.bz2 SHA256: c8ae44051fcb331625217f98c09a3aa69f493052b69d62c03f41fed0bfe610cd xf86-video-ati-7.1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.1.0.tar.gz MD5: 8a2694537b1fc6ff85b2aee1c00a0eb9 xf86-video-ati-7.1.0.tar.gz SHA1: 88b94a7503e813f8a12066dbda8d9642934f5a08 xf86-video-ati-7.1.0.tar.gz SHA256: 187230127739de179118e54205dd5c17fdb1e04cfbee1f9a63fde0030f39fcb0 xf86-video-ati-7.1.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRCUcZAAoJEP5VjHKmcBPDDVsP/RrdCI07QVxDANrNqKiUlScI B7kMYcB4phNn/SiFKElrxikpdrHddHtRdnXs4RzG+0gb6CVGDD48xY1MZNrJRBEY Lm+g1IKXU2w1LMqj9q3dMasNe73Msws5iRMy31n5NtVNNehcneibLR8Na7vkc30t bAsCP6Z0kOtrlxbVsEvUbQw4JIWQIBSzWflB1hqsWQKbLEGKC9TUKWNr+ZnoPBCm 5dPYSe/vrTeaC2RvdYGsyMLcyO4D2g67uvDmRvAlE9/VWj7eTLS8QAIy2kSliHbJ 7z2F+VDRjbBYGhIsa7neWzsdA85guSFhQj5+ToLcBNn9YXSxP7MWKJ0fPoaWPTxG wroTd14/HOCwH7a0w34SdHyB+kblTu9iOVi+DWsJ7YHs5yg/HGeB1c10OtejaZH5 cLiM4Wq1TNUuzX+DFq4JHdOwX9KM8pqyy7yPOvLOik1B7gbljmP6bJEv7NUnhNdT cY7WOgmvlNcbuY41YI6gY8XMjP4OyEC2cK+za6THEiLL+foj3CpdBcacnMopGTbs E4HgmzG+wXX1QBXe1y7iNz5B+y/dGNMJsM9yv2POoDZ2OTpnBczOmzGq2lJ7oxGA /6P66eiKt1NH4CGvojzqTbTc2gJ+KQtmSJtVt2+l+m/iwHInaGbgEtAbCDVK833Y R7KTbofGO9xkOAwBFRZr =AnY7 -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugzilla.kernel.org/show_bug.cgi?id=49981 Jérôme Glisse gli...@freedesktop.org changed: What|Removed |Added CC||gli...@freedesktop.org --- Comment #6 from Jérôme Glisse gli...@freedesktop.org 2013-01-30 17:22:36 --- It's not completely a kernel bug. It's userspace asking insane things to kernel. This mesa patch should avoid the issue most of the time : http://people.freedesktop.org/~glisse/0001-r600g-add-cs-memory-usage-accounting-and-limit-it.patch If you are using a recent mesa with gnome you will probably want this cogl patch too : http://people.freedesktop.org/~glisse/0001-glx-do-not-use-multisample-visual-config-for-front-o.patch And for kernel i am working on better handling of memory fragmentation. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60034] rv790 etqw regression since r600g: add async for staging buffer upload v2
https://bugs.freedesktop.org/show_bug.cgi?id=60034 --- Comment #4 from Jerome Glisse gli...@freedesktop.org --- Please update mesa again a bunch of fixes were push. Make sure you have up to : e1598cb642334c809e6ec219d793e7bc85a213de -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59903] [RS880] Xorg.0.log: flip queue failed: Device or resource busy
https://bugs.freedesktop.org/show_bug.cgi?id=59903 --- Comment #8 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #6) * with echo 2 /sys/module/drm/parameters/debug nothing special in dmesg Hmm, so maybe the EBUSY error is coming from this code in drm_mode_page_flip_ioctl(): if (crtc-fb == NULL) { /* The framebuffer is currently unbound, presumably * due to a hotplug event, that userspace has not * yet discovered. */ ret = -EBUSY; goto out; } What does xrandr --current say when the problem occurs? After that, does running xrandr without arguments make any difference? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel