Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

2014-05-11 Thread Dave Airlie 
On 11 May 2014 18:28, Thomas Meyer  wrote:
> Hi,
>
> 3.14.3 works as expected.
> 3.15-rc5 shows a strange behaviour: When resuming from ram the X server
> seems to be disfunctional.
>
> I see this WARNING in the kernel log before suspend to ram in the early
> boot process:
>
> - Fresh boot 3.15-rc5:
> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Initialized drm 1.1.0 
> 20060810
> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Memory usable by graphics 
> device = 2048M
> Mai 10 15:24:43 localhost.localdomain kernel: ACPI: Battery Slot [BAT1] 
> (battery absent)
> Mai 10 15:24:43 localhost.localdomain kernel: i915 :00:02.0: irq 42 for 
> MSI/MSI-X
> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Supports vblank timestamp 
> caching Rev 2 (21.10.2013).
> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Driver supports precise 
> vblank timestamp query.
> Mai 10 15:24:43 localhost.localdomain kernel: vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> Mai 10 15:24:43 localhost.localdomain kernel: fbcon: inteldrmfb (fb0) is 
> primary device
> Mai 10 15:24:43 localhost.localdomain kernel: [ cut here 
> ]
> Mai 10 15:24:43 localhost.localdomain kernel: WARNING: CPU: 0 PID: 1 at 
> drivers/gpu/drm/i915/intel_panel.c:714 i965_enable_backlight+0x12a/0x150()
> Mai 10 15:24:43 localhost.localdomain kernel: backlight already enabled
> Mai 10 15:24:43 localhost.localdomain kernel: Modules linked in:
> Mai 10 15:24:43 localhost.localdomain kernel: CPU: 0 PID: 1 Comm: swapper Not 
> tainted 3.15.0-rc5 #132
> Mai 10 15:24:43 localhost.localdomain kernel: Hardware name: Acer Aspire 
> 1810T/JM11-MS, BIOS v1.3310 03/25/2010
> Mai 10 15:24:43 localhost.localdomain kernel:  8802368bd470 
> a776f508 8802368bd428 81585472
> Mai 10 15:24:43 localhost.localdomain kernel:  8802368bd460 
> 8103d1fc 8800b4898000 
> Mai 10 15:24:43 localhost.localdomain kernel:  880234979c00 
> c000 880235154200 8802368bd4c8
> Mai 10 15:24:43 localhost.localdomain kernel: Call Trace:
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> dump_stack+0x19/0x1b
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> warn_slowpath_common+0x6c/0x90
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> warn_slowpath_fmt+0x57/0x80
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> i965_enable_backlight+0x12a/0x150
> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
> gen4_write64+0x60/0x60
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> intel_panel_enable_backlight+0x73/0xd0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> intel_enable_lvds+0x163/0x180
> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
> gen4_write64+0x60/0x60
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> i9xx_crtc_enable+0x2e1/0x410
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> __intel_set_mode+0x80f/0x1630
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> intel_set_mode+0x11/0x30
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> intel_crtc_set_config+0x8dd/0xdb0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> drm_mode_set_config_internal+0x61/0xf0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> drm_fb_helper_restore_fbdev_mode+0xab/0xd0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> drm_fb_helper_set_par+0x2c/0x80
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> fbcon_init+0x504/0x580
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> visual_init+0xb3/0x110
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> do_bind_con_driver+0x153/0x320
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> do_take_over_console+0x114/0x1c0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> do_fbcon_takeover+0x5b/0xc0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> fbcon_event_notify+0x68d/0x7e0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> notifier_call_chain+0x4c/0x70
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> __blocking_notifier_call_chain+0x48/0x70
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> blocking_notifier_call_chain+0x11/0x20
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> fb_notifier_call_chain+0x16/0x20
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> register_framebuffer+0x1f6/0x340
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> drm_fb_helper_initial_config+0x32e/0x500
> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
> drm_fb_helper_single_add_all_connectors+0x64/0xd0
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> intel_fbdev_initial_config+0x1a/0x20
> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
> i915_driver_load+0xe7c/0xf00
> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
> dev_uevent+0x59/0x220
> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
> netlink_has_listeners+0x58/0x70
> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
> kobj

Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns

2014-05-11 Thread Daniel Vetter 
On Fri, May 9, 2014 at 11:18 PM, Dave Airlie  wrote:
> Please don't make things more prominent if the fixes can't be merged
> without rewriting the world,
>
> Distros have auto reporting tools for the major backtrace warnings,
> and releasing kernels with unfixable ones in it make it hard to know
> what is real and what isn't.

Fully agreed if we can't fix them. But we also need to strike some
balance for otherwise we can never enable we self-tests. And I
absolutely want those enable to have the best possible regression
testing coverage. E.g. every time we add a substantial amount of new
checks to the modeset state checker it takes 1-2 releases to settle
all the fallout. But we're backporting all the fixes, except when
they're too invasive (in which case we disable the check temporarily
or restrict it).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns

2014-05-11 Thread Daniel Vetter 
On Sat, May 10, 2014 at 10:52 AM, Jörg Otte  wrote:
>> On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote:
>>> On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote:
>>> > > Jörg, can you please boot with drm.debug=0xe, reproduce the issue and
>>> > > then attach the complete dmesg? Please make sure that the dmesg
>>> > > contains the boot-up stuff too.
>>> > >
>>> > > Thanks, Daniel
>>> > Here it is. I should mention it only happens at boot-up.
>>>
>>> [0.374095] [drm] Wrong MCH_SSKPD value: 0x20100406
>>> [0.374096] [drm] This can cause pipe underruns and display issues.
>>> [0.374097] [drm] Please upgrade your BIOS to fix this.
>>
>> That can be a factor, but I think we may have some more general issue
>> in the modeset sequence which causes these to get reported. I'm getting
>> some on my machine as well where SSKPD looks more sane. Maybe we turn on
>> the error reporting too early or something.
>>
>> But I'm not going to spend time worrying about these before my previous
>> watermark stuff gets merged. Also the underrun reporting code itself
>> would need some kind of rewrite to be really useful.
>>
>> If the display doesn't blank out during use everything is more or less
>> fine and you can ignore these errors. It's quite likely that the
>> errors were always present and you didn't know it. We just made them
>> more prominent recently.
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>
> It comes out on the boot-up screen which is normally clean. So it becomes
> highly visible for anyone.

To make sure that you're only seeing this at boot up and not elseplace
please check that it doesn't show up when you do anything of the
below:
a) suspend/resume
b) changing the output mode (e.g. with xrandr --mode)
c) changing the output pipe (e.g. with xrandr --crtc)
d) all of the above but with heavy system load, e.g. compile kernels
with make -j 

Also please test the latest drm-intel-nightly branch from
http://cgit.freedesktop.org/drm-intel to make sure we haven't yet
fixed this in our -next branch.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/56] [RFCish] Dynamic page table alloc, 64b, and GPU/CPU mirror

2014-05-11 Thread Daniel Vetter 
On Sat, May 10, 2014 at 5:58 AM, Ben Widawsky
 wrote:
> Just as before, these patches are living based off of my Broadwell
> branch, here:
> http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=gpu_mirror
>
> This is the follow-on patches for [1]
>
> This patch series brings 3 things:
> 1. Dynamic page table allocation for gen6-8
> 2. 64b (48b canonical) graphics virtual address space for Broadwell
> 3. An interface to specify a specific offset for a BO.
>
> It's taken way longer than I thought to get this work done, and given
> the current state of our driver, I fear I may not have time to see this
> through to the end before I am pulled onto other things. If people want
> to send me smallish bugfixes, I will gladly do my best to fix them
> quickly. If there are more substantial change requests wrt design or
> patch reorganization, I will not be able to accommodate. Someone else
> must take over this patch series at that point if they want these
> features. I do believe that everything up until the userptr patch is in
> decent shape though, so we'll see, I guess. (if you are qualified to
> take this over, and have interest, please let me know).
>
> The patch series is highly volatile and not manicured. I've run exactly
> 1 test on the GPU mirror (see below for what that means), though many
> more on the prior stuff. The series depends on full PPGTT, which is not
> yet enabled by default, and has a few outstanding issues. It also has
> been developed exclusively on pre-production hardware. I am only sending
> out now because I will be on vacation for the next 10 days, and I know
> there are people that can benefit from this code before I return. With
> that, I got the last parts of this working very recently, and they're
> very hackish. The reason for this lack of refinement is I expect the
> interfaces for letting userspace dictate things to change (more on this
> later), and the other part is I just ran out of time before my vacation.
> Throughout development, I've been hitting issues which I am not yet sure
> if they are bugs in my code, bugs in full PPGTT, bugs in userptr, or
> generally flakiness. There are a few patches in here which say TESTME
> reflecting upon this. Also, if you want to run this, I highly recommend
> turning off semaphores, and rc6. (To be honest, I've not tried it
> recently). You also need to turn on PPGTT since it is disabled by
> default.
>
> modprobe i915 enable_ppgtt=2 semaphores=0 enable_rc6=0
>
> What you get in this series is what I'm going to coin, GPU mirror. This
> patch series allows one to allocate an arbitrary address for your GPU
> buffer object, and map it to a specific space within the GPUs address
> space. This is only possible because on Broadwell we get a 64b canonical
> GPU address space, and this allows us to map any CPU address as a GPU
> address. The obvious usage here is malloc(). malloc() returns a pointer
> that is valid on the CPU. Now that address can be identical on the GPU.
>
> The interface provided is identical to the userptr interface previously
> posted by Chris Wilson. I've added a flag to that interface that
> indicates this new functionality. This is not necessarily the final
> version, and it's arguably not the best idea either. The reason for this
> choice is we had users of userptr that wanted to try out this concept
> and not have to do much porting.
>
> To get to the userptr interface, I had to make a few things happen
> first. I needed to get dynamic page table allocation and teardown
> working. This was posted previously for gen6-7 [1] (with very rough code
> for gen8). I've now added more robust support for gen8 dynamic page
> table allocations. Doing the allocations dynamically was important
> because preallocating all 4 levels of page tables is not feasible in a
> real system. 4 level page tables are required in order to be able to
> support the 64b canonical address space.
>
> With that all done, I was able to make a few minor hacks to userptr,
> take the intel-gpu-tools test from Tvrtko, and see at least one pass.
> FWIW, I am currently running,
> ./tests/gem_userptr_blits --run-subtest coherency-unsync
>
> Since I feel the interface will likely change, I do not feel compelled
> to post either my libdrm, not my IGT changes. If you want the modified
> test, let me know, as I don't think it's really relevant here.
>
> One last thing. Intel GPU tools, as it stands today, makes a lot of
> assumptions about using an address space > 32b. I have not had time to
> fix this. It is something which needs fixing before this series could
> even be considered testable.

Until full ppgtt is fixed up and enabled by default it in my opinion
doesn't make sense to pile more ppgtt features on top. Until that's
addressed or someone convinces me that my opinion is stupid I'll
reject this.

Of course that doesn't include the entire patch series, since the
dynamic ppgtt pte stuff is part of fixing up ppgtt. But I still think
we should address the bugs f

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

2014-05-11 Thread Daniel Vetter 
On Sun, May 11, 2014 at 11:02 AM, Dave Airlie  wrote:
> On 11 May 2014 18:28, Thomas Meyer  wrote:
>> Hi,
>>
>> 3.14.3 works as expected.
>> 3.15-rc5 shows a strange behaviour: When resuming from ram the X server
>> seems to be disfunctional.
>>
>> I see this WARNING in the kernel log before suspend to ram in the early
>> boot process:

Doesn't ring a bell really.
- Is there anything in dmesg after resume?
- How exactly does X misbehave? Is fbcon still working? Does X
behaviour get restored if you restart X?
- Can you please try to bisect this issue? Note that the backlight
issue might be unrelated to the issues with X misbehaving after
resume. You might need to do a bisect for both if the symptoms don't
agree.

Thanks, Daniel

>>
>> - Fresh boot 3.15-rc5:
>> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Initialized drm 1.1.0 
>> 20060810
>> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Memory usable by 
>> graphics device = 2048M
>> Mai 10 15:24:43 localhost.localdomain kernel: ACPI: Battery Slot [BAT1] 
>> (battery absent)
>> Mai 10 15:24:43 localhost.localdomain kernel: i915 :00:02.0: irq 42 for 
>> MSI/MSI-X
>> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Supports vblank 
>> timestamp caching Rev 2 (21.10.2013).
>> Mai 10 15:24:43 localhost.localdomain kernel: [drm] Driver supports precise 
>> vblank timestamp query.
>> Mai 10 15:24:43 localhost.localdomain kernel: vgaarb: device changed 
>> decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>> Mai 10 15:24:43 localhost.localdomain kernel: fbcon: inteldrmfb (fb0) is 
>> primary device
>> Mai 10 15:24:43 localhost.localdomain kernel: [ cut here 
>> ]
>> Mai 10 15:24:43 localhost.localdomain kernel: WARNING: CPU: 0 PID: 1 at 
>> drivers/gpu/drm/i915/intel_panel.c:714 i965_enable_backlight+0x12a/0x150()
>> Mai 10 15:24:43 localhost.localdomain kernel: backlight already enabled
>> Mai 10 15:24:43 localhost.localdomain kernel: Modules linked in:
>> Mai 10 15:24:43 localhost.localdomain kernel: CPU: 0 PID: 1 Comm: swapper 
>> Not tainted 3.15.0-rc5 #132
>> Mai 10 15:24:43 localhost.localdomain kernel: Hardware name: Acer Aspire 
>> 1810T/JM11-MS, BIOS v1.3310 03/25/2010
>> Mai 10 15:24:43 localhost.localdomain kernel:  8802368bd470 
>> a776f508 8802368bd428 81585472
>> Mai 10 15:24:43 localhost.localdomain kernel:  8802368bd460 
>> 8103d1fc 8800b4898000 
>> Mai 10 15:24:43 localhost.localdomain kernel:  880234979c00 
>> c000 880235154200 8802368bd4c8
>> Mai 10 15:24:43 localhost.localdomain kernel: Call Trace:
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> dump_stack+0x19/0x1b
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> warn_slowpath_common+0x6c/0x90
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> warn_slowpath_fmt+0x57/0x80
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> i965_enable_backlight+0x12a/0x150
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
>> gen4_write64+0x60/0x60
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> intel_panel_enable_backlight+0x73/0xd0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> intel_enable_lvds+0x163/0x180
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] ? 
>> gen4_write64+0x60/0x60
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> i9xx_crtc_enable+0x2e1/0x410
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> __intel_set_mode+0x80f/0x1630
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> intel_set_mode+0x11/0x30
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> intel_crtc_set_config+0x8dd/0xdb0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> drm_mode_set_config_internal+0x61/0xf0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> drm_fb_helper_restore_fbdev_mode+0xab/0xd0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> drm_fb_helper_set_par+0x2c/0x80
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> fbcon_init+0x504/0x580
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> visual_init+0xb3/0x110
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> do_bind_con_driver+0x153/0x320
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> do_take_over_console+0x114/0x1c0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> do_fbcon_takeover+0x5b/0xc0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> fbcon_event_notify+0x68d/0x7e0
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> notifier_call_chain+0x4c/0x70
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> __blocking_notifier_call_chain+0x48/0x70
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> blocking_notifier_call_chain+0x11/0x20
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> fb_notifier_call_chain+0x16/0x20
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>> register_framebuffer+0x1f6/0x340
>> Mai 10 15:24:43 localhost.localdomain kernel:  [] 
>>

[Intel-gfx] broken eDP device types

2014-05-11 Thread Jon Pry 
Hi,

   I'm trying to work out some bugs on Asus T100TA which is Baytrail-T
platform. Current code in use is 3.15_rc4. In general I have been
having problems with the backlight control. For some reason the kernel
is detecting the panel as a VGA device and intel_crt.c does not load
intel_backlight, so I hacked something together real quick and ended
up getting something that actual changes PWM registers, but this had
no effect on actual screen brightness.

   Without any real solid theory as to why PWM is not doing anything.
I started wondering why exactly the kernel thinks the panel is VGA
since it is kind of unlikely the panel is analog especially
considering Baytrail-T does not have any analog interfaces. So I
nabbed the VBT to take a look.

Whole thing is here if your interested http://pastebin.com/crht1nDU

Pretty sure the relevant portion is:

EFP device info:
Device type: 0x1400 (unknown)
Port: 0x15 (unknown)
DDC pin: 0x04
Dock port: 0x00 (N/A)
HDMI compatible? No
Info: HDMI certified
Aux channel: 0x00
Dongle detect: 0x00

The VBT does include tables for LVDS/eDP operation of the panel. It
seems just the device type is fubar. So my questions are, why is the
type screwed up? What would windows driver do upon seeing that, and
what is the best way to override it in the kernel?

The practical impact here I think will be during sleep. As taking down
the eDP link is unlikely to work so long as driver thinks it is a CRT.

Also I notice that the backlight block contains these values:

I2C slave addr: 0x58
I2C command: 0xaa

Which are not used in the linux driver. Is this something the windows
driver actually does? Any plans to implement i2c backlight control in
i915?

Regards,

Jon Pry
jon...@gmail.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] broken eDP device types

2014-05-11 Thread Daniel Vetter 
Asus T100 has a mipi dsi panel, and we don't yet have the proper
support for that merged. Hopefully that will get adressed in 3.16. See

https://bugzilla.kernel.org/show_bug.cgi?id=74381

for the overall progress.
-Daniel


On Sun, May 11, 2014 at 6:27 AM, Jon Pry  wrote:
> Hi,
>
>I'm trying to work out some bugs on Asus T100TA which is Baytrail-T
> platform. Current code in use is 3.15_rc4. In general I have been
> having problems with the backlight control. For some reason the kernel
> is detecting the panel as a VGA device and intel_crt.c does not load
> intel_backlight, so I hacked something together real quick and ended
> up getting something that actual changes PWM registers, but this had
> no effect on actual screen brightness.
>
>Without any real solid theory as to why PWM is not doing anything.
> I started wondering why exactly the kernel thinks the panel is VGA
> since it is kind of unlikely the panel is analog especially
> considering Baytrail-T does not have any analog interfaces. So I
> nabbed the VBT to take a look.
>
> Whole thing is here if your interested http://pastebin.com/crht1nDU
>
> Pretty sure the relevant portion is:
>
> EFP device info:
> Device type: 0x1400 (unknown)
> Port: 0x15 (unknown)
> DDC pin: 0x04
> Dock port: 0x00 (N/A)
> HDMI compatible? No
> Info: HDMI certified
> Aux channel: 0x00
> Dongle detect: 0x00
>
> The VBT does include tables for LVDS/eDP operation of the panel. It
> seems just the device type is fubar. So my questions are, why is the
> type screwed up? What would windows driver do upon seeing that, and
> what is the best way to override it in the kernel?
>
> The practical impact here I think will be during sleep. As taking down
> the eDP link is unlikely to work so long as driver thinks it is a CRT.
>
> Also I notice that the backlight block contains these values:
>
> I2C slave addr: 0x58
> I2C command: 0xaa
>
> Which are not used in the linux driver. Is this something the windows
> driver actually does? Any plans to implement i2c backlight control in
> i915?
>
> Regards,
>
> Jon Pry
> jon...@gmail.com
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Design review request: DRM color manager

2014-05-11 Thread Sharma, Shashank 
Gentle reminder. 

Regards
Shashank 
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Sharma, Shashank
Sent: Wednesday, May 07, 2014 7:53 PM
To: Vetter, Daniel; ville.syrj...@linux.intel.com; 
intel-gfx@lists.freedesktop.org
Cc: uma.sha...@intel.com
Subject: [Intel-gfx] Design review request: DRM color manager

Hello all,

As per previous discussions, I am sending the drm-color-manager design for 
review, as inline text. Please have a look and let me know your feedback.

(I tried hard to align the inline text diagram in mail, hope you can see the 
proper picture too)

=
DRM Color Manager
=

- Color manager provides a common interface for all color correction /
   enhancement properties supported by various hardwares.
- Color manager will be one Umbrella DRM property (blob type)
- Driver can register the color correction properties of its HW during
   the init time, and all the corrections can be applied using the same
   interface.

How does a driver register color properties with DRM color manager:
---

- A DRM driver will call drm_register_color_manager() function with following 
information:
.prop_set_handler
.prop_get_hanlder
.color_prop_identifier structure
{porp_name, prop_id}
{porp_name, prop_id}
{porp_name, prop_id}

For example: I915 driver can register as:
.prop_set_handler = intel_clrmgr_set()
.prop_get_hanlder = intel_clrmgr_get()
.color_prop_identifier structure
{gamma_correction, 0}
{csc_correction, 1}
{hue_saturation, 2}



How will color_manager_set/get() functions work:
-

Color EDID:
   ==
|| property || Enable/  || Pipe/Plane/  || No of||  
||  ID  || Disable  || Identifier   || Data bytes   ||data..
|| <1 Byte> || <1 Byte> || <1 Byte> || <1 Byte> || 
==

- Color EDID is a protocol to extract the color correction
   characterictics from a blob, coming from DRM layer
   as property_set_blob() or loading a blob for property_get_blob()

- Userspace will load this blob with corresponding values and use the
   drm_set_blob(color-manager) interface.
- DRM layer of get/set_color_manager() will validate the entry, extract
   the following information from blob
- property
- enable/disable
- identifier
- ptr to start of raw data
- With this information, drm_get/set_color_manager() layer will call
   driver's .get/set_handler()
   which will do the correction using those values.
- Based on the driver's requirement, user space can send any type of
   values in byte stream, like
   direct reg values, correction coefficients or any other form of data.

Benefits of this common interface:
--
- Single interface for all color properties. No need to create multiple
   properties.
- HW agonist. Its in hands of driver to register the properties.
- Any no of properties can be registered.
- Can be clubbed with modeset implementations.




Regards
Shashank

On 5/7/2014 7:41 PM, Sharma, Shashank wrote:
> FYI
>
> -Original Message-
> From: Sharma, Shashank
> Sent: Tuesday, April 22, 2014 8:32 PM
> To: Daniel Vetter
> Cc: David Herrmann; intel-gfx@lists.freedesktop.org; Cn, Ramakrishnan; 
> Jindal, Sonika; Shankar, Uma
> Subject: RE: [Intel-gfx] Design review request: DRM color manager
>
> David,
> My apologies for starting a pre-mature design discussion.
>
> Daniel,
> Thanks for pointing out first two things, It was not known to me, I will take 
> care of this in future.
>
> First time I presented color-manager design, in internal display design 
> forum, where most of the reviewers were not there.
> We took the feedback from people who were present, and implemented the design.
>
> When we shared color manager implementation, that design was rejected and one 
> of the feedbacks was that it would be better to discuss it on dri-devel where 
> people outside Intel can give their opinion, and that’s the only reason why I 
> added dri-devel for the new design (Please see the attached mail, I replied 
> to all who were in last communication).
> Please let me know how do we want to proceed now.
>
>
> Regards
> Shashank
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
> Daniel Vetter
> Sent: Tuesday, April 22, 2014 7:18 PM
> To: Sharma, Shashank
> Cc: David Herrmann; intel-gfx@lists.freedesktop.org; 
> dri-de...@lists.freedesktop.org; Thierry Reding; Cn, Ramakrishnan; 
> Alex Deucher; Jindal, Sonika; Shankar, Uma
> Subject: Re: [Intel-gfx] Design review request: DRM color manager
>
>

Re: [Intel-gfx] [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

2014-05-11 Thread Sagar Arun Kamble 
I support approach using docbook to start since there are not lot of
properties. Laurent has ack'ed this one. Can we go ahead with this?
http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html

Adding description of new property is not very complex (assuming table
format is understood and being comfortable with HTML row/table
manipulation).

Adding description of each property in their source might be time
consuming task.

thanks,
Sagar


On Sat, 2014-05-10 at 06:56 -0400, Rob Clark wrote:
> On Sat, May 10, 2014 at 6:39 AM, Ville Syrjälä
>  wrote:
> > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote:
> >> Hi Sagar,
> >>
> >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote:
> >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote:
> >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote:
> >> > > > On Wed, Mar 5, 2014 at 11:56 AM,   wrote:
> >> > > > > +
> >> > > > > +
> >> > > > > +
> >> > > > > +Owner Module/Drivers
> >> > > > > +Group
> >> > > > > +Property Object
> >> > > > > +Property Name
> >> > > > > +Type
> >> > > > > +Property Values
> >> > > > > +Object attached
> >> > > > > +Description
> >> > > > > +
> >> > > >
> >> > > > In my opinion this is a horrible way to write property documentations
> >> > > > - explicitly constructing html tables is error prone and really hard
> >> > > > to read in the source. Imo docbook in general is rather horrible,
> >> > > > which is way I write almost all my docs as kerneldoc ;-)
> >> > > >
> >> > > > I think a simple asciidoc/markdown would be much simpler, with a bit
> >> > > > of free-form structure to group properties into relevant groups.
> >> > > > Long-term we might even need to split it up into different spec files
> >> > > > to keep a good overview.
> >> > >
> >> > > Docbook is indeed hard to read and write when it comes to such tables.
> >> > > However I like having the properties documented in the DRM core
> >> > > documentation. Maybe we could come up with a simpler text format that
> >> > > would be transformed into docbook when compiling the documentation ?
> >> >
> >> > Does this mean we need to create comment block with "Doc: drm
> >> > properties" style section in each driver where drm properties are
> >> > instantiated. And then in drm.tmpl collect all these using !P escape
> >> > sequence?
> >> > How do create table out of these across all drivers?
> >>
> >> I don't have a strong preference here. Documenting properties in source 
> >> code
> >> comments would be fine, so would an external central documentation file in 
> >> a
> >> non Docbook format. For the record I'm personally fine with using Docbook 
> >> as
> >> in this patch :-)
> >>
> >> If we decide to go for property documentation inside the source code then I
> >> believe we'll have to create our own format, as creating a properties table
> >> from kerneldoc information extracted from comments is probably not 
> >> possible.
> >
> > Can comeone pick up the ball here and figure out what needs to be done?
> >
> > The reason why I want a central place for the documentation is to force
> > people to collaborate outside their own sandbox when adding properties.
> > Whether that's docbook or some text file I don't care so much at this
> > point. The fact that it's a central place should mandate that the
> > patches changing it will go through dri-devel and so everyone should se
> > them, and when adding new properties it would make the patch author more
> > likely to look around a bit before adding another slighty incompatible
> > version of the same property. If someone has a better suggestion how to
> > encforce this I'm all ears.
> >
> > Of course this idea can still fail if our esteemed maintainer merges
> > stuff without checking for violations of this policy. Dave, any thoughts
> > on the subject?
> >
> > Either way I can tell you that I'm not very enthusiastic about reviewing
> > any property patches until some kind of decision about this is reached,
> > be it "docbook", "text", "plan c", or "fuck it, let the world burn!".
> 
> any of the first three options would be vastly superior to what we do now
> 
> tbh, I'd suggest imposing a no-new-properties-without-docs rule even
> if we haven't finished bikeshedding about the docs format.  That might
> motivate someone to hurry up and just pick one.
> 
> We can change the format, figure out some way to get it into docbook,
> etc, later.. it's not such a huge volume of words we have to type here
> that we can't reformat it later.
> 
> BR,
> -R
> 
> 
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3.15-rc5: Regression in i915 driver?

2014-05-11 Thread Chris Wilson 
On Sun, May 11, 2014 at 07:40:57PM +0200, Daniel Vetter wrote:
> On Sun, May 11, 2014 at 11:02 AM, Dave Airlie  wrote:
> > On 11 May 2014 18:28, Thomas Meyer  wrote:
> >> Hi,
> >>
> >> 3.14.3 works as expected.
> >> 3.15-rc5 shows a strange behaviour: When resuming from ram the X server
> >> seems to be disfunctional.
> >>
> >> I see this WARNING in the kernel log before suspend to ram in the early
> >> boot process:
> 
> Doesn't ring a bell really.

Same symptoms as
https://bugs.freedesktop.org/show_bug.cgi?id=76554
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/10] drm: add DP MST encoder type

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

This adds an encoder type for DP MST encoders.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c  | 1 +
 include/uapi/drm/drm_mode.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a3fe324..f1753e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -227,6 +227,7 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
{ DRM_MODE_ENCODER_DSI, "DSI" },
+   { DRM_MODE_ENCODER_DPMST, "DP MST" },
 };
 
 static const struct drm_prop_enum_list drm_subpixel_enum_list[] =
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f104c26..719add4 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -181,6 +181,7 @@ struct drm_mode_get_plane_res {
 #define DRM_MODE_ENCODER_TVDAC 4
 #define DRM_MODE_ENCODER_VIRTUAL 5
 #define DRM_MODE_ENCODER_DSI   6
+#define DRM_MODE_ENCODER_DPMST 7
 
 struct drm_mode_get_encoder {
__u32 encoder_id;
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/10] drm/crtc: add interface to reinitialise the legacy mode group

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

This can be called to update things after dynamic connectors/encoders
are created/deleted.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 include/drm/drm_crtc.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f1753e6..8bf87a6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1421,6 +1421,15 @@ int drm_mode_group_init_legacy_group(struct drm_device 
*dev,
 }
 EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
 
+void drm_reinit_primary_mode_group(struct drm_device *dev)
+{
+   drm_modeset_lock_all(dev);
+   drm_mode_group_destroy(&dev->primary->mode_group);
+   drm_mode_group_init_legacy_group(dev, &dev->primary->mode_group);
+   drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_reinit_primary_mode_group);
+
 /**
  * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo
  * @out: drm_mode_modeinfo struct to return to the user
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c6b9e8a..55bc523 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -916,6 +916,7 @@ extern const char *drm_get_tv_select_name(int val);
 extern void drm_fb_release(struct drm_file *file_priv);
 extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct 
drm_mode_group *group);
 extern void drm_mode_group_destroy(struct drm_mode_group *group);
+extern void drm_reinit_primary_mode_group(struct drm_device *dev);
 extern bool drm_probe_ddc(struct i2c_adapter *adapter);
 extern struct edid *drm_get_edid(struct drm_connector *connector,
 struct i2c_adapter *adapter);
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/10] i915: split some DP modesetting code into a separate function

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

this is just prep work for mst support.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/intel_ddi.c | 20 +---
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e96..a5b8b76 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -364,6 +364,18 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR("FDI link training failed!\n");
 }
 
+void intel_ddi_mode_set_dp(struct intel_encoder *encoder)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(&encoder->base);
+
+   intel_dp->DP = intel_dig_port->saved_port_bits |
+   DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
+   intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
+
+}
+
 static void intel_ddi_mode_set(struct intel_encoder *encoder)
 {
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
@@ -378,13 +390,7 @@ static void intel_ddi_mode_set(struct intel_encoder 
*encoder)
crtc->eld_vld = false;
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
-   struct intel_digital_port *intel_dig_port =
-   enc_to_dig_port(&encoder->base);
-
-   intel_dp->DP = intel_dig_port->saved_port_bits |
-  DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
-   intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count);
-
+   intel_ddi_mode_set_dp(encoder);
if (intel_dp->has_audio) {
DRM_DEBUG_DRIVER("DP audio on pipe %c on DDI\n",
 pipe_name(crtc->pipe));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b885df1..8e41cdc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -683,6 +683,7 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_config *pipe_config);
 
+void intel_ddi_mode_set_dp(struct intel_encoder *encoder);
 
 /* intel_display.c */
 const char *intel_output_name(int output);
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] DisplayPort MST v0.3

2014-05-11 Thread Dave Airlie 
Hi,

A repost of the current state of the displayport MST support for
i915, mainly targetted the Lenovo docks.

Major changes since last posting:
add a path blob property for userspace to use to track topology
provide reference counting, locking and lookups for branch and port structs.
some DocBook!
fix i915 problems with DPMS - ordering of link bring up.
aux channel locking - this should be pushed down I think into the aux helpers,

TODO:
fbcon support:
fix non 4 lane 5.4Ghz.
fix more of state checker harder.

Dave.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/10] drm/i915: add some registers need for displayport MST support.

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

These are just from the Haswell spec.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_reg.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8f84555..557b37a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5386,6 +5386,7 @@ enum punit_power_well {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_BFI_ENABLE  (1<<4)
 
 /* DisplayPort Transport Control */
@@ -5395,6 +5396,7 @@ enum punit_power_well {
 #define  DP_TP_CTL_ENABLE  (1<<31)
 #define  DP_TP_CTL_MODE_SST(0<<27)
 #define  DP_TP_CTL_MODE_MST(1<<27)
+#define  DP_TP_CTL_FORCE_ACT   (1<<25)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1<<18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1<<15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7<<8)
@@ -5409,8 +5411,13 @@ enum punit_power_well {
 #define DP_TP_STATUS_A 0x64044
 #define DP_TP_STATUS_B 0x64144
 #define DP_TP_STATUS(port) _PORT(port, DP_TP_STATUS_A, DP_TP_STATUS_B)
-#define  DP_TP_STATUS_IDLE_DONE(1<<25)
-#define  DP_TP_STATUS_AUTOTRAIN_DONE   (1<<12)
+#define  DP_TP_STATUS_IDLE_DONE(1<<25)
+#define  DP_TP_STATUS_ACT_SENT (1<<24)
+#define  DP_TP_STATUS_MODE_STATUS_MST  (1<<23)
+#define  DP_TP_STATUS_AUTOTRAIN_DONE   (1<<12)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC2  (3 << 8)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC1  (3 << 4)
+#define  DP_TP_STATUS_PAYLOAD_MAPPING_VC0  (3 << 0)
 
 /* DDI Buffer Control */
 #define DDI_BUF_CTL_A  0x64000
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/10] drm: add a path blob property

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

This property will be used by the MST code to provide userspace
with a path to parse so it can recognise connectors around hotplugs.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c | 26 ++
 include/drm/drm_crtc.h |  5 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8bf87a6..06b9255 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1165,6 +1165,7 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
 {
struct drm_property *edid;
struct drm_property *dpms;
+   struct drm_property *dev_path;
 
/*
 * Standard properties (apply to all connectors)
@@ -1179,6 +1180,12 @@ static int 
drm_mode_create_standard_connector_properties(struct drm_device *dev)
   ARRAY_SIZE(drm_dpms_enum_list));
dev->mode_config.dpms_property = dpms;
 
+   dev_path = drm_property_create(dev,
+  DRM_MODE_PROP_BLOB |
+  DRM_MODE_PROP_IMMUTABLE,
+  "PATH", 0);
+   dev->mode_config.path_property = dev_path;
+
return 0;
 }
 
@@ -3637,6 +3644,25 @@ done:
return ret;
 }
 
+int drm_mode_connector_set_path_property(struct drm_connector *connector,
+char *path)
+{
+   struct drm_device *dev = connector->dev;
+   int ret, size;
+   size = strlen(path) + 1;
+
+   connector->path_blob_ptr = drm_property_create_blob(connector->dev,
+   size, path);
+   if (!connector->path_blob_ptr)
+   return -EINVAL;
+
+   ret = drm_object_property_set_value(&connector->base,
+   dev->mode_config.path_property,
+   connector->path_blob_ptr->base.id);
+   return ret;
+}
+EXPORT_SYMBOL(drm_mode_connector_set_path_property);
+
 /**
  * drm_mode_connector_update_edid_property - update the edid property of a 
connector
  * @connector: drm connector
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 55bc523..e33959b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -500,6 +500,8 @@ struct drm_connector {
struct drm_property_blob *edid_blob_ptr;
struct drm_object_properties properties;
 
+   struct drm_property_blob *path_blob_ptr;
+
uint8_t polled; /* DRM_CONNECTOR_POLL_* */
 
/* requested DPMS state */
@@ -774,6 +776,7 @@ struct drm_mode_config {
struct list_head property_blob_list;
struct drm_property *edid_property;
struct drm_property *dpms_property;
+   struct drm_property *path_property;
struct drm_property *plane_type_property;
 
/* DVI-I properties */
@@ -926,6 +929,8 @@ extern void drm_mode_config_init(struct drm_device *dev);
 extern void drm_mode_config_reset(struct drm_device *dev);
 extern void drm_mode_config_cleanup(struct drm_device *dev);
 
+extern int drm_mode_connector_set_path_property(struct drm_connector 
*connector,
+   char *path);
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);
 extern int drm_object_property_set_value(struct drm_mode_object *obj,
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/10] drm/i915: check connector->encoder before using it.

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

DP MST will need connectors that aren't connected to specific
encoders, add some checks in advance to avoid oopses.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 16 +---
 drivers/gpu/drm/i915/i915_irq.c  |  4 
 drivers/gpu/drm/i915/intel_display.c | 25 ++---
 3 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..88e944f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2279,13 +2279,15 @@ static void intel_connector_info(struct seq_file *m,
seq_printf(m, "\tCEA rev: %d\n",
   connector->display_info.cea_rev);
}
-   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
-   intel_encoder->type == INTEL_OUTPUT_EDP)
-   intel_dp_info(m, intel_connector);
-   else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
-   intel_hdmi_info(m, intel_connector);
-   else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
-   intel_lvds_info(m, intel_connector);
+   if (intel_encoder) {
+   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_encoder->type == INTEL_OUTPUT_EDP)
+   intel_dp_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_HDMI)
+   intel_hdmi_info(m, intel_connector);
+   else if (intel_encoder->type == INTEL_OUTPUT_LVDS)
+   intel_lvds_info(m, intel_connector);
+   }
 
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index afa5519..5852dee 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1016,6 +1016,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
dev_priv->hpd_event_bits = 0;
list_for_each_entry(connector, &mode_config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+   if (!intel_connector->encoder)
+   continue;
intel_encoder = intel_connector->encoder;
if (intel_encoder->hpd_pin > HPD_NONE &&
dev_priv->hpd_stats[intel_encoder->hpd_pin].hpd_mark == 
HPD_MARK_DISABLED &&
@@ -1046,6 +1048,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
 
list_for_each_entry(connector, &mode_config->connector_list, head) {
intel_connector = to_intel_connector(connector);
+   if (!intel_connector->encoder)
+   continue;
intel_encoder = intel_connector->encoder;
if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
if (intel_encoder->hot_plug)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b39d036..75b2aaf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4600,20 +4600,23 @@ static void intel_connector_check_state(struct 
intel_connector *connector)
 "wrong connector dpms state\n");
WARN(connector->base.encoder != &encoder->base,
 "active connector not linked to encoder\n");
-   WARN(!encoder->connectors_active,
-"encoder->connectors_active not set\n");
 
-   encoder_enabled = encoder->get_hw_state(encoder, &pipe);
-   WARN(!encoder_enabled, "encoder not enabled\n");
-   if (WARN_ON(!encoder->base.crtc))
-   return;
+   if (encoder) {
+   WARN(!encoder->connectors_active,
+"encoder->connectors_active not set\n");
+
+   encoder_enabled = encoder->get_hw_state(encoder, &pipe);
+   WARN(!encoder_enabled, "encoder not enabled\n");
+   if (WARN_ON(!encoder->base.crtc))
+   return;
 
-   crtc = encoder->base.crtc;
+   crtc = encoder->base.crtc;
 
-   WARN(!crtc->enabled, "crtc not enabled\n");
-   WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
-   WARN(pipe != to_intel_crtc(crtc)->pipe,
-"encoder active on the wrong pipe\n");
+   WARN(!crtc->enabled, "crtc not enabled\n");
+   WARN(!to_intel_crtc(crtc)->active, "crtc not active\n");
+   WARN(pipe != to_intel_crtc(crtc)->pipe,
+"encoder active on the wrong pipe\n");
+   }
}
 }
 
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lis

[Intel-gfx] [PATCH 10/10] i915: mst topology dumper in debugfs

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

use the mst helper code to dump the topology in debugfs.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 88e944f..b8a9a51 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2378,6 +2378,31 @@ struct pipe_crc_info {
enum pipe pipe;
 };
 
+static int i915_dp_mst_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_encoder *encoder;
+   struct intel_encoder *intel_encoder;
+   struct intel_digital_port *intel_dig_port;
+   drm_modeset_lock_all(dev);
+   list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+   intel_encoder = to_intel_encoder(encoder);
+   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
+   continue;
+   intel_dig_port = enc_to_dig_port(encoder);
+   if (!intel_dig_port->dp.can_mst)
+   continue;
+
+   if (!intel_dig_port->dp.is_mst)
+   continue;
+
+   drm_dp_mst_dump_topology(m, &intel_dig_port->dp.mst_mgr);
+   }
+   drm_modeset_unlock_all(dev);
+   return 0;
+}
+
 static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
 {
struct pipe_crc_info *info = inode->i_private;
@@ -3813,6 +3838,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_pc8_status", i915_pc8_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_display_info", i915_display_info, 0},
+   {"i915_dp_mst_info", i915_dp_mst_info, 0},
 };
 #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
 
-- 
1.9.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/10] drm/dp_helper: add defines for DP 1.2 and MST support.

2014-05-11 Thread Dave Airlie 
From: Dave Airlie 

This just adds the defines from the DP 1.2 spec, which we
will use later.

Signed-off-by: Dave Airlie 
---
 include/drm/drm_dp_helper.h | 78 +
 1 file changed, 78 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index cfcacec..879836d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -37,6 +37,7 @@
  * eDP: Embedded DisplayPort version 1
  * DPI: DisplayPort Interoperability Guideline v1.1a
  * 1.2: DisplayPort 1.2
+ * MST: Multistream Transport - part of DP 1.2a
  *
  * 1.2 formally includes both eDP and DPI definitions.
  */
@@ -103,9 +104,14 @@
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
 
 /* Multiple stream transport */
+#define DP_FAUX_CAP0x020   /* 1.2 */
+# define DP_FAUX_CAP_1 (1 << 0)
+
 #define DP_MSTM_CAP0x021   /* 1.2 */
 # define DP_MST_CAP(1 << 0)
 
+#define DP_GUID0x030   /* 1.2 */
+
 #define DP_PSR_SUPPORT  0x070   /* XXX 1.2? */
 # define DP_PSR_IS_SUPPORTED1
 #define DP_PSR_CAPS 0x071   /* XXX 1.2? */
@@ -221,6 +227,16 @@
 # define DP_PSR_CRC_VERIFICATION   (1 << 2)
 # define DP_PSR_FRAME_CAPTURE  (1 << 3)
 
+#define DP_ADAPTER_CTRL0x1a0
+# define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE   (1 << 0)
+
+#define DP_BRANCH_DEVICE_CTRL  0x1a1
+# define DP_BRANCH_DEVICE_IRQ_HPD  (1 << 0)
+
+#define DP_PAYLOAD_ALLOCATE_SET0x1c0
+#define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1
+#define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2
+
 #define DP_SINK_COUNT  0x200
 /* prior to 1.2 bit 7 was reserved mbz */
 # define DP_GET_SINK_COUNT(x)  x) & 0x80) >> 1) | ((x) & 0x3f))
@@ -230,6 +246,9 @@
 # define DP_REMOTE_CONTROL_COMMAND_PENDING  (1 << 0)
 # define DP_AUTOMATED_TEST_REQUEST (1 << 1)
 # define DP_CP_IRQ (1 << 2)
+# define DP_MCCS_IRQ   (1 << 3)
+# define DP_DOWN_REP_MSG_RDY   (1 << 4) /* DP MST */
+# define DP_UP_REQ_MSG_RDY (1 << 5) /* DP MST */
 # define DP_SINK_SPECIFIC_IRQ  (1 << 6)
 
 #define DP_LANE0_1_STATUS  0x202
@@ -294,6 +313,13 @@
 #define DP_TEST_SINK   0x270
 #define DP_TEST_SINK_START (1 << 0)
 
+#define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
+# define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
+# define DP_PAYLOAD_ACT_HANDLED (1 << 1)
+
+#define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1   /* 1.2 MST */
+/* up to ID_SLOT_63 at 0x2ff */
+
 #define DP_SOURCE_OUI  0x300
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
@@ -303,6 +329,21 @@
 # define DP_SET_POWER_D30x2
 # define DP_SET_POWER_MASK  0x3
 
+#define DP_SIDEBAND_MSG_DOWN_REQ_BASE  0x1000   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_UP_REP_BASE0x1200   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_DOWN_REP_BASE  0x1400   /* 1.2 MST */
+#define DP_SIDEBAND_MSG_UP_REQ_BASE0x1600   /* 1.2 MST */
+
+#define DP_SINK_COUNT_ESI  0x2002   /* 1.2 */
+/* 0-5 sink count */
+# define DP_SINK_COUNT_CP_READY (1 << 6)
+
+#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0   0x2003   /* 1.2 */
+
+#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1   0x2004   /* 1.2 */
+
+#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
+
 #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
 # define DP_PSR_LINK_CRC_ERROR  (1 << 0)
 # define DP_PSR_RFB_STORAGE_ERROR   (1 << 1)
@@ -319,6 +360,43 @@
 # define DP_PSR_SINK_INTERNAL_ERROR 7
 # define DP_PSR_SINK_STATE_MASK 0x07
 
+/* DP 1.2 Sideband message defines */
+/* peer device type - DP 1.2a Table 2-92 */
+#define DP_PEER_DEVICE_NONE0x0
+#define DP_PEER_DEVICE_SOURCE_OR_SST   0x1
+#define DP_PEER_DEVICE_MST_BRANCHING   0x2
+#define DP_PEER_DEVICE_SST_SINK0x3
+#define DP_PEER_DEVICE_DP_LEGACY_CONV  0x4
+
+/* DP 1.2 MST sideband request names DP 1.2a Table 2-80 */
+#define DP_LINK_ADDRESS0x01
+#define DP_CONNECTION_STATUS_NOTIFY0x02
+#define DP_ENUM_PATH_RESOURCES 0x10
+#define DP_ALLOCATE_PAYLOAD0x11
+#define DP_QUERY_PAYLOAD   0x12
+#define DP_RESOURCE_STATUS_NOTIFY  0x13
+#define DP_CLEAR_PAYLOAD_ID_TABLE  0x14
+#define DP_REMOTE_DPCD_READ0x20
+#define DP_REMOTE_DPCD_WRITE   0x21
+#define DP_REMOTE_I2C_READ 0x22
+#define DP_REMOTE_I2C_WRITE0x23
+#define DP_POWER_UP_PHY0x24
+#define DP_POWER_DOWN_PHY  0x25
+#define DP_SINK_EVENT