[Intel-gfx] broken eDP device types

[Jon Pry]

Do you know if the DSI patch set is being maintained? I noticed it is
not integrated into drm-intel-next, the patches don't apply cleanly to
anything, and there has been no activity in about a month on them.

-Jon

On Sun, May 11, 2014 at 1:45 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 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 <jonpry at gmail.com> 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
>> jonpry at gmail.com
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at 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