Re: broken eDP device types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux