Re: [linux-sunxi] Kernel CEC driver.

[Maxime Ripard]

On Thu, Oct 20, 2016 at 04:39:26PM +0200, Hans de Goede wrote:
> On 20-10-16 14:55, Maxime Ripard wrote:
> > On Thu, Oct 20, 2016 at 11:17:13AM +0200, Hans de Goede wrote:
> > > Yes that is the idea. Although it is not really fake as theoretically
> > > the CEC pin could be used as a general gpio. Basically the idea is that
> > > if the hardware only offers get and set functionality on the pin and
> > > nothing really CEC specific, that we then should really have one generic
> > > driver to deal with any such hardware, and not an allwinner specific
> > > driver.
> > > 
> > > The natural abstraction for such a driver to talk to the actual hardware
> > > (be it allwinner or other hw) would be to use the gpio interface.
> > 
> > There's really no point of having such an abstraction in the first
> > place. Theorically, you could use your audio output or PWM as a GPIO,
> > yet no one exposes it as a GPIO to then use a generic pwm-gpio driver
> > to actually implement a PWM.
> 
> Of course if there is pwm hardware then exporting that as just a
> gpio is not sensible (assuming it can be muxed as a regular gpio),
> but this is the other way around even though the hardware is labeled
> as CEC it cannot do anything a gpio cannot.
> 
> As your rock-chip example points out we are not alone here, so we
> really should have a common cec-gpio drivers, just like e.g.
> drivers/i2c/busses/i2c-gpio.c drivers/spi/spi-gpio.c, etc.
> exist.

I don't know, we're the only users without an interrupt, which changes
the logic a bit.

> > > > How in that case implement interrupts for such fake gpio?
> > > 
> > > GPIOs can be interrupts too, e.g. the cec driver would do:
> > > 
> > > struct gpio_desc *cec_gpio = gpiod_get(dev, ...);
> > > 
> > > int irq = gpiod_to_irq(cec_gpio);
> > > 
> > > devm_request_threaded_irq(dev, irq, NULL, cec_gpio_irq_handler, 
> > > IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> > >   "cec_irq", cec_data);
> > > 
> > > To register an irq on rising and falling edges on the gpio
> > > pin. If you want to use this you can even make the availability
> > > of irq functionality on the gpio mandatory in your cec-gpio driver
> > > and then when someone needs things to work without irq functionality
> > > they can extend it.
> > > 
> > > The cool thing about this approach is that it will give instant CEC
> > > capability to any (new) board where an edge irq capable GPIO is
> > > available, just hook up the HMDI connector CEC pin to an edge IRQ
> > > capable gpio and even non CEC capable HDMI encoders can do CEC :)
> > 
> > The bad thing about this approach is that it doesn't work for us,
> > since we don't have any interrupts on the CEC pins.
> 
> Oh, the question from Jarosław gave me the impression that we did,
> but it does not matter really, it just means that the initial
> cec-gpio implementation will not use interrupts, and later someone
> who actually has an edge irq capable gpio can extend it to handle
> both cases, or write another driver for that case, just like we e.g.
> have drivers/input/keyboard/gpio_keys.c and
> drivers/input/keyboard/gpio_keys_polled.c.
> 
> I'm somewhat surprised we're having so much discussion about this,
> if the cec functionality on the A10 is just being able to get / set
> some pin(s) then exporting these as gpio's seems the obvious solution
> to abstract this in such a way that we can have a generic and *shared*
> bit-banged cec driver. As said on some other boards we might very well
> use an actual gpio for this, and not all gpio-s are edge irq capable,
> so sooner or later we will need a generic bit bang cec driver which
> does not use edge irqs on the pin.

I'm actually quite surprised too. I don't see how it's different from
say the discussion we had a couple of times on the ADCs found in the
touchscreen IPs, in the AXP or in the LRADC.

With the difference that the ADCs can be used for ADCs (and yet we
chose not to support that), while there's no way this pin can be used
for a GPIO.

Having it in the driver is just the most straightforward way to
implement it, and it deals with all the usecases that we have right
now. Why would we want to overcomplicate things and trying to fit
something in a model that isn't fit?

And there's also the side effect that we would expose that pin through
sysfs and /dev/, allowing the user to change it any way it wants. And
I'm not really confortable with that.

Having some kind of generic library to be able to do just that seems
like a better design.

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.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Kernel CEC driver.

[Jarosław Nieć]

Hi,

Thank you guys for your great inputs.
Discussion was very very helpful and clarified lot of things.
Here is more of less my current master plan :)

1) finish first version of sunxi CEC adapter that is using
pooling of HDMI CEC register. This version will be without
EDID parsing. Even if we later decide that we prefer GPIO version,
this one will allow testing core CEC sending/receiving
functionality.

2) create version of above driver, but for GPIO instead of
sunxi specific CEC register. This version will still use pooling
and won't support EDID parsing. It will probably reuse 90%
of code so should be quite easy to write.

3) After that I will take a look at this HDMI notifier (maybe it will
be finished already) and sunxi HDMI display engine driver
to add parsing of EDID.

4) Maybe new cec over GPIO with interrupts driver ???

5) Maybe cec driver for more recent Allwinner CPU-s ???

Jarek

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

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 20-10-16 14:55, Maxime Ripard wrote:

On Thu, Oct 20, 2016 at 11:17:13AM +0200, Hans de Goede wrote:

Yes that is the idea. Although it is not really fake as theoretically
the CEC pin could be used as a general gpio. Basically the idea is that
if the hardware only offers get and set functionality on the pin and
nothing really CEC specific, that we then should really have one generic
driver to deal with any such hardware, and not an allwinner specific
driver.

The natural abstraction for such a driver to talk to the actual hardware
(be it allwinner or other hw) would be to use the gpio interface.


There's really no point of having such an abstraction in the first
place. Theorically, you could use your audio output or PWM as a GPIO,
yet no one exposes it as a GPIO to then use a generic pwm-gpio driver
to actually implement a PWM.


Of course if there is pwm hardware then exporting that as just a
gpio is not sensible (assuming it can be muxed as a regular gpio),
but this is the other way around even though the hardware is labeled
as CEC it cannot do anything a gpio cannot.

As your rock-chip example points out we are not alone here, so we
really should have a common cec-gpio drivers, just like e.g.
drivers/i2c/busses/i2c-gpio.c drivers/spi/spi-gpio.c, etc.
exist.


How in that case implement interrupts for such fake gpio?


GPIOs can be interrupts too, e.g. the cec driver would do:

struct gpio_desc *cec_gpio = gpiod_get(dev, ...);

int irq = gpiod_to_irq(cec_gpio);

devm_request_threaded_irq(dev, irq, NULL, cec_gpio_irq_handler, 
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
  "cec_irq", cec_data);

To register an irq on rising and falling edges on the gpio
pin. If you want to use this you can even make the availability
of irq functionality on the gpio mandatory in your cec-gpio driver
and then when someone needs things to work without irq functionality
they can extend it.

The cool thing about this approach is that it will give instant CEC
capability to any (new) board where an edge irq capable GPIO is
available, just hook up the HMDI connector CEC pin to an edge IRQ
capable gpio and even non CEC capable HDMI encoders can do CEC :)


The bad thing about this approach is that it doesn't work for us,
since we don't have any interrupts on the CEC pins.


Oh, the question from Jarosław gave me the impression that we did,
but it does not matter really, it just means that the initial
cec-gpio implementation will not use interrupts, and later someone
who actually has an edge irq capable gpio can extend it to handle
both cases, or write another driver for that case, just like we e.g.
have drivers/input/keyboard/gpio_keys.c and
drivers/input/keyboard/gpio_keys_polled.c.

I'm somewhat surprised we're having so much discussion about this,
if the cec functionality on the A10 is just being able to get / set
some pin(s) then exporting these as gpio's seems the obvious solution
to abstract this in such a way that we can have a generic and *shared*
bit-banged cec driver. As said on some other boards we might very well
use an actual gpio for this, and not all gpio-s are edge irq capable,
so sooner or later we will need a generic bit bang cec driver which
does not use edge irqs on the pin.

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.

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 20-10-16 14:55, Maxime Ripard wrote:

On Thu, Oct 20, 2016 at 11:17:13AM +0200, Hans de Goede wrote:

Yes that is the idea. Although it is not really fake as theoretically
the CEC pin could be used as a general gpio. Basically the idea is that
if the hardware only offers get and set functionality on the pin and
nothing really CEC specific, that we then should really have one generic
driver to deal with any such hardware, and not an allwinner specific
driver.

The natural abstraction for such a driver to talk to the actual hardware
(be it allwinner or other hw) would be to use the gpio interface.


There's really no point of having such an abstraction in the first
place. Theorically, you could use your audio output or PWM as a GPIO,
yet no one exposes it as a GPIO to then use a generic pwm-gpio driver
to actually implement a PWM.


Of course if there is pwm hardware then exporting that as just a
gpio is not sensible (assuming it can be muxed as a regular gpio),
but this is the other way around even though the hardware is labeled
as CEC it cannot do anything a gpio cannot.

As your rock-chip example points out we are not alone here, so we
really should have a common cec-gpio drivers, just like e.g.
drivers/i2c/busses/i2c-gpio.c drivers/spi/spi-gpio.c, etc.
exist.


How in that case implement interrupts for such fake gpio?


GPIOs can be interrupts too, e.g. the cec driver would do:

struct gpio_desc *cec_gpio = gpiod_get(dev, ...);

int irq = gpiod_to_irq(cec_gpio);

devm_request_threaded_irq(dev, irq, NULL, cec_gpio_irq_handler, 
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
  "cec_irq", cec_data);

To register an irq on rising and falling edges on the gpio
pin. If you want to use this you can even make the availability
of irq functionality on the gpio mandatory in your cec-gpio driver
and then when someone needs things to work without irq functionality
they can extend it.

The cool thing about this approach is that it will give instant CEC
capability to any (new) board where an edge irq capable GPIO is
available, just hook up the HMDI connector CEC pin to an edge IRQ
capable gpio and even non CEC capable HDMI encoders can do CEC :)


The bad thing about this approach is that it doesn't work for us,
since we don't have any interrupts on the CEC pins.


Oh, the question from Jarosław gave me the impression that we did,
but it does not matter really, it just means that the initial
cec-gpio implementation will not use interrupts, and later someone
who actually has an edge irq capable gpio can extend it to handle
both cases, or write another driver for that case, just like we e.g.
have drivers/input/keyboard/gpio_keys.c and
drivers/input/keyboard/gpio_keys_polled.c.

I'm somewhat surprised we're having so much discussion about this,
if the cec functionality on the A10 is just being able to get / set
some pin(s) then exporting these as gpio's seems the obvious solution
to abstract this in such a way that we can have a generic and *shared*
bit-banged cec driver. As said on some other boards we might very well
use an actual gpio for this, and not all gpio-s are edge irq capable,
so sooner or later we will need a generic bit bang cec driver which
does not use edge irqs on the pin.

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.

Re: [linux-sunxi] Kernel CEC driver.

[Maxime Ripard]

On Wed, Oct 19, 2016 at 09:02:50PM +0200, Jarosław Nieć wrote:
> On Wed, Oct 19, 2016 at 3:02 PM, Maxime Ripard <
> maxime.rip...@free-electrons.com> wrote:
> 
> > Hi,
> >
> > On Mon, Oct 17, 2016 at 11:33:45PM +0200, Jarosław Nieć wrote:
> > > BTW Implementing general cec-over-gpio driver could be also quite
> > > useful for lot of projects.
> >
> > Rockchip has such a driver already. It's not upstream at the moment,
> > but your point is valid :)
> 
> Are you refering to this driver?
> https://github.com/tyeo098/MK908-Kernel-NAND/tree/master/drivers/video/rockchip/hdmi/softcec
> Or maybe something new was written?

Yes, I think that's the one.

> This old one doesn't look too good. Lot of very ineffective sleeps
> and of course lack of support to this new framework.

I didn't it was good, I said there would be other users for such a
driver. But not us.

> Truly I don't know what I need :)
> CEC framework supports 2 types of CEC adapters. First one that doesn't know
> its HDMI physical address and second one that knows it, because it analyzed
> EDID on its own.
> In case of first adapters userplane should pass this address to adapter so
> it can use it.
> Unfortunately right now there is no large support in userplane for new
> framework.
> The most popular libcec doesn't support framework and I don't know how they
> are
> planing to obtain and pass this address to adapter.
> Maybe they will read this sysfs file. Who knows.
> https://github.com/Pulse-Eight/libcec/issues/67
> 
> Thats why to make this cec driver "more independent" and I wanted to somehow
> get address from EDID.
> But as for now I don't think this is very important and we shouldn't worry
> about that.

We'll see that in time then :)
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.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Kernel CEC driver.

[Maxime Ripard]

On Thu, Oct 20, 2016 at 11:17:13AM +0200, Hans de Goede wrote:
> Yes that is the idea. Although it is not really fake as theoretically
> the CEC pin could be used as a general gpio. Basically the idea is that
> if the hardware only offers get and set functionality on the pin and
> nothing really CEC specific, that we then should really have one generic
> driver to deal with any such hardware, and not an allwinner specific
> driver.
> 
> The natural abstraction for such a driver to talk to the actual hardware
> (be it allwinner or other hw) would be to use the gpio interface.

There's really no point of having such an abstraction in the first
place. Theorically, you could use your audio output or PWM as a GPIO,
yet no one exposes it as a GPIO to then use a generic pwm-gpio driver
to actually implement a PWM.

> > How in that case implement interrupts for such fake gpio?
> 
> GPIOs can be interrupts too, e.g. the cec driver would do:
> 
> struct gpio_desc *cec_gpio = gpiod_get(dev, ...);
> 
> int irq = gpiod_to_irq(cec_gpio);
> 
> devm_request_threaded_irq(dev, irq, NULL, cec_gpio_irq_handler, 
> IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
>   "cec_irq", cec_data);
> 
> To register an irq on rising and falling edges on the gpio
> pin. If you want to use this you can even make the availability
> of irq functionality on the gpio mandatory in your cec-gpio driver
> and then when someone needs things to work without irq functionality
> they can extend it.
> 
> The cool thing about this approach is that it will give instant CEC
> capability to any (new) board where an edge irq capable GPIO is
> available, just hook up the HMDI connector CEC pin to an edge IRQ
> capable gpio and even non CEC capable HDMI encoders can do CEC :)

The bad thing about this approach is that it doesn't work for us,
since we don't have any interrupts on the CEC pins.

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.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Kernel CEC driver.

[Hans Verkuil]

On 10/20/16 11:18, Hans de Goede wrote:

Hi,

On 19-10-16 21:02, Jarosław Nieć wrote:


On Wed, Oct 19, 2016 at 3:02 PM, Maxime Ripard
mailto:maxime.rip...@free-electrons.com>> wrote:

Hi,

On Mon, Oct 17, 2016 at 11:33:45PM +0200, Jarosław Nieć wrote:
> BTW Implementing general cec-over-gpio driver could be also quite
> useful for lot of projects.

Rockchip has such a driver already. It's not upstream at the moment,
but your point is valid :)


Are you refering to this driver?
https://github.com/tyeo098/MK908-Kernel-NAND/tree/master/drivers/video/rockchip/hdmi/softcec

Or maybe something new was written?
This old one doesn't look too good. Lot of very ineffective sleeps
and of course lack of support to this new framework.

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



The EDIDs are exposed to the userspace already through a sysfs
file. Did you need them in the kernel too?


Truly I don't know what I need :)
CEC framework supports 2 types of CEC adapters. First one that doesn't
know
its HDMI physical address and second one that knows it, because it
analyzed EDID on its own.
In case of first adapters userplane should pass this address to
adapter so it can use it.
Unfortunately right now there is no large support in userplane for new
framework.
The most popular libcec doesn't support framework and I don't know how
they are
planing to obtain and pass this address to adapter.
Maybe they will read this sysfs file. Who knows.
https://github.com/Pulse-Eight/libcec/issues/67

Thats why to make this cec driver "more independent" and I wanted to
somehow
get address from EDID.
But as for now I don't think this is very important and we shouldn't
worry about that.


You really should be talking to Hans Verkuil about this (added to the Cc)
he is usually very willing to help people when it comes to stuff he is
working on.


The physical address needs to be passed from the DRM/KMS driver to the CEC
driver.

Russell King worked on a HDMI notifier framework for this:

https://www.spinics.net/lists/arm-kernel/msg523556.html

I haven't seen any progress on this. It's a good idea, but it is missing
on critical feature: it needs to store the EDID/ELD so that when another
device registers itself so it can be notified it will receive the latest
EDID/ELD versions. With that added it is a very nice framework: CEC drivers
can register themselves and they will receive the EDID whenever it
changes.

I was planning to look into this, but ENOTIME...

This really needs to be done, since I won't accept CEC drivers that do not
automatically use the EDID information. The sole exception to this are
USB CEC dongles since they simply can't know the EDID, that HAS to come from
userspace.

This also means that the Samsung s5p cec driver will remain in staging until
it can use this HDMI notifier to obtain the physical address.

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.

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 19-10-16 21:02, Jarosław Nieć wrote:


On Wed, Oct 19, 2016 at 3:02 PM, Maxime Ripard mailto:maxime.rip...@free-electrons.com>> wrote:

Hi,

On Mon, Oct 17, 2016 at 11:33:45PM +0200, Jarosław Nieć wrote:
> BTW Implementing general cec-over-gpio driver could be also quite
> useful for lot of projects.

Rockchip has such a driver already. It's not upstream at the moment,
but your point is valid :)


Are you refering to this driver?
https://github.com/tyeo098/MK908-Kernel-NAND/tree/master/drivers/video/rockchip/hdmi/softcec
Or maybe something new was written?
This old one doesn't look too good. Lot of very ineffective sleeps
and of course lack of support to this new framework.

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


The EDIDs are exposed to the userspace already through a sysfs
file. Did you need them in the kernel too?


Truly I don't know what I need :)
CEC framework supports 2 types of CEC adapters. First one that doesn't know
its HDMI physical address and second one that knows it, because it analyzed 
EDID on its own.
In case of first adapters userplane should pass this address to adapter so it 
can use it.
Unfortunately right now there is no large support in userplane for new 
framework.
The most popular libcec doesn't support framework and I don't know how they are
planing to obtain and pass this address to adapter.
Maybe they will read this sysfs file. Who knows.
https://github.com/Pulse-Eight/libcec/issues/67

Thats why to make this cec driver "more independent" and I wanted to somehow
get address from EDID.
But as for now I don't think this is very important and we shouldn't worry 
about that.


You really should be talking to Hans Verkuil about this (added to the Cc)
he is usually very willing to help people when it comes to stuff he is
working on.

Regards,

Hans (de Goede)

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

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 19-10-16 20:33, Jarosław Nieć wrote:


On Wed, Oct 19, 2016 at 2:55 PM, Maxime Ripard mailto:maxime.rip...@free-electrons.com>> wrote:

On Wed, Oct 19, 2016 at 11:53:10AM +0200, Hans de Goede wrote:
> > > 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.

+1

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

Well, it might not be even shared. Someone hooking it on a GPIO will
have an interrupt on that GPIO, and that will change the polling logic
significantly.

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

You'd still have to tie it to the CEC stuff. And really, it's not a
GPIO, but more just an O and an I ;)


I think I'm little confused about all of this gpio-chip driver and probably
I don't understanding it correctly :)
Do you want to create gpio-driver that "fake" gpio hardware and is
using this HDMI CEC register to read/write CEC line?


Yes that is the idea. Although it is not really fake as theoretically
the CEC pin could be used as a general gpio. Basically the idea is that
if the hardware only offers get and set functionality on the pin and
nothing really CEC specific, that we then should really have one generic
driver to deal with any such hardware, and not an allwinner specific
driver.

The natural abstraction for such a driver to talk to the actual hardware
(be it allwinner or other hw) would be to use the gpio interface.


How in that case implement interrupts for such fake gpio?


GPIOs can be interrupts too, e.g. the cec driver would do:

struct gpio_desc *cec_gpio = gpiod_get(dev, ...);

int irq = gpiod_to_irq(cec_gpio);

devm_request_threaded_irq(dev, irq, NULL, cec_gpio_irq_handler, 
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
  "cec_irq", cec_data);

To register an irq on rising and falling edges on the gpio
pin. If you want to use this you can even make the availability
of irq functionality on the gpio mandatory in your cec-gpio driver
and then when someone needs things to work without irq functionality
they can extend it.

The cool thing about this approach is that it will give instant CEC
capability to any (new) board where an edge irq capable GPIO is
available, just hook up the HMDI connector CEC pin to an edge IRQ
capable gpio and even non CEC capable HDMI encoders can do CEC :)


We would still need to pool this register periodically to check if state 
changed.
Only if we use interrupts we can eliminate need of timers in cec module.

If I'm wrong please explain this a little more. :)

BTW. There is second line HPD (Hot-Plug-Detect) that has very similar
interface as CEC. How this will be handled in HDMI driver?


AFAIK hotplug functionality is the encoder drivers responsibility.

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.

Re: [linux-sunxi] Kernel CEC driver.

[Jarosław Nieć]

On Wed, Oct 19, 2016 at 3:02 PM, Maxime Ripard <
maxime.rip...@free-electrons.com> wrote:

> Hi,
>
> On Mon, Oct 17, 2016 at 11:33:45PM +0200, Jarosław Nieć wrote:
> > BTW Implementing general cec-over-gpio driver could be also quite
> > useful for lot of projects.
>
> Rockchip has such a driver already. It's not upstream at the moment,
> but your point is valid :)
>

Are you refering to this driver?
https://github.com/tyeo098/MK908-Kernel-NAND/tree/master/drivers/video/rockchip/hdmi/softcec
Or maybe something new was written?
This old one doesn't look too good. Lot of very ineffective sleeps
and of course lack of support to this new framework.


> > > > 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
>
> The EDIDs are exposed to the userspace already through a sysfs
> file. Did you need them in the kernel too?


Truly I don't know what I need :)
CEC framework supports 2 types of CEC adapters. First one that doesn't know
its HDMI physical address and second one that knows it, because it analyzed
EDID on its own.
In case of first adapters userplane should pass this address to adapter so
it can use it.
Unfortunately right now there is no large support in userplane for new
framework.
The most popular libcec doesn't support framework and I don't know how they
are
planing to obtain and pass this address to adapter.
Maybe they will read this sysfs file. Who knows.
https://github.com/Pulse-Eight/libcec/issues/67

Thats why to make this cec driver "more independent" and I wanted to somehow
get address from EDID.
But as for now I don't think this is very important and we shouldn't worry
about that.

Jarek

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

Re: [linux-sunxi] Kernel CEC driver.

[Jarosław Nieć]

On Wed, Oct 19, 2016 at 2:55 PM, Maxime Ripard <
maxime.rip...@free-electrons.com> wrote:

> On Wed, Oct 19, 2016 at 11:53:10AM +0200, Hans de Goede wrote:
> > > > 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.
>
> +1
>
> > 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.
>
> Well, it might not be even shared. Someone hooking it on a GPIO will
> have an interrupt on that GPIO, and that will change the polling logic
> significantly.
>
> > 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.
>
> You'd still have to tie it to the CEC stuff. And really, it's not a
> GPIO, but more just an O and an I ;)
>
>
I think I'm little confused about all of this gpio-chip driver and probably
I don't understanding it correctly :)
Do you want to create gpio-driver that "fake" gpio hardware and is
using this HDMI CEC register to read/write CEC line?
How in that case implement interrupts for such fake gpio?
We would still need to pool this register periodically to check if state
changed.
Only if we use interrupts we can eliminate need of timers in cec module.

If I'm wrong please explain this a little more. :)

BTW. There is second line HPD (Hot-Plug-Detect) that has very similar
interface as CEC. How this will be handled in HDMI driver?

Jarek

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

Re: [linux-sunxi] Kernel CEC driver.

[Maxime Ripard]

Hi,

On Mon, Oct 17, 2016 at 11:33:45PM +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 :)

If you have something that works already, it would be kind of a shame
to 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 (1Hz).
> > > 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.

Yeah, this pin is not muxable unfortunately.

> BTW Implementing general cec-over-gpio driver could be also quite
> useful for lot of projects.

Rockchip has such a driver already. It's not upstream at the moment,
but your point is valid :)

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

The EDIDs are exposed to the userspace already through a sysfs
file. Did you need them in the kernel too?

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.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Kernel CEC driver.

[Maxime Ripard]

On Wed, Oct 19, 2016 at 11:53:10AM +0200, Hans de Goede wrote:
> > > 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.

+1

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

Well, it might not be even shared. Someone hooking it on a GPIO will
have an interrupt on that GPIO, and that will change the polling logic
significantly.

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

You'd still have to tie it to the CEC stuff. And really, it's not a
GPIO, but more just an O and an I ;)

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.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 19-10-16 11:57, Chen-Yu Tsai wrote:

On Wed, Oct 19, 2016 at 5:53 PM, Hans de Goede  wrote:

Hi,


On 19-10-16 05:16, Chen-Yu Tsai wrote:


On Tue, Oct 18, 2016 at 6:14 PM, Hans de Goede 
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
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 (1Hz).
> 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.


Well since all boards which have it routed route it to the HDMI connector
just having the hdmi-encoder driver register a gpio_chip with a single pin
seems fine to me and is a much more KISS solution.

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.

Re: [linux-sunxi] Kernel CEC driver.

[Chen-Yu Tsai]

On Wed, Oct 19, 2016 at 5:53 PM, Hans de Goede  wrote:
> Hi,
>
>
> On 19-10-16 05:16, Chen-Yu Tsai wrote:
>>
>> On Tue, Oct 18, 2016 at 6:14 PM, Hans de Goede 
>> 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
 >>> >
 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 (1Hz).
 > 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 linu

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 19-10-16 05:16, Chen-Yu Tsai wrote:

On Tue, Oct 18, 2016 at 6:14 PM, Hans de Goede  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
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 (1Hz).
> 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.

Re: [linux-sunxi] Kernel CEC driver.

[Chen-Yu Tsai]

On Tue, Oct 18, 2016 at 6:14 PM, Hans de Goede  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
>> 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 (1Hz).
>> > 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.

Re: [linux-sunxi] Kernel CEC driver.

[Hans de Goede]

Hi,

On 17-10-16 23:33, Jarosław Nieć wrote:

Hi Maxime,

On Mon, Oct 17, 2016 at 9:51 PM, Maxime Ripard 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 (1Hz).
> 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.


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.

Re: [linux-sunxi] Kernel CEC driver.

[Jarosław Nieć]

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 (1Hz).
> > 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.

Re: [linux-sunxi] Kernel CEC driver.

[Maxime Ripard]

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 (1Hz).
> 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

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


signature.asc
Description: PGP signature

Re: [linux-sunxi] Kernel CEC driver.

[jonsm...@gmail.com]

On Mon, Oct 17, 2016 at 3:07 PM, Jarosław Nieć  wrote:
>>
>> https://groups.google.com/forum/#!topic/linux-sunxi/l5jhSY8PDFA
>>
>> This thread does seem to suggest there is (some) CEC hardware...
>>
>> Also some code here ;
>> https://groups.google.com/forum/#!msg/linux-sunxi/cNbMiwzgGJ0/tK-KvXkn-pQJ
>>
>> Not sure if you missed it or i'm blind, just ignore if nonsense ;)
>>
>
> I saw this code and my implementation use it as a reference how to use
> HDMI-CEC register. Unfortunately this implementation is unfinished and AFAIK
> is using very ineffective busy-wait loop.
> CEC hardware in A10 is very very simple and basically is just mapping of CEC
> line state to register in memory. It isn't similar to other CEC cores that
> can transmit/receive whole messages on its own.
> Thats why we need to use bit banging in kernel to use it at all.


I believe there is a bitbanging I2C implementation already in the
kernel. Might make a good place to start from.


>
> Regards, Jarek
>
> --
> 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.



-- 
Jon Smirl
jonsm...@gmail.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.

Re: [linux-sunxi] Kernel CEC driver.

[Jarosław Nieć]

>
>
> https://groups.google.com/forum/#!topic/linux-sunxi/l5jhSY8PDFA
>
> This thread does seem to suggest there is (some) CEC hardware...​
>
> Also some code here ;
> https://groups.google.com/forum/#!msg/linux-sunxi/cNbMiwzgGJ0/tK-KvXkn-pQJ
>
> Not sure if you missed it or i'm blind, just ignore if nonsense ;)
>
>
I saw this code and my implementation use it as a reference how to use HDMI-CEC
register. Unfortunately this implementation is unfinished and AFAIK is
using very ineffective busy-wait loop.
CEC hardware in A10 is very very simple and basically is just mapping of
CEC line state to register in memory. It isn't similar to other CEC cores
that can transmit/receive whole messages on its own.
Thats why we need to use bit banging in kernel to use it at all.

Regards, Jarek

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

Re: [linux-sunxi] Kernel CEC driver.

[Bastiaan van den Berg]

https://groups.google.com/forum/#!topic/linux-sunxi/l5jhSY8PDFA

This thread does seem to suggest there is (some) CEC hardware...​

Also some code here ;
https://groups.google.com/forum/#!msg/linux-sunxi/cNbMiwzgGJ0/tK-KvXkn-pQJ

Not sure if you missed it or i'm blind, just ignore if nonsense ;)

--
buZz

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

[linux-sunxi] Kernel CEC driver.

[Jarosław Nieć]

Hi

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.

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 (1Hz).
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?

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 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?
Any idea how to correctly handle this driver in device tree of these CPUs?

4) Are there any information how CEC is implemented for new CPUs? Is it
supported at all by allwinner 3.4 kernel?
Isn't this implementation inside hdmi blob that is present for new CPUs?

Regards,
Jarek

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