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

Message ID CAGd==04VMKUvb6hZkeNw3kAQt04y0d_Ry7oCtC8=2SWcfWG25A@mail.gmail.com
State New
Headers show

Commit Message

Xinliang Liu Jan. 20, 2016, 1:24 a.m. UTC
On 20 January 2016 at 00:52, Carlos Palminha
<CARLOS.PALMINHA@synopsys.com> 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:
--
--

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:
>> 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 <CARLOS.PALMINHA@synopsys.com>
>>> wrote:
>>>
>>>> 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:
>>>>> 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);
>>>>> }
>>>>>
>>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>>> On 31-12-2015 02:19, Xinliang Liu wrote:
>>>>>>
>>>>>>
>>>>>> On 31 December 2015 at 02:46, Carlos Palminha
>>>>>> <CARLOS.PALMINHA@synopsys.com <mailto:CARLOS.PALMINHA@synopsys.com>>
>>>> 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=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?
>>>>>>
>>>>>>
>>>>>> I think you should check on the 'get_modes' call back of adv7511
>>>>>> driver. (Or, if possible show us the code.)
>>>>>>
>>>>>> Best,
>>>>>> -xinliang
>>>>>>
>>>>>>
>>>>>>     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 ---
>>>>>>     --
>>>>>>     To unsubscribe from this list: send the line "unsubscribe
>>>>>>     linux-fbdev" in
>>>>>>     the body of a message to majordomo@vger.kernel.org
>>>>>>     <mailto:majordomo@vger.kernel.org>
>>>>>>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>
>>>

Comments

Carlos Palminha Jan. 21, 2016, 6:09 p.m. UTC | #1
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:
> On 20 January 2016 at 00:52, Carlos Palminha
> <CARLOS.PALMINHA@synopsys.com> 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:
>>> 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 <CARLOS.PALMINHA@synopsys.com>
>>>> wrote:
>>>>
>>>>> 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:
>>>>>> 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);
>>>>>> }
>>>>>>
>>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>>> On 31-12-2015 02:19, Xinliang Liu wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 31 December 2015 at 02:46, Carlos Palminha
>>>>>>> <CARLOS.PALMINHA@synopsys.com <mailto:CARLOS.PALMINHA@synopsys.com>>
>>>>> 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=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?
>>>>>>>
>>>>>>>
>>>>>>> I think you should check on the 'get_modes' call back of adv7511
>>>>>>> driver. (Or, if possible show us the code.)
>>>>>>>
>>>>>>> Best,
>>>>>>> -xinliang
>>>>>>>
>>>>>>>
>>>>>>>     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 ---
>>>>>>>     --
>>>>>>>     To unsubscribe from this list: send the line "unsubscribe
>>>>>>>     linux-fbdev" in
>>>>>>>     the body of a message to majordomo@vger.kernel.org
>>>>>>>     <mailto:majordomo@vger.kernel.org>
>>>>>>>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>>>
>>>>>
>>>>
Carlos Palminha Jan. 21, 2016, 6:30 p.m. UTC | #2
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:
>> On 20 January 2016 at 00:52, Carlos Palminha
>> <CARLOS.PALMINHA@synopsys.com> 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:
>>>> 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 <CARLOS.PALMINHA@synopsys.com>
>>>>> wrote:
>>>>>
>>>>>> 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:
>>>>>>> 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);
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> On 31-12-2015 02:19, Xinliang Liu wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 31 December 2015 at 02:46, Carlos Palminha
>>>>>>>> <CARLOS.PALMINHA@synopsys.com <mailto:CARLOS.PALMINHA@synopsys.com>>
>>>>>> 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=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?
>>>>>>>>
>>>>>>>>
>>>>>>>> I think you should check on the 'get_modes' call back of adv7511
>>>>>>>> driver. (Or, if possible show us the code.)
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> -xinliang
>>>>>>>>
>>>>>>>>
>>>>>>>>     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 ---
>>>>>>>>     --
>>>>>>>>     To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>     linux-fbdev" in
>>>>>>>>     the body of a message to majordomo@vger.kernel.org
>>>>>>>>     <mailto:majordomo@vger.kernel.org>
>>>>>>>>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
Daniel Vetter Jan. 22, 2016, 7:41 a.m. UTC | #3
On Thu, Jan 21, 2016 at 7:09 PM, Carlos Palminha
<CARLOS.PALMINHA@synopsys.com> 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 Stone Jan. 22, 2016, 8:32 a.m. UTC | #4
Hi,

On 21 January 2016 at 18:30, Carlos Palminha
<CARLOS.PALMINHA@synopsys.com> 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
Daniel Stone Jan. 22, 2016, 8:34 a.m. UTC | #5
Hey,

On 22 January 2016 at 07:41, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jan 21, 2016 at 7:09 PM, Carlos Palminha
> <CARLOS.PALMINHA@synopsys.com> 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 ...

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

Cheers,
Dan
Alexey Brodkin Jan. 28, 2016, 2:20 p.m. UTC | #6
Hi Carlos,

On Thu, 2016-01-21 at 18:30 +0000, Carlos Palminha wrote:
> 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.

-Alexey
Rob Clark Jan. 28, 2016, 3:42 p.m. UTC | #7
On Thu, Jan 28, 2016 at 9:20 AM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hi Carlos,
>
> On Thu, 2016-01-21 at 18:30 +0000, Carlos Palminha wrote:
>> 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

Patch
diff mbox

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