| 12:39 | jnettlet | vpeter, ping. So for your second patch for shutdown. You need to add CONFIG_POWER_RESET_GPIO to your defconfig and then add a device-tree entry similar to this. http://pastebin.com/e4UrB5gH |
| 12:40 | jnettlet | that will condense both your patches down to just one. Then you just need to look at audio. |
| 12:42 | vpeter | Thank you. I saw this but though it is only for shutdown via button. |
| 12:51 | jnettlet | vpeter, nope CONFIG_RESET_GPIO is for that...very confusing :) |
| 16:30 | jnettlet | mk01_, that placement was actually on purpose, it was just to trigger the IPU to turn itself on and off. |
| 16:30 | jnettlet | was something not working? |
| 16:30 | mk01_ | sound |
| 16:31 | mk01_ | but that can be handled differently |
| 16:31 | jnettlet | oh, right... I have that change in my local stash |
| 16:31 | mk01_ | ok, I will just remove it then |
| 16:32 | jnettlet | but I was just looking at it and we can actually use your patch after I was testing. We just need to be careful because if you have a DVI monitor plugged in and unplug it which call BLANK_POWERDOWN you can get hotplug interrupts completely disabled. |
| 16:32 | jnettlet | but I forgot I had put a check on that code. |
| 16:32 | jnettlet | maybe your patch is best then |
| 16:33 | mk01_ | and put into blanking code test for != powerdown on irq disabling ? |
| 16:34 | jnettlet | I test specifically for if(hdmi->hp_state == HDMI_HOTPLUG_CONNECTED_DVI) to disable interrupts |
| 16:34 | jnettlet | so we can set it to unplugged and that will be fine |
| 16:35 | jnettlet | one of the reasons I wanted to streamline our connection status |
| 16:38 | jnettlet | vpeter, I am going to close your two pull requests and wait for the new one...okay? |
| 16:52 | jnettlet | mk01_, I think I am going to merge warped_rudi's pull requests as well. Some of it includes mode handling but it doesn't look like it will interfere with your work. |
| 16:52 | jnettlet | can you take a quick look and let me know if you have any major objections. |
| 16:52 | jnettlet | it all looks reasonable to me. |
| 16:53 | mk01_ | ok, going to |
| 16:53 | jnettlet | mainly it his his second pull request |
| 16:55 | mk01_ | do you know what was the main reason to do ignore_edid=1 ? |
| 16:56 | jnettlet | mk01_, I think it is for monitors that provide broken edid's |
| 16:56 | jnettlet | it does happen...still. |
| 16:57 | mk01_ | perhaps he could add option to load ext edid file |
| 16:57 | mk01_ | then |
| 16:58 | jnettlet | I got ahead of myself. your patch was half right. The disconnect placement was correct |
| 16:58 | jnettlet | oh well I will just push another patch |
| 17:06 | mk01_ | so don't blank on disconnect, only powerdown in ipu3_fb, yes ? |
| 17:07 | jnettlet | yeah, I believe so. I am testing now. |
| 17:07 | mk01_ | then let's ignore my patch completely, and let's just call hdmi_set_blank_state(1) in registered() or in blank/unblank handling before NOOP |
| 17:08 | mk01_ | that that the audio can work. |
| 17:10 | jnettlet | actually, your patch seems to be working fine. I am happy with it |
| 17:11 | jnettlet | still the problem exists where you have a DVI monitor plugged in and the screen is blanked, you unplug the cable and plug in an HDMI monitor. |
| 17:11 | mk01_ | and the irqs in mxc_hdmi_fb_event() for DVI ? |
| 17:11 | jnettlet | however if then userspace unblanks the monitor we will reconfigure properly so I think that is the best we can handle this scenario |
| 17:12 | mk01_ | this is something I was telling koying (from xbmc) maybe a year ago |
| 17:12 | jnettlet | this is why MX6 doesn't officially support DVI |
| 17:12 | mk01_ | that it would be very polite to blank/unblank |
| 17:13 | jnettlet | I think this workflow is much better then before. |
| 17:14 | jnettlet | the next step will be to sort out the receivers behavior. I am pretty sure I know how to make that work now. |
| 17:14 | mk01_ | what you mean ? |
| 17:15 | jnettlet | like you receiver, where we get a disconnect and reconnect so it can pass a new edid |
| 17:15 | mk01_ | oh yes, this is problem in solidrun's kernel |
| 17:16 | mk01_ | and I have the feeling you made it worse with the new handling of resolutions (change / restore) |
| 17:17 | jnettlet | I made it worse to make it better though |
| 17:19 | vpeter | jnettlet: No need to close. I will commit new dts very soon (got home and testing). Poweroff pr I will close. |
| 17:19 | jnettlet | vpeter, okay cool. |
| 17:23 | mk01_ | jnettlet: so you have additional commits in stash regarding the res handling ? |
| 17:25 | jnettlet | mk01_, I haven't written them yet but I know what they are. |
| 17:27 | mk01_ | jnettlet: ok. because now with the change in handling XBMC will break on each HDMI TV off/on cycle |
| 17:28 | mk01_ | (before this broke only by new edid read) |
| 17:31 | jnettlet | if you can enable debugging for the mxc_hdmi.c driver and send me logs of it happening I would appreciate it. Then I can look better at the workflow it is trying to use. |
| 17:33 | vpeter | jnettlet: I was affraid this will happen with gpio shutdown - [ 1.876288] gpio_poweroff_probe: pm_power_off function already registered |
| 17:33 | jnettlet | vpeter, get my latest commits I just pushed. I have fixed that stupidity |
| 17:33 | jnettlet | freescale taking over pm_power_off for all socs in the rtc driver....ridiculous |
| 17:35 | mk01_ | jnettlet: problem is not in workflow, but in re-matching previous mode and call to mxc_hdmi_setup or mxc_hdmi_notify_fb respectively. |
| 17:35 | vpeter | jnettlet: rebuilding... |
| 17:36 | mk01_ | jnettlet: mxc_hdmi_notify_fb is recreating FB from scratch and it destroys double buffer. |
| 17:37 | jnettlet | yeah, but we won't be calling that so much after the next change. Follow me. |
| 17:38 | jnettlet | actually it will take to long. I will work on it in the next day or so. |
| 18:03 | jnettlet | vpeter, how did we do? |
| 18:12 | vpeter | jnettlet: first test was not good - kernel hangs. Removing ccache and rebuilding. |
| 18:13 | jnettlet | vpeter, what toolchain are you using to build with? |
| 18:14 | vpeter | openelec master. |
| 18:15 | jnettlet | hmmm...oh I am not building master currently. |
| 18:15 | vpeter | I just replaced Linux with yours. |
| 18:15 | jnettlet | vpeter, oh please test on the openelec-6.0 branch |
| 18:16 | jnettlet | I am shooting for the next release since it is held up. |
| 18:16 | jnettlet | I will push my branch for testing later once I package all my bits. I don't want to send out my half assed test build system |
| 18:17 | vpeter | toolchain in master is the same as in 6.0. I think. |
| 18:17 | vpeter | I'm only interested in kernel for now. |
| 18:18 | vpeter | Until all your changes get somewhere :) |
| 18:23 | vpeter | jnettlet: something is (again) broken for me: http://pastebin.com/HfXD7E1k |
| 18:26 | jnettlet | that is where it stops? |
| 18:26 | jnettlet | next thing loading should be i2c |
| 18:28 | vpeter | No, something sd card related |
| 18:28 | vpeter | sdhci: Secure Digital Host Controller Interface driver |
| 18:29 | jnettlet | I guess you will need to enable MMC_DEBUG then. It spits out lots of mess but will let us see where the problem is. |
| 18:29 | vpeter | ok. |
| 20:38 | vpeter | jnettlet: All ok with current kernel. It was stupid mistake (I forgot to change active low/high). I closed one PR and update the second one (dts). |
| 20:56 | vpeter | And one q: is it possible to have another GPIO set on shutdown? |
| 21:30 | jnettlet | vpeter, okay great. What gpio do you need on shutdown? The o |
| 21:30 | jnettlet | The imx6 state is reset on por |
| 21:31 | vpeter | Udoo has arduino compatable microcontroller on board. And this can be put to reset. |
| 21:32 | vpeter | After imx6 is powered down arduino is still running. |
| 21:32 | vpeter | But this is not important. Just wondering - and using your knowledge :) |
| 21:35 | jnettlet | Sure. I would extended or duplicate the driver you are using and include a hook for pm_power_off_prepare instead of pm_power_off. Although if I remember correctly udoo has a driver for the arduino interface |
| 21:35 | jnettlet | You could add something there to reset the gpio. |
| 21:36 | jnettlet | That is where I would start at least |
| 21:37 | vpeter | Yes, I have external driver for this. But I though it could be something build-in like this gpio-poweroff. |
| 21:38 | vpeter | Ok, little more interesting question. When imx6 is off what is the state of GPIO's? Floating? |
| 21:39 | vpeter | Can I set low level on gpio pin when imx6 is powered down. |
| 21:44 | jnettlet | Good question I have no idea. Probably floating there is a default on state. |
| 21:45 | jnettlet | But the default pin state isn't necessarily a gpio |
| 21:46 | vpeter | Sure. Set as gpio output at one time and then off. With reading imx6 manual I though you can set in one register pin behaviour after power down. There is some latch or something like that. But could get it work. |
| 21:46 | vpeter | Anyway, forget this. |
| 21:56 | vpeter | About FEC halt at boot which happened on my board I found this: https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba41c7f7af86b99476055c2b46e86605 |
| 21:56 | vpeter | Adding msleep() helped. |
| 21:59 | jnettlet | Interesting. I used to carry a similar patch. I will review it. |
| 22:01 | vpeter | Thanks for the help today. Now it's time to sleep. If not I will dream about all this :) |
| 22:07 | jnettlet | Night |