Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?

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

#

On 19-01-2016 03:38, Xinliang Liu wrote:

On 18 January 2016 at 22:45, Carlos Palminha [off-list ref]
wrote:

quoted

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


On 18-01-2016 14:32, Carlos Palminha wrote:

quoted

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)

quoted

{
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;

81 more quoted lines

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

#

On 19-01-2016 16:03, Carlos Palminha wrote:

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

#

On 19-01-2016 03:38, Xinliang Liu wrote:

quoted

On 18 January 2016 at 22:45, Carlos Palminha [off-list ref]
wrote:

quoted

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 ---

106 more quoted lines

On 20 January 2016 at 00:52, Carlos Palminha
[off-list ref] wrote:

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?

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:
--

--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c

@@ -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

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

#

On 19-01-2016 16:03, Carlos Palminha wrote:

quoted

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:

134 more quoted lines

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?!

On 20-01-2016 01:24, Xinliang Liu wrote:

167 more quoted lines

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?

On 21-01-2016 18:09, Carlos Palminha wrote:

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?!

On 20-01-2016 01:24, Xinliang Liu wrote:

quoted

On 20 January 2016 at 00:52, Carlos Palminha
[off-list ref] wrote:

quoted

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

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:
--

--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c

@@ -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,

176 more quoted lines

On Thu, Jan 21, 2016 at 7:09 PM, Carlos Palminha
[off-list ref] wrote:

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?!

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Hi,

On 21 January 2016 at 18:30, Carlos Palminha
[off-list ref] wrote:

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?

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

Hey,

On 22 January 2016 at 07:41, Daniel Vetter [off-list ref] wrote:

On Thu, Jan 21, 2016 at 7:09 PM, Carlos Palminha
[off-list ref] wrote:

quoted

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?!

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 ...

Didn't spot this at the time, but that should probably quash the
WARN_ON_CONSOLE_UNLOCKED warnings as well ...

Cheers,
Dan

SGkgQ2FybG9zLA0KDQpPbiBUaHUsIDIwMTYtMDEtMjEgYXQgMTg6MzAgKzAwMDAsIENhcmxvcyBQ
YWxtaW5oYSB3cm90ZToNCj4gaGkuLi4NCj4gDQo+IGkganVzdCBmb3VuZCB0aGF0IGl0cyBibG9j
a2luZyB3YWl0aW5nIGZvciBjb25zb2xlX2xvY2suLi4NCj4gQHZpbmVldCwgYWxleGV5OiBpIHRo
aW5rIHRoYXQgY29uc29sZV9sb2NrIGlzIGFyY2hpdGVjdHVyZSBkZXBlbmRlbnQgcmlnaHQ/IERv
IHlvdSBrbm93IGFueSBpc3N1ZSB3aXRoIGNvbnNvbGVfbG9jaw0KPiBmb3IgQVJDPw0KDQpJJ20g
bm90IHJlYWxseSBzdXJlICJjb25zb2xlX2xvY2siIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBB
UkMgYXJjaGl0ZWN0dXJlLg0KQXQgbGVhc3QgImdpdCBncmVwIGJjb25zb2xlX2xvY2siIGRvZXNu
J3QgZmluZCBhbnl0aGluZyBpbiAiYXJjaC9hcmMiLg0KDQpTbyBJJ2QgYXNzdW1lIHRoaXMgaXMg
YSBnZW5lcmljIHRoaW5nLg0KDQotQWxleGV5

On Thu, Jan 28, 2016 at 9:20 AM, Alexey Brodkin
[off-list ref] wrote:

Hi Carlos,

On Thu, 2016-01-21 at 18:30 +0000, Carlos Palminha wrote:

quoted

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?

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.

it is a generic thing..  all arch's are afflicted by console_lock..

BR,
-R