Jump to content

Recommended Posts

Posted

Hi,

i'm working on a hdmi cec driver for H3 and i'm looking for some feedback how the driver works. I have tested the driver with OrangePi PC and a Samsung TV.

I have pushed my driver to github : https://github.com/jodamm/linux/tree/sun8i or here is a patch file that can be placed in userpatches for armbian toolchain.

The driver can be loaded with modprobe hdmi_cec .

I have modified libcec to work with this driver : https://github.com/jodamm/libcec or again a patch file for libcec.

Posted

Is this the same that you did for sun4/7i?

If not, we should find some testers for it, too :P

Thanks

rellla

Posted

Is this the same that you did for sun4/7i?

If not, we should find some testers for it, too :P

Thanks

rellla

No it's a new one :P , but i will rewrite the one for sun4/7i to be compatible with this libcec changes and hopefully better timing. Now i can test it better with 2 different devices. With this driver i tried to use the cec hardware but either there is something wrong with how Allwinner integrated it in H3, how it is wired on my Orange Pi PC or there is still some secret register setting. I could only get the hardware to either send or receive. But for receiving messages they have to be ACKed so i came up with some sort of bit banging. If it is receiving, i count the received bits and when it comes to the ack bit, i switch from receiving to sending for 1 bit.

Posted

Just a few small observations:

1. Could you change SUNXI_ADAPTER_PID to something else? On systems with imx6 patches also applied, libcec crashes (OpenELEC).

2. Your kernel patch from server doesn't apply cleanly due to different end of line marker. Patch downloaded from github works, though.

3. Documentation has a typo. It suggests using "cmake -DHAVE_SUNXI_LIB=1 .." while it should "cmake -DHAVE_SUNXI_API=1 .."

 

Great job otherwise! I will test it tomorrow hopefully.

Posted

Just a few small observations:

1. Could you change SUNXI_ADAPTER_PID to something else? On systems with imx6 patches also applied, libcec crashes (OpenELEC).

2. Your kernel patch from server doesn't apply cleanly due to different end of line marker. Patch downloaded from github works, though.

3. Documentation has a typo. It suggests using "cmake -DHAVE_SUNXI_LIB=1 .." while it should "cmake -DHAVE_SUNXI_API=1 .."

 

Great job otherwise! I will test it tomorrow hopefully.

Thanks for your feedback.

1. hopfully fixed.

2. fixed.

3. No, it's not a typo, more a workaround. The bug introduced with this commit was never fixed.

Posted

@Melanrz,

no, it works without board modifications. That is the beauty of it.

 

@jodamm,

while I couldn't test it due to bad TV CEC support but others did and they report that everything works if TV is already on. Once you turn off and on again TV, it stops working. I compared your kernel code with the imx6 one and I noticed that your code doesn't have "HDMI cable connect/disconnect" hooks. Do you think that is the reason?

Posted

@jodamm,

while I couldn't test it due to bad TV CEC support but others did and they report that everything works if TV is already on. Once you turn off and on again TV, it stops working. I compared your kernel code with the imx6 one and I noticed that your code doesn't have "HDMI cable connect/disconnect" hooks. Do you think that is the reason?

 

I can reproduce this error, i will investigate it. But i think that something in HDMI driver overwrites registers when reconnecting.

Posted

Just out of curiosity, how did you found HDMI_H3_PHY_CEC register at address 0x1003c?

You have posted it :D . In Orange Pi forum first hdmi_write in your code box.

 

I have found the cause of the problem with turning TV off and on. On reconnect init_hdmi is called and it overwrites two registers needed for my driver. I'm not sure how to fix it. Change the hdmi_init so that it wouldn't overwrite the registers or let the driver somehow know that it has to reset the registers.

Posted (edited)

Uh, I was wondering what's that for. I didn't think it could be directly connected to CEC :wacko:

 

Currently I can't help you much. Maybe in a few days?

 

EDIT: Which registers exactly?

EDIT2: I see, I think it would be safe to call this function only at driver init, at least that mainline driver does. I will test once I will have time.

Edited by jernej
Posted

I have found the cause of the problem with turning TV off and on. On reconnect init_hdmi is called and it overwrites two registers needed for my driver. I'm not sure how to fix it. Change the hdmi_init so that it wouldn't overwrite the registers or let the driver somehow know that it has to reset the registers.

 

Maybe something like this: https://transfer.sh/12Ss3a/linux-011-disp2-keep-cec-signals.patch

It preserves HDMI_CEC_MASK and HDMI_CEC_MASK, doesn't make software reset in HDMI_MC_SWRSTZ register and doesn't disable clock in HDMI_MC_CLKDIS register. Only question remains if register at address 0x10020 could hurt this or not.

Posted

Maybe something like this: https://transfer.sh/12Ss3a/linux-011-disp2-keep-cec-signals.patch

It preserves HDMI_CEC_MASK and HDMI_CEC_MASK, doesn't make software reset in HDMI_MC_SWRSTZ register and doesn't disable clock in HDMI_MC_CLKDIS register. Only question remains if register at address 0x10020 could hurt this or not.

That should work, a restart of cec-client was enough to communicate again. But i'm working on solution two, i wanted the plug and unplug events too for the cec driver.

Posted

Ok, it seems best not to use that patch because it breaks suspend/resume. You are right that second solution is best. Where do you plan to make hooks? Iniside drv_hdmi.c, using function Hdmi_hpd_event() or hdmi_report_hpd_work()? The latter would need to be fixed on two places...

Posted

I updated the patch file and github. Now the driver should better handle hdmi reconnects and power on from TV.

Posted (edited)

It's hard to trace through Allwinner's code, but do you know by any chance why suspend and resume wouldn't work? It seems to me that you already have notification for that, but I'm not sure.

 

One user reports that CEC diagnostic would often crash OPi Plus board. Any thoughts on that? I really don't know how diagnostic looks like...

 

EDIT: It seems that hdmi suspend function is not called anywhere.

EDIT2: Or it is... Can you just check that suspending turns tv off?

Edited by jernej
Posted

I had a buffer overflow in the last patch, maybe that is causing the CEC diagnostic to crash the OPi. I will release a new patch later, i will do some testing first.

 

When i poweroff openelec, the TV is not suspended or switched to other input, just signal will go off. Are there settings to change this behaviour?

I had it once that i could not get the OPiPC out off suspend with the power button, but after that i tested it at least 20 times without problems.

 

I will try to implement that the OPi can be waked up from the TV over CEC, but that will take some time to programm and test it.

With the screensaver i have no clue what settings i should try to test the issues the testers had.

Posted

Thanks for looking into issues.

 

Power off in Kodi is actually suspend, not a proper shutdown. Otherwise it wouldn't be possible to wake it up. You can debug this issues with appending "no_console_suspend" in U-Boot kernel parameters and executing "echo 8 > /proc/sys/kernel/printk" in console. I think that at least some messages will be useful to you. There is also another bug at suspend. If you have USB hub connected to any port and that hub has some USB device connected to it, it will crash at suspending (watchdog timer). I tried to debug this issue, but I couldn't find what is wrong. You can do a proper shutdown from console with standard "shutdown now" commnad.

 

Don't mind screensaver issue. It might be because of buffer overflow you mentioned or some other thing. If it will still exist after your bugfix, I will check the code what is happening in that moment.

Posted

I found the settings for CEC, if i turn the option "send TV to standby with kodi" to off, the TV will switch back to satellite. It seems it depends on the TV what will work and what not.

And i found a situation when the OPi will not come out of suspend. If OPi is in suspend and i turn TV off, OPi can only be reseted with unpluging powersupply. At least something i can debug the next days.

Btw i have a problem with setting ip address to manual, only off and dhcp will work. Where i can find the settings, so i can change it over ssh?

Posted

I'm using DHCP to my computer and serial console (which is a must for debugging sleep issues). Maybe this will help you with setting static ip.

Posted

Github repository and patchfile updated. Small change: wait for free cec line before sending messages and fix for wrong array sizes.

Posted

One user reports constant freezes for 1-2 seconds after every button press and that suspend/resume cycle works only first time. Tested on LG TV if that helps anything.

Posted

hello, thanks for patch i want to test it on my Orange Pi lite with armbian (controling with Domoticz)
i allready compiled patched libcec, but i have problems with compiling Driver...

anyone can help?

do i have to clone whole repo or patch somehow my kernel src files ?

thanks!

Posted

Should be great to have a package to install :))))

 

I have compiled libcec but I don't really understand how to install the driver....

Toolchain is necessary ? I don't understand, I must install all the drivers the git repo contains ?

It should be great to detail how to do in command lines :))))

Posted

Hi all, (Noobie alert!)

 

Can someone please clarify how libcec is applied to the H3 device? Is libcec meant to be cross-compiled or compiled on the device?

 

I've just compiled Armbian with HDMI_CEC driver which can be loaded with modprobe but not sure how to handle libcec?

 

Am I meant to include libcec source in the Armbian source folders? if so where?

 

Thanks

Posted

Which kernel version do you use? Take a look at output of "uname -a". If it is 3.4 then you can use libcec, but if it is 4.x, then libcec is useless without additional patches and possibly some kernel patches too.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines