[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #12 from Christian König --- (In reply to comment #3) > Created attachment 86598 [details] [review] > use hw generated cts and n values rather than the sw programmed values > > Does this patch help? If not, it may be worth adding some slop to the > r600_hdmi_predefined_acr[] table to handle rounding differences so the > appropriate defined values get selected. On some early R6xx the hardware generation of CTS/N values didn't worked reliable, that's why I've done it like fglrx and calculated the values manually/used a table for it. -- 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 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #17 from Marco --- > Are you sure it doesn't work if you remvoe your xorg.conf completely? Yes, I'm sure. Without a xorg.conf I only have a black screen with the cursor caret in the upper left corner. I also tried disabling dpm (radeon.dpm=0) but the result is the same. I think the problem is due to having two gpus under radeon driver and glamor. -- 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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #11 from Pierre Ossman --- (In reply to comment #10) > > So what should I actually try for the second patch? What you wrote? Or the > value from the mode line? :) Which were the same, so don't mind me... -- 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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #10 from Pierre Ossman ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Something like this:
> >
> > Not really, the selection doesn't work like that - clock has to match
> > exactly to the table value, it is not an upper bound.
>
> I just meant to patch the table so that you end up using the pre-defined
> values for CTS and N rather than calculating them from the formula.
>
> { xxx, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 74.25/1.001 MHz */
>
> Replace xxx with whatever clock value the drm edid code gives you for
> 74.25/1.001 MHz.
>
So what should I actually try for the second patch? What you wrote? Or the
value from the mode line? :)
--
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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #9 from Pierre Ossman --- (In reply to comment #1) > IIRC it was the XBMC people that wanted the ntsc variants in the first place > as their player defaults to sync to video exactly and would need to resample > sound at 24Hz because of this (blu-ray are 24/1.001). > Sure? The source material is 24 Hz, and wasn't the whole point of 24p to get away from NTSC conversions? TV shows might be a different matter though... > Assuming you can reproduce the issue just using mplayer playing a CD - then > I can't, maybe your receiver is just more fussy than my TV. > > Does it claim CEA compliance? > I would assume so. But it's not really something blingy enough to brag about on the box. There are specs here: http://eu.harmankardon.com/harman-kardon-product-detail-eu/avr_265.html > Of course your GPU is likely different to mine (HD4890) so I can't test like > for like properly. > > The old mode is the first one listed by xrandr - can't you just avoid the > ntsc ones rather than needing them to be removed? If I can, I don't know how. It is xbmc that's my use case, and it tends to pick that mode. Besides, we shouldn't have modes listed that don't work properly. :) -- 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
Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Wed, Sep 25, 2013 at 09:56:52AM +0200, Daniel Vetter wrote: > On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote: > > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin > > wrote: > > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: > > >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: > > >> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] > > >> > > > >> > Hi, > > >> > > > >> > saw your posting in [1]... can you try the patches below? > > >> > Not sure if they apply. > > >> > Did you try v3.11-rc6(+)... or drm-intel-nightly? > > >> > > > >> > Regards, > > >> > - Sedat - > > >> > > > >> > [1] > > >> > http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html > > >> > > >> Same thing observed with v3.11-rc7. > > > > > > I still see this with 3.11. > > > Following this message, my VGA monitor goes blank and > > > shows an error suggesting a wrong resolution or frequency are set. > > > Anyone? > > > > Daniel, Jesse? > > > > still ongoing I think. > > Yeah, I've dismissed it since the original issue in this thread is > resolved. But it's something else. > > Note to bug reporters: Please don't me-too, but start a new thread/report > - almost every gfx bug is different, even if it superficially looks the > same. > > Michael, can you please boot with drm.debug=0xe, reproduce the problem and > then attach the complete dmesg? Please make sure dmesg contains everything > since boot-up, if not please increase the dmesg buffer size with > log_buf_len=4M. Complete dmesg attached. > Also please test the latest drm-intel-fixes release to check that we > haven't just forgotten to send the patch to stable (there's at least one > flags mismatch fix already in-flight to 3.11 stable kernels). > > Thanks, Daniel Is it included in latest -rc2? It's easier for me to test that. > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11.0-mst (mst at robin.redhat.com) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #258 SMP Sun Sep 22 02:49:15 IDT 2013 [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.11.0-mst root=UUID=75d505b0-6e76-4f40-9cbc-0d6e700effd1 ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet drm.debug=0xe [0.00] Disabled fast string operations [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xda99efff] usable [0.00] BIOS-e820: [mem 0xda99f000-0xdae9efff] reserved [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd2-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021e5f] usable [0.00] BIOS-e820: [mem 0x00021e60-0x00021e7f] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: LENOVO 4243BQ9/4243BQ9, BIOS 8AET57WW (1.37 ) 04/05/2012 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x21e600 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MT
[Bug 69790] [HSW ULT] testdisplay : The output of 720x576 mode is dislocated
https://bugs.freedesktop.org/show_bug.cgi?id=69790 Guang Yang changed: What|Removed |Added Hardware|Other |All OS|All |Linux (All) Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede |.org|sktop.org QA Contact||intel-gfx-bugs@lists.freede ||sktop.org CC||intel-gfx-bugs@lists.freede ||sktop.org Component|libdrm |DRM/Intel -- 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 61891] Cannot switch off Radeon 6400M with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=61891 --- Comment #5 from madc...@atlas.cz --- Kernel 3.12-rc2 seems to fix the issue for me. (The kernel still crashes with the patches for powerxpress dynamic power switching, but that's obviously another story). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #23 from Alex Deucher --- (In reply to comment #22) > Bad news. On 3.12rc2 those patches don't work anymore. Same problem like at > starting this crq. HDMI audio seems to be totally disabled... In 3.12 you can enable audio on the fly with xrandr. E.g., xrandr --output HDMI-0 --set audio auto -- 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
[Intel-gfx] Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Wed, Sep 25, 2013 at 06:34:38PM +0300, Michael S. Tsirkin wrote: > On Wed, Sep 25, 2013 at 09:56:52AM +0200, Daniel Vetter wrote: > > On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote: > > > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin > > > wrote: > > > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: > > > >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: > > > >> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] > > > >> > > > > >> > Hi, > > > >> > > > > >> > saw your posting in [1]... can you try the patches below? > > > >> > Not sure if they apply. > > > >> > Did you try v3.11-rc6(+)... or drm-intel-nightly? > > > >> > > > > >> > Regards, > > > >> > - Sedat - > > > >> > > > > >> > [1] > > > >> > http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html > > > >> > > > >> Same thing observed with v3.11-rc7. > > > > > > > > I still see this with 3.11. > > > > Following this message, my VGA monitor goes blank and > > > > shows an error suggesting a wrong resolution or frequency are set. > > > > Anyone? > > > > > > Daniel, Jesse? > > > > > > still ongoing I think. > > > > Yeah, I've dismissed it since the original issue in this thread is > > resolved. But it's something else. > > > > Note to bug reporters: Please don't me-too, but start a new thread/report > > - almost every gfx bug is different, even if it superficially looks the > > same. > > > > Michael, can you please boot with drm.debug=0xe, reproduce the problem and > > then attach the complete dmesg? Please make sure dmesg contains everything > > since boot-up, if not please increase the dmesg buffer size with > > log_buf_len=4M. > > Complete dmesg attached. > > > Also please test the latest drm-intel-fixes release to check that we > > haven't just forgotten to send the patch to stable (there's at least one > > flags mismatch fix already in-flight to 3.11 stable kernels). > > > > Thanks, Daniel > > Is it included in latest -rc2? It's easier for me to test that. -rc2 should be good enough for testing - the additional patches in -fixes won't affect your issue. -Daniel > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Initializing cgroup subsys cpuacct > [0.00] Linux version 3.11.0-mst (mst at robin.redhat.com) (gcc > version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #258 SMP Sun Sep 22 02:49:15 IDT 2013 > [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.11.0-mst > root=UUID=75d505b0-6e76-4f40-9cbc-0d6e700effd1 ro rd.md=0 rd.lvm=0 rd.dm=0 > SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet drm.debug=0xe > [0.00] Disabled fast string operations > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable > [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved > [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable > [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved > [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable > [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved > [0.00] BIOS-e820: [mem 0x4020-0xda99efff] usable > [0.00] BIOS-e820: [mem 0xda99f000-0xdae9efff] reserved > [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS > [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI > data > [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable > [0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved > [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved > [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved > [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved > [0.00] BIOS-e820: [mem 0xffd2-0x] reserved > [0.00] BIOS-e820: [mem 0x0001-0x00021e5f] usable > [0.00] BIOS-e820: [mem 0x00021e60-0x00021e7f] reserved > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.6 present. > [0.00] DMI: LENOVO 4243BQ9/4243BQ9, BIOS 8AET57WW (1.37 ) 04/05/2012 > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable >
[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #22 from Paul Bodenbenner --- Bad news. On 3.12rc2 those patches don't work anymore. Same problem like at starting this crq. HDMI audio seems to be totally disabled... -- 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 67107] Xorg starts and crashes with DPM enable
https://bugs.freedesktop.org/show_bug.cgi?id=67107 --- Comment #12 from Adam Honse --- I'm using the Ubuntu kernel PPA's 3.12-rc2 kernel which according to the changelog has this patch but am still having the problem. My laptop is A10-4600M with 7730M discrete GPU. If I disable gdm and X, I can boot up, log in to a text mode terminal and do text mode things just fine and dmesg shows that dpm is enabled for both GPU's, but trying to start X crashes the entire machine instantly. This happens when my laptop is plugged in and fully charged, haven't tested it unplugged and on battery. -- 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: PCI Radeon RV100 detection hang on sparc64
> > >> The pci_assign_resource() path must have some bug that causes the > > >> resource values to be set incorrectly or similar. > > >> > > >> Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE) > > >> before the pci_map_rom() call? > > > > > > [drm] radeon_read_bios: pci_resource_start(ROM)=01FF1002 > > > > > > I am a little confused here. ROM addressis OK but after pci_map_rom it > > > results in address that corresponds to another device? > > > > That's certainly a bug. > > > > So after pci_map_rom() pci_resource_start(ROM)=01FF, right? > > I double checked it - yes: > > before pci_map_rom: > [drm] radeon_read_bios: pci_resource_start(ROM)=01FF1002 > > > radeon :02:02.0: BAR 6: assigned [mem 0x1ff-0x1ff0001] > > after pci_map_rom: > > [drm] radeon_read_bios, bios=01ff, > pci_resource_start(ROM)=01FF, size=46592 This is first range in pci bus :02 that is tried, and it matches: pci_bus :02: pci_bus_alloc_resource trying [mem 0x1ff-0x1ff00bf] I instrumented bootup with pci_bus_add_resource_offset and pci_bus_add_resource logs if this of any help: /pci@1f,0: PCI IO[1fe0200] MEM[1ff] /pci@1f,0: SABRE PCI Bus Module ver[0:0] PCI: Scanning PBM /pci@1f,0 pci_bus_add_resource_offset adding [io 0x1fe0200-0x1fe02ff] pci_bus_add_resource_offset adding [mem 0x1ff-0x1ff] pci_bus_add_resource_offset adding [bus 00-02] sabre f005f9c0: PCI host bridge to bus :00 pci_bus :00: pci_bus_add_resource adding [io 0x1fe0200-0x1fe02ff] with flags 0 pci_bus :00: root bus resource [io 0x1fe0200-0x1fe02ff] (bus address [0x-0xff]) pci_bus :00: pci_bus_add_resource adding [mem 0x1ff-0x1ff] with flags 0 pci_bus :00: root bus resource [mem 0x1ff-0x1ff] (bus address [0x-0x]) pci_bus :00: root bus resource [bus 00-02] To me it looks like we get the PCI bus ranges and store them and nobody uses them until now, and then we insert PCI devices with allocations from OF and do not update PCI bus available windows? -- Meelis Roos (mr...@linux.ee) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.12
Hi Dave, More radeon fixes for 3.12. Kind of all over the place: UVD, DPM, tiling, etc. The following changes since commit 6ddf2ed6e00396883b3123032ccb4416205aac7c: Merge branch 'msm-fixes-3.12' of git://people.freedesktop.org/~robclark/linux into drm-fixes (2013-09-20 09:06:48 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.12 for you to fetch changes up to 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a: drm/radeon: fix hdmi audio on DCE3.0/3.1 asics (2013-09-25 12:15:11 -0400) Alex Deucher (13): drm/radeon: avoid UVD corruption on AGP cards using GPU gart drm/radeon: additional gcc fixes for radeon_atombios.c drm/radeon: fix missed variable sized access drm/radeon/dpm: fetch the max clk from voltage dep tables helper drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables drm/radeon: don't set default clocks for SI when DPM is disabled drm/radeon: disable tests/benchmarks if accel is disabled drm/radeon: add missing hdmi callbacks for rv6xx drm/radeon/cik: fix overflow in vram fetch drm/radeon: fix hdmi audio on DCE3.0/3.1 asics Alex Ivanov (1): drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2) Christian König (1): drm/radeon/uvd: lower msg&fb buffer requirements on UVD3 Michel Dänzer (3): drm/radeon/cik: Fix printing of client name on VM protection fault drm/radeon/cik: Fix encoding of number of banks in tiling configuration info drm/radeon/cik: Add tiling mode index for 1D tiled depth/stencil surfaces drivers/gpu/drm/radeon/btc_dpm.c | 51 drivers/gpu/drm/radeon/btc_dpm.h | 2 + drivers/gpu/drm/radeon/ci_dpm.c | 26 + drivers/gpu/drm/radeon/cik.c | 17 drivers/gpu/drm/radeon/ni_dpm.c | 24 drivers/gpu/drm/radeon/r100.c| 8 ++-- drivers/gpu/drm/radeon/r600_dpm.c| 2 +- drivers/gpu/drm/radeon/r600_hdmi.c | 20 +++--- drivers/gpu/drm/radeon/radeon_asic.c | 2 + drivers/gpu/drm/radeon/radeon_atombios.c | 66 +--- drivers/gpu/drm/radeon/radeon_cs.c | 5 ++- drivers/gpu/drm/radeon/radeon_device.c | 15 ++-- drivers/gpu/drm/radeon/radeon_pm.c | 8 ++-- drivers/gpu/drm/radeon/radeon_ring.c | 8 ++-- drivers/gpu/drm/radeon/radeon_uvd.c | 3 +- drivers/gpu/drm/radeon/si_dpm.c | 24 drivers/gpu/drm/radeon/uvd_v1_0.c| 4 +- include/uapi/drm/radeon_drm.h| 2 + 18 files changed, 230 insertions(+), 57 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #8 from Andy Furniss --- (In reply to comment #2) > From IRC: > agd5f: you might've seen already, but the 23.976 Hz pixel clock > 74175.824175 is rounded up to 74176 in Ville's commit FWIW I guess he did this because 74.176 appears in CEA D for 23.976, there isn't anything for 23.976 in E. -- 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 v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm
Hi Benoit,
On Tue, Sep 24, 2013 at 11:29:51AM +0200, Benoit Cousson wrote:
> Hi Benoit,
>
> On 03/09/2013 16:55, Benoit Parrot wrote:
> >Hi,
> >
> >I have not received any feedback on this patch.
> >It has been pending since the end of June (first post).
> >Can I get an estimate when it will be included/accepted?
>
> It looks good to me beside a minor comment below.
>
> Could you just rebase it on my lastest
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
> for_3.13/dts branch because it conflicts with the cleanup done by
> Javier.
>
I was going to rebase it to your for_3.13/dts branch, but Joel Frenandez has
already included this patch as part of his most recent submission.
(http://marc.info/?l=devicetree&m=138014654925217&w=2) so I guess there is no
need to duplicate the work now.
Let me know if this causes any issue.
Thanks,
Benoit
> >
> >On Fri, Aug 23, 2013 at 11:13:56AM -0500, Benoit Parrot wrote:
> >>Add LCDC device node in DT for am33xx
> >>Add LCDC and Panel info in DT for am335x-evm
> >>
> >>Changes in v3:
> >>- rebase to 3.11-rc6
> >>
> >>Changes in v2:
> >>- remove redundant/unnecessary SoC specific setting in the board dts
> >>
> >>Signed-off-by: Benoit Parrot
> >>---
> >> arch/arm/boot/dts/am335x-evm.dts | 72
> >> ++
> >> arch/arm/boot/dts/am33xx.dtsi|9 +
> >> 2 files changed, 81 insertions(+)
> >>
> >>diff --git a/arch/arm/boot/dts/am335x-evm.dts
> >>b/arch/arm/boot/dts/am335x-evm.dts
> >>index 3aee1a4..b0703f1 100644
> >>--- a/arch/arm/boot/dts/am335x-evm.dts
> >>+++ b/arch/arm/boot/dts/am335x-evm.dts
> >>@@ -149,6 +149,40 @@
> >>0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> >>>;
> >>};
> >>+
> >>+ lcd_pins_s0: lcd_pins_s0 {
> >>+ pinctrl-single,pins = <
> >>+ 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
> >>| MODE1 */
> >>+ 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
> >>| MODE1 */
> >>+ 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
> >>| MODE1 */
> >>+ 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
> >>| MODE1 */
> >>+ 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
> >>| MODE1 */
> >>+ 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
> >>| MODE1 */
> >>+ 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
> >>| MODE1 */
> >>+ 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
> >>| MODE1 */
> >>+ 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
> >>| MODE0 */
> >>+ 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
> >>| MODE0 */
> >>+ 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
> >>| MODE0 */
> >>+ 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
> >>| MODE0 */
> >>+ 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
> >>| MODE0 */
> >>+ 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
> >>| MODE0 */
> >>+ 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
> >>| MODE0 */
> >>+ 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
> >>| MODE0 */
> >>+ 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
> >>| MODE0 */
> >>+ 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
> >>| MODE0 */
> >>+ 0xc8 0x00 /* lcd_data10.lcd_data10,
> >>OUTPUT | MODE0 */
> >>+ 0xcc 0x00 /* lcd_data11.lcd_data11,
> >>OUTPUT | MODE0 */
> >>+ 0xd0 0x00 /* lcd_data12.lcd_data12,
> >>OUTPUT | MODE0 */
> >>+ 0xd4 0x00 /* lcd_data13.lcd_data13,
> >>OUTPUT | MODE0 */
> >>+ 0xd8 0x00 /* lcd_data14.lcd_data14,
> >>OUTPUT | MODE0 */
> >>+ 0xdc 0x00 /* lcd_data15.lcd_data15,
> >>OUTPUT | MODE0 */
> >>+ 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
> >>| MODE0 */
> >>+ 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
> >>| MODE0 */
> >>+ 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
> >>MODE0 */
> >>+ 0xec 0x00 /*
> >>lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
> >>+ >;
> >>+ };
> >>+
> >>};
> >>
> >>ocp {
> >>@@ -311,6 +345,10 @@
> >>};
> >>};
> >>};
> >>+
> >>+ lcdc: lcdc@4830e000 {
> >>+ status = "okay";
> >>+ };
> >>};
> >>
> >>vbat: fixedregulator@0 {
> >>@@ -374,6 +412,40 @@
> >>brightness-levels = <0 51 53 56 62 75 101 152 255>;
> >
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #7 from Anssi Hannula ---
(In reply to comment #6)
> I just meant to patch the table so that you end up using the pre-defined
> values for CTS and N rather than calculating them from the formula.
>
> { xxx, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 74.25/1.001 MHz */
>
> Replace xxx with whatever clock value the drm edid code gives you for
> 74.25/1.001 MHz.
Ah, OK.
> The's presumably a reason the predefined values are there rather just using
> the formula for everything.
Well my guess is that the table could be there just because the HDMI spec has
that table. Note how everything in the table except the three /1.001 rates
(that have differing N) just have the same N/CTS value that the manual
calculation would result in anyway.
The reason the table is in the spec is because using the "default" N for the
(exact, relative to audio) /1.001 rates results in a non-constant CTS - which
is not preferred though should still work.
> The actual clock generated by the PLL will not always be exact either. It's
> limited by reference clock and the divider ranges.
Hence my preference for HW counted CTS if at all possible.
If HW CTS will not work and it is confirmed that the CTS value is indeed the
issue here, it might get a bit tricky to figure out the proper values in all
cases...
Of course it could be this is not CTS/N related at all and something else in
HDMI audio programming is wrong for these "unusual" pixel clocks.
Better not get too much ahead of ourselves until we know if the HW measured CTS
patch makes any difference, though... :)
--
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 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #16 from Alex Deucher --- Are you sure it doesn't work if you remvoe your xorg.conf completely? You don't need one and in most cases it causes more problems than it solves. Also you can remove this line: Virtual 5760 1920 from your config. Unless you are actually using a large virtual desktop, it just wastes memory. -- 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 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #15 from Marco --- Created attachment 86601 --> https://bugs.freedesktop.org/attachment.cgi?id=86601&action=edit xorg.conf working with only one GPU (HD8330) -- 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 69694] Xorg doesn't start on KABINi with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=69694 --- Comment #14 from Marco --- I found a workaround! Disabling second GPU in xorg.conf let me enter in X with acceleration enabled: marco@albireo:~$ glxinfo | grep -i opengl OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD KABINI OpenGL version string: 2.1 Mesa 9.3.0-devel OpenGL shading language version string: 1.30 Finally!!! And all is working fine. Then the bug is related to having 2 GPU. At least now I can play games (with only one GPU). -- 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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #6 from Alex Deucher ---
(In reply to comment #5)
> (In reply to comment #4)
> > Something like this:
>
> Not really, the selection doesn't work like that - clock has to match
> exactly to the table value, it is not an upper bound.
I just meant to patch the table so that you end up using the pre-defined values
for CTS and N rather than calculating them from the formula.
{ xxx, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 74.25/1.001 MHz */
Replace xxx with whatever clock value the drm edid code gives you for
74.25/1.001 MHz.
The's presumably a reason the predefined values are there rather just using the
formula for everything.
The actual clock generated by the PLL will not always be exact either. It's
limited by reference clock and the divider ranges.
--
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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #5 from Anssi Hannula --- To expand a bit on my earlier comment that Alex pasted: HDMI sends ACR packets in the stream that will allow the sink to recover the audio clock. Two values are sent: N: Divisor used on the audio reference clock (128 * samplerate). CTS: Amount of TMDS clock cycles per one N-divided audio reference clock cycle. AFAICS normally the source hardware is expected to measure the CTS in real-time by counting the cycles. If the audio/video clocks are perfectly in sync and N is selected optimally (if possible), CTS will of course stay constant. In other cases it is expected to alternate between several values. The HDMI specification has some recommended N values (and corresponding expected CTS values) for common TMDS clocks. The recommended values result in a constant CTS if the clocks are synchronous (constant CTS is "recommended whenever possible"). The recommendation table does include TMDS clock 74.25/1.001, which is the one used for 1080p23.976. However, the provided N will result in constant CTS only if the clock is exactly 74.25/1.001 without rounding (and the modeline is of course rounded, unless something in the driver or hw does something to try to restore the fractional rate - I have no idea if that is the case). The radeon driver contains the recommended table and hardwires N/CTS values. If the TMDS clock is not found in the table, recommended N is selected and the CTS is simply directly calculated and set as constant. The table in question contains N/CTS 11648/140625 for 48kHz and 74.175 MHz (74.175 is down-rounded 74.25/1.001). However, if the TMDS freq is actually exactly 74.175 Mhz and not 74.25/1.001 (74175.824) (i.e. nothing corrects 74.175 => 74.25/1.001), the N/CTS values are already wrong (74175000*11648/(48000*128) = 140623.4375 != 140625. The driver calculated N/CTS (for clocks not in the table) are correct only if the TMDS clock is exactly the value used (relative to audio clock). I have a feeling that might not be the case (evidenced by e.g. this bug), though I didn't look at the radeon driver internals that closely. To me it would seem like using hardware measurement for CTS value would be better than to deal with all this. According to header comments radeon hw seems to support that, but for some reason that is not used and driver-wired values are used instead. Alex' attached patch should switch the ACR to hw measured CTS. If that actually works, hopefully it fixes the audio synchronization issues... (In reply to comment #4) > Something like this: Not really, the selection doesn't work like that - clock has to match exactly to the table value, it is not an upper bound. -- 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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #4 from Alex Deucher ---
Something like this:
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index b0fa600..f7d2766 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -63,7 +63,7 @@ static const struct radeon_hdmi_acr
r600_hdmi_predefined_acr[] = {
{ 27027, 4096, 27027, 6272, 30030, 6144, 27027 }, /* 27.00*1.001
MHz */
{ 54000, 4096, 54000, 6272, 6, 6144, 54000 }, /* 54.00
MHz */
{ 54054, 4096, 54054, 6272, 60060, 6144, 54054 }, /* 54.00*1.001
MHz */
-{ 74175, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 74.25/1.001
MHz */
+{ 74180, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 74.25/1.001
MHz */
{ 74250, 4096, 74250, 6272, 82500, 6144, 74250 }, /* 74.25
MHz */
{ 148351, 11648, 421875, 8918, 234375, 5824, 140625 }, /* 148.50/1.001
MHz */
{ 148500, 4096, 148500, 6272, 165000, 6144, 148500 }, /* 148.50
MHz */
--
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 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #21 from Paul Bodenbenner --- Perfect! Works also on 3.11.1. So Bug is solved for me. Thanks a lot! -- 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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #3 from Alex Deucher --- Created attachment 86598 --> https://bugs.freedesktop.org/attachment.cgi?id=86598&action=edit use hw generated cts and n values rather than the sw programmed values Does this patch help? If not, it may be worth adding some slop to the r600_hdmi_predefined_acr[] table to handle rounding differences so the appropriate defined values get selected. -- 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 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #2 from Alex Deucher --- >From IRC: agd5f: you might've seen already, but the 23.976 Hz pixel clock 74175.824175 is rounded up to 74176 in Ville's commit, but r600_hdmi_predefined_acr[] table contains 74175 so it does not match not sure why the calculated value would not work, though... probably for the same reason the recommended value is not the calculated value, but I don't understand enough to know why -- 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 v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
On Tue, 24 Sep 2013, Aaron Lu wrote: > locate handle for ACPI video by HID, the problem is, ACPI video node > doesn't really have HID defined(i.e. no _HID control method is defined ACPI video is supposed to attach a virtual HID node (ACPI_VIDEO_HID) to ACPI video devices so as to keep the non-trivial video device detection logic in just one place instead of reinventing the wheel in every driver (which is always a recipe for disaster). When did that break? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #1 from Andy Furniss --- IIRC it was the XBMC people that wanted the ntsc variants in the first place as their player defaults to sync to video exactly and would need to resample sound at 24Hz because of this (blu-ray are 24/1.001). Assuming you can reproduce the issue just using mplayer playing a CD - then I can't, maybe your receiver is just more fussy than my TV. Does it claim CEA compliance? Of course your GPU is likely different to mine (HD4890) so I can't test like for like properly. The old mode is the first one listed by xrandr - can't you just avoid the ntsc ones rather than needing them to be removed? -- 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 69671] rv790 hdmi sound regression since fix audio dto calculation on DCE3+ (v3)
https://bugs.freedesktop.org/show_bug.cgi?id=69671 --- Comment #5 from Andy Furniss --- (In reply to comment #4) > Created attachment 86569 [details] [review] > possible fix > > Does this patch fix the isssue? Yes, all modes are working with that, 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
Re: drm/radeon: "ring test failed" on PA-RISC Linux
Alex,
> You'd want to add the add the flush to r100_ring_test() in r100.c.
> radeon_cp.c is for the old UMS support.
Right!
Konrad,
Thanks for the code! I'll try asap.
25.09.2013, 21:28, "Konrad Rzeszutek Wilk" :
> I took a look at the arch/parisc/kernel/pci-dma.c and I see that
> is mostly a flat platform. That is bus addresses == physical addresses.
> Unless it is an pclx or pclx2 CPU type (huh?) - if its it that
> then any calls to dma_alloc_coherent will map memory out of a pool.
> In essence it will look like a SWIOTLB bounce buffer.
arch/parisc/kernel/pci-dma.c:
** PARISC 1.1 Dynamic DMA mapping support.
** This implementation is for PA-RISC platforms that do not support
** I/O TLBs (aka DMA address translation hardware).
That's very old. PA-RISC 2.0 came into the game circa 1996.
PA-RISC 1.1 is 32-bit only and i even not sure whether these machines
had PCI bus.
Only old boxes (PA7200 CPU and lower) cannot use dma_alloc_coherent()
(and forced to do syncs iirc). That's not our case.
And PA-RISC configs have 'Discontiguous Memory' choosen.
>
> But interestingly enough there is a lot of 'flush_kernel_dcache_range'
> call for every DMA operation. And I think the you need to do
> dma_sync_for_cpu call in the radeon_test_writeback for it to
> use the flush_kernel_dcache_range. I don't know what the
> flush_kernel_dcache_range does thought so I could be wrong.
D-cache is a CPU cache (if they meant it).
Seems to be L1-level. There is an I-cache at same level.
>
> That means you can ignore the little code below I wrote and
> see about doing something like this:
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
> b/drivers/gpu/drm/radeon/radeon_cp.c
> index 3cae2bb..9e5923d 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -876,6 +876,7 @@ static void radeon_test_writeback(drm_radeon_private_t *
> dev_priv)
>
> RADEON_WRITE(RADEON_SCRATCH_REG1, 0xdeadbeef);
>
> + flush_kernel_dcache_range(dev_priv->ring_rptr, PAGE_SIZE);
> for (tmp = 0; tmp < dev_priv->usec_timeout; tmp++) {
> u32 val;
>
> But that is probably a shot in the dark. I have no clue what the flush_..
> is doing.
>
> [edit: And then I noticed sba_iommu.c, which is a complete IOMMU driver
> where bus and physical addresses are different. sigh. What type of machine
> is this? Does it have the IOMMU in it?]
That's our case.
Yes, recent IA64 and PA-RISC machines have SBA IOMMU device. PCI I/O
seem to go through it. There is a note for my chipset in sba_iommu.c:
/* We are just "encouraging" 32-bit DMA masks here since we can
* never allow IOMMU bypass unless we add special support for ZX1.
*/
And it indeed right. When i've tried to bypass hw IOMMU like in ia64
code it lead to the faults from drivers which do the DMA (like Fusion MPT SCSI
driver).
>> void *va = bus_to_virt(gtt->ttm.dma_address[i]);
>> if ((phys_addr_t) va != virt_to_bus(va)) {
>
> You are missing a translation here (you were comparing the virtual address
> to the bus address). I was thinking something along this:
Yes, this confused me. I've translated your suggestion literally :\
>
> unsigned int pfn = page_to_pfn(ttm->pages[i]);
> dma_addr_t bus = gtt->ttm.dma_address[i];
> void *va_bus, *va, *va_pfn;
>
> if ((pfn << PAGE_SHIFT) != bus)
> printk("Bus 0x%lx != PFN 0x%lx, bus, pfn <<
> PAGE_SHIFT); /* OK, that means
> bus addresses are different */
>
> va_bus = bus_to_virt(gtt->ttm.dma_address[i]);
> va_pfn = __va(pfn << PAGE_SHIFT);
>
> if (!virt_addr_valid(va_bus))
> printk("va_bus (0x%lx) not good!\n", va_bus);
> if (!virt_addr_valid(va_pfn))
> printk("va_pfn (0x%lx) not good!\n", va_pfn);
>
> /* We got VA for both bus -> va, and pfn -> va. Should be the
> same if bus and physical addresses are on the same
> namespace. */
> if (va_bus != va_pfn)
> printk("va bus:%lx != va pfn: %lx\n", va_bus, va_pfn);
>
> /* Now that we have bus -> pa -> va (va_bus) try to go va_bus
> -> bus address.
> The bus address should be the same */
> if (gtt->tmm.dma_address[i] != virt_to_bus(va_bus))
> printk("bus->pa->va:%lx != bus->pa->va->ba: %lx\n",
> gtt->tmm.dma_address[i],virt_to_bus(va_bus));
>
>> DRM_INFO("MISMATCH: %p != %p\n", va, (void *)
>> virt_to_bus(va));
>> /*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ //
>> Leads to a Kernel Fault
>
> That is odd. I would have thought it would be usuable.
>
>> ...
>> }
>>
>> I'm getting the output:
>>
>> [drm] MISMATCH: 8028 != 4028
>
>
Re: drm/radeon: "ring test failed" on PA-RISC Linux
On Wed, Sep 25, 2013 at 1:28 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Sep 25, 2013 at 08:29:07PM +0400, Alex Ivanov wrote:
>> 24.09.2013, 00:11, "Konrad Rzeszutek Wilk" :
>> > On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
>> >
>> >> 21.09.2013, в 1:27, Alex Deucher написал(а):
>> >>> The register writes seems to be going through the register backbone
>> >>> correctly:
>> >>>
>> >>> [0x00B] 0x15E0=0x
>> >>> [0x00C] 0x15E4=0xCAFEDEAD
>> >>> [0x00D] 0x4274=0x000F
>> >>> [0x00E] 0x42C8=0x0007
>> >>> [0x00F] 0x4018=0x001D
>> >>> [0x010] 0x170C=0x8000
>> >>> [0x011] 0x3428=0x00020100
>> >>> [0x012] 0x15E4=0xCAFEDEAD
>> >>>
>> >>> You can see the 0xCAFEDEAD written to the scratch register via MMIO
>> >>> from the ring_test(). The CP fifo however seems to be full of garbage.
>> >>> The CP is busy though, so it seems to be functional. I guess it's
>> >>> just fetching garbage rather than commands.
>> >
>> > If it is fetching garbage, that would imply the DMA (or bus addresses)
>> > that are programmed in the GART are bogus. If you dump them and try
>> > to figure out if bus adress -> physical address -> virtual address ==
>> > virtual address -> bus address that could help. And perhaps seeing what
>> > the virtual address has - and or poisoning it with known data?
>> >
>> > Or perhaps the the card has picked up an incorrect page table? Meaning
>> > the (bus) address given to it is not the correct one?
>> >
>>
>> Konrad,
>>
>> Let's see. Please notice that i'm not PA-RISC or general linux kernel
>> developer, just the user, so i may do things completely wrong.
>> I was hoping that PA-RISC smarties will join me here, but they seem
>> to be busy with other duties. Even port's mail list activity is low
>> during last weeks.
>
> I took a look at the arch/parisc/kernel/pci-dma.c and I see that
> is mostly a flat platform. That is bus addresses == physical addresses.
> Unless it is an pclx or pclx2 CPU type (huh?) - if its it that
> then any calls to dma_alloc_coherent will map memory out of a pool.
> In essence it will look like a SWIOTLB bounce buffer.
>
> But interestingly enough there is a lot of 'flush_kernel_dcache_range'
> call for every DMA operation. And I think the you need to do
> dma_sync_for_cpu call in the radeon_test_writeback for it to
> use the flush_kernel_dcache_range. I don't know what the
> flush_kernel_dcache_range does thought so I could be wrong.
>
> That means you can ignore the little code below I wrote and
> see about doing something like this:
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
> b/drivers/gpu/drm/radeon/radeon_cp.c
> index 3cae2bb..9e5923d 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -876,6 +876,7 @@ static void radeon_test_writeback(drm_radeon_private_t *
> dev_priv)
>
> RADEON_WRITE(RADEON_SCRATCH_REG1, 0xdeadbeef);
>
> + flush_kernel_dcache_range(dev_priv->ring_rptr, PAGE_SIZE);
> for (tmp = 0; tmp < dev_priv->usec_timeout; tmp++) {
> u32 val;
>
You'd want to add the add the flush to r100_ring_test() in r100.c.
radeon_cp.c is for the old UMS support.
Alex
> But that is probably a shot in the dark. I have no clue what the flush_..
> is doing.
>
> [edit: And then I noticed sba_iommu.c, which is a complete IOMMU driver
> where bus and physical addresses are different. sigh. What type of machine
> is this? Does it have the IOMMU in it?]
>>
>> > If you dump them and try
>> > to figure out if bus adress -> physical address -> virtual address ==
>> > virtual address -> bus address that could help
>>
>> With following
>>
>> radeon/radeon_ttm.c:
>>
>> radeon_ttm_tt_populate():
>> ...
>> for (i = 0; i < ttm->num_pages; i++) {
>> gtt->ttm.dma_address[i] = pci_map_page(rdev->pdev,
>> ttm->pages[i],
>>0, PAGE_SIZE,
>>
>> PCI_DMA_BIDIRECTIONAL);
>>
>> void *va = bus_to_virt(gtt->ttm.dma_address[i]);
>> if ((phys_addr_t) va != virt_to_bus(va)) {
>
> You are missing a translation here (you were comparing the virtual address
> to the bus address). I was thinking something along this:
>
> unsigned int pfn = page_to_pfn(ttm->pages[i]);
> dma_addr_t bus = gtt->ttm.dma_address[i];
> void *va_bus, *va, *va_pfn;
>
> if ((pfn << PAGE_SHIFT) != bus)
> printk("Bus 0x%lx != PFN 0x%lx, bus, pfn <<
> PAGE_SHIFT); /* OK, that means
> bus addresses are different */
>
> va_bus = bus_to_virt(gtt->ttm.dma_address[i]);
> va_pfn = __va(pfn << PAGE_SHIFT);
>
> if (!virt_addr_valid(va_bus))
> printk("va_bus (0x%lx) not good!\n", va_bus);
> if (!virt_addr_valid(va_pfn))
> prin
[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #20 from Paul Bodenbenner --- Nice, nice, nice... Patch worked on rc5. So it seems to be solved. For being sure I will apply both patches also on 3.11.1 and give feedback. -- 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 v3 3/4] ACPI / video: Do not register backlight if win8 and native interface exists
On Tuesday, September 24, 2013 05:47:31 PM Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI interface, including the fact that
> it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the
> ACPI backlight interface on these systems".
>
> So for Win8 systems, if there is native backlight control interface
> registered by GPU driver, ACPI video will not register its own. For
> users who prefer to keep ACPI video's backlight interface, the existing
> kernel cmdline option acpi_backlight=video can be used.
I think the idea is to use the aggressive default for now and we can switch the
default back to the current behavior before the merge window in case there are
too many problems with it?
Rafael
> Signed-off-by: Aaron Lu
> Tested-by: Igor Gnatenko
> Tested-by: Yves-Alexis Perez
> ---
> drivers/acpi/internal.h | 5 ++---
> drivers/acpi/video.c| 10 +-
> drivers/acpi/video_detect.c | 14 --
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 20f4233..453ae8d 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
> Video
>--
> */
> #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
> -bool acpi_video_backlight_quirks(void);
> -#else
> -static inline bool acpi_video_backlight_quirks(void) { return false; }
> +bool acpi_osi_is_win8(void);
> +bool acpi_video_verify_backlight_support(void);
> #endif
>
> #endif /* _ACPI_INTERNAL_H_ */
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 3bd1eaa..343db59 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
> *device, int event)
> unsigned long long level_current, level_next;
> int result = -EINVAL;
>
> - /* no warning message if acpi_backlight=vendor is used */
> - if (!acpi_video_backlight_support())
> + /* no warning message if acpi_backlight=vendor or a quirk is used */
> + if (!acpi_video_verify_backlight_support())
> return 0;
>
> if (!device->brightness)
> @@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus
> *video,
> static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
> {
> return acpi_video_bus_DOS(video, 0,
> - acpi_video_backlight_quirks() ? 1 : 0);
> + acpi_osi_is_win8() ? 1 : 0);
> }
>
> static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
> {
> return acpi_video_bus_DOS(video, 0,
> - acpi_video_backlight_quirks() ? 0 : 1);
> + acpi_osi_is_win8() ? 0 : 1);
> }
>
> static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
> @@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level,
> void *context,
>
> static void acpi_video_dev_register_backlight(struct acpi_video_device
> *device)
> {
> - if (acpi_video_backlight_support()) {
> + if (acpi_video_verify_backlight_support()) {
> struct backlight_properties props;
> struct pci_dev *pdev;
> acpi_handle acpi_parent;
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index 940edbf..23d7d26 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include "internal.h"
>
> @@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
> acpi_video_get_capabilities(NULL);
> }
>
> -bool acpi_video_backlight_quirks(void)
> +bool acpi_osi_is_win8(void)
> {
> return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
> }
> -EXPORT_SYMBOL(acpi_video_backlight_quirks);
> +EXPORT_SYMBOL(acpi_osi_is_win8);
>
> /* Promote the vendor interface instead of the generic video module.
> * This function allow DMI blacklists to be implemented by externals
> @@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
> }
> EXPORT_SYMBOL(acpi_video_backlight_support);
>
> +bool acpi_video_verify_backlight_support(void)
> +{
> + if (!(acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) &&
> + acpi_osi_is_win8() && backlight_device_registered(BACKLIGHT_RAW))
> + return false;
> + return acpi_video_backlight_support();
> +}
> +EXPORT_SYMBOL(acpi_video_verify_backlight_support);
> +
> /*
> * Use acpi_back
Re: drm/radeon: "ring test failed" on PA-RISC Linux
On Wed, Sep 25, 2013 at 08:29:07PM +0400, Alex Ivanov wrote:
> 24.09.2013, 00:11, "Konrad Rzeszutek Wilk" :
> > On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
> >
> >> 21.09.2013, в 1:27, Alex Deucher написал(а):
> >>> The register writes seems to be going through the register backbone
> >>> correctly:
> >>>
> >>> [0x00B] 0x15E0=0x
> >>> [0x00C] 0x15E4=0xCAFEDEAD
> >>> [0x00D] 0x4274=0x000F
> >>> [0x00E] 0x42C8=0x0007
> >>> [0x00F] 0x4018=0x001D
> >>> [0x010] 0x170C=0x8000
> >>> [0x011] 0x3428=0x00020100
> >>> [0x012] 0x15E4=0xCAFEDEAD
> >>>
> >>> You can see the 0xCAFEDEAD written to the scratch register via MMIO
> >>> from the ring_test(). The CP fifo however seems to be full of garbage.
> >>> The CP is busy though, so it seems to be functional. I guess it's
> >>> just fetching garbage rather than commands.
> >
> > If it is fetching garbage, that would imply the DMA (or bus addresses)
> > that are programmed in the GART are bogus. If you dump them and try
> > to figure out if bus adress -> physical address -> virtual address ==
> > virtual address -> bus address that could help. And perhaps seeing what
> > the virtual address has - and or poisoning it with known data?
> >
> > Or perhaps the the card has picked up an incorrect page table? Meaning
> > the (bus) address given to it is not the correct one?
> >
>
> Konrad,
>
> Let's see. Please notice that i'm not PA-RISC or general linux kernel
> developer, just the user, so i may do things completely wrong.
> I was hoping that PA-RISC smarties will join me here, but they seem
> to be busy with other duties. Even port's mail list activity is low
> during last weeks.
I took a look at the arch/parisc/kernel/pci-dma.c and I see that
is mostly a flat platform. That is bus addresses == physical addresses.
Unless it is an pclx or pclx2 CPU type (huh?) - if its it that
then any calls to dma_alloc_coherent will map memory out of a pool.
In essence it will look like a SWIOTLB bounce buffer.
But interestingly enough there is a lot of 'flush_kernel_dcache_range'
call for every DMA operation. And I think the you need to do
dma_sync_for_cpu call in the radeon_test_writeback for it to
use the flush_kernel_dcache_range. I don't know what the
flush_kernel_dcache_range does thought so I could be wrong.
That means you can ignore the little code below I wrote and
see about doing something like this:
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 3cae2bb..9e5923d 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -876,6 +876,7 @@ static void radeon_test_writeback(drm_radeon_private_t *
dev_priv)
RADEON_WRITE(RADEON_SCRATCH_REG1, 0xdeadbeef);
+ flush_kernel_dcache_range(dev_priv->ring_rptr, PAGE_SIZE);
for (tmp = 0; tmp < dev_priv->usec_timeout; tmp++) {
u32 val;
But that is probably a shot in the dark. I have no clue what the flush_..
is doing.
[edit: And then I noticed sba_iommu.c, which is a complete IOMMU driver
where bus and physical addresses are different. sigh. What type of machine
is this? Does it have the IOMMU in it?]
>
> > If you dump them and try
> > to figure out if bus adress -> physical address -> virtual address ==
> > virtual address -> bus address that could help
>
> With following
>
> radeon/radeon_ttm.c:
>
> radeon_ttm_tt_populate():
> ...
> for (i = 0; i < ttm->num_pages; i++) {
> gtt->ttm.dma_address[i] = pci_map_page(rdev->pdev,
> ttm->pages[i],
>0, PAGE_SIZE,
>PCI_DMA_BIDIRECTIONAL);
>
> void *va = bus_to_virt(gtt->ttm.dma_address[i]);
> if ((phys_addr_t) va != virt_to_bus(va)) {
You are missing a translation here (you were comparing the virtual address
to the bus address). I was thinking something along this:
unsigned int pfn = page_to_pfn(ttm->pages[i]);
dma_addr_t bus = gtt->ttm.dma_address[i];
void *va_bus, *va, *va_pfn;
if ((pfn << PAGE_SHIFT) != bus)
printk("Bus 0x%lx != PFN 0x%lx, bus, pfn <<
PAGE_SHIFT); /* OK, that means
bus addresses are different */
va_bus = bus_to_virt(gtt->ttm.dma_address[i]);
va_pfn = __va(pfn << PAGE_SHIFT);
if (!virt_addr_valid(va_bus))
printk("va_bus (0x%lx) not good!\n", va_bus);
if (!virt_addr_valid(va_pfn))
printk("va_pfn (0x%lx) not good!\n", va_pfn);
/* We got VA for both bus -> va, and pfn -> va. Should be the
same if bus and physical addresses are on the same
namespace. */
if (va_bus != va_pfn)
printk("va bus:%lx != va pfn: %lx\n", v
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Sep 26, 2013 at 02:48:49AM +1000, Ben Skeggs wrote:
> On Thu, Sep 26, 2013 at 12:41 AM, Pasi Kärkkäinen wrote:
> > Hello,
> >
> > On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> >> Op 04-09-13 05:41, Ben Skeggs schreef:
> >> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> >> > wrote:
> >> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >> >>> set, it will do a null deref down the line. Warn on that condition and
> >> >>> return an error.
> >> >>>
> >> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >> >>>
> >> >>> Reported-by: Pasi Kärkkäinen
> >> >>> Tested-by: Pasi Kärkkäinen
> >> >>> Signed-off-by: Ilia Mirkin
> >> >>> Cc: # 3.8+
> >> >>> ---
> >> >>>
> >> >>> I don't exactly understand what's going on, but this is just a
> >> >>> straightforward way to avoid a null deref that you see happens in the
> >> >>> bug. I haven't figured out the root cause of this, but it's getting
> >> >>> well into the "I have no idea how TTM works" space. However this seems
> >> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >> >>> node->pages as a list down, which will be dereferenced by
> >> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >> >>> dereferencing not happen, but it definitely was happening here, as you
> >> >>> can see in the bug.
> >> >>>
> >> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >> >>> since like I hope I was able to convey above, I'm just not really sure
> >> >>> :)
> >> >> Not it really isn't appropriate..
> >> >>
> >> >> You'd have to call call nouveau_vm_map_sg_table instead, the only place
> >> >> that doesn't handle that correctly
> >> >> is where it's not expected to be called.
> >> >>
> >> >> Here, have a completely untested patch to fix things...
> >> >>
> >> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> >> b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> >> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> >> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> >> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device
> >> >> *dev,
> >> >> {
> >> >> struct nouveau_framebuffer *nouveau_fb;
> >> >> struct drm_gem_object *gem;
> >> >> + struct nouveau_bo *nvbo;
> >> >> int ret = -ENOMEM;
> >> >>
> >> >> gem = drm_gem_object_lookup(dev, file_priv,
> >> >> mode_cmd->handles[0]);
> >> >> if (!gem)
> >> >> return ERR_PTR(-ENOENT);
> >> >>
> >> >> + nvbo = nouveau_gem_object(gem);
> >> >> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> >> >> + nv_warn(nouveau_drm(dev), "Trying to create a fb in
> >> >> vram with"
> >> >> + " valid_domains=%08x\n", nvbo->valid_domains);
> >> >> + ret = -EINVAL;
> >> >> + goto err_unref;
> >> >> + }
> >> >> +
> >> > Definitely the right idea, we can't handle this case right now.
> >> > However, we may someday want/need to be able to scan out of system
> >> > memory, so this is the wrong place.
> >> >
> >> > I suspect the correct thing to do (which'll also handle the
> >> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> >> > a DMA-BUF backed object into VRAM.
> >> >
> >> > Sound OK?
> >> >
> >> If it has a WARN_ON or something that would be ok, I didn't find any other
> >> places that attempt to move buffers to VRAM though, so it's probably
> >> harmless.
> >>
> >
> > Ben/Maarten: Are you guys planning to take a look at this and submit
> > another patch, or.. ?
> >
> > I tested the two earlier patches from this thread, and they both fixed the
> > problem (hard kernel crash).
> > I'm hoping this bug could be finally solved in the kernel..
> I shall be looking at it properly once I'm back from XDC next week.
>
Great, thanks!
-- Pasi
> Thanks,
> Ben.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Thu, Sep 26, 2013 at 12:41 AM, Pasi Kärkkäinen wrote:
> Hello,
>
> On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
>> Op 04-09-13 05:41, Ben Skeggs schreef:
>> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
>> > wrote:
>> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
>> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>> >>> set, it will do a null deref down the line. Warn on that condition and
>> >>> return an error.
>> >>>
>> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>> >>>
>> >>> Reported-by: Pasi Kärkkäinen
>> >>> Tested-by: Pasi Kärkkäinen
>> >>> Signed-off-by: Ilia Mirkin
>> >>> Cc: # 3.8+
>> >>> ---
>> >>>
>> >>> I don't exactly understand what's going on, but this is just a
>> >>> straightforward way to avoid a null deref that you see happens in the
>> >>> bug. I haven't figured out the root cause of this, but it's getting
>> >>> well into the "I have no idea how TTM works" space. However this seems
>> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
>> >>> node->pages as a list down, which will be dereferenced by
>> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
>> >>> dereferencing not happen, but it definitely was happening here, as you
>> >>> can see in the bug.
>> >>>
>> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
>> >>> since like I hope I was able to convey above, I'm just not really sure :)
>> >> Not it really isn't appropriate..
>> >>
>> >> You'd have to call call nouveau_vm_map_sg_table instead, the only place
>> >> that doesn't handle that correctly
>> >> is where it's not expected to be called.
>> >>
>> >> Here, have a completely untested patch to fix things...
>> >>
>> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
>> >> b/drivers/gpu/drm/nouveau/nouveau_display.c
>> >> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
>> >> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
>> >> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device
>> >> *dev,
>> >> {
>> >> struct nouveau_framebuffer *nouveau_fb;
>> >> struct drm_gem_object *gem;
>> >> + struct nouveau_bo *nvbo;
>> >> int ret = -ENOMEM;
>> >>
>> >> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
>> >> if (!gem)
>> >> return ERR_PTR(-ENOENT);
>> >>
>> >> + nvbo = nouveau_gem_object(gem);
>> >> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
>> >> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram
>> >> with"
>> >> + " valid_domains=%08x\n", nvbo->valid_domains);
>> >> + ret = -EINVAL;
>> >> + goto err_unref;
>> >> + }
>> >> +
>> > Definitely the right idea, we can't handle this case right now.
>> > However, we may someday want/need to be able to scan out of system
>> > memory, so this is the wrong place.
>> >
>> > I suspect the correct thing to do (which'll also handle the
>> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
>> > a DMA-BUF backed object into VRAM.
>> >
>> > Sound OK?
>> >
>> If it has a WARN_ON or something that would be ok, I didn't find any other
>> places that attempt to move buffers to VRAM though, so it's probably
>> harmless.
>>
>
> Ben/Maarten: Are you guys planning to take a look at this and submit another
> patch, or.. ?
>
> I tested the two earlier patches from this thread, and they both fixed the
> problem (hard kernel crash).
> I'm hoping this bug could be finally solved in the kernel..
I shall be looking at it properly once I'm back from XDC next week.
Thanks,
Ben.
>
> Thanks,
>
> -- Pasi
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Upstreaming the stereo v6 series
Hi, So this series looks like a good candidate to be merged in one tree. Beside the new 3d flags added to the mode structure, the other new API is the SET_CLIENT_CAP ioctl. It seems that this new ioctl could already be potentially useful for user space to tell us they want the "primary" plane explosed as a DRM plane. The i915 bits depend on the lastest drm-intel(-next-queued) so it'd be simpler to merge this series in drm-intel rather than drm-next. Options are: - merge it through drm-intel (yey!) - merge it through drm-next once the current drm-intel has been merged (will probably need a rebase because of the crtc_clock addition) - merge the drm patches through drm-next and the drm/i915 ones through drm-intel, but that'll likely need me to rebase the i915 patches as well. All in all, it'd be much easier to merge it through drm-intel (if people are happy with the current state of the series, of course). -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: "ring test failed" on PA-RISC Linux
24.09.2013, 00:11, "Konrad Rzeszutek Wilk" :
> On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
>
>> 21.09.2013, в 1:27, Alex Deucher написал(а):
>>> The register writes seems to be going through the register backbone
>>> correctly:
>>>
>>> [0x00B] 0x15E0=0x
>>> [0x00C] 0x15E4=0xCAFEDEAD
>>> [0x00D] 0x4274=0x000F
>>> [0x00E] 0x42C8=0x0007
>>> [0x00F] 0x4018=0x001D
>>> [0x010] 0x170C=0x8000
>>> [0x011] 0x3428=0x00020100
>>> [0x012] 0x15E4=0xCAFEDEAD
>>>
>>> You can see the 0xCAFEDEAD written to the scratch register via MMIO
>>> from the ring_test(). The CP fifo however seems to be full of garbage.
>>> The CP is busy though, so it seems to be functional. I guess it's
>>> just fetching garbage rather than commands.
>
> If it is fetching garbage, that would imply the DMA (or bus addresses)
> that are programmed in the GART are bogus. If you dump them and try
> to figure out if bus adress -> physical address -> virtual address ==
> virtual address -> bus address that could help. And perhaps seeing what
> the virtual address has - and or poisoning it with known data?
>
> Or perhaps the the card has picked up an incorrect page table? Meaning
> the (bus) address given to it is not the correct one?
>
Konrad,
Let's see. Please notice that i'm not PA-RISC or general linux kernel
developer, just the user, so i may do things completely wrong.
I was hoping that PA-RISC smarties will join me here, but they seem
to be busy with other duties. Even port's mail list activity is low
during last weeks.
> If you dump them and try
> to figure out if bus adress -> physical address -> virtual address ==
> virtual address -> bus address that could help
With following
radeon/radeon_ttm.c:
radeon_ttm_tt_populate():
...
for (i = 0; i < ttm->num_pages; i++) {
gtt->ttm.dma_address[i] = pci_map_page(rdev->pdev,
ttm->pages[i],
0, PAGE_SIZE,
PCI_DMA_BIDIRECTIONAL);
void *va = bus_to_virt(gtt->ttm.dma_address[i]);
if ((phys_addr_t) va != virt_to_bus(va)) {
DRM_INFO("MISMATCH: %p != %p\n", va, (void *)
virt_to_bus(va));
/*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ //
Leads to a Kernel Fault
...
}
I'm getting the output:
[drm] MISMATCH: 8028 != 4028
[drm] MISMATCH: 80281000 != 40281000
...
How can i check the same for an AGP mode?
> Or perhaps the the card has picked up an incorrect page table? Meaning
> the (bus) address given to it is not the correct one?
I'll see.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Fix Win8 backlight issue
On Wed, 25 Sep 2013, Jörg Otte wrote: > 2013/9/25 Jani Nikula : >> On Wed, 25 Sep 2013, Aaron Lu wrote: >>> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 >> >> So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? > > In v3.11-rc1 it didn't work. > Since a later rc (I don't remember exactly which) it did work. > In v3.12-rc1/2 it does work. > In v3.12-rc2 + Aaron's patch set it again doesn't work. > >> >>> Thanks for the test. >>> >>> Please check /sys/class/backlight, is there only one link file >>> intel_backlight? >> >> Indeed, are there others? fujitsu-laptop perhaps? If yes, try >> CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. >> >> Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? > > There is only one intel_backlight link. > Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y > >> Embarrassingly there was a bug in i915 fixed just recently where the >> backlight device wasn't registered for >> CONFIG_BACKLIGHT_CLASS_DEVICE=m... >> >>> If so, please cd inside and try modify the brightness file using echo >>> with some values in the range of 0 - max_brightness, does the >>> backlight level change when you echo a new value? I guess it doesn't, >>> or you wouldn't notice problem. If indeed so, perhaps file a bug at >>> http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani >>> and Daniel can help fix your problem. >> >> Yup, please check the above, and report back. > > - echo 0..max_brightness > brightness does not work. Thanks for the info. How about v3.12-rc2 without Aaron's patches? Does intel_backlight also not work there? How about the acpi_video0 (which I presume is present) sysfs interface? BR, Jani. > Video driver: i915 FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 acpi_backlight=video works. > > Jörg ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #19 from Alex Deucher --- Created attachment 86570 --> https://bugs.freedesktop.org/attachment.cgi?id=86570&action=edit possible fix Does this patch fix the playback problems? -- 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 69671] rv790 hdmi sound regression since fix audio dto calculation on DCE3+ (v3)
https://bugs.freedesktop.org/show_bug.cgi?id=69671 --- Comment #4 from Alex Deucher --- Created attachment 86569 --> https://bugs.freedesktop.org/attachment.cgi?id=86569&action=edit possible fix Does this patch fix the isssue? -- 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 21/22] drm/i915: Prefer crtc_{h|v}display for pipe src dimensions
Now that we ask to adjust the crtc timings for stereo modes, the correct pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay. v2: Add comment about why pipe_src_w/h need to be set afert set_crtcinfo() (Daniel Vetter) Reviewed-by: Ville Syrjälä Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_display.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c25622d..c94fe38 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8400,9 +8400,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, drm_mode_copy(&pipe_config->adjusted_mode, mode); drm_mode_copy(&pipe_config->requested_mode, mode); - pipe_config->pipe_src_w = mode->hdisplay; - pipe_config->pipe_src_h = mode->vdisplay; - pipe_config->cpu_transcoder = (enum transcoder) to_intel_crtc(crtc)->pipe; pipe_config->shared_dpll = DPLL_ID_PRIVATE; @@ -8437,6 +8434,10 @@ encoder_retry: /* Fill in default crtc timings, allow encoders to overwrite them. */ drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, CRTC_STEREO_DOUBLE); + /* set_crtcinfo() may have adjusted hdisplay/vdisplay */ + pipe_config->pipe_src_w = pipe_config->adjusted_mode.crtc_hdisplay; + pipe_config->pipe_src_h = pipe_config->adjusted_mode.crtc_vdisplay; + /* Pass our mode to the connectors and the CRTC to give them a chance to * adjust it according to limitations or connector properties, and also * a chance to reject the mode entirely. -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 22/22] drm/i915: Allow stereo modes on HDMI
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1a57758..6004f9c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1228,6 +1228,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
+ connector->stereo_allowed = 1;
switch (port) {
case PORT_B:
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/22] drm/i915: Ask the DRM core do make stereo timings adjustements
When scanning out big stereo buffers that are actually bigger that their natural 2D counterpart, we need to blow up the crtc timings as well. Not that this is only done for frame packing as this is the only stereo mode currently exposed needing this kind of ajdustements. Reviewed-by: Ville Syrjälä Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3c982a4..c25622d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8435,7 +8435,7 @@ encoder_retry: pipe_config->pixel_multiplier = 1; /* Fill in default crtc timings, allow encoders to overwrite them. */ - drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, 0); + drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, CRTC_STEREO_DOUBLE); /* Pass our mode to the connectors and the CRTC to give them a chance to * adjust it according to limitations or connector properties, and also -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/22] drm/i915: Use crtc_clock with the adjusted mode
struct drm_mode_display now has a separate crtc_ version of the clock to
be used when we're talking about the timings given to the harwadre (was
far as the mode is concerned).
This commit is really the result of a git grep adjusted_mode.*clock and
replacing those by adjusted_mode.crtc_clock. No functional change.
v2: Rebased on drm-intel-queued-next
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_crt.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 34 +-
drivers/gpu/drm/i915/intel_dp.c | 11 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c| 6 +++---
drivers/gpu/drm/i915/intel_lvds.c| 2 +-
drivers/gpu/drm/i915/intel_pm.c | 36 +++-
drivers/gpu/drm/i915/intel_sdvo.c| 2 +-
drivers/gpu/drm/i915/intel_tv.c | 2 +-
10 files changed, 56 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 019c4ce..0263629 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -117,7 +117,7 @@ static void intel_crt_get_config(struct intel_encoder
*encoder,
if (HAS_PCH_SPLIT(dev))
ironlake_check_encoder_dotclock(pipe_config, dotclock);
- pipe_config->adjusted_mode.clock = dotclock;
+ pipe_config->adjusted_mode.crtc_clock = dotclock;
}
static void hsw_crt_get_config(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 88c641a..3c982a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -739,14 +739,14 @@ bool intel_crtc_active(struct drm_crtc *crtc)
/* Be paranoid as we can arrive here with only partial
* state retrieved from the hardware during setup.
*
-* We can ditch the adjusted_mode.clock check as soon
+* We can ditch the adjusted_mode.crtc_clock check as soon
* as Haswell has gained clock readout/fastboot support.
*
* We can ditch the crtc->fb check as soon as we can
* properly reconstruct framebuffers.
*/
return intel_crtc->active && crtc->fb &&
- intel_crtc->config.adjusted_mode.clock;
+ intel_crtc->config.adjusted_mode.crtc_clock;
}
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
@@ -2913,7 +2913,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- int clock = to_intel_crtc(crtc)->config.adjusted_mode.clock;
+ int clock = to_intel_crtc(crtc)->config.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
@@ -2937,8 +2937,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
phaseinc = 0x20;
} else {
/* The iCLK virtual clock root frequency is in MHz,
-* but the adjusted_mode->clock in in KHz. To get the divisors,
-* it is necessary to divide one by another, so we
+* but the adjusted_mode->crtc_clock in in KHz. To get the
+* divisors, it is necessary to divide one by another, so we
* convert the virtual clock precision to KHz here for higher
* precision.
*/
@@ -4148,7 +4148,7 @@ retry:
*/
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
- fdi_dotclock = adjusted_mode->clock;
+ fdi_dotclock = adjusted_mode->crtc_clock;
lane = ironlake_get_lanes_required(fdi_dotclock, link_bw,
pipe_config->pipe_bpp);
@@ -4204,12 +4204,12 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* otherwise pipe A only.
*/
if ((crtc->pipe == PIPE_A || IS_I915G(dev)) &&
- adjusted_mode->clock > clock_limit * 9 / 10) {
+ adjusted_mode->crtc_clock > clock_limit * 9 / 10) {
clock_limit *= 2;
pipe_config->double_wide = true;
}
- if (adjusted_mode->clock > clock_limit * 9 / 10)
+ if (adjusted_mode->crtc_clock > clock_limit * 9 / 10)
return -EINVAL;
}
@@ -4869,7 +4869,7 @@ static void intel_crtc_mode_from_pipe_config(struct
intel_crtc *intel_crtc,
crtc->mode.flags = pipe_config->adjusted_mode.flags;
- crtc->mode.clock = pipe_config->adjusted_mode.clock;
+ crtc->mode.clock = pipe_config->adjusted_mode.crtc_clock;
crtc->mode.flags |= pipe_config->adjusted_mode.flags;
}
@@ -7440,7 +7440,7 @@ static void i9xx_crtc_clock_get(struct intel_crtc
[PATCH 18/22] drm/i915: Use crtc_clock in intel_dump_crtc_timings()
We want to dump the parameters given to the hardware, so let's use
crtc_clock here.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d12d563..88c641a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8310,7 +8310,7 @@ static void intel_dump_crtc_timings(const struct
drm_display_mode *mode)
{
DRM_DEBUG_KMS("crtc timings: %d %d %d %d %d %d %d %d %d, "
"type: 0x%x flags: 0x%x\n",
- mode->clock,
+ mode->crtc_clock,
mode->crtc_hdisplay, mode->crtc_hsync_start,
mode->crtc_hsync_end, mode->crtc_htotal,
mode->crtc_vdisplay, mode->crtc_vsync_start,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/22] drm: Implement timings adjustments for frame packing
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
v2: Use crtc_vtotal and multiply the clock by 2 instead of
reconstructing it (Ville Syrjälä)
Suggested-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 22 +-
include/drm/drm_crtc.h | 3 ++-
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ef26eb2..b073315 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -707,12 +707,18 @@ EXPORT_SYMBOL(drm_mode_vrefresh);
/**
* drm_mode_set_crtcinfo - set CRTC modesetting parameters
* @p: mode
- * @adjust_flags: unused? (FIXME)
+ * @adjust_flags: a combination of adjustment flags
*
* LOCKING:
* None.
*
* Setup the CRTC modesetting parameters for @p, adjusting if necessary.
+ *
+ * - The CRTC_INTERLACE_HALVE_V flag can be used to halve vertical timings of
+ * interlaced modes.
+ * - The CRTC_STEREO_DOUBLE flag can be used to compute the timings for
+ * buffers containing two eyes (only adjust the timings when needed, eg. for
+ * "frame packing" or "side by side full").
*/
void drm_mode_set_crtcinfo(struct drm_display_mode *p, int adjust_flags)
{
@@ -753,6 +759,20 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int
adjust_flags)
p->crtc_vtotal *= p->vscan;
}
+ if (adjust_flags & CRTC_STEREO_DOUBLE) {
+ unsigned int layout = p->flags & DRM_MODE_FLAG_3D_MASK;
+
+ switch (layout) {
+ case DRM_MODE_FLAG_3D_FRAME_PACKING:
+ p->crtc_clock *= 2;
+ p->crtc_vdisplay += p->crtc_vtotal;
+ p->crtc_vsync_start += p->crtc_vtotal;
+ p->crtc_vsync_end += p->crtc_vtotal;
+ p->crtc_vtotal += p->crtc_vtotal;
+ break;
+ }
+ }
+
p->crtc_vblank_start = min(p->crtc_vsync_start, p->crtc_vdisplay);
p->crtc_vblank_end = max(p->crtc_vsync_end, p->crtc_vtotal);
p->crtc_hblank_start = min(p->crtc_hsync_start, p->crtc_hdisplay);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73478bc..b2d08ca 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -125,7 +125,8 @@ enum drm_mode_status {
.vscan = (vs), .flags = (f), \
.base.type = DRM_MODE_OBJECT_MODE
-#define CRTC_INTERLACE_HALVE_V 0x1 /* halve V values for interlacing */
+#define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
+#define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
struct drm_display_mode {
/* Header */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/22] drm: Check the fb size against the adjusted v/hdisplay for stereo modes
Some stereo modes, like frame packing, need a larger CRTC viewport than
the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
needs to query the adjusted mode to use the correct h/vdisplay.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index db05864..807309f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2078,6 +2078,14 @@ static int drm_crtc_check_viewport(const struct drm_crtc
*crtc,
hdisplay = mode->hdisplay;
vdisplay = mode->vdisplay;
+ if (drm_mode_is_stereo(mode)) {
+ struct drm_display_mode adjusted = *mode;
+
+ drm_mode_set_crtcinfo(&adjusted, CRTC_STEREO_DOUBLE);
+ hdisplay = adjusted.crtc_hdisplay;
+ vdisplay = adjusted.crtc_vdisplay;
+ }
+
if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/22] drm: Introduce a crtc_clock for struct drm_display_mode
Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 1 +
include/drm/drm_crtc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c2cb2c8..ef26eb2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -719,6 +719,7 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int
adjust_flags)
if ((p == NULL) || ((p->type & DRM_MODE_TYPE_CRTC_C) ==
DRM_MODE_TYPE_BUILTIN))
return;
+ p->crtc_clock = p->clock;
p->crtc_hdisplay = p->hdisplay;
p->crtc_hsync_start = p->hsync_start;
p->crtc_hsync_end = p->hsync_end;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8e9716e..73478bc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,6 +156,7 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
+ int crtc_clock; /* in KHz */
int crtc_hdisplay;
int crtc_hblank_start;
int crtc_hblank_end;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/22] drm: Remove clock_index from struct drm_display_mode
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Acked-by: Ben Skeggs
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 --
include/drm/drm_crtc.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index d4fbf11..0e3270c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -326,8 +326,6 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct
drm_display_mode *mode)
regp->MiscOutReg = 0x23;/* +hsync +vsync */
}
- regp->MiscOutReg |= (mode->clock_index & 0x03) << 2;
-
/*
* Time Sequencer
*/
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1b69407..011baaa 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,7 +156,6 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
- int clock_index;
int synth_clock;
int crtc_hdisplay;
int crtc_hblank_start;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/22] drm: Set the relevant infoframe field when scanning out a 3D mode
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7366007..0bae76d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3421,6 +3421,33 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+static enum hdmi_3d_structure
+s3d_structure_from_display_mode(const struct drm_display_mode *mode)
+{
+ u32 layout = mode->flags & DRM_MODE_FLAG_3D_MASK;
+
+ switch (layout) {
+ case DRM_MODE_FLAG_3D_FRAME_PACKING:
+ return HDMI_3D_STRUCTURE_FRAME_PACKING;
+ case DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE:
+ return HDMI_3D_STRUCTURE_FIELD_ALTERNATIVE;
+ case DRM_MODE_FLAG_3D_LINE_ALTERNATIVE:
+ return HDMI_3D_STRUCTURE_LINE_ALTERNATIVE;
+ case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL:
+ return HDMI_3D_STRUCTURE_SIDE_BY_SIDE_FULL;
+ case DRM_MODE_FLAG_3D_L_DEPTH:
+ return HDMI_3D_STRUCTURE_L_DEPTH;
+ case DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH:
+ return HDMI_3D_STRUCTURE_L_DEPTH_GFX_GFX_DEPTH;
+ case DRM_MODE_FLAG_3D_TOP_AND_BOTTOM:
+ return HDMI_3D_STRUCTURE_TOP_AND_BOTTOM;
+ case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
+ return HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF;
+ default:
+ return HDMI_3D_STRUCTURE_INVALID;
+ }
+}
+
/**
* drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI infoframe with
* data from a DRM display mode
@@ -3438,20 +3465,29 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
const struct drm_display_mode *mode)
{
int err;
+ u32 s3d_flags;
u8 vic;
if (!frame || !mode)
return -EINVAL;
vic = drm_match_hdmi_mode(mode);
- if (!vic)
+ s3d_flags = mode->flags & DRM_MODE_FLAG_3D_MASK;
+
+ if (!vic && !s3d_flags)
+ return -EINVAL;
+
+ if (vic && s3d_flags)
return -EINVAL;
err = hdmi_vendor_infoframe_init(frame);
if (err < 0)
return err;
- frame->vic = vic;
+ if (vic)
+ frame->vic = vic;
+ else
+ frame->s3d_struct = s3d_structure_from_display_mode(mode);
return 0;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/22] drm: Remove synth_clock from struct drm_display_mode
This field is unused. Garbage collect it.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 011baaa..8e9716e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,7 +156,6 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
- int synth_clock;
int crtc_hdisplay;
int crtc_hblank_start;
int crtc_hblank_end;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/22] drm: Factor out common CRTC viewport checking code
Both setcrtc and page_flip are checking that the framebuffer is big
enough for the defined crtc viewport (x, y, hdisplay, vdisplay). Factor
that code out in a single function.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 70 --
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 090415f..db05864 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2063,6 +2063,37 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
}
EXPORT_SYMBOL(drm_mode_set_config_internal);
+/*
+ * Checks that the framebuffer is big enough for the CRTC viewport
+ * (x, y, hdisplay, vdisplay)
+ */
+static int drm_crtc_check_viewport(const struct drm_crtc *crtc,
+ int x, int y,
+ const struct drm_display_mode *mode,
+ const struct drm_framebuffer *fb)
+
+{
+ int hdisplay, vdisplay;
+
+ hdisplay = mode->hdisplay;
+ vdisplay = mode->vdisplay;
+
+ if (crtc->invert_dimensions)
+ swap(hdisplay, vdisplay);
+
+ if (hdisplay > fb->width ||
+ vdisplay > fb->height ||
+ x > fb->width - hdisplay ||
+ y > fb->height - vdisplay) {
+ DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height, hdisplay, vdisplay, x, y,
+ crtc->invert_dimensions ? " (inverted)" : "");
+ return -ENOSPC;
+ }
+
+ return 0;
+}
+
/**
* drm_mode_setcrtc - set CRTC configuration
* @dev: drm device for the ioctl
@@ -2110,7 +2141,6 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
if (crtc_req->mode_valid) {
- int hdisplay, vdisplay;
/* If we have a mode we need a framebuffer. */
/* If we pass -1, set the mode with the currently bound fb */
if (crtc_req->fb_id == -1) {
@@ -2146,23 +2176,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
- hdisplay = mode->hdisplay;
- vdisplay = mode->vdisplay;
-
- if (crtc->invert_dimensions)
- swap(hdisplay, vdisplay);
-
- if (hdisplay > fb->width ||
- vdisplay > fb->height ||
- crtc_req->x > fb->width - hdisplay ||
- crtc_req->y > fb->height - vdisplay) {
- DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
- fb->width, fb->height,
- hdisplay, vdisplay, crtc_req->x,
crtc_req->y,
- crtc->invert_dimensions ? " (inverted)" :
"");
- ret = -ENOSPC;
+ ret = drm_crtc_check_viewport(crtc, crtc_req->x, crtc_req->y,
+ mode, fb);
+ if (ret)
goto out;
- }
+
}
if (crtc_req->count_connectors == 0 && mode) {
@@ -3579,7 +3597,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
struct drm_framebuffer *fb = NULL, *old_fb = NULL;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
- int hdisplay, vdisplay;
int ret = -EINVAL;
if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
@@ -3611,22 +3628,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!fb)
goto out;
- hdisplay = crtc->mode.hdisplay;
- vdisplay = crtc->mode.vdisplay;
-
- if (crtc->invert_dimensions)
- swap(hdisplay, vdisplay);
-
- if (hdisplay > fb->width ||
- vdisplay > fb->height ||
- crtc->x > fb->width - hdisplay ||
- crtc->y > fb->height - vdisplay) {
- DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
- fb->width, fb->height, hdisplay, vdisplay,
crtc->x, crtc->y,
- crtc->invert_dimensions ? " (inverted)" : "");
- ret = -ENOSPC;
+ ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y, &crtc->mode, fb);
+ if (ret)
goto out;
- }
if (crtc->fb->pixel_format != fb->pixel_format) {
DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
format.\n");
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/22] drm: Make exposing stereo modes a per-connector opt-in
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 8 +++-
include/drm/drm_crtc.h| 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index c722c3b..4280e37 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -76,7 +76,8 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
{
struct drm_display_mode *mode;
- if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE))
+ if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE |
+ DRM_MODE_FLAG_3D_MASK))
return;
list_for_each_entry(mode, &connector->modes, head) {
@@ -86,6 +87,9 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
if ((mode->flags & DRM_MODE_FLAG_DBLSCAN) &&
!(flags & DRM_MODE_FLAG_DBLSCAN))
mode->status = MODE_NO_DBLESCAN;
+ if ((mode->flags & DRM_MODE_FLAG_3D_MASK) &&
+ !(flags & DRM_MODE_FLAG_3D_MASK))
+ mode->status = MODE_NO_STEREO;
}
return;
@@ -175,6 +179,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
mode_flags |= DRM_MODE_FLAG_INTERLACE;
if (connector->doublescan_allowed)
mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+ if (connector->stereo_allowed)
+ mode_flags |= DRM_MODE_FLAG_3D_MASK;
drm_mode_validate_flag(connector, mode_flags);
list_for_each_entry(mode, &connector->modes, head) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6b7f9c7..1b69407 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -108,6 +108,7 @@ enum drm_mode_status {
MODE_ONE_HEIGHT,/* only one height is supported */
MODE_ONE_SIZE, /* only one resolution is supported */
MODE_NO_REDUCED,/* monitor doesn't accept reduced blanking */
+MODE_NO_STEREO,/* stereo modes not supported */
MODE_UNVERIFIED = -3, /* mode needs to reverified */
MODE_BAD = -2, /* unspecified reason */
MODE_ERROR = -1/* error condition */
@@ -611,6 +612,7 @@ struct drm_connector {
int connector_type_id;
bool interlace_allowed;
bool doublescan_allowed;
+ bool stereo_allowed;
struct list_head modes; /* list of modes on this connector */
enum drm_connector_status status;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/22] drm: Carry over the stereo flags when adding the alternate mode
This allows to expose the alternate clock versions of the stereo modes. Reviewed-by: Ville Syrjälä Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 48f1746..c24af1d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2507,6 +2507,9 @@ add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid) if (!newmode) continue; + /* Carry over the stereo flags */ + newmode->flags |= mode->flags & DRM_MODE_FLAG_3D_MASK; + /* * The current mode could be either variant. Make * sure to pick the "other" clock for the new mode. -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/22] drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modes
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 4 ++--
drivers/gpu/drm/drm_modes.c | 18 --
include/drm/drm_crtc.h | 2 +-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0bae76d..48f1746 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2404,7 +2404,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
- drm_mode_equal_no_clocks(to_match, cea_mode))
+ drm_mode_equal_no_clocks_no_stereo(to_match, cea_mode))
return mode + 1;
}
return 0;
@@ -2453,7 +2453,7 @@ static u8 drm_match_hdmi_mode(const struct
drm_display_mode *to_match)
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
- drm_mode_equal_no_clocks(to_match, hdmi_mode))
+ drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return mode + 1;
}
return 0;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fc2adb6..c2cb2c8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -830,12 +830,16 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
const struct drm_displ
} else if (mode1->clock != mode2->clock)
return false;
- return drm_mode_equal_no_clocks(mode1, mode2);
+ if ((mode1->flags & DRM_MODE_FLAG_3D_MASK) !=
+ (mode2->flags & DRM_MODE_FLAG_3D_MASK))
+ return false;
+
+ return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
}
EXPORT_SYMBOL(drm_mode_equal);
/**
- * drm_mode_equal_no_clocks - test modes for equality
+ * drm_mode_equal_no_clocks_no_stereo - test modes for equality
* @mode1: first mode
* @mode2: second mode
*
@@ -843,12 +847,13 @@ EXPORT_SYMBOL(drm_mode_equal);
* None.
*
* Check to see if @mode1 and @mode2 are equivalent, but
- * don't check the pixel clocks.
+ * don't check the pixel clocks nor the stereo layout.
*
* RETURNS:
* True if the modes are equal, false otherwise.
*/
-bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const
struct drm_display_mode *mode2)
+bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
{
if (mode1->hdisplay == mode2->hdisplay &&
mode1->hsync_start == mode2->hsync_start &&
@@ -860,12 +865,13 @@ bool drm_mode_equal_no_clocks(const struct
drm_display_mode *mode1, const struct
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
- mode1->flags == mode2->flags)
+ (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
return false;
}
-EXPORT_SYMBOL(drm_mode_equal_no_clocks);
+EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
/**
* drm_mode_validate_size - make sure modes adhere to size constraints
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 825d6fa..6b7f9c7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -989,7 +989,7 @@ extern void drm_mode_config_reset(struct drm_device *dev);
extern void drm_mode_config_cleanup(struct drm_device *dev);
extern void drm_mode_set_name(struct drm_display_mode *mode);
extern bool drm_mode_equal(const struct drm_display_mode *mode1, const struct
drm_display_mode *mode2);
-extern bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1,
const struct drm_display_mode *mode2);
+extern bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode
*mode1, const struct drm_display_mode *mode2);
extern int drm_mode_width(const struct drm_display_mode *mode);
extern int drm_mode_height(const struct drm_display_mode *mode);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/22] drm: Reject modes with more than 1 stereo flags set
When setting a stereo 3D mode, there can be only one bit set describing the layout of the frambuffer(s). So reject invalid modes early. Reviewed-by: Ville Syrjälä Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_crtc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 454ac8a..090415f 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1319,6 +1319,10 @@ static int drm_crtc_convert_umode(struct drm_display_mode *out, if (in->clock > INT_MAX || in->vrefresh > INT_MAX) return -ERANGE; + /* At most, 1 set bit describing the 3D layout of the mode */ + if (hweight32(in->flags & DRM_MODE_FLAG_3D_MASK) > 1) + return -EINVAL; + out->clock = in->clock; out->hdisplay = in->hdisplay; out->hsync_start = in->hsync_start; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/22] drm: Extract add_hdmi_mode() out of do_hdmi_vsdb_modes()
So we respect a nice design of having similar functions at the same
level, in this case:
do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 52e6087..7366007 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2634,6 +2634,26 @@ static int add_hdmi_mandatory_stereo_modes(struct
drm_connector *connector)
return modes;
}
+static int add_hdmi_mode(struct drm_connector *connector, u8 vic)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *newmode;
+
+ vic--; /* VICs start at 1 */
+ if (vic >= ARRAY_SIZE(edid_4k_modes)) {
+ DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
+ return 0;
+ }
+
+ newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
+ if (!newmode)
+ return 0;
+
+ drm_mode_probed_add(connector, newmode);
+
+ return 1;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
@@ -2646,7 +2666,6 @@ static int add_hdmi_mandatory_stereo_modes(struct
drm_connector *connector)
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
{
- struct drm_device *dev = connector->dev;
int modes = 0, offset = 0, i;
u8 vic_len;
@@ -2679,23 +2698,10 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
vic_len = db[8 + offset] >> 5;
for (i = 0; i < vic_len && len >= (9 + offset + i); i++) {
- struct drm_display_mode *newmode;
u8 vic;
vic = db[9 + offset + i];
-
- vic--; /* VICs start at 1 */
- if (vic >= ARRAY_SIZE(edid_4k_modes)) {
- DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
- continue;
- }
-
- newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
- if (!newmode)
- continue;
-
- drm_mode_probed_add(connector, newmode);
- modes++;
+ modes += add_hdmi_mode(connector, vic);
}
out:
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/22] drm/edid: Expose mandatory stereo modes for HDMI sinks
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
v2: Rename freq to vrefresh, make the mandatory structure a bit more
compact, fix some white space issues and add a couple of const
(Ville Syrjälä)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 110 ++---
1 file changed, 103 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1688ff5..52e6087 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2553,13 +2553,95 @@ do_cea_modes(struct drm_connector *connector, const u8
*db, u8 len)
return modes;
}
+struct stereo_mandatory_mode {
+ int width, height, vrefresh;
+ unsigned int flags;
+};
+
+static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
+ { 1920, 1080, 24,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1920, 1080, 50,
+ DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+ { 1920, 1080, 60,
+ DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+ { 1280, 720, 50,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1280, 720, 60,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+};
+
+static bool
+stereo_match_mandatory(const struct drm_display_mode *mode,
+ const struct stereo_mandatory_mode *stereo_mode)
+{
+ unsigned int interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
+
+ return mode->hdisplay == stereo_mode->width &&
+ mode->vdisplay == stereo_mode->height &&
+ interlaced == (stereo_mode->flags & DRM_MODE_FLAG_INTERLACE) &&
+ drm_mode_vrefresh(mode) == stereo_mode->vrefresh;
+}
+
+static const struct stereo_mandatory_mode *
+hdmi_find_stereo_mandatory_mode(const struct drm_display_mode *mode)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(stereo_mandatory_modes); i++)
+ if (stereo_match_mandatory(mode, &stereo_mandatory_modes[i]))
+ return &stereo_mandatory_modes[i];
+
+ return NULL;
+}
+
+static int add_hdmi_mandatory_stereo_modes(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ const struct drm_display_mode *mode;
+ struct list_head stereo_modes;
+ int modes = 0;
+
+ INIT_LIST_HEAD(&stereo_modes);
+
+ list_for_each_entry(mode, &connector->probed_modes, head) {
+ const struct stereo_mandatory_mode *mandatory;
+ u32 stereo_layouts, layout;
+
+ mandatory = hdmi_find_stereo_mandatory_mode(mode);
+ if (!mandatory)
+ continue;
+
+ stereo_layouts = mandatory->flags & DRM_MODE_FLAG_3D_MASK;
+ do {
+ struct drm_display_mode *new_mode;
+
+ layout = 1 << (ffs(stereo_layouts) - 1);
+ stereo_layouts &= ~layout;
+
+ new_mode = drm_mode_duplicate(dev, mode);
+ if (!new_mode)
+ continue;
+
+ new_mode->flags |= layout;
+ list_add_tail(&new_mode->head, &stereo_modes);
+ modes++;
+ } while (stereo_layouts);
+ }
+
+ list_splice_tail(&stereo_modes, &connector->probed_modes);
+
+ return modes;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
* @db: start of the CEA vendor specific block
* @len: length of the CEA block payload, ie. one can access up to db[len]
*
- * Parses the HDMI VSDB looking for modes to add to @connector.
+ * Parses the HDMI VSDB looking for modes to add to @connector. This function
+ * also adds the stereo 3d modes when applicable.
*/
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
@@ -2585,10 +2667,15 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
/* the declared length is not long enough for the 2 first bytes
* of additional video format capabilities */
- offset += 2;
- if (len < (8 + offset))
+ if (len < (8 + offset + 2))
goto out;
+ /* 3D_Present */
+ offset++;
+ if (db[8 + offset] & (1 << 7))
+ modes += add_hdmi_mandatory_stereo_modes(connector);
+
+ offset++;
vic_len = db[8 + offset] >> 5;
for (i = 0; i < vic_len && len >= (9 + offset + i); i++) {
@@ -2668,8 +2755,8 @@ static int
add_cea_modes(struct drm_connector *connector, str
[PATCH 04/22] drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctl
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo modes from the list of modes we
give to DRM clients by default, and let them through if we are being
told otherwise.
stereo_allowed is bound to the drm_file structure to make it a
per-client setting, not a global one.
v2: Replace clearing 3D flags by discarding the stereo modes now that
they are regular modes.
v3: SET_CAP -> SET_CLIENT_CAP rename (Chris Wilson)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 19 ++-
drivers/gpu/drm/drm_ioctl.c | 14 +-
include/drm/drmP.h | 3 +++
include/uapi/drm/drm.h | 9 +
4 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79577c..454ac8a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1581,6 +1581,19 @@ out:
return ret;
}
+static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct drm_file *file_priv)
+{
+ /*
+* If user-space hasn't configured the driver to expose the stereo 3D
+* modes, don't expose them.
+*/
+ if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
+ return false;
+
+ return true;
+}
+
/**
* drm_mode_getconnector - get connector configuration
* @dev: drm device for the ioctl
@@ -1646,7 +1659,8 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
/* delayed so we get modes regardless of pre-fill_modes state */
list_for_each_entry(mode, &connector->modes, head)
- mode_count++;
+ if (drm_mode_expose_to_userspace(mode, file_priv))
+ mode_count++;
out_resp->connector_id = connector->base.id;
out_resp->connector_type = connector->connector_type;
@@ -1668,6 +1682,9 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned
long)out_resp->modes_ptr;
list_for_each_entry(mode, &connector->modes, head) {
+ if (!drm_mode_expose_to_userspace(mode, file_priv))
+ continue;
+
drm_crtc_convert_to_umode(&u_mode, mode);
if (copy_to_user(mode_ptr + copied,
&u_mode, sizeof(u_mode))) {
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 15da412..dffc836 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -308,7 +308,19 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
int
drm_setclientcap(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
- return -EINVAL;
+ struct drm_set_client_cap *req = data;
+
+ switch (req->capability) {
+ case DRM_CLIENT_CAP_STEREO_3D:
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->stereo_allowed = req->value;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
}
/**
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index dbc86b0..c65f496 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -433,6 +433,9 @@ struct drm_file {
struct drm_master *master; /* master this node is currently associated
with
N.B. not always minor->master */
+ /* true when the client has asked us to expose stereo 3D mode flags */
+ bool stereo_allowed;
+
/**
* fbs - List of framebuffers associated with this file.
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 526baed..9b24d65 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -627,6 +627,15 @@ struct drm_get_cap {
__u64 value;
};
+/**
+ * DRM_CLIENT_CAP_STEREO_3D
+ *
+ * if set to 1, the DRM core will expose the stereo 3D capabilities of the
+ * monitor by advertising the supported 3D layouts in the flags of struct
+ * drm_mode_modeinfo.
+ */
+#define DRM_CLIENT_CAP_STEREO_3D 1
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/22] drm: Add HDMI stereo 3D flags to struct drm_mode_modeinfo
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 14 ++
include/uapi/drm/drm_mode.h | 36 ++--
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 24f4995..825d6fa 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -180,6 +180,20 @@ struct drm_display_mode {
int hsync; /* in kHz */
};
+#define DRM_MODE_FLAG_3D_MASK (DRM_MODE_FLAG_3D_FRAME_PACKING | \
+DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE | \
+DRM_MODE_FLAG_3D_LINE_ALTERNATIVE | \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL | \
+DRM_MODE_FLAG_3D_L_DEPTH | \
+DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH | \
+DRM_MODE_FLAG_3D_TOP_AND_BOTTOM| \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
+
+static inline bool drm_mode_is_stereo(const struct drm_display_mode *mode)
+{
+ return mode->flags & DRM_MODE_FLAG_3D_MASK;
+}
+
enum drm_connector_status {
connector_status_connected = 1,
connector_status_disconnected = 2,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 113d324..bafe612 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -44,20 +44,28 @@
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC (1<<0)
-#define DRM_MODE_FLAG_NHSYNC (1<<1)
-#define DRM_MODE_FLAG_PVSYNC (1<<2)
-#define DRM_MODE_FLAG_NVSYNC (1<<3)
-#define DRM_MODE_FLAG_INTERLACE(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN (1<<5)
-#define DRM_MODE_FLAG_CSYNC(1<<6)
-#define DRM_MODE_FLAG_PCSYNC (1<<7)
-#define DRM_MODE_FLAG_NCSYNC (1<<8)
-#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(1<<10)
-#define DRM_MODE_FLAG_PIXMUX (1<<11)
-#define DRM_MODE_FLAG_DBLCLK (1<<12)
-#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_PHSYNC (1<<0)
+#define DRM_MODE_FLAG_NHSYNC (1<<1)
+#define DRM_MODE_FLAG_PVSYNC (1<<2)
+#define DRM_MODE_FLAG_NVSYNC (1<<3)
+#define DRM_MODE_FLAG_INTERLACE(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN (1<<5)
+#define DRM_MODE_FLAG_CSYNC(1<<6)
+#define DRM_MODE_FLAG_PCSYNC (1<<7)
+#define DRM_MODE_FLAG_NCSYNC (1<<8)
+#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(1<<10)
+#define DRM_MODE_FLAG_PIXMUX (1<<11)
+#define DRM_MODE_FLAG_DBLCLK (1<<12)
+#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (1<<14)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (1<<15)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (1<<16)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (1<<17)
+#define DRM_MODE_FLAG_3D_L_DEPTH (1<<18)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (1<<19)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(1<<20)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (1<<21)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/22] drm: Add a SET_CLIENT_CAP ioctl
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from SET_CAP to SET_CLIENT_CAP (Chris Wilson)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_drv.c | 1 +
drivers/gpu/drm/drm_ioctl.c | 9 +
include/drm/drmP.h | 2 ++
include/uapi/drm/drm.h | 7 +++
4 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e572dd2..e79d8d9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -69,6 +69,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_CLIENT_CAP, drm_setclientcap, 0),
DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 07247e2..15da412 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -303,6 +303,15 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
}
/**
+ * Set device/driver capabilities
+ */
+int
+drm_setclientcap(struct drm_device *dev, void *data, struct drm_file
*file_priv)
+{
+ return -EINVAL;
+}
+
+/**
* Setversion ioctl.
*
* \param inode device inode.
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b46fb45..dbc86b0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1303,6 +1303,8 @@ extern int drm_getstats(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
extern int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_setclientcap(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
extern int drm_setversion(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int drm_noop(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 1e09e8f..526baed 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -627,6 +627,12 @@ struct drm_get_cap {
__u64 value;
};
+/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
+struct drm_set_client_cap {
+ __u64 capability;
+ __u64 value;
+};
+
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
@@ -659,6 +665,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_GEM_FLINKDRM_IOWR(0x0a, struct drm_gem_flink)
#define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
#define DRM_IOCTL_GET_CAP DRM_IOWR(0x0c, struct drm_get_cap)
+#define DRM_IOCTL_SET_CLIENT_CAP DRM_IOW( 0x0d, struct
drm_set_client_cap)
#define DRM_IOCTL_SET_UNIQUE DRM_IOW( 0x10, struct drm_unique)
#define DRM_IOCTL_AUTH_MAGIC DRM_IOW( 0x11, struct drm_auth)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/22] drm: Move the GET_CAP macros next to the corresponding ioctl structure
It's a tiny bit more logical to find the different capabilities you can
use with the GET_CAP ioctl next to the structure rather than putting
them at the end of the file.
v2: Tab align the litterals (David Herrmann)
v3: Make it clearer that DRM_PRIME_CAP_EXPORT/IMPORT are flags of
DRM_CAP_PRIME.
v4: Rebase on top of latest bits (DRM_CAP_ASYNC_PAGE_FLIP was
introduced)
Reviewed-by: David Herrmann (for v2)
Signed-off-by: Damien Lespiau
---
include/uapi/drm/drm.h | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index ece8678..1e09e8f 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -611,6 +611,16 @@ struct drm_gem_open {
__u64 size;
};
+#define DRM_CAP_DUMB_BUFFER0x1
+#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
+#define DRM_CAP_PRIME 0x5
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
+#define DRM_CAP_TIMESTAMP_MONOTONIC0x6
+#define DRM_CAP_ASYNC_PAGE_FLIP0x7
+
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
__u64 capability;
@@ -774,17 +784,6 @@ struct drm_event_vblank {
__u32 reserved;
};
-#define DRM_CAP_DUMB_BUFFER 0x1
-#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
-#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
-#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
-#define DRM_CAP_PRIME 0x5
-#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
-#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
-
-#define DRM_PRIME_CAP_IMPORT 0x1
-#define DRM_PRIME_CAP_EXPORT 0x2
-
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
HDMI stereo support v6
v5 was: http://lists.freedesktop.org/archives/dri-devel/2013-September/045576.html Changes from v5: - Added a size check on frame packing fbs - Addressed the various reviews - All the patches now have r-b tags -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #4 from Ilya Tumaykin --- (In reply to Alex Deucher from comment #3) > Do you only get the lockups with dpm enabled? If so, try disabling certain > dpm features and see if any of them help. See if you can narrow down which > if any of them help. E.g., So far, yes, it happens only with dpm enabled. I'll try to switch certain features off and report if this helps somehow. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69805] flightgear crashes on r600 (rs880) with llvm backend
https://bugs.freedesktop.org/show_bug.cgi?id=69805 Alex Deucher changed: What|Removed |Added Summary|flightgear crashes on r600 |flightgear crashes on r600 |(rs880) |(rs880) with llvm backend -- 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 3/3] Fix compile error in drivers/gpu/drm/msm/msm_drv.c with IOMMU disabled
The function msm_iommu_get_ctx() is needed buy the MSM-GPU
driver with and wiithout IOMMU compiled in. Make the
function available when no IOMMU driver is there.
Signed-off-by: Joerg Roedel
---
drivers/iommu/msm_iommu.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/msm_iommu.h b/drivers/iommu/msm_iommu.h
index 5c7c955..da53558 100644
--- a/drivers/iommu/msm_iommu.h
+++ b/drivers/iommu/msm_iommu.h
@@ -108,7 +108,14 @@ struct msm_iommu_ctx_drvdata {
* Useful for testing and drivers that do not yet fully have IOMMU stuff in
* their platform devices.
*/
+#ifdef CONFIG_MSM_IOMMU
struct device *msm_iommu_get_ctx(const char *ctx_name);
+#else
+static inline struct device *msm_iommu_get_ctx(const char *ctx_name)
+{
+ return NULL;
+}
+#endif
/*
* Interrupt handler for the IOMMU context fault interrupt. Hooking the
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] Fix compile error in drivers/gpu/drm/msm/msm_drv.c
The include file has been moved but this file was not
updated, so compile breaks.
Signed-off-by: Joerg Roedel
---
drivers/gpu/drm/msm/Makefile |3 ---
drivers/gpu/drm/msm/msm_drv.c |5 -
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e179148..fc7ed9e 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,7 +1,4 @@
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm
-ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
- ccflags-y += -Werror
-endif
msm-y := \
adreno/adreno_gpu.o \
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 008d772..08acebb 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -18,7 +18,10 @@
#include "msm_drv.h"
#include "msm_gpu.h"
-#include
+#ifndef I_AM_NOT_TOO_LAZY_TO_FIX_DRIVERS_WHEN_I_MOVE_INCLUDE_FILES
+#warning "Help! I use non-public subsystem headers. Please fix me!"
+#include <../../../iommu/msm_iommu.h>
+#endif
static void msm_fb_output_poll_changed(struct drm_device *dev)
{
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] MSM: Remove iommu include from drivers/gpu/drm/msm/mdp4/mdp4_kms.c
The include file has been removed and the file does not need it anyway, so remove it. Fixes a compile error. Signed-off-by: Joerg Roedel --- drivers/gpu/drm/msm/mdp4/mdp4_kms.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/msm/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/mdp4/mdp4_kms.c index 5db5bba..bc7fd11 100644 --- a/drivers/gpu/drm/msm/mdp4/mdp4_kms.c +++ b/drivers/gpu/drm/msm/mdp4/mdp4_kms.c @@ -19,8 +19,6 @@ #include "msm_drv.h" #include "mdp4_kms.h" -#include - static struct mdp4_platform_config *mdp4_get_config(struct platform_device *dev); static int mdp4_hw_init(struct msm_kms *kms) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
>
> When looking into this bug I noticed that nouveau_bo_vma_add needs to have a
> check for nvbo->page_shift == vma->vm->vmm->spg_shift,
> and only if the check is true it should map the page in TTM_PL_TT. Patch
> below.
> Should probably also be cc'd to stable.
>
How about this patch? Is it ready to go in?
Thanks,
-- Pasi
> ~Maarten
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 89b992e..355a1b7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
> nouveau_vm *vm,
>
> if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
> nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
> - else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
> + else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
> + nvbo->page_shift == vma->vm->vmm->spg_shift) {
> if (node->sg)
> nouveau_vm_map_sg_table(vma, 0, size, node);
> else
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Hello,
On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
> Op 04-09-13 05:41, Ben Skeggs schreef:
> > On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> > wrote:
> >> Op 22-08-13 02:10, Ilia Mirkin schreef:
> >>> The code expects non-VRAM mem nodes to have a pages list. If that's not
> >>> set, it will do a null deref down the line. Warn on that condition and
> >>> return an error.
> >>>
> >>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
> >>>
> >>> Reported-by: Pasi Kärkkäinen
> >>> Tested-by: Pasi Kärkkäinen
> >>> Signed-off-by: Ilia Mirkin
> >>> Cc: # 3.8+
> >>> ---
> >>>
> >>> I don't exactly understand what's going on, but this is just a
> >>> straightforward way to avoid a null deref that you see happens in the
> >>> bug. I haven't figured out the root cause of this, but it's getting
> >>> well into the "I have no idea how TTM works" space. However this seems
> >>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
> >>> node->pages as a list down, which will be dereferenced by
> >>> nvc0_vm_map_sg. Perhaps the other arguments should make that
> >>> dereferencing not happen, but it definitely was happening here, as you
> >>> can see in the bug.
> >>>
> >>> Ben/Maarten, I'll let you judge whether this check is appropriate,
> >>> since like I hope I was able to convey above, I'm just not really sure :)
> >> Not it really isn't appropriate..
> >>
> >> You'd have to call call nouveau_vm_map_sg_table instead, the only place
> >> that doesn't handle that correctly
> >> is where it's not expected to be called.
> >>
> >> Here, have a completely untested patch to fix things...
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> >> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device
> >> *dev,
> >> {
> >> struct nouveau_framebuffer *nouveau_fb;
> >> struct drm_gem_object *gem;
> >> + struct nouveau_bo *nvbo;
> >> int ret = -ENOMEM;
> >>
> >> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> >> if (!gem)
> >> return ERR_PTR(-ENOENT);
> >>
> >> + nvbo = nouveau_gem_object(gem);
> >> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
> >> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram
> >> with"
> >> + " valid_domains=%08x\n", nvbo->valid_domains);
> >> + ret = -EINVAL;
> >> + goto err_unref;
> >> + }
> >> +
> > Definitely the right idea, we can't handle this case right now.
> > However, we may someday want/need to be able to scan out of system
> > memory, so this is the wrong place.
> >
> > I suspect the correct thing to do (which'll also handle the
> > "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> > a DMA-BUF backed object into VRAM.
> >
> > Sound OK?
> >
> If it has a WARN_ON or something that would be ok, I didn't find any other
> places that attempt to move buffers to VRAM though, so it's probably harmless.
>
Ben/Maarten: Are you guys planning to take a look at this and submit another
patch, or.. ?
I tested the two earlier patches from this thread, and they both fixed the
problem (hard kernel crash).
I'm hoping this bug could be finally solved in the kernel..
Thanks,
-- Pasi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69805] flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805
--- Comment #6 from Marc Dietrich ---
you are right, I didn't compiled llvm with assertions. Here's an updated bt
KMA20 audio panel initialized
KI266 dme indicator #0 initialized
Missing separate debuginfo for /usr/lib64/libXcursor.so.1
Try: zypper install -C
"debuginfo(build-id)=36dc7be208365a4e9d2c4e6e67bf20c04907fe97"
[New Thread 0x7fffc5306700 (LWP 2810)]
[New Thread 0x7fffc4b05700 (LWP 2811)]
[Thread 0x7fffe4a19700 (LWP 2804) exited]
Electrical system initialized
fgfs: R600ControlFlowFinalizer.cpp:259:
{anonymous}::R600ControlFlowFinalizer::ClauseFile
{anonymous}::R600ControlFlowFinalizer::MakeALUClause(llvm::MachineBasicBlock&,
llvm::MachineBasicBlock::iterator&) const: Assertion `ClauseContent.size() <
128 && "ALU clause is too big"' failed.
Program received signal SIGABRT, Aborted.
0x73c8d3d5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x73c8d3d5 in raise () from /lib64/libc.so.6
#1 0x73c8e858 in abort () from /lib64/libc.so.6
#2 0x73c862e2 in __assert_fail_base () from /lib64/libc.so.6
#3 0x73c86392 in __assert_fail () from /lib64/libc.so.6
#4 0x7fffe81d4ca7 in (anonymous
namespace)::R600ControlFlowFinalizer::MakeALUClause (this=0xe192e30, MBB=...,
I=...)
at R600ControlFlowFinalizer.cpp:259
#5 0x7fffe81d5808 in (anonymous
namespace)::R600ControlFlowFinalizer::runOnMachineFunction (this=0xe192e30,
MF=...)
at R600ControlFlowFinalizer.cpp:375
#6 0x7fffe8733d1d in llvm::MachineFunctionPass::runOnFunction
(this=0xe192e30, F=...) at MachineFunctionPass.cpp:33
#7 0x7fffe83d17bd in llvm::FPPassManager::runOnFunction (this=0xe273470,
F=...) at PassManager.cpp:1530
#8 0x7fffe83d19ae in llvm::FPPassManager::runOnModule (this=0xe273470,
M=...) at PassManager.cpp:1550
#9 0x7fffe83d1d0b in llvm::MPPassManager::runOnModule (this=0xe1d6c30,
M=...) at PassManager.cpp:1608
#10 0x7fffe83d230d in llvm::PassManagerImpl::run (this=0xdff41f0, M=...) at
PassManager.cpp:1703
#11 0x7fffe83d251f in llvm::PassManager::run (this=0x7fff20a0, M=...)
at PassManager.cpp:1738
#12 0x7fffe891abe9 in LLVMTargetMachineEmit (T=0xe20c0b0, M=0xe1880e0,
OS=..., codegen=LLVMObjectFile, ErrorMessage=0x7fff2278)
at TargetMachineC.cpp:194
#13 0x7fffe891adda in LLVMTargetMachineEmitToMemoryBuffer (T=0xe20c0b0,
M=0xe1880e0, codegen=LLVMObjectFile,
ErrorMessage=0x7fff2278, OutMemBuf=0x7fff2270) at
TargetMachineC.cpp:220
#14 0x7fffea601f32 in radeon_llvm_compile (M=0xe1880e0,
binary=0x7fff2340, gpu_family=0x7fffea72e5e9 "rs880", dump=0)
at radeon_llvm_emit.c:124
#15 0x7fffea5fd5a0 in r600_llvm_compile (mod=0xe1880e0, family=CHIP_RS880,
bc=0xe226e98, use_kill=0x7fffacdf "", dump=0)
at r600_llvm.c:617
#16 0x7fffea565d08 in r600_shader_from_tgsi (rscreen=0x13263c0,
pipeshader=0xe226e80, key=...) at r600_shader.c:1143
#17 0x7fffea5632ac in r600_pipe_shader_create (ctx=0x139cb50,
shader=0xe226e80, key=...) at r600_shader.c:156
#18 0x7fffea58d67a in r600_shader_select (ctx=0x139cb50, sel=0xe2228f0,
dirty=0x0) at r600_state_common.c:750
#19 0x7fffea58d879 in r600_create_shader_state (ctx=0x139cb50,
state=0xe1c93a0, pipe_shader_type=1) at r600_state_common.c:797
#20 0x7fffea58d8b7 in r600_create_ps_state (ctx=0x139cb50, state=0xe1c93a0)
at r600_state_common.c:807
#21 0x7fffea2e7a0c in st_translate_fragment_program (st=0x13daa90,
stfp=0xe22cc10, key=0x7fffc280)
at ../../src/mesa/state_tracker/st_program.c:768
#22 0x7fffea2e7b22 in st_get_fp_variant (st=0x13daa90, stfp=0xe22cc10,
key=0x7fffc280)
at ../../src/mesa/state_tracker/st_program.c:805
#23 0x7fffea2ab513 in update_fp (st=0x13daa90) at
../../src/mesa/state_tracker/st_atom_shader.c:92
#24 0x7fffea2a5fba in st_validate_state (st=0x13daa90) at
../../src/mesa/state_tracker/st_atom.c:201
#25 0x7fffea2c4bcb in st_draw_vbo (ctx=0x13e9390, prims=0xd6cd598,
nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=23, tfb_vertcount=0x0) at
../../src/mesa/state_tracker/st_draw.c:210
#26 0x7fffea2a5611 in vbo_save_playback_vertex_list (ctx=0x13e9390,
data=0xb5262f8) at ../../src/mesa/vbo/vbo_save_draw.c:309
#27 0x7fffea14c6db in ext_opcode_execute (ctx=0x13e9390, node=0xb5262f0) at
../../src/mesa/main/dlist.c:598
#28 0x7fffea160239 in execute_list (ctx=0x13e9390, list=74) at
../../src/mesa/main/dlist.c:7334
#29 0x7fffea165c43 in _mesa_CallList (list=74) at
../../src/mesa/main/dlist.c:8734
#30 0x76a44364 in osgUtil::RenderLeaf::render(osg::RenderInfo&,
osgUtil::RenderLeaf*) () from /usr/lib64/libosgUtil.so.80
#31 0x76a3e7e5 in
osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&)
()
from /usr/lib64/libosgUtil.so.80
#32 0x76a3e824 in
osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&)
()
from /usr/lib64/libosgUtil.so.80
#33 0x76a457
[Bug 69805] flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805 --- Comment #5 from Vadim Girlin --- The assert in SB seems to be caused by incorrect alu clause size in the bytecode. LLVM with enabled asserts also fails to compile that shader for me with the following message: llc: R600ControlFlowFinalizer.cpp:259: ClauseFile ::R600Con trolFlowFinalizer::MakeALUClause(llvm::MachineBasicBlock &, MachineBasicBlock::i terator &) const: Assertion `ClauseContent.size() < 128 && "ALU clause is too bi g"' failed. So this looks like a bug in LLVM backend. -- 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 69805] flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805 --- Comment #4 from Marc Dietrich --- does not crash with R600_DEBUG=nosb -- 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 69805] flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805 --- Comment #3 from Marc Dietrich --- Created attachment 86558 --> https://bugs.freedesktop.org/attachment.cgi?id=86558&action=edit output of R600_DEBUG=vs,fs -- 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 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 samit vats changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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
[Bug 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 --- Comment #9 from samit vats --- I think it is a regression issue. The issue is resolved with upgrading mesa to latest 9.3.0-devel(git-59157d1) and with glamor-0.5.0 -- 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 69805] flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805 --- Comment #2 from Vadim Girlin --- Crash occurs in SB's bytecode parser, so possibly it's not related to llvm, on the other hand it may be caused by the bad code produced by llvm backend. Does it work with llvm backend if you disable sb (R600_DEBUG=nosb)? Please also attach the output (with enabled llvm and sb) 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
[PATCH] drm/i915: Fix up usage of SHRINK_STOP
In
commit 81e49f811404f428a9d9a63295a0c267e802fa12
Author: Glauber Costa
Date: Wed Aug 28 10:18:13 2013 +1000
i915: bail out earlier when shrinker cannot acquire mutex
SHRINK_STOP was added to tell the core shrinker code to bail out and
go to the next shrinker since the i915 shrinker couldn't acquire
required locks. But the SHRINK_STOP return code was added to the
->count_objects callback and not the ->scan_objects callback as it
should have been, resulting in tons of dmesg noise like
shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete
nr=-x
Fix discusssed with Dave Chinner.
References: http://www.spinics.net/lists/intel-gfx/msg33597.html
Reported-by: Knut Petersen
Cc: Knut Petersen
Cc: Dave Chinner
Cc: Glauber Costa
Cc: Glauber Costa
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Johannes Weiner
Cc: Michal Hocko
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index df9253d..cdfb9da 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4800,10 +4800,10 @@ i915_gem_inactive_count(struct shrinker *shrinker,
struct shrink_control *sc)
if (!mutex_trylock(&dev->struct_mutex)) {
if (!mutex_is_locked_by(&dev->struct_mutex, current))
- return SHRINK_STOP;
+ return 0;
if (dev_priv->mm.shrinker_no_lock_stealing)
- return SHRINK_STOP;
+ return 0;
unlock = false;
}
@@ -4901,10 +4901,10 @@ i915_gem_inactive_scan(struct shrinker *shrinker,
struct shrink_control *sc)
if (!mutex_trylock(&dev->struct_mutex)) {
if (!mutex_is_locked_by(&dev->struct_mutex, current))
- return 0;
+ return SHRINK_STOP;
if (dev_priv->mm.shrinker_no_lock_stealing)
- return 0;
+ return SHRINK_STOP;
unlock = false;
}
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69805] flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805 --- Comment #1 from Marc Dietrich --- sorry, backtrace with debug info this time: sb/sb_bc_parser.cpp:231:decode_alu_clause: Assertion `gcnt <= cnt' failed. Program received signal SIGTRAP, Trace/breakpoint trap. 0x7fffea45167c in _debug_assert_fail (expr=0x7fffea744065 "gcnt <= cnt", file=0x7fffea744015 "sb/sb_bc_parser.cpp", line=231, function=0x7fffea7457f0 "decode_alu_clause") at util/u_debug.c:278 278 os_abort(); (gdb) bt #0 0x7fffea45167c in _debug_assert_fail (expr=0x7fffea744065 "gcnt <= cnt", file=0x7fffea744015 "sb/sb_bc_parser.cpp", line=231, function=0x7fffea7457f0 "decode_alu_clause") at util/u_debug.c:278 #1 0x7fffea5a8f70 in r600_sb::bc_parser::decode_alu_clause (this=0x7fffadb0, cf=0xd2a03b8) at sb/sb_bc_parser.cpp:231 #2 0x7fffea5a8d34 in r600_sb::bc_parser::decode_cf (this=0x7fffadb0, i=@0x7ffface8: 72, eop=@0x7ffface7: false) at sb/sb_bc_parser.cpp:196 #3 0x7fffea5a87ed in r600_sb::bc_parser::decode_shader (this=0x7fffadb0) at sb/sb_bc_parser.cpp:94 #4 0x7fffea5a873b in r600_sb::bc_parser::decode (this=0x7fffadb0) at sb/sb_bc_parser.cpp:75 #5 0x7fffea5afc18 in r600_sb_bytecode_process (rctx=0x13076f0, bc=0xd0e6f08, pshader=0xd0e6f00, dump_bytecode=0, optimize=1) at sb/sb_core.cpp:114 #6 0x7fffea5633ee in r600_pipe_shader_create (ctx=0x13076f0, shader=0xd0e6ef0, key=...) at r600_shader.c:179 #7 0x7fffea58d67a in r600_shader_select (ctx=0x13076f0, sel=0xd01be70, dirty=0x0) at r600_state_common.c:750 #8 0x7fffea58d879 in r600_create_shader_state (ctx=0x13076f0, state=0xd265820, pipe_shader_type=1) at r600_state_common.c:797 #9 0x7fffea58d8b7 in r600_create_ps_state (ctx=0x13076f0, state=0xd265820) at r600_state_common.c:807 #10 0x7fffea2e7a0c in st_translate_fragment_program (st=0x13d39a0, stfp=0xd272870, key=0x7fffc280) at ../../src/mesa/state_tracker/st_program.c:768 #11 0x7fffea2e7b22 in st_get_fp_variant (st=0x13d39a0, stfp=0xd272870, key=0x7fffc280) at ../../src/mesa/state_tracker/st_program.c:805 #12 0x7fffea2ab513 in update_fp (st=0x13d39a0) at ../../src/mesa/state_tracker/st_atom_shader.c:92 #13 0x7fffea2a5fba in st_validate_state (st=0x13d39a0) at ../../src/mesa/state_tracker/st_atom.c:201 #14 0x7fffea2c4bcb in st_draw_vbo (ctx=0x13e8cd0, prims=0xc6db758, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=203, tfb_vertcount=0x0) at ../../src/mesa/state_tracker/st_draw.c:210 #15 0x7fffea2a5611 in vbo_save_playback_vertex_list (ctx=0x13e8cd0, data=0xc79d918) at ../../src/mesa/vbo/vbo_save_draw.c:309 #16 0x7fffea14c6db in ext_opcode_execute (ctx=0x13e8cd0, node=0xc79d910) at ../../src/mesa/main/dlist.c:598 #17 0x7fffea160239 in execute_list (ctx=0x13e8cd0, list=67) at ../../src/mesa/main/dlist.c:7334 #18 0x7fffea165c43 in _mesa_CallList (list=67) at ../../src/mesa/main/dlist.c:8734 #19 0x76a44364 in osgUtil::RenderLeaf::render(osg::RenderInfo&, osgUtil::RenderLeaf*) () from /usr/lib64/libosgUtil.so.80 #20 0x76a3e7e5 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #21 0x76a3e824 in osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #22 0x76a457c3 in osgUtil::RenderStage::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #23 0x76a48c96 in osgUtil::RenderStage::drawInner(osg::RenderInfo&, osgUtil::RenderLeaf*&, bool&) () from /usr/lib64/libosgUtil.so.80 #24 0x76a488ba in osgUtil::RenderStage::draw(osg::RenderInfo&, osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80 #25 0x76a524a5 in osgUtil::SceneView::draw() () from /usr/lib64/libosgUtil.so.80 #26 0x766743f5 in osgViewer::Renderer::cull_draw() () from /usr/lib64/libosgViewer.so.80 #27 0x760075f9 in osg::GraphicsContext::runOperations() () from /usr/lib64/libosg.so.80 #28 0x766a9964 in osgViewer::ViewerBase::renderingTraversals() () from /usr/lib64/libosgViewer.so.80 #29 0x00b2d7a5 in fgOSMainLoop() () #30 0x0064317a in fgMainInit(int, char**) () #31 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 69805] New: flightgear crashes on r600 (rs880)
https://bugs.freedesktop.org/show_bug.cgi?id=69805
Priority: medium
Bug ID: 69805
Assignee: dri-devel@lists.freedesktop.org
Summary: flightgear crashes on r600 (rs880)
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: marvi...@gmx.de
Hardware: x86-64 (AMD64)
Status: NEW
Version: git
Component: Drivers/Gallium/r600
Product: Mesa
flightgear 2.12 crashes on git mesa. Works with R600_LLVM=0. I initially
thought it is due to missing trig functions, but after applying a workaround
(from some other bug), it still crashes, so this must be something different.
environment init
Missing separate debuginfo for /usr/lib64/osgPlugins-3.0.1/osgdb_freetype.so
Try: zypper install -C
"debuginfo(build-id)=462971b0ab27e0a7e0e887d5a49071eda4dd3258"
Missing separate debuginfo for /usr/lib64/libfreetype.so.6
Try: zypper install -C
"debuginfo(build-id)=0d930f71e40c49e05024dd84de90ec2bbd703a02"
KMA20 audio panel initialized
KI266 dme indicator #0 initialized
Missing separate debuginfo for /usr/lib64/libXcursor.so.1
Try: zypper install -C
"debuginfo(build-id)=36dc7be208365a4e9d2c4e6e67bf20c04907fe97"
[New Thread 0x7fffc673e700 (LWP 4495)]
[New Thread 0x7fffc5f3d700 (LWP 4496)]
[Thread 0x7fffe5eca700 (LWP 4489) exited]
Electrical system initialized
Program received signal SIGSEGV, Segmentation fault.
0x7fffea71f024 in r600_sb::bc_decoder::decode_alu(unsigned int&,
r600_sb::bc_alu&) () from /usr/lib64/dri/r600_dri.so
(gdb) bt
#0 0x7fffea71f024 in r600_sb::bc_decoder::decode_alu(unsigned int&,
r600_sb::bc_alu&) () from /usr/lib64/dri/r600_dri.so
#1 0x7fffea725982 in
r600_sb::bc_parser::decode_alu_group(r600_sb::cf_node*, unsigned int&, unsigned
int&) ()
from /usr/lib64/dri/r600_dri.so
#2 0x7fffea725bbb in
r600_sb::bc_parser::decode_alu_clause(r600_sb::cf_node*) () from
/usr/lib64/dri/r600_dri.so
#3 0x7fffea725d2b in r600_sb::bc_parser::decode_cf(unsigned int&, bool&)
() from /usr/lib64/dri/r600_dri.so
#4 0x7fffea725d94 in r600_sb::bc_parser::decode_shader() () from
/usr/lib64/dri/r600_dri.so
#5 0x7fffea725e8b in r600_sb::bc_parser::decode() () from
/usr/lib64/dri/r600_dri.so
#6 0x7fffea72993f in r600_sb_bytecode_process () from
/usr/lib64/dri/r600_dri.so
#7 0x7fffea7006e2 in ?? () from /usr/lib64/dri/r600_dri.so
#8 0x7fffea7153cd in ?? () from /usr/lib64/dri/r600_dri.so
#9 0x7fffea71555a in ?? () from /usr/lib64/dri/r600_dri.so
#10 0x7fffea456864 in ?? () from /usr/lib64/dri/r600_dri.so
#11 0x7fffea457386 in ?? () from /usr/lib64/dri/r600_dri.so
#12 0x7fffea416ad7 in ?? () from /usr/lib64/dri/r600_dri.so
#13 0x7fffea412e9f in ?? () from /usr/lib64/dri/r600_dri.so
#14 0x7fffea429712 in ?? () from /usr/lib64/dri/r600_dri.so
#15 0x7fffea4125db in ?? () from /usr/lib64/dri/r600_dri.so
#16 0x7fffea2862c2 in ?? () from /usr/lib64/dri/r600_dri.so
#17 0x7fffea2a51f8 in ?? () from /usr/lib64/dri/r600_dri.so
#18 0x76a44364 in osgUtil::RenderLeaf::render(osg::RenderInfo&,
osgUtil::RenderLeaf*) () from /usr/lib64/libosgUtil.so.80
#19 0x76a3e7e5 in
osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&)
()
from /usr/lib64/libosgUtil.so.80
#20 0x76a3e824 in
osgUtil::RenderBin::drawImplementation(osg::RenderInfo&, osgUtil::RenderLeaf*&)
()
from /usr/lib64/libosgUtil.so.80
#21 0x76a457c3 in
osgUtil::RenderStage::drawImplementation(osg::RenderInfo&,
osgUtil::RenderLeaf*&) ()
from /usr/lib64/libosgUtil.so.80
#22 0x76a48c96 in osgUtil::RenderStage::drawInner(osg::RenderInfo&,
osgUtil::RenderLeaf*&, bool&) ()
from /usr/lib64/libosgUtil.so.80
#23 0x76a488ba in osgUtil::RenderStage::draw(osg::RenderInfo&,
osgUtil::RenderLeaf*&) () from /usr/lib64/libosgUtil.so.80
#24 0x76a524a5 in osgUtil::SceneView::draw() () from
/usr/lib64/libosgUtil.so.80
#25 0x766743f5 in osgViewer::Renderer::cull_draw() () from
/usr/lib64/libosgViewer.so.80
#26 0x760075f9 in osg::GraphicsContext::runOperations() () from
/usr/lib64/libosg.so.80
#27 0x766a9964 in osgViewer::ViewerBase::renderingTraversals() () from
/usr/lib64/libosgViewer.so.80
#28 0x00b2d7a5 in fgOSMainLoop() ()
#29 0x0064317a in fgMainInit(int, char**) ()
#30 0x0060a474 in main ()
(gdb)
workaround patch:
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -1165,6 +1165,8 @@ let Predicates = [isR600] in {
def UINT_TO_FLT_r600 : UINT_TO_FLT_Common<0x6d>;
def SIN_r600 : SIN_Common<0x6E>;
def COS_r600 : COS_Common<0x6F>;
+ def : Pat<(fcos f32:$src),(COS_r600 $src)>;
+ def : Pat<(fsin f32:$src),(SIN_r600 $src)>;
def ASHR_r600 : ASHR_Common<0x70>;
def LSHR_r600 : LSHR_Common<0x71>;
def LSHL_r600 : LSHL_Common<0x72>;
--
You are receiving this mail because:
You are the assignee for t
Re: [PATCH v3 0/4] Fix Win8 backlight issue
On Wed, 25 Sep 2013, Aaron Lu wrote: > On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: >> Backlight can't be modified with this patch set - neither with >> function keys nor with the gui. It is a step backward to v3.11-rc1 So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? > Thanks for the test. > > Please check /sys/class/backlight, is there only one link file > intel_backlight? Indeed, are there others? fujitsu-laptop perhaps? If yes, try CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? Embarrassingly there was a bug in i915 fixed just recently where the backlight device wasn't registered for CONFIG_BACKLIGHT_CLASS_DEVICE=m... > If so, please cd inside and try modify the brightness file using echo > with some values in the range of 0 - max_brightness, does the > backlight level change when you echo a new value? I guess it doesn't, > or you wouldn't notice problem. If indeed so, perhaps file a bug at > http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani > and Daniel can help fix your problem. Yup, please check the above, and report back. BR, Jani. > > Thanks, > Aaron > >> >> Video driver: i915 >> FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 >> >> acpi_backlight=video works. >> >> Jörg >> >> >> 2013/9/24 Igor Gnatenko >> >> > On Tue, 2013-09-24 at 17:47 +0800, Aaron Lu wrote: >> > > v3: >> > > 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; >> > > 2 Remove unnecessary function acpi_video_unregister introduced in >> > > patch 2/3 as pointed out by Jani Nikula. >> > > >> > > v2: >> > > v1 has the subject of "Rework ACPI video driver" and is posted here: >> > > http://lkml.org/lkml/2013/9/9/74 >> > > Since the objective is really to fix Win8 backlight issues, I changed >> > > the subject in this version, sorry about that. >> > > >> > > This patchset has three patches, the first introduced a new API named >> > > backlight_device_registered in backlight layer that can be used for >> > > backlight interface provider module to check if a specific type backlight >> > > interface has been registered, see changelog for patch 1/3 for details. >> > > Then patch 2/3 does the cleanup to sepeate the backlight control and >> > > event delivery functionality in the ACPI video module and patch 3/3 >> > > solves some Win8 backlight control problems by avoiding register ACPI >> > > video's backlight interface if: >> > > 1 Kernel cmdline option acpi_backlight=video is not given; >> > > 2 This is a Win8 system; >> > > 3 Native backlight control interface exists. >> > > >> > > Technically, patch 2/3 is not required to fix the issue here. So if you >> > > think it is not necessary, I can remove it from the series. >> > > >> > > Aaron Lu (4): >> > > backlight: introduce backlight_device_registered >> > > ACPI / video: seperate backlight control and event interface >> > > ACPI / video: Do not register backlight if win8 and native interface >> > > exists >> > > thinkpad-acpi: fix handle locate for video and query of _BCL >> > > >> > > drivers/acpi/internal.h | 5 +- >> > > drivers/acpi/video.c | 442 >> > --- >> > > drivers/acpi/video_detect.c | 14 +- >> > > drivers/platform/x86/thinkpad_acpi.c | 31 ++- >> > > drivers/video/backlight/backlight.c | 31 +++ >> > > include/acpi/video.h | 2 + >> > > include/linux/backlight.h| 4 + >> > > 7 files changed, 324 insertions(+), 205 deletions(-) >> > > >> > >> > Excellent! I've tested this patch-set on ThinkPad X230 and backlight >> > issue is exhausted. >> > >> > Thanks. >> > >> > -- >> > Igor Gnatenko >> > Fedora release 20 (Heisenbug) >> > Linux 3.11.1-300.fc20.x86_64 >> > >> > -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69790] [HSW ULT] testdisplay : The output of 720x576 mode is dislocated
https://bugs.freedesktop.org/show_bug.cgi?id=69790 --- Comment #2 from Ville Syrjala --- I managed to reproduce this on my HSW. But it seems that it's somehow random as it doesn't happen every time. It's rather hard to reproduce actually when you just retry the same mode w/ 'testdisplay -o'. There's no difference in dmesg between a good and bad modesets using the same mode. As it stands, I don't have any good ideas as to what might be happening. -- 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 69729] HDMI audio stopped working on HD 3470 (RV620/M82)
https://bugs.freedesktop.org/show_bug.cgi?id=69729 --- Comment #18 from Paul Bodenbenner --- Conclusion: Beginning with rc5 the problem occurs. Hope that helps a bit. -- 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: Fwd: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]
On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote: > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin wrote: > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote: > >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote: > >> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ] > >> > > >> > Hi, > >> > > >> > saw your posting in [1]... can you try the patches below? > >> > Not sure if they apply. > >> > Did you try v3.11-rc6(+)... or drm-intel-nightly? > >> > > >> > Regards, > >> > - Sedat - > >> > > >> > [1] > >> > http://lists.freedesktop.org/archives/intel-gfx/2013-August/032154.html > >> > >> Same thing observed with v3.11-rc7. > > > > I still see this with 3.11. > > Following this message, my VGA monitor goes blank and > > shows an error suggesting a wrong resolution or frequency are set. > > Anyone? > > Daniel, Jesse? > > still ongoing I think. Yeah, I've dismissed it since the original issue in this thread is resolved. But it's something else. Note to bug reporters: Please don't me-too, but start a new thread/report - almost every gfx bug is different, even if it superficially looks the same. Michael, can you please boot with drm.debug=0xe, reproduce the problem and then attach the complete dmesg? Please make sure dmesg contains everything since boot-up, if not please increase the dmesg buffer size with log_buf_len=4M. Also please test the latest drm-intel-fixes release to check that we haven't just forgotten to send the patch to stable (there's at least one flags mismatch fix already in-flight to 3.11 stable kernels). Thanks, 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: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote: > On 23.09.13 10:38, Ville Syrjälä wrote: > > On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote: > >> On 09/17/2013 10:55 PM, Daniel Vetter wrote: > >>> On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley > >>> wrote: > On 09/11/2013 03:31 PM, Peter Hurley wrote: > > > > [+cc dri-devel] > > > > On 09/11/2013 11:38 AM, Steven Rostedt wrote: > >> > >> On Wed, 11 Sep 2013 11:16:43 -0400 > >> Peter Hurley wrote: > >> > The funny part is, there's a comment there that shows that this was > done even for "PREEMPT_RT". Unfortunately, the call to > "get_scanout_position()" can call functions that use the rt-mutex > "sleeping spin locks" and it breaks there. > > I guess we need to ask the authors of the mainline patch exactly why > that preempt_disable() is needed? > >>> > >>> > >>> The drm core associates a timestamp with each vertical blank frame #. > >>> Drm drivers can optionally support a 'high resolution' hw timestamp. > >>> The vblank frame #/timestamp tuple is user-space visible. > >>> > >>> The i915 drm driver supports a hw timestamp via this drm helper > >>> function > >>> which computes the timestamp from the crtc scan position (based on the > >>> pixel clock). > >>> > >>> For mainline, the preempt_disable/_enable() isn't actually necessary > >>> because every call tree that leads here already has preemption > >>> disabled. > >>> > >>> For -RT, the maybe i915 register spinlock (uncore.lock) should be raw? > >>> > >> > >> No, it should not. Note, any other lock that can be held when it is > >> held would also need to be raw. > > > > > > By that, you mean "any other lock" that might be claimed "would also > > need > > to be raw"? Hopefully not "any other lock" already held? > > > >> And by taking a quick audit of the code, I see this: > >> > >> spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); > >> > >> /* Reset the chip */ > >> > >> /* GEN6_GDRST is not in the gt power well, no need to check > >>* for fifo space for the write or forcewake the chip for > >>* the read > >>*/ > >> __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL); > >> > >> /* Spin waiting for the device to ack the reset request */ > >> ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & > >> GEN6_GRDOM_FULL) == 0, 500); > >> > >> That spin is unacceptable in RT with preemption and interrupts > >> disabled. > > > > > > Yep. That would be bad. > > > > AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included > > in the force-wake set, so raw reads of the registers would > > probably be acceptable (thus obviating the need for claiming the > > uncore.lock). > > > > Except that _ALL_ register access is disabled with the uncore.lock > > during a gpu reset. Not sure if that's meant to include crtc registers > > or not, or what other synchronization/serialization issues are being > > handled/hidden by forcing all register accesses to wait during a gpu > > reset. > > > > Hopefully an i915 expert can weigh in here? > > > > Daniel, > > Can you shed some light on whether the i915+ crtc registers (specifically > those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter()) > read as part of the vblank counter/timestamp handling need to > be prevented during gpu reset? > >>> > >>> The depency here in the locking is a recent addition: > >>> > >>> commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a > >>> Author: Chris Wilson > >>> Date: Fri Jul 19 20:36:51 2013 +0100 > >>> > >>> drm/i915: Serialize almost all register access > >>> > >>> It's a (slightly) oversized hammer to work around a hardware issue - > >>> we could break it down to register blocks, which can be accessed > >>> concurrently, but that tends to be more fragile. But the chip really > >>> dies if you access (even just reads) the same block concurrently :( > >>> > >>> We could try break the spinlock protected section a bit in the reset > >>> handler - register access on a hung gpu tends to be ill-defined > >>> anyway. > >>> > The implied wait with preemption and interrupts disabled is causing grief > in -RT, but also a 4ms wait inside an irq handler seems like a bad idea. > >>> > >>> Oops, the magic code in wait_for which is just there to make the imo > >>> totally misguided kgdb support work papered over the aweful long wait > >>> in atomic context ever since we've added this in > >>> > >>> commit b6e45f866465f42b53d803b0c574da0fc508a0e9 > >>> Author: Keith Packard > >>> Date: Fri Jan 6 11:34:04 2012 -0800 > >>> > >>>
Re: [Intel-gfx] BUG: sleeping function called from invalid context on 3.10.10-rt7
On 23.09.13 10:38, Ville Syrjälä wrote: On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote: On 09/17/2013 10:55 PM, Daniel Vetter wrote: On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote: On 09/11/2013 03:31 PM, Peter Hurley wrote: [+cc dri-devel] On 09/11/2013 11:38 AM, Steven Rostedt wrote: On Wed, 11 Sep 2013 11:16:43 -0400 Peter Hurley wrote: The funny part is, there's a comment there that shows that this was done even for "PREEMPT_RT". Unfortunately, the call to "get_scanout_position()" can call functions that use the rt-mutex "sleeping spin locks" and it breaks there. I guess we need to ask the authors of the mainline patch exactly why that preempt_disable() is needed? The drm core associates a timestamp with each vertical blank frame #. Drm drivers can optionally support a 'high resolution' hw timestamp. The vblank frame #/timestamp tuple is user-space visible. The i915 drm driver supports a hw timestamp via this drm helper function which computes the timestamp from the crtc scan position (based on the pixel clock). For mainline, the preempt_disable/_enable() isn't actually necessary because every call tree that leads here already has preemption disabled. For -RT, the maybe i915 register spinlock (uncore.lock) should be raw? No, it should not. Note, any other lock that can be held when it is held would also need to be raw. By that, you mean "any other lock" that might be claimed "would also need to be raw"? Hopefully not "any other lock" already held? And by taking a quick audit of the code, I see this: spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); /* Reset the chip */ /* GEN6_GDRST is not in the gt power well, no need to check * for fifo space for the write or forcewake the chip for * the read */ __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL); /* Spin waiting for the device to ack the reset request */ ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & GEN6_GRDOM_FULL) == 0, 500); That spin is unacceptable in RT with preemption and interrupts disabled. Yep. That would be bad. AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included in the force-wake set, so raw reads of the registers would probably be acceptable (thus obviating the need for claiming the uncore.lock). Except that _ALL_ register access is disabled with the uncore.lock during a gpu reset. Not sure if that's meant to include crtc registers or not, or what other synchronization/serialization issues are being handled/hidden by forcing all register accesses to wait during a gpu reset. Hopefully an i915 expert can weigh in here? Daniel, Can you shed some light on whether the i915+ crtc registers (specifically those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter()) read as part of the vblank counter/timestamp handling need to be prevented during gpu reset? The depency here in the locking is a recent addition: commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Author: Chris Wilson Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access It's a (slightly) oversized hammer to work around a hardware issue - we could break it down to register blocks, which can be accessed concurrently, but that tends to be more fragile. But the chip really dies if you access (even just reads) the same block concurrently :( We could try break the spinlock protected section a bit in the reset handler - register access on a hung gpu tends to be ill-defined anyway. The implied wait with preemption and interrupts disabled is causing grief in -RT, but also a 4ms wait inside an irq handler seems like a bad idea. Oops, the magic code in wait_for which is just there to make the imo totally misguided kgdb support work papered over the aweful long wait in atomic context ever since we've added this in commit b6e45f866465f42b53d803b0c574da0fc508a0e9 Author: Keith Packard Date: Fri Jan 6 11:34:04 2012 -0800 drm/i915: Move reset forcewake processing to gen6_do_reset Reverting this change should be enough (code moved obviously a bit). Cheers, Daniel Regards, Peter Hurley What's the real issue here? That the vblank timestamp needs to be an accurate measurement of a realtime event. Sleeping/servicing interrupts while reading the registers necessary to compute the timestamp would be bad too. (edit: which hopefully Mario Kleiner clarified in his reply) My point earlier was three-fold: 1. Don't need the preempt_disable() for mainline: all callers are already holding interrupt-disabling spinlocks. 2. -RT still needs to prevent scheduling there. 3. the problem is i915-specific. [update: the radeon driver should also BUG like the i915 driver but probably should have mmio_idx_lock spinlock as raw] Ok, so register access must be serialized, at least within a register block, no way around it. Thanks for explaining this. That makes me a bit de
[RFC PATCH 4/4] ARM: dts: exynos4210-trats: add panel and dsi nodes
The patch adds mipi-dsi-exynos bus master node
and s6e8aa0 panel subnode to trats device.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
Conflicts:
arch/arm/boot/dts/exynos4210-trats.dts
---
arch/arm/boot/dts/exynos4210-trats.dts | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 94eebff..6f1a034 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -301,4 +301,58 @@
clock-frequency = <2400>;
};
};
+
+ dsi_0: dsi@11C8 {
+ samsung,pll-stable-time = <500>;
+ samsung,stop-holding-count = <0x7ff>;
+ samsung,bta-timeout = <0xff>;
+ samsung,rx-timeout = <0x>;
+ samsung,pll-clk-freq = <2400>;
+ samsung,cmd-allow = <0xf>;
+ vdd11-supply = <&vusb_reg>;
+ vdd18-supply = <&vmipi_reg>;
+ status = "okay";
+
+ fimd0_lcd: panel {
+ compatible = "samsung,s6e8aa0";
+ reset-gpio = <&gpy4 5 0>;
+ power-on-delay= <50>;
+ reset-delay = <100>;
+ init-delay = <100>;
+ vdd3-supply = <&vcclcd_reg>;
+ vci-supply = <&vlcd_reg>;
+ video-source = <&dsi_0>;
+ flip-horizontal;
+ flip-vertical;
+ samsung,panel-width-mm = <58>;
+ samsung,panel-height-mm = <103>;
+
+ display-timings {
+ native-mode = <&timing0>;
+
+ timing0: timing-0 {
+ clock-frequency = <0>;
+ hactive = <720>;
+ vactive = <1280>;
+ hfront-porch = <5>;
+ hback-porch = <5>;
+ hsync-len = <5>;
+ vfront-porch = <13>;
+ vback-porch = <1>;
+ vsync-len = <2>;
+ };
+ };
+ };
+ };
+
+ fimd@11c0 {
+ samsung,fimd-display = <&fimd0_lcd>;
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-vclk;
+ samsung,fimd-frame-rate = <60>;
+ samsung,default-window = <3>;
+ samsung,fimd-win-bpp = <32>;
+ status = "okay";
+ };
+
};
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 3/4] panel-s6e8aa0: add driver
The patch adds mipi-dsi-bus slave driver for s6e8aa0 familiy panels. Signed-off-by: Donghwa Lee Signed-off-by: Inki Dae Signed-off-by: Joongmock Shin Signed-off-by: Eunchul Kim Signed-off-by: Tomasz Figa Signed-off-by: Andrzej Hajda Signed-off-by: Kyungmin Park --- drivers/video/display/Kconfig |6 + drivers/video/display/Makefile|1 + drivers/video/display/panel-s6e8aa0.c | 1286 + include/video/panel-s6e8aa0.h | 42 ++ 4 files changed, 1335 insertions(+) create mode 100644 drivers/video/display/panel-s6e8aa0.c create mode 100644 include/video/panel-s6e8aa0.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 0a1e90b..9a9b7e9 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -67,4 +67,10 @@ config DISPLAY_VGA_DAC If you are in doubt, say N. To compile this driver as a module, choose M here: the module will be called vga-dac. +config DISPLAY_PANEL_S6E8AA0 + tristate "S6E8AA0 DSI video mode panel" + select BACKLIGHT_CLASS_DEVICE + select DISPLAY_MIPI_DSI + select VIDEOMODE_HELPERS + endif # DISPLAY_CORE diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 2fd84f5..45225e1 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o obj-$(CONFIG_DISPLAY_VGA_DAC) += vga-dac.o +obj-$(CONFIG_DISPLAY_PANEL_S6E8AA0)+= panel-s6e8aa0.o diff --git a/drivers/video/display/panel-s6e8aa0.c b/drivers/video/display/panel-s6e8aa0.c new file mode 100644 index 000..99246da --- /dev/null +++ b/drivers/video/display/panel-s6e8aa0.c @@ -0,0 +1,1286 @@ +/* linux/drivers/video/s6e8aa0.c + * + * MIPI-DSI based s6e8aa0 AMOLED lcd 5.3 inch panel driver. + * + * Inki Dae, + * Donghwa Lee, + * Joongmock Shin + * Eunchul Kim + * Tomasz Figa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define LDI_MTP_LENGTH 24 +#define GAMMA_LEVEL_NUM25 +#define GAMMA_TABLE_LEN26 +#define S6E8AA0_PANEL_COND_LEN 39 + +/* 1 */ +#define PANELCTL_SS_MASK (1 << 5) +#define PANELCTL_SS_1_800 (0 << 5) +#define PANELCTL_SS_800_1 (1 << 5) +#define PANELCTL_GTCON_MASK(7 << 2) +#define PANELCTL_GTCON_110 (6 << 2) +#define PANELCTL_GTCON_111 (7 << 2) +/* LTPS */ +/* 30 */ +#define PANELCTL_CLK1_CON_MASK (7 << 3) +#define PANELCTL_CLK1_000 (0 << 3) +#define PANELCTL_CLK1_001 (1 << 3) +#define PANELCTL_CLK2_CON_MASK (7 << 0) +#define PANELCTL_CLK2_000 (0 << 0) +#define PANELCTL_CLK2_001 (1 << 0) +/* 31 */ +#define PANELCTL_INT1_CON_MASK (7 << 3) +#define PANELCTL_INT1_000 (0 << 3) +#define PANELCTL_INT1_001 (1 << 3) +#define PANELCTL_INT2_CON_MASK (7 << 0) +#define PANELCTL_INT2_000 (0 << 0) +#define PANELCTL_INT2_001 (1 << 0) +/* 32 */ +#define PANELCTL_BICTL_CON_MASK(7 << 3) +#define PANELCTL_BICTL_000 (0 << 3) +#define PANELCTL_BICTL_001 (1 << 3) +#define PANELCTL_BICTLB_CON_MASK (7 << 0) +#define PANELCTL_BICTLB_000(0 << 0) +#define PANELCTL_BICTLB_001(1 << 0) +/* 36 */ +#define PANELCTL_EM_CLK1_CON_MASK (7 << 3) +#define PANELCTL_EM_CLK1_110 (6 << 3) +#define PANELCTL_EM_CLK1_111 (7 << 3) +#define PANELCTL_EM_CLK1B_CON_MASK (7 << 0) +#define PANELCTL_EM_CLK1B_110 (6 << 0) +#define PANELCTL_EM_CLK1B_111 (7 << 0) +/* 37 */ +#define PANELCTL_EM_CLK2_CON_MASK (7 << 3) +#define PANELCTL_EM_CLK2_110 (6 << 3) +#define PANELCTL_EM_CLK2_111 (7 << 3) +#define PANELCTL_EM_CLK2B_CON_MASK (7 << 0) +#define PANELCTL_EM_CLK2B_110 (6 << 0) +#define PANELCTL_EM_CLK2B_111 (7 << 0) +/* 38 */ +#define PANELCTL_EM_INT1_CON_MASK (7 << 3) +#define PANELCTL_EM_INT1_000 (0 << 3) +#define PANELCTL_EM_INT1_001 (1 << 3) +#define PANELCTL_EM_INT2_CON_MASK (7 << 0) +#define PANELCTL_EM_INT2_000 (0 << 0) +#define PANELCTL_EM_INT2_001 (1 << 0) + +#define AID_DISABLE(0x4) +#define AID_1 (0x5) +#define AID_2
[RFC PATCH 2/4] mipi-dsi-exynos: add driver
This patch adds mipi-dsi-bus master driver for Exynos chipset family. Signed-off-by: Tomasz Figa Signed-off-by: Donghwa Lee Signed-off-by: Sylwester Nawrocki Signed-off-by: Andrzej Hajda Signed-off-by: Kyungmin Park --- drivers/video/display/Kconfig |4 + drivers/video/display/Makefile |1 + drivers/video/display/mipi-dsi-exynos.c | 1310 +++ include/video/mipi-dsi-exynos.h | 41 + 4 files changed, 1356 insertions(+) create mode 100644 drivers/video/display/mipi-dsi-exynos.c create mode 100644 include/video/mipi-dsi-exynos.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index 619b05d..0a1e90b 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -24,6 +24,10 @@ config DISPLAY_MIPI_DSI tristate default n +config DISPLAY_MIPI_DSI_EXYNOS + select DISPLAY_MIPI_DSI + tristate "Samsung SoC MIPI DSI Master" + config DISPLAY_PANEL_DPI tristate "DPI (Parallel) Display Panels" ---help--- diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index b323fd4..2fd84f5 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_DISPLAY_CORE) += display.o obj-$(CONFIG_DISPLAY_CONNECTOR_VGA)+= con-vga.o obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o +obj-$(CONFIG_DISPLAY_MIPI_DSI_EXYNOS) += mipi-dsi-exynos.o obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o diff --git a/drivers/video/display/mipi-dsi-exynos.c b/drivers/video/display/mipi-dsi-exynos.c new file mode 100644 index 000..e094744 --- /dev/null +++ b/drivers/video/display/mipi-dsi-exynos.c @@ -0,0 +1,1310 @@ +/* + * Samsung SoC MIPI DSI Master driver. + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd + * + * Contacts: Tomasz Figa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define DSIM_STATUS_REG0x0 /* Status register */ +#define DSIM_SWRST_REG 0x4 /* Software reset register */ +#define DSIM_CLKCTRL_REG 0x8 /* Clock control register */ +#define DSIM_TIMEOUT_REG 0xc /* Time out register */ +#define DSIM_CONFIG_REG0x10/* Configuration register */ +#define DSIM_ESCMODE_REG 0x14/* Escape mode register */ + +/* Main display image resolution register */ +#define DSIM_MDRESOL_REG 0x18 +#define DSIM_MVPORCH_REG 0x1c/* Main display Vporch register */ +#define DSIM_MHPORCH_REG 0x20/* Main display Hporch register */ +#define DSIM_MSYNC_REG 0x24/* Main display sync area register */ + +/* Sub display image resolution register */ +#define DSIM_SDRESOL_REG 0x28 +#define DSIM_INTSRC_REG0x2c/* Interrupt source register */ +#define DSIM_INTMSK_REG0x30/* Interrupt mask register */ +#define DSIM_PKTHDR_REG0x34/* Packet Header FIFO register */ +#define DSIM_PAYLOAD_REG 0x38/* Payload FIFO register */ +#define DSIM_RXFIFO_REG0x3c/* Read FIFO register */ +#define DSIM_FIFOTHLD_REG 0x40/* FIFO threshold level register */ +#define DSIM_FIFOCTRL_REG 0x44/* FIFO status and control register */ + +/* FIFO memory AC characteristic register */ +#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */ +#define DSIM_PLLTMR_REG0x50/* PLL timer register */ +#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */ +#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */ + +/* DSIM_STATUS */ +#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0) +#define DSIM_STOP_STATE_CLK(1 << 8) +#define DSIM_TX_READY_HS_CLK (1 << 10) +#define DSIM_PLL_STABLE(1 << 31) + +/* DSIM_SWRST */ +#define DSIM_FUNCRST (1 << 16) +#define DSIM_SWRST (1 << 0) + +/* DSIM_TIMEOUT */ +#define DSIM_LPDR_TOUT(x) ((x) << 0) +#define DSIM_BTA_TOUT(x) ((x) << 16) + +/* DSIM_CLKCTRL */ +#define DSIM_ESC_PRESCALER(x) (((x) & 0x) << 0) +#define DSIM_ESC_PRESCALER_MASK(0x << 0) +#define DSIM_LANE_ESC_CLK_EN_CLK (1 << 19) +#define DSIM
[RFC PATCH 1/4] mipi-dsi-bus: add MIPI DSI bus support
MIPI DSI is a high-speed serial interface to transmit
data from/to host to display module.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/video/display/Kconfig| 4 +
drivers/video/display/Makefile | 1 +
drivers/video/display/mipi-dsi-bus.c | 332 +++
include/video/display.h | 3 +
include/video/mipi-dsi-bus.h | 144 +++
5 files changed, 484 insertions(+)
create mode 100644 drivers/video/display/mipi-dsi-bus.c
create mode 100644 include/video/mipi-dsi-bus.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 9b482a8..619b05d 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -20,6 +20,10 @@ config DISPLAY_MIPI_DBI
tristate
default n
+config DISPLAY_MIPI_DSI
+ tristate
+ default n
+
config DISPLAY_PANEL_DPI
tristate "DPI (Parallel) Display Panels"
---help---
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index d03c64a..b323fd4 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -3,6 +3,7 @@ display-y :=
display-core.o \
obj-$(CONFIG_DISPLAY_CORE) += display.o
obj-$(CONFIG_DISPLAY_CONNECTOR_VGA)+= con-vga.o
obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
+obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o
obj-$(CONFIG_DISPLAY_PANEL_DPI)+= panel-dpi.o
obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/display/mipi-dsi-bus.c
b/drivers/video/display/mipi-dsi-bus.c
new file mode 100644
index 000..a194d92
--- /dev/null
+++ b/drivers/video/display/mipi-dsi-bus.c
@@ -0,0 +1,332 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012, Samsung Electronics, Co., Ltd.
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
-
+ * Bus operations
+ */
+
+int mipi_dsi_set_power(struct mipi_dsi_device *dev, bool on)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+
+ if (!ops->set_power)
+ return 0;
+
+ return ops->set_power(dev->bus, dev, on);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_set_power);
+
+int mipi_dsi_set_stream(struct mipi_dsi_device *dev, bool on)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+
+ if (!ops->set_stream)
+ return 0;
+
+ return ops->set_stream(dev->bus, dev, on);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_set_stream);
+
+int mipi_dsi_dcs_write(struct mipi_dsi_device *dev, int channel, const u8
*data,
+ size_t len)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+ u8 type = channel << 6;
+
+ if (!ops->transfer)
+ return -EINVAL;
+
+ switch (len) {
+ case 0:
+ return -EINVAL;
+ case 1:
+ type |= MIPI_DSI_DCS_SHORT_WRITE;
+ break;
+ case 2:
+ type |= MIPI_DSI_DCS_SHORT_WRITE_PARAM;
+ break;
+ default:
+ type |= MIPI_DSI_DCS_LONG_WRITE;
+ }
+
+ return ops->transfer(dev->bus, dev, type, data, len, NULL, 0);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_dcs_write);
+
+int mipi_dsi_dcs_read(struct mipi_dsi_device *dev, int channel, u8 cmd,
+ u8 *data, size_t len)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+ u8 type = MIPI_DSI_DCS_READ | (channel << 6);
+
+ if (!ops->transfer)
+ return -EINVAL;
+
+ return ops->transfer(dev->bus, dev, type, &cmd, 1, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_dcs_read);
+
+/*
-
+ * Bus type
+ */
+
+static const struct mipi_dsi_device_id *
+mipi_dsi_match_id(const struct mipi_dsi_device_id *id,
+ struct mipi_dsi_device *dev)
+{
+ while (id->name[0]) {
+ if (strcmp(dev->name, id->name) == 0) {
+ dev->id_entry = id;
+ return id;
+ }
+ id++;
+ }
+ return NULL;
+}
+
+static int mipi_dsi_match(struct device *_dev, struct device_driver *_drv)
+{
+ struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
+ struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv);
+
+ if (of_driver_match_device(_dev, _drv))
+ return 1;
+
+ if (drv->id_table)
+ return mipi_d
Re: [PATCH v3 2/4] ACPI / video: seperate backlight control and event interface
On 09/24/2013 05:47 PM, Aaron Lu wrote:
> The backlight control and event delivery functionality provided by ACPI
> video module is mixed together and registered all during video device
> enumeration time. As a result, the two functionality are also removed
> together on module unload time or by the acpi_video_unregister function.
> The two functionalities are actually independent and one may be useful
> while the other one may be broken, so it is desirable to seperate the
> two functionalities such that it is clear and easy to disable one
> functionality without affecting the other one.
>
> APIs to selectively remove backlight control interface and/or event
> delivery functionality can be easily added once needed.
>
> Signed-off-by: Aaron Lu
> Tested-by: Igor Gnatenko
> Tested-by: Yves-Alexis Perez
> ---
> drivers/acpi/video.c | 434
> +--
> include/acpi/video.h | 2 +
> 2 files changed, 247 insertions(+), 189 deletions(-)
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index aebcf63..3bd1eaa 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -89,6 +89,8 @@ static bool use_bios_initial_backlight = 1;
> module_param(use_bios_initial_backlight, bool, 0644);
>
> static int register_count;
> +static struct mutex video_list_lock;
> +static struct list_head video_bus_head;
> static int acpi_video_bus_add(struct acpi_device *device);
> static int acpi_video_bus_remove(struct acpi_device *device);
> static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
> @@ -157,6 +159,7 @@ struct acpi_video_bus {
> struct acpi_video_bus_flags flags;
> struct list_head video_device_list;
> struct mutex device_list_lock; /* protects video_device_list */
> + struct list_head entry;
> struct input_dev *input;
> char phys[32]; /* for input device */
> struct notifier_block pm_nb;
> @@ -884,79 +887,6 @@ static void acpi_video_device_find_cap(struct
> acpi_video_device *device)
>
> if (acpi_has_method(device->dev->handle, "_DDC"))
> device->cap._DDC = 1;
> -
> - if (acpi_video_backlight_support()) {
> - struct backlight_properties props;
> - struct pci_dev *pdev;
> - acpi_handle acpi_parent;
> - struct device *parent = NULL;
> - int result;
> - static int count;
> - char *name;
> -
> - result = acpi_video_init_brightness(device);
> - if (result)
> - return;
> - name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
> - if (!name)
> - return;
> - count++;
> -
> - acpi_get_parent(device->dev->handle, &acpi_parent);
> -
> - pdev = acpi_get_pci_dev(acpi_parent);
> - if (pdev) {
> - parent = &pdev->dev;
> - pci_dev_put(pdev);
> - }
> -
> - memset(&props, 0, sizeof(struct backlight_properties));
> - props.type = BACKLIGHT_FIRMWARE;
> - props.max_brightness = device->brightness->count - 3;
> - device->backlight = backlight_device_register(name,
> - parent,
> - device,
> -
> &acpi_backlight_ops,
> - &props);
> - kfree(name);
> - if (IS_ERR(device->backlight))
> - return;
> -
> - /*
> - * Save current brightness level in case we have to restore it
> - * before acpi_video_device_lcd_set_level() is called next time.
> - */
> - device->backlight->props.brightness =
> - acpi_video_get_brightness(device->backlight);
> -
> - device->cooling_dev = thermal_cooling_device_register("LCD",
> - device->dev, &video_cooling_ops);
> - if (IS_ERR(device->cooling_dev)) {
> - /*
> - * Set cooling_dev to NULL so we don't crash trying to
> - * free it.
> - * Also, why the hell we are returning early and
> - * not attempt to register video output if cooling
> - * device registration failed?
> - * -- dtor
> - */
> - device->cooling_dev = NULL;
> - return;
> - }
> -
> - dev_info(&device->dev->dev, "registered as cooling_device%d\n",
> - device->cooling_dev->id);
> - result = sysfs_create_link(&device->dev->dev.kobj,
> - &device->cooling_dev->device.kobj,
> -
[PATCH v3 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to
locate handle for ACPI video by HID, the problem is, ACPI video node
doesn't really have HID defined(i.e. no _HID control method is defined
for video device), so.. that function would fail. This can be solved by
enhancing the callback function for acpi_get_devices, where we can use
acpi_device_hid function to check if the ACPI node corresponds to a
video controller.
In addition to that, the _BCL control method only exists under a video
output device node, not a video controller device node. So to evaluate
_BCL, we need the handle of a video output device node, which is child
of the located video controller node from tpacpi_acpi_handle_locate.
The two fix are necessary for some Thinkpad models to emit notification
on backlight hotkey press as a result of evaluation of _BCL.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
---
drivers/platform/x86/thinkpad_acpi.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 03ca6c1..170f278 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -700,6 +700,14 @@ static void __init drv_acpi_handle_init(const char *name,
static acpi_status __init tpacpi_acpi_handle_locate_callback(acpi_handle
handle,
u32 level, void *context, void **return_value)
{
+ struct acpi_device *dev;
+ if (!strcmp(context, "video")) {
+ if (acpi_bus_get_device(handle, &dev))
+ return AE_OK;
+ if (strcmp(ACPI_VIDEO_HID, acpi_device_hid(dev)))
+ return AE_OK;
+ }
+
*(acpi_handle *)return_value = handle;
return AE_CTRL_TERMINATE;
@@ -712,10 +720,10 @@ static void __init tpacpi_acpi_handle_locate(const char
*name,
acpi_status status;
acpi_handle device_found;
- BUG_ON(!name || !hid || !handle);
+ BUG_ON(!name || !handle);
vdbg_printk(TPACPI_DBG_INIT,
"trying to locate ACPI handle for %s, using HID %s\n",
- name, hid);
+ name, hid ? hid : "NULL");
memset(&device_found, 0, sizeof(device_found));
status = acpi_get_devices(hid, tpacpi_acpi_handle_locate_callback,
@@ -6090,19 +6098,28 @@ static int __init tpacpi_query_bcl_levels(acpi_handle
handle)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
+ struct acpi_device *device, *child;
int rc;
- if (ACPI_SUCCESS(acpi_evaluate_object(handle, "_BCL", NULL, &buffer))) {
+ if (acpi_bus_get_device(handle, &device))
+ return 0;
+
+ rc = 0;
+ list_for_each_entry(child, &device->children, node) {
+ acpi_status status = acpi_evaluate_object(child->handle, "_BCL",
+ NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ continue;
+
obj = (union acpi_object *)buffer.pointer;
if (!obj || (obj->type != ACPI_TYPE_PACKAGE)) {
pr_err("Unknown _BCL data, please report this to %s\n",
- TPACPI_MAIL);
+ TPACPI_MAIL);
rc = 0;
} else {
rc = obj->package.count;
}
- } else {
- return 0;
+ break;
}
kfree(buffer.pointer);
@@ -6118,7 +6135,7 @@ static unsigned int __init
tpacpi_check_std_acpi_brightness_support(void)
acpi_handle video_device;
int bcl_levels = 0;
- tpacpi_acpi_handle_locate("video", ACPI_VIDEO_HID, &video_device);
+ tpacpi_acpi_handle_locate("video", NULL, &video_device);
if (video_device)
bcl_levels = tpacpi_query_bcl_levels(video_device);
--
1.8.4.12.g2ea3df6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] ACPI / video: Do not register backlight if win8 and native interface exists
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".
So for Win8 systems, if there is native backlight control interface
registered by GPU driver, ACPI video will not register its own. For
users who prefer to keep ACPI video's backlight interface, the existing
kernel cmdline option acpi_backlight=video can be used.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
---
drivers/acpi/internal.h | 5 ++---
drivers/acpi/video.c| 10 +-
drivers/acpi/video_detect.c | 14 --
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..453ae8d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
Video
-- */
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-bool acpi_video_backlight_quirks(void);
-#else
-static inline bool acpi_video_backlight_quirks(void) { return false; }
+bool acpi_osi_is_win8(void);
+bool acpi_video_verify_backlight_support(void);
#endif
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 3bd1eaa..343db59 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
- /* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ /* no warning message if acpi_backlight=vendor or a quirk is used */
+ if (!acpi_video_verify_backlight_support())
return 0;
if (!device->brightness)
@@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus *video,
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 1 : 0);
+ acpi_osi_is_win8() ? 1 : 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 0 : 1);
+ acpi_osi_is_win8() ? 0 : 1);
}
static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level, void
*context,
static void acpi_video_dev_register_backlight(struct acpi_video_device *device)
{
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 940edbf..23d7d26 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
acpi_video_get_capabilities(NULL);
}
-bool acpi_video_backlight_quirks(void)
+bool acpi_osi_is_win8(void)
{
return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
}
-EXPORT_SYMBOL(acpi_video_backlight_quirks);
+EXPORT_SYMBOL(acpi_osi_is_win8);
/* Promote the vendor interface instead of the generic video module.
* This function allow DMI blacklists to be implemented by externals
@@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
}
EXPORT_SYMBOL(acpi_video_backlight_support);
+bool acpi_video_verify_backlight_support(void)
+{
+ if (!(acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) &&
+ acpi_osi_is_win8() && backlight_device_registered(BACKLIGHT_RAW))
+ return false;
+ return acpi_video_backlight_support();
+}
+EXPORT_SYMBOL(acpi_video_verify_backlight_support);
+
/*
* Use acpi_backlight=vendor/video to force that backlight switching
* is processed by vendor specific acpi drivers or video.ko driver.
--
1.8.4.12.g2ea3df6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] ACPI / video: seperate backlight control and event interface
The backlight control and event delivery functionality provided by ACPI
video module is mixed together and registered all during video device
enumeration time. As a result, the two functionality are also removed
together on module unload time or by the acpi_video_unregister function.
The two functionalities are actually independent and one may be useful
while the other one may be broken, so it is desirable to seperate the
two functionalities such that it is clear and easy to disable one
functionality without affecting the other one.
APIs to selectively remove backlight control interface and/or event
delivery functionality can be easily added once needed.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
---
drivers/acpi/video.c | 434 +--
include/acpi/video.h | 2 +
2 files changed, 247 insertions(+), 189 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index aebcf63..3bd1eaa 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -89,6 +89,8 @@ static bool use_bios_initial_backlight = 1;
module_param(use_bios_initial_backlight, bool, 0644);
static int register_count;
+static struct mutex video_list_lock;
+static struct list_head video_bus_head;
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
@@ -157,6 +159,7 @@ struct acpi_video_bus {
struct acpi_video_bus_flags flags;
struct list_head video_device_list;
struct mutex device_list_lock; /* protects video_device_list */
+ struct list_head entry;
struct input_dev *input;
char phys[32]; /* for input device */
struct notifier_block pm_nb;
@@ -884,79 +887,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
if (acpi_has_method(device->dev->handle, "_DDC"))
device->cap._DDC = 1;
-
- if (acpi_video_backlight_support()) {
- struct backlight_properties props;
- struct pci_dev *pdev;
- acpi_handle acpi_parent;
- struct device *parent = NULL;
- int result;
- static int count;
- char *name;
-
- result = acpi_video_init_brightness(device);
- if (result)
- return;
- name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
- if (!name)
- return;
- count++;
-
- acpi_get_parent(device->dev->handle, &acpi_parent);
-
- pdev = acpi_get_pci_dev(acpi_parent);
- if (pdev) {
- parent = &pdev->dev;
- pci_dev_put(pdev);
- }
-
- memset(&props, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_FIRMWARE;
- props.max_brightness = device->brightness->count - 3;
- device->backlight = backlight_device_register(name,
- parent,
- device,
-
&acpi_backlight_ops,
- &props);
- kfree(name);
- if (IS_ERR(device->backlight))
- return;
-
- /*
-* Save current brightness level in case we have to restore it
-* before acpi_video_device_lcd_set_level() is called next time.
-*/
- device->backlight->props.brightness =
- acpi_video_get_brightness(device->backlight);
-
- device->cooling_dev = thermal_cooling_device_register("LCD",
- device->dev, &video_cooling_ops);
- if (IS_ERR(device->cooling_dev)) {
- /*
-* Set cooling_dev to NULL so we don't crash trying to
-* free it.
-* Also, why the hell we are returning early and
-* not attempt to register video output if cooling
-* device registration failed?
-* -- dtor
-*/
- device->cooling_dev = NULL;
- return;
- }
-
- dev_info(&device->dev->dev, "registered as cooling_device%d\n",
-device->cooling_dev->id);
- result = sysfs_create_link(&device->dev->dev.kobj,
- &device->cooling_dev->device.kobj,
- "thermal_cooling");
- if (result)
- printk(KERN_ERR PREFIX "Create sysfs link
[PATCH v3 1/4] backlight: introduce backlight_device_registered
Introduce a new API for modules to query if a specific type of backlight
device has been registered. This is useful for some backlight device
provider module(e.g. ACPI video) to know if a native control
interface(e.g. the interface created by i915) is available and then do
things accordingly(e.g. avoid register its own on Win8 systems).
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
---
drivers/video/backlight/backlight.c | 31 +++
include/linux/backlight.h | 4
2 files changed, 35 insertions(+)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..bf2d71d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -21,6 +21,9 @@
#include
#endif
+static struct list_head bd_list_head;
+static struct mutex bd_list_mutex;
+
static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
[BACKLIGHT_PLATFORM] = "platform",
@@ -349,10 +352,32 @@ struct backlight_device *backlight_device_register(const
char *name,
mutex_unlock(&pmac_backlight_mutex);
#endif
+ mutex_lock(&bd_list_mutex);
+ list_add(&new_bd->entry, &bd_list_head);
+ mutex_unlock(&bd_list_mutex);
+
return new_bd;
}
EXPORT_SYMBOL(backlight_device_register);
+bool backlight_device_registered(enum backlight_type type)
+{
+ bool found = false;
+ struct backlight_device *bd;
+
+ mutex_lock(&bd_list_mutex);
+ list_for_each_entry(bd, &bd_list_head, entry) {
+ if (bd->props.type == type) {
+ found = true;
+ break;
+ }
+ }
+ mutex_unlock(&bd_list_mutex);
+
+ return found;
+}
+EXPORT_SYMBOL(backlight_device_registered);
+
/**
* backlight_device_unregister - unregisters a backlight device object.
* @bd: the backlight device object to be unregistered and freed.
@@ -364,6 +389,10 @@ void backlight_device_unregister(struct backlight_device
*bd)
if (!bd)
return;
+ mutex_lock(&bd_list_mutex);
+ list_del(&bd->entry);
+ mutex_unlock(&bd_list_mutex);
+
#ifdef CONFIG_PMAC_BACKLIGHT
mutex_lock(&pmac_backlight_mutex);
if (pmac_backlight == bd)
@@ -499,6 +528,8 @@ static int __init backlight_class_init(void)
backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
+ INIT_LIST_HEAD(&bd_list_head);
+ mutex_init(&bd_list_mutex);
return 0;
}
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..5f9cd96 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -100,6 +100,9 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
+ /* list entry of all registered backlight devices */
+ struct list_head entry;
+
struct device dev;
};
@@ -123,6 +126,7 @@ extern void devm_backlight_device_unregister(struct device
*dev,
struct backlight_device *bd);
extern void backlight_force_update(struct backlight_device *bd,
enum backlight_update_reason reason);
+extern bool backlight_device_registered(enum backlight_type type);
#define to_backlight_device(obj) container_of(obj, struct backlight_device,
dev)
--
1.8.4.12.g2ea3df6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] Fix Win8 backlight issue
v3: 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; 2 Remove unnecessary function acpi_video_unregister introduced in patch 2/3 as pointed out by Jani Nikula. v2: v1 has the subject of "Rework ACPI video driver" and is posted here: http://lkml.org/lkml/2013/9/9/74 Since the objective is really to fix Win8 backlight issues, I changed the subject in this version, sorry about that. This patchset has three patches, the first introduced a new API named backlight_device_registered in backlight layer that can be used for backlight interface provider module to check if a specific type backlight interface has been registered, see changelog for patch 1/3 for details. Then patch 2/3 does the cleanup to sepeate the backlight control and event delivery functionality in the ACPI video module and patch 3/3 solves some Win8 backlight control problems by avoiding register ACPI video's backlight interface if: 1 Kernel cmdline option acpi_backlight=video is not given; 2 This is a Win8 system; 3 Native backlight control interface exists. Technically, patch 2/3 is not required to fix the issue here. So if you think it is not necessary, I can remove it from the series. Aaron Lu (4): backlight: introduce backlight_device_registered ACPI / video: seperate backlight control and event interface ACPI / video: Do not register backlight if win8 and native interface exists thinkpad-acpi: fix handle locate for video and query of _BCL drivers/acpi/internal.h | 5 +- drivers/acpi/video.c | 442 --- drivers/acpi/video_detect.c | 14 +- drivers/platform/x86/thinkpad_acpi.c | 31 ++- drivers/video/backlight/backlight.c | 31 +++ include/acpi/video.h | 2 + include/linux/backlight.h| 4 + 7 files changed, 324 insertions(+), 205 deletions(-) -- 1.8.4.12.g2ea3df6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] ARM: dts: AM33XX: Add LCDC info into am335x-evm
Hi Benoit,
On 03/09/2013 16:55, Benoit Parrot wrote:
Hi,
I have not received any feedback on this patch.
It has been pending since the end of June (first post).
Can I get an estimate when it will be included/accepted?
It looks good to me beside a minor comment below.
Could you just rebase it on my lastest
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.13/dts branch because it conflicts with the cleanup done by Javier.
On Fri, Aug 23, 2013 at 11:13:56AM -0500, Benoit Parrot wrote:
Add LCDC device node in DT for am33xx
Add LCDC and Panel info in DT for am335x-evm
Changes in v3:
- rebase to 3.11-rc6
Changes in v2:
- remove redundant/unnecessary SoC specific setting in the board dts
Signed-off-by: Benoit Parrot
---
arch/arm/boot/dts/am335x-evm.dts | 72 ++
arch/arm/boot/dts/am33xx.dtsi|9 +
2 files changed, 81 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..b0703f1 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -149,6 +149,40 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+
+ lcd_pins_s0: lcd_pins_s0 {
+ pinctrl-single,pins = <
+ 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT
| MODE1 */
+ 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT
| MODE1 */
+ 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT
| MODE1 */
+ 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT
| MODE1 */
+ 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT
| MODE1 */
+ 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT
| MODE1 */
+ 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT
| MODE1 */
+ 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT
| MODE1 */
+ 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT
| MODE0 */
+ 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT
| MODE0 */
+ 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT
| MODE0 */
+ 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT
| MODE0 */
+ 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT
| MODE0 */
+ 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT
| MODE0 */
+ 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT
| MODE0 */
+ 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT
| MODE0 */
+ 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT
| MODE0 */
+ 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT
| MODE0 */
+ 0xc8 0x00 /* lcd_data10.lcd_data10,
OUTPUT | MODE0 */
+ 0xcc 0x00 /* lcd_data11.lcd_data11,
OUTPUT | MODE0 */
+ 0xd0 0x00 /* lcd_data12.lcd_data12,
OUTPUT | MODE0 */
+ 0xd4 0x00 /* lcd_data13.lcd_data13,
OUTPUT | MODE0 */
+ 0xd8 0x00 /* lcd_data14.lcd_data14,
OUTPUT | MODE0 */
+ 0xdc 0x00 /* lcd_data15.lcd_data15,
OUTPUT | MODE0 */
+ 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT
| MODE0 */
+ 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT
| MODE0 */
+ 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT |
MODE0 */
+ 0xec 0x00 /*
lcd_ac_bias_en.lcd_ac_bias_en, OUTPUT | MODE0 */
+ >;
+ };
+
};
ocp {
@@ -311,6 +345,10 @@
};
};
};
+
+ lcdc: lcdc@4830e000 {
+ status = "okay";
+ };
};
vbat: fixedregulator@0 {
@@ -374,6 +412,40 @@
brightness-levels = <0 51 53 56 62 75 101 152 255>;
default-brightness-level = <8>;
};
+
+ panel {
+ compatible = "ti,tilcdc,panel";
Nit: There are a lots of TI here :-)
Could you just name it: ti,lcdc,panel ?
Thanks,
Benoit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/nouveau: fix nested locking in mmap handler
* Maarten Lankhorst wrote: > > I think the Nouveau guys need to comment further on this, but > > returning -EFAULT might break existing user-space, and that's not > > allowed, but IIRC the return value of "presumed" is only a hint, and > > if it's incorrect will only trigger future command stream patching. > > > > Otherwise reviewing mostly the TTM stuff. FWIW, from wat I can tell > > the vmwgfx driver doesn't need any fixups. > > Well because we read the list of buffer objects the presumed offsets are > at least read-mapped. Although I guess in the worst case the mapping > might disappear before the syscall copies back the data. So if -EFAULT > happens here then userspace messed up in some way, either by forgetting > to map the offsets read-write, which cannot happen with libdrm or > free'ing the bo list before the syscall returns, which would probably > result in libdrm crashing shortly afterwards anyway. > > So I don't know whether to swallow that -EFAULT or not, which is what I > asked. In such a case returning -EFAULT is very strongly preferred. If there's a user-space bug, such as a context life time race between graphics context creation/destruction and user threads making use of the graphics context, then getting the -EFAULT would be very helpful to user-space debugging as well. Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/4] CDFv3: MIPI DSI bus implementation
Hi Laurent, This is my MIPI DSI bus implementation. The patchset contains also two drivers: - DSI bus master driver for Exynos, - DSI slave driver for s6e8aa0 panel family. All code has been tested on real device - Exynos 4210 based 'Trats'. This is not final version, there are still some things to do. DSI bus code is based on mipi-dbi-bus, with few major changes. 1. I have replaced three DBI opses: - write_command, - write_data, - read_data with one op 'transfer', this way it better fits to MIPI DSI standard, I wonder if this cannot be adapted to DBI also. The only things which bothers me is number of arguments, maybe struct should be used instead. I have added DCS helpers functions which use 'transfer' op: - mipi_dsi_dcs_read - mipi_dsi_dcs_write and two macros which allow to pass variable number of bytes as arguments, example usage in panel driver code: - mipi_dsi_dcs_write_seq - mipi_dsi_dcs_write_static_seq I have added also following opses: - set_stream - to enable/disable streaming on DSI master, - set_power - I have temporarily dropped idea of using runtime_pm due to compliacted power on sequence of panel/dsi, which would probably require different op anyway. struct mipi_dsi_device contains videomode and mipi_dsi_interface_params fields. Those fields are read by opses, I wonder if it would not be better to pass them directly to opses as arguments. TODO: - helpers for non-DT drivers, - minor power management issues, - better error handling - ... Regards Andrzej Andrzej Hajda (4): mipi-dsi-bus: add MIPI DSI bus support mipi-dsi-exynos: add driver panel-s6e8aa0: add driver ARM: dts: exynos4210-trats: add panel and dsi nodes arch/arm/boot/dts/exynos4210-trats.dts | 54 ++ drivers/video/display/Kconfig | 14 + drivers/video/display/Makefile |3 + drivers/video/display/mipi-dsi-bus.c| 332 drivers/video/display/mipi-dsi-exynos.c | 1310 +++ drivers/video/display/panel-s6e8aa0.c | 1286 ++ include/video/display.h |3 + include/video/mipi-dsi-bus.h| 144 include/video/mipi-dsi-exynos.h | 41 + include/video/panel-s6e8aa0.h | 42 + 10 files changed, 3229 insertions(+) create mode 100644 drivers/video/display/mipi-dsi-bus.c create mode 100644 drivers/video/display/mipi-dsi-exynos.c create mode 100644 drivers/video/display/panel-s6e8aa0.c create mode 100644 include/video/mipi-dsi-bus.h create mode 100644 include/video/mipi-dsi-exynos.h create mode 100644 include/video/panel-s6e8aa0.h -- 1.8.1.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
