On Wed, Oct 19, 2016 at 5:53 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > > On 19-10-16 05:16, Chen-Yu Tsai wrote: >> >> 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. > > > If we're going to spend time writing a bit-bang cec driver using timers we > should IMHO really do this through a gpio indirection so that the entire > bit-bang code can be shared. > > As for this being convoluted, it does not need to be that bad. I think > you're > thinking too much along the lines of doing a stand-alone gpio driver + > regmap > or some such to access the register. But we can just have the hdmi encoder > driver register a gpio_chip, without doing 2 separate drivers, and then the > code should be pretty clean.
That is actually what I had in mind. It would mean you'd have 2 devices instead of 1. But in this case I suppose it's actually correct, since you can pretty much do anything with that pin, besides the fact that it's a dedicated pin. ChenYu > Regards, > > Hans > > > > >> >> 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.
