Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
Subsystems (4)
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4
After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling drm_fbdev_cma_init to create a fbdev.
When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the /dev/dri/* and /dev/fb0 devices.
Any clue what i might be missing during the driver load?
Thanks...
Regards,
C.Palminha
--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
Quoted 7 lines · Carlos Palminha
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4
Quoted 9 lines
After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the 'get_modes' call back of adv7511 driver. (Or, if possible show us the code.)
Best,
-xinliang
Quoted 6 lines
Thanks...
Regards,
C.Palminha
Quoted 13 lines
--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
--- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Xinliang,
My get_modes seems to be implemented as the rcar driver... Probably still missing some init step?
Regards,
C.Palminha
static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
{
struct drm_encoder_slave *slave;
const struct drm_encoder_slave_funcs *sfuncs;
struct arcpgu_drm_connector * con container_of(connector, struct arcpgu_drm_connector, connector);
slave = con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}
sfuncs = slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}
return sfuncs->get_modes(&slave->base,connector);
}
Quoted 50 lines · Xinliang Liu
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>> wrote:
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the 'get_modes' call back of adv7511 driver. (Or, if possible show us the code.)
Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here. :(
-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---
Any help?
Regards,
C.Palminha
Quoted 81 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int
arcpgu_drm_connector_get_modes(struct drm_connector *connector)
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con >container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}sfuncs =
slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}return
sfuncs->get_modes(&slave->base,connector);
}Quoted 50 lines · Xinliang Liu
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>> wrote:
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the 'get_modes' call back of adv7511 driver. (Or, if possible show us the code.)
Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 44 lines · Carlos Palminha
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here.
:(-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---Any help?
Regards,
C.PalminhaQuoted 10 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int arcpgu_drm_connector_get_modes(struct
drm_connector*connector)
Quoted 13 lines
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con =container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave == NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}
Quoted 11 lines
Quoted 6 lines
sfuncs =
slave->slave_funcs;if(sfuncs->get_modes == NULL){
return 0;
}return sfuncs->
get_modes(&slave->base,connector);Quoted 2 lines
}
so, this will call adv7511 driver's
get_modes call back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -M DRM_DRIVER_NAME -c
Quoted 36 lines
Quoted 5 lines · Xinliang Liu
Quoted 4 lines
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>>
Quoted 30 lines · wrote:
Quoted 30 lines
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the 'get_modes' call back of adv7511 driver. (Or, if possible show us the code.)
Best,
-xinliangThanks... Regards, C.Palminha
Quoted 17 lines
Quoted 8 lines
Quoted 8 lines
--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---Quoted 8 lines
Quoted 8 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha
# modetest -M drm-arcpgu -c
Connectors:
id encoder status type size (mm) modes encoders
21 0 disconnected HDMI-A 0x0 0 20
props:
1 EDID:
flags: immutable blob
blobs: value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
#
Quoted 121 lines · Xinliang Liu
Quoted 43 lines · Carlos Palminha
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here.
:(-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---Any help?
Regards,
C.PalminhaQuoted 10 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int arcpgu_drm_connector_get_modes(struct
drm_connector*connector)
Quoted 12 lines
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con >>>container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}Quoted 11 lines
Quoted 6 lines
sfuncs =
slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}return sfuncs->
get_modes(&slave->base,connector);Quoted 2 lines
}
so, this will call adv7511 driver's
get_modescall back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -MDRM_DRIVER_NAME-cQuoted 53 lines
Quoted 5 lines · Xinliang Liu
Quoted 4 lines
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>>
Quoted 46 lines · wrote:
Quoted 46 lines
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the 'get_modes' call back of adv7511 driver. (Or, if possible show us the code.)
Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
when i boot the kernel and connect the HDMI cable after booting i can retrieve 4 modes... :)
if i boot linux with the HDMI cable inserted the kernel hangs. Possible relation with HPD?
Regards,
C.Palminha
# modetest -M drm-arcpgu -c
Connectors:
id encoder status type size (mm) modes encoders
21 0 connected HDMI-A 0x0 4 20
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
800x600 60 800 840 968 1056 600 601 605 628 flags: phsync, pvsync; type: driver
800x600 56 800 824 896 1024 600 601 603 625 flags: phsync, pvsync; type: driver
848x480 60 848 864 976 1088 480 486 494 517 flags: phsync, pvsync; type: driver
640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver
props:
1 EDID:
flags: immutable blob
blobs: value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
#
Quoted 146 lines · Carlos Palminha
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 disconnected HDMI-A 0x0 0 20 props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 121 lines · Xinliang Liu
Quoted 43 lines · Carlos Palminha
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here.
:(-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---Any help?
Regards,
C.PalminhaQuoted 10 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int arcpgu_drm_connector_get_modes(struct
drm_connector*connector)
Quoted 12 lines
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con >>>>container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}Quoted 11 lines
Quoted 6 lines
sfuncs =
slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}return sfuncs->
get_modes(&slave->base,connector);Quoted 2 lines
}
so, this will call adv7511 driver's
get_modescall back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -MDRM_DRIVER_NAME-cQuoted 53 lines
Quoted 5 lines · Xinliang Liu
Quoted 4 lines
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>>
Quoted 46 lines · wrote:
Quoted 46 lines
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the 'get_modes' call back of adv7511 driver. (Or, if possible show us the code.)
Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Carlos Palminha
when i boot the kernel and connect the HDMI cable after booting i can retrieve 4 modes... :)
if i boot linux with the HDMI cable inserted the kernel hangs.
What's the hang kernel log. Is it a oops?
Quoted 1 line
Possible relation with HPD?
Yes, I think there might be something wrong with the HPD interrupt or the EDID ready interrupt.
I do meet the similar issue before when I using the upstream adv7511 driver to enable adv7533.
I found that the HPD and EDID interrupt is not reliable.
In order to get modes stably, I have to add some delay like bellow:
--
drivers/gpu/drm/i2c/adv7511.c +2 -0
@@ -657,6 +657,8 @@ static int adv7511_get_modes(struct adv7511 *adv7511,regmap_update_bits (adv7511->regmap,ADV7511_REG_POWER ,ADV7511_POWER_POWER_DOWN ,0 ); adv7511->current_edid_segment =-1 ; +/* wait some time for edid is ready */ +msleep (200 ); } edid =drm_do_get_edid (connector, adv7511_get_edid_block, adv7511);
--
Best,
-xinliang
Quoted 174 lines
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 connected HDMI-A 0x0 4 20 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 800x600 60 800 840 968 1056 600 601 605 628 flags: phsync, pvsync; type: driver 800x600 56 800 824 896 1024 600 601 603 625 flags: phsync, pvsync; type: driver 848x480 60 848 864 976 1088 480 486 494 517 flags: phsync, pvsync; type: driver 640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 146 lines · Carlos Palminha
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 disconnected HDMI-A 0x0 0 20 props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 121 lines · Xinliang Liu
Quoted 43 lines · Carlos Palminha
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here.
:(-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---Any help?
Regards,
C.PalminhaQuoted 10 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int arcpgu_drm_connector_get_modes(struct
drm_connector*connector)
Quoted 12 lines
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con >>>>>container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}Quoted 11 lines
Quoted 6 lines
sfuncs =
slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}return sfuncs->
get_modes(&slave->base,connector);Quoted 2 lines
}
so, this will call adv7511 driver's
get_modescall back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -MDRM_DRIVER_NAME-cQuoted 53 lines
Quoted 5 lines · Xinliang Liu
Quoted 4 lines
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>>
Quoted 46 lines · wrote:
Quoted 46 lines
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the '
get_modes' call back of adv7511 driver. (Or, if possible show us the code.)Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
i made some progress in identifying the issue...
When my driver calls drm_fb_helper_initial_config it seems DRM blocks waiting for register_framebuffer to return. The sequence is drm_fb_helper_initial_config->drm_fb_helper_single_fb_probe->register_framebuffer.
Its strange because register_framebuffer function is just a mutex around do_register_framebuffer.
Any clue?!
Quoted 207 lines · Xinliang Liu
Quoted 3 lines · Carlos Palminha
when i boot the kernel and connect the HDMI cable after booting i can retrieve 4 modes... :)
if i boot linux with the HDMI cable inserted the kernel hangs.
What's the hang kernel log. Is it a oops?
Quoted 1 line
Possible relation with HPD?
Yes, I think there might be something wrong with the HPD interrupt or the EDID ready interrupt.
I do meet the similar issue before when I using the upstream adv7511 driver to enable adv7533.
I found that the HPD and EDID interrupt is not reliable.
In order to get modes stably, I have to add some delay like bellow:
--drivers/gpu/drm/i2c/adv7511.c +2
-1@@ -657,6 +657,8 @@ static int adv7511_get_modes(struct adv7511 *adv7511,regmap_update_bits (adv7511->regmap,ADV7511_REG_POWER ,ADV7511_POWER_POWER_DOWN ,0 ); adv7511->current_edid_segment =-1 ; +/* wait some time for edid is ready */ +msleep (200 ); } edid =drm_do_get_edid (connector, adv7511_get_edid_block, adv7511); --Best,
-xinliangQuoted 174 lines
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 connected HDMI-A 0x0 4 20 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 800x600 60 800 840 968 1056 600 601 605 628 flags: phsync, pvsync; type: driver 800x600 56 800 824 896 1024 600 601 603 625 flags: phsync, pvsync; type: driver 848x480 60 848 864 976 1088 480 486 494 517 flags: phsync, pvsync; type: driver 640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 146 lines · Carlos Palminha
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 disconnected HDMI-A 0x0 0 20 props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 121 lines · Xinliang Liu
Quoted 43 lines · Carlos Palminha
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here.
:(-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---Any help?
Regards,
C.PalminhaQuoted 10 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int arcpgu_drm_connector_get_modes(struct
drm_connector*connector)
Quoted 12 lines
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con >>>>>>container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}Quoted 11 lines
Quoted 6 lines
sfuncs =
slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}return sfuncs->
get_modes(&slave->base,connector);Quoted 2 lines
}
so, this will call adv7511 driver's
get_modescall back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -MDRM_DRIVER_NAME-cQuoted 53 lines
Quoted 5 lines · Xinliang Liu
Quoted 4 lines
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>>
Quoted 46 lines · wrote:
Quoted 46 lines
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the '
get_modes' call back of adv7511 driver. (Or, if possible show us the code.)Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
hi...
i just found that its blocking waiting for console_lock...
@vineet, alexey: i think that console_lock is architecture dependent right? Do you know any issue with console_lock for ARC?
Quoted 216 lines · Carlos Palminha
i made some progress in identifying the issue...
When my driver callsdrm_fb_helper_initial_configit seems DRM blocks waiting forregister_framebufferto return. The sequence isdrm_fb_helper_initial_config->drm_fb_helper_single_fb_probe->register_framebuffer.Its strange because
register_framebufferfunction is just a mutex arounddo_register_framebuffer.Any clue?!
Quoted 207 lines · Xinliang Liu
Quoted 3 lines · Carlos Palminha
when i boot the kernel and connect the HDMI cable after booting i can retrieve 4 modes... :)
if i boot linux with the HDMI cable inserted the kernel hangs.
What's the hang kernel log. Is it a oops?
Quoted 1 line
Possible relation with HPD?
Yes, I think there might be something wrong with the HPD interrupt or the EDID ready interrupt.
I do meet the similar issue before when I using the upstream adv7511 driver to enable adv7533.
I found that the HPD and EDID interrupt is not reliable.
In order to get modes stably, I have to add some delay like bellow:
--drivers/gpu/drm/i2c/adv7511.c +2
-1@@ -657,6 +657,8 @@ static int adv7511_get_modes(struct adv7511 *adv7511,regmap_update_bits (adv7511->regmap,ADV7511_REG_POWER ,ADV7511_POWER_POWER_DOWN ,0 ); adv7511->current_edid_segment =-1 ; +/* wait some time for edid is ready */ +msleep (200 ); } edid =drm_do_get_edid (connector, adv7511_get_edid_block, adv7511); --Best,
-xinliangQuoted 174 lines
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 connected HDMI-A 0x0 4 20 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 800x600 60 800 840 968 1056 600 601 605 628 flags: phsync, pvsync; type: driver 800x600 56 800 824 896 1024 600 601 603 625 flags: phsync, pvsync; type: driver 848x480 60 848 864 976 1088 480 486 494 517 flags: phsync, pvsync; type: driver 640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 146 lines · Carlos Palminha
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha# modetest -M drm-arcpgu -c Connectors: id encoder status type size (mm) modes encoders 21 0 disconnected HDMI-A 0x0 0 20 props: 1 EDID: flags: immutable blob blobs:value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0#
Quoted 121 lines · Xinliang Liu
Quoted 43 lines · Carlos Palminha
I'm also getting a message from DRM saying can't find any crtc or sizes...i'm really missing something here.
:(-- log --
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
-- log ---Any help?
Regards,
C.PalminhaQuoted 10 lines · Carlos Palminha
Hi Xinliang,
My
get_modesseems to be implemented as the rcar driver... Probably still missing some init step?Regards,
C.Palminhastatic int arcpgu_drm_connector_get_modes(struct
drm_connector*connector)
Quoted 12 lines
{
structdrm_encoder_slave*slave;
const structdrm_encoder_slave_funcs*sfuncs;
structarcpgu_drm_connector* con >>>>>>>container_of(connector, struct arcpgu_drm_connector, connector);slave =
con->encoder_slave;
if(slave = NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n"); return 0;
}Quoted 11 lines
Quoted 6 lines
sfuncs =
slave->slave_funcs;if(sfuncs->get_modes = NULL){
return 0;
}return sfuncs->
get_modes(&slave->base,connector);Quoted 2 lines
}
so, this will call adv7511 driver's
get_modescall back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -MDRM_DRIVER_NAME-cQuoted 53 lines
Quoted 5 lines · Xinliang Liu
Quoted 4 lines
On 31 December 2015 at 02:46, Carlos Palminha <[email protected] <mailto:[email protected]>>
Quoted 46 lines · wrote:
Quoted 46 lines
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses an i2c encoder (adv7511), following the basic steps suggested by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4After initiliazing all kms, crtc, encoder, i2c, connector functions and structures i'm calling
drm_fbdev_cma_initto create a fbdev.When booting i'm getting an error message saying "No connectors reported connected with modes", but the driver init is ok and i can find the
/dev/dri/*and/dev/fb0devices.Any clue what i might be missing during the driver load?
I think you should check on the '
get_modes' call back of adv7511 driver. (Or, if possible show us the code.)Best,
-xinliangThanks...
Regards,
C.Palminha--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes [drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48 drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0 --- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
Hi,
Quoted 2 lines · Carlos Palminha
i just found that its blocking waiting for
console_lock...
@vineet, alexey: i think thatconsole_lockis architecture dependent right? Do you know any issue withconsole_lockfor ARC?
Once console_lock is acquired, you will not see any further prints whilst it is held. Likely your driver is hanging/crashing whilst holding console_lock, which you don't see. See the patch just sent to the list to document how to debug issues which happen under console_lock.
Cheers,
Daniel
Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
In reply to Carlos PalminhaHi Carlos,
Quoted 5 lines · Carlos Palminha
hi...
i just found that its blocking waiting for
console_lock...
@vineet, alexey: i think thatconsole_lockis architecture dependent right? Do you know any issue withconsole_lockfor ARC?
I'm not really sure "console_lock" has something to do with ARC architecture. At least "git grep bconsole_lock" doesn't find anything in "arch/arc".
So I'd assume this is a generic thing.
-Alexey
Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
Quoted 5 lines · Alexey Brodkin
Hi Carlos,
Quoted 2 lines · Carlos Palminha
hi...
Quoted 9 lines
Quoted 3 lines
i just found that its blocking waiting for
console_lock...
@vineet, alexey: i think thatconsole_lockis architecture dependent right? Do you know any issue withconsole_lockfor ARC?I'm not really sure "
console_lock" has something to do with ARC architecture. At least "git grepbconsole_lock" doesn't find anything in "arch/arc".So I'd assume this is a generic thing.
it is a generic thing.. all arch's are afflicted by console_lock..
BR,
-R
Quoted 7 lines · Carlos Palminha
i made some progress in identifying the issue...
When my driver callsdrm_fb_helper_initial_configit seems DRM blocks waiting forregister_framebufferto return. The sequence isdrm_fb_helper_initial_config->drm_fb_helper_single_fb_probe->register_framebuffer.Its strange because
register_framebufferfunction is just a mutex arounddo_register_framebuffer.Any clue?!
Ah, the curse of console_lock. drm_fb_helper_initial_config also does the initial modeset if you have fbcon enabled. But because of locking stupidity we must do _all_ that code (which means pretty much your entire driver) under the console_lock, which means no log output until console_unlock. Not even on serial port.
https://patchwork.freedesktop.org/patch/57951/ is the usual hack to use to get rid of console_lock while booting, so that you can see where your driver crashes. I guess we should explain this in the kerneldoc ...
-Daniel
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Hey,
Quoted 16 lines · Daniel Vetter
Quoted 7 lines · Carlos Palminha
i made some progress in identifying the issue...
When my driver callsdrm_fb_helper_initial_configit seems DRM blocks waiting forregister_framebufferto return. The sequence isdrm_fb_helper_initial_config->drm_fb_helper_single_fb_probe->register_framebuffer.Its strange because
register_framebufferfunction is just a mutex arounddo_register_framebuffer.Any clue?!
Ah, the curse of
console_lock.drm_fb_helper_initial_configalso does the initial modeset if you have fbcon enabled. But because of locking stupidity we must do _all_ that code (which means pretty much your entire driver) under theconsole_lock, which means no log output untilconsole_unlock. Not even on serial port.
Quoted 4 lines
https://patchwork.freedesktop.org/patch/57951/ is the usual hack to use to get rid of
console_lockwhile booting, so that you can see where your driver crashes. I guess we should explain this in the kerneldoc ...
Didn't spot this at the time, but that should probably quash the WARN_ON_CONSOLE_UNLOCKED warnings as well ...
Cheers,
Dan