* 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: 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
* 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
* 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
* 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
* 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-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
* 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
* 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 (?) @ 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
* 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
* 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... "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... "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
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.