On 03/24/15 17:16, Tomi Valkeinen wrote:
On 24/03/15 16:28, Jyri Sarha wrote:
I tried first with 3.19 and then with 4.0-rc5, checked the boot and then
the modetest, but I could not reproduce the trace above.
In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m
on top of plain omap2plus_defconfig. Should I take something else?
Anyway, I doubt this has anything to do with my patches. Could you give
it one more try without my patches?
4.0-rc3 works ok for me without your patches. I can run modetest and I
get a picture on the monitor.
Well, not 100% ok. If I run my test app, I get "BUG: sleeping function
called from invalid context at drivers/base/power/runtime.c:949".
With your patches I get the warnings and I don't get anything on the
screen.
I've attached my kernel config.
Hmm. The warning comes if tilcdc_crtc_mode_valid() fails (I think). My
monitor is not a HDMI monitor. It has native mode 1920x1200@60, which
cannot be produced by tilcdc, and on -rc3 the mode picked is 1280x960@60.
Oh-o. That is the reason then. My HDMI TV also - wrongly - advertises
having 1920x1200@60 mode. When that mode produced the error I did not
think much of it and tested with other modes.
Maybe this is somehow related? You're using a HDMI TV? What mode does it
pick? Is it the native mode?
Hmm, yes, I think it's related. Enabling debug prints shows:
[ 32.361924] [drm:tilcdc_crtc_mode_valid] Processing mode 1920x1080@60
with pixel clock 148500
[ 32.370850] [drm:tilcdc_crtc_mode_valid] Pruning mode: pixel clock
too high
[ 32.378143] ------------[ cut here ]------------
[ 32.382993] WARNING: CPU: 0 PID: 50 at
drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269
tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]()
[ 32.394641] Modules linked in: tilcdc tda998x drm_kms_helper drm
[ 32.400964] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted
4.0.0-rc3-00007-g944a1f8a79f1 #16
[ 32.409617] Hardware name: Generic AM33XX (Flattened Device Tree)
So maybe your series removes some filtering somewhere, and illegal modes
get passed forward?
It indeed looks like that. The actual tilcdc_slave code does not have
much much logic in it, but is sounds like the DRM slave encoder API and
the DRM external encoder API are not entirely entirely "compatible".
I'll try to track this further.
Thanks,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
