* Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2015-12-30 18:46 Carlos Palminha
2015-12-30 18:53 ` Carlos Palminha
2015-12-31 2:19 ` Xinliang Liu
0 siblings, 2 replies; 33+ messages in thread
From: Carlos Palminha @ 2015-12-30 18:46 UTC (permalink / raw)
To: linux-fbdev
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 ---
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2015-12-30 18:53 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2015-12-30 18:53 UTC (permalink / raw)
To: laurent.pinchart, dri-devel, linux-fbdev; +Cc: tomi.valkeinen, 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
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 ---
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2015-12-30 18:53 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2015-12-30 18:53 UTC (permalink / raw)
To: laurent.pinchart, dri-devel, linux-fbdev; +Cc: tomi.valkeinen, 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
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 ---
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2015-12-30 18:46 Whats missing in my new FB DRM driver... "No connectors reported connected with modes"? Carlos Palminha
2015-12-30 18:53 ` Carlos Palminha
@ 2015-12-31 2:19 ` Xinliang Liu
2016-01-18 14:32 ` Carlos Palminha
1 sibling, 1 reply; 33+ messages in thread
From: Xinliang Liu @ 2015-12-31 2:19 UTC (permalink / raw)
To: Carlos Palminha; +Cc: linux-fbdev, tomi.valkeinen, laurent.pinchart, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1533 bytes --]
On 31 December 2015 at 02:46, Carlos Palminha <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
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #1.2: Type: text/html, Size: 2837 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2015-12-31 2:19 ` Xinliang Liu
@ 2016-01-18 14:32 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-18 14:32 UTC (permalink / raw)
To: Xinliang Liu; +Cc: linux-fbdev, tomi.valkeinen, laurent.pinchart, 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);
}
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
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-18 14:32 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-18 14:32 UTC (permalink / raw)
To: Xinliang Liu; +Cc: linux-fbdev, tomi.valkeinen, laurent.pinchart, 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);
}
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
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-18 14:32 ` Carlos Palminha
@ 2016-01-18 14:45 ` Carlos Palminha
-1 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-18 14:45 UTC (permalink / raw)
To: Xinliang Liu, dri-devel; +Cc: linux-fbdev, tomi.valkeinen, laurent.pinchart
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);
> }
>
> 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
>>
>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-18 14:45 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-18 14:45 UTC (permalink / raw)
To: Xinliang Liu, dri-devel; +Cc: linux-fbdev, tomi.valkeinen, laurent.pinchart
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);
> }
>
> 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
>>
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-18 14:45 ` Carlos Palminha
(?)
@ 2016-01-19 3:38 ` Xinliang Liu
2016-01-19 16:03 ` Carlos Palminha
-1 siblings, 1 reply; 33+ messages in thread
From: Xinliang Liu @ 2016-01-19 3:38 UTC (permalink / raw)
To: Carlos Palminha; +Cc: linux-fbdev, tomi.valkeinen, laurent.pinchart, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 3678 bytes --]
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
> >>
> >>
>
[-- Attachment #1.2: Type: text/html, Size: 6261 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-19 3:38 ` Xinliang Liu
@ 2016-01-19 16:03 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-19 16:03 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, 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
#
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
>>>>
>>>>
>>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-19 16:03 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-19 16:03 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, 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
#
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
>>>>
>>>>
>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-19 16:03 ` Carlos Palminha
@ 2016-01-19 16:52 ` Carlos Palminha
-1 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-19 16:52 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, dri-devel
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:
>> 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
>>>>>
>>>>>
>>>
>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-19 16:52 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-19 16:52 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, dri-devel
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:
>> 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
>>>>>
>>>>>
>>>
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-19 16:52 ` Carlos Palminha
@ 2016-01-20 1:24 ` Xinliang Liu
-1 siblings, 0 replies; 33+ messages in thread
From: Xinliang Liu @ 2016-01-20 1:24 UTC (permalink / raw)
To: Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, dri-devel
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
>>>>>>
>>>>>>
>>>>
>>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-20 1:24 ` Xinliang Liu
0 siblings, 0 replies; 33+ messages in thread
From: Xinliang Liu @ 2016-01-20 1:24 UTC (permalink / raw)
To: Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, dri-devel
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
>>>>>>
>>>>>>
>>>>
>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-20 1:24 ` Xinliang Liu
@ 2016-01-21 18:09 ` Carlos Palminha
-1 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-21 18:09 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, dri-devel
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
>>>>>>>
>>>>>>>
>>>>>
>>>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-21 18:09 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-21 18:09 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha
Cc: linux-fbdev, tomi.valkeinen, Alexey Brodkin, laurent.pinchart, dri-devel
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
>>>>>>>
>>>>>>>
>>>>>
>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
2016-01-21 18:09 ` Carlos Palminha
(?)
@ 2016-01-21 18:30 ` Carlos Palminha
-1 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-21 18:30 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha, Alexey Brodkin, Vineet Gupta
Cc: linux-snps-arc, linux-fbdev, tomi.valkeinen, laurent.pinchart, dri-devel
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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-21 18:30 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-21 18:30 UTC (permalink / raw)
To: linux-snps-arc
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 at 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 at synopsys.com <mailto:CARLOS.PALMINHA at 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 at vger.kernel.org
>>>>>>>> <mailto:majordomo at vger.kernel.org>
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-21 18:30 ` Carlos Palminha
0 siblings, 0 replies; 33+ messages in thread
From: Carlos Palminha @ 2016-01-21 18:30 UTC (permalink / raw)
To: Xinliang Liu, Carlos Palminha, Alexey Brodkin, Vineet Gupta
Cc: linux-snps-arc, linux-fbdev, tomi.valkeinen, laurent.pinchart, dri-devel
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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-21 18:09 ` Carlos Palminha
@ 2016-01-22 7:41 ` Daniel Vetter
-1 siblings, 0 replies; 33+ messages in thread
From: Daniel Vetter @ 2016-01-22 7:41 UTC (permalink / raw)
To: Carlos Palminha
Cc: Linux Fbdev development list, Alexey Brodkin, dri-devel,
Tomi Valkeinen, Laurent Pinchart
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 Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-22 7:41 ` Daniel Vetter
0 siblings, 0 replies; 33+ messages in thread
From: Daniel Vetter @ 2016-01-22 7:41 UTC (permalink / raw)
To: Carlos Palminha
Cc: Linux Fbdev development list, Alexey Brodkin, dri-devel,
Tomi Valkeinen, Laurent Pinchart
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 Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
2016-01-21 18:30 ` Carlos Palminha
(?)
@ 2016-01-22 8:32 ` Daniel Stone
-1 siblings, 0 replies; 33+ messages in thread
From: Daniel Stone @ 2016-01-22 8:32 UTC (permalink / raw)
To: Carlos Palminha
Cc: linux-fbdev, Vineet Gupta, Alexey Brodkin, dri-devel,
Tomi Valkeinen, Laurent Pinchart, linux-snps-arc
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-22 8:32 ` Daniel Stone
0 siblings, 0 replies; 33+ messages in thread
From: Daniel Stone @ 2016-01-22 8:32 UTC (permalink / raw)
To: linux-snps-arc
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-22 8:32 ` Daniel Stone
0 siblings, 0 replies; 33+ messages in thread
From: Daniel Stone @ 2016-01-22 8:32 UTC (permalink / raw)
To: Carlos Palminha
Cc: linux-fbdev, Vineet Gupta, Alexey Brodkin, dri-devel,
Tomi Valkeinen, Laurent Pinchart, linux-snps-arc
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
2016-01-22 7:41 ` Daniel Vetter
@ 2016-01-22 8:34 ` Daniel Stone
-1 siblings, 0 replies; 33+ messages in thread
From: Daniel Stone @ 2016-01-22 8:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Alexey Brodkin, Carlos Palminha,
dri-devel, Tomi Valkeinen, Laurent Pinchart
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
@ 2016-01-22 8:34 ` Daniel Stone
0 siblings, 0 replies; 33+ messages in thread
From: Daniel Stone @ 2016-01-22 8:34 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Alexey Brodkin, Carlos Palminha,
dri-devel, Tomi Valkeinen, Laurent Pinchart
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
2016-01-21 18:30 ` Carlos Palminha
(?)
@ 2016-01-28 14:20 ` Alexey Brodkin
-1 siblings, 0 replies; 33+ messages in thread
From: Alexey Brodkin @ 2016-01-28 14:20 UTC (permalink / raw)
To: Carlos Palminha
Cc: linux-fbdev, xinliang.liu, Vineet Gupta, dri-devel,
tomi.valkeinen, laurent.pinchart, linux-snps-arc
SGkgQ2FybG9zLA0KDQpPbiBUaHUsIDIwMTYtMDEtMjEgYXQgMTg6MzAgKzAwMDAsIENhcmxvcyBQ
YWxtaW5oYSB3cm90ZToNCj4gaGkuLi4NCj4gDQo+IGkganVzdCBmb3VuZCB0aGF0IGl0cyBibG9j
a2luZyB3YWl0aW5nIGZvciBjb25zb2xlX2xvY2suLi4NCj4gQHZpbmVldCwgYWxleGV5OiBpIHRo
aW5rIHRoYXQgY29uc29sZV9sb2NrIGlzIGFyY2hpdGVjdHVyZSBkZXBlbmRlbnQgcmlnaHQ/IERv
IHlvdSBrbm93IGFueSBpc3N1ZSB3aXRoIGNvbnNvbGVfbG9jaw0KPiBmb3IgQVJDPw0KDQpJJ20g
bm90IHJlYWxseSBzdXJlICJjb25zb2xlX2xvY2siIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBB
UkMgYXJjaGl0ZWN0dXJlLg0KQXQgbGVhc3QgImdpdCBncmVwIGJjb25zb2xlX2xvY2siIGRvZXNu
J3QgZmluZCBhbnl0aGluZyBpbiAiYXJjaC9hcmMiLg0KDQpTbyBJJ2QgYXNzdW1lIHRoaXMgaXMg
YSBnZW5lcmljIHRoaW5nLg0KDQotQWxleGV5
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-28 14:20 ` Alexey Brodkin
0 siblings, 0 replies; 33+ messages in thread
From: Alexey Brodkin @ 2016-01-28 14:20 UTC (permalink / raw)
To: linux-snps-arc
Hi Carlos,
On Thu, 2016-01-21@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-28 14:20 ` Alexey Brodkin
0 siblings, 0 replies; 33+ messages in thread
From: Alexey Brodkin @ 2016-01-28 14:20 UTC (permalink / raw)
To: Carlos Palminha
Cc: linux-fbdev, xinliang.liu, Vineet Gupta, dri-devel,
tomi.valkeinen, laurent.pinchart, linux-snps-arc
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
2016-01-28 14:20 ` Alexey Brodkin
(?)
@ 2016-01-28 15:42 ` Rob Clark
-1 siblings, 0 replies; 33+ messages in thread
From: Rob Clark @ 2016-01-28 15:42 UTC (permalink / raw)
To: Alexey Brodkin
Cc: linux-fbdev, Vineet Gupta, Carlos Palminha, dri-devel,
tomi.valkeinen, laurent.pinchart, linux-snps-arc
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-28 15:42 ` Rob Clark
0 siblings, 0 replies; 33+ messages in thread
From: Rob Clark @ 2016-01-28 15:42 UTC (permalink / raw)
To: linux-snps-arc
On Thu, Jan 28, 2016 at 9:20 AM, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hi Carlos,
>
> On Thu, 2016-01-21@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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return
@ 2016-01-28 15:42 ` Rob Clark
0 siblings, 0 replies; 33+ messages in thread
From: Rob Clark @ 2016-01-28 15:42 UTC (permalink / raw)
To: Alexey Brodkin
Cc: linux-fbdev, Vineet Gupta, Carlos Palminha, dri-devel,
tomi.valkeinen, laurent.pinchart, linux-snps-arc
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-01-28 15:42 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-30 18:46 Whats missing in my new FB DRM driver... "No connectors reported connected with modes"? Carlos Palminha
2015-12-30 18:53 ` Carlos Palminha
2015-12-30 18:53 ` Carlos Palminha
2015-12-31 2:19 ` Xinliang Liu
2016-01-18 14:32 ` Carlos Palminha
2016-01-18 14:32 ` Carlos Palminha
2016-01-18 14:45 ` Carlos Palminha
2016-01-18 14:45 ` Carlos Palminha
2016-01-19 3:38 ` Xinliang Liu
2016-01-19 16:03 ` Carlos Palminha
2016-01-19 16:03 ` Carlos Palminha
2016-01-19 16:52 ` Carlos Palminha
2016-01-19 16:52 ` Carlos Palminha
2016-01-20 1:24 ` Xinliang Liu
2016-01-20 1:24 ` Xinliang Liu
2016-01-21 18:09 ` Carlos Palminha
2016-01-21 18:09 ` Carlos Palminha
2016-01-21 18:30 ` Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return Carlos Palminha
2016-01-21 18:30 ` Carlos Palminha
2016-01-21 18:30 ` Carlos Palminha
2016-01-22 8:32 ` Daniel Stone
2016-01-22 8:32 ` Daniel Stone
2016-01-22 8:32 ` Daniel Stone
2016-01-28 14:20 ` Alexey Brodkin
2016-01-28 14:20 ` Alexey Brodkin
2016-01-28 14:20 ` Alexey Brodkin
2016-01-28 15:42 ` Rob Clark
2016-01-28 15:42 ` Rob Clark
2016-01-28 15:42 ` Rob Clark
2016-01-22 7:41 ` Whats missing in my new FB DRM driver... "No connectors reported connected with modes"? Daniel Vetter
2016-01-22 7:41 ` Daniel Vetter
2016-01-22 8:34 ` Daniel Stone
2016-01-22 8:34 ` Daniel Stone
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.