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
<[email protected]
<mailto:[email protected]>> 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
<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 [email protected].
For more options, visit https://groups.google.com/d/optout.