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