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 :)

> 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.

> 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 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 Ripard, Free Electrons
Embedded Linux and Kernel engineering

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.

Attachment: signature.asc
Description: PGP signature

Reply via email to