[PATCH] arm64: defconfig: Enable modules for arm displays

Liviu Dudau liviu.dudau at arm.com
Tue May 10 13:06:52 PDT 2022


On Tue, May 10, 2022 at 05:31:11PM +0100, Mark Brown wrote:
> On Tue, May 10, 2022 at 05:19:04PM +0100, Liviu Dudau wrote:
> > On Tue, May 10, 2022 at 03:05:21PM +0100, Carsten Haitzler wrote:
> 
> > > is it the:
> 
> > > [    7.471809] tda9950 0-0034: driver requires an interrupt
> 
> > > that you're talking about Liviu?
> 
> > Yes, that is the warning.
> 
> That doesn't look too worrying TBH, if it's causing confusion we should
> just either fix the tda998x driver to not instantiate the tda9950 unless
> it has an interrupt or lower the severity of the log message in the
> tda9950 code.  It's certanly not something that should block use in a
> defconfig.
> 
> Ideally we'd not be using the wildcard compatible in the tda998x and
> would know if the CEC functionality was there but I think that ship has
> disappeared over the horizon at this point, and in any case someone
> might just not want to support CEC for some reason.

The quickest way is to harmonise the treatment of IRQs between tda998x and tda9950.
The former treats the IRQ as optional, the later as mandatory. Given that (according
to comments in the code) TDA998X is actually a TDA9989+TDA9950, it makes sense to
treat the lack of IRQ the same way (make it optional, IMHO).

I agree that that should not block adding the two config options to the defconfig.
It's just that using Juno as an argument for doing so when tda9950 returns ENXIO on
that platform can confuse people.

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯



More information about the linux-arm-kernel mailing list