broken eDP device types

broken eDP device types

[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
jonpry@gmail.com

Re: broken eDP device types

[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 <jonpry@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@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

Re: 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@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@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@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

Re: broken eDP device types

[Kumar, Shobhit]

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@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@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@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
>