Monday, 2013-11-18

*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:01
*** gabrbedd <gabrbedd!~gabrbedd@vs1738.corenetworks.net> has quit IRC00:41
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #minnowboard00:50
*** aholler_ <aholler_!~aholler@p57B233E6.dip0.t-ipconnect.de> has joined #minnowboard04:54
*** aholler <aholler!~aholler@p57B22F19.dip0.t-ipconnect.de> has quit IRC04:58
*** aholler_ is now known as aholler07:37
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #minnowboard10:24
*** jkridner|work <jkridner|work!~jkridner@c-98-250-142-42.hsd1.mi.comcast.net> has joined #minnowboard10:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC10:34
*** jkridner|work <jkridner|work!~jkridner@c-98-250-142-42.hsd1.mi.comcast.net> has quit IRC13:16
*** patrik <patrik!~patrik@h138n8-oer-a32.ias.bredband.telia.com> has joined #minnowboard13:21
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #minnowboard14:15
*** prpplague <prpplague!~prpplague@107-206-64-184.lightspeed.rcsntx.sbcglobal.net> has quit IRC14:47
*** gabrbedd <gabrbedd!~gabrbedd@vs1738.corenetworks.net> has joined #minnowboard15:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC15:30
*** prpplague <prpplague!~danders@rrcs-97-77-26-26.sw.biz.rr.com> has joined #minnowboard15:57
*** thaytan_ <thaytan_!~thaytan@113.94.233.220.static.exetel.com.au> has quit IRC16:12
*** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has joined #minnowboard16:13
*** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has quit IRC16:16
*** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has joined #minnowboard16:16
*** zenlinux_ <zenlinux_!~sgarman@c-24-20-145-95.hsd1.or.comcast.net> has joined #minnowboard16:40
*** zenlinux_ <zenlinux_!~sgarman@c-24-20-145-95.hsd1.or.comcast.net> has quit IRC16:56
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #minnowboard18:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:03
*** bluelightning_ is now known as bluelightning18:03
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC18:10
*** jayneil <jayneil!~jayneil@cpe-173-175-241-63.tx.res.rr.com> has joined #minnowboard18:51
*** bluelightning_ <bluelightning_!~paul@83.217.123.106> has joined #minnowboard19:04
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #minnowboard19:04
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:08
*** zenlinux <zenlinux!~sgarman@masterfoo.zenlinux.com> has joined #minnowboard19:27
*** dvhart <dvhart!dvhart@nat/intel/x-nugbdhqehpvkmati> has joined #minnowboard21:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #minnowboard21:44
patrikdvhart, ping about LVDS21:46
dvhartpong21:47
dvhartpatrik, what's up?21:47
*** zenlinux <zenlinux!~sgarman@masterfoo.zenlinux.com> has quit IRC21:47
patrikdvhart, Will it be EEPROM -> I2C -> GPIO?21:48
dvharthrm... will what be?21:48
*** zenlinux <zenlinux!~sgarman@masterfoo.zenlinux.com> has joined #minnowboard21:48
dvhartThe DDC signal?21:49
patrikHow are you going to hook it up?21:49
dvhartI don't know much about the display side of the equation, but from the minnow side, the CPU has a mix of hardware muxed pins for LVDS signals and software muxed pins for the LVDS DDC signals.21:50
prpplaguepatrik: based on my understanding, the ddc pins are muxed with the gpio functions21:50
prpplaguepatrik: that when the EMGD is started it enables them as DDC(i2c) interface21:51
dvhartthe gma500 driver should play nice with the sch_gpio driver so they do not both try to use the gpio lines21:51
patrikOk, was just scared you might have taken some firmware approach21:51
dvhartI would suggest using the i2c_gpio driver to claim the 2 software muxed gpio lines from the gpio-sch driver using gpiolib21:51
prpplaguepatrik: now with that said, my information is very limited, and i have heard that the interface for the ddc is basically just bit-banging i2c via gpio21:51
dvhartthat is correct21:53
dvharta better approach, although still bit banging, would be to use the i2c_gpio driver which at least doesn't fight the system for ownership of the GPIO registers21:53
dvhartI'm working with the EMGD devs to do something similar21:53
prpplagueand not only that, but if you tied that into the existing EDID functions in the kernel....21:54
dvhartpatrik, the firmware may disable the lines in the RGEN register if LVDS is detected to indicate to EMGD they can use them, but that doesn't actually impact the driver (oddly enough)21:54
dvhartprpplague, right, it's all about playing nice with existing infrastructure, that's one of the biggest problems with the emgd driver currently.21:55
dvhartpatrik, does that... help?21:55
patrikyes, emgd tries to be somewhat OS agnostic :)21:55
patrikdvhart, yes, that's all I need to know for now21:56
dvhartpatrik, yes, and breaks GPIO functionality in the process.... doh.21:56
patriksome people might also find it useful to hook up a panels I2C pins (if the panel provides them) since the FPDLink-I connector doesn't carry them21:58
dvhartpatrik, that sort of Lure description will eventually be done via ACPI _PRP properties in an EEPROM on the Lure itself.21:59
patrikdvhart, ah ok22:02
prpplaguepatrik: right FPD-Link-I doesn't spec i2c/edid, but pretty much all the stock panels include one22:03
patrikprpplague, ok, if possible I'd like to get my hands on some hardware. I think the mode programming for LVDS is actually working right now but I have no way to test it.22:09
patrikor if any of you would like to tinker with gma500 and lvds that would be great22:11
*** jayneil <jayneil!~jayneil@cpe-173-175-241-63.tx.res.rr.com> has quit IRC22:12
patrikgma500 tries really hard to find a mode in various places and then it just guesses a panel but I had to rip that out in order for it to fail gracefully and pick sdvo instead22:13
patrikdvhart, just fyi, emgd probes scratchpad registers written by bios to find available outputs but I guess we can't do that on the minnow but as you say, will go for the ACPI properties provided by the lure22:18
dvhartright22:19
prpplaguepatrik: i have some basic breakout boards, but nothing ready for production22:23
prpplaguepatrik: basically a hookup for a 10.1" lvds panel22:23
patrikprpplague, I'm not that good with the soldering iron so then it's better to wait ;)22:25
prpplaguepatrik: so you think you have the module actually working?22:26
patrikI got plenty of gma500 bugs to hunt down anyways and tons of refactoring to do so no time wasted22:26
patrikprpplague, gma500 works with Minnow SDVO for all monitors I've tested with. The patches have already been pulled by Linus for 3.13-rc122:27
patrikprpplague, Or did you mean LVDS?22:29
prpplaguepatrik: i was under the impression that there had to be some things done in the UEFI for the lvds22:30
prpplaguepatrik: for lvds i mean22:30
patrikprpplague, If you provide a panel mode to gma500 it should/could work but I might be missing something. The lvds code right now is working for Oaktrail and I'm thinking they are pretty much alike22:32
prpplaguepatrik: interesting22:32
prpplaguepatrik: the intel folks kept pushing me to some windows tool that was needed to create configurations for the uefi22:33
patrikprpplague, and lvds is on pipe a which is much more sane then sdvo (pipe b) which floats around in various io maps22:33
patrikprpplague, that sounds like they're asking you to generate a vbios. That shouldn't be needed if we can get all panel data via gpio22:34
prpplaguepatrik: ahh dandy22:34
patrikprpplague, but who knows ;)22:35
prpplagueindeed22:37
prpplaguepatrik: no guarantees, but i'll see if i can get some hardware together for you shortly22:38
dvhartpatrik, what do you suppose the difficulty will be to backport those to 3.10?22:38
dvhartpatrik, I'm testing my 3.10 BSP now... but if I could add gma500 support, and get that into LTSI 3.10, that would be awesome.22:39
* dvhart attempts a backport....22:39
prpplaguepatrik: i've got a variation of this kit almost ready for minnow - http://www.tincantools.com/10.1-LVDS-LCD-Kit-with-a-Chunghwa-CLAA101NB01-10.1-LVDS-LCD.html22:39
patrikdvhart, should be doable, I'm mostly touching the oaktrail_ files which are quite DRM core independent22:42
patrikprpplague, that looks nice22:43
*** prpplague <prpplague!~danders@rrcs-97-77-26-26.sw.biz.rr.com> has quit IRC23:01
*** jayneil <jayneil!~jayneil@cpe-173-175-241-63.tx.res.rr.com> has joined #minnowboard23:03
*** zenlinux <zenlinux!~sgarman@masterfoo.zenlinux.com> has quit IRC23:03
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #minnowboard23:07
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC23:10
*** jkridner <jkridner!~jkridner@c-98-250-142-42.hsd1.mi.comcast.net> has joined #minnowboard23:10
*** jkridner <jkridner!~jkridner@c-98-250-142-42.hsd1.mi.comcast.net> has quit IRC23:10
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #minnowboard23:10
patrikdvhart, crap, it's messy to backport it to 3.10 because of my chip unifying code23:20
patrikThe unifying is ~30 patches which the clock stuff in oaktrail_crtc.c needs to behave properly. IIRC that landed in 3.11.23:22
dvhartack23:25
dvhartthanks23:25
*** dvhart <dvhart!dvhart@nat/intel/x-nugbdhqehpvkmati> has quit IRC23:39
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:59

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!