drm: imx: callback after probe deferral not working
Hi Akshay, On 9 February 2016 at 22:25, Akshay Bhat wrote: > On 02/09/2016 04:28 PM, Daniel Stone wrote: >> On 1 February 2016 at 19:02, Akshay Bhat wrote: >>> On 02/01/2016 07:11 AM, Liviu Dudau wrote: On Fri, Jan 29, 2016 at 05:12:28PM -0500, Akshay Bhat wrote: > On 01/28/2016 05:29 PM, Rob Clark wrote: > Also from the original log you can see that there are a lot of modules > that > are loaded after the drm driver does a probe defer, yet there is no > entries > in the bootlog for the drm driver being re-probed. In the next-20151202 > kernel log you can see it being re-probed. This points to the drm probe > deferral being broken. I think your problem is similar to what Tixy has found when testing HDLCD, which also uses the components API. He has posted a patch here: http://www.spinics.net/lists/arm-kernel/msg477090.html Russell has added it to his branch, seems to be available in linux-next as commit 57480484f9f7631738ef2. >>> >>> I re-tested with next-20160201 which contains the above patch and still >>> see >>> the issue where the re-probe does not work. >> >> >> Could you please try with this patch? The component system was broken >> (with the same result) in a slightly different way by the same >> patchset Lixy had to fix; this also kept Rockchip DRM from loading. >> >> http://lkml.iu.edu/hypermail/linux/kernel/1602.1/00832.html > > Your patch fixes the above re-probe issue. Thank you very much for reaching > out with the patch, appreciate your help :) Russell, looks like there's further component breakage when you defer inside a bind; IMX and Rockchip are both broken. See the patch I sent yesterday for this. Cheers, Daniel
drm: imx: callback after probe deferral not working
Hi Akshay, On 1 February 2016 at 19:02, Akshay Bhat wrote: > On 02/01/2016 07:11 AM, Liviu Dudau wrote: >> On Fri, Jan 29, 2016 at 05:12:28PM -0500, Akshay Bhat wrote: >>> On 01/28/2016 05:29 PM, Rob Clark wrote: >>> Also from the original log you can see that there are a lot of modules >>> that >>> are loaded after the drm driver does a probe defer, yet there is no >>> entries >>> in the bootlog for the drm driver being re-probed. In the next-20151202 >>> kernel log you can see it being re-probed. This points to the drm probe >>> deferral being broken. >> >> I think your problem is similar to what Tixy has found when testing HDLCD, >> which also uses the components API. He has posted a patch here: >> >> http://www.spinics.net/lists/arm-kernel/msg477090.html >> >> Russell has added it to his branch, seems to be available in linux-next >> as commit 57480484f9f7631738ef2. > > Liviu, > > I re-tested with next-20160201 which contains the above patch and still see > the issue where the re-probe does not work. Could you please try with this patch? The component system was broken (with the same result) in a slightly different way by the same patchset Lixy had to fix; this also kept Rockchip DRM from loading. http://lkml.iu.edu/hypermail/linux/kernel/1602.1/00832.html Cheers, Daniel
drm: imx: callback after probe deferral not working
Hi Daniel, On 02/09/2016 04:28 PM, Daniel Stone wrote: > Hi Akshay, > > On 1 February 2016 at 19:02, Akshay Bhat wrote: >> On 02/01/2016 07:11 AM, Liviu Dudau wrote: >>> On Fri, Jan 29, 2016 at 05:12:28PM -0500, Akshay Bhat wrote: On 01/28/2016 05:29 PM, Rob Clark wrote: Also from the original log you can see that there are a lot of modules that are loaded after the drm driver does a probe defer, yet there is no entries in the bootlog for the drm driver being re-probed. In the next-20151202 kernel log you can see it being re-probed. This points to the drm probe deferral being broken. >>> >>> I think your problem is similar to what Tixy has found when testing HDLCD, >>> which also uses the components API. He has posted a patch here: >>> >>> http://www.spinics.net/lists/arm-kernel/msg477090.html >>> >>> Russell has added it to his branch, seems to be available in linux-next >>> as commit 57480484f9f7631738ef2. >> >> Liviu, >> >> I re-tested with next-20160201 which contains the above patch and still see >> the issue where the re-probe does not work. > > Could you please try with this patch? The component system was broken > (with the same result) in a slightly different way by the same > patchset Lixy had to fix; this also kept Rockchip DRM from loading. > > http://lkml.iu.edu/hypermail/linux/kernel/1602.1/00832.html > > Cheers, > Daniel > Your patch fixes the above re-probe issue. Thank you very much for reaching out with the patch, appreciate your help :) Thanks, Akshay
drm: imx: callback after probe deferral not working
On 02/01/2016 07:11 AM, Liviu Dudau wrote: > On Fri, Jan 29, 2016 at 05:12:28PM -0500, Akshay Bhat wrote: >> >> >> On 01/28/2016 05:29 PM, Rob Clark wrote: >>> can't really say if that is the issue in this case, but these are the >>> symptoms you'd see if the kernel was built without some driver that >>> imx-drm depends on[1]. The kernel will only try to reprobe a driver >>> if some other driver has loaded since it last deferred (otherwise, it >>> would be pointless, you'd just -EPROBE_DEFER again). >>> >>> [1] which is a really annoying thing about devicetree.. there's no >>> good way to figure out which drivers need to be enabled in kernel >>> config.. >>> >>> BR, >>> -R >>> >> >> I agree a missing driver would show the symptoms I am seeing. However I have >> verified this is not the case by moving i2c above gpu in the makefile and >> keeping everything else the same. This results in the i2c mux driver init >> (pca9547) being called before the drm init and everything works fine in that >> case (indicates no missing driver). >> >> Also from the original log you can see that there are a lot of modules that >> are loaded after the drm driver does a probe defer, yet there is no entries >> in the bootlog for the drm driver being re-probed. In the next-20151202 >> kernel log you can see it being re-probed. This points to the drm probe >> deferral being broken. >> >> Thanks for your input, any other ideas are welcome. > > I think your problem is similar to what Tixy has found when testing HDLCD, > which also uses the components API. He has posted a patch here: > > http://www.spinics.net/lists/arm-kernel/msg477090.html > > Russell has added it to his branch, seems to be available in linux-next > as commit 57480484f9f7631738ef2. > > Best regards, > Liviu > Liviu, I re-tested with next-20160201 which contains the above patch and still see the issue where the re-probe does not work. Thanks, Akshay dmesg | grep -i 'drm \| pca' [1.266320] [drm] Initialized drm 1.1.0 20060810 [1.437590] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops) [1.445237] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops) [1.452856] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops ipu_crtc_ops) [1.460453] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops ipu_crtc_ops) [1.468188] imx-drm display-subsystem: failed to bind 12.hdmi (ops dw_hdmi_imx_ops): -517 [1.479742] imx-drm display-subsystem: master bind failed: -517 [2.169468] pca954x 0-0070: registered 8 multiplexed busses for I2C mux pca9547 [2.223390] pca954x 1-0070: registered 8 multiplexed busses for I2C mux pca9547 dmesg |head -n2 [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.5.0-rc1-next-20160201-7-g3c1226b (nodeax at timesysab) (gcc version 4.8.5 (Timesys 20150713) ) #168 SMP Mon Feb 1 13:12:04 EST 2016
drm: imx: callback after probe deferral not working
On Fri, Jan 29, 2016 at 05:12:28PM -0500, Akshay Bhat wrote: > > > On 01/28/2016 05:29 PM, Rob Clark wrote: > >can't really say if that is the issue in this case, but these are the > >symptoms you'd see if the kernel was built without some driver that > >imx-drm depends on[1]. The kernel will only try to reprobe a driver > >if some other driver has loaded since it last deferred (otherwise, it > >would be pointless, you'd just -EPROBE_DEFER again). > > > >[1] which is a really annoying thing about devicetree.. there's no > >good way to figure out which drivers need to be enabled in kernel > >config.. > > > >BR, > >-R > > > > I agree a missing driver would show the symptoms I am seeing. However I have > verified this is not the case by moving i2c above gpu in the makefile and > keeping everything else the same. This results in the i2c mux driver init > (pca9547) being called before the drm init and everything works fine in that > case (indicates no missing driver). > > Also from the original log you can see that there are a lot of modules that > are loaded after the drm driver does a probe defer, yet there is no entries > in the bootlog for the drm driver being re-probed. In the next-20151202 > kernel log you can see it being re-probed. This points to the drm probe > deferral being broken. > > Thanks for your input, any other ideas are welcome. I think your problem is similar to what Tixy has found when testing HDLCD, which also uses the components API. He has posted a patch here: http://www.spinics.net/lists/arm-kernel/msg477090.html Russell has added it to his branch, seems to be available in linux-next as commit 57480484f9f7631738ef2. Best regards, Liviu > > Log with i2c init before drm (Makefile hack to avoid probe deferral): > dmesg | grep -i 'drm \| pca' > [1.325962] pca954x 0-0070: registered 8 multiplexed busses for I2C mux > pca9547 > [1.379740] pca954x 1-0070: registered 8 multiplexed busses for I2C mux > pca9547 > [1.387465] [drm] Initialized drm 1.1.0 20060810 > [1.578625] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops > ipu_crtc_ops) > [1.586272] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops > ipu_crtc_ops) > [1.593905] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops > ipu_crtc_ops) > [1.601509] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops > ipu_crtc_ops) > [1.618241] imx-drm display-subsystem: bound 12.hdmi (ops > dw_hdmi_imx_ops) > [1.634754] imx-drm display-subsystem: bound > 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops) > [1.902172] imx-drm display-subsystem: fb0: frame buffer device > [1.929283] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1 > > > >On Thu, Jan 28, 2016 at 2:56 PM, Akshay Bhat > >wrote: > >>Hi, > >> > >>There appears to be a bug in kernel where after a probe deferral by the drm > >>driver, the deferred drm function is never called again at a later point. > >> > >>I have a iMX6 based board where there is pca9547 i2c mux between the display > >>and the mx6 processor. The drm driver tries to get EDID information but the > >>I2C mux pca9547 driver is not yet called, so drm driver does a probe > >>deferral as expected. However the drm function is never called again after > >>the pca9547 driver completes initialization because of which the display > >>remains blank. Things used to work with next-20151202 and I saw it stop > >>working sometime around next-20151223 onwards. > >> > >>If I comment the "ddc-i2c-bus" entry in device tree, then the display works > >>in next-20160128 since the probe deferral does not happen. > >> > >>Has anyone else seen this issue? > >> > >>Logs provided below. > >> > >>Thanks, > >>Akshay > >> > >>Log where things work in next-20151202: > >>dmesg | grep -i 'drm \| pca' > >>[1.597271] [drm] Initialized drm 1.1.0 20060810 > >>[1.638434] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops > >>ipu_crtc_ops) > >>[1.646013] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops > >>ipu_crtc_ops) > >>[1.653669] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops > >>ipu_crtc_ops) > >>[1.661276] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops > >>ipu_crtc_ops) > >>[1.669067] imx-drm display-subsystem: failed to bind 12.hdmi (ops > >>dw_hdmi_imx_ops): -517 > >>[1.680883] imx-drm display-subsystem: master bind failed: -517 > >>[2.460839] pca954x 0-0070: registered 8 multiplexed busses for I2C mux > >>pca9547 > >>[2.515638] pca954x 1-0070: registered 8 multiplexed busses for I2C mux > >>pca9547 > >>[3.241065] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops > >>ipu_crtc_ops) > >>[3.248565] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops > >>ipu_crtc_ops) > >>[3.256053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops > >>ipu_crtc_ops) > >>[3.263566] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops > >>ipu_crtc_ops) > >>[3.283249] imx-drm display-subsystem: boun
drm: imx: callback after probe deferral not working
On Thu, Jan 28, 2016 at 4:29 PM, Rob Clark wrote: > can't really say if that is the issue in this case, but these are the > symptoms you'd see if the kernel was built without some driver that > imx-drm depends on[1]. The kernel will only try to reprobe a driver > if some other driver has loaded since it last deferred (otherwise, it > would be pointless, you'd just -EPROBE_DEFER again). > > [1] which is a really annoying thing about devicetree.. there's no > good way to figure out which drivers need to be enabled in kernel > config.. The same problem existed w/o DT. It could be solved with board/platform kconfigs to turn on all dependencies, but then we'd be back to having board files to some extent. IIRC, Geert U has a script that generates the config entries from dts files. Rob
drm: imx: callback after probe deferral not working
On 01/28/2016 05:29 PM, Rob Clark wrote: > can't really say if that is the issue in this case, but these are the > symptoms you'd see if the kernel was built without some driver that > imx-drm depends on[1]. The kernel will only try to reprobe a driver > if some other driver has loaded since it last deferred (otherwise, it > would be pointless, you'd just -EPROBE_DEFER again). > > [1] which is a really annoying thing about devicetree.. there's no > good way to figure out which drivers need to be enabled in kernel > config.. > > BR, > -R > I agree a missing driver would show the symptoms I am seeing. However I have verified this is not the case by moving i2c above gpu in the makefile and keeping everything else the same. This results in the i2c mux driver init (pca9547) being called before the drm init and everything works fine in that case (indicates no missing driver). Also from the original log you can see that there are a lot of modules that are loaded after the drm driver does a probe defer, yet there is no entries in the bootlog for the drm driver being re-probed. In the next-20151202 kernel log you can see it being re-probed. This points to the drm probe deferral being broken. Thanks for your input, any other ideas are welcome. Log with i2c init before drm (Makefile hack to avoid probe deferral): dmesg | grep -i 'drm \| pca' [1.325962] pca954x 0-0070: registered 8 multiplexed busses for I2C mux pca9547 [1.379740] pca954x 1-0070: registered 8 multiplexed busses for I2C mux pca9547 [1.387465] [drm] Initialized drm 1.1.0 20060810 [1.578625] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops) [1.586272] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops) [1.593905] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops ipu_crtc_ops) [1.601509] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops ipu_crtc_ops) [1.618241] imx-drm display-subsystem: bound 12.hdmi (ops dw_hdmi_imx_ops) [1.634754] imx-drm display-subsystem: bound 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops) [1.902172] imx-drm display-subsystem: fb0: frame buffer device [1.929283] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1 > On Thu, Jan 28, 2016 at 2:56 PM, Akshay Bhat > wrote: >> Hi, >> >> There appears to be a bug in kernel where after a probe deferral by the drm >> driver, the deferred drm function is never called again at a later point. >> >> I have a iMX6 based board where there is pca9547 i2c mux between the display >> and the mx6 processor. The drm driver tries to get EDID information but the >> I2C mux pca9547 driver is not yet called, so drm driver does a probe >> deferral as expected. However the drm function is never called again after >> the pca9547 driver completes initialization because of which the display >> remains blank. Things used to work with next-20151202 and I saw it stop >> working sometime around next-20151223 onwards. >> >> If I comment the "ddc-i2c-bus" entry in device tree, then the display works >> in next-20160128 since the probe deferral does not happen. >> >> Has anyone else seen this issue? >> >> Logs provided below. >> >> Thanks, >> Akshay >> >> Log where things work in next-20151202: >> dmesg | grep -i 'drm \| pca' >> [1.597271] [drm] Initialized drm 1.1.0 20060810 >> [1.638434] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops >> ipu_crtc_ops) >> [1.646013] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops >> ipu_crtc_ops) >> [1.653669] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops >> ipu_crtc_ops) >> [1.661276] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops >> ipu_crtc_ops) >> [1.669067] imx-drm display-subsystem: failed to bind 12.hdmi (ops >> dw_hdmi_imx_ops): -517 >> [1.680883] imx-drm display-subsystem: master bind failed: -517 >> [2.460839] pca954x 0-0070: registered 8 multiplexed busses for I2C mux >> pca9547 >> [2.515638] pca954x 1-0070: registered 8 multiplexed busses for I2C mux >> pca9547 >> [3.241065] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops >> ipu_crtc_ops) >> [3.248565] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops >> ipu_crtc_ops) >> [3.256053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops >> ipu_crtc_ops) >> [3.263566] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops >> ipu_crtc_ops) >> [3.283249] imx-drm display-subsystem: bound 12.hdmi (ops >> dw_hdmi_imx_ops) >> [3.299943] imx-drm display-subsystem: bound >> 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops) >> [3.547620] imx-drm display-subsystem: fb0: frame buffer device >> [3.577445] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1 >> >> Log where things do not work in next-20160128: >> dmesg | grep -i 'drm \| pca' >> [1.265837] [drm] Initialized drm 1.1.0 20060810 >> [1.458511] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops >> ipu_crtc_ops) >> [1.4
drm: imx: callback after probe deferral not working
can't really say if that is the issue in this case, but these are the symptoms you'd see if the kernel was built without some driver that imx-drm depends on[1]. The kernel will only try to reprobe a driver if some other driver has loaded since it last deferred (otherwise, it would be pointless, you'd just -EPROBE_DEFER again). [1] which is a really annoying thing about devicetree.. there's no good way to figure out which drivers need to be enabled in kernel config.. BR, -R On Thu, Jan 28, 2016 at 2:56 PM, Akshay Bhat wrote: > Hi, > > There appears to be a bug in kernel where after a probe deferral by the drm > driver, the deferred drm function is never called again at a later point. > > I have a iMX6 based board where there is pca9547 i2c mux between the display > and the mx6 processor. The drm driver tries to get EDID information but the > I2C mux pca9547 driver is not yet called, so drm driver does a probe > deferral as expected. However the drm function is never called again after > the pca9547 driver completes initialization because of which the display > remains blank. Things used to work with next-20151202 and I saw it stop > working sometime around next-20151223 onwards. > > If I comment the "ddc-i2c-bus" entry in device tree, then the display works > in next-20160128 since the probe deferral does not happen. > > Has anyone else seen this issue? > > Logs provided below. > > Thanks, > Akshay > > Log where things work in next-20151202: > dmesg | grep -i 'drm \| pca' > [1.597271] [drm] Initialized drm 1.1.0 20060810 > [1.638434] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops > ipu_crtc_ops) > [1.646013] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops > ipu_crtc_ops) > [1.653669] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops > ipu_crtc_ops) > [1.661276] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops > ipu_crtc_ops) > [1.669067] imx-drm display-subsystem: failed to bind 12.hdmi (ops > dw_hdmi_imx_ops): -517 > [1.680883] imx-drm display-subsystem: master bind failed: -517 > [2.460839] pca954x 0-0070: registered 8 multiplexed busses for I2C mux > pca9547 > [2.515638] pca954x 1-0070: registered 8 multiplexed busses for I2C mux > pca9547 > [3.241065] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops > ipu_crtc_ops) > [3.248565] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops > ipu_crtc_ops) > [3.256053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops > ipu_crtc_ops) > [3.263566] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops > ipu_crtc_ops) > [3.283249] imx-drm display-subsystem: bound 12.hdmi (ops > dw_hdmi_imx_ops) > [3.299943] imx-drm display-subsystem: bound > 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops) > [3.547620] imx-drm display-subsystem: fb0: frame buffer device > [3.577445] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1 > > Log where things do not work in next-20160128: > dmesg | grep -i 'drm \| pca' > [1.265837] [drm] Initialized drm 1.1.0 20060810 > [1.458511] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops > ipu_crtc_ops) > [1.466156] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops > ipu_crtc_ops) > [1.473766] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops > ipu_crtc_ops) > [1.481389] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops > ipu_crtc_ops) > [1.489201] imx-drm display-subsystem: failed to bind 12.hdmi (ops > dw_hdmi_imx_ops): -517 > [1.500631] imx-drm display-subsystem: master bind failed: -517 > [2.188536] pca954x 0-0070: registered 8 multiplexed busses for I2C mux > pca9547 > [2.242492] pca954x 1-0070: registered 8 multiplexed busses for I2C mux > pca9547 > > Complete log with next-20160128 kernel: > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.5.0-rc1-next-20160128-7-g0d6335e > (nodeax at timesysab) (gcc version 4.8.5 (Timesys 20150713) ) #159 SMP Thu Jan > 28 14:02:00 EST 2016 > [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), > cr=10c5387d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] Machine model: General Electric B850v3 > [0.00] cma: Reserved 128 MiB at 0x8800 > [0.00] Memory policy: Data cache writealloc > [0.00] On node 0 totalpages: 524288 > [0.00] free_area_init_node: node 0, pgdat 80c7e040, node_mem_map > eeff8000 > [0.00] Normal zone: 3584 pages used for memmap > [0.00] Normal zone: 0 pages reserved > [0.00] Normal zone: 458752 pages, LIFO batch:31 > [0.00] HighMem zone: 65536 pages, LIFO batch:15 > [0.00] PERCPU: Embedded 13 pages/cpu @eefa2000 s23296 r8192 d21760 > u53248 > [0.00] pcpu-alloc: s23296 r8192 d21760 u53248 alloc=13*4096 > [0.00] pcpu-alloc: [0] 0 [0] 1 > [0.00] Built 1 zonelists in Zone order, mobility grouping on
drm: imx: callback after probe deferral not working
Hi, There appears to be a bug in kernel where after a probe deferral by the drm driver, the deferred drm function is never called again at a later point. I have a iMX6 based board where there is pca9547 i2c mux between the display and the mx6 processor. The drm driver tries to get EDID information but the I2C mux pca9547 driver is not yet called, so drm driver does a probe deferral as expected. However the drm function is never called again after the pca9547 driver completes initialization because of which the display remains blank. Things used to work with next-20151202 and I saw it stop working sometime around next-20151223 onwards. If I comment the "ddc-i2c-bus" entry in device tree, then the display works in next-20160128 since the probe deferral does not happen. Has anyone else seen this issue? Logs provided below. Thanks, Akshay Log where things work in next-20151202: dmesg | grep -i 'drm \| pca' [1.597271] [drm] Initialized drm 1.1.0 20060810 [1.638434] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) [1.646013] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) [1.653669] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) [1.661276] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) [1.669067] imx-drm display-subsystem: failed to bind 12.hdmi (ops dw_hdmi_imx_ops): -517 [1.680883] imx-drm display-subsystem: master bind failed: -517 [2.460839] pca954x 0-0070: registered 8 multiplexed busses for I2C mux pca9547 [2.515638] pca954x 1-0070: registered 8 multiplexed busses for I2C mux pca9547 [3.241065] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) [3.248565] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) [3.256053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) [3.263566] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) [3.283249] imx-drm display-subsystem: bound 12.hdmi (ops dw_hdmi_imx_ops) [3.299943] imx-drm display-subsystem: bound 200.aips-bus:ldb at 020e0008 (ops imx_ldb_ops) [3.547620] imx-drm display-subsystem: fb0: frame buffer device [3.577445] [drm] Initialized imx-drm 1.0.0 20120507 on minor 1 Log where things do not work in next-20160128: dmesg | grep -i 'drm \| pca' [1.265837] [drm] Initialized drm 1.1.0 20060810 [1.458511] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops) [1.466156] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops) [1.473766] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops ipu_crtc_ops) [1.481389] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops ipu_crtc_ops) [1.489201] imx-drm display-subsystem: failed to bind 12.hdmi (ops dw_hdmi_imx_ops): -517 [1.500631] imx-drm display-subsystem: master bind failed: -517 [2.188536] pca954x 0-0070: registered 8 multiplexed busses for I2C mux pca9547 [2.242492] pca954x 1-0070: registered 8 multiplexed busses for I2C mux pca9547 Complete log with next-20160128 kernel: [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.5.0-rc1-next-20160128-7-g0d6335e (nodeax at timesysab) (gcc version 4.8.5 (Timesys 20150713) ) #159 SMP Thu Jan 28 14:02:00 EST 2016 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: General Electric B850v3 [0.00] cma: Reserved 128 MiB at 0x8800 [0.00] Memory policy: Data cache writealloc [0.00] On node 0 totalpages: 524288 [0.00] free_area_init_node: node 0, pgdat 80c7e040, node_mem_map eeff8000 [0.00] Normal zone: 3584 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 458752 pages, LIFO batch:31 [0.00] HighMem zone: 65536 pages, LIFO batch:15 [0.00] PERCPU: Embedded 13 pages/cpu @eefa2000 s23296 r8192 d21760 u53248 [0.00] pcpu-alloc: s23296 r8192 d21760 u53248 alloc=13*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520704 [0.00] Kernel command line: console=ttymxc2,115200 ip=none root=/dev/mmcblk0p2 rootwait rw ext4 cma=128M [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes) [0.00] Inode-cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Memory: 1926572K/2097152K available (8759K kernel code, 429K rwdata, 3152K rodata, 420K init, 8374K bss, 39508K reserved, 131072K cma-reserved, 131072K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc
