cnxsoft changed the topic of #imx6-dongle to: i.MX6 HDMI Dongle Software Development. You can also join us at https://groups.google.com/forum/?fromgroups#!forum/imx6-dongle - IRC Logs - http://irclog.whitequark.org/imx6-dongle/
<hroth> So you can "echo Y | i2cdump <bus> 0x50" where <bus> is your EDID EEPROM i2c bus?
<abrasive> i don't have the stick running atm
<abrasive> but there's an 'edid' file under the hdmi driver in sysfs
<abrasive> mine is not all zeroes.
<abrasive> does i2cdetect show any acks?
<abrasive> i get addresses 50 and 51 coming back on i2c-1 (as well as a couple of others)
Noskcaj has quit [Ping timeout: 256 seconds]
Noskcaj has joined #imx6-dongle
<hroth> Not me. when I run i2dump it says "Device or resource busy". Here's what dmesg reads:
<hroth> It's not all zeros - it just cannot access the bus.
Noskcaj has quit [Ping timeout: 256 seconds]
Noskcaj has joined #imx6-dongle
<hroth> Also - question about the governor. When I run cpufreq-info it says "no or unknown cpufreq driver is active on this CPU". Do I need to compile a specific module?
<hroth> Or am I just looking in the wrong place?
<abrasive> that's interesting.
<abrasive> it might be a dodgy kernel? puzzling.
<abrasive> can you try http://neuro.axdf.net/~jhl/pub/uImage ?
<abrasive> should at least have cpufreq up
<hroth> Sure. Right now as I compile the kernel it gets too hot (even with the case on). Is there a simple hardcoded way to throttle the cpu?
<hroth> Thanks, I'll grab that kernel.
<abrasive> there should be a cur_freq entry in sysfs
<abrasive> that is writable within a range
<abrasive> have a find.
<hroth> Thanks
<hroth> You must be write about a dodgy kernel. find /sys -name cur_freq doesn't turn up anything.
<hroth> +right
<abrasive> i'd look for *cur_freq* actually
<abrasive> pretty sure it's not calle that.
<abrasive> also check /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
<hroth> Hmmm.. nothing. I'm not the only one it seems. My console is crying "cooling: cpu cur freq is 0" "thermal_notify: trip_hot reached!" and "cooling: can't get cpufreq current operating point!"
<abrasive> yuck
<abrasive> get a real kernel.
<hroth> Yup.
<abrasive> i think jas built his kernels without cpufreq for a while, maybe he still does
<abrasive> cpufreq is unstable on vendor u-boots with bad DRAM configuration at boot, but we fixed that in ours months ago
<hroth> Was hoping to compile my own but I'm having to hit Ctrl-Z.
<hroth> Yes, this the latest jas kernel from his blog post yesterday.
<hroth> Whew - has come down from 92 to 66.
<hroth> Time to "fg" again...
<hroth> Oops. Have to go - but that kernel you mentioned at neuro.axdf - I'm having trouble with the modules. What is the uname -r for that version of the kernel?
Noskcaj has quit [Ping timeout: 264 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 252 seconds]
Noskcaj has joined #imx6-dongle
<abrasive> hroth: i'm sorry, i don't recall
<abrasive> i think it had all the needful compiled in though
<abrasive> you can't get it to boot?
Noskcaj has quit [Ping timeout: 260 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 264 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 246 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 264 seconds]
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Ping timeout: 256 seconds]
Noskcaj has joined #imx6-dongle
<hroth> No, couldn't get it to boot properly. It's working now with jas's earlier kernel with cpufreq off his blog. (hosted at miniand).
<abrasive> fair enough.
<abrasive> it might have a baked-in commandline that doesn't suit your setup
<hroth> Still struggling with kernel compilation. I hadn't realized it could throttle the CPU *that* much... dmesg says: "cooling: cpu cur freq is 792 000 000; cooling: cpu max freq set to 792 000" That's a lot lower! Time to cross-compile...
<abrasive> crossing should be fairly easy. what is your host OS?
<hroth> Yes should be fine. VMWare Player on an Ubuntu 10.04 (also have a 12.04) server.
<hroth> One thing is interesting - all these kernels and none of them can read from EDID.
<abrasive> my $2 is still on the hardware.
<abrasive> different, if not broken
<hroth> Yes. I was looking at the Freescale HDMI ref design (which may or may not be the same) and for the HDMI I2C connection it looks like they use the GPIOs. I wonder if I need to enable I2C via GPIO in the kernel... As you said, maybe they moved it onto a different I2C bus.
<abrasive> i highly doubt it
<abrasive> only one of the i2c ports supports HDCP, as far as i know
<abrasive> and on my board, that's the port they used (I2C2 on the chip, which is i2c-1 under linux)
<hroth> EDID is DRM protected?
<abrasive> no, but HDCP depends on the DDC link
<abrasive> the HDCP engine on the chip takes over the i2c link from the host controller
<hroth> Hmmm. So my V2.4 brethren may have trouble if we actually used HDCP.
<abrasive> which we never will, so.
<abrasive> that's assuming that they're using a different i2c port
<abrasive> there may be some other explanation.
<abrasive> it does suggest we'll have to figure out how to tell the difference between the revs from software, which doesn't strike me as fun.
<hroth> I wonder if a better approach might be for me to load in the 1.65.4 Android firmware from Richtechie and look a bit closer at dmesg at boot.
<abrasive> afaik, they ignore edid entirely
<abrasive> and force either 720p or 1080p depending on user selection
<hroth> Oh, interesting..
<hroth> Well, if they didn't even design for it, I suppose I'll have to force things anyway.
<abrasive> yes, well. unfortunately the kernel makes it hard to force a video mode that isn't supplied by EDID
<abrasive> we might need to patch for that if we can't figure out how to get EDID up on your rev
<abrasive> but if we can, there should be a more elegant solution.
<hroth> (?) passing through the videomode from u-boot seemed to work fine for me.
<abrasive> interesting. i've heard of problems.
<hroth> My main problem was using that old u-boot that has nothing to do with the compiled one to pass through setenv's.
<abrasive> CEA modes might work OK, there's a table of those in the kernel somewhere.
<hroth> video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 worked well.
<hroth> dmesg during boot responds: fbcvt: 1920x1080@60: CVT Name - 2.073M9
<abrasive> oh, great.
<abrasive> one more thing off the to-do list then!
<abrasive> wait, that *is* a CEA mode
<hroth> I know nothing about CEA modes, but this might be relevant; http://boundarydevices.com/hdmi-cea-mode/; I can see my mode in there, I think.. 16?
Juggie has quit [Read error: Operation timed out]
<abrasive> CEA sets the standard HDTV modes.
<abrasive> and there's a table of them in the kernel
<abrasive> but there isn't an equivalent table for non-HDTV modes, even ones that are common in PC monitors like 1280x1024
<abrasive> so to set those, you need EDID
<hroth> Oh, I see.
<hroth> Yes, I have a 16:9 monitor.
<abrasive> i pushed a very similar patch to theirs to our tree ages ago
<hroth> Thinking outside the box.. I don't suppose we could add some common VESA modes to mxc_edid.c?
<abrasive> yes, but i'd still rather fix the problem at the source
Juggie has joined #imx6-dongle
<hroth> Sure. I just find it rough when the designers themselves ignore EDID.
<abrasive> it's a bit crap, but as far as whitebox designs go, it's reasonably solid.
<abrasive> when I was working on linux for WM8505 based netbooks a few years ago, i found out that about half the machines in the wild had the SD card write protect line backwards relative to the other half
<hroth> I just mean in some revision they could have taken over the i2c clk or data for some other purpose and they wouldn't care about it.
<hroth> I think it's still a bargain for $69.
<abrasive> yeah, i don't know what the reason for the engineering change might be. maybe they just left off the parts to save cash. you've still got 3 SOT23 transistors next to the HDMI connector, right?
<hroth> Hold, please.
<abrasive> it's a great deal. based on freescale is a great win. it's only the 3d/video support that's closed and consequently shitty
<hroth> Those chips are very tiny. I'm assuming, yes.
<abrasive> yeah, little 3-legged things
<hroth> (Are they on the same side as the CPU?
<abrasive> can't remember. probably.
<abrasive> they're on top when the board is in its sled
<hroth> Yep, 3x 3-legged things.
<abrasive> so they haven't ditched the functionality.
<abrasive> it's just not working!
<abrasive> when you get a chance to get a scope on to them then can do some debugging.
<hroth> Yes. After getting set up on the Bus Pirate first to look at the I2C I just realized it's the wrong i2c bus.
<abrasive> ?
<hroth> Let me grab my scope.
hste has quit [Ping timeout: 240 seconds]
<hroth> Alrighty.. All set. What do you suggest I capture with the scope.
<hroth> Just curious. Is anyone working on integrating the on-board bluetooth/FM radio?
<abrasive> BT works.
<abrasive> or so i hear
<abrasive> FM i'm not sure if the audio is wired in
<abrasive> so, the USB connector shield is a good place for your ground clip
<abrasive> i suggest looping some i2c access in the shell
<abrasive> then probing around those transistors i mentioned
<abrasive> the single transistor on one side translates SCL from 3.3 to 5 volts
<abrasive> and the pair on the other side push SDA between 3.3 and 5 also
<hroth> You just want to make sure they are level shifting properly?
<abrasive> you should be able to see the bits coming past
<abrasive> i doubt it's the shifting that's the issue, but either there's a signal integrity problem, or it's the plain old wrong bus
<hroth> ok. how fast is this bus supposed to be?
<abrasive> 100khz
<hroth> ok.. just perturb it with the i2cdump?
<abrasive> yeah. i'd do something like
<abrasive> while true; do echo Y | i2cdump...; done
<hroth> hmm. no dice. It just streams "Error: Could not set address to 0x50: Device or resource busy" across the screen and there's nothing actually there.
<hroth> They are all pretty much flat at ground.
<abrasive> the "device or resource busy" comes from not getting an ACK from the device, i think
<abrasive> hroth: is there any activity on the other pins on the serial header connector?
<abrasive> i think a couple of them are attached to one of the i2c buses
<abrasive> also, if you can try with the other numbered i2c buses, that'd be good.
<hroth> Looked there too.. it says "I2C 3" on the cnx-software blog post but I don't see "3" on my available devices. I *can* i2cdump dev 2.
<hroth> Boy, tried it on the header and there's nothing. I'll speak Bus Pirate to that exposed bus and see what it says.
<hroth> Are there any headers or signatures for the EDID block?
<abrasive> if it's not coming up on your scope, nothing's doing.
<abrasive> um, probably.
<abrasive> but i2c idles high
<abrasive> so that suggests the pins are not being properly configured.
<abrasive> which u-boot are you using? it shouldn't matter, but...
<hroth> Right.. I'm using jas's u-boot_multiboot.imx. The Bus Pirate does speak i2c so I can inquire 0x50 but don't know if there's a fast way to see if EDID is read out there.
<abrasive> do you have gpiodev on your system - is /sys/class/gpio present?
<hroth> yes.
<abrasive> okay. so, we can try and figure out which SoC pin those i2c lines are wired to.
<abrasive> let me quickly clone the kernel source here so i can dig along
<hroth> Right..
<abrasive> so... candidates for I2C2 SCL are GPIO_2_30, and GPIO_4_12
<abrasive> the latter is the default used by our kernel
<abrasive> the kernel pin numbering is different to the SoC bank numbering (sigh) so the number is (2-1)*32 + 30
<abrasive> which is 62 if today is a good day
<abrasive> so echo 62 > /sys/class/gpio/export, echo out > /sys/class/gpio/gpio62/direction, and echo 1 > /sys/class/gpio/gpio62/value
<abrasive> then if that was the right line the SCL output (single transistor side) will now be high.
hroth920 has joined #imx6-dongle
<hroth920> Got it.
<abrasive> and if that doesn't work... we might have to be a bit more creative
<hroth920> Dumb question - how do you know it is I2C2 that is the bus (say, instead of I2C3)?
<abrasive> i'm assuming that they're still using it because it's the only one that muxes with HDCP
<hroth920> Got it, again.
<hroth920> Give me a few minutes..
<abrasive> no rush :)
<hroth920> Actually, do you have the GPIO for I2C3 ? That's the one brought out on the serial header and I'd feel better with a known good to make sure my testing jig is working.
<abrasive> yeah, sure
<abrasive> one sec
<hroth920> Also - have you read this thread: "http://www.armtvtech.com/armtvtechforum/viewtopic.php?f=137&t=1984" where conversy appears to have solved EDID by building a kernel. I don't know their config.
<abrasive> GPIO_3_17 or GPIO_1_3 or GPIO_1_5
Noskcaj has quit [Ping timeout: 252 seconds]
<abrasive> which converts to 81, 3, and 5
<hroth920> Those three are all possibilities for I2C3 SCL?
<abrasive> yep
Noskcaj has joined #imx6-dongle
<hroth920> It's only $69 but any idea on where else I might be asserting high... ? :)
<abrasive> if the iomux on those pins isn't configured for GPIO (which most are by default, i think, but not all), then that might not get you far
<abrasive> you could use the method i used to find the wifi enable GPIO - just set every available GPIO to high, then if that gets you there, binary search for which one you're looking for
<abrasive> for i in `seq 0 256`; do [set pin to output] [set pin to high]; done
<abrasive> that's the easiest way to find if any of these pins are set to gpio...
<hroth920> If I can echo the pin number to the console this might not require a binary search.
<hroth920> Not sure I have the hang of the algorithm there, though.
<abrasive> well, i did it with echoing and pausing between each pin
<abrasive> but if you just want to know up front if this is going to work, just set them all high and figure it out later :)
hroth920 has quit [Quit: irc2go]
<hroth> Hmmm... 3, 5, and 81 didn't make I2C3 SCL assert high.
<hroth> Let me check them all... after I compile my kernel.
<hroth> Perhaps I'm not doing something correctly... but nothing happened. gpio0, gpio32, gpio171, gpio224+ didn't write but the others did and no dice.
<abrasive> then the muxes are set to something else.
<abrasive> it could be that they *are* set to i2c and that something is wrong in its initialisation or similar
Noskcaj has quit [Ping timeout: 252 seconds]
<hroth> Well, I'll have to pack it in - but just continue the IRC and I'll check tomorrow on any other ideas you may have.
<hroth> From the IRC log
<abrasive> thanks for the efforts, it's very illuminating
<abrasive> i (and all other users of that revision!) appreciate it :)
<hroth> Not a problem; you guys are doing a tremendous job of making a $69 SoC dev board.
<hroth> PS: Are there any logs/posts on that Bluetooth working? I haven't seen it in any kernel I've looked at.
<abrasive> um.
<abrasive> you can get it chatting with hciattach
<abrasive> i haven't actually gotten any further than that, but that does work
<abrasive> it may be that we aren't configuring the pinmuxes though and that only worked with vendor u-boot, but that's highly unlikely
<abrasive> i think it's on ttymxc1 if you want to give it a try
<hroth> I'll try that.
<projectgus> abrasive: do you need to compile a special hciattach with an 'rda' mode? I found a source download for that the other day
<abrasive> you do if you want to go above 115200 baud
<projectgus> but I haven't tried using it either in a generic mode or with the patched hciattach
<projectgus> oic
<abrasive> i *think* it works fine with generic
<abrasive> it attached without error and read the BD addr
<abrasive> i couldn't get it to see my stupid ipod though
<projectgus> yay standards!
<abrasive> bluetooth is such a dog.
<projectgus> the more i learn about either bluetooth or usb the less i want to learn about them
<projectgus> also, the more impressed I am that things mostly work most of the time
<abrasive> yeah.
<abrasive> i really like speaking native USB in devices though
<hroth> abrasive: I could hciattach and read hci0 's address with hcitool ; but the Xubuntu Bluetooth Devices hasn't found a thing, including my mouse.
<abrasive> hroth: then maybe we do need this RDA-patched tool
<abrasive> or, there's some sort of GPIO enable we're missing
<abrasive> projectgus: i've got plenty of code on hand for atmega32u4 and friends if you ever get the urge to do proper uSB
<hroth> All comes back to those GPIO...
<abrasive> it beats the absolute living daylights out of serial bridge chips
<abrasive> hroth: GPIO is wonderful for system designers :)
<projectgus> i haven't done anything apart from download the rar file and verify it had the C file in it
<projectgus> heh gpio
<hroth> abrasive: no doubt. Infinite flexibility means infinite debug.
<projectgus> i don't know, wouldn't gpio most likely be just used for powering it on?
<abrasive> could be a radio killswitch
<projectgus> oh yeah
<abrasive> what was the P/N again?
<projectgus> RDA5876
<projectgus> downloading datasheet...
<abrasive> hroth: it's like my mobile phone
<abrasive> it has an FM Tx/Rx chip in it
<abrasive> but i have no idea where or even if its audio path is connected to the CPU
<hroth> Also, I read that it was in a Telechips linux distribution that cnx-software had gitted.
<projectgus> arg i might have spoken too soon about the datasheet, have a baidu.com online viewer only so far
<hroth> I didn't know where to start (it was the entire kernel) but it does have these files: http://en.pudn.com/downloads470/sourcecode/comm/android/detail1969534_en.html
<hroth> including the tcc_bt_dev and tcc_serial.
<projectgus> datasheet doesn't seem to imply any hard rfkill type feature
<abrasive> no, i don't see one on the pinout
<abrasive> and the coex signals are probably not used
<abrasive> given the wifi module doesn't bring them out
<abrasive> any hints in the hciattach code about radio enables or anything?
<projectgus> i haven't even unpacked the rar file yet
<abrasive> or the LDO_ON pin...
<abrasive> sorry for backseat driving here, i'm working on something totally unrelated :)
<projectgus> I think the LDO is for the FM receiver but it's hard to be sure
<projectgus> I'm just about to test run the graphical version of the debian installer
<projectgus> then I was going to poke around with bluetooth a bit
<hroth> On the Kconfig for tcc_bt_dev it states: tristate "TCC Bluetooth dev Control power"; if you say Y here, you can control the power of the BT H/W Module.
<projectgus> their board might have a gpio used to power it on/off
<abrasive> i might have a poke when i get home too
<projectgus> awesome, their C file is commented in chinese, and less doesn't like that :)
<projectgus> void RDA_pin_to_high(int fd)
<projectgus> {
<projectgus> #if 0 RDA_BT_POWER_ON;//open LDO_ON usleep(5000); GPIO_SetBtReset(SCI_TRUE);//open reset
<abrasive> i see.
<projectgus> so I don't actually know if that means there's likely to be an LDO_ON GPIO or not...
<abrasive> i love sloppy code.
<projectgus> this source drop is from Telechips as well
<abrasive> well, it depends if LDO_ON is in the correct state or no on our boards.
<abrasive> it's a CSP package, isn't it? so probe-able, if barely
<projectgus> probably
<projectgus> the definitions for those RDA_BT_POWER_** macros don't appear to be here anyhow
<abrasive> no, but the comments are pretty clear.
<abrasive> i don't see a reset pin
<projectgus> true
<projectgus> it's #defined out anyhow so maybe not necessary
<projectgus> the rest of the file looks like it will compile, at least
<abrasive> any juicy commands, or just the usual writing of magic values into magically-numbered registers?
<projectgus> it's nearly all numeric content
<projectgus> strings of commands as hex words
<projectgus> some of them have comments, though
<projectgus> and those comments are even in english
<projectgus> albeit maybe not very useful, ie {0x40180110,0x000247a0},//sleep patch
<abrasive> hahaha.
<projectgus> one sequence is named RfInit though
<projectgus> so it sounds like it may be what we need
<projectgus> there are a bunch of weird macros for compile-time config too though :/
<abrasive> well that's delightful. the telechips source dump has the needful to compile it?
<projectgus> specifically they look like this
<projectgus> they're all of the form RDA_PATCH_UARTn
<projectgus> and it seems to choose baud rates and some other features based on that choice
<projectgus> No definitions for them anywhere, maybe they're not used :/
<abrasive> the android source dump doesn't have them
<abrasive> not sure if we should be setting EXTERNAL_32K or not, though
<abrasive> it seems to enable some sort of snooze mode.
<abrasive> </wild-guess>
<projectgus> yeah ok
<projectgus> i hadn't even seen that
<projectgus> theirs is also weird in that it hardcodes the device node, must be what that kernel module hroth mentioned does
<projectgus> even though it looks like it otherwise integrates smoothly into hciattach
<abrasive> yeah.
<projectgus> so need to somehow wrangle that to use the fd passed in from hciattach I assume
<abrasive> it's a combined UART and GPIO wrangler i think
<projectgus> right
<projectgus> that sounds plausible
<abrasive> i tell a lie
<abrasive> it's just GPIO
<abrasive> note the distinction between fd and bt_fd :/
<projectgus> ah you're right
<projectgus> that's somewhat better, then
<abrasive> yes. but we'll have to attach to the gpio and punch the LDO on and off.
<abrasive> judging by how often it toggles the power, it is necessary.
<projectgus> ah, i thought it was a noop, missed the ioctl call there
<projectgus> it
<abrasive> for your reference i scored the dump from here: http://www.armtvtech.com/armtvtechforum/viewtopic.php?f=51&t=1954#p11855
<projectgus> 's really quite an odd initialisation sequence, isn't it?
<abrasive> including the platform dev driver.
<projectgus> I think it's the same dump I linked before
<abrasive> it reeks of cargo cult programming.
<abrasive> for the 5876, i like how it inits it, then resets it, then does the same init again
<projectgus> same file name at least
<projectgus> yeah, totally
<projectgus> it's hack randomly until it works then ship
<projectgus> does the stock android on the gk802 come with root?
jas-hacks_ has joined #imx6-dongle
<projectgus> looks like not from stock, people have rooted it
<projectgus> i guess the thing to do is root the android, dump the gpio space with bluetooth on and off
<projectgus> bah, i did a test run of the debian installer this morning
<projectgus> and the screen went totally blank about halfway through the base install
<projectgus> and i didn't have any time to investigate
<projectgus> happened at the exact same time when i ran it this evening
<projectgus> and it took me quite a bit of prodding before i touched the keyboard and realised the screen blanking had kicked in due to inactivity
<projectgus> why would you turn that on in an installer!
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Changing host]
Noskcaj has joined #imx6-dongle
<abrasive> bfft
<abrasive> dumb.
<abrasive> projectgus: jas dumped the iomux registers, that's kicking around somewhere
<abrasive> for gpio i'm a fan of trial and error, but you might have to use their uboot to get the pinmuxes right
<projectgus> abrasive: if i wasn't suspect about the hardware i probably would have assumed this straight away
<projectgus> abrasive: ok
<abrasive> heavily templated C++ errors hurt my brain :(
<jas-hacks_> projectgus: I tried to dump out gpio for bluetooth. The problem is that in android the bluetooth stuff gets initialized very quickly
<abrasive> jas-hacks_: is there a device node for the bt gpio?
<jas-hacks_> abrasive: I think it is gpio 2_31
<abrasive> cool.
<abrasive> does the pinmux default to gpio or to special functions? i forget.
<RaYmAn> abrasive: _sometimes_ it helps to try and compile it with llvm. It has somewhat better error messages
<abrasive> RaYmAn: yes, it is certainly nicer, and a bit faster than gcc
<jas-hacks_> abrasive: However if you turn off/on bluetooth the gpio 2_31 doesn't toggle
<abrasive> but CGAL is just... tangled.
<abrasive> jas-hacks_: where's your info from? does radio stop if you turn 2_31 back off?
<jas-hacks_> abrasive: However it seems to be used when the rda driver is loaded
<abrasive> it'd be nice if gpio-sysfs let you override drivers. but i guess that would be a bit rude.
<jas-hacks_> abrasive: I dumped by the iomux from android
<abrasive> do we have that gpio in our iomux config at the moment? you synced it with the android ones, didn't you?
<jas-hacks_> It's not configured, but I tried test it yesterday
<jas-hacks_> I think that the rda kernel driver is just switching the gpio line on and creating /dev/tcc_bt_dev
<abrasive> tcc_bt_dev doesn't take the IOCTL?
<jas-hacks_> hicattach internally calls RDABT_core_Intialization which toggles gpio via /dev/tcc_bt_/dev,
<abrasive> that's what i thought.
<jas-hacks_> I think we could change hicattach to use gpio sysfs instead?
<abrasive> yeah... it's more polite to use a platform device, but the hciattach will never be pretty
<jas-hacks_> there is an sdk gpio api available
Noskcaj has quit [Read error: Connection reset by peer]
Juggie has quit [Ping timeout: 264 seconds]
fossxplorer has joined #imx6-dongle
Juggie has joined #imx6-dongle
GasVesa_ has quit [Ping timeout: 246 seconds]
GasVesa has joined #imx6-dongle
rz2k has joined #imx6-dongle
iamfrankenstein has joined #imx6-dongle
datagutt has joined #imx6-dongle
hroth has quit [Ping timeout: 272 seconds]
iamfrankenstein has quit [Ping timeout: 246 seconds]
fossxplorer has quit [Remote host closed the connection]
hste has joined #imx6-dongle
rz2k has quit [Read error: Connection reset by peer]
jas-hacks_ has left #imx6-dongle [#imx6-dongle]
ajayr has quit [Read error: Connection reset by peer]
ajayr has joined #imx6-dongle
datagutt has quit [Quit: kthxbai]
iamfrankenstein has joined #imx6-dongle
Noskcaj has joined #imx6-dongle
Noskcaj has quit [Changing host]
Noskcaj has joined #imx6-dongle
fossxplorer has joined #imx6-dongle
fossxplorer has quit [Quit: Leaving]
fossxplorer has joined #imx6-dongle
fossxplorer has joined #imx6-dongle
fossxplorer has quit [Changing host]
fossxplorer has quit [Client Quit]
fossxplorer has joined #imx6-dongle
fossxplorer has quit [Changing host]
fossxplorer has joined #imx6-dongle
<fossxplorer> Hi folks
<fossxplorer> Is Linux working fine on imx6 now?
<FergusL> yes
fossxplorer has quit [Ping timeout: 264 seconds]
hp__ has quit [Ping timeout: 264 seconds]