On 01.02.2015 15:16, Gabriel Dobato wrote:
>> I'd be happy to take over, but I admit that my current lack of spare
>> time would only allow me to support Gabriel and you.
>>
>> Let's wait for Gabriel's response on how he can help improving
>> Dove mainline with his cm-a510 and baseboard.
>
> First of all, I would like to give thanks all people like you for all
> your help and support. I really appreciate it.
>
> DT is new for me, I have never worked using this kind of hardware
> description, so I am involving in many issues due to my lack of skills
> in this kind of structure.
>
> At this moment, I am focusing in the update of the version of the kernel
> on the CM-A510 board (from 2.6 to 3.1x)in order to give more features to
> the system, but as I said before, I have lots of problems.
>
> Thanks to the help and support of Jean-Francois Moine, I have achieved
> to boot the kernel completely and to mount the rootfs via NFS. I have a
> prompt, what has been a very big step for me.
Gabriel,
great you can boot a recent kernel. I guess you had to quite heavily
modify current dove-cm-a510.dts? Can you upload the one you use now
to any pastebin and send the link?
>> Nope. One dove.dtsi, one dove-cm-a510.dtsi, and one baseboard.dts
>> including dove-cm-a510.dtsi for every baseboard we stumble upon.
>
> In reference to the structure of .dts and .dtsi files, I agree with this
> kind of structure, of course, nobody as you can consider it better. I
> think the idea of make a dove-cm-a510.dtsi file and different
> baseboards.dts depending of the peripherals used is great. But as I say,
> maybe I am not the right person to decide it, Jean-Froncois Moine and
> you have better criteria.So, whatever you decide I would very happy to help.
You didn't mention if you really use the sb-a510, i.e. the Compulab
reference baseboard. Is it what you are using with your cm-a510?
> At this moment, I am trying to configure the framebuffer, but as Moine
> told me,it seems there is not video driver support for this board in
> DT... :( .
Not quite true. Video is made up of at least 4 different devices:
Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
VGA.
We do have a driver for the framebuffer (armada_drm) and there is great
work from Russell King and others on the GPU and Decode engine (IIRC).
If you are using the sb-a510, I can see from the manual, that DVI
transmitter is SIL164.. AFAIS there is a driver for it, that maybe
needs some polishing. Nobody ever tested VGA, but it shouldn't be too
hard to add support for it as it is directly supported by the
framebuffer HW.
One quite important driver at least for Dove is a clock source for
video. Internal clock generators for video are way to limited with
respect to frequencies to allow any useful resolution.
I'll see if I can have a look at the dts stuff this weekend.. that
way we'll have at least the basic done before moving to the other
devices.
Sebastian
On Thu, 05 Feb 2015 23:13:58 +0100
Sebastian Hesselbarth <[email protected]> wrote:
> > At this moment, I am trying to configure the framebuffer, but as Moine
> > told me,it seems there is not video driver support for this board in
> > DT... :( .
>
> Not quite true. Video is made up of at least 4 different devices:
> Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
> VGA.
>
> We do have a driver for the framebuffer (armada_drm) and there is great
> work from Russell King and others on the GPU and Decode engine (IIRC).
Yes, but it has no DT support. Mine has.
> If you are using the sb-a510, I can see from the manual, that DVI
> transmitter is SIL164.. AFAIS there is a driver for it, that maybe
> needs some polishing. Nobody ever tested VGA, but it shouldn't be too
> hard to add support for it as it is directly supported by the
> framebuffer HW.
This asks for some VGA encoder/connector module.
Actually, as Gabriel told me that his screen is directly connected to
the RGB LCD output, I wrote a simple panel for him. This module just
gets the display timings from the DT.
> One quite important driver at least for Dove is a clock source for
> video. Internal clock generators for video are way to limited with
> respect to frequencies to allow any useful resolution.
>From my previous tests with the si5351 in the Cubox, most video modes
should work without external clocks.
> I'll see if I can have a look at the dts stuff this weekend.. that
> way we'll have at least the basic done before moving to the other
> devices.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
On 06.02.2015 08:58, Jean-Francois Moine wrote:
> On Thu, 05 Feb 2015 23:13:58 +0100
> Sebastian Hesselbarth <[email protected]> wrote:
>>> At this moment, I am trying to configure the framebuffer, but as Moine
>>> told me,it seems there is not video driver support for this board in
>>> DT... :( .
>>
>> Not quite true. Video is made up of at least 4 different devices:
>> Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
>> VGA.
>>
>> We do have a driver for the framebuffer (armada_drm) and there is great
>> work from Russell King and others on the GPU and Decode engine (IIRC).
>
> Yes, but it has no DT support. Mine has.
Yeah, it would be nice if you two stick together once again and work
that out for mainline?
>> If you are using the sb-a510, I can see from the manual, that DVI
>> transmitter is SIL164.. AFAIS there is a driver for it, that maybe
>> needs some polishing. Nobody ever tested VGA, but it shouldn't be too
>> hard to add support for it as it is directly supported by the
>> framebuffer HW.
>
> This asks for some VGA encoder/connector module.
Hmm, maybe it is just enough to tell the DRM driver to switch to
VGA and what i2c to use for DDC. I'll have to catch up with DRM
and DT.
> Actually, as Gabriel told me that his screen is directly connected to
> the RGB LCD output, I wrote a simple panel for him. This module just
> gets the display timings from the DT.
Ok. That makes it less complicated as there already should be support
for dumb RGB anyway.
>> One quite important driver at least for Dove is a clock source for
>> video. Internal clock generators for video are way to limited with
>> respect to frequencies to allow any useful resolution.
>
> From my previous tests with the si5351 in the Cubox, most video modes
> should work without external clocks.
Well, this is not about a working corner case.. video modes are (more or
less) standardized and so is the clock frequency. Monitors are allowed
to reject any non-standard modes and it gets worse with TVs.
Ergo, we do want to hit the frequency as close as possible and Dove's
internal PLL simply cannot.
Sebastian
On Fri, Feb 06, 2015 at 08:58:55AM +0100, Jean-Francois Moine wrote:
> On Thu, 05 Feb 2015 23:13:58 +0100
> Sebastian Hesselbarth <[email protected]> wrote:
>
> > > At this moment, I am trying to configure the framebuffer, but as Moine
> > > told me,it seems there is not video driver support for this board in
> > > DT... :( .
> >
> > Not quite true. Video is made up of at least 4 different devices:
> > Framebuffer, GPU, Decode engine, and usually DVI/HDMI transmitter or
> > VGA.
> >
> > We do have a driver for the framebuffer (armada_drm) and there is great
> > work from Russell King and others on the GPU and Decode engine (IIRC).
>
> Yes, but it has no DT support. Mine has.
It has partial DT support. I'm currently waiting for a production Cubox
from SolidRun (Jon Nettleton recently went to Israel, and he and Rabeeh
located one - it's currently with Jon, waiting for him to be well enough
to dispatch it to me.) Maybe that will put an end to my HDMI problems
with DT kernels.
Until then, I've no interest in DT kernels on Dove hardware; they're
basically not functional for me.
> From my previous tests with the si5351 in the Cubox, most video modes
> should work without external clocks.
Jean, let's put this into perspective.
Different HDMI sinks have different tolerances on the video timing
parameters. Some HDMI sinks (such as monitors) accept almost any
timing. Other sinks (such as TVs) are much stricter.
Just because it works for you without using the SI5351 does not make
it a correct implementation. It probably means that you have a HDMI
sink that will accept wildly wrong timing but still display the image.
Other HDMI sinks may decide to ignore such a wrong signal (and many
seem to.)
You've more or less proved that by your investigations into what your
HDMI sink will accept for audio (which is basically anything) which,
again, is not the general rule.
Taking your case and trying to make believe that it applies everywhere
is wholely wrong.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Fri, 06 Feb 2015 11:05:39 +0100
Sebastian Hesselbarth <[email protected]> wrote:
> >> We do have a driver for the framebuffer (armada_drm) and there is great
> >> work from Russell King and others on the GPU and Decode engine (IIRC).
> >
> > Yes, but it has no DT support. Mine has.
>
> Yeah, it would be nice if you two stick together once again and work
> that out for mainline?
It is not important for me to have something in the mainline: my driver
works fine enough for program development, and I don't need video
streaming. On the other hand, Russell said that his system does not
work well in a DT context...
> > Actually, as Gabriel told me that his screen is directly connected to
> > the RGB LCD output, I wrote a simple panel for him. This module just
> > gets the display timings from the DT.
>
> Ok. That makes it less complicated as there already should be support
> for dumb RGB anyway.
I could not find such a module, and, more, these LCD / VGA modules have
to be componentized to work with the armada DRM driver, and same for
mine.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
On Fri, Feb 06, 2015 at 11:05:39AM +0100, Sebastian Hesselbarth wrote:
> Yeah, it would be nice if you two stick together once again and work
> that out for mainline?
I don't see that happening, ever.
While I will (and have) taken patches from Jean which are technically
good (for things which I look after like the TDA998x) I see no
reciprocal good will - all I get is this "my driver is better than
yours" crap all the time.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.