Hi, On Mon, Oct 17, 2016 at 11:33:45PM +0200, Jarosław Nieć wrote: > > > I've decided that I want to learn kernel hacking a little and because of > > > that and because of new HDMI CEC Framework in kernel 4.8 I chose to write > > > CEC driver for old Allwinner A10. > > > There in no CEC hardware core for this CPU and I think the only way is to > > > create implementation that uses bit banging. > > > I've investigated the topic a little, tried few things and finally I have > > > prototype that more or less can receive and send CEC messages using this > > > new Framework. > > > Code isn't very pretty right now and there is few things missing (like > > > proper error handling etc.) but before I continue I want firstly ask you > > > guys few questions. > > > > I actually started to look into this too a few days ago. Nothing > > really major though :) > > OK so maybe I will clean my implementation (I hope in few days) and pass it > to first review. > You could see it and decide if it make sense to invest more time in it or > start from scratch :)
If you have something that works already, it would be kind of a shame to start from scratch :) > > > 1) For bit banging I'm using high resolution timer. If CEC line is idle > > > this timer ticks every 2.4 ms (416Hz). For every tick it checks the state > > > of CEC line and when it detects start of CEC message it reduce delay to > > 0.1 > > > ms (10000Hz). > > > We need more or less this kind of frequency to probe CEC line to detect > > if > > > transmitted bit is 0 or 1. I've used high resolution timer because it was > > > the solution that give me this very accurate 0.1 ms delay. > > > I've also tried udelay, usleep_range and few other functions, but without > > > success. They were too unreliable (because triggered by scheduler) or too > > > CPU consuming (because of using busy-wait loop for too long). > > > OK so the first question is does it make sens to use HR timer for bit > > > banging? What other things I could try? Maybe you know some traps that > > are > > > connected with HR timers? > > > > I had this exact same discussion today on #v4l, and what design we > > should implement, and we came to pretty much that conclusion. > > I had also another idea how this CEC could be implemented, but I > don't think it is possible. CEC line is connected to P23 CPU ball > (for A10) and it would be very good if we could use this pin as a > GPIO. Implementing CEC using GPIO should be much easier than using > this CEC register. But as I mentioned I don't think it is possible, > not for this pin. Yeah, this pin is not muxable unfortunately. > BTW Implementing general cec-over-gpio driver could be also quite > useful for lot of projects. Rockchip has such a driver already. It's not upstream at the moment, but your point is valid :) > > > 2) CEC driver requires HDMI physical address to be provided. This address > > > can be passed from userspace (but userspace need to know it), or driver > > can > > > obtain it on its own. > > > Right now I left providing of this parameter to userspace, but it will be > > > good to have option of obtaining it. Normally we can read this value from > > > EDID that is read using HDMI I2C. > > > AFAIK currently there is no Display Engine HDMI support in mainline > > kernel, > > > so there is no HDMI I2C interface implemented. > > > Are there any plans to support HDMI in Display Engine in near future? > > > > I started working on it. I'm still at the point where I try to get the > > EDIDs, but I shouldn't be very far now. > > I'm very happy to hear that :) > Are you planing to provide any interface to EDID or HDMI address to other > modules? > CEC framework already contains some code to parse EDID > https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-next/include/media/cec-edid.h The EDIDs are exposed to the userspace already through a sysfs file. Did you need them in the kernel too? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
