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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
