From: gianluca <gianlucarenzi@eurekelettronica.it>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Using LVDS in a iMX6Q/D from Barebox
Date: Wed, 15 Feb 2017 15:34:55 +0100 [thread overview]
Message-ID: <e77ad532-0850-45a7-d41e-90e83b655dbf@eurekelettronica.it> (raw)
In-Reply-To: <20170215115104.qez5tgbsvwt3zxzz@pengutronix.de>
On 02/15/2017 12:51 PM, Sascha Hauer wrote:
> On Tue, Feb 14, 2017 at 11:32:44AM +0100, gianluca wrote:
>> On 02/10/2017 08:35 AM, Sascha Hauer wrote:
>>> Hi Gianluca,
>>>
>>> On Thu, Feb 09, 2017 at 03:37:41PM +0100, gianluca wrote:
>>>> Hello,
>>>> I would like to know if there is a clear way on using the lvds pins to drive
>>>> a LVDS display in a custom made board, based on iMX6Q (in the near future
>>>> the iMX6Dual).
>>>
>>> I think what you are looking for is of_device_enable_and_register() or
>>> of_device_enable_and_register_by_name(). You can call it on either the
>>> lvds device node or the hdmi device node, depending on whether you found
>>> an EEPROM or not.
>>>
>>
>> I think this is not necessary as during boot I can see clearly:
>>
>>> imx-ipuv3 2400000.ipu: IPUv3H probed
>>> imx-ipuv3 2800000.ipu: IPUv3H probed
>>> imx-ldb ldb.10: probe failed: Invalid argument
>>> imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
>>
>> So barebox is trying to bring-up the imx-ldb but fails.
>>
>> So I suppose something is wrong in my device tree structure.
>
> Nope, there's everything right.
>
> I can reproduce this here on a GuF Santaro board. LVDS works fine on
> current barebox as long as I leave hdmi disabled in the device tree.
> When I enable hdmi I also get a "failed to get modes".
>
> Normally when different outputs are available then one would expect
> that each one of them is routed to some framebuffer, maybe with some
> sane default and configurable during runtime. The current code falls
> short here.
> What happens is each framebuffer looks around for outputs, all finding
> hdmi and lvds. Now the hdmi output may not have a monitor connected
> and returns no valid mode. In this case the lvds is not even asked for
> modes.
> Also in the current code it can happen that the lvds is asked for modes
> which are then applied to hdmi.
> Where we currently are is that it should work when exactly one output
> is enabled. Does lvds work properly when hdmi is disabled? In this
> case I would suggest that you manipulate your devicetree so that exactly
> one output is enabled.
>
That's works. Thank you!
Now I am planning to adapt the (internal) and external device-tree to
match the hardware.
First of all hdmi and ldb node are "disabled" by default.
Then I am looking for any eeprom in the lvds connector I have.
If it is found, check the phandle "native-mode" of the display-timings
node to match the value found in eeprom. If not matches the native-mode,
it should change the native-mode phandle accordingly with the value
found. (I was thinking about of_find_node_by_name() and then change its
value using of_set_property_to_child_phandle(display, "native-mode")).
And finally change the status of ldb node from "disabled" to "okay". Is
this the correct way of doing this?
If no eeprom is found activate the status of the hdmi node from
"disabled" to "okay". So with the same algorithm as above,
Those operations will be done in the coredevice_initcall() level. Is
this correct?
Regards,
--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2017-02-15 14:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 14:37 gianluca
2017-02-10 7:35 ` Sascha Hauer
2017-02-14 10:32 ` gianluca
2017-02-14 10:59 ` gianluca
2017-02-15 10:07 ` gianluca
2017-02-15 11:51 ` Sascha Hauer
2017-02-15 14:34 ` gianluca [this message]
2017-02-16 7:28 ` Sascha Hauer
2017-02-16 9:07 ` gianluca
2017-02-16 14:43 ` gianluca
2017-02-16 15:50 ` Lucas Stach
2017-02-17 15:38 ` gianluca
2017-02-22 8:00 ` Sascha Hauer
2017-02-22 8:26 ` gianluca
2017-02-22 9:05 ` gianluca
2017-02-22 9:40 ` Sascha Hauer
2017-02-23 12:10 ` gianluca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e77ad532-0850-45a7-d41e-90e83b655dbf@eurekelettronica.it \
--to=gianlucarenzi@eurekelettronica.it \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox