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