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