[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 --- Created attachment 87013 --> https://bugs.freedesktop.org/attachment.cgi?id=87013&action=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 --- Created attachment 87014 --> https://bugs.freedesktop.org/attachment.cgi?id=87014&action=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 CC: Andreas Dilger CC: Andy Walls CC: Arnd Bergmann CC: Benjamin LaHaise CC: ceph-de...@vger.kernel.org CC: Dan Williams CC: David Airlie CC: dri-devel@lists.freedesktop.org CC: Gleb Natapov CC: Greg Kroah-Hartman CC: hpdd-disc...@lists.01.org CC: Jarod Wilson CC: Jayant Mangalampalli CC: Jean-Christophe Plagniol-Villard CC: Jesper Nilsson CC: Kai Makisara CC: k...@vger.kernel.org CC: Laurent Pinchart 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 CC: Mark Allyn CC: Mikael Starvik CC: Mike Marciniszyn CC: Naren Sankar CC: Paolo Bonzini CC: Peng Tao CC: Roland Dreier CC: Sage Weil CC: Scott Davilla CC: Timur Tabi CC: Tomi Valkeinen CC: Tony Luck CC: Trond Myklebust ___ 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ä
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ä
Reviewed-by: Jesse Barnes
Signed-off-by: Daniel Vetter
: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
# bad: [57779d06367a915ee03e6cb918d7575f0a46e419] drm/i915: Fix
display pixel format handling
gi
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 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 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 --- 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 --- (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 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][] dump_stack+0x7a/0x97 [13766.703382] [] warn_slowpath_common+0x87/0xb0 [13766.703388] [] warn_slowpath_fmt+0x41/0x50 [13766.703425] [] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [] handle_irq_event_percpu+0xac/0x220 [13766.703442] [] handle_irq_event+0x49/0x70 [13766.703449] [] handle_edge_irq+0x7f/0x150 [13766.703454] [] handle_irq+0x59/0x150 [13766.703461] [] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [] do_IRQ+0x5b/0xe0 [13766.703474] [] common_interrupt+0x6f/0x6f [13766.703482][] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [] cpuidle_idle_call+0x10a/0x160 [13766.703503] [] arch_cpu_idle+0x9/0x30 [13766.703509] [] cpu_idle_loop+0x8b/0x270 [13766.703515] [] cpu_startup_entry+0x1e/0x20 [13766.703522] [] 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 wrote: > During resume from hibernation, I started to see the warning below since > > commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b > Author: Egbert Eich > 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][] dump_stack+0x7a/0x97 > [13766.703382] [] warn_slowpath_common+0x87/0xb0 > [13766.703388] [] warn_slowpath_fmt+0x41/0x50 > [13766.703425] [] i965_irq_handler+0x492/0x680 [i915] > [13766.703436] [] handle_irq_event_percpu+0xac/0x220 > [13766.703442] [] handle_irq_event+0x49/0x70 > [13766.703449] [] handle_edge_irq+0x7f/0x150 > [13766.703454] [] handle_irq+0x59/0x150 > [13766.703461] [] ? atomic_notifier_call_chain+0x11/0x20 > [13766.703466] [] do_IRQ+0x5b/0xe0 > [13766.703474] [] common_interrupt+0x6f/0x6f > [13766.703482][] ? cpuidle_enter_state+0x54/0xd0 > [13766.703488] [] ? cpuidle_enter_state+0x50/0xd0 > [13766.703496] [] cpuidle_idle_call+0x10a/0x160 > [13766.703503] [] arch_cpu_idle+0x9/0x30 > [13766.703509] [] cpu_idle_loop+0x8b/0x270 > [13766.703515] [] cpu_startup_entry+0x1e/0x20 > [13766.703522] [] 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 , 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 , 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 --- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Alex Deucher --- *** 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 changed: What|Removed |Added CC||marvi...@gmx.de --- Comment #10 from Alex Deucher --- *** 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
[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
With the agp_init call moved back into pci code this series is
Reviewed-by: Daniel Vetter
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 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
>
> [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 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 :
> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
> bridge chip.
>
> Signed-off-by: Sean Paul
> ---
> .../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
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#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
> +#de
[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 --- Created attachment 87033 --> https://bugs.freedesktop.org/attachment.cgi?id=87033&action=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 changed: What|Removed |Added Attachment #87033|0 |1 is obsolete|| --- Comment #5 from Alex Deucher --- Created attachment 87044 --> https://bugs.freedesktop.org/attachment.cgi?id=87044&action=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 wrote: > > During resume from hibernation, I started to see the warning below since > > > > commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b > > Author: Egbert Eich > > 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][] dump_stack+0x7a/0x97 > > [13766.703382] [] warn_slowpath_common+0x87/0xb0 > > [13766.703388] [] warn_slowpath_fmt+0x41/0x50 > > [13766.703425] [] i965_irq_handler+0x492/0x680 [i915] > > [13766.703436] [] handle_irq_event_percpu+0xac/0x220 > > [13766.703442] [] handle_irq_event+0x49/0x70 > > [13766.703449] [] handle_edge_irq+0x7f/0x150 > > [13766.703454] [] handle_irq+0x59/0x150 > > [13766.703461] [] ? > > atomic_notifier_call_chain+0x11/0x20 > > [13766.703466] [] do_IRQ+0x5b/0xe0 > > [13766.703474] [] common_interrupt+0x6f/0x6f > > [13766.703482][] ? > > cpuidle_enter_state+0x54/0xd0 > > [13766.703488] [] ? cpuidle_enter_state+0x50/0xd0 > > [13766.703496] [] cpuidle_idle_call+0x10a/0x160 > > [13766.703503] [] arch_cpu_idle+0x9/0x30 > > [13766.703509] [] cpu_idle_loop+0x8b/0x270 > > [13766.703515] [] cpu_startup_entry+0x1e/0x20 > > [13766.703522] [] 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 :
> 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
> ---
> 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
> #include
> +#include
> #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 wrote:
> Hi, thank you for your contribution and the below is my short comments,
>
> 2013/10/2 Sean Paul :
>> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
>> bridge chip.
>>
>> Signed-off-by: Sean Paul
>> ---
>> .../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
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "drmP.h"
>> +#include "drm_edid.h
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
> 2013/10/2 Sean Paul :
>> 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
>> ---
>> 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
>> #include
>> +#include
>> #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
Re: [PATCH 2/5] ARM: dts: Add dp-controller node to exynos5250-snow
On Wed, Oct 2, 2013 at 5:10 PM, Olof Johansson wrote:
> On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul wrote:
>> This patch adds the dp-controller node to the exynos5250-snow board dts
>> file.
>>
>> Signed-off-by: Sean Paul
>> ---
>> 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" : > 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 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 писал: > >>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 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 писал: >>> 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 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 писал: > >>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 >>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 писал: >>> Jerome's talk was abou
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
>> 2013/10/2 Sean Paul :
>>> 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
>>> ---
>>> 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
>>> #include
>>> +#include
>>> #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,
>>>
[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=87079&action=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 wrote:
> 2013/10/4 Sean Paul :
>> On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
>>> 2013/10/2 Sean Paul :
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
---
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
#include
+#include
#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
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 wrote: > On Thu, Oct 3, 2013 at 7:48 AM, dm.leontiev7 > 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 писал: > > > >>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 > 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 писал: > >>> > 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 > 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 писал: > > > >>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 fr
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/3 Sean Paul :
> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>> Hi, thank you for your contribution and the below is my short comments,
>>
>> 2013/10/2 Sean Paul :
>>> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
>>> bridge chip.
>>>
>>> Signed-off-by: Sean Paul
>>> ---
>>> .../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, an
[PATCH] drm/doc: Document drm_add_modes_noedid() usage
From: Laurent Pinchart And fix a spelling mistake. Signed-off-by: Laurent Pinchart --- 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 get_modes helper operation. + +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 +drm_add_modes_noedid. + -The function filters out modes larger than +The function then filters out modes larger than max_width and max_height -if specified. It then calls the connector +if specified. It finally calls the connector mode_valid helper operation for each mode in the probed list to check whether the mode is valid for the connector. @@ -1924,12 +1930,20 @@ void intel_crt_init(struct drm_device *dev) int (*get_modes)(struct drm_connector *connector); Fill the connector's probed_modes list -by parsing EDID data with drm_add_edid_modes or -calling drm_mode_probed_add directly for every +by parsing EDID data with drm_add_edid_modes, +adding standard VESA DMT modes with drm_add_modes_noedid, +or calling drm_mode_probed_add directly for every supported mode and return the number of modes it has detected. This operation is mandatory. +Note that the caller function will automatically add standard VESA +DMT modes up to 1024x768 if the get_modes +helper operation returns no mode and if the connector status is +connector_status_connected. There is no need to call +drm_add_edid_modes manually in that case. + + When adding modes manually the driver creates each mode with a call to drm_mode_create and must fill the following fields. @@ -2126,7 +2140,7 @@ void intel_crt_init(struct drm_device *dev) drm_helper_probe_single_connector_modes. -When parsing EDID data, drm_add_edid_modes fill the +When parsing EDID data, drm_add_edid_modes fills the connector display_info width_mm and height_mm 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 --- 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 --- 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 wrote: > 2013/10/3 Sean Paul : >> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae 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 wrote:
> 2013/10/3 Sean Paul :
>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>>> Hi, thank you for your contribution and the below is my short comments,
>>>
>>> 2013/10/2 Sean Paul :
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
.../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.
+ *
Re: [PATCH 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae wrote:
>> 2013/10/4 Sean Paul :
>>> On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
2013/10/2 Sean Paul :
> 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
> ---
> 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
> #include
> +#include
> #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---
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 Krzysztof A. Sobiecki 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 :
> On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
>> 2013/10/3 Sean Paul :
>>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul :
> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
> bridge chip.
>
> Signed-off-by: Sean Paul
> ---
> .../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/
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae wrote:
> 2013/10/4 Sean Paul :
>> On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
>>> 2013/10/3 Sean Paul :
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
> Hi, thank you for your contribution and the below is my short comments,
>
> 2013/10/2 Sean Paul :
>> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
>> bridge chip.
>>
>> Signed-off-by: Sean Paul
>> ---
>> .../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/bri
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #2 from Vadim Girlin --- 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 --- 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 --- 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 --- This issue is now fixed for me, presumably by: commit b893bbf438e1924d5f47370b29421642e79b0221 Author: Marek Olšák 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Marek Olšák --- 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 --- Created attachment 87094 --> https://bugs.freedesktop.org/attachment.cgi?id=87094&action=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 --- Created attachment 87095 --> https://bugs.freedesktop.org/attachment.cgi?id=87095&action=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 --- 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
---
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
---
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
---
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
+#include
+#include
+#include
+#include
+#include
+
+#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;
+ struct drm_encoder *encoder;
+ struct drm_bridge *b
[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
---
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
#include
+#include
#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
---
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 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 -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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Brian Paul --- 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 --- Created attachment 87097 --> https://bugs.freedesktop.org/attachment.cgi?id=87097&action=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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Stellard --- 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 --- (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 :
> On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae wrote:
>> 2013/10/4 Sean Paul :
>>> On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
2013/10/3 Sean Paul :
> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>> Hi, thank you for your contribution and the below is my short comments,
>>
>> 2013/10/2 Sean Paul :
>>> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
>>> bridge chip.
>>>
>>> Signed-off-by: Sean Paul
>>> ---
>>> .../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 +
Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver
2013/10/4 Olof Johansson : > On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae wrote: >> 2013/10/3 Sean Paul : >>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae 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." > I still think the pin could be replaced with a regulator. But lvds-bridge node has "powerdown-gpio" property - it say this board will use gpio pin - specific to board. So it seems no problem. > > > -Olof > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present
2013/10/4 Sean Paul :
> 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
> ---
>
> 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
> #include
> +#include
> #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);
Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
that such tricky isn't needed? Is there any reason you use such tricky
codes?
I think you need to implement the lvds-bridge driver as i2c driver,
and then consider how to take care of this. I mean let's find a better
way how we could take care of the i2c based driver in exynos drm
framework or driver. In all cases, such tricky codes are not good.
> + 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70108] New: [bisected e64633e8c3a5498998a45ab721bf80edca101cf5] regression: bad rendering on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=70108 Priority: medium Bug ID: 70108 Assignee: dri-devel@lists.freedesktop.org Summary: [bisected e64633e8c3a5498998a45ab721bf80edca101cf5] regression: bad rendering on r600g Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.dem...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa I noticed a couple of days ago a regression on some demo applications where the light or shadows wouldn't be rendered correctly. They form lines. This can be observed testing Unigine where light reflecting on water or on the dock will not be rendered correctly. Bisecting gave me the following result: git bisect bad e64633e8c3a5498998a45ab721bf80edca101cf5 is the first bad commit commit e64633e8c3a5498998a45ab721bf80edca101cf5 Author: Marek Olšák Date: Sun Sep 22 13:06:27 2013 +0200 r600g,radeonsi: share r600_texture.c The function r600_choose_tiling is new and needs a review. The only change in functionality is that it enables 2D tiling for compressed textures on SI. It was probably accidentally turned off. v2: don't make scanout buffers linear :04 04 138f5235123706d30903e259a8c7651ee53e9fd5 79f8e5d3497c5d2a3c71bb6ba968ecf5fd4c1a1a Msrc I'm using HD 6950 on ArchLinux 64, with latest drm and ddx from git. -- 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 v2 4/5] drm/exynos: Initialize ptn3460 if present
On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae wrote:
> 2013/10/4 Sean Paul :
>> 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
>> ---
>>
>> 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
>> #include
>> +#include
>> #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);
>
> Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
> that such tricky isn't needed? Is there any reason you use such tricky
> codes?
>
This is what I was explaining earlier today. If the bridge driver is
just an i2c driver, it won't get a pointer to drm_device, and can't
register itself as a drm_bridge or drm_connector. To solve this, you
need the ptn3460_init callback.
If it's an i2c driver with the ptn3460_init callback, where it parses
the dt in probe, then you have a race between the ptn probe and the
ptn init/drm hooks. ie: it's possible drm will initialize and call
disable/post_disable/pre_enable/enable before things have been probed.
To solve this, you need to use some global state and/or locking.
So, to summarize. We can have this of_find_compatible with a init
callback, or we can have an i2c driver + global state/locking + init
callback. I chose the former, since it seemed easier.
If you have a better way to achieve this, I'm definitely interested,
but I saw this as the lesser of two evils.
Sean
> I think you need to implement the lvds-bridge driver as i2c driver,
> and then consider how to take care of this. I mean let's find a better
> way how we could take care of the i2c based driver in exynos drm
> framework or driver. In all cases, such tricky codes are not good.
>
>> + 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
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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(&dev_priv->rps.delayed_resume_work, intel_gen6_powersave_work); - - INIT_DELAYED_WORK(&dev_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>
