mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: gianluca <gianlucarenzi@eurekelettronica.it>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Using LVDS in a iMX6Q/D from Barebox
Date: Fri, 17 Feb 2017 16:38:37 +0100	[thread overview]
Message-ID: <638491f2-9946-e9b1-e84e-e9ae05464bcc@eurekelettronica.it> (raw)
In-Reply-To: <1487260229.13536.33.camel@pengutronix.de>

On 02/16/2017 04:50 PM, Lucas Stach wrote:
> Am Donnerstag, den 16.02.2017, 15:43 +0100 schrieb gianluca:
>> On 02/16/2017 08:28 AM, Sascha Hauer wrote:
>>> On Wed, Feb 15, 2017 at 03:34:55PM +0100, gianluca wrote:
>>>> 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:
>>>> 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?
>>>
>>> Sounds like a plan. I'm not sure though if you find your EEPROM at
>>> coredevice_initcall time.
>>>
>>
>> Nope. Accessing device drivers (enabled in the device-tree) is possible
>> in the section: device_initcall() and *NOT* in the coredevice_initcall()
>> time.
>>
>> Anyway I was wondering if looking for a node in the device-tree, it will
>> be possible to change the status of that node.
>>
>> in DTS I have
>>
>> &hdmi {
>> 	status="disabled";
>> }
>>
>> but I need to set the status to "okay" later on the device_initcall() time.
>>
>> Iterating in the device tree using for_each_node_by_name_from() does not
>> show any node like hdmi, but using the same function to look for any
>> "display-timing" section it works.
>
> The node isn't called just "hdmi", that is just the handle, which may
> not even be present in the final DTB if nothing uses it. The nodes name
> is "hdmi@0120000".
>
> See "arch/arm/boot/dts/imx6qdl.dtsi".
>

Ok, thank you for hints.

 From my dts file:

> &hdmi {
> 	ddc-i2c-bus = <&i2c2>;
> 	status = "disabled";
> };
>

It is disabled by default. It will be enabled later by my 
device_initcall() function.

> &ldb {
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 	status = "disabled";
>

As the hdmi node.

> 	lvds0: lvds-channel@0 {
> 		fsl,data-mapping = "spwg";
> 		fsl,data-width = <24>;
> 		status = "disabled";
>

Just for sure it is disabled too!


> 		display-timings {
> 			native-mode = <&am128080n3tz>;

This is fixed. It will be changed during the device_initcall() functions.

> 			/* DISPLAY 1280x800 AMPIRE AM1280800N3TZ */
> 			am128080n3tz: am1280800n3tz {
> 				clock-frequency = <71000000>;
> 				hactive = <1280>;
> 				vactive = <800>;
> 				hback-porch = <50>;
> 				hfront-porch = <50>;
> 				vback-porch = <5>;
> 				vfront-porch = <5>;
> 				hsync-len = <60>;
> 				vsync-len = <13>;
> 				hsync-active = <0>;
> 				vsync-active = <0>;
> 				de-active = <1>;
> 				pixelclk-active = <0>;
> 			};
> 			/* DISPLAY 1024x600 AMPIRE AM-1024600LTM LVDS */
> 			am1024600l: am1024600l {
> 				clock-frequency = <51200000>;
> 				hactive = <1024>;
> 				vactive = <600>;
> 				hback-porch = <0>;
> 				hfront-porch = <320>;
> 				vback-porch = <0>;
> 				vfront-porch = <35>;
> 				hsync-len = <1>;
> 				vsync-len = <1>;
> 				hsync-active = <0>;
> 				vsync-active = <0>;
> 				de-active = <1>;
> 				pixelclk-active = <0>;
> 			};
> 			/* DISPLAY 800x480 */
> 			ph800480t013: ph800480t013 {
> 				clock-frequency = <33300000>;
> 				hactive = <800>;
> 				vactive = <480>;
> 				hback-porch = <46>;
> 				hfront-porch = <210>;
> 				vback-porch = <23>;
> 				vfront-porch = <22>;
> 				hsync-len = <1>;
> 				vsync-len = <1>;
> 				hsync-active = <0>;
> 				vsync-active = <0>;
> 				de-active = <1>;
> 				pixelclk-active = <0>;
> 			};
> 		};
>
> 		port@4 {
> 			reg = <4>;
> 			lvds0_out: endpoint {
> 				remote-endpoint = <&in_lvds0>;
> 			};
> 		};
>
> 	};
> };

The device_initcall() functions is looking for an eeprom on the lvds 
channel, and if found it will matched against the native-mode phandle.
If it is different from the default, a new native-mode will be placed as 
native-mode, and afterall the lvds-channel@0 and ldb will be flagged in 
status as "okay".

Then the of_device_enable_and_register_by_name("ldb@020e0008") will be 
called.

In the same way if an eeprom is found on the hdmi connector bus, the 
hdmi status will be changed to "okay".

If there is no display (so no eeprom either) connected on the lvds 
connector, the device_initcall() functions will let all ldb stuff as 
default (i.e. disabled) and it will enable the hdmi section if there is 
a hdmi display (and its eeprom EDID) connected.

The problem is the modeset of framebuffer (.num_modes): this list is 
created from the device-tree sequence and the default does not respect 
the native-mode section. i.e. if I have a 800x480 native mode display 
timing in the device tree as a third option, the fb0.modes will have the 
800x480 in the third place.

There is a quick (and dirty) way of calling the fb0.mode_name inside a 
device_initcall()?

Or I have to use the shell script in init to adapt it correctly?

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

  reply	other threads:[~2017-02-17 15:39 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
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 [this message]
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=638491f2-9946-e9b1-e84e-e9ae05464bcc@eurekelettronica.it \
    --to=gianlucarenzi@eurekelettronica.it \
    --cc=barebox@lists.infradead.org \
    --cc=l.stach@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