On Tue, Oct 18, 2016 at 6:14 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 17-10-16 23:33, Jarosław Nieć wrote: >> >> Hi Maxime, >> >> >> On Mon, Oct 17, 2016 at 9:51 PM, Maxime Ripard >> <maxime.rip...@free-electrons.com <mailto: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. > > > If all the hardware allows you to-do is set / read the pin, you could write > a gpio-chip > driver for it, and then attach a generic cec-over-gpio driver to that, that > seems like > a better idea then an Allwinner specific bit-bang driver.
That might not be easy to do. The CEC line is a dedicated pin on the SoC, leading to the HDMI controller, much like the HDMI DDC lines. And the control bits are in the middle of the HDMI register space. Doing a one-line GPIO controller for that pin should work, though it's a really convoluted approach. ChenYu > > > Regards, > > Hans > > > -- > 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. -- 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.
