Hi Maxime, On Mon, Oct 17, 2016 at 9:51 PM, Maxime Ripard < maxime.rip...@free-electrons.com> wrote:
> Hi Jarosław, > > On Mon, Oct 17, 2016 at 08:15:53PM +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 :) > > 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. BTW Implementing general cec-over-gpio driver could be also quite useful for lot of projects. And one more thing http://linux-sunxi.org/Display_Controller_Register_Guide shows that there are 4 bits connected to CEC 11 Read/Write 0 REG_CEC_EN 10 Read/Write 0 REG_CECPS 9 Read/Write 0 W_CEC 8 Read / R_CEC Does anyone know what REG_CECPS is for? > > 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 > > I could try to implement simple HDMI I2C driver just for obtaining EDID, > > but I don't think this make lot of sense without proper HDMI support. > > > > 3) Do you know what if other CPUs uses similar HDMI core? I think A20 and > > A13. Any other? > > A10s, A31, at least. > > 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.
