Hello Sylwester,
On 10/20/2016 08:27 AM, Sylwester Nawrocki wrote:
On 10/20/2016 12:41 PM, Javier Martinez Canillas wrote:
I see no relevant changes in exynos_defconfig between v4.7..v4.8 and also no changes in drivers/Makefile that could cause things to be initialized on a different order.
I remember this
commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d clk: probe common clock drivers earlier
going in recently, but it's rather dubious it could cause such trouble.
Yes, I'm aware of this change (and in fact it broke MMC in the Peach Pi Chromebook) but that commit landed in v4.9-rc1, not v4.8.
Anyway, I'd try to add some debug prints to samsung_i2s_probe() to see what's the issue with the CPU DAI registration.
Sure, I'm busy with other stuff now but I'll dig again this next week.
But I thought the patches had merits on its own since probe deferral can make a driver probe many times and the error logs were noisy. I wasn't sure though and that's why are marked as RFC.
In general I wouldn't be disabling those err logs unless proper EPROBE_DEFER handling is added on related error paths and we can differentiate between probe deferral and real unrecoverable errors and can disable logging only for EPROBE_DEFER cases.
Yes, the sound core change (patch 1/2) is only for the EPROBE_DEFER path.
As far as the error log is concerned, I would just not print anything in snow_probe() when register_card() returns EPROBE_DEFER.
I believe it may be useful to know that a driver's probe is deferring due a missing dependency but have no strong opinion and can remove the message.
I'd rather rely on core code to inform about missing resources when registering components. Otherwise booting unnecessarily takes more time when there is more probe deferring logs printed on the console.
Fair enough.
-- Thanks, Sylwester
Best regards,