[PATCH] drm/i915: Resolve interaction with drm-fixes tree
Signed-off-by: Mark Brown --- drivers/gpu/drm/i915/intel_pm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 7cdac0b..0b4de57 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5879,7 +5879,5 @@ void intel_pm_init(struct drm_device *dev) INIT_DELAYED_WORK(_priv->rps.delayed_resume_work, intel_gen6_powersave_work); - - INIT_DELAYED_WORK(_priv->rps.vlv_work, vlv_rps_timer_work); } -- 1.8.4.rc3 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131003/4ab617fc/attachment-0001.pgp>
[Bug 69983] [r600g, bisected] Screen corruption in Firefox and World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #9 from Jos van Wolput wol...@onsneteindhoven.nl --- Same corrupted screen issue running /demos/cuberender, cubemap and dinoshade using mesa-68f6dec32ed5eede361f76c8dbdf897652659baf -- 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 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Jos van Wolput wol...@onsneteindhoven.nl changed: What|Removed |Added Summary|[r600g, bisected] Screen|[r600g, bisected] Screen |corruption in Firefox and |corruption in Firefox, |World of Warcraft |World of Warcraft and other ||apps -- 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 70042] Major texture flickering in Dota 2 (r600g on HD 6950)
https://bugs.freedesktop.org/show_bug.cgi?id=70042 --- Comment #2 from Alexandre Demers alexandre.f.dem...@gmail.com --- I can't seem to be able to launch dota 2 with apitrace. I can launch Steam, but Dota keeps crashing at launch. I'll add screenshots later. -- 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 70042] Major texture flickering in Dota 2 (r600g on HD 6950)
https://bugs.freedesktop.org/show_bug.cgi?id=70042 --- Comment #3 from Alexandre Demers alexandre.f.dem...@gmail.com --- Created attachment 87012 -- https://bugs.freedesktop.org/attachment.cgi?id=87012action=edit Visible corruption on mini-map While the texture flickering is very fast, it appears as static on screenshots. On this one, textures flickering on the mini-map and a thin artifact on the left side of the screen (looks like a line, but it is most likely a triangle caused by the light coming from a tower) -- 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 70042] Major texture flickering in Dota 2 (r600g on HD 6950)
https://bugs.freedesktop.org/show_bug.cgi?id=70042 --- Comment #4 from Alexandre Demers alexandre.f.dem...@gmail.com --- Created attachment 87013 -- https://bugs.freedesktop.org/attachment.cgi?id=87013action=edit Many glitches in the middle of the screen Here, some more visible glitches flickering at an impressive pace. -- 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 70009] [r300g, bisected] some wine apps renders black
https://bugs.freedesktop.org/show_bug.cgi?id=70009 --- Comment #6 from Pavel Ondračka pavel.ondra...@email.cz --- Created attachment 87014 -- https://bugs.freedesktop.org/attachment.cgi?id=87014action=edit EVE online Wine terminal output (In reply to comment #5) Do particular shaders fail to compile or is there just incorrect rendering? Yeah, there is a particular failing shader, however it fails to compile and link even before the patch, its just that the patch introduced also a bad rendering (but only for r300g). I've attached the wine log, which shows the failing shader, however I'm starting to believe, that it may not be the root cause here. -- 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
[PATCH 0/26] get_user_pages() cleanup
Hello, In my quest for changing locking around page faults to make things easier for filesystems I found out get_user_pages() users could use a cleanup. The knowledge about necessary locking for get_user_pages() is in tons of places in drivers and quite a few of them actually get it wrong (don't have mmap_sem when calling get_user_pages() or hold mmap_sem when calling copy_from_user() in the surrounding code). Rather often this actually doesn't seem necessary. This patch series converts lots of places to use either get_user_pages_fast() or a new simple wrapper get_user_pages_unlocked() to remove the knowledge of mmap_sem from the drivers. I'm still looking into converting a few remaining drivers (most notably v4l2) which are more complex. As I already wrote, in some cases I actually think drivers were buggy (and I note that in corresponding changelogs). I would really like to ask respective maintainers to have a look at the patches in their area. Also any other comments are welcome. Thanks. Honza PS: Sorry for the huge recipient list but I don't really know how to trim it down... CC: Alexander Viro v...@zeniv.linux.org.uk CC: Andreas Dilger andreas.dil...@intel.com CC: Andy Walls awa...@md.metrocast.net CC: Arnd Bergmann a...@arndb.de CC: Benjamin LaHaise b...@kvack.org CC: ceph-de...@vger.kernel.org CC: Dan Williams dan.j.willi...@intel.com CC: David Airlie airl...@linux.ie CC: dri-devel@lists.freedesktop.org CC: Gleb Natapov g...@redhat.com CC: Greg Kroah-Hartman gre...@linuxfoundation.org CC: hpdd-disc...@lists.01.org CC: Jarod Wilson ja...@wilsonet.com CC: Jayant Mangalampalli jayant.mangalampa...@intel.com CC: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com CC: Jesper Nilsson jesper.nils...@axis.com CC: Kai Makisara kai.makis...@kolumbus.fi CC: k...@vger.kernel.org CC: Laurent Pinchart laurent.pinch...@ideasonboard.com CC: linux-...@kvack.org CC: linux-cris-ker...@axis.com CC: linux-fb...@vger.kernel.org CC: linux-fsde...@vger.kernel.org CC: linux-i...@vger.kernel.org CC: linux-me...@vger.kernel.org CC: linux-...@vger.kernel.org CC: linux-r...@vger.kernel.org CC: linux-s...@vger.kernel.org CC: Manu Abraham abraham.m...@gmail.com CC: Mark Allyn mark.a.al...@intel.com CC: Mikael Starvik star...@axis.com CC: Mike Marciniszyn infinip...@intel.com CC: Naren Sankar nsan...@broadcom.com CC: Paolo Bonzini pbonz...@redhat.com CC: Peng Tao tao.p...@emc.com CC: Roland Dreier rol...@kernel.org CC: Sage Weil s...@inktank.com CC: Scott Davilla davi...@4pi.com CC: Timur Tabi ti...@freescale.com CC: Tomi Valkeinen tomi.valkei...@ti.com CC: Tony Luck tony.l...@intel.com CC: Trond Myklebust trond.mykleb...@netapp.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/26] get_user_pages() cleanup
On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote: Hello, In my quest for changing locking around page faults to make things easier for filesystems I found out get_user_pages() users could use a cleanup. The knowledge about necessary locking for get_user_pages() is in tons of places in drivers and quite a few of them actually get it wrong (don't have mmap_sem when calling get_user_pages() or hold mmap_sem when calling copy_from_user() in the surrounding code). Rather often this actually doesn't seem necessary. This patch series converts lots of places to use either get_user_pages_fast() or a new simple wrapper get_user_pages_unlocked() to remove the knowledge of mmap_sem from the drivers. I'm still looking into converting a few remaining drivers (most notably v4l2) which are more complex. Even looking over the kerneldoc comment next to it I still fail to understand when you'd want to use get_user_pages_fast and when not. This isn't meant as an argument against your series, but maybe a hint that we'd need further work in this direction. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space
On 9/30/2013 7:36 AM, Daniel Vetter wrote:
On Sat, Sep 28, 2013 at 12:49:24PM -0400, John Hupp wrote:
[I emailed the list with this same material on 9/13, but it has
received no response and someone on the Ubuntu kernel team suggested
that I change the email Subject from Re: Moving a bug upstream per
downstream request, emailing the maintainers to the more
descriptive one above.]
When I emailed the maintainers with the report below on 8/15 (and
archived at
http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html),
a response came on 8/16:
It's a flash bug. They ignore the format of the Window that they
PutImage to. (Worse, they create an image of the right depth or else X
would reject the PutImage with a BadMatch and then render incorrect
pixel data into it.)
Despite that, someone on the Ubuntu kernel team asserted at a
minimum a non-flash regression exists going from Quantal to Raring,
and urged me to proceed with upstream kernel bisection.
I finally finished that, and arrived at the result:
Still a flash bug. This commit simply enables rgb555 in the kernel, which
sna likes to use on gen2/3. Flash is just too dense and always presumes
xrgb. Adding
Section Screen
Identifier igd
DefaultDepth 24
EndSection
to your xorg.conf will work around.
-Daniel
*Thanks! That successfully works around the Flash problem with the
Intel driver/chipsets that I reported on. We have at least 4 of those
machines here.*
57779d06367a915ee03e6cb918d7575f0a46e419 is the first bad commit
commit 57779d06367a915ee03e6cb918d7575f0a46e419
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Oct 31 17:50:14 2012 +0200
drm/i915: Fix display pixel format handling
Fix support for all RGB/BGR pixel formats (except the
16:16:16:16 float
format).
Fix intel_init_framebuffer() to match hardware and driver limitations:
* RGB332 is not supported at all
* CI8 is supported
* XRGB1555 co. are supported on Gen3 and earlier
* XRGB210101010 co. are supported from Gen4 onwards
* BGR formats are supported from Gen4 onwards
* YUV formats are supported from Gen5 onwards (driver limitation)
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
:04 04 334e1536b3513d0c329a8bb6360593d12065b71d
bf0996ec13cbee07156c5e9f98dcdee30200e658 M drivers
-
The git bisect log:
git bisect start
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
# good: [db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070] Merge tag 'dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070
# bad: [3c2e81ef344a90bb0a39d84af6878b4aeff568a2] Merge branch
'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect bad 3c2e81ef344a90bb0a39d84af6878b4aeff568a2
# good: [d8c532c40721f7507896d202b8cae3b3642d2b0d] Merge branch
'v4l_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good d8c532c40721f7507896d202b8cae3b3642d2b0d
# good: [2a74dbb9a86e8102dcd07d284135b4530a84826e] Merge branch
'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
git bisect good 2a74dbb9a86e8102dcd07d284135b4530a84826e
# bad: [124ea297c8f0e0a3a567af0894fdbe05caaf80ec] drm/nouveau: unpin
pushbuffer bo before destroying it
git bisect bad 124ea297c8f0e0a3a567af0894fdbe05caaf80ec
# bad: [12f3382bc0262e981a2e58aca900cbbdbbe66825] drm/i915:
implement WaDisablePSDDualDispatchEnable on IVB VLV
git bisect bad 12f3382bc0262e981a2e58aca900cbbdbbe66825
# good: [20474e90c948545c51da95689b8342a4f3bbaeb6] drm/i915: fix
checks inside ironlake_crtc_{enable, disable}
git bisect good 20474e90c948545c51da95689b8342a4f3bbaeb6
# good: [00c09d70df6b30c980f20facc1db3def3f5a637e] drm/i915: create
the DDI encoder
git bisect good 00c09d70df6b30c980f20facc1db3def3f5a637e
# bad: [a35f267946947b3798827a783d82d3d2aa55697d] drm/i915: remove
IBX code from lpt_enable_pch_transcoder
git bisect bad a35f267946947b3798827a783d82d3d2aa55697d
# bad: [9256aa195d3badd009bf4addee6c3ae39879b8a6] drm/i915: move
encoder-mode_set calls to crtc_mode_set
git bisect bad 9256aa195d3badd009bf4addee6c3ae39879b8a6
# good: [e7210c3c4f0d05e318b854bbd545fe335930c5cc] drm/i915: move
more pte encoding to pte encode
git bisect good e7210c3c4f0d05e318b854bbd545fe335930c5cc
# bad: [90f9a336f56318d4f21a29e8ef063cb70fe7dd11] drm/i915: Check
the framebuffer offset
git bisect bad 90f9a336f56318d4f21a29e8ef063cb70fe7dd11
# bad: [5d7bd705ddb362d5bd8ef2f3b294cd8f9d93c39e] drm/i915: Check
framebuffer stride more thoroughly
git bisect bad 5d7bd705ddb362d5bd8ef2f3b294cd8f9d93c39e
#
Re: [PATCH 0/26] get_user_pages() cleanup
On Wed 02-10-13 09:20:09, Christoph Hellwig wrote: On Wed, Oct 02, 2013 at 04:27:41PM +0200, Jan Kara wrote: Hello, In my quest for changing locking around page faults to make things easier for filesystems I found out get_user_pages() users could use a cleanup. The knowledge about necessary locking for get_user_pages() is in tons of places in drivers and quite a few of them actually get it wrong (don't have mmap_sem when calling get_user_pages() or hold mmap_sem when calling copy_from_user() in the surrounding code). Rather often this actually doesn't seem necessary. This patch series converts lots of places to use either get_user_pages_fast() or a new simple wrapper get_user_pages_unlocked() to remove the knowledge of mmap_sem from the drivers. I'm still looking into converting a few remaining drivers (most notably v4l2) which are more complex. Even looking over the kerneldoc comment next to it I still fail to understand when you'd want to use get_user_pages_fast and when not. AFAIU get_user_pages_fast() should be used 1) if you don't need any special get_user_pages() arguments (like calling it for mm of a different process, forcing COW, or similar). 2) you don't expect pages to be unmapped (then get_user_pages_fast() is actually somewhat slower because it walks page tables twice). Honza -- Jan Kara j...@suse.cz SUSE Labs, CR ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Hi,
First of all sorry for the late response,
On Tue, Oct 1, 2013 at 10:09 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Sylwester Nawrocki [mailto:sylvester.nawro...@gmail.com]
Sent: Monday, September 30, 2013 7:09 AM
To: Inki Dae
Cc: Rahul Sharma; devicet...@vger.kernel.org; linux-samsung-soc;
sw0312.kim; sunil joshi; dri-devel; kgene.kim; Shirish S; Sylwester
Nawrocki; Rahul Sharma; Stephen Warren; Mark Rutland; Kumar Gala; Pawel
Moll; Rob Herring; Sean Paul
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 09/28/2013 06:10 PM, Inki Dae wrote:
Any opinion from Device-Tree folks?
IMO, we should have same consensus on Shirish patches before
proceeding.
Rahul, it seems that DT people have no interest in this issue. So let's
have a consensus about this issue internally.
To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
How about keeping hdmiphy config data in each board dts file?
Please don't use HTML and quote only relevant part of e-mails. Otherwise
there are good chances your messages end up in people's spam box.
Ah, I missed checking text mode. Sorry about this. :)
It often helps to Cc a DT binding maintainer directly.
Good idea.
Then, you consider moving the HDMI phy configuration to the device tree.
As Sean suggested in this thread:
Right.
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
[trimmed couple more entries]
+};
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them universally.
Shirish has uploaded a patch to the chromium review site to push these
into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
you can work that into your patch set?
The configuration data is 64 bytes of the register values IIUC. Would it
be
possible to figure out exact meaning of each byte ? Do all of these bytes
Right, but the user manual doesn't describe that enough so we might need to
inquire for what it means to design team.
need to be changed per board ? Perhaps we can have per SoC static tables
in
the PHY driver and be overwriting only some of the bytes with values read
from device tree ?
AFAIR firmware-like binary blobs (register address/value pairs) are not
supposed to be stored in DT.
If there is no detailed documentation for theese PHY configuration tables
I guess there is no choice but to put these raw 64 bytes in DT.
Presumably
this should be a an required property defined only by board dts, since
those
values are PCB design dependent.
However, if not all boards need tweaking this configuration data, then it
could make sense to define recommended per-SoC tables in the driver and
overwrite from DT only if it is specified there for a specific board.
If we can come up with universal configuration for a SoC and selected
pixel
clock frequency then it could likely be better to store that in the
driver
rather than in DT.
Thanks you your opinion. However, we need to make sure how we take care of
the PHY configuration values. So I will have two steps to merge this pages
set.
To Rahul,
Could you post only your patch set regardless of Shirish's patch? I will
merge your patch set first because as is, Exynos drm hdmi driver is broken.
And, we need more discussions about Shirish patch. So I will not merge this
patch until we have a consensus about it.
To Shirish,
For your patch, it seems that you need to make sure to figure out exact
meaning of each byte of the PHY configuration values first. Maybe you need
to inquire for that to hardware or design team. And please separate the
values into common and specific parts if needed.
Agreed, I shall request our hardware team to provide description about the
phy values, and will update the patch, once i receive the same.
Thanks,
Inki Dae
--
Thanks,
Sylwester
Thanks,
Shirish S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57919] Visual glitches in unity with Radeon HD 7600M
https://bugs.freedesktop.org/show_bug.cgi?id=57919 --- Comment #23 from Thilo Cestonaro th...@cestona.ro --- Sadly no. Unity still is flickering and has that triangle kind of display errors. :( Greetings Thilo -- 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 70035] GPU Lockup on AMD RS880 HD4200
https://bugs.freedesktop.org/show_bug.cgi?id=70035 --- Comment #7 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #1) Possibly related to bug 69983. That is indeed likely — current master (since 68f6dec32ed5eede361f76c8dbdf897652659baf) locks up my RS880 even with glxgears, though only using LLVM. -- 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
HPD flood warning since b8f102e8b
During resume from hibernation, I started to see the warning below since commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich e...@suse.de Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) the system is otherwise working properly, and so far it seems to happen only during hibernation resume. [13766.703229] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [13766.703230] Received HPD interrupt although disabled [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm bn ep btusb bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi snd_seq iwldvm mac80211 sg snd_timer iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_he lper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.12.0-rc3 #1 [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [13766.703350] 03e9 88007c283d18 81583013 88007c283d58 [13766.703357] 8104d297 88007c283d98 000c 0002 [13766.703365] 880037158000 0004 880037158000 88007c283db8 [13766.703367] Call Trace: [13766.703375] IRQ [81583013] dump_stack+0x7a/0x97 [13766.703382] [8104d297] warn_slowpath_common+0x87/0xb0 [13766.703388] [8104d361] warn_slowpath_fmt+0x41/0x50 [13766.703425] [a00c7be2] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [810a40fc] handle_irq_event_percpu+0xac/0x220 [13766.703442] [810a42b9] handle_irq_event+0x49/0x70 [13766.703449] [810a7b2f] handle_edge_irq+0x7f/0x150 [13766.703454] [81004a89] handle_irq+0x59/0x150 [13766.703461] [8158d371] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [8100403b] do_IRQ+0x5b/0xe0 [13766.703474] [815895af] common_interrupt+0x6f/0x6f [13766.703482] EOI [8146cf74] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [8146cf70] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [8146d37a] cpuidle_idle_call+0x10a/0x160 [13766.703503] [8100b7b9] arch_cpu_idle+0x9/0x30 [13766.703509] [810a35cb] cpu_idle_loop+0x8b/0x270 [13766.703515] [810a37ce] cpu_startup_entry+0x1e/0x20 [13766.703522] [8103115e] start_secondary+0x8e/0x90 It's not a single occurence, it's quite a flood within the same second, ending with [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from hotplug detection to pollin If this really needs to be enabled unconditionally by default (?), having it to warn only once would be nice. If there is anything else I could do to make this go away, please let me know. I don't want to be running Tainted: W kernel from now forever on :) This is a standard x200s thinkpad, no fancy development HW. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: HPD flood warning since b8f102e8b
Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... Cheers, Daniel On Thu, Oct 3, 2013 at 11:46 AM, Jiri Kosina jkos...@suse.cz wrote: During resume from hibernation, I started to see the warning below since commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich e...@suse.de Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) the system is otherwise working properly, and so far it seems to happen only during hibernation resume. [13766.703229] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [13766.703230] Received HPD interrupt although disabled [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm bn ep btusb bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi snd_seq iwldvm mac80211 sg snd_timer iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_he lper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.12.0-rc3 #1 [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [13766.703350] 03e9 88007c283d18 81583013 88007c283d58 [13766.703357] 8104d297 88007c283d98 000c 0002 [13766.703365] 880037158000 0004 880037158000 88007c283db8 [13766.703367] Call Trace: [13766.703375] IRQ [81583013] dump_stack+0x7a/0x97 [13766.703382] [8104d297] warn_slowpath_common+0x87/0xb0 [13766.703388] [8104d361] warn_slowpath_fmt+0x41/0x50 [13766.703425] [a00c7be2] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [810a40fc] handle_irq_event_percpu+0xac/0x220 [13766.703442] [810a42b9] handle_irq_event+0x49/0x70 [13766.703449] [810a7b2f] handle_edge_irq+0x7f/0x150 [13766.703454] [81004a89] handle_irq+0x59/0x150 [13766.703461] [8158d371] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [8100403b] do_IRQ+0x5b/0xe0 [13766.703474] [815895af] common_interrupt+0x6f/0x6f [13766.703482] EOI [8146cf74] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [8146cf70] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [8146d37a] cpuidle_idle_call+0x10a/0x160 [13766.703503] [8100b7b9] arch_cpu_idle+0x9/0x30 [13766.703509] [810a35cb] cpu_idle_loop+0x8b/0x270 [13766.703515] [810a37ce] cpu_startup_entry+0x1e/0x20 [13766.703522] [8103115e] start_secondary+0x8e/0x90 It's not a single occurence, it's quite a flood within the same second, ending with [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from hotplug detection to pollin If this really needs to be enabled unconditionally by default (?), having it to warn only once would be nice. If there is anything else I could do to make this go away, please let me know. I don't want to be running Tainted: W kernel from now forever on :) This is a standard x200s thinkpad, no fancy development HW. -- Jiri Kosina SUSE Labs -- 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 70068] New: flightgear crashes with Streamout unsupported in util_blitter_clear_buffer()
https://bugs.freedesktop.org/show_bug.cgi?id=70068 Priority: medium Bug ID: 70068 Assignee: dri-devel@lists.freedesktop.org Summary: flightgear crashes with Streamout unsupported in util_blitter_clear_buffer() Severity: normal Classification: Unclassified OS: All Reporter: marvi...@gmx.de Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Flightgear asserts with todays mesa git on RS880. ... Enabling ATI viewport hack util/u_blitter.c:1728:util_blitter_clear_buffer: Assertion `!Streamout unsupported in util_blitter_clear_buffer()' failed. Program received signal SIGTRAP, Trace/breakpoint trap. 0x7fffea44c9e8 in _debug_assert_fail (expr=0x7fffea6c1030 !\Streamout unsupported in util_blitter_clear_buffer()\, file=0x7fffea6c0cf7 util/u_blitter.c, line=1728, function=0x7fffea6c10e0 __func__.8464 util_blitter_clear_buffer) at util/u_debug.c:278 278 os_abort(); (gdb) bt #0 0x7fffea44c9e8 in _debug_assert_fail (expr=0x7fffea6c1030 !\Streamout unsupported in util_blitter_clear_buffer()\, file=0x7fffea6c0cf7 util/u_blitter.c, line=1728, function=0x7fffea6c10e0 __func__.8464 util_blitter_clear_buffer) at util/u_debug.c:278 #1 0x7fffea45a558 in util_blitter_clear_buffer (blitter=0x132fec0, dst=0x1494dc0, offset=0, size=34816, num_channels=1, clear_value=0x7fffbc00) at util/u_blitter.c:1728 #2 0x7fffea554470 in r600_clear_buffer (ctx=0x1326520, dst=0x1494dc0, offset=0, size=34816, value=0) at r600_blit.c:645 #3 0x7fffea5f5c54 in r600_screen_clear_buffer (rscreen=0x1325e70, dst=0x1494dc0, offset=0, size=34816, value=0) at r600_pipe_common.c:272 #4 0x7fffea5f91fb in r600_texture_allocate_htile (rscreen=0x1325e70, rtex=0x1525e50) at r600_texture.c:488 #5 0x7fffea5f9487 in r600_texture_create_object (screen=0x1325e70, base=0x7fffcba0, pitch_in_bytes_override=0, buf=0x0, surface=0x7fffbda0) at r600_texture.c:549 #6 0x7fffea5f9d5b in r600_texture_create (screen=0x1325e70, templ=0x7fffcba0) at r600_texture.c:702 #7 0x7fffea55d6a1 in r600_resource_create (screen=0x1325e70, templ=0x7fffcba0) at r600_resource.c:38 #8 0x7fffea604f50 in dri2_drawable_process_buffers (ctx=0x13000b0, drawable=0x1523a60, buffers=0x14964b0, buffer_count=1, atts=0x1524fb0, att_count=2) at dri2.c:352 #9 0x7fffea6052fa in dri2_allocate_textures (ctx=0x13000b0, drawable=0x1523a60, statts=0x1524fb0, statts_count=2) at dri2.c:471 #10 0x7fffea60356b in dri_st_framebuffer_validate (stctx=0x13d59a0, stfbi=0x1523a60, statts=0x1524fb0, count=2, out=0x7fffcd50) at dri_drawable.c:83 #11 0x7fffea2da890 in st_framebuffer_validate (stfb=0x1524b60, st=0x13d59a0) at ../../src/mesa/state_tracker/st_manager.c:192 #12 0x7fffea2db973 in st_api_make_current (stapi=0x7fffeaa43de0 st_gl_api, stctxi=0x13d59a0, stdrawi=0x1523a60, streadi=0x1523a60) at ../../src/mesa/state_tracker/st_manager.c:722 #13 0x7fffea60232e in dri_make_current (cPriv=0x136acf0, driDrawPriv=0x1495d80, driReadPriv=0x1495d80) at dri_context.c:240 #14 0x7fffea1002e3 in driBindContext (pcp=0x136acf0, pdp=0x1495d80, prp=0x1495d80) at dri_util.c:380 #15 0x75a3f3db in dri2_bind_context (context=0x1306f50, old=0x75c5c4a0 dummyContext, draw=104857603, read=104857603) at dri2_glx.c:172 #16 0x75a04d76 in MakeContextCurrent (dpy=0x12f0bd0, draw=104857603, read=104857603, gc_user=0x1306f50) at glxcurrent.c:269 #17 0x75a04e97 in glXMakeCurrent (dpy=0x12f0bd0, draw=104857603, gc=0x1306f50) at glxcurrent.c:303 #18 0x766b0d0a in osgViewer::GraphicsWindowX11::makeCurrentImplementation() () from /usr/lib64/libosgViewer.so.80 #19 0x7600471d in osg::GraphicsContext::makeCurrent() () from /usr/lib64/libosg.so.80 #20 0x766a9988 in osgViewer::ViewerBase::renderingTraversals() () from /usr/lib64/libosgViewer.so.80 #21 0x00b2d7a5 in fgOSMainLoop() () #22 0x0064317a in fgMainInit(int, char**) () #23 0x0060a474 in main () -- 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 70068] flightgear crashes with Streamout unsupported in util_blitter_clear_buffer()
https://bugs.freedesktop.org/show_bug.cgi?id=70068 --- Comment #1 from Marc Dietrich marvi...@gmx.de --- bisect revealed that 68f6dec32ed5eede361f76c8dbdf897652659baf: r600g: move aux_context and r600_screen_clear_buffer to drivers/radeon is the one to be blamed. -- 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 70068] flightgear crashes with Streamout unsupported in util_blitter_clear_buffer()
https://bugs.freedesktop.org/show_bug.cgi?id=70068 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alex Deucher ag...@yahoo.com --- *** This bug has been marked as a duplicate of bug 69983 *** -- 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 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||marvi...@gmx.de --- Comment #10 from Alex Deucher ag...@yahoo.com --- *** Bug 70068 has been marked as a duplicate of this bug. *** -- 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 70073] New: [r300g] Stop calling draw_prepare_shader_outputs
https://bugs.freedesktop.org/show_bug.cgi?id=70073 Priority: medium Bug ID: 70073 Assignee: dri-devel@lists.freedesktop.org Summary: [r300g] Stop calling draw_prepare_shader_outputs Severity: normal Classification: Unclassified OS: All Reporter: fabio@libero.it Hardware: All Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa Reporting here just to avoid forgetting it: http://lists.freedesktop.org/archives/mesa-dev/2013-September/044240.html i915g commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b1461acf15ab450fa0d360ec5e03c90d0797a6d4 -- 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/5] drm: merge device setup into drm_dev_register()
On Wed, Oct 02, 2013 at 11:23:35AM +0200, David Herrmann wrote:
All bus drivers do device setup themselves. This requires us to adjust all
of them if we introduce new core features. Thus, merge all these into a
uniform drm_dev_register() helper.
Note that this removes the drm_lastclose() error path for AGP as it is
horribly broken. Moreover, no bus driver called this in any other error
path either. Instead, we use the recently introduced AGP cleanup helpers.
We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep
semantics.
Signed-off-by: David Herrmann dh.herrm...@gmail.com
[snip]
+int drm_dev_register(struct drm_device *dev)
+{
+ int ret;
+
+ mutex_lock(drm_global_mutex);
+
+ if (dev-driver-bus-agp_init) {
+ ret = dev-driver-bus-agp_init(dev);
+ if (ret)
+ goto out_unlock;
+ }
Imo this should stay in drm_get_pci_dev since its pci specific - no other
bus type should ever bother with this really.
Looks good otherwise.
-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: move device unregistration into drm_dev_unregister()
On Wed, Oct 02, 2013 at 11:23:38AM +0200, David Herrmann wrote:
Analog to drm_dev_register(), we now provide drm_dev_unregister() which
does the reverse. drm_dev_put() is still in place and combines the calls
to drm_dev_unregister() and drm_dev_free() so buses don't have to change.
*_get() and *_put() are used for reference-counting in the kernel.
However, drm_dev_put() definitely does not do any kind of ref-counting.
Hence, use the more appropriate *_register(), *_unregister(), *_alloc()
and *_free() names.
Signed-off-by: David Herrmann dh.herrm...@gmail.com
With the agp_init call moved back into pci code this series is
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
We still have a bit a midlayer smell here, and to correctly fix the
init/cleanup order I think a bit more work is required. But this is a
definit step up imo.
-Daniel
---
drivers/gpu/drm/drm_stub.c | 61
+++---
include/drm/drmP.h | 1 +
2 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 397ab90..a5290b7 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -363,8 +363,6 @@ static void drm_unplug_minor(struct drm_minor *minor)
*/
void drm_put_dev(struct drm_device *dev)
{
- struct drm_map_list *r_list, *list_temp;
-
DRM_DEBUG(\n);
if (!dev) {
@@ -372,29 +370,7 @@ void drm_put_dev(struct drm_device *dev)
return;
}
- drm_lastclose(dev);
-
- if (dev-driver-unload)
- dev-driver-unload(dev);
-
- if (dev-driver-bus-agp_destroy)
- dev-driver-bus-agp_destroy(dev);
-
- drm_vblank_cleanup(dev);
-
- list_for_each_entry_safe(r_list, list_temp, dev-maplist, head)
- drm_rmmap(dev, r_list-map);
-
- if (drm_core_check_feature(dev, DRIVER_MODESET))
- drm_put_minor(dev-control);
-
- if (dev-render)
- drm_put_minor(dev-render);
-
- drm_put_minor(dev-primary);
-
- list_del(dev-driver_item);
-
+ drm_dev_unregister(dev);
drm_dev_free(dev);
}
EXPORT_SYMBOL(drm_put_dev);
@@ -595,3 +571,38 @@ out_unlock:
return ret;
}
EXPORT_SYMBOL(drm_dev_register);
+
+/**
+ * drm_dev_unregister - Unregister DRM device
+ * @dev: Device to unregister
+ *
+ * Unregister the DRM device from the system. This does the reverse of
+ * drm_dev_register() but does not deallocate the device. The caller must
call
+ * drm_dev_free() to free all resources.
+ */
+void drm_dev_unregister(struct drm_device *dev)
+{
+ struct drm_map_list *r_list, *list_temp;
+
+ drm_lastclose(dev);
+
+ if (dev-driver-unload)
+ dev-driver-unload(dev);
+
+ if (dev-driver-bus-agp_destroy)
+ dev-driver-bus-agp_destroy(dev);
+
+ drm_vblank_cleanup(dev);
+
+ list_for_each_entry_safe(r_list, list_temp, dev-maplist, head)
+ drm_rmmap(dev, r_list-map);
+
+ if (dev-control)
+ drm_put_minor(dev-control);
+ if (dev-render)
+ drm_put_minor(dev-render);
+ drm_put_minor(dev-primary);
+
+ list_del(dev-driver_item);
+}
+EXPORT_SYMBOL(drm_dev_unregister);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f4ec6b3..7516d22 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1649,6 +1649,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver
*driver,
struct device *parent);
void drm_dev_free(struct drm_device *dev);
int drm_dev_register(struct drm_device *dev);
+void drm_dev_unregister(struct drm_device *dev);
int drm_get_minor(struct drm_device *dev, struct drm_minor **minor, int
type);
/*@}*/
--
1.8.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 2/5] drm: merge device setup into drm_dev_register()
Hi Daniel
On Thu, Oct 3, 2013 at 3:15 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Oct 02, 2013 at 11:23:35AM +0200, David Herrmann wrote:
All bus drivers do device setup themselves. This requires us to adjust all
of them if we introduce new core features. Thus, merge all these into a
uniform drm_dev_register() helper.
Note that this removes the drm_lastclose() error path for AGP as it is
horribly broken. Moreover, no bus driver called this in any other error
path either. Instead, we use the recently introduced AGP cleanup helpers.
We also keep a DRIVER_MODESET condition around pci_set_drvdata() to keep
semantics.
Signed-off-by: David Herrmann dh.herrm...@gmail.com
[snip]
+int drm_dev_register(struct drm_device *dev)
+{
+ int ret;
+
+ mutex_lock(drm_global_mutex);
+
+ if (dev-driver-bus-agp_init) {
+ ret = dev-driver-bus-agp_init(dev);
+ if (ret)
+ goto out_unlock;
+ }
Imo this should stay in drm_get_pci_dev since its pci specific - no other
bus type should ever bother with this really.
You mean I should _move_ it to drm_pci.c? It has never been
pci-specific. But sure, I can do that. It actually makes sense. But
I'd like to do that in a followup patch as it's a semantic change
that's not directly related. I will include it in v2.
Thanks
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: merge device setup into drm_dev_register()
On Thu, Oct 3, 2013 at 3:19 PM, David Herrmann dh.herrm...@gmail.com wrote: You mean I should _move_ it to drm_pci.c? It has never been pci-specific. But sure, I can do that. It actually makes sense. But I'd like to do that in a followup patch as it's a semantic change that's not directly related. I will include it in v2. Oh right it's always been in fill_in_dev, but never should have been there ;-) Follow-up patch like you've suggested it better. -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 3/5] drm/bridge: Add PTN3460 bridge driver
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR 0x0
+#define PTN3460_EDID_EMULATION_ADDR0x84
+#define PTN3460_EDID_ENABLE_EMULATION 0
[Bug 70053] hard machine hang when switching to battery power with DPM enabled on Trinity APU
https://bugs.freedesktop.org/show_bug.cgi?id=70053 --- Comment #4 from Alex Deucher ag...@yahoo.com --- Created attachment 87033 -- https://bugs.freedesktop.org/attachment.cgi?id=87033action=edit force battery state on DC Does this patch also fix the problem? -- 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 70053] hard machine hang when switching to battery power with DPM enabled on Trinity APU
https://bugs.freedesktop.org/show_bug.cgi?id=70053 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #87033|0 |1 is obsolete|| --- Comment #5 from Alex Deucher ag...@yahoo.com --- Created attachment 87044 -- https://bugs.freedesktop.org/attachment.cgi?id=87044action=edit better patch Improved patch. Please try this one instead. -- 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: HPD flood warning since b8f102e8b
On Thu, 3 Oct 2013, Daniel Vetter wrote: Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... A bit difficult ... I originally thought that it was reliably reproducible, but now I didn't get it after 10 suspend/resume cycles. Will keep following it, and once it appears, will send you the dmesg. Cheers, Daniel On Thu, Oct 3, 2013 at 11:46 AM, Jiri Kosina jkos...@suse.cz wrote: During resume from hibernation, I started to see the warning below since commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich e...@suse.de Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) the system is otherwise working properly, and so far it seems to happen only during hibernation resume. [13766.703229] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [13766.703230] Received HPD interrupt although disabled [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm bn ep btusb bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi snd_seq iwldvm mac80211 sg snd_timer iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_he lper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.12.0-rc3 #1 [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [13766.703350] 03e9 88007c283d18 81583013 88007c283d58 [13766.703357] 8104d297 88007c283d98 000c 0002 [13766.703365] 880037158000 0004 880037158000 88007c283db8 [13766.703367] Call Trace: [13766.703375] IRQ [81583013] dump_stack+0x7a/0x97 [13766.703382] [8104d297] warn_slowpath_common+0x87/0xb0 [13766.703388] [8104d361] warn_slowpath_fmt+0x41/0x50 [13766.703425] [a00c7be2] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [810a40fc] handle_irq_event_percpu+0xac/0x220 [13766.703442] [810a42b9] handle_irq_event+0x49/0x70 [13766.703449] [810a7b2f] handle_edge_irq+0x7f/0x150 [13766.703454] [81004a89] handle_irq+0x59/0x150 [13766.703461] [8158d371] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [8100403b] do_IRQ+0x5b/0xe0 [13766.703474] [815895af] common_interrupt+0x6f/0x6f [13766.703482] EOI [8146cf74] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [8146cf70] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [8146d37a] cpuidle_idle_call+0x10a/0x160 [13766.703503] [8100b7b9] arch_cpu_idle+0x9/0x30 [13766.703509] [810a35cb] cpu_idle_loop+0x8b/0x270 [13766.703515] [810a37ce] cpu_startup_entry+0x1e/0x20 [13766.703522] [8103115e] start_secondary+0x8e/0x90 It's not a single occurence, it's quite a flood within the same second, ending with [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from hotplug detection to pollin If this really needs to be enabled unconditionally by default (?), having it to warn only once would be nice. If there is anything else I could do to make this go away, please let me know. I don't want to be running Tainted: W kernel from now forever on :) This is a standard x200s thinkpad, no fancy development HW. -- Jiri Kosina SUSE Labs -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge? Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(ptn3460-bridge, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR 0x0
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
Since the actual crtc/encoder drivers are abstracted through
exynos_drm_core/crtc/encoder, we need to initialize the ptn driver in
the abstraction layers in order to hook it directly into drm.
Sean
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(ptn3460-bridge, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
On Wed, Oct 2, 2013 at 5:10 PM, Olof Johansson o...@lixom.net wrote:
On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul seanp...@chromium.org wrote:
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index e5af3f2..780511a 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -190,6 +190,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ dp-controller {
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ };
This won't actually do what I think you want. Since the dtsi has the
node name dp-controller@145B, you will end up duplicating a new
node and not build on top of that one.
Thanks, Olof. I based this off Inki's exynos-drm-next tree which does
not have the latest from arm-soc, I'll re-upload.
Sean
There's two ways to do it: Always include the unit address, or create
a label in the dtsi such that:
dp_controller: dp-controller@ {
}
Then in your dts you can, at the root level:
dp_controller {
... new stuff and overrides ...
};
-Olof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Use of pci_map_page in nouveau, radeon TTM.
01.10.2013, 18:16, Konrad Rzeszutek Wilk konrad.w...@oracle.com: On Tue, Oct 01, 2013 at 12:16:16PM +0200, Thomas Hellstrom wrote: Jerome, Konrad Forgive an ignorant question, but it appears like both Nouveau and Radeon may use pci_map_page() when populating TTMs on pages obtained using the ordinary (not DMA pool). These pages will, if I understand things correctly, not be pages allocated with DMA_ALLOC_COHERENT. Not always. That depends if the SWIOTLB buffer has been enabled. Which happens if you have Calgary IOMMU, AMD GART and if you run under Xen. From what I understand, at least for the corresponding dma_map_page() it's illegal for the CPU to access these pages without calling dma_sync_xx_for_cpu(). And before the device is allowed to access them again, you need to call dma_sync_xx_for_device(). Correct. So mapping for PCI really invalidates the TTM interleaved CPU / device access model. Unless you use the TTM DMA one which allocates them from the coherent pool - in which case they are already mapped. Granted the part of using DMA export/import API is not finished (so moving from TTM pool to a V4L for example) and it will blow up with the right mix. Or did I miss something here? That is it. But for most of the use cases the drivers have been able to skirt this restriction b/c the pci_map_page/pci_unmap_page setup a DMA mapping that is static (until the pci_unmap_page) and on x86 the memory is coherent. So the map is good irregardless of the PCI devices. Naturally if you have multitple IOMMUs per bridge this all falls apart :-( This all falls flat also with non-coherent memory and I believe that is what some of the PA-RISC folks are hitting their heads against. Konrad, As i already answered you, this is irrelevant to the 2.0 version of PA-RISC architecture on which we run our ATI video options. And probably also on ARM once they start using these chipsets. Thanks, Thomas ___ 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
Re: A simple alternative to GEMr
On Thu, Oct 3, 2013 at 7:48 AM, dm.leontiev7 dm.leonti...@gmail.com wrote: Hello In my opinion, graphics stack will benefit from moving memory management to userspace because there are tons of features not available in kernel, like simd or c++. both of which bring no benefit to memory management code Also, bugs in buffer management code will bite only one process, not the whole system. As soon as you need to pin pages (which you need to do, except for the hw that Jerome is targetting with his proposal where the GPU can really support virtual memory), memory management becomes a whole system issue.. pinning pages can only be done from the kernel and it is pretty frowned upon to have a driver that lets userspace pin arbitrary pages without being able to keep track of those pages and clean up. Anyways, it is much better to trust the kernel than userspace. In system design, you must assume userspace is untrusted. If you have enough tracking for random pages that userspace asks the kernel to pin for the gpu in order to cleanup when userspace process dies, then you have *more* complexity than what you have in GEM. Trust me, it is far easier for the kernel to deal with buffer handles than having go figure out the pages backing a random vma (get_user_pages()) and keeping track of things on a per-page basis. However, tile-based page flipping can be implemented without major changes in graphics stack and it may improve double-buffered 2D rendering performance by reducing amount of blitted pixels by reusing unchanged pages. If GPU's ROP units can take pixels from one location(front buffer) and put results to another one(back buffer), blitting may be completely avoided if a small area of double buffered window is updated. Taking pixels from one location to another sounds like blitting to me. But anyways, client GL app blitting (or otherwise) directly into front buffer is basically defeating the purpose of dri2 And tile base page flipping is an orthogonal topic to userspace vs kernel memory management. As for security, there are thousands of ways to peeform a DoS attack. In windows, one can eat so much ram, so user will be unable to kill an app because the task manager will not start. To avoid this, some memory must be reserved for emergency situation, enough to perform 2D rendering by single client. Multiple clients will be able to render their gui without caching of window contents even under stress conditions. Also, kernel dri module must be able to warn a client if it must return memory to system and reset it's context on task manager request With the current GEM design, buffers can be swapped out under memory pressure, or the appropriate cleanup done if OOM killer kills a userspace process. Doing the memory management in userspace, there are just so many ways that things can go wrong. And once you've fixed those, you end up with something more complex. Sorry, it is just a really bad idea. BR, -R Regards, Dmitry. Пользователь Rob Clark robdcl...@gmail.com писал: right, but the time you do that, you've implemented enough memory tracking/management in the kernel, so you don't really win on complexity. Otherwise those pinned pages will remain pinned, and you are still out of memory. BR, -R On Fri, Sep 27, 2013 at 7:53 PM, dm.leontiev7 dm.leonti...@gmail.com wrote: DoS from client app is a certainly a problem if we can't interrupt a program. But we can. The program ate all gpu ram, ok. Let wm to cast oom killer on gpu ram eater.j Пользователь Rob Clark robdcl...@gmail.com писал: sure, but userspace memory management is not a good idea for gpu's which cannot support page fault resume, as it requires pinning pages. In the best case (ignoring other issues), it allows any userspace that can use GPU easily construct a DoS attach by pinning all available memory. BR, -R On Fri, Sep 27, 2013 at 6:54 PM, dm.leontiev7 dm.leonti...@gmail.com wrote: My idea targets not only new gpus. it targets any GPU with MMU. I just want the idea to be not patentable. Пользователь Rob Clark robdcl...@gmail.com писал: new gpu's can support coherency.. this is the HSA stuff (latest generation of radeon can support, and I think latest nv stuff as well.. probably not any current intel hw, though). What Jerome was talking about is a bit different from what you are trying to do. On Fri, Sep 27, 2013 at 6:41 PM, dm.leontiev7 dm.leonti...@gmail.com wrote: Passing structures... well, maybe sometimes in future. But NOW we are not living in infuture. Right now gpus doesn't support cache snooping, memory coherence protocols like MESI or MOESI. Radeon cache is read-only. And memory is NUMA. Just forget about coherence. I see no point in fighting selfmade problems. Really. Пользователь Rob Clark robdcl...@gmail.com писал: Jerome's talk was about something above and beyond opencl, where you can just pass data structures (which can include cpu userspace
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
At least, dt binding shoul be done in real device driver so this way
is not good. Let's find a better way.
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
I don't mean that the bridge device should be initialized by fimd
directly but the fimd driver provides just interfaces abstracted to
control the bridge device. And basically, the exynos_drm_display_ops
shouldn't be in fimd driver but in real connector driver; i.e. lcd
panel or LVDS driver. The reason I placed the exynos_drm_display_ops
in fimd driver is that lcd panel driver is controlled by lcd class
depended on Linux framebuffer, and I thought the panel driver should
be shared with drm driver in case of ARM SoC. The
exynos_drm_display_ops should be moved into right place if something
better exists some time or other.
So how can the DP driver control the bridge device as of now? the DP
you mentioned would be eDP, and the eDP driver is placed in
drivers/video/exynos/, and also MIPI-DSI driver.
Since the actual crtc/encoder drivers are abstracted through
exynos_drm_core/crtc/encoder, we need to initialize the ptn driver in
the abstraction layers in order to hook it directly into drm.
Sean
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(ptn3460-bridge, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client,
bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device
*dev,
DRM_ERROR(failed to create
[Bug 70088] New: Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 Priority: medium Bug ID: 70088 Assignee: dri-devel@lists.freedesktop.org Summary: Glamor on r600g crashes Xserver Severity: normal Classification: Unclassified OS: All Reporter: sob...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 87079 -- https://bugs.freedesktop.org/attachment.cgi?id=87079action=edit Crash log When I try to run Xserver and radeon driver with glamor accel method I get a crash from Xserver. It happens when I'm starting blackbox or Gnome(from GDM3). While GNOME causes crash, gdm3 works. -- 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 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
At least, dt binding shoul be done in real device driver so this way
is not good. Let's find a better way.
Right, so this is kind of tricky. If you do it in a real device
driver, you end up parsing the dt stuff in the probe, and then racing
the init callback. I figured it would be best just to do everything in
one place without races.
Hopefully I'm just missing a good way to solve this problem, any concrete ideas?
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
I don't mean that the bridge device should be initialized by fimd
directly but the fimd driver provides just interfaces abstracted to
control the bridge device. And basically, the exynos_drm_display_ops
shouldn't be in fimd driver but in real connector driver; i.e. lcd
panel or LVDS driver. The reason I placed the exynos_drm_display_ops
in fimd driver is that lcd panel driver is controlled by lcd class
depended on Linux framebuffer, and I thought the panel driver should
be shared with drm driver in case of ARM SoC. The
exynos_drm_display_ops should be moved into right place if something
better exists some time or other.
So how can the DP driver control the bridge device as of now? the DP
you mentioned would be eDP, and the eDP driver is placed in
drivers/video/exynos/, and also MIPI-DSI driver.
It can't. The DP driver just operates on its own and display either
comes up or it doesn't depending on whether fimd happens to be
initialized first. As I mentioned earlier, I have a patch set which
moves DP driver into drm/exynos and removes the display_ops from fimd.
That will fix this issue.
Sean
Since the actual crtc/encoder drivers are abstracted through
exynos_drm_core/crtc/encoder, we need to initialize the ptn driver in
the abstraction layers in order to hook it directly into drm.
Sean
Thanks,
Inki Dae
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of
Re: A simple alternative to GEMr
Hi, DirectFB is a good example of doing it all in userspace. It works but at the cost of ending up with pretty custom interfaces and non-standard ways of handling things such as buffer addresses (physical) w.r.t to h/w acceleration, IPC/RPC, buffer sharing for multi-process support, etc. Memory management (and dma) has to be the kernel's duty. Ilyes On Thu, Oct 3, 2013 at 6:00 PM, Rob Clark robdcl...@gmail.com wrote: On Thu, Oct 3, 2013 at 7:48 AM, dm.leontiev7 dm.leonti...@gmail.com wrote: Hello In my opinion, graphics stack will benefit from moving memory management to userspace because there are tons of features not available in kernel, like simd or c++. both of which bring no benefit to memory management code Also, bugs in buffer management code will bite only one process, not the whole system. As soon as you need to pin pages (which you need to do, except for the hw that Jerome is targetting with his proposal where the GPU can really support virtual memory), memory management becomes a whole system issue.. pinning pages can only be done from the kernel and it is pretty frowned upon to have a driver that lets userspace pin arbitrary pages without being able to keep track of those pages and clean up. Anyways, it is much better to trust the kernel than userspace. In system design, you must assume userspace is untrusted. If you have enough tracking for random pages that userspace asks the kernel to pin for the gpu in order to cleanup when userspace process dies, then you have *more* complexity than what you have in GEM. Trust me, it is far easier for the kernel to deal with buffer handles than having go figure out the pages backing a random vma (get_user_pages()) and keeping track of things on a per-page basis. However, tile-based page flipping can be implemented without major changes in graphics stack and it may improve double-buffered 2D rendering performance by reducing amount of blitted pixels by reusing unchanged pages. If GPU's ROP units can take pixels from one location(front buffer) and put results to another one(back buffer), blitting may be completely avoided if a small area of double buffered window is updated. Taking pixels from one location to another sounds like blitting to me. But anyways, client GL app blitting (or otherwise) directly into front buffer is basically defeating the purpose of dri2 And tile base page flipping is an orthogonal topic to userspace vs kernel memory management. As for security, there are thousands of ways to peeform a DoS attack. In windows, one can eat so much ram, so user will be unable to kill an app because the task manager will not start. To avoid this, some memory must be reserved for emergency situation, enough to perform 2D rendering by single client. Multiple clients will be able to render their gui without caching of window contents even under stress conditions. Also, kernel dri module must be able to warn a client if it must return memory to system and reset it's context on task manager request With the current GEM design, buffers can be swapped out under memory pressure, or the appropriate cleanup done if OOM killer kills a userspace process. Doing the memory management in userspace, there are just so many ways that things can go wrong. And once you've fixed those, you end up with something more complex. Sorry, it is just a really bad idea. BR, -R Regards, Dmitry. Пользователь Rob Clark robdcl...@gmail.com писал: right, but the time you do that, you've implemented enough memory tracking/management in the kernel, so you don't really win on complexity. Otherwise those pinned pages will remain pinned, and you are still out of memory. BR, -R On Fri, Sep 27, 2013 at 7:53 PM, dm.leontiev7 dm.leonti...@gmail.com wrote: DoS from client app is a certainly a problem if we can't interrupt a program. But we can. The program ate all gpu ram, ok. Let wm to cast oom killer on gpu ram eater.j Пользователь Rob Clark robdcl...@gmail.com писал: sure, but userspace memory management is not a good idea for gpu's which cannot support page fault resume, as it requires pinning pages. In the best case (ignoring other issues), it allows any userspace that can use GPU easily construct a DoS attach by pinning all available memory. BR, -R On Fri, Sep 27, 2013 at 6:54 PM, dm.leontiev7 dm.leonti...@gmail.com wrote: My idea targets not only new gpus. it targets any GPU with MMU. I just want the idea to be not patentable. Пользователь Rob Clark robdcl...@gmail.com писал: new gpu's can support coherency.. this is the HSA stuff (latest generation of radeon can support, and I think latest nv stuff as well.. probably not any current intel hw, though). What Jerome was talking about is a bit different from what you are trying to do. On Fri, Sep 27, 2013 at 6:41 PM, dm.leontiev7 dm.leonti...@gmail.com wrote: Passing
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more
[PATCH] drm/doc: Document drm_add_modes_noedid() usage
From: Laurent Pinchart laurent.pinch...@ideasonboard.com And fix a spelling mistake. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/drm.tmpl | 24 +++- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ed1d6d2..53963be 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1781,10 +1781,16 @@ void intel_crt_init(struct drm_device *dev) and then retrieves a list of modes by calling the connector methodnameget_modes/methodname helper operation. /para + para +If the helper operation returns no mode, and if the connector status +is connector_status_connected, standard VESA DMT modes up to +1024x768 are automatically added to the modes list by a call to +functiondrm_add_modes_noedid/function. + /para para -The function filters out modes larger than +The function then filters out modes larger than parametermax_width/parameter and parametermax_height/parameter -if specified. It then calls the connector +if specified. It finally calls the connector methodnamemode_valid/methodname helper operation for each mode in the probed list to check whether the mode is valid for the connector. /para @@ -1924,12 +1930,20 @@ void intel_crt_init(struct drm_device *dev) synopsisint (*get_modes)(struct drm_connector *connector);/synopsis para Fill the connector's structfieldprobed_modes/structfield list -by parsing EDID data with functiondrm_add_edid_modes/function or -calling functiondrm_mode_probed_add/function directly for every +by parsing EDID data with functiondrm_add_edid_modes/function, +adding standard VESA DMT modes with functiondrm_add_modes_noedid/function, +or calling functiondrm_mode_probed_add/function directly for every supported mode and return the number of modes it has detected. This operation is mandatory. /para para +Note that the caller function will automatically add standard VESA +DMT modes up to 1024x768 if the methodnameget_modes/methodname +helper operation returns no mode and if the connector status is +connector_status_connected. There is no need to call +functiondrm_add_edid_modes/function manually in that case. + /para + para When adding modes manually the driver creates each mode with a call to functiondrm_mode_create/function and must fill the following fields. itemizedlist @@ -2126,7 +2140,7 @@ void intel_crt_init(struct drm_device *dev) functiondrm_helper_probe_single_connector_modes/function. /para para -When parsing EDID data, functiondrm_add_edid_modes/function fill the +When parsing EDID data, functiondrm_add_edid_modes/function fills the connector structfielddisplay_info/structfield structfieldwidth_mm/structfield and structfieldheight_mm/structfield fields. When creating modes -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #1 from Grigori Goronzy g...@chown.ath.cx --- That looks exactly like the crash I see on PALM ASICs, too. I just didn't have time to properly report it yet. Something is going wrong in SB's gcm phase. This only seems to happen on certain ASICs, it works fine on TURKS. -- 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 45641] Screen goes black randomly
https://bugs.freedesktop.org/show_bug.cgi?id=45641 --- Comment #19 from John john.etted...@gmail.com --- Still same behavior with current drivers/kernel/mesa, I was hoping something would have helped :) Alex, do you have any other patch I can test against this? Thanks, John -- 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 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae inki@samsung.com wrote: 2013/10/3 Sean Paul seanp...@chromium.org: On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote: Can a regulator be used instead of gpio in other board case? No, not to my knowledge. Hm.. plz check it out again. the gpio pin is specific to board, and the the gpio be used as power source trigger could be replaced with a regulator according to board design. So you should consider all possibilities even though there are no other cases yet: other board could use a regulator instead. Take a look at the data sheet, it is publicly available. PD_N is not a power supply input, so modelling it as a regulator makes no sense: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. -Olof ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae inki@samsung.com wrote:
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 44
+++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..9cf4476 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/of_i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *name, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_node_by_name(NULL, name);
Not clear to me. Why do you try to handle device tree here, not real
device driver?. How about adding a output property to board specific
fimd dt node: i.e. output = ptn3460_bridge?
The problem doing something like this is that we won't have a handle
to drm_device if it's just a standalone driver, and so we won't be
able to register the bridge or connector. We need this init call one
way or another.
At least, dt binding shoul be done in real device driver so this way
is not good. Let's find a better way.
Right, so this is kind of tricky. If you do it in a real device
driver, you end up parsing the dt stuff in the probe, and then racing
the init callback. I figured it would be best just to do everything in
one place without races.
Hopefully I'm just missing a good way to solve this problem, any concrete
ideas?
Actually, the output
device of fimd hw could be one of MIPI-DSI, eDP, mDNIe, LVDS bridge,
or LCD. And then, let's find ptn3460-bridge node in the fimd driver,
and initialize the ptn3460 bridge driver, and get power on or off
through exynos_drm_display_ops of the fimd driver. And all these
codes could be hided from fimd driver by moving them into
exynos_drm_display_ops. Of course, for this, you would need additional
works. So let's do it if needed.
The below is the outline of device tree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = ptn3460_bridge;
}
With this, I believe that you can do all things you want for
controlling the LVDS bridge in fimd driver.
No, this isn't what I want to do. The bridge should not hang off fimd
since it's a crtc. The bridge should only be initialized by the DP
driver (it doesn't make sense to initialize ptn when you're using
MIPI/LVDS/whatever).
I don't mean that the bridge device should be initialized by fimd
directly but the fimd driver provides just interfaces abstracted to
control the bridge device. And basically, the exynos_drm_display_ops
shouldn't be in fimd driver but in real connector driver; i.e. lcd
panel or LVDS driver. The reason I placed the exynos_drm_display_ops
in fimd driver is that lcd panel driver is controlled by lcd class
depended on Linux framebuffer, and I thought the panel driver should
be shared with drm driver in case of ARM SoC. The
exynos_drm_display_ops should be moved into right place if something
better exists some time or other.
So how can the DP driver control the bridge device as of now? the DP
you mentioned would be eDP, and the eDP driver is placed in
drivers/video/exynos/, and also MIPI-DSI driver.
It can't. The DP driver just operates on its own and display either
comes up or it doesn't depending on whether fimd happens to be
initialized first.
Ok, I don't know the DP hardware well. But, MIPI-DSI driver is
depending on fimd on/off ordering. ie. to enable display hw pipe, the
ordering should be FIMDMIPI-DSI-LCD because initial commands
_cannot be set_ to lcd panel if fimd is off. And to disable that, the
ordering should be LCD---MIPI-DSI---FIMD in same reason: to
get lcd panel off, off commands should be set to lcd panel. In similar
reason, I had posted FB_EARLY_EVENT_BLANK feature to mainline and that
have been merged.
As I mentioned earlier, I have a patch set which
moves DP driver into
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 Krzysztof A. Sobiecki sob...@gmail.com changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- 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 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #2 from Vadim Girlin pt...@yandex.ru --- Please attach the output with R600_DEBUG=ps,vs -- 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 66673] NULL pointer dereference on BONAIRE (hd7790) after starting X server
https://bugs.freedesktop.org/show_bug.cgi?id=66673 --- Comment #5 from Dmitry Derevyanko nrn...@gmail.com --- With kernel: 3.11.3 gentoo version mesa: git(Oct 3) builded with gles xf86-video-ati: git(Oct 3) libdrm: git(Oct 3) llvm: git(Oct 3) glamor: git(Oct 3) builded without gles I can boot to kde (with radeon.dpm=1 in kernel cmdline) but some activity in firefox leads to GPU lockup, what has nothing to do with this bug. Without gles in mesa I can't boot at all. As described before. Maybe it'll help find problem. -- 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.11-rc7: i915: stuck on render ring
On Wed 2013-09-04 11:08:14, Chris Wilson wrote: On Tue, Sep 03, 2013 at 09:06:47PM +0200, Pavel Machek wrote: Hi! I was happily using X... and then screen froze. Mouse still moves. Switching to text console still worked, good. It is first time in a while, normally this machine works well. i915_error_state is attached. Any ideas? It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29). Aha, so I need to update X or rather debian should update the X server. Thanks for the info. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #3 from Marek Olšák mar...@gmail.com --- You should be able to obtain a better backtrace if you do this: 1) Delete /etc/X11/core. 2) Reproduce the crash. This should create a new core file in /etc/X11. 3) Run: gdb /usr/bin/Xorg /etc/X11/core 4) Type bt in gdb. The paths may differ depending on your distribution. Please attach the backtrace you will get from gdb. -- 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 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #11 from Chris Rankin ranki...@googlemail.com --- This issue is now fixed for me, presumably by: commit b893bbf438e1924d5f47370b29421642e79b0221 Author: Marek Olšák marek.ol...@amd.com Date: Thu Oct 3 16:39:50 2013 +0200 r600g,radeonsi: create aux_context last This fixes a regression caused by 68f6dec32ed5eede361f76c8dbdf897652659baf. -- 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 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Marek Olšák mar...@gmail.com --- Ok, I'm closing this bug. -- 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 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #4 from Grigori Goronzy g...@chown.ath.cx --- Created attachment 87094 -- https://bugs.freedesktop.org/attachment.cgi?id=87094action=edit Xorg log with shader dump and sb dump -- 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 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #5 from Grigori Goronzy g...@chown.ath.cx --- Created attachment 87095 -- https://bugs.freedesktop.org/attachment.cgi?id=87095action=edit Xorg backtrace -- 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 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 --- Comment #3 from Tom Stellard tstel...@gmail.com --- It looks the EP test is failing, because the compiler doesn't support double operations yet. I'm guessing the other tests are failing for the same reason. Adding support for doubles is relatively straight forward. If you are interested in working on this, let me know and I can help give you some pointers. -- 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
[PATCH v2 0/5] Add some missing bits for exynos5250-snow
This set adds some missing devicetree nodes to the exynos5250-snow file as well as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in the exynos5250-snow board. Sean Sean Paul (5): ARM: dts: Add fimd display-timings for exynos5250-snow ARM: dts: Add dp-controller node to exynos5250-snow drm/bridge: Add PTN3460 bridge driver drm/exynos: Initialize ptn3460 if present ARM: dts: Add ptn3460 to exynos5250-snow Documentation/devicetree/bindings/drm/bridge/ptn3460.txt | 27 +++ arch/arm/boot/dts/exynos5250-snow.dts| 48 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/bridge/Kconfig | 4 + drivers/gpu/drm/bridge/Makefile | 3 + drivers/gpu/drm/bridge/ptn3460.c | 349 drivers/gpu/drm/exynos/exynos_drm_core.c | 44 - include/drm/bridge/ptn3460.h | 37 9 files changed, 514 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] ARM: dts: Add fimd display-timings for exynos5250-snow
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: No difference
arch/arm/boot/dts/exynos5250-snow.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd711e2..2a0f0de 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,23 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ fimd: fimd@1440 {
+ display-timings {
+ native-mode = lcd_timing;
+ lcd_timing: 1366x768 {
+ clock-frequency = 70589280;
+ hactive = 1366;
+ vactive = 768;
+ hfront-porch = 40;
+ hback-porch = 40;
+ hsync-len = 32;
+ vback-porch = 10;
+ vfront-porch = 12;
+ vsync-len = 6;
+ };
+ };
+ };
+
fixed-rate-clocks {
xxti {
compatible = samsung,clock-xxti;
--
1.8.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: Added dp-controller address to node (rebased on linux-next)
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 2a0f0de..f1cf68e 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -186,6 +186,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ dp-controller@145B {
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ };
+
fimd: fimd@1440 {
display-timings {
native-mode = lcd_timing;
--
1.8.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/bridge: Add PTN3460 bridge driver
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed header definition to static inline
- Changed dt node name to lvds-bridge
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349 +
include/drm/bridge/ptn3460.h | 37 +++
7 files changed, 423 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..52b93b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460 bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ lvds-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+
+#include drmP.h
+#include drm_edid.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+#include bridge/ptn3460.h
+
+#define PTN3460_EDID_ADDR 0x0
+#define PTN3460_EDID_EMULATION_ADDR0x84
+#define PTN3460_EDID_ENABLE_EMULATION 0
+#define PTN3460_EDID_EMULATION_SELECTION 1
+#define PTN3460_EDID_SRAM_LOAD_ADDR0x85
+
+struct ptn3460_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+
[PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2:
- Changed include from of_i2c.h to i2c.h
- Changed of_find_by_name to of_find_compatible
drivers/gpu/drm/exynos/exynos_drm_core.c | 44 +++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 1bef6dc..08ca4f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -12,7 +12,9 @@
* option) any later version.
*/
+#include linux/i2c.h
#include drm/drmP.h
+#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
@@ -20,6 +22,40 @@
static LIST_HEAD(exynos_drm_subdrv_list);
+struct bridge_init {
+ struct i2c_client *client;
+ struct device_node *node;
+};
+
+static bool find_bridge(const char *compat, struct bridge_init *bridge)
+{
+ bridge-client = NULL;
+ bridge-node = of_find_compatible_node(NULL, NULL, compat);
+ if (!bridge-node)
+ return false;
+
+ bridge-client = of_find_i2c_device_by_node(bridge-node);
+ if (!bridge-client)
+ return false;
+
+ return true;
+}
+
+/* returns the number of bridges attached */
+static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
+ struct drm_encoder *encoder)
+{
+ struct bridge_init bridge;
+ int ret;
+
+ if (find_bridge(nxp,ptn3460, bridge)) {
+ ret = ptn3460_init(dev, encoder, bridge.client, bridge.node);
+ if (!ret)
+ return 1;
+ }
+ return 0;
+}
+
static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
@@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
DRM_ERROR(failed to create encoder\n);
return -EFAULT;
}
+ subdrv-encoder = encoder;
+
+ if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) {
+ ret = exynos_drm_attach_lcd_bridge(dev, encoder);
+ if (ret)
+ return 0;
+ }
/*
* create and initialize a connector for this sub driver and
@@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device *dev,
goto err_destroy_encoder;
}
- subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
--
1.8.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] ARM: dts: Add ptn3460 to exynos5250-snow
This patch adds a node for the ptn3460 DP-LVDS chip in the
exynos5250-snow board dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
---
v2: Changed node name to lvds-bridge
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index f1cf68e..2870205 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -33,6 +33,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = 0;
};
+
+ ptn3460_gpios: ptn3460-gpios {
+ samsung,pins = gpy2-5, gpx1-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
gpio-keys {
@@ -186,6 +193,18 @@
samsung,vbus-gpio = gpx1 1 0;
};
+ i2c@12CD {
+ lvds-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 0;
+ reset-gpio = gpx1 5 0;
+ edid-emulation = 5;
+ pinctrl-names = default;
+ pinctrl-0 = ptn3460_gpios;
+ };
+ };
+
dp-controller@145B {
samsung,color-space = 0;
samsung,dynamic-range = 0;
--
1.8.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add some missing bits for exynos5250-snow
On Thu, Oct 3, 2013 at 3:28 PM, Sean Paul seanp...@chromium.org wrote: This set adds some missing devicetree nodes to the exynos5250-snow file as well as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in the exynos5250-snow board. Sean Series: Acked-by: Olof Johansson o...@lixom.net -Olof ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70104] New: radeonsi_compute.c:260:11: error: 'struct pipe_context' has no member named 'bind_compute_sampler_states'
https://bugs.freedesktop.org/show_bug.cgi?id=70104 Priority: medium Bug ID: 70104 Keywords: regression CC: bri...@vmware.com Assignee: dri-devel@lists.freedesktop.org Summary: radeonsi_compute.c:260:11: error: 'struct pipe_context' has no member named 'bind_compute_sampler_states' Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa mesa: 800610f9eb6ad24b5fefc9206fb700c7ae2f0ec8 (master) CC radeonsi_compute.lo radeonsi_compute.c: In function 'si_init_compute_functions': radeonsi_compute.c:260:11: error: 'struct pipe_context' has no member named 'bind_compute_sampler_states' rctx-b.b.bind_compute_sampler_states = si_bind_compute_sampler_states; ^ -- 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 70104] radeonsi_compute.c:260:11: error: 'struct pipe_context' has no member named 'bind_compute_sampler_states'
https://bugs.freedesktop.org/show_bug.cgi?id=70104 Brian Paul bri...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Brian Paul bri...@vmware.com --- I just pushed a fix: 99a471c67bd0de1aad69b0219c056a7345ea0a33 -- 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 70106] New: si_state.c:2776:13: error: conflicting types for 'si_bind_sampler_states'
https://bugs.freedesktop.org/show_bug.cgi?id=70106 Priority: medium Bug ID: 70106 Keywords: regression CC: bri...@vmware.com Assignee: dri-devel@lists.freedesktop.org Summary: si_state.c:2776:13: error: conflicting types for 'si_bind_sampler_states' Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa mesa: 757ec72b23bac52052c2fb98105b52699e265a24 (master) CC si_state.lo si_state.c:2776:13: error: conflicting types for 'si_bind_sampler_states' static void si_bind_sampler_states(struct pipe_context *ctx, unsigned shader, ^ si_state.c:2681:29: note: previous definition of 'si_bind_sampler_states' was here static struct si_pm4_state *si_bind_sampler_states(struct r600_context *rctx, unsigned count, ^ -- 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 70106] si_state.c:2776:13: error: conflicting types for 'si_bind_sampler_states'
https://bugs.freedesktop.org/show_bug.cgi?id=70106 --- Comment #1 from Brian Paul bri...@vmware.com --- Created attachment 87097 -- https://bugs.freedesktop.org/attachment.cgi?id=87097action=edit patch to try Can you try the attached patch? I can't build radeonsi ATM. I guess nobody tested my branch. -- 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 70106] si_state.c:2776:13: error: conflicting types for 'si_bind_sampler_states'
https://bugs.freedesktop.org/show_bug.cgi?id=70106 Tom Stellard tstel...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Stellard tstel...@gmail.com --- This patch works for me, and I've pushed it. Thanks. -- 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 69983] [r600g, bisected] Screen corruption in Firefox, World of Warcraft and other apps
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #13 from Jos van Wolput wol...@onsneteindhoven.nl --- (In reply to comment #12) Ok, I'm closing this bug. Thanks, demos running well, issue fixed! -- 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 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae inki@samsung.com wrote:
2013/10/4 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae inki@samsung.com wrote:
2013/10/3 Sean Paul seanp...@chromium.org:
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae inki@samsung.com wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul seanp...@chromium.org:
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul seanp...@chromium.org
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 4 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349
+
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 422 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: nxp,ptn3460
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
Can a regulator be used instead of gpio in other board case?
No, not to my knowledge.
Hm.. plz check it out again. the gpio pin is specific to board, and
the the gpio be used as power source trigger could be replaced with a
regulator according to board design. So you should consider all
possibilities even though there are no other cases yet: other board
could use a regulator instead.
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = nxp,ptn3460;
+ reg = 0x20;
+ powerdown-gpio = gpy2 5 1 0 0;
+ reset-gpio = gpx1 5 1 0 0;
+ edid-emulation = 5;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..cd7bfb3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/bridge/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9234253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-$(CONFIG_DRM_MSM) += msm/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig
b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..f8db069
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,4 @@
+config DRM_PTN3460
+ tristate PTN3460 DP/LVDS bridge
+ depends on DRM I2C
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This
