[Intel-gfx] broken eDP device types
Kumar, Shobhit
shobhit.kumar at intel.com
Thu May 15 06:32:26 CEST 2014
On 5/15/2014 6:05 AM, Jon Pry wrote:
> 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.
>
The basic DSI sequence is merged already and the panel driver is under
review in the list. Those patches did apply on drm-intel-nightly at the
time of posting and I can confirm that they do work on AsusT100.
Back-light is another issue altogether and needs PMIC driver to control
PWM. The support is not yet up-streamed but does not stop at least
booting Asus T100 to UI with the patches.
Regards
Shobhit
> -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
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
More information about the Intel-gfx
mailing list