[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:46:01PM +0200, Yves-Alexis Perez wrote: > But if that introduce regressions, shouldn't workarounds be found then? > Sorry if I keep repeating that but brightness keys handling in-kernel is > quite a useful feature and losing it (because of the ?behave exactly > like Windows 8 kernel? policy) is indeed a regression. Your firmware behaves differently depending on whether the OS claims to be Windows 8 or not. We can't make that invisible. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> > just fine, whether in console, in the display manager or in my desktop
> > environment (Xfce). xfce4-power-manager just needs to be told that the
> > brightness keys are already handled and it doesn't need to do anything.
>
> Right, the kernel has special-casing to hook the backlight keys up to
> the ACPI backlight control. This is an awful thing, because there's no
> way to detect this case other than parsing a single driver-specific
> module parameter.
I'm not sure what that means. To detect what case exactly? That the
brightness is handled by video.ko?
>
> Could this functionality be duplicated across other backlight drivers?
> Not easily. The ACPI driver receives keypresses and performs backlight
> control. The i915 driver doesn't receive keypresses. We could easily tie
> certain keycodes into backlight events, but which backlight should they
> control? You're really starting to get into the kind of complex policy
> decision that's best left to userspace, which is where it should have
> been to begin with.
>
Well, I get the reasoning, but I'm not sure I agree. That means
userspace behavior is inconsistent depending on who does it
(gnome-power-manager, gnome-setting-daemon, whatever), and it usually
means there's nothing handling the brightness before those are running,
not to mention people not running them because they don't run a full
blown desktop environment (until someone starts thinking it's a good
idea to handle brightness in systemd).
And in the end, the user just want the brightness keys to correctly
handle the brightness, full stop. Having multiple brightness daemons
using different policies on different hardware is a nightmare for the
end user, imho. From a user point of view, having it handled all in the
kernel works really pretty fine and is completely transparent (I have to
admit that from that point of view, it was even better when it was
handled by the EC but those times seem long gone).
Regards,
--
Yves-Alexis
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/d78f51ec/attachment-0001.pgp>
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote: > On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote: > > Which, as we've already established, you don't - Lenovo broke it. Your > > Thinkpad claims to have 100 available levels, and most of them don't > > work. The kernel has no way of knowing which levels work and which > > don't, so leaving this up to the kernel won't actually fix your system > > either. > > I was referring to ?standardize the behaviour by leaving up to > userspace?. A lot of thinkpads (for example) (all the pre-windows 8 > ones) have a perfectly working ACPI backlight interface. And this patchset won't alter their behaviour. > Also, if the kernel has no way of knowing which levels work, I fail to > see how userspace can do better. It can't. That's why this patchset disables the ACPI interface on Windows 8 systems. > I understand that switching to intel_backlight instead of acpi_video0 > follows what Windows 8 recommends but for me it looks orthogonal to the > fact ACPI methods now have some awkward (Lenovo) or broken (Dell). I > mean, it's not the first time firmware people break some kernel > behavior. I know it's usually not easy to contact them, but shouldn't > those methods be fixed, instead of somehow blindly switching to graphic > drivers? No. The correct answer to all firmware issues is "Are we making the same firmware calls as the version of Windows that this hardware thinks it's running". If Windows 8 doesn't make these calls, we shouldn't make these calls. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote: > On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote: > > I agree, we should standardise the behaviour. And the only way we can > > standardise the behaviour is to leave it up to userspace. > > > It's pretty clear we disagree on this and that my opinion won't really > matter here. But letting userspace handle that just means broken > functionality for those who have the chance (apparently) to have an ACPI > backlight interface. Which, as we've already established, you don't - Lenovo broke it. Your Thinkpad claims to have 100 available levels, and most of them don't work. The kernel has no way of knowing which levels work and which don't, so leaving this up to the kernel won't actually fix your system either. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote: > On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote: > > Right, the kernel has special-casing to hook the backlight keys up to > > the ACPI backlight control. This is an awful thing, because there's no > > way to detect this case other than parsing a single driver-specific > > module parameter. > > I'm not sure what that means. To detect what case exactly? That the > brightness is handled by video.ko? That the kernel will automatically handle backlight key presses. > > Could this functionality be duplicated across other backlight drivers? > > Not easily. The ACPI driver receives keypresses and performs backlight > > control. The i915 driver doesn't receive keypresses. We could easily tie > > certain keycodes into backlight events, but which backlight should they > > control? You're really starting to get into the kind of complex policy > > decision that's best left to userspace, which is where it should have > > been to begin with. > > > Well, I get the reasoning, but I'm not sure I agree. That means > userspace behavior is inconsistent depending on who does it > (gnome-power-manager, gnome-setting-daemon, whatever), and it usually > means there's nothing handling the brightness before those are running, > not to mention people not running them because they don't run a full > blown desktop environment (until someone starts thinking it's a good > idea to handle brightness in systemd). The behaviour is already inconsistent. If you have an ACPI backlight interface, hitting the keys makes your brightness change without any userspace help. If you don't, it doesn't. > And in the end, the user just want the brightness keys to correctly > handle the brightness, full stop. Having multiple brightness daemons > using different policies on different hardware is a nightmare for the > end user, imho. From a user point of view, having it handled all in the > kernel works really pretty fine and is completely transparent (I have to > admit that from that point of view, it was even better when it was > handled by the EC but those times seem long gone). I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. -- Matthew Garrett | mjg59 at srcf.ucam.org
[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #22 from PJBrs --- This fixes it!--great, thanks very much! Is this patch already in master? And will it also go in the 9.0 / 9.1 stable branches? Anyway, thanks very much again for your time, glad I could be of some help too. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/4d11b0ec/attachment.html>
[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes
https://bugzilla.kernel.org/show_bug.cgi?id=57381 Nigel Cunningham changed: What|Removed |Added CC||nigel at tuxonice.net --- Comment #20 from Nigel Cunningham 2013-06-25 20:54:06 --- If you install the userui binary in the initramfs, you'll be able to single step through the process and modify the TuxOnIce debugging settings as you go - perhaps this will help. Press 'P' to pause between steps, 0-9 to modify the level of debugging info that's displayed (9 = max info, including all kernel messages). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes
https://bugzilla.kernel.org/show_bug.cgi?id=57381 --- Comment #19 from Harald Judt 2013-06-25 19:10:07 --- > echo disabled > > "/sys/devices/pci:00/:00:01.0/:01:00.0/power/async" > echo disabled > > "/sys/devices/pci:00/:00:01.0/:01:00.1/power/async" > > This seems to have a similar effect as "echo 0 > /sys/power/pm_async". I believe I was wrong with this assumption. However, I got serial console debugging working now. Unfortunately, it does not reveal much, but here is the output anyway. Linux version 3.8.13+ (user at localhost) (gcc version 4.7.3 (Gentoo 4.7.3 p1.0, pie-0.5.5) ) #142 SMP PREEMPT Tue Jun 25 18:56:39 CEST 2013^M^J Command line: root=/dev/sda6 rootfstype=ext4 video=DVI-I-1:1920x1080 radeon.pcie_gen2=1 radeon.audio=1 pci=nocrs console=ttyS0,115200n8 console=tty0 no_console_suspend=1^M^J e820: BIOS-provided physical RAM map:^M^J BIOS-e820: [mem 0x-0x0009d7ff] usable^M^J BIOS-e820: [mem 0x0009d800-0x0009] reserved^M^J BIOS-e820: [mem 0x000e-0x000f] reserved^M^J BIOS-e820: [mem 0x0010-0xdd49dfff] usable^M^J BIOS-e820: [mem 0xdd49e000-0xde048fff] reserved^M^J BIOS-e820: [mem 0xde049000-0xde0d5fff] usable^M^J BIOS-e820: [mem 0xde0d6000-0xde177fff] ACPI NVS^M^J BIOS-e820: [mem 0xde178000-0xde976fff] reserved^M^J BIOS-e820: [mem 0xde977000-0xde977fff] usable^M^J BIOS-e820: [mem 0xde978000-0xde9bafff] ACPI NVS^M^J BIOS-e820: [mem 0xde9bb000-0xdf3f5fff] usable^M^J BIOS-e820: [mem 0xdf3f6000-0xdf7f1fff] reserved^M^J BIOS-e820: [mem 0xdf7f2000-0xdf7f] usable^M^J BIOS-e820: [mem 0xf800-0xfbff] reserved^M^J BIOS-e820: [mem 0xfec0-0xfec00fff] reserved^M^J BIOS-e820: [mem 0xfed0-0xfed03fff] reserved^M^J BIOS-e820: [mem 0xfed1c000-0xfed1] reserved^M^J BIOS-e820: [mem 0xfee0-0xfee00fff] reserved^M^J BIOS-e820: [mem 0xff00-0x] reserved^M^J BIOS-e820: [mem 0x0001-0x00041eff] usable^M^J NX (Execute Disable) protection: active^M^J SMBIOS 2.7 present.^M^J No AGP bridge found^M^J e820: last_pfn = 0x41f000 max_arch_pfn = 0x4^M^J x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106^M^J e820: last_pfn = 0xdf800 max_arch_pfn = 0x4^M^J found SMP MP-table at [mem 0x000fd8e0-0x000fd8ef] mapped at [880fd8e0]^M^J init_memory_mapping: [mem 0x-0xdf7f]^M^J init_memory_mapping: [mem 0x1-0x41eff]^M^J ACPI: RSDP 000f0490 00024 (v02 ALASKA)^M^J ACPI: XSDT de169078 0006C (v01 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: FACP de172f58 0010C (v05 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: DSDT de169178 09DDD (v02 ALASKAA M I 0022 INTL 20051117)^M^J ACPI: FACS de176080 00040^M^J ACPI: APIC de173068 00092 (v03 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: FPDT de173100 00044 (v01 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: MCFG de173148 0003C (v01 ALASKAA M I 01072009 MSFT 0097)^M^J ACPI: AAFT de173188 00112 (v01 ALASKA OEMAAFT 01072009 MSFT 0097)^M^J ACPI: HPET de1732a0 00038 (v01 ALASKAA M I 01072009 AMI. 0005)^M^J ACPI: SSDT de1732d8 0036D (v01 SataRe SataTabl 1000 INTL 20091112)^M^J ACPI: SSDT de173648 00A92 (v01 PmRefCpuPm 3000 INTL 20051117)^M^J ACPI: BGRT de1740e0 00038 (v00 ALASKAA M I 01072009 AMI 00010013)^M^J No NUMA configuration found^M^J Faking a node at [mem 0x-0x00041eff]^M^J Initmem setup node 0 [mem 0x-0x41eff]^M^J NODE_DATA [mem 0x41effc000-0x41eff]^M^J Zone ranges:^M^J DMA [mem 0x0001-0x00ff]^M^J DMA32[mem 0x0100-0x]^M^J Normal [mem 0x1-0x41eff]^M^J Movable zone start for each node^M^J Early memory node ranges^M^J node 0: [mem 0x0001-0x0009cfff]^M^J node 0: [mem 0x0010-0xdd49dfff]^M^J node 0: [mem 0xde049000-0xde0d5fff]^M^J node 0: [mem 0xde977000-0xde977fff]^M^J node 0: [mem 0xde9bb000-0xdf3f5fff]^M^J node 0: [mem 0xdf7f2000-0xdf7f]^M^J node 0: [mem 0x1-0x41eff]^M^J ACPI: PM-Timer IO Port: 0x408^M^J ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)^M^J ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)^M^J ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)^M^J ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)^M^J ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)^M^J ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)^M^J ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)^M^J ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)^M^J ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])^M^J ACPI: IOAPIC (id[0x02] address[0xfec0]
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
>> Before Linux support for acpi_osi("Windows 2012") (and when booting with
>> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
>> just fine, whether in console, in the display manager or in my desktop
>> environment (Xfce). xfce4-power-manager just needs to be told that the
>> brightness keys are already handled and it doesn't need to do anything.
>
> Right, the kernel has special-casing to hook the backlight keys up to
> the ACPI backlight control. This is an awful thing, because there's no
> way to detect this case other than parsing a single driver-specific
> module parameter.
>
> Could this functionality be duplicated across other backlight drivers?
> Not easily. The ACPI driver receives keypresses and performs backlight
> control. The i915 driver doesn't receive keypresses. We could easily tie
> certain keycodes into backlight events, but which backlight should they
> control? You're really starting to get into the kind of complex policy
> decision that's best left to userspace, which is where it should have
> been to begin with.
Do we have any chances to amend this mistake by (gradually) phasing
out support for the direct keypress forwarding in ACPI? Or at least
some plans?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
commands for that. I am thinking >> of using existing resources as possible. My idea also is similar in >> using the reservation stuff to your idea because my approach also >> should use the dma-buf resource. However, My idea is that a user >> process, that wants buffer synchronization with the other, sees a sync >> object as a file descriptor like dma-buf does. The below shows simple >> my idea about it: >> >> ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, ); >> >> flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock. >> CPU access for read >> flock(sync->fd, LOCK_UN); >> >> Or >> >> flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock >> CPU access for write >> flock(sync->fd, LOCK_UN); >> >> close(sync->fd); >> >> As you know, that's similar to dmabuf export feature. >> >> In addition, a more simple idea, >> flock(dmabuf_fd, LOCK_SH/EX); >> CPU access for read/write >> flock(dmabuf_fd, LOCK_UN); >> >> However, I'm not sure that the above examples could be worked well, >> and there are no problems yet: actually, I don't fully understand >> flock mechanism, so looking into it. >> >>> >>>> >>>> And to get back to my original point: if you have more than >>>> one task >>>> operating together on a buffer you absolutely need some kind >>>> of real IPC >>>> to sync them up and do something useful. Both you syncpoints >>>> and the >>>> proposed dma-fences only protect the buffer accesses to make >>>> sure >>>> different task don't stomp on each other. There is nothing in >>>> there to >>>> make sure that the output of your pipeline is valid. You have >>>> to take >>>> care of that yourself in userspace. I'll reuse your example to >>>> make it >>>> clear what I mean: >>>> >>>> Task A Task B >>>> -- --- >>>> dma_buf_sync_lock(buf1) >>>> CPU write buf1 >>>> dma_buf_sync_unlock(buf1) >>>> -schedule Task A again--- >>>> dma_buf_sync_lock(buf1) >>>> CPU write buf1 >>>> dma_buf_sync_unlock(buf1) >>>> -schedule Task B- >>>>qbuf(buf1) >>>> >>>> dma_buf_sync_lock(buf1) >>>> >>>> >>>> This is what can happen if you don't take care of proper >>>> syncing. Task A >>>> writes something to the buffer in expectation that Task B will >>>> take care >>>> of it, but before Task B even gets scheduled Task A overwrites >>>> the >>>> buffer again. Not what you wanted, isn't it? >>>> >>>> Exactly wrong example. I had already mentioned about that. "In case >>>> that data flow goes from A to B, it needs some kind of IPC between the >>>> two tasks every time" So again, your example would have no any >>>> problem in case that *two tasks share the same buffer but these tasks >>>> access the buffer(buf1) as write, and data of the buffer(buf1) isn't >>>> needed to be shared*. They just need to use the buffer as *storage*. >>>> So All they want is to avoid stomping on the buffer in this case. >>>> >>> Sorry, but I don't see the point. If no one is interested in the data of >>> the buffer, why are you sharing it in the first place? >>> >> >> Just used as a storage. i.e., Task A fills the buffer with "AA" >> using CPU, And Task B fills the buffer with "BB" using DMA. They >> don't share data of the buffer, but they share *memory region* of the >> buffer. That would be very useful for the embedded systems with very >> small size system memory. > > Just so i understand. You want to share backing memory, you don't want > to share content ie you want to do memory management in userspace. > This sounds wrong on so many level (not even considering the security > implication). > > If Task A need memory and then can release it for Task B usage Not true. Task A can never release memory because All task A can do is to unreference dma buf object of sync object. And please know that user interfaces hasn't been implemented yet, and we just have a plan for it as I already mentioned. > that > should be the role of kernel memory management which of course needs > synchronization btw A and B. But in no case this should be done using > dma-buf. dma-buf is for sharing content btw different devices not > sharing resources. > hmm, is that true? And are you sure? Then how do you think about reservation? the reservation also uses dma-buf with same reason as long as I know: actually, we use reservation to use dma-buf. As you may know, a reservation object is allocated and initialized when a buffer object is exported to a dma buf. Thanks, Inki Dae > > Also don't over complicate the vram case, just consider desktop gpu as > using system memory directly. They can do it and they do it. Migration > to vram is orthogonal to all this, it's an optimization so to speak. > > Cheers, > Jerome -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/d27a3ed5/attachment-0001.html>
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 06:10:35PM +0200, Daniel Vetter wrote: > Do we have any chances to amend this mistake by (gradually) phasing > out support for the direct keypress forwarding in ACPI? Or at least > some plans? We could make the default value of brightness_switch_enabled a config variable and encourage distributions to flip their behaviour. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
> Before Linux support for acpi_osi("Windows 2012") (and when booting with
> acpi_osi="!Windows 2012"), brightness keys were handled by the kernel
> just fine, whether in console, in the display manager or in my desktop
> environment (Xfce). xfce4-power-manager just needs to be told that the
> brightness keys are already handled and it doesn't need to do anything.
Right, the kernel has special-casing to hook the backlight keys up to
the ACPI backlight control. This is an awful thing, because there's no
way to detect this case other than parsing a single driver-specific
module parameter.
Could this functionality be duplicated across other backlight drivers?
Not easily. The ACPI driver receives keypresses and performs backlight
control. The i915 driver doesn't receive keypresses. We could easily tie
certain keycodes into backlight events, but which backlight should they
control? You're really starting to get into the kind of complex policy
decision that's best left to userspace, which is where it should have
been to begin with.
--
Matthew Garrett | mjg59 at srcf.ucam.org
Armada DRM driver on OLPC XO
Hi Russell,
Thanks a lot for writing the Armada DRM driver.
I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
aka PXA2128). After a bit of fighting, I have it running. Could you share your
X driver, or your methodology for testing hardware cursors? I'd like to test
your work there too.
It's probably easiest to get your cubox driver merged before adding MMP2/MMP3
complications into the mix. At that point, I will hopefully have time to
follow up developing MMP2/MMP3 support, which will involve the points
mentioned below.
A hacky patch is also included below, which makes the driver run on this
platform. I'm prepared to do the heavy lifting in implementing these changes
properly, but any high level guidance would be appreciated, especially as I
am new to the world of graphics.
Ordered roughly from highest to lowest importance:
1. Device tree support
The OLPC XO boots entirely from the device tree, all clocks and things are
defined there. Your current display controller driver is close to
DT-compatibility, the only tricky bit is:
?? ?? ?? ?? ?? ?? ?? ??clk = clk_get_sys("dovefb.0", "extclk");
Not sure how that would translate to DT, or if we can transform that into
something that works for both DT and platform devices. The norm in DT is
that a clock is associated to a specific device, so we could just pull it
off the platform device itself.
2. Panel support.
>From my reading of your patches, on the cubox you drive the hardware as if it
is connected to a panel, but actually it is connected to an encoder chip which
outputs a HDMI signal?
In the OLPC case, we actually have a dumb panel connected to the panel
interface, so we need some driver support there.
The panel definition should come from the device tree, but I already hit a
small headache there. The display controller driver (armada_drv) gets probed
before my panel driver, and armada_drm_load() is not happy if it completes
without a connector/encoder registered. We will either have to force a probe
order somehow, or make the driver be happy to be loaded without a
connector/encoder which would then appear later.
3. Register space conflicts
Already found a couple of register conflicts between your dove and the MMP
platforms. Your LCD_SPU_ADV_REG is something completely different here.
The high bits of the DMA_CTRL0 register is used to select a clock. ??In the
dove and MMP2 case these bits are 31:30 but on MMP3 this is 31:29. Also, OLPC
uses this field to select the LCD clock as a clock source, but your driver
chooses another clock for cubox. So we need ways to represent all of these
differences.
4. Video memory
The driver at the moment requires an area of RAM as video memory, but this
must actually be memory that Linux does not regard as normal available RAM,
since ioremap() is called on it. I guess in your platform code you look at
how much RAM is available and cut out a chunk for graphics memory. Then when
communicating to the MM core how much RAM is available, you do not tell it
about the graphics memory?
I realise I'm talking to the ARM MM guru here, but... can we do better? The
decision to have to "cut out" the memory as above would have to be made during
early boot, before we know if we even have a graphics driver to come along and
make use of that memory. In my case I have similarly hacked our firmware to do
the "cut out" operation when finalizing the DT before booting the kernel.
I would have hoped in a world with CMA and things like that we could now do a
bit better. I tried creating a coherent DMA allocation in armada_drm_load() to
be used as video memory, but this failed later when armada_gem_linear_back()
tried to ioremap it (you probably don't need reminding that ioremap on memory
otherwise available as RAM fails, http://lwn.net/Articles/409689/).
I realise that I can avoid that particular ioremap since we already have the
virtual address available, but I am left wondering how this memory is
accessed by DRM/GEM in other contexts (e.g. when it wants to write image data
in there). If that uses ioremap() as well, then we are in trouble.
5. Output paths
This is something we'll have to address for HDMI output support on OLPC, which
is the lowest priority item on this list, lets get the inbuilt panel going
first!
The way I read your code is that up to 2 CRTC addresses can be defined in
platform data. Each one then gets passed to armada_drm_crtc_create() and the
address is used as a base for register accesses.
Does that mean that the register list in the big armada_hw.h enum is
essentially duplicated exactly? Almost as if the system has 2 separate display
controllers?
Your register list essentially starts at offset 0xc0. What can be found at
offsets below that address?
On MMP2/MMP3 the situation is a bit different. 3 output paths are supported
- two panel paths, and one TV path (which is HDMI - direct output from the
SoC, no separate encoder chip necessary).
These paths are closely related, probably
Packard Bell EasyNote LV need i915.invert_brightness=1
On Mon, Jun 24, 2013 at 11:57:43PM +0200, Petter Reinholdtsen wrote: > [Petter Reinholdtsen 2013-06-11] > > Sure. This is my first try, so I hope I got it right. > > Does the silence mean I got the kernel patch formatting right, or that > I should try again? Nah, silence just means that your patch fell through the crack while I've travelled around a bit. Thanks for poking, it's merged now for 3.11 (with cc: stable) to my drm-intel-next-queued branch. I've slightly bikeshedded the patch though for formatting. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 65958] GPU Lockup on Trinity 7500G
https://bugs.freedesktop.org/show_bug.cgi?id=65958 Mike Lothian changed: What|Removed |Added CC||mike at fireburn.co.uk --- Comment #3 from Mike Lothian --- I've not had another lockup since doing this -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130625/9d36d4fb/attachment.html>
[PATCH] drm/crtc-helper: don't disable disconnected outputs
On Tue, Jun 25, 2013 at 3:09 AM, Dave Airlie wrote: > On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter > wrote: >> This has originally been added in >> >> commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93 >> Author: Dave Airlie >> Date: Mon Aug 31 15:16:30 2009 +1000 >> >> drm/kms: add explicit encoder disable function and detach harder. >> >> I think it's the wrong thing to do for a few reasons: >> - It's policy in the kernel. Userspace gets hotplug events when an >> output disconnects, and it can inquire about all the routing that is >> already set up. If userspace wants to disable a disconnected output >> it can simply do so itself. >> - The reason for adding it given in the commit message was to improve >> use of shared encoders. But the disable_unused_functions call only >> happens after the modeset has been completed, so it won't help too >> much in making the modest succeed. >> - We (at least in drm/i915, but iirc all other drivers work the same) >> ensure that if the user accidentally yanks the cable and then >> replugs, the same configuration will keep on working without any >> userspace actions required. For most outputs that's the case by >> default, and DP can have the same semantics with a simple re-train >> handler fired off from the hpd replug event. This breaks it since if >> the user is unlucky and hits the mouse, resulting in a panning of >> e.g. the integrated panel that modeset might kill the accidentally >> yanked output. Which isn't too great. >> >> i915 has applied this behaviour change as part of the bit modeset >> review, thus far without resulting in an angry crowd with pitchforks: >> > > The reason is that i915 hardware is nearly impossible to ever set > something up that could trigger this on. You don't have > shared encoders in places that could affect this from what I can see. Actually we do have shared encoders, and on second consideration I guess we could hit this. We get away with it though since we don't really implement the connector modeset correctly for shared encoders: We simply pick what has been last detected as connected ... Of course that's a bit broken, and we have the bug reports to prove it (and since the modeset rework they include noisy dmesg spam from the checker about the inconsistencies even). I guess I should fix that up first ;-) > I know this will break the radeon card I have that I wrote this for > originally, where if you alternate hotplugging a tv-out > and vga that share the same encoder it won't work. I can probably drag > that card out of whatever hole if fell into, > but the given justifications have give me no confidence that this > patch just isn't reverting the original commit without > fixing anything else. > > I suspect I was testing hotplugging at fbcon not using X also. Oh, that makes a lot of sense. fbcon kinda wants an atomic modeset interface, but since it doesn't have one it expects the backend to paper over any intermediate inconsistencies. I guess we should fix that first. For userspace I still think that it makes much more sense to obey userspace's request and not silently kill outputs. We do that already if userspace steals the crtc. But that's something userspace can predict, wheras the exact connector->encoder relationship is more elusive. So I think the right thing would be to fail such a modeset. Anyway I agree that this patch needs a bit more prep work. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 12:46 PM, Russell King - ARM Linux wrote: >> > Note: the existing stuff does have the nice side effect of being able >> > to pass buffers which do not have a struct page * associated with them >> > through the dma_buf API - I think we can still preserve that by having >> > dma_buf provide a couple of new APIs to do the SG list map/sync/unmap, >> > but in any case we need to fix the existing API so that: >> > >> > dma_buf_map_attachment() becomes dma_buf_get_sg() >> > dma_buf_unmap_attachment() becomes dma_buf_put_sg() >> > >> > both getting rid of the DMA direction argument, and then we have four >> > new dma_buf calls: >> > >> > dma_buf_map_sg() >> > dma_buf_unmap_sg() >> > dma_buf_sync_sg_for_cpu() >> > dma_buf_sync_sg_for_device() >> > >> > which do the actual sg map/unmap via the DMA API *at the appropriate >> > time for DMA*. >> >> Hm, my idea was to just add a dma_buf_sync_attchment for the device side >> syncing, since the cpu access stuff is already bracketed with the >> begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap, >> but imo mmap support for dma_buf is a bit insane anyway, so I don't care >> too much about it. >> >> Since such dma mappings would be really longstanding in most cases anyway >> drivers could just map with BIDIRECTIONAL and do all the real flushing >> with the new sync stuff. > > Note that the DMA API debug doesn't allow you to change the direction > argument on an existing mapping (neither should it, again this is > documented in the DMA API stuff in Documentation/). This is where you > would need the complete set of four functions I mention above which > reflect the functionality of the DMA API. [Been travelling a bit, hence the delay.] Just a quick question on your assertion that we need all four functions: Since we already have begin/end_cpu_access functions (intention here was to allow the dma_buf exporter to ensure the memory is pinned, e.g. for swapable gem objects, but also allow cpu cache flushing if required) do we still need the sync_sg_for_cpu? At least with i915 as the exporter we currently hide the cflushing behind our begin_cpu_access callback. For device dma we currently punt on it due to lack of the dma_buf_sync_sg_for_device interface. Aside: I know that i915 doing the clflushing dance itself is a bit ugly, but thus far we've been the only guys on the x86 block with non-coherent dma. But it sounds like a bunch of other blocks on Atom SoCs have similar needs, so I guess it would make sense to move that into the dma layer. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
i915 mapping large (3MB) scatter list, hitting limits on certain IOMMUs that can only map contingous regions up to 2MB.
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote: > On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk > wrote: > > Hey, > > > > I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18 > > (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6 > > I found that i915 would halt with a > > > > [drm:intel_pipe_set_base] *ERROR* pin & fence failed > > [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = > > -28 > > > > after a bit of debugging (see patch below) I traced it down > > to the fact that the scatter list that is provided at the end has > > a huge (3MB) page. I am wondering if anybody knows what patch might > > have introduced it to grab such a large memory segment? > > > > The other thing I am wondering is if there are some fallbacks when the > > underlaying IOMMU can't deal with a request for contingous regions > > that are more than 2MB? > > There is no fallback afaik, but most gpu have their own mmu so they > don't really need contiguous iommu mapping, all they need is at the > very least being able to access all page of large object. Probably > something we should take a look at. They can see. It is just that the underlaying DMA was not capable of dealing with a large chunk of the scatter gather. > > Cheers, > Jerome > > > Thanks. > > > > From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001 > > From: Konrad Rzeszutek Wilk > > Date: Fri, 21 Jun 2013 11:17:55 -0400 > > Subject: [PATCH] dbug: print scatterlist. > > > > [ cut here ] > > WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 > > i915_gem_gtt_prepare_object+0x180/0x200() > > 10 but got 0 > > Modules linked in: > > crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel > > CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16 > > Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012 > > 0009 8801fa42d958 816e6d89 8801fa42d998 > > 8105d2b0 8801fa42d988 8801fb0f4d80 > > 81c172e0 8801fa76f000 000a 8801fa42d9f8 > > Call Trace: > > [] dump_stack+0x19/0x1b > > [] warn_slowpath_common+0x70/0xa0 > > [] warn_slowpath_fmt+0x46/0x50 > > [] i915_gem_gtt_prepare_object+0x180/0x200 > > [] i915_gem_object_pin+0x321/0x670 > > [] i915_gem_object_pin_to_display_plane+0x81/0x190 > > [] intel_pin_and_fence_fb_obj+0x85/0x1a0 > > [] intel_pipe_set_base+0x7c/0x220 > > [] intel_crtc_set_config+0x89e/0x990 > > [] drm_mode_set_config_internal+0x2e/0x60 > > [] drm_mode_setcrtc+0xfb/0x620 > > [] ? kmem_cache_alloc_trace+0x39/0x1f0 > > [] ? drm_vm_open_locked+0x57/0x90 > > [] drm_ioctl+0x549/0x680 > > [] ? drm_mode_setplane+0x3b0/0x3b0 > > [] do_vfs_ioctl+0x97/0x580 > > [] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30 > > [] ? file_has_perm+0x97/0xb0 > > [] SyS_ioctl+0x91/0xb0 > > [] tracesys+0xdd/0xe2 > > ---[ end trace 7b6adc5450d9a9e1 ]--- > > i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0 > > [0] virT:8801fd37c000 dma: 1fd37c000, size:4096 > > [1] virT:8801fd37b000 dma: 1fd37b000, size:4096 > > [2] virT:8801fd37a000 dma: 1fd37a000, size:4096 > > [3] virT:8801fd378000 dma: 1fd378000, size:4096 > > [4] virT:8801fd131000 dma: 1fd131000, size:4096 > > [5] virT:880200c36000 dma: 200c36000, size:4096 > > [6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632 > > [7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096 > > [8] virT:8801fd3c dma: 1fd3c, size:262144 > > [9] virT:8801f940 dma: 1f940, size:3866624 > > [drm] 3011: ret:-28 > > [drm] 3540: ret:-28 > > [drm] 3364: ret:-28 > > [drm:intel_pin_and_fence_fb_obj] *ERROR* > > i915_gem_object_pin_to_display_plane failed: -28 > > [drm:intel_pipe_set_base] *ERROR* pin & fence failed > > [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = > > -28 > > > > Signed-off-by: Konrad Rzeszutek Wilk > > --- > > drivers/gpu/drm/i915/i915_drv.c | 6 ++ > > drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +--- > > 2 files changed, 31 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index 8411942..141c6fb 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600); > > MODULE_PARM_DESC(use_coherent, > > "Use coherent DMA API calls (default: false)"); > > > > +int i915_sgl __read_mostly = 0; > > +module_param_named(sgl, i915_sgl, int, 0600); > > +MODULE_PARM_DESC(sgl, > > +"Print scatterlist SG's when DMA mapping them (default: > > false)"); > > + > > + > > static struct drm_driver driver; > > extern int intel_agp_enabled; > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > >
[PATCH] drm/crtc-helper: don't disable disconnected outputs
On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter wrote: > This has originally been added in > > commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93 > Author: Dave Airlie > Date: Mon Aug 31 15:16:30 2009 +1000 > > drm/kms: add explicit encoder disable function and detach harder. > > I think it's the wrong thing to do for a few reasons: > - It's policy in the kernel. Userspace gets hotplug events when an > output disconnects, and it can inquire about all the routing that is > already set up. If userspace wants to disable a disconnected output > it can simply do so itself. > - The reason for adding it given in the commit message was to improve > use of shared encoders. But the disable_unused_functions call only > happens after the modeset has been completed, so it won't help too > much in making the modest succeed. > - We (at least in drm/i915, but iirc all other drivers work the same) > ensure that if the user accidentally yanks the cable and then > replugs, the same configuration will keep on working without any > userspace actions required. For most outputs that's the case by > default, and DP can have the same semantics with a simple re-train > handler fired off from the hpd replug event. This breaks it since if > the user is unlucky and hits the mouse, resulting in a panning of > e.g. the integrated panel that modeset might kill the accidentally > yanked output. Which isn't too great. > > i915 has applied this behaviour change as part of the bit modeset > review, thus far without resulting in an angry crowd with pitchforks: > The reason is that i915 hardware is nearly impossible to ever set something up that could trigger this on. You don't have shared encoders in places that could affect this from what I can see. I know this will break the radeon card I have that I wrote this for originally, where if you alternate hotplugging a tv-out and vga that share the same encoder it won't work. I can probably drag that card out of whatever hole if fell into, but the given justifications have give me no confidence that this patch just isn't reverting the original commit without fixing anything else. I suspect I was testing hotplugging at fbcon not using X also. Dave.
i915 mapping large (3MB) scatter list, hitting limits on certain IOMMUs that can only map contingous regions up to 2MB.
On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk wrote: > Hey, > > I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18 > (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6 > I found that i915 would halt with a > > [drm:intel_pipe_set_base] *ERROR* pin & fence failed > [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 > > after a bit of debugging (see patch below) I traced it down > to the fact that the scatter list that is provided at the end has > a huge (3MB) page. I am wondering if anybody knows what patch might > have introduced it to grab such a large memory segment? > > The other thing I am wondering is if there are some fallbacks when the > underlaying IOMMU can't deal with a request for contingous regions > that are more than 2MB? There is no fallback afaik, but most gpu have their own mmu so they don't really need contiguous iommu mapping, all they need is at the very least being able to access all page of large object. Probably something we should take a look at. Cheers, Jerome > Thanks. > > From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001 > From: Konrad Rzeszutek Wilk > Date: Fri, 21 Jun 2013 11:17:55 -0400 > Subject: [PATCH] dbug: print scatterlist. > > [ cut here ] > WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 > i915_gem_gtt_prepare_object+0x180/0x200() > 10 but got 0 > Modules linked in: > crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel > CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16 > Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012 > 0009 8801fa42d958 816e6d89 8801fa42d998 > 8105d2b0 8801fa42d988 8801fb0f4d80 > 81c172e0 8801fa76f000 000a 8801fa42d9f8 > Call Trace: > [] dump_stack+0x19/0x1b > [] warn_slowpath_common+0x70/0xa0 > [] warn_slowpath_fmt+0x46/0x50 > [] i915_gem_gtt_prepare_object+0x180/0x200 > [] i915_gem_object_pin+0x321/0x670 > [] i915_gem_object_pin_to_display_plane+0x81/0x190 > [] intel_pin_and_fence_fb_obj+0x85/0x1a0 > [] intel_pipe_set_base+0x7c/0x220 > [] intel_crtc_set_config+0x89e/0x990 > [] drm_mode_set_config_internal+0x2e/0x60 > [] drm_mode_setcrtc+0xfb/0x620 > [] ? kmem_cache_alloc_trace+0x39/0x1f0 > [] ? drm_vm_open_locked+0x57/0x90 > [] drm_ioctl+0x549/0x680 > [] ? drm_mode_setplane+0x3b0/0x3b0 > [] do_vfs_ioctl+0x97/0x580 > [] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30 > [] ? file_has_perm+0x97/0xb0 > [] SyS_ioctl+0x91/0xb0 > [] tracesys+0xdd/0xe2 > ---[ end trace 7b6adc5450d9a9e1 ]--- > i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0 > [0] virT:8801fd37c000 dma: 1fd37c000, size:4096 > [1] virT:8801fd37b000 dma: 1fd37b000, size:4096 > [2] virT:8801fd37a000 dma: 1fd37a000, size:4096 > [3] virT:8801fd378000 dma: 1fd378000, size:4096 > [4] virT:8801fd131000 dma: 1fd131000, size:4096 > [5] virT:880200c36000 dma: 200c36000, size:4096 > [6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632 > [7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096 > [8] virT:8801fd3c dma: 1fd3c, size:262144 > [9] virT:8801f940 dma: 1f940, size:3866624 > [drm] 3011: ret:-28 > [drm] 3540: ret:-28 > [drm] 3364: ret:-28 > [drm:intel_pin_and_fence_fb_obj] *ERROR* i915_gem_object_pin_to_display_plane > failed: -28 > [drm:intel_pipe_set_base] *ERROR* pin & fence failed > [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 > > Signed-off-by: Konrad Rzeszutek Wilk > --- > drivers/gpu/drm/i915/i915_drv.c | 6 ++ > drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +--- > 2 files changed, 31 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 8411942..141c6fb 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600); > MODULE_PARM_DESC(use_coherent, > "Use coherent DMA API calls (default: false)"); > > +int i915_sgl __read_mostly = 0; > +module_param_named(sgl, i915_sgl, int, 0600); > +MODULE_PARM_DESC(sgl, > +"Print scatterlist SG's when DMA mapping them (default: > false)"); > + > + > static struct drm_driver driver; > extern int intel_agp_enabled; > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index acb3b3f..292179c 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -28,6 +28,7 @@ > #include "i915_trace.h" > #include "intel_drv.h" > > +extern int use_coherent; > typedef uint32_t gen6_gtt_pte_t; > > /* PPGTT stuff */ > @@ -403,15 +404,36 @@ void i915_gem_restore_gtt_mappings(struct drm_device > *dev) > > i915_gem_chipset_flush(dev); > } > - >
[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae wrote: > 2013/6/25 Rob Clark : >> On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote: that should be the role of kernel memory management which of course needs synchronization btw A and B. But in no case this should be done using dma-buf. dma-buf is for sharing content btw different devices not sharing resources. >>> >>> hmm, is that true? And are you sure? Then how do you think about >>> reservation? the reservation also uses dma-buf with same reason as long as I >>> know: actually, we use reservation to use dma-buf. As you may know, a >>> reservation object is allocated and initialized when a buffer object is >>> exported to a dma buf. >> >> no, this is why the reservation object can be passed in when you >> construction the dmabuf. > > Right, that way, we could use dma buf for buffer synchronization. I > just wanted to ask for why Jerome said that "dma-buf is for sharing > content btw different devices not sharing resources". >From memory, the motivation of dma-buf was to done for few use case, among them webcam capturing frame into a buffer and having gpu using it directly without memcpy, or one big gpu rendering a scene into a buffer that is then use by low power gpu for display ie it was done to allow different device to operate on same data using same backing memory. AFAICT you seem to want to use dma-buf to create scratch buffer, ie a process needs to use X amount of memory for an operation, it can release|free this memory once its done and a process B can the use this X memory for its own operation discarding content of process A. I presume that next frame would have the sequence repeat, process A do something, then process B does its thing. So to me it sounds like you want to implement global scratch buffer using the dmabuf API and that sounds bad to me. I know most closed driver have several pool of memory, long lived object, short lived object and scratch space, then user space allocate from one of this pool and there is synchronization done by driver using driver specific API to reclaim memory. Of course this work nicely if you only talking about one logic block or at very least hw that have one memory controller. Now if you are thinking of doing scratch buffer for several different device and share the memory among then you need to be aware of security implication, most obvious being that you don't want process B being able to read process A scratch memory. I know the argument about it being graphic but one day this might become gpu code and it might be able to insert jump to malicious gpu code. Cheers, Jerome
[PATCH] drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.
On Tue, Jun 25, 2013 at 9:18 AM, Konrad Rzeszutek Wilk
wrote:
> Dave Airlie wrote:
>
>>On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
>> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk
>>wrote:
>> > Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
>> > ("drm/i915: create compact dma scatter lists for gem objects")
>>makes
>> > certain assumptions about the under laying DMA API that are not
>>always
>> > correct.
>> >
>> > On a ThinkPad X230 with an Intel HD 4000 with Xen during the
>>bootup
>> > I see:
>> >
>> > [drm:intel_pipe_set_base] *ERROR* pin & fence failed
>> > [drm:intel_crtc_set_config] *ERROR* failed to set mode on
>>[CRTC:3], err = -28
>> >
>> > Bit of debugging traced it down to dma_map_sg failing (in
>> > i915_gem_gtt_prepare_object) as some of the SG entries were
>>huge (3MB).
>> >
>> > That unfortunately are sizes that the SWIOTLB is incapable of
>>handling -
>> > the maximum it can handle is a an entry of 512KB of virtual
>>contiguous
>> > memory for its bounce buffer. (See IO_TLB_SEGSIZE).
>> >
>> > Previous to the above mention git commit the SG entries were of
>>4KB, and
>> > the code introduced by above git commit squashed the CPU
>>contiguous PFNs
>> > in one big virtual address provided to DMA API.
>> >
>> > This patch is a simple semi-revert - were we emulate the old
>>behavior
>> > if we detect that SWIOTLB is online. If it is not online then
>>we continue
>> > on with the new compact scatter gather mechanism.
>> >
>> > An alternative solution would be for the the '.get_pages' and
>>the
>> > i915_gem_gtt_prepare_object to retry with smaller max gap of
>>the
>> > amount of PFNs that can be combined together - but with this
>>issue
>> > discovered during rc7 that might be too risky.
>> >
>> > Reported-and-Tested-by: Konrad Rzeszutek Wilk
>>
>> > CC: Chris Wilson
>> > CC: Imre Deak
>> > CC: Daniel Vetter
>> > CC: David Airlie
>> > CC:
>> > Signed-off-by: Konrad Rzeszutek Wilk
>>
>> Two things:
>
> Hey Daniel,
>
>>
>> - SWIOTLB usage should seriously blow up all over the place in
>>drm/i915.
>> We really rely on the everywhere else true fact that the pages
>>and their
>> dma mapping point at the same backing storage.
>
> It works. As in, it seems to work for just a normal desktop user.
>>I don't
> see much of dma_sync_* sprinkled around the drm/i915 so I would
>>think that
> there are some issues would be hit as well - but at the first
>>glance
> when using it on a laptop it looks OK.
Yeah, we have a pretty serious case of "roll our own coherency
>>stuff".
The biggest reason is that for a long time i915.ko didn't care one
>>bit
about iommus, and the thing we care about (flushing cpu caches for
dma) isn't supported on x86 since x86 every dma is coherent (well,
>>not
quite, but we don't have support for it). I think longer-term it
>>would
make sense to move the clfushing we're doing into the dma layer.
>> - How is this solved elsewhere when constructing sg tables? Or
>>are we
>> really the only guys who try to construct such big sg entries?
>>I
>> expected somewhat that the dma mapping backed would fill in the
>>segment
>> limits accordingly, but I haven't found anything really on a
>>quick
>> search.
>
> The TTM layer (so radeon, nouveau) uses pci_alloc_coherent which
>>will
> construct the dma mapped pages. That allows it to construct
>>"SWIOTLB-approved"
> pages that won't need to go through dma_map/dma_unmap as they are
> already mapped and ready to go.
>
> Coming back to your question - I think that i915 is the one that
>>I've
> encountered.
That's a bit surprising. With dma_buf graphics people will use sg
tables much more (there's even a nice sg_alloc_table_from_pages
>>helper
to construct them), and those sg tables tend to have large segments.
>>I
guess we need some more generic solution here ...
>>>
>>> Yes. I don't grok the full picture yet so I am not sure how to help
>>with
>>> this right now. Is there a roadmap or Wiki on how this was
>>envisioned?
For now I guess we can live with your CONFIG_SWIOTLB hack.
-Daniel
>>>
>>> OK, I read that as an Ack-ed-by. Should I send the patch to Dave
>>Airlie
>>> in a GIT PULL or some other way to make it on the v3.10-rc7 train?
>>
>>I don't like this at all, I'll accept the patch on the condition you
>>investigate further :-)
>>
>>If you are using swiotlb on i915 things
[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae wrote: >> that >> should be the role of kernel memory management which of course needs >> synchronization btw A and B. But in no case this should be done using >> dma-buf. dma-buf is for sharing content btw different devices not >> sharing resources. >> > > hmm, is that true? And are you sure? Then how do you think about > reservation? the reservation also uses dma-buf with same reason as long as I > know: actually, we use reservation to use dma-buf. As you may know, a > reservation object is allocated and initialized when a buffer object is > exported to a dma buf. no, this is why the reservation object can be passed in when you construction the dmabuf. The fallback is for dmabuf to create it's own, for compatibility and to make life easier for simple devices with few buffers... but I think pretty much all drm drivers would embed the reservation object in the gem buffer and pass it in when the dmabuf is created. It is pretty much imperative that synchronization works independently of dmabuf, you really don't want to have two different cases to deal with in your driver, one for synchronizing non-exported objects, and one for synchronizing dmabuf objects. BR, -R
[PATCH] drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.
On Tue, Jun 25, 2013 at 4:34 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jun 24, 2013 at 08:26:18PM +0200, Daniel Vetter wrote:
>> On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
>> >> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wrote:
>> >> > Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
>> >> > ("drm/i915: create compact dma scatter lists for gem objects") makes
>> >> > certain assumptions about the under laying DMA API that are not always
>> >> > correct.
>> >> >
>> >> > On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup
>> >> > I see:
>> >> >
>> >> > [drm:intel_pipe_set_base] *ERROR* pin & fence failed
>> >> > [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err
>> >> > = -28
>> >> >
>> >> > Bit of debugging traced it down to dma_map_sg failing (in
>> >> > i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB).
>> >> >
>> >> > That unfortunately are sizes that the SWIOTLB is incapable of handling -
>> >> > the maximum it can handle is a an entry of 512KB of virtual contiguous
>> >> > memory for its bounce buffer. (See IO_TLB_SEGSIZE).
>> >> >
>> >> > Previous to the above mention git commit the SG entries were of 4KB, and
>> >> > the code introduced by above git commit squashed the CPU contiguous PFNs
>> >> > in one big virtual address provided to DMA API.
>> >> >
>> >> > This patch is a simple semi-revert - were we emulate the old behavior
>> >> > if we detect that SWIOTLB is online. If it is not online then we
>> >> > continue
>> >> > on with the new compact scatter gather mechanism.
>> >> >
>> >> > An alternative solution would be for the the '.get_pages' and the
>> >> > i915_gem_gtt_prepare_object to retry with smaller max gap of the
>> >> > amount of PFNs that can be combined together - but with this issue
>> >> > discovered during rc7 that might be too risky.
>> >> >
>> >> > Reported-and-Tested-by: Konrad Rzeszutek Wilk > >> > oracle.com>
>> >> > CC: Chris Wilson
>> >> > CC: Imre Deak
>> >> > CC: Daniel Vetter
>> >> > CC: David Airlie
>> >> > CC:
>> >> > Signed-off-by: Konrad Rzeszutek Wilk
>> >>
>> >> Two things:
>> >
>> > Hey Daniel,
>> >
>> >>
>> >> - SWIOTLB usage should seriously blow up all over the place in drm/i915.
>> >> We really rely on the everywhere else true fact that the pages and their
>> >> dma mapping point at the same backing storage.
>> >
>> > It works. As in, it seems to work for just a normal desktop user. I don't
>> > see much of dma_sync_* sprinkled around the drm/i915 so I would think that
>> > there are some issues would be hit as well - but at the first glance
>> > when using it on a laptop it looks OK.
>>
>> Yeah, we have a pretty serious case of "roll our own coherency stuff".
>> The biggest reason is that for a long time i915.ko didn't care one bit
>> about iommus, and the thing we care about (flushing cpu caches for
>> dma) isn't supported on x86 since x86 every dma is coherent (well, not
>> quite, but we don't have support for it). I think longer-term it would
>> make sense to move the clfushing we're doing into the dma layer.
>>
>> >> - How is this solved elsewhere when constructing sg tables? Or are we
>> >> really the only guys who try to construct such big sg entries? I
>> >> expected somewhat that the dma mapping backed would fill in the segment
>> >> limits accordingly, but I haven't found anything really on a quick
>> >> search.
>> >
>> > The TTM layer (so radeon, nouveau) uses pci_alloc_coherent which will
>> > construct the dma mapped pages. That allows it to construct
>> > "SWIOTLB-approved"
>> > pages that won't need to go through dma_map/dma_unmap as they are
>> > already mapped and ready to go.
>> >
>> > Coming back to your question - I think that i915 is the one that I've
>> > encountered.
>>
>> That's a bit surprising. With dma_buf graphics people will use sg
>> tables much more (there's even a nice sg_alloc_table_from_pages helper
>> to construct them), and those sg tables tend to have large segments. I
>> guess we need some more generic solution here ...
>
> Yes. I don't grok the full picture yet so I am not sure how to help with
> this right now. Is there a roadmap or Wiki on how this was envisioned?
>>
>> For now I guess we can live with your CONFIG_SWIOTLB hack.
>> -Daniel
>
> OK, I read that as an Ack-ed-by. Should I send the patch to Dave Airlie
> in a GIT PULL or some other way to make it on the v3.10-rc7 train?
I don't like this at all, I'll accept the patch on the condition you
investigate further :-)
If you are using swiotlb on i915 things should break, I know I've
investigated problems before where swiotlb was being incorrectly used
due to page masks or other issues. Shouldn't you be passing through
using the real iommu?
Dave.
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/24/13 13:28, Rahul Sharma wrote: [...] > I never got these patches. I'm not subscribed to devicetree-devel or > linux-samsung so I only got two replies to patch #0, but none of the > code. Can you or Rajul resend? > Sure mike. >>> >>> Acked-by: Mike Turquette >>> Applied with Mike's ack. Thanks, - Kukjin
[RFC 6/6] drm: nouveau: kick out firmware drivers during probe
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 383f4e6..418867f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -233,13 +233,11 @@ nouveau_accel_init(struct nouveau_drm *drm)
nouveau_bo_move_init(drm);
}
-static int nouveau_drm_probe(struct pci_dev *pdev,
-const struct pci_device_id *pent)
+static int nouveau_kick_out_firmware(struct drm_device *dev)
{
- struct nouveau_device *device;
struct apertures_struct *aper;
bool boot = false;
- int ret;
+ struct pci_dev *pdev = dev->pdev;
/* remove conflicting drivers (vesafb, efifb etc) */
aper = alloc_apertures(3);
@@ -265,8 +263,18 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
#ifdef CONFIG_X86
boot = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
#endif
- remove_conflicting_framebuffers(aper, "nouveaufb", boot);
- kfree(aper);
+
+ drm_kick_out_firmware(aper, boot);
+ dev->apertures = aper;
+ dev->apert_boot = boot;
+ return 0;
+}
+
+static int nouveau_drm_probe(struct pci_dev *pdev,
+const struct pci_device_id *pent)
+{
+ struct nouveau_device *device;
+ int ret;
ret = nouveau_device_create(pdev, nouveau_name(pdev), pci_name(pdev),
nouveau_config, nouveau_debug, );
@@ -294,9 +302,13 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
struct nouveau_drm *drm;
int ret;
- ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**));
+ ret = nouveau_kick_out_firmware(dev);
if (ret)
return ret;
+
+ ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**));
+ if (ret)
+ goto fail_apert;
lockdep_set_class(>client.mutex, _client_lock_class_key);
dev->dev_private = drm;
@@ -392,6 +404,9 @@ fail_ttm:
nouveau_vga_fini(drm);
fail_device:
nouveau_cli_destroy(>client);
+fail_apert:
+ kfree(dev->apertures);
+ dev->apertures = NULL;
return ret;
}
--
1.8.3.1
[RFC 5/6] drm: add helpers to kick out firmware drivers
If we load a real hardware DRM driver, we want all firmware drivers to be
unloaded. Historically, this was done via
remove_conflicting_framebuffers(), but for DRM drivers (like SimpleDRM) we
need a new way.
This patch introduces DRIVER_FIRMWARE and DRM apertures to provide a quite
similar way to kick out firmware DRM drivers. Additionally, unlike the
fbdev equivalent, DRM firmware drivers can now query the system whether a
real hardware driver is already loaded and prevent loading themselves.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 1 +
drivers/gpu/drm/drm_platform.c | 1 +
drivers/gpu/drm/drm_stub.c | 107 +
drivers/gpu/drm/drm_usb.c | 1 +
drivers/gpu/drm/simpledrm/simpledrm.h | 1 +
drivers/gpu/drm/simpledrm/simpledrm_drv.c | 3 +-
drivers/gpu/drm/simpledrm/simpledrm_main.c | 34 +
include/drm/drmP.h | 26 +++
8 files changed, 173 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 14194b6..4dcb2a4 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -366,6 +366,7 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
}
list_add_tail(>driver_item, >device_list);
+ list_add_tail(>global_item, _devlist);
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor, driver->patchlevel,
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index b8a282e..94923c8 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -88,6 +88,7 @@ int drm_get_platform_dev(struct platform_device *platdev,
}
list_add_tail(>driver_item, >device_list);
+ list_add_tail(>global_item, _devlist);
mutex_unlock(_global_mutex);
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 16f3ec5..a433ab0 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -46,6 +46,9 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */
EXPORT_SYMBOL(drm_timestamp_precision);
+LIST_HEAD(drm_devlist);/* device list; protected by global
lock */
+EXPORT_SYMBOL(drm_devlist);
+
/*
* Default to use monotonic timestamps for wait-for-vblank and page-flip
* complete events.
@@ -484,7 +487,9 @@ void drm_put_dev(struct drm_device *dev)
drm_put_minor(>primary);
+ list_del(>global_item);
list_del(>driver_item);
+ kfree(dev->apertures);
kfree(dev->devname);
kfree(dev);
}
@@ -507,3 +512,105 @@ void drm_unplug_dev(struct drm_device *dev)
mutex_unlock(_global_mutex);
}
EXPORT_SYMBOL(drm_unplug_dev);
+
+void drm_unplug_dev_locked(struct drm_device *dev)
+{
+ /* for a USB device */
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ drm_unplug_minor(dev->control);
+ drm_unplug_minor(dev->primary);
+
+ drm_device_set_unplugged(dev);
+
+ /* TODO: schedule drm_put_dev if open_count == 0 */
+}
+EXPORT_SYMBOL(drm_unplug_dev_locked);
+
+#define VGA_FB_PHYS 0xa
+
+static bool apertures_overlap(struct drm_device *dev,
+ struct apertures_struct *ap,
+ bool boot)
+{
+ unsigned int i, j;
+ struct aperture *a, *b;
+
+ if (!dev->apertures)
+ return false;
+
+ for (i = 0; i < dev->apertures->count; ++i) {
+ a = >apertures->ranges[i];
+
+ if (boot && a->base == VGA_FB_PHYS)
+ return true;
+
+ for (j = 0; ap && j < ap->count; ++j) {
+ b = >ranges[j];
+ if (a->base <= b->base && a->base + a->size > b->base)
+ return true;
+ if (b->base <= a->base && b->base + b->size > a->base)
+ return true;
+ }
+ }
+
+ return false;
+}
+
+/**
+ * Kick out firmware
+ *
+ * Virtually unplug any firmware graphics devices which overlap the given
+ * region. This must be called with the global-drm-mutex locked.
+ * This calls the kick_out_firmware() callback on any firmware DRM driver and
+ * after that remove_conflicting_framebuffers() to remove legacy fbdev
+ * framebuffers.
+ */
+void drm_kick_out_firmware(struct apertures_struct *ap, bool boot)
+{
+ struct drm_device *dev;
+
+ list_for_each_entry(dev, _devlist, global_item) {
+ if (!drm_core_check_feature(dev, DRIVER_FIRMWARE))
+ continue;
+ if (apertures_overlap(dev, ap, boot)) {
+ DRM_INFO("kicking out firmware %s\n",
+dev->devname);
+
[RFC 4/6] drm: simpledrm: add fbdev fallback support
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
fbdev deletion is quite buggy. A unregister_framebuffer() call followed by
a printk() causes NULL-derefs in hide_cursor() and other places in the VT
layer. Hence, we leak the fbdev device currently to make the VT layer
happy. This needs to be fixed soon! Otherwise, we need a "depends !VT"
line for SimpleDRM.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Kconfig | 11 ++
drivers/gpu/drm/simpledrm/Makefile | 4 +
drivers/gpu/drm/simpledrm/simpledrm.h | 22
drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 180
drivers/gpu/drm/simpledrm/simpledrm_main.c | 2 +
5 files changed, 219 insertions(+)
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
diff --git a/drivers/gpu/drm/simpledrm/Kconfig
b/drivers/gpu/drm/simpledrm/Kconfig
index 1d4f38e..7936211 100644
--- a/drivers/gpu/drm/simpledrm/Kconfig
+++ b/drivers/gpu/drm/simpledrm/Kconfig
@@ -12,7 +12,18 @@ config DRM_SIMPLEDRM
SimpleDRM supports: "simple-framebuffer" DeviceTree objects, x86 VESA
BIOS Extensions (VBE), EFI framebuffers
+ If fbdev support is enabled, this driver will also provide an fbdev
+ compatibility layer.
+
If unsure, say Y.
To compile this driver as a module, choose M here: the
module will be called simpledrm.
+
+config DRM_SIMPLEDRM_FBDEV
+ bool
+ depends on DRM_SIMPLEDRM && FB
+ default y
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
diff --git a/drivers/gpu/drm/simpledrm/Makefile
b/drivers/gpu/drm/simpledrm/Makefile
index 2d474a5..e77bd9b 100644
--- a/drivers/gpu/drm/simpledrm/Makefile
+++ b/drivers/gpu/drm/simpledrm/Makefile
@@ -2,4 +2,8 @@ ccflags-y := -Iinclude/drm
simpledrm-y := simpledrm_drv.o simpledrm_main.o simpledrm_mem.o
+ifdef CONFIG_DRM_SIMPLEDRM_FBDEV
+ simpledrm-y += simpledrm_fbdev.o
+endif
+
obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h
b/drivers/gpu/drm/simpledrm/simpledrm.h
index 279d847..cfd99f9 100644
--- a/drivers/gpu/drm/simpledrm/simpledrm.h
+++ b/drivers/gpu/drm/simpledrm/simpledrm.h
@@ -48,6 +48,9 @@ struct sdrm_device {
struct drm_encoder enc;
struct drm_connector conn;
struct drm_display_mode *mode;
+
+ /* fbdev */
+ struct fb_info *fbdev;
};
int sdrm_drm_load(struct drm_device *ddev, unsigned long flags);
@@ -88,4 +91,23 @@ struct sdrm_framebuffer {
#define to_sdrm_fb(x) container_of(x, struct sdrm_framebuffer, base)
+/* simpledrm fbdev helpers */
+
+#ifdef CONFIG_DRM_SIMPLEDRM_FBDEV
+
+void sdrm_fbdev_init(struct sdrm_device *sdrm);
+void sdrm_fbdev_cleanup(struct sdrm_device *sdrm);
+
+#else /* CONFIG_DRM_SIMPLEDRM_FBDEV */
+
+static inline void sdrm_fbdev_init(struct sdrm_device *sdrm)
+{
+}
+
+static inline void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
+{
+}
+
+#endif /* CONFIG_DRM_SIMPLEDRM_FBDEV */
+
#endif /* SDRM_DRV_H */
diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
new file mode 100644
index 000..40a2696
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
@@ -0,0 +1,180 @@
+/*
+ * SimpleDRM firmware framebuffer driver
+ * Copyright (c) 2012-2013 David Herrmann
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+/*
+ * fbdev compatibility layer
+ * We provide a basic fbdev device for the same framebuffer that is used for
+ * the pseudo CRTC.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "simpledrm.h"
+
+struct sdrm_fbdev {
+ u32 palette[256];
+};
+
+static int sdrm_fbdev_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ /*
+* Set a single color register. The values supplied are
+* already rounded down to the hardware's capabilities
+* (according to the entries in the `var' structure). Return != 0 for
+* invalid regno.
+*/
+
+ if (regno >= info->cmap.len)
+ return 1;
+ if (info->var.bits_per_pixel == 8)
+ return -EINVAL;
+ if (regno >= 16)
+ return 0;
+
+ switch (info->var.bits_per_pixel) {
+ case 16:
+ if (info->var.red.offset == 10) {
+ /* 1:5:5:5 */
+ ((u32*) (info->pseudo_palette))[regno] =
+ ((red & 0xf800) >> 1) |
+ ((green & 0xf800) >> 6) |
+
[RFC 3/6] drm: add SimpleDRM driver
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create one dumb-buffer and attach it to the CRTC. Only if
the buffer is destroyed, a new buffer can be created. The buffer is
directly mapped into user-space, so we have only resources for a single
buffer. Otherwise, shadow buffers plus damage-request would be needed.
Signed-off-by: David Herrmann
---
MAINTAINERS| 8 +
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/simpledrm/Kconfig | 18 ++
drivers/gpu/drm/simpledrm/Makefile | 5 +
drivers/gpu/drm/simpledrm/simpledrm.h | 91
drivers/gpu/drm/simpledrm/simpledrm_drv.c | 230
drivers/gpu/drm/simpledrm/simpledrm_main.c | 330 +
drivers/gpu/drm/simpledrm/simpledrm_mem.c | 254 ++
9 files changed, 939 insertions(+)
create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
create mode 100644 drivers/gpu/drm/simpledrm/Makefile
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5be702c..0f651845 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7305,6 +7305,14 @@ S: Odd Fixes
F: drivers/media/platform/sh_vou.c
F: include/media/sh_vou.h
+SIMPLE DRM DRIVER
+M: David Herrmann
+L: dri-devel at lists.freedesktop.org
+T: git git://people.freedesktop.org/~dvdhrm/linux
+S: Maintained
+F: drivers/gpu/drm/simpledrm
+F: include/linux/platform_data/simpledrm.h
+
SIMPLE FIRMWARE INTERFACE (SFI)
M: Len Brown
L: sfi-devel at simplefirmware.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b16c50e..b3ccef6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -220,3 +220,5 @@ source "drivers/gpu/drm/omapdrm/Kconfig"
source "drivers/gpu/drm/tilcdc/Kconfig"
source "drivers/gpu/drm/qxl/Kconfig"
+
+source "drivers/gpu/drm/simpledrm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1c9f2439..59c424d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,4 +52,5 @@ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
obj-$(CONFIG_DRM_OMAP) += omapdrm/
obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
+obj-$(CONFIG_DRM_SIMPLEDRM) += simpledrm/
obj-y += i2c/
diff --git a/drivers/gpu/drm/simpledrm/Kconfig
b/drivers/gpu/drm/simpledrm/Kconfig
new file mode 100644
index 000..1d4f38e
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/Kconfig
@@ -0,0 +1,18 @@
+config DRM_SIMPLEDRM
+ tristate "Simple firmware framebuffer DRM driver"
+ depends on DRM && !FB_SIMPLE
+ help
+ SimpleDRM can run on all systems with pre-initialized graphics
+ hardware. It uses a framebuffer that was initialized during
+ firmware boot. No page-flipping, modesetting or other advanced
+ features are available. However, other DRM drivers can be loaded
+ later and take over from SimpleDRM if they provide real hardware
+ support.
+
+ SimpleDRM supports: "simple-framebuffer" DeviceTree objects, x86 VESA
+ BIOS Extensions (VBE), EFI framebuffers
+
+ If unsure, say Y.
+
+ To compile this driver as a module, choose M here: the
+ module will be called simpledrm.
diff --git a/drivers/gpu/drm/simpledrm/Makefile
b/drivers/gpu/drm/simpledrm/Makefile
new file mode 100644
index 000..2d474a5
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/Makefile
@@ -0,0 +1,5 @@
+ccflags-y := -Iinclude/drm
+
+simpledrm-y := simpledrm_drv.o simpledrm_main.o simpledrm_mem.o
+
+obj-$(CONFIG_DRM_SIMPLEDRM) := simpledrm.o
diff --git a/drivers/gpu/drm/simpledrm/simpledrm.h
b/drivers/gpu/drm/simpledrm/simpledrm.h
new file mode 100644
index 000..279d847
--- /dev/null
+++ b/drivers/gpu/drm/simpledrm/simpledrm.h
@@ -0,0 +1,91 @@
+/*
+ * SimpleDRM firmware framebuffer driver
+ * Copyright (c) 2012-2013 David Herrmann
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#ifndef SDRM_DRV_H
+#define SDRM_DRV_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sdrm_device;
+struct sdrm_gem_object;
+struct sdrm_framebuffer;
+
+/* simpledrm devices */
+
+struct sdrm_device {
+ struct drm_device *ddev;
+
+ /* framebuffer information */
+ const struct simplefb_format
[RFC 2/6] x86: provide platform-devices for boot-framebuffers
The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on x86 causes troubles when loading multiple fbdev drivers. The global "struct screen_info" does not provide any state-tracking about which drivers use the FBs. request_mem_region() theoretically works, but unfortunately vesafb/efifb ignore it due to quirks for broken boards. Avoid this by creating a "platform-framebuffer" device with a pointer to the "struct screen_info" as platform-data. Drivers can now create platform-drivers and the driver-core will refuse multiple drivers being active simultaneously. We keep the screen_info available for backwards-compatibility. Drivers can be converted in follow-up patches. Apart from "platform-framebuffer" devices, this also introduces a compatibility option for "simple-framebuffer" drivers which recently got introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we try to match the screen_info against a simple-framebuffer supported format. If we succeed, we create a "simple-framebuffer" device instead of a platform-framebuffer. This allows to reuse the simplefb.c driver across architectures and also to introduce a SimpleDRM driver. There is no need to have vesafb.c, efifb.c, simplefb.c and more just to have architecture specific quirks in their setup-routines. Instead, we now move the architecture specific quirks into x86-setup and provide a generic simple-framebuffer. For backwards-compatibility (if strange formats are used), we still allow vesafb/efifb to be loaded simultaneously and pick up all remaining devices. Signed-off-by: David Herrmann --- arch/x86/Kconfig | 18 ++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/sysfb.c | 157 +++ 3 files changed, 176 insertions(+) create mode 100644 arch/x86/kernel/sysfb.c diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fe120da..8eb06b5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2255,6 +2255,24 @@ config RAPIDIO source "drivers/rapidio/Kconfig" +config X86_SYSFB + bool "Mark VGA/VBE/EFI FB as generic system framebuffer" + help + Firmwares often provide initial graphics framebuffers so the BIOS, + bootloader or kernel can show basic video-output during boot for + user-guidance and debugging. Historically, x86 used the VESA BIOS + Extensions and EFI-framebuffers for this, which are mostly limited + to x86. However, a generic system-framebuffer initialization emerged + recently on some non-x86 architectures. + This option, if enabled, marks VGA/VBE/EFI framebuffers as generic + framebuffers so the new generic system-framebuffer drivers can be + used on x86. + + This breaks any x86-only driver like efifb, vesafb, uvesafb, which + will not work if this is selected. + + If unsure, say N. + endmenu diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 7bd3bd3..1e1005a 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -100,6 +100,7 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o obj-$(CONFIG_SWIOTLB) += pci-swiotlb.o obj-$(CONFIG_OF) += devicetree.o obj-$(CONFIG_UPROBES) += uprobes.o +obj-y += sysfb.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o diff --git a/arch/x86/kernel/sysfb.c b/arch/x86/kernel/sysfb.c new file mode 100644 index 000..8272958 --- /dev/null +++ b/arch/x86/kernel/sysfb.c @@ -0,0 +1,157 @@ +/* + * Generic System Framebuffers on x86 + * Copyright (c) 2012-2013 David Herrmann + */ + +/* + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + */ + +/* + * Simple-Framebuffer support for x86 systems + * Create a platform-device for any available boot framebuffer. The + * simple-framebuffer platform device is already available on DT systems, so + * this module parses the global "screen_info" object and creates a suitable + * platform device compatible with the "simple-framebuffer" DT object. If + * the framebuffer is incompatible, we instead create a "platform-framebuffer" + * device and pass the screen_info as platform_data. This allows legacy drivers + * to pick these devices up without messing with simple-framebuffer drivers. + * + * If CONFIG_X86_SYSFB is not selected, we never register "simple-framebuffer" + * platform devices, but only use "platform-framebuffer" devices for + * backwards compatibility. + * + * TODO: We set the dev_id field of all platform-devices to 0. This allows + * other x86 OF/DT parsers to create such devices, too. However, they must + * start at offset 1 for this to work. + */ + +#include +#include +#include +#include +#include +#include +#include +
[RFC 1/6] fbdev: simplefb: add init through platform_data
If we create proper platform-devices in x86 boot-code, we can use simplefb
for VBE or EFI framebuffers, too. However, there is normally no OF support
so we introduce a platform_data object so x86 boot-code can pass the
paramaters via plain old platform-data.
This also removes the OF dependency as it is not needed. The headers
provide proper dummies for the case OF is disabled.
Furthermore, we move the FORMAT-definitions to the common platform header
so initialization code can use it to transform "struct screen_info" to
the right format-name.
Signed-off-by: David Herrmann
---
drivers/video/Kconfig | 5 ++--
drivers/video/simplefb.c | 45 +-
include/linux/platform_data/simplefb.h | 40 ++
3 files changed, 76 insertions(+), 14 deletions(-)
create mode 100644 include/linux/platform_data/simplefb.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 2e937bd..22586ee 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2455,7 +2455,7 @@ config FB_HYPERV
config FB_SIMPLE
bool "Simple framebuffer support"
- depends on (FB = y) && OF
+ depends on (FB = y)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2467,8 +2467,7 @@ config FB_SIMPLE
pre-allocated frame buffer surface.
Configuration re: surface address, size, and format must be provided
- through device tree, or potentially plain old platform data in the
- future.
+ through device tree, or plain old platform data.
source "drivers/video/omap/Kconfig"
source "drivers/video/omap2/Kconfig"
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index e2e9e3e..35e36c5 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
static struct fb_fix_screeninfo simplefb_fix = {
@@ -73,17 +74,8 @@ static struct fb_ops simplefb_ops = {
.fb_imageblit = cfb_imageblit,
};
-struct simplefb_format {
- const char *name;
- u32 bits_per_pixel;
- struct fb_bitfield red;
- struct fb_bitfield green;
- struct fb_bitfield blue;
- struct fb_bitfield transp;
-};
-
static struct simplefb_format simplefb_formats[] = {
- { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+ SIMPLEFB_FORMATS
};
struct simplefb_params {
@@ -139,6 +131,32 @@ static int simplefb_parse_dt(struct platform_device *pdev,
return 0;
}
+static int simplefb_parse_pd(struct platform_device *pdev,
+struct simplefb_params *params)
+{
+ struct simplefb_platform_data *pd = pdev->dev.platform_data;
+ int i;
+
+ params->width = pd->width;
+ params->height = pd->height;
+ params->stride = pd->stride;
+
+ for (i = 0; i < ARRAY_SIZE(simplefb_formats); i++) {
+ if (strcmp(pd->format, simplefb_formats[i].name))
+ continue;
+
+ params->format = _formats[i];
+ break;
+ }
+
+ if (!params->format) {
+ dev_err(>dev, "Invalid format value\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int simplefb_probe(struct platform_device *pdev)
{
int ret;
@@ -149,7 +167,12 @@ static int simplefb_probe(struct platform_device *pdev)
if (fb_get_options("simplefb", NULL))
return -ENODEV;
- ret = simplefb_parse_dt(pdev, );
+ ret = -ENODEV;
+ if (pdev->dev.platform_data)
+ ret = simplefb_parse_pd(pdev, );
+ else if (pdev->dev.of_node)
+ ret = simplefb_parse_dt(pdev, );
+
if (ret)
return ret;
diff --git a/include/linux/platform_data/simplefb.h
b/include/linux/platform_data/simplefb.h
new file mode 100644
index 000..a18353d
--- /dev/null
+++ b/include/linux/platform_data/simplefb.h
@@ -0,0 +1,40 @@
+/*
+ * simplefb.h - Simple Framebuffer Device
+ *
+ * Copyright (C) 2013 David Herrmann
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __PLATFORM_DATA_SIMPLEFB_H__
+#define __PLATFORM_DATA_SIMPLEFB_H__
+
+#include
+#include
+#include
+
+#define SIMPLEFB_FORMATS \
+ { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0}, DRM_FORMAT_RGB565 }
+
+struct simplefb_format {
+ const char *name;
+ u32 bits_per_pixel;
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp;
+ u32 fourcc;
+};
+
+/* the framebuffer size and location is available as IORESOURCE_MEM */
+struct simplefb_platform_data {
+ u32 width;
+ u32 height;
+ u32
[RFC 0/6] SimpleDRM Driver (was: dvbe driver)
Hi This is my second revision of the dvbe driver. I renamed it to SimpleDRM to show the resemblence with the recently introduced simplefb.c fbdev driver. The driver is supposed to be the most basic DRM driver similar to efifb.c, vesafb.c, offb.c, simplefb.c, ... It provides a single virtual CRTC+encoder+connector and allows user-space to create one dumb-buffer at a time and attach it. The setup changed slightly. It no longer uses shadow buffers but instead maps the framebuffer directly into userspace. Furthermore, a new infrastructure is used to unload firmware drivers during real hardware drivers probe cycles. Only nouveau was changed to use it, yet. I still have an odd problem when unloading DRM drivers (not just SimpleDRM) with an fbdev fallback. If I call printk() directly after unregister_framebufer(), I get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I haven't figured out exactly where that happens, but I am also very reluctant to spend more time debugging the VT layer. Anyhow, comments welcome. If someone wants to test it, you probably need to add a line to ./include/linux/platform_data/simplefb.h and add the modeline of your VESA/EFI framebuffer. Cheers David David Herrmann (6): fbdev: simplefb: add init through platform_data x86: provide platform-devices for boot-framebuffers drm: add SimpleDRM driver drm: simpledrm: add fbdev fallback support drm: add helpers to kick out firmware drivers drm: nouveau: kick out firmware drivers during probe MAINTAINERS | 8 + arch/x86/Kconfig| 18 ++ arch/x86/kernel/Makefile| 1 + arch/x86/kernel/sysfb.c | 157 drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/drm_pci.c | 1 + drivers/gpu/drm/drm_platform.c | 1 + drivers/gpu/drm/drm_stub.c | 107 drivers/gpu/drm/drm_usb.c | 1 + drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++- drivers/gpu/drm/simpledrm/Kconfig | 29 +++ drivers/gpu/drm/simpledrm/Makefile | 9 + drivers/gpu/drm/simpledrm/simpledrm.h | 114 + drivers/gpu/drm/simpledrm/simpledrm_drv.c | 231 ++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 180 ++ drivers/gpu/drm/simpledrm/simpledrm_main.c | 366 drivers/gpu/drm/simpledrm/simpledrm_mem.c | 254 +++ drivers/video/Kconfig | 5 +- drivers/video/simplefb.c| 45 +++- include/drm/drmP.h | 26 ++ include/linux/platform_data/simplefb.h | 40 +++ 22 files changed, 1604 insertions(+), 21 deletions(-) create mode 100644 arch/x86/kernel/sysfb.c create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_main.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_mem.c create mode 100644 include/linux/platform_data/simplefb.h -- 1.8.3.1
Packard Bell EasyNote LV need i915.invert_brightness=1
[Petter Reinholdtsen 2013-06-11] > Sure. This is my first try, so I hope I got it right. Does the silence mean I got the kernel patch formatting right, or that I should try again? http://lists.freedesktop.org/archives/dri-devel/2013-June/039787.html > contain the complete patch with description etc. -- Happy hacking Petter Reinholdtsen
[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
2013/6/22 Jerome Glisse j.gli...@gmail.com:
On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae daei...@gmail.com wrote:
2013/6/21 Lucas Stach l.st...@pengutronix.de:
Hi Inki,
please refrain from sending HTML Mails, it makes proper quoting without
messing up the layout everywhere pretty hard.
Sorry about that. I should have used text mode.
Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
[...]
Yeah, you'll some knowledge and understanding about the API
you are
working with to get things right. But I think it's not an
unreasonable
thing to expect the programmer working directly with kernel
interfaces
to read up on how things work.
Second thing: I'll rather have *one* consistent API for every
subsystem,
even if they differ from each other than having to implement
this
syncpoint thing in every subsystem. Remember: a single execbuf
in DRM
might reference both GEM objects backed by dma-buf as well
native SHM or
CMA backed objects. The dma-buf-mgr proposal already allows
you to
handle dma-bufs much the same way during validation than
native GEM
objects.
Actually, at first I had implemented a fence helper framework based on
reservation and dma fence to provide easy-use-interface for device
drivers. However, that was wrong implemention: I had not only
customized the dma fence but also not considered dead lock issue.
After that, I have reimplemented it as dmabuf sync to solve dead
issue, and at that time, I realized that we first need to concentrate
on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
DMA can access a same buffer, And the fact simple is the best, and the
fact we need not only kernel side but also user side interfaces. After
that, I collected what is the common part for all subsystems, and I
have devised this dmabuf sync framework for it. I'm not really
specialist in Desktop world. So question. isn't the execbuf used only
for the GPU? the gpu has dedicated video memory(VRAM) so it needs
migration mechanism between system memory and the dedicated video
memory, and also to consider ordering issue while be migrated.
Yeah, execbuf is pretty GPU specific, but I don't see how this matters
for this discussion. Also I don't see a big difference between embedded
and desktop GPUs. Buffer migration is more of a detail here. Both take
command stream that potentially reference other buffers, which might be
native GEM or dma-buf backed objects. Both have to make sure the buffers
are in the right domain (caches cleaned and address mappings set up) and
are available for the desired operation, meaning you have to sync with
other DMA engines and maybe also with CPU.
Yeah, right. Then, in case of desktop gpu, does't it need additional
something to do when a buffer/s is/are migrated from system memory to
video memory domain, or from video memory to system memory domain? I
guess the below members does similar thing, and all other DMA devices
would not need them:
struct fence {
...
unsigned int context, seqno;
...
};
And,
struct seqno_fence {
...
uint32_t seqno_ofs;
...
};
The only case where sync isn't clearly defined right now by the current
API entrypoints is when you access memory through the dma-buf fallback
mmap support, which might happen with some software processing element
in a video pipeline or something. I agree that we will need a userspace
interface here, but I think this shouldn't be yet another sync object,
but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
hooks into the existing dma-fence and reservation stuff.
I think we don't need addition ioctl commands for that. I am thinking
of using existing resources as possible. My idea also is similar in
using the reservation stuff to your idea because my approach also
should use the dma-buf resource. However, My idea is that a user
process, that wants buffer synchronization with the other, sees a sync
object as a file descriptor like dma-buf does. The below shows simple
my idea about it:
ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, sync);
flock(sync-fd, LOCK_SH); - LOCK_SH means a shared lock.
CPU access for read
flock(sync-fd, LOCK_UN);
Or
flock(sync-fd, LOCK_EX); - LOCK_EX means an exclusive lock
CPU access for write
flock(sync-fd, LOCK_UN);
close(sync-fd);
As you know, that's similar to dmabuf export feature.
In addition, a more simple idea,
flock(dmabuf_fd, LOCK_SH/EX);
CPU access for read/write
flock(dmabuf_fd, LOCK_UN);
However, I'm not sure that the above examples could be worked well,
and there are no problems yet: actually, I don't fully understand
flock mechanism, so looking into it.
And to get back
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 12:46 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Note: the existing stuff does have the nice side effect of being able to pass buffers which do not have a struct page * associated with them through the dma_buf API - I think we can still preserve that by having dma_buf provide a couple of new APIs to do the SG list map/sync/unmap, but in any case we need to fix the existing API so that: dma_buf_map_attachment() becomes dma_buf_get_sg() dma_buf_unmap_attachment() becomes dma_buf_put_sg() both getting rid of the DMA direction argument, and then we have four new dma_buf calls: dma_buf_map_sg() dma_buf_unmap_sg() dma_buf_sync_sg_for_cpu() dma_buf_sync_sg_for_device() which do the actual sg map/unmap via the DMA API *at the appropriate time for DMA*. Hm, my idea was to just add a dma_buf_sync_attchment for the device side syncing, since the cpu access stuff is already bracketed with the begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap, but imo mmap support for dma_buf is a bit insane anyway, so I don't care too much about it. Since such dma mappings would be really longstanding in most cases anyway drivers could just map with BIDIRECTIONAL and do all the real flushing with the new sync stuff. Note that the DMA API debug doesn't allow you to change the direction argument on an existing mapping (neither should it, again this is documented in the DMA API stuff in Documentation/). This is where you would need the complete set of four functions I mention above which reflect the functionality of the DMA API. [Been travelling a bit, hence the delay.] Just a quick question on your assertion that we need all four functions: Since we already have begin/end_cpu_access functions (intention here was to allow the dma_buf exporter to ensure the memory is pinned, e.g. for swapable gem objects, but also allow cpu cache flushing if required) do we still need the sync_sg_for_cpu? At least with i915 as the exporter we currently hide the cflushing behind our begin_cpu_access callback. For device dma we currently punt on it due to lack of the dma_buf_sync_sg_for_device interface. Aside: I know that i915 doing the clflushing dance itself is a bit ugly, but thus far we've been the only guys on the x86 block with non-coherent dma. But it sounds like a bunch of other blocks on Atom SoCs have similar needs, so I guess it would make sense to move that into the dma layer. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/crtc-helper: don't disable disconnected outputs
On Tue, Jun 25, 2013 at 3:09 AM, Dave Airlie airl...@gmail.com wrote: On Sun, Jun 16, 2013 at 6:41 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: This has originally been added in commit a3a0544b2c84e1d7a2022b558ecf66d8c6a8dd93 Author: Dave Airlie airl...@redhat.com Date: Mon Aug 31 15:16:30 2009 +1000 drm/kms: add explicit encoder disable function and detach harder. I think it's the wrong thing to do for a few reasons: - It's policy in the kernel. Userspace gets hotplug events when an output disconnects, and it can inquire about all the routing that is already set up. If userspace wants to disable a disconnected output it can simply do so itself. - The reason for adding it given in the commit message was to improve use of shared encoders. But the disable_unused_functions call only happens after the modeset has been completed, so it won't help too much in making the modest succeed. - We (at least in drm/i915, but iirc all other drivers work the same) ensure that if the user accidentally yanks the cable and then replugs, the same configuration will keep on working without any userspace actions required. For most outputs that's the case by default, and DP can have the same semantics with a simple re-train handler fired off from the hpd replug event. This breaks it since if the user is unlucky and hits the mouse, resulting in a panning of e.g. the integrated panel that modeset might kill the accidentally yanked output. Which isn't too great. i915 has applied this behaviour change as part of the bit modeset review, thus far without resulting in an angry crowd with pitchforks: The reason is that i915 hardware is nearly impossible to ever set something up that could trigger this on. You don't have shared encoders in places that could affect this from what I can see. Actually we do have shared encoders, and on second consideration I guess we could hit this. We get away with it though since we don't really implement the connector modeset correctly for shared encoders: We simply pick what has been last detected as connected ... Of course that's a bit broken, and we have the bug reports to prove it (and since the modeset rework they include noisy dmesg spam from the checker about the inconsistencies even). I guess I should fix that up first ;-) I know this will break the radeon card I have that I wrote this for originally, where if you alternate hotplugging a tv-out and vga that share the same encoder it won't work. I can probably drag that card out of whatever hole if fell into, but the given justifications have give me no confidence that this patch just isn't reverting the original commit without fixing anything else. I suspect I was testing hotplugging at fbcon not using X also. Oh, that makes a lot of sense. fbcon kinda wants an atomic modeset interface, but since it doesn't have one it expects the backend to paper over any intermediate inconsistencies. I guess we should fix that first. For userspace I still think that it makes much more sense to obey userspace's request and not silently kill outputs. We do that already if userspace steals the crtc. But that's something userspace can predict, wheras the exact connector-encoder relationship is more elusive. So I think the right thing would be to fail such a modeset. Anyway I agree that this patch needs a bit more prep work. -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: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com wrote: that should be the role of kernel memory management which of course needs synchronization btw A and B. But in no case this should be done using dma-buf. dma-buf is for sharing content btw different devices not sharing resources. hmm, is that true? And are you sure? Then how do you think about reservation? the reservation also uses dma-buf with same reason as long as I know: actually, we use reservation to use dma-buf. As you may know, a reservation object is allocated and initialized when a buffer object is exported to a dma buf. no, this is why the reservation object can be passed in when you construction the dmabuf. The fallback is for dmabuf to create it's own, for compatibility and to make life easier for simple devices with few buffers... but I think pretty much all drm drivers would embed the reservation object in the gem buffer and pass it in when the dmabuf is created. It is pretty much imperative that synchronization works independently of dmabuf, you really don't want to have two different cases to deal with in your driver, one for synchronizing non-exported objects, and one for synchronizing dmabuf objects. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/24/13 13:28, Rahul Sharma wrote: [...] I never got these patches. I'm not subscribed to devicetree-devel or linux-samsung so I only got two replies to patch #0, but none of the code. Can you or Rajul resend? Sure mike. Acked-by: Mike Turquettemturque...@linaro.org Applied with Mike's ack. Thanks, - Kukjin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: MTRR use in drivers
On Sun, Jun 23, 2013 at 1:38 PM, H. Peter Anvin h...@zytor.com wrote: On 06/23/2013 01:30 PM, Dave Airlie wrote: Why do you care about performance when PAT is disabled? breaking old boxes just because, is just going to get reverted when I get the first regression report that you broke old boxes. Not just because, but *if* the choice is between breaking old boxes and breaking new boxes I'll take the latter. Andy Lutomirski just submitted a bunch of patches to clean up the DRM usage of mtrrs, they are in drm-next, afaik we no longer add them on PAT systems. Fantastic news. No issue, then, and no need to break anything. The only problem I see with having ioremap_wc() installing an MTRR on non-PAT, rather than pushing that into the drivers which is clearly not the right thing, is that we will need a hook to uninstall it when the mapping is destroyed. I have trouble believing that this will ever work well -- MTRRs have crazy alignment requirements and interactions with other MTRRs, and a few drivers have to jump through hoops to set up the right MTRRs. There aren't really enough to break down every mapping. My patches (in dri-next) add functions arch_wc_phys_add and arch_wc_phys_del that do nothing except on x86 with MTRRs on and PAT off, in which case they try to add a WC MTRR. That way the handful of drivers that need WC for performance on old hardware can try (and possibly fail, depending on the usual vagaries of MTRRs). With my patches applied, DRM and agpgart no longer touch MTRRs at all with PAT on. I didn't get around to excising MTRRs from the non-DRM video drivers or from the few odd cases like myri10ge. This stuff is painful to test. The only drivers I can really test are i915 and radeon. I have a myri10ge device, but it's on a production server. I also have several mgag200 devices, but they're in a super-secret-locked-down datacenter a few thousand miles away, and trying to gauge framebuffer performance over Dell and/or HP's crappy remoting interface is a lost cause. I'm not sure that my oldest computer (locked in a basement in another state) is old enough to have an AGP port. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
PROBLEM: WARNING, plane B assertion failure
BIOS Information Vendor: Hewlett-Packard Version: 361A0 Ver. F.11 System Information Manufacturer: Hewlett-Packard Product Name: HP Mini Version: F.11 Wake-up Type: Power Switch SKU Number: FW376UA#ABA Family: 103C_5335KV 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03) (prog-if 0 0 [VGA controller]) Subsystem: Hewlett-Packard Company Device 361a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe98 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at dc80 [size=8] Region 2: Memory at d000 (32-bit, prefetchable) [size=256M] Region 3: Memory at fe94 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 Kernel modules: i915 [3.243456] [ cut here ] [3.243541] WARNING: at drivers/gpu/drm/i915/intel_display.c:1274 intel_disable_pipe+0x146/0x150 [i915]() [3.243548] Hardware name: HP Mini [3.243554] plane B assertion failure, should be off on pipe B but is still active [3.243559] Modules linked in: cfg80211 hp_wmi(+) sparse_keymap iTCO_wdt iTCO_vendor_support rfkill uvcvideo coretemp videobuf2_vmalloc videobuf2_memops videobuf2_core microcode videodev usb_storage media snd_hda_intel(+) i915(+) evdev psmouse serio_raw pcspkr snd_hda_codec lpc_ich i2c_i801 of_i2c snd_hwdep drm_kms_helper wmi snd_pcm ssb snd_page_alloc mmc_core snd_timer drm snd pcmcia soundcore battery pcmcia_core acpi_cpufreq mperf sky2 video thermal ac intel_agp intel_gtt agpgart i2c_algo_bit i2c_core button processor ext4 crc16 mbcache jbd2 sd_mod ata_generic pata_acpi ata_piix libata ehci_pci uhci_hcd ehci_hcd scsi_mod usbcore usb_common [3.243695] Pid: 117, comm: systemd-udevd Not tainted 3.9.7-1-ARCH #1 [3.243701] Call Trace: [3.243721] [c103bcec] warn_slowpath_common+0x6c/0xa0 [3.243788] [f873a766] ? intel_disable_pipe+0x146/0x150 [i915] [3.243854] [f873a766] ? intel_disable_pipe+0x146/0x150 [i915] [3.243867] [c103bd53] warn_slowpath_fmt+0x33/0x40 [3.243933] [f873a766] intel_disable_pipe+0x146/0x150 [i915] [3.244000] [f873adac] i9xx_crtc_disable+0xec/0x1c0 [i915] [3.244233] [f873c40e] intel_crtc_disable+0x2e/0x110 [i915] [3.244299] [f873c732] __intel_set_mode+0x242/0x880 [i915] [3.244316] [c140a7ad] ? mutex_unlock+0xd/0x10 [3.244347] [f835d4d0] ? drm_framebuffer_init+0x80/0x90 [drm] [3.244417] [f87431a3] intel_set_mode+0x23/0x40 [i915] [3.244647] [f87441e0] intel_get_load_detect_pipe+0x230/0x3a0 [i915] [3.244724] [f87458d4] intel_modeset_setup_hw_state+0x714/0x8b0 [i915] [3.244796] [f8745a90] intel_modeset_gem_init+0x20/0x30 [i915] [3.244852] [f8719a16] i915_driver_load+0xa86/0xcb0 [i915] [3.245039] [f8716de0] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] [3.245091] [f835a16b] drm_get_pci_dev+0x13b/0x260 [drm] [3.245152] [f871553a] i915_pci_probe+0x3a/0x90 [i915] [3.245168] [c122e6ef] pci_device_probe+0x6f/0xb0 [3.245184] [c12ca389] driver_probe_device+0x79/0x360 [3.245199] [c12ca721] __driver_attach+0x71/0x80 [3.245211] [c12ca6b0] ? __device_attach+0x40/0x40 [3.245223] [c12c87b7] bus_for_each_dev+0x47/0x80 [3.245236] [c12c9e9e] driver_attach+0x1e/0x20 [3.245247] [c12ca6b0] ? __device_attach+0x40/0x40 [3.245258] [c12c9acf] bus_add_driver+0x1df/0x2a0 [3.245402] [c122e730] ? pci_device_probe+0xb0/0xb0 [3.245417] [c122e730] ? pci_device_probe+0xb0/0xb0 [3.245429] [c12cacfa] driver_register+0x6a/0x130 [3.245444] [c122e582] __pci_register_driver+0x32/0x40 [3.245473] [f835a385] drm_pci_init+0xf5/0x100 [drm] [3.245504] [f880a000] ? 0xf8809fff [3.245568] [f880a05e] i915_init+0x5e/0x60 [i915] [3.245581] [c10011fa] do_one_initcall+0x10a/0x150 [3.245594] [c10607c4] ? __blocking_notifier_call_chain+0x44/0x60 [3.245609] [c109b636] load_module+0x19a6/0x2340 [3.245627] [c109c055] sys_init_module+0x85/0xe0 [3.245641] [c141318d] sysenter_do_call+0x12/0x28 [3.245785] ---[ end trace 62583c49c20e738c ]--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] staging: drm/imx: use generic irqchip
On Fri, 21 Jun 2013 14:52:17 +0200, Philipp Zabel p.za...@pengutronix.de
wrote:
This depends on the patch genirq: Generic chip: Add linear irq domain
support
and removes the custom IPU irq_chip and irq_domain_ops. Instead, the generic
irq chip implementation is reused.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 90
+
1 file changed, 26 insertions(+), 64 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index d629d6d..c135c66 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -986,53 +986,6 @@ static void ipu_err_irq_handler(unsigned int irq, struct
irq_desc *desc)
chained_irq_exit(chip, desc);
}
-static void ipu_ack_irq(struct irq_data *d)
-{
- struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
- irq_hw_number_t irq = d-hwirq;
-
- ipu_cm_write(ipu, 1 (irq % 32), IPU_INT_STAT(irq / 32));
-}
-
-static void ipu_unmask_irq(struct irq_data *d)
-{
- struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
- irq_hw_number_t irq = d-hwirq;
- unsigned long flags;
- u32 reg;
-
- spin_lock_irqsave(ipu-lock, flags);
-
- reg = ipu_cm_read(ipu, IPU_INT_CTRL(irq / 32));
- reg |= 1 (irq % 32);
- ipu_cm_write(ipu, reg, IPU_INT_CTRL(irq / 32));
-
- spin_unlock_irqrestore(ipu-lock, flags);
-}
-
-static void ipu_mask_irq(struct irq_data *d)
-{
- struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
- irq_hw_number_t irq = d-hwirq;
- unsigned long flags;
- u32 reg;
-
- spin_lock_irqsave(ipu-lock, flags);
-
- reg = ipu_cm_read(ipu, IPU_INT_CTRL(irq / 32));
- reg = ~(1 (irq % 32));
- ipu_cm_write(ipu, reg, IPU_INT_CTRL(irq / 32));
-
- spin_unlock_irqrestore(ipu-lock, flags);
-}
-
-static struct irq_chip ipu_irq_chip = {
- .name = IPU,
- .irq_ack = ipu_ack_irq,
- .irq_mask = ipu_mask_irq,
- .irq_unmask = ipu_unmask_irq,
-};
-
int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
enum ipu_channel_irq irq_type)
{
@@ -1171,32 +1124,39 @@ err_register:
return ret;
}
-static int ipu_irq_map(struct irq_domain *h, unsigned int irq,
-irq_hw_number_t hw)
-{
- struct ipu_soc *ipu = h-host_data;
-
- irq_set_chip_and_handler(irq, ipu_irq_chip, handle_level_irq);
- set_irq_flags(irq, IRQF_VALID);
- irq_set_chip_data(irq, ipu);
-
- return 0;
-}
-
-const struct irq_domain_ops ipu_irq_domain_ops = {
- .map = ipu_irq_map,
- .xlate = irq_domain_xlate_onecell,
-};
static int ipu_irq_init(struct ipu_soc *ipu)
{
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
+ int ret, i;
+
ipu-domain = irq_domain_add_linear(ipu-dev-of_node, IPU_NUM_IRQS,
- ipu_irq_domain_ops, ipu);
+ irq_generic_chip_ops, ipu);
if (!ipu-domain) {
dev_err(ipu-dev, failed to add irq domain\n);
return -ENODEV;
}
+ ret = irq_alloc_domain_generic_chips(ipu-domain, 32, 1, IPU,
+ handle_level_irq, 0, IRQF_VALID,
0);
+ if (ret 0) {
+ dev_err(ipu-dev, failed to alloc generic irq chips\n);
+ irq_domain_remove(ipu-domain);
+ return ret;
+ }
+
+ for (i = 0; i IPU_NUM_IRQS; i += 32) {
+ gc = irq_get_domain_generic_chip(ipu-domain, i);
+ gc-reg_base = ipu-cm_reg;
+ ct = gc-chip_types;
+ ct-chip.irq_ack = irq_gc_ack_set_bit;
+ ct-chip.irq_mask = irq_gc_mask_clr_bit;
+ ct-chip.irq_unmask = irq_gc_mask_set_bit;
+ ct-regs.ack = IPU_INT_STAT(i / 32);
+ ct-regs.mask = IPU_INT_CTRL(i / 32);
+ }
+
irq_set_chained_handler(ipu-irq_sync, ipu_irq_handler);
irq_set_handler_data(ipu-irq_sync, ipu);
irq_set_chained_handler(ipu-irq_err, ipu_err_irq_handler);
@@ -1214,6 +1174,8 @@ static void ipu_irq_exit(struct ipu_soc *ipu)
irq_set_chained_handler(ipu-irq_sync, NULL);
irq_set_handler_data(ipu-irq_sync, NULL);
+ /* TODO: remove irq_domain_generic_chips */
+
for (i = 0; i IPU_NUM_IRQS; i++) {
irq = irq_linear_revmap(ipu-domain, i);
if (irq)
--
1.8.3.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
email sent from notmuch.vim plugin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH 1/2] power: add new interface to return pm_transition state
On 06/22/2013 03:17 PM, Rafael J. Wysocki wrote: On Saturday, June 22, 2013 02:11:14 PM Shuah Khan wrote: Add a new interface get_pm_transition() to return pm_transition state. This interface is intended to be used from dev_pm_ops class and type suspend interfaces that call legacy pm ops driver suspend interfaces. Legacy suspend pm_ops take pm_message_t as a parameter. e.g: drm_class_suspend() calls into driver suspend routines via drm_dev-driver-suspend(drm_dev, state). Once drm_class_suspend() is converted to dev_pm_ops, it will no longer have access to pm_transition which it has to pass into driver legacy suspend calls. get_pm_transition() interface addresses this need. That shouldn't be necessary because each transition has its own callback in strict dev_pm_ops. Thanks, Rafael Yes that is correct that there is no need pass in or know pm_transition with dev_pm_ops. The issue I am running into is the legacy pm_ops class suspend/resume routines call. In the example, I mentioned in my changelog, drm_class_suspend() calls legacy pm_ops and passes in state. It passes in the state to the driver legacy suspend routine. I have seen code paths in drivers that differentiate between PM_EVENT_FREEZE, PM_EVENT_SUSPEND, PM_EVENT_SLEEP etc. I considered passing PM_EVENT_SUSPEND to drm_dev-driver-suspend(drm_dev, state) from drm_class_suspend() which would eliminate the need for this new interface. However, I am concerned about breaking driver legacy suspend routines that key of off the state to execute different code paths for PM_EVENT_FREEZE vs. PM_EVENT_SUSPEND. Suspend routines get called when state is is PM_EVENT_FREEZE based on my testing. I would rather not add a new interface. Hoping you will have another idea on how to pass in the state to legacy suspend/resume without adding this new interface. My thinking is that this new interface is temporary measure until all of the legacy suspend routines get converted to dev_pm_ops and at the tile legacy interface gets removed, this new interface can go away as well. thanks, -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Packard Bell EasyNote LV need i915.invert_brightness=1
[Petter Reinholdtsen 2013-06-11] Sure. This is my first try, so I hope I got it right. Does the silence mean I got the kernel patch formatting right, or that I should try again? URL: http://lists.freedesktop.org/archives/dri-devel/2013-June/039787.html contain the complete patch with description etc. -- Happy hacking Petter Reinholdtsen ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 3/6] drm: add SimpleDRM driver
On 06/24/2013 03:27 PM, David Herrmann wrote: + sdrm-fb_map = ioremap(sdrm-fb_base, sdrm-fb_size); This should probably be ioremap_wc. Otherwise it will be *really* slow if used in legacy mode and it may cause conflicts with the pgprot_writecombine mode for mmap. (Watching boot messages go by on fbcon on efifb was like using an old 2400 baud modem before I made the corresponding change to efifb.) --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65958] GPU Lockup on Trinity 7500G
https://bugs.freedesktop.org/show_bug.cgi?id=65958 Mike Lothian m...@fireburn.co.uk changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #3 from Mike Lothian m...@fireburn.co.uk --- I've not had another lockup since doing this -- 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: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
2013/6/25 Rob Clark robdcl...@gmail.com: On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com wrote: that should be the role of kernel memory management which of course needs synchronization btw A and B. But in no case this should be done using dma-buf. dma-buf is for sharing content btw different devices not sharing resources. hmm, is that true? And are you sure? Then how do you think about reservation? the reservation also uses dma-buf with same reason as long as I know: actually, we use reservation to use dma-buf. As you may know, a reservation object is allocated and initialized when a buffer object is exported to a dma buf. no, this is why the reservation object can be passed in when you construction the dmabuf. Right, that way, we could use dma buf for buffer synchronization. I just wanted to ask for why Jerome said that dma-buf is for sharing content btw different devices not sharing resources. The fallback is for dmabuf to create it's own, for compatibility and to make life easier for simple devices with few buffers... but I think pretty much all drm drivers would embed the reservation object in the gem buffer and pass it in when the dmabuf is created. It is pretty much imperative that synchronization works independently of dmabuf, you really don't want to have two different cases to deal with in your driver, one for synchronizing non-exported objects, and one for synchronizing dmabuf objects. Now my approach is concentrating on the most basic implementation, buffer synchronization mechanism between CPU and CPU, CPU and DMA, and DMA and DMA. But I think reserveration could be used for other purposes such as pipe line synchronization independently of dmabuf as you said. Actually, I had already implemented pipe line synchronization mechanism using the reservation: in case of MALI-400 DDK, there was pipe line issue between gp and pp jobs, and we had solved the issue using the pipe line synchronization mechanism with the reservation. So, we could add more features anytime; those two different cases, dmabuf objects and non-exported objects, if needed because we are using the reservation object. Thanks, Inki Dae BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 25, 2013 at 10:17 AM, Inki Dae daei...@gmail.com wrote: 2013/6/25 Rob Clark robdcl...@gmail.com: On Tue, Jun 25, 2013 at 5:09 AM, Inki Dae daei...@gmail.com wrote: that should be the role of kernel memory management which of course needs synchronization btw A and B. But in no case this should be done using dma-buf. dma-buf is for sharing content btw different devices not sharing resources. hmm, is that true? And are you sure? Then how do you think about reservation? the reservation also uses dma-buf with same reason as long as I know: actually, we use reservation to use dma-buf. As you may know, a reservation object is allocated and initialized when a buffer object is exported to a dma buf. no, this is why the reservation object can be passed in when you construction the dmabuf. Right, that way, we could use dma buf for buffer synchronization. I just wanted to ask for why Jerome said that dma-buf is for sharing content btw different devices not sharing resources. From memory, the motivation of dma-buf was to done for few use case, among them webcam capturing frame into a buffer and having gpu using it directly without memcpy, or one big gpu rendering a scene into a buffer that is then use by low power gpu for display ie it was done to allow different device to operate on same data using same backing memory. AFAICT you seem to want to use dma-buf to create scratch buffer, ie a process needs to use X amount of memory for an operation, it can release|free this memory once its done and a process B can the use this X memory for its own operation discarding content of process A. I presume that next frame would have the sequence repeat, process A do something, then process B does its thing. So to me it sounds like you want to implement global scratch buffer using the dmabuf API and that sounds bad to me. I know most closed driver have several pool of memory, long lived object, short lived object and scratch space, then user space allocate from one of this pool and there is synchronization done by driver using driver specific API to reclaim memory. Of course this work nicely if you only talking about one logic block or at very least hw that have one memory controller. Now if you are thinking of doing scratch buffer for several different device and share the memory among then you need to be aware of security implication, most obvious being that you don't want process B being able to read process A scratch memory. I know the argument about it being graphic but one day this might become gpu code and it might be able to insert jump to malicious gpu code. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 mapping large (3MB) scatter list, hitting limits on certain IOMMUs that can only map contingous regions up to 2MB.
On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: Hey, I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18 (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6 I found that i915 would halt with a [drm:intel_pipe_set_base] *ERROR* pin fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 after a bit of debugging (see patch below) I traced it down to the fact that the scatter list that is provided at the end has a huge (3MB) page. I am wondering if anybody knows what patch might have introduced it to grab such a large memory segment? The other thing I am wondering is if there are some fallbacks when the underlaying IOMMU can't deal with a request for contingous regions that are more than 2MB? There is no fallback afaik, but most gpu have their own mmu so they don't really need contiguous iommu mapping, all they need is at the very least being able to access all page of large object. Probably something we should take a look at. Cheers, Jerome Thanks. From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com Date: Fri, 21 Jun 2013 11:17:55 -0400 Subject: [PATCH] dbug: print scatterlist. [ cut here ] WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 i915_gem_gtt_prepare_object+0x180/0x200() 10 but got 0 Modules linked in: crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16 Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012 0009 8801fa42d958 816e6d89 8801fa42d998 8105d2b0 8801fa42d988 8801fb0f4d80 81c172e0 8801fa76f000 000a 8801fa42d9f8 Call Trace: [816e6d89] dump_stack+0x19/0x1b [8105d2b0] warn_slowpath_common+0x70/0xa0 [8105d396] warn_slowpath_fmt+0x46/0x50 [8142a740] i915_gem_gtt_prepare_object+0x180/0x200 [81423581] i915_gem_object_pin+0x321/0x670 [81423951] i915_gem_object_pin_to_display_plane+0x81/0x190 [814381b5] intel_pin_and_fence_fb_obj+0x85/0x1a0 [8143999c] intel_pipe_set_base+0x7c/0x220 [814409be] intel_crtc_set_config+0x89e/0x990 [813ffdae] drm_mode_set_config_internal+0x2e/0x60 [814023ab] drm_mode_setcrtc+0xfb/0x620 [811850f9] ? kmem_cache_alloc_trace+0x39/0x1f0 [813f9767] ? drm_vm_open_locked+0x57/0x90 [813f2e39] drm_ioctl+0x549/0x680 [814022b0] ? drm_mode_setplane+0x3b0/0x3b0 [811aef77] do_vfs_ioctl+0x97/0x580 [81295dca] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30 [81297397] ? file_has_perm+0x97/0xb0 [811af4f1] SyS_ioctl+0x91/0xb0 [816f63e7] tracesys+0xdd/0xe2 ---[ end trace 7b6adc5450d9a9e1 ]--- i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0 [0] virT:8801fd37c000 dma: 1fd37c000, size:4096 [1] virT:8801fd37b000 dma: 1fd37b000, size:4096 [2] virT:8801fd37a000 dma: 1fd37a000, size:4096 [3] virT:8801fd378000 dma: 1fd378000, size:4096 [4] virT:8801fd131000 dma: 1fd131000, size:4096 [5] virT:880200c36000 dma: 200c36000, size:4096 [6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632 [7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096 [8] virT:8801fd3c dma: 1fd3c, size:262144 [9] virT:8801f940 dma: 1f940, size:3866624 [drm] 3011: ret:-28 [drm] 3540: ret:-28 [drm] 3364: ret:-28 [drm:intel_pin_and_fence_fb_obj] *ERROR* i915_gem_object_pin_to_display_plane failed: -28 [drm:intel_pipe_set_base] *ERROR* pin fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- drivers/gpu/drm/i915/i915_drv.c | 6 ++ drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +--- 2 files changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 8411942..141c6fb 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600); MODULE_PARM_DESC(use_coherent, Use coherent DMA API calls (default: false)); +int i915_sgl __read_mostly = 0; +module_param_named(sgl, i915_sgl, int, 0600); +MODULE_PARM_DESC(sgl, +Print scatterlist SG's when DMA mapping them (default: false)); + + static struct drm_driver driver; extern int intel_agp_enabled; diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index acb3b3f..292179c 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -28,6 +28,7 @@
Re: i915 mapping large (3MB) scatter list, hitting limits on certain IOMMUs that can only map contingous regions up to 2MB.
On Tue, Jun 25, 2013 at 11:03:01AM -0400, Jerome Glisse wrote: On Fri, Jun 21, 2013 at 3:28 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: Hey, I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18 (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6 I found that i915 would halt with a [drm:intel_pipe_set_base] *ERROR* pin fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 after a bit of debugging (see patch below) I traced it down to the fact that the scatter list that is provided at the end has a huge (3MB) page. I am wondering if anybody knows what patch might have introduced it to grab such a large memory segment? The other thing I am wondering is if there are some fallbacks when the underlaying IOMMU can't deal with a request for contingous regions that are more than 2MB? There is no fallback afaik, but most gpu have their own mmu so they don't really need contiguous iommu mapping, all they need is at the very least being able to access all page of large object. Probably something we should take a look at. They can see. It is just that the underlaying DMA was not capable of dealing with a large chunk of the scatter gather. Cheers, Jerome Thanks. From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com Date: Fri, 21 Jun 2013 11:17:55 -0400 Subject: [PATCH] dbug: print scatterlist. [ cut here ] WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 i915_gem_gtt_prepare_object+0x180/0x200() 10 but got 0 Modules linked in: crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16 Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012 0009 8801fa42d958 816e6d89 8801fa42d998 8105d2b0 8801fa42d988 8801fb0f4d80 81c172e0 8801fa76f000 000a 8801fa42d9f8 Call Trace: [816e6d89] dump_stack+0x19/0x1b [8105d2b0] warn_slowpath_common+0x70/0xa0 [8105d396] warn_slowpath_fmt+0x46/0x50 [8142a740] i915_gem_gtt_prepare_object+0x180/0x200 [81423581] i915_gem_object_pin+0x321/0x670 [81423951] i915_gem_object_pin_to_display_plane+0x81/0x190 [814381b5] intel_pin_and_fence_fb_obj+0x85/0x1a0 [8143999c] intel_pipe_set_base+0x7c/0x220 [814409be] intel_crtc_set_config+0x89e/0x990 [813ffdae] drm_mode_set_config_internal+0x2e/0x60 [814023ab] drm_mode_setcrtc+0xfb/0x620 [811850f9] ? kmem_cache_alloc_trace+0x39/0x1f0 [813f9767] ? drm_vm_open_locked+0x57/0x90 [813f2e39] drm_ioctl+0x549/0x680 [814022b0] ? drm_mode_setplane+0x3b0/0x3b0 [811aef77] do_vfs_ioctl+0x97/0x580 [81295dca] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30 [81297397] ? file_has_perm+0x97/0xb0 [811af4f1] SyS_ioctl+0x91/0xb0 [816f63e7] tracesys+0xdd/0xe2 ---[ end trace 7b6adc5450d9a9e1 ]--- i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0 [0] virT:8801fd37c000 dma: 1fd37c000, size:4096 [1] virT:8801fd37b000 dma: 1fd37b000, size:4096 [2] virT:8801fd37a000 dma: 1fd37a000, size:4096 [3] virT:8801fd378000 dma: 1fd378000, size:4096 [4] virT:8801fd131000 dma: 1fd131000, size:4096 [5] virT:880200c36000 dma: 200c36000, size:4096 [6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632 [7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096 [8] virT:8801fd3c dma: 1fd3c, size:262144 [9] virT:8801f940 dma: 1f940, size:3866624 [drm] 3011: ret:-28 [drm] 3540: ret:-28 [drm] 3364: ret:-28 [drm:intel_pin_and_fence_fb_obj] *ERROR* i915_gem_object_pin_to_display_plane failed: -28 [drm:intel_pipe_set_base] *ERROR* pin fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- drivers/gpu/drm/i915/i915_drv.c | 6 ++ drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +--- 2 files changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 8411942..141c6fb 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600); MODULE_PARM_DESC(use_coherent, Use coherent DMA API calls (default: false)); +int i915_sgl __read_mostly = 0; +module_param_named(sgl, i915_sgl, int, 0600); +MODULE_PARM_DESC(sgl, +Print scatterlist SG's when DMA mapping them (default: false)); + +
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote: Before Linux support for acpi_osi(Windows 2012) (and when booting with acpi_osi=!Windows 2012), brightness keys were handled by the kernel just fine, whether in console, in the display manager or in my desktop environment (Xfce). xfce4-power-manager just needs to be told that the brightness keys are already handled and it doesn't need to do anything. Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote: Before Linux support for acpi_osi(Windows 2012) (and when booting with acpi_osi=!Windows 2012), brightness keys were handled by the kernel just fine, whether in console, in the display manager or in my desktop environment (Xfce). xfce4-power-manager just needs to be told that the brightness keys are already handled and it doesn't need to do anything. Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. Do we have any chances to amend this mistake by (gradually) phasing out support for the direct keypress forwarding in ACPI? Or at least some plans? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 06:10:35PM +0200, Daniel Vetter wrote: Do we have any chances to amend this mistake by (gradually) phasing out support for the direct keypress forwarding in ACPI? Or at least some plans? We could make the default value of brightness_switch_enabled a config variable and encourage distributions to flip their behaviour. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes
https://bugzilla.kernel.org/show_bug.cgi?id=57381 --- Comment #19 from Harald Judt h.j...@gmx.at 2013-06-25 19:10:07 --- echo disabled /sys/devices/pci:00/:00:01.0/:01:00.0/power/async echo disabled /sys/devices/pci:00/:00:01.0/:01:00.1/power/async This seems to have a similar effect as echo 0 /sys/power/pm_async. I believe I was wrong with this assumption. However, I got serial console debugging working now. Unfortunately, it does not reveal much, but here is the output anyway. Linux version 3.8.13+ (user@localhost) (gcc version 4.7.3 (Gentoo 4.7.3 p1.0, pie-0.5.5) ) #142 SMP PREEMPT Tue Jun 25 18:56:39 CEST 2013^M^J Command line: root=/dev/sda6 rootfstype=ext4 video=DVI-I-1:1920x1080 radeon.pcie_gen2=1 radeon.audio=1 pci=nocrs console=ttyS0,115200n8 console=tty0 no_console_suspend=1^M^J e820: BIOS-provided physical RAM map:^M^J BIOS-e820: [mem 0x-0x0009d7ff] usable^M^J BIOS-e820: [mem 0x0009d800-0x0009] reserved^M^J BIOS-e820: [mem 0x000e-0x000f] reserved^M^J BIOS-e820: [mem 0x0010-0xdd49dfff] usable^M^J BIOS-e820: [mem 0xdd49e000-0xde048fff] reserved^M^J BIOS-e820: [mem 0xde049000-0xde0d5fff] usable^M^J BIOS-e820: [mem 0xde0d6000-0xde177fff] ACPI NVS^M^J BIOS-e820: [mem 0xde178000-0xde976fff] reserved^M^J BIOS-e820: [mem 0xde977000-0xde977fff] usable^M^J BIOS-e820: [mem 0xde978000-0xde9bafff] ACPI NVS^M^J BIOS-e820: [mem 0xde9bb000-0xdf3f5fff] usable^M^J BIOS-e820: [mem 0xdf3f6000-0xdf7f1fff] reserved^M^J BIOS-e820: [mem 0xdf7f2000-0xdf7f] usable^M^J BIOS-e820: [mem 0xf800-0xfbff] reserved^M^J BIOS-e820: [mem 0xfec0-0xfec00fff] reserved^M^J BIOS-e820: [mem 0xfed0-0xfed03fff] reserved^M^J BIOS-e820: [mem 0xfed1c000-0xfed1] reserved^M^J BIOS-e820: [mem 0xfee0-0xfee00fff] reserved^M^J BIOS-e820: [mem 0xff00-0x] reserved^M^J BIOS-e820: [mem 0x0001-0x00041eff] usable^M^J NX (Execute Disable) protection: active^M^J SMBIOS 2.7 present.^M^J No AGP bridge found^M^J e820: last_pfn = 0x41f000 max_arch_pfn = 0x4^M^J x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106^M^J e820: last_pfn = 0xdf800 max_arch_pfn = 0x4^M^J found SMP MP-table at [mem 0x000fd8e0-0x000fd8ef] mapped at [880fd8e0]^M^J init_memory_mapping: [mem 0x-0xdf7f]^M^J init_memory_mapping: [mem 0x1-0x41eff]^M^J ACPI: RSDP 000f0490 00024 (v02 ALASKA)^M^J ACPI: XSDT de169078 0006C (v01 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: FACP de172f58 0010C (v05 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: DSDT de169178 09DDD (v02 ALASKAA M I 0022 INTL 20051117)^M^J ACPI: FACS de176080 00040^M^J ACPI: APIC de173068 00092 (v03 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: FPDT de173100 00044 (v01 ALASKAA M I 01072009 AMI 00010013)^M^J ACPI: MCFG de173148 0003C (v01 ALASKAA M I 01072009 MSFT 0097)^M^J ACPI: AAFT de173188 00112 (v01 ALASKA OEMAAFT 01072009 MSFT 0097)^M^J ACPI: HPET de1732a0 00038 (v01 ALASKAA M I 01072009 AMI. 0005)^M^J ACPI: SSDT de1732d8 0036D (v01 SataRe SataTabl 1000 INTL 20091112)^M^J ACPI: SSDT de173648 00A92 (v01 PmRefCpuPm 3000 INTL 20051117)^M^J ACPI: BGRT de1740e0 00038 (v00 ALASKAA M I 01072009 AMI 00010013)^M^J No NUMA configuration found^M^J Faking a node at [mem 0x-0x00041eff]^M^J Initmem setup node 0 [mem 0x-0x41eff]^M^J NODE_DATA [mem 0x41effc000-0x41eff]^M^J Zone ranges:^M^J DMA [mem 0x0001-0x00ff]^M^J DMA32[mem 0x0100-0x]^M^J Normal [mem 0x1-0x41eff]^M^J Movable zone start for each node^M^J Early memory node ranges^M^J node 0: [mem 0x0001-0x0009cfff]^M^J node 0: [mem 0x0010-0xdd49dfff]^M^J node 0: [mem 0xde049000-0xde0d5fff]^M^J node 0: [mem 0xde977000-0xde977fff]^M^J node 0: [mem 0xde9bb000-0xdf3f5fff]^M^J node 0: [mem 0xdf7f2000-0xdf7f]^M^J node 0: [mem 0x1-0x41eff]^M^J ACPI: PM-Timer IO Port: 0x408^M^J ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)^M^J ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)^M^J ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)^M^J ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)^M^J ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)^M^J ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)^M^J ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)^M^J ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)^M^J ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])^M^J ACPI: IOAPIC (id[0x02] address[0xfec0]
[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes
https://bugzilla.kernel.org/show_bug.cgi?id=57381 Nigel Cunningham ni...@tuxonice.net changed: What|Removed |Added CC||ni...@tuxonice.net --- Comment #20 from Nigel Cunningham ni...@tuxonice.net 2013-06-25 20:54:06 --- If you install the userui binary in the initramfs, you'll be able to single step through the process and modify the TuxOnIce debugging settings as you go - perhaps this will help. Press 'P' to pause between steps, 0-9 to modify the level of debugging info that's displayed (9 = max info, including all kernel messages). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote: Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. I'm not sure what that means. To detect what case exactly? That the brightness is handled by video.ko? That the kernel will automatically handle backlight key presses. Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. Well, I get the reasoning, but I'm not sure I agree. That means userspace behavior is inconsistent depending on who does it (gnome-power-manager, gnome-setting-daemon, whatever), and it usually means there's nothing handling the brightness before those are running, not to mention people not running them because they don't run a full blown desktop environment (until someone starts thinking it's a good idea to handle brightness in systemd). The behaviour is already inconsistent. If you have an ACPI backlight interface, hitting the keys makes your brightness change without any userspace help. If you don't, it doesn't. And in the end, the user just want the brightness keys to correctly handle the brightness, full stop. Having multiple brightness daemons using different policies on different hardware is a nightmare for the end user, imho. From a user point of view, having it handled all in the kernel works really pretty fine and is completely transparent (I have to admit that from that point of view, it was even better when it was handled by the EC but those times seem long gone). I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63520] r300g regression (RV380): Strange rendering of light sources in Penumbra (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=63520 --- Comment #22 from PJBrs pj...@floorenpj.xs4all.nl --- This fixes it!--great, thanks very much! Is this patch already in master? And will it also go in the 9.0 / 9.1 stable branches? Anyway, thanks very much again for your time, glad I could be of some help too. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote: I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. It's pretty clear we disagree on this and that my opinion won't really matter here. But letting userspace handle that just means broken functionality for those who have the chance (apparently) to have an ACPI backlight interface. Which, as we've already established, you don't - Lenovo broke it. Your Thinkpad claims to have 100 available levels, and most of them don't work. The kernel has no way of knowing which levels work and which don't, so leaving this up to the kernel won't actually fix your system either. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote: Which, as we've already established, you don't - Lenovo broke it. Your Thinkpad claims to have 100 available levels, and most of them don't work. The kernel has no way of knowing which levels work and which don't, so leaving this up to the kernel won't actually fix your system either. I was referring to “standardize the behaviour by leaving up to userspace”. A lot of thinkpads (for example) (all the pre-windows 8 ones) have a perfectly working ACPI backlight interface. And this patchset won't alter their behaviour. Also, if the kernel has no way of knowing which levels work, I fail to see how userspace can do better. It can't. That's why this patchset disables the ACPI interface on Windows 8 systems. I understand that switching to intel_backlight instead of acpi_video0 follows what Windows 8 recommends but for me it looks orthogonal to the fact ACPI methods now have some awkward (Lenovo) or broken (Dell). I mean, it's not the first time firmware people break some kernel behavior. I know it's usually not easy to contact them, but shouldn't those methods be fixed, instead of somehow blindly switching to graphic drivers? No. The correct answer to all firmware issues is Are we making the same firmware calls as the version of Windows that this hardware thinks it's running. If Windows 8 doesn't make these calls, we shouldn't make these calls. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:46:01PM +0200, Yves-Alexis Perez wrote: But if that introduce regressions, shouldn't workarounds be found then? Sorry if I keep repeating that but brightness keys handling in-kernel is quite a useful feature and losing it (because of the “behave exactly like Windows 8 kernel” policy) is indeed a regression. Your firmware behaves differently depending on whether the OS claims to be Windows 8 or not. We can't make that invisible. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] fix error routine of exporting dma_buf
During exporting dma_buf, it can fail after dma_buf is exported. In this case, exported dma_buf should be release with putting. Also dma_buf_fd can be failed to get fd, but failure cases are not handled. Error handling routine is not quite clean, so I send this patch set as RFC. Seung-Woo Kim (1): drm/prime: reorder drm_prime_add_buf_handle and remove prototype YoungJun Cho (2): drm/prime: fix to put an exported dma_buf for adding handle failure drm/prime: add return check for dma_buf_fd drivers/gpu/drm/drm_prime.c | 79 +++--- 1 files changed, 51 insertions(+), 28 deletions(-) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/prime: fix to put an exported dma_buf for adding handle failure
From: YoungJun Cho yj44@samsung.com When drm_prime_add_buf_handle() returns failure for an exported dma_buf, the dma_buf was already allocated and its refcount was increased, so it needs to be put. Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/gpu/drm/drm_prime.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 5b7b911..afff7c8 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -235,7 +235,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev, ret = drm_prime_add_buf_handle(file_priv-prime, obj-export_dma_buf, handle); if (ret) - goto out; + goto fail_put_dmabuf; *prime_fd = dma_buf_fd(buf, flags); mutex_unlock(file_priv-prime.lock); @@ -244,6 +244,12 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev, out_have_obj: get_dma_buf(dmabuf); *prime_fd = dma_buf_fd(dmabuf, flags); + goto out; + +fail_put_dmabuf: + /* clear NOT to be checked when releasing dma_buf */ + obj-export_dma_buf = NULL; + dma_buf_put(buf); out: drm_gem_object_unreference_unlocked(obj); mutex_unlock(file_priv-prime.lock); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/prime: reorder drm_prime_add_buf_handle and remove prototype
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_prime.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index afff7c8..b3bb2fb 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,7 +62,22 @@ struct drm_prime_member {
struct dma_buf *dma_buf;
uint32_t handle;
};
-static int drm_prime_add_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
+
+static int drm_prime_add_buf_handle(struct drm_prime_file_private *prime_fpriv,
+ struct dma_buf *dma_buf, uint32_t handle)
+{
+ struct drm_prime_member *member;
+
+ member = kmalloc(sizeof(*member), GFP_KERNEL);
+ if (!member)
+ return -ENOMEM;
+
+ get_dma_buf(dma_buf);
+ member-dma_buf = dma_buf;
+ member-handle = handle;
+ list_add(member-entry, prime_fpriv-head);
+ return 0;
+}
static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
@@ -498,21 +513,6 @@ void drm_prime_destroy_file_private(struct
drm_prime_file_private *prime_fpriv)
}
EXPORT_SYMBOL(drm_prime_destroy_file_private);
-static int drm_prime_add_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle)
-{
- struct drm_prime_member *member;
-
- member = kmalloc(sizeof(*member), GFP_KERNEL);
- if (!member)
- return -ENOMEM;
-
- get_dma_buf(dma_buf);
- member-dma_buf = dma_buf;
- member-handle = handle;
- list_add(member-entry, prime_fpriv-head);
- return 0;
-}
-
int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpriv,
struct dma_buf *dma_buf, uint32_t *handle)
{
struct drm_prime_member *member;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/prime: add return check for dma_buf_fd
From: YoungJun Cho yj44@samsung.com
The dma_buf_fd() can return error when it fails to prepare fd,
so the dma_buf needs to be put.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_prime.c | 39 ---
1 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index b3bb2fb..24c801c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -79,6 +79,21 @@ static int drm_prime_add_buf_handle(struct
drm_prime_file_private *prime_fpriv,
return 0;
}
+static void drm_prime_remove_buf_handle_locked(
+ struct drm_prime_file_private *prime_fpriv,
+ struct dma_buf *dma_buf)
+{
+ struct drm_prime_member *member, *safe;
+
+ list_for_each_entry_safe(member, safe, prime_fpriv-head, entry) {
+ if (member-dma_buf == dma_buf) {
+ dma_buf_put(dma_buf);
+ list_del(member-entry);
+ kfree(member);
+ }
+ }
+}
+
static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
@@ -252,15 +267,25 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
if (ret)
goto fail_put_dmabuf;
- *prime_fd = dma_buf_fd(buf, flags);
+ ret = dma_buf_fd(buf, flags);
+ if (ret 0)
+ goto fail_rm_handle;
+
+ *prime_fd = ret;
mutex_unlock(file_priv-prime.lock);
return 0;
out_have_obj:
get_dma_buf(dmabuf);
- *prime_fd = dma_buf_fd(dmabuf, flags);
+ ret = dma_buf_fd(dmabuf, flags);
+ if (ret 0)
+ dma_buf_put(dmabuf);
+ else
+ *prime_fd = ret;
goto out;
+fail_rm_handle:
+ drm_prime_remove_buf_handle_locked(file_priv-prime, buf);
fail_put_dmabuf:
/* clear NOT to be checked when releasing dma_buf */
obj-export_dma_buf = NULL;
@@ -529,16 +554,8 @@ EXPORT_SYMBOL(drm_prime_lookup_buf_handle);
void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv,
struct dma_buf *dma_buf)
{
- struct drm_prime_member *member, *safe;
-
mutex_lock(prime_fpriv-lock);
- list_for_each_entry_safe(member, safe, prime_fpriv-head, entry) {
- if (member-dma_buf == dma_buf) {
- dma_buf_put(dma_buf);
- list_del(member-entry);
- kfree(member);
- }
- }
+ drm_prime_remove_buf_handle_locked(prime_fpriv, dma_buf);
mutex_unlock(prime_fpriv-lock);
}
EXPORT_SYMBOL(drm_prime_remove_buf_handle);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: fix not to assign error value to gem name
From: YoungJun Cho yj44@samsung.com
If idr_alloc() is failed, obj-name can be error value. Also
it cleans up duplicated flink processing code.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_gem.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index cf919e3..239ef30 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -453,25 +453,21 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
spin_lock(dev-object_name_lock);
if (!obj-name) {
ret = idr_alloc(dev-object_name_idr, obj, 1, 0, GFP_NOWAIT);
- obj-name = ret;
- args-name = (uint64_t) obj-name;
- spin_unlock(dev-object_name_lock);
- idr_preload_end();
-
if (ret 0)
goto err;
- ret = 0;
+
+ obj-name = ret;
/* Allocate a reference for the name table. */
drm_gem_object_reference(obj);
- } else {
- args-name = (uint64_t) obj-name;
- spin_unlock(dev-object_name_lock);
- idr_preload_end();
- ret = 0;
}
+ args-name = (uint64_t) obj-name;
+ ret = 0;
+
err:
+ spin_unlock(dev-object_name_lock);
+ idr_preload_end();
drm_gem_object_unreference_unlocked(obj);
return ret;
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: add mutex lock when using drm_gem_mmap_obj
From: YoungJun Cho yj44@samsung.com
The drm_gem_mmap_obj() has to be protected with dev-struct_mutex,
but some caller functions do not. So it adds mutex lock to missing
callers and adds WARN_ON assertion whether drm_gem_mmap_obj() is
called with mutex lock or not.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
CC: Rob Clark robdcl...@gmail.com
---
This patch is based on drm-next branch.
drivers/gpu/drm/drm_gem.c |4
drivers/gpu/drm/drm_gem_cma_helper.c |3 +++
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |3 +++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4321713..b19bba0 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -661,6 +661,8 @@ EXPORT_SYMBOL(drm_gem_vm_close);
* the GEM object is not looked up based on its fake offset. To implement the
* DRM mmap operation, drivers should use the drm_gem_mmap() function.
*
+ * NOTE: This function has to be protected with dev-struct_mutex
+ *
* Return 0 or success or -EINVAL if the object size is smaller than the VMA
* size, or if no gem_vm_ops are provided.
*/
@@ -669,6 +671,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned
long obj_size,
{
struct drm_device *dev = obj-dev;
+ WARN_ON(!mutex_is_locked(dev-struct_mutex));
+
/* Check for valid size. */
if (obj_size vma-vm_end - vma-vm_start)
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 9efabce..ce06397 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -487,9 +487,12 @@ static int drm_gem_cma_dmabuf_mmap(struct dma_buf *dmabuf,
{
struct drm_gem_cma_object *cma_obj = dmabuf-priv;
struct drm_gem_object *gem_obj = cma_obj-base;
+ struct drm_device *dev = gem_obj-dev;
int ret;
+ mutex_lock(dev-struct_mutex);
ret = drm_gem_mmap_obj(gem_obj, gem_obj-size, vma);
+ mutex_unlock(dev-struct_mutex);
if (ret 0)
return ret;
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 3256693..4fcca8d 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -140,12 +140,15 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct vm_area_struct *vma)
{
struct drm_gem_object *obj = buffer-priv;
+ struct drm_device *dev = obj-dev;
int ret = 0;
if (WARN_ON(!obj-filp))
return -EINVAL;
+ mutex_lock(dev-struct_mutex);
ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma);
+ mutex_unlock(dev-struct_mutex);
if (ret 0)
return ret;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commits 2d05eae1c92f
(drm/i915: Propagate errors back from fb set-base) and d62cf62ad07d
(drm/i915: Quirk the pipe A quirk in the modeset state checker) from
Linus' tree and commits 6c49f24180c3 (drm/i915: hw state readout support
for pixel_multiplier) and 9222be993921 (drm/i915: don't scream into
dmesg when a modeset fails) from the drm-intel tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 6eb99e1,8f746d9..000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -8177,11 -8264,14 +8264,19 @@@ check_crtc_state(struct drm_device *dev
active = dev_priv-display.get_pipe_config(crtc,
pipe_config);
+
+ /* hw state is inconsistent with the pipe A quirk */
+ if (crtc-pipe == PIPE_A dev_priv-quirks
QUIRK_PIPEA_FORCE)
+ active = crtc-active;
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list,
+ base.head) {
+ if (encoder-base.crtc != crtc-base)
+ continue;
+ if (encoder-get_config)
+ encoder-get_config(encoder, pipe_config);
+ }
+
WARN(crtc-active != active,
crtc active state doesn't match with hw state
(expected %i, found %i)\n, crtc-active, active);
pgpNdKtKWzIte.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
