mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: gianluca <gianlucarenzi@eurekelettronica.it>
Cc: barebox@lists.infradead.org
Subject: Re: Using LVDS in a iMX6Q/D from Barebox
Date: Wed, 22 Feb 2017 10:40:01 +0100	[thread overview]
Message-ID: <20170222094001.kjlneun4mpf2mgvk@pengutronix.de> (raw)
In-Reply-To: <75ff7d5a-8952-590f-c6b4-9fc3d4c17753@eurekelettronica.it>

On Wed, Feb 22, 2017 at 09:26:25AM +0100, gianluca wrote:
> On 02/22/2017 09:00 AM, Sascha Hauer wrote:
> > On Fri, Feb 17, 2017 at 04:38:37PM +0100, gianluca wrote:
> > > 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()?
> > 
> > You can do a setenv("fb0.mode_name", "800x480");
> > 
> 
> Yep. I supposed. But putting it inside a C code, need a recompilation. I
> opted for calling explicity in the init script shell to do this kinda stuff.
> 
> > However, it would be nicer to make the native mode the default. struct
> > display_timings already has a native_mode field, but currently noone is
> > interested in its value.
> > 
> 
> Actually in my code I do:
> 
> > static int of_display_timing_set(const char *name)
> > {
> > 	int ret = -1;
> > 	struct device_node *root = NULL;
> > 	struct device_node *display = NULL;
> > 	struct device_node *timing = NULL;
> > 	const char *node = "display-timings";
> > 
> > 	pr_debug("%s Enter with: ACTIVATING %s as NATIVE-MODE\n", __func__, name);
> > 
> > 	root = of_get_root_node();
> > 
> > 	for_each_node_by_name_from(display, root, node) {
> > 		if (display != NULL) {
> > 			for_each_node_by_name_from(display, root, name) {
> > 				timing = display;
> > 				if (timing != NULL) {
> > 					pr_debug("%s Node: %s PTR: 0x%p\n",
> > 						__func__, timing->full_name, timing);
> > 					break;
> > 				}
> > 			}
> > 		} else {
> > 			continue;
> > 		}
> > 	}
> > 
> > 	if (name != NULL && timing != NULL) {
> > 		pr_debug("%s Activating native-mode %s\n", __func__, name);
> > 		/*
> > 		 * Now we have the correct phandle ptr for the correct timing
> > 		 * to point to. Now change the native-mode property to that phandle
> > 		 */
> > 		ret = of_set_property_to_child_phandle(timing, "native-mode");
> > 		if (ret) {
> > 			pr_err("%s Error on setting native-mode to %s\n", __func__, name);
> > 		}
> > 	} else {
> > 		pr_debug("%s Some ptr are NULL! name: %p -- timing: %p\n",
> > 			__func__, name, timing);
> > 	}
> > 	pr_debug("%s Exit with: %d\n", __func__, ret);
> > 	return ret;
> 
> In this way I set as default native-mode the name of the timings passed to
> the function. Is there something better?
> 
> Anyway, now I am doing the same stuff for compatibile property of the panel,
> because Linux wants to have a timing hardcoded in the panel-simple instead
> of getting them from the timing section of the device-tree.
> 
> This is a very lack of feature to me. But now, it is quicker to use the
> bootloader to compile the correctness of the compatible property to a
> almost-identical-timings found in the panel-simple.c...
> 
> The other way is to add a edid chip (@ 0x50) for every panel I add, so to
> let the EDID stuff to discover what is connected or not to the lvds board.
> 
> This issue can not simply solved in this board, because I do have an
> internal eeprom at address 0x50, but it can not be usable for EDID stuff.
> 
> So I have two options:
> 
> 1- let the imx-ldb.c code in the kernel to probe (simple-panel and edid) and
> *add* a way to parse the device-tree for adding mode timing property using
> the display-timing stuff. (this means kernel patch)

And it's a patch you probably cannot upstream as for reasons I do not
understand Thierry refuses to parse timings from the device tree. He
insists on determing timings based on the compatible string.

> 
> 2- look for a common timings from an existing displays in simple-panel.c and
> pass them to the compatibile property of the panel in the device-tree via
> bootloader.

You should add the correct compatible and add support for it to the
simple-panel driver. This also requires a kernel patch, but one you can
upstream.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  parent reply	other threads:[~2017-02-22  9:40 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
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 [this message]
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=20170222094001.kjlneun4mpf2mgvk@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=gianlucarenzi@eurekelettronica.it \
    /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