Discussion:
Re HDMI transmitter interface
Robert Swindells
2014-09-22 18:15:00 UTC
Permalink
I made some progress on the TDA19988 HDMI transmitter driver as
found in the beaglebone black (doens't work yet, sorry :).
The driver will attach directly to the i2c bus, because other
devices are also connected to this bus (eeprom, the power managenent IC, and
more depending on connected capes). Then the TDA19988 driver and the
video drivers have to talk together: the TDA19988 driver knows when a
monitor is connected/disconnected and also can read the EDID, and
the video driver knows which mode to select.
Had you considered using the drmkms code for this SoC ?

Current Linux sources have a driver for the display and for this HDMI
transmitter.

They were added to Linux after the last import that riastradh@ made so
are not in the NetBSD tree yet.

Robert Swindells
Manuel Bouyer
2014-09-23 06:53:04 UTC
Permalink
Post by Robert Swindells
I made some progress on the TDA19988 HDMI transmitter driver as
found in the beaglebone black (doens't work yet, sorry :).
The driver will attach directly to the i2c bus, because other
devices are also connected to this bus (eeprom, the power managenent IC, and
more depending on connected capes). Then the TDA19988 driver and the
video drivers have to talk together: the TDA19988 driver knows when a
monitor is connected/disconnected and also can read the EDID, and
the video driver knows which mode to select.
Had you considered using the drmkms code for this SoC ?
No, I though drmkms was x86 only.
Post by Robert Swindells
Current Linux sources have a driver for the display and for this HDMI
transmitter.
are not in the NetBSD tree yet.
What is the licence of this code ? I think it's a case where it would be
better to avoid the GPL.
--
Manuel Bouyer <***@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
Robert Swindells
2014-09-23 10:52:35 UTC
Permalink
Post by Manuel Bouyer
Post by Robert Swindells
I made some progress on the TDA19988 HDMI transmitter driver as
found in the beaglebone black (doens't work yet, sorry :).
The driver will attach directly to the i2c bus, because other
devices are also connected to this bus (eeprom, the power managenent IC, and
more depending on connected capes). Then the TDA19988 driver and the
video drivers have to talk together: the TDA19988 driver knows when a
monitor is connected/disconnected and also can read the EDID, and
the video driver knows which mode to select.
Had you considered using the drmkms code for this SoC ?
No, I though drmkms was x86 only.
It can be used on any architecture.
Post by Manuel Bouyer
Post by Robert Swindells
Current Linux sources have a driver for the display and for this HDMI
transmitter.
are not in the NetBSD tree yet.
What is the licence of this code ? I think it's a case where it would be
better to avoid the GPL.
I had not checked the licence when I wrote the original email, it is
GPL v2 and I agree that we wouldn't want it in tree.

Both bits were written by the same person (at TI), maybe ask if they
would dual licence it.

The drm code is licenced under mixture of BSD and GPL. The core stuff
and mass market GPU drivers are BSD, more recent SoC drivers look to
be mostly GPL.

We might want a plan for how to do framebuffers and X11 across all the
SoCs. Do we stick to using wsfb and xf86-video-wsfb or recommend that
new ports use drmkms and either xf86-video-modeswitching or a more
specific X11 driver ?

Maybe take this to tech-x11 ?

Robert Swindells
Martin Husemann
2014-09-23 11:23:38 UTC
Permalink
Post by Robert Swindells
It can be used on any architecture.
In principle, but not the code in tree currently - at least not last
time I looked. Fixing that would be a good thing(tm).

Martin
matthew green
2014-09-24 00:05:13 UTC
Permalink
Post by Robert Swindells
I had not checked the licence when I wrote the original email, it is
GPL v2 and I agree that we wouldn't want it in tree.
Both bits were written by the same person (at TI), maybe ask if they
would dual licence it.
The drm code is licenced under mixture of BSD and GPL. The core stuff
and mass market GPU drivers are BSD, more recent SoC drivers look to
be mostly GPL.
We might want a plan for how to do framebuffers and X11 across all the
SoCs. Do we stick to using wsfb and xf86-video-wsfb or recommend that
new ports use drmkms and either xf86-video-modeswitching or a more
specific X11 driver ?
Maybe take this to tech-x11 ?
we should take this to the authors of this code and ask them for
the same dual-license the rest of the drm code has.

anyone want to carry the torch? :)


.mrg.
Roy Marples
2014-09-24 00:37:25 UTC
Permalink
Post by matthew green
anyone want to carry the torch? :)


Apologies :)

R
Taylor R Campbell
2014-09-23 13:38:53 UTC
Permalink
Date: Tue, 23 Sep 2014 08:53:04 +0200
Post by Robert Swindells
Had you considered using the drmkms code for this SoC ?
No, I though drmkms was x86 only.

The generic drmkms code is MI. The Intel graphics driver is x86-only
but only because Intel graphics is x86-only. Currently radeon is
x86-only but only because there's no MI way to get bus_dma-safe pages
backing a uvm anonymous object -- if we fix that, it'll be MI.

What is the licence of this code ? I think it's a case where it would be
better to avoid the GPL.

If it's GPL, we can make kernel modules.
Martin Husemann
2014-09-23 13:41:25 UTC
Permalink
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.

Martin
Taylor R Campbell
2014-09-23 13:47:03 UTC
Permalink
Date: Tue, 23 Sep 2014 15:41:25 +0200
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.

Why not? Can't the boot loader load modules?
Matt Thomas
2014-09-23 15:26:46 UTC
Permalink
Post by Taylor R Campbell
Date: Tue, 23 Sep 2014 15:41:25 +0200
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.
Why not? Can't the boot loader load modules?
No, arm is typically only monolithic kernels. There is no NetBSD bootloader,
just u-boot or similar.
Christoph Egger
2014-09-23 18:24:25 UTC
Permalink
Post by Matt Thomas
Post by Taylor R Campbell
Date: Tue, 23 Sep 2014 15:41:25 +0200
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.
Why not? Can't the boot loader load modules?
No, arm is typically only monolithic kernels. There is no NetBSD bootloader,
just u-boot or similar.
AFAIK arm has a device tree in the firmware you use to load modules.

Christoph
Manuel Bouyer
2014-09-23 18:29:48 UTC
Permalink
Post by Christoph Egger
Post by Matt Thomas
Post by Taylor R Campbell
Date: Tue, 23 Sep 2014 15:41:25 +0200
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.
Why not? Can't the boot loader load modules?
No, arm is typically only monolithic kernels. There is no NetBSD bootloader,
just u-boot or similar.
AFAIK arm has a device tree in the firmware you use to load modules.
No, that's not how NetBSD works on these devices (at last one some of them,
including the beaglebone black). It could be used to load module
once the kernel has booted, but you want to have the console available
as early as possible.
--
Manuel Bouyer <***@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
Matt Thomas
2014-09-23 19:52:14 UTC
Permalink
Post by Christoph Egger
Post by Matt Thomas
Post by Taylor R Campbell
Date: Tue, 23 Sep 2014 15:41:25 +0200
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.
Why not? Can't the boot loader load modules?
No, arm is typically only monolithic kernels. There is no NetBSD bootloader,
just u-boot or similar.
AFAIK arm has a device tree in the firmware you use to load modules.
That device tree, if present, is presented only to linux kernels. And it
will not help you load modules since u-boot will not assist with that.
Christoph Egger
2014-09-23 21:12:37 UTC
Permalink
Post by Matt Thomas
Post by Christoph Egger
Post by Matt Thomas
Post by Taylor R Campbell
Date: Tue, 23 Sep 2014 15:41:25 +0200
Post by Taylor R Campbell
If it's GPL, we can make kernel modules.
That is not very practical for display drivers on platforms like Manuel
is working on.
Why not? Can't the boot loader load modules?
No, arm is typically only monolithic kernels. There is no NetBSD bootloader,
just u-boot or similar.
AFAIK arm has a device tree in the firmware you use to load modules.
That device tree, if present, is presented only to linux kernels.
Not quite true, FreeBSD has support for it.

Christoph
Post by Matt Thomas
And it will not help you load modules since u-boot will not assist
with that.
Martin Husemann
2014-09-24 06:24:36 UTC
Permalink
Post by Christoph Egger
Not quite true, FreeBSD has support for it.
All theoretical discussions aside, it is not usefull for booting modular
NetBSD kernels from u-boot, so we need a solution usable in monolithic
kernels for this case.

Martin

Continue reading on narkive:
Loading...