On 27/09/2019 15:13, Adam Ford wrote:
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
On 26/09/2019 17:12, Adam Ford wrote:
And what is the hdmi5_configure there? I don't see anything in the
driver that would print hdmi5_configure. And, of course, there's no
hdmi5 on that platform. Hmm, ok... it's from component.c, using "%ps".
Somehow that goes wrong. Which is a bit alarming, but perhaps a totally
different issue.
I'll try to take a look later. For Logic PD distributions, we create
a custom defconfig with all those drivers removed, so I'm not worked
up about it, but it would be nice to not call drivers that don't
exist.
So you have CONFIG_OMAP5_DSS_HDMI=n? Then it's even more disturbing, as
there's no way the string "hdmi5_configure" can be in the kernel image...
For the logs and problems I am showing in this thread, I am using a
stock omap2plus_defconfig which has it enabled. I was only trying to
state that I am not worried about the omap5 hdmi stuff, because when I
do a custom distribution for Logic PD, I remove those config options
to make the issue go away.
Maybe it's nothing, but... It's just so odd.
I don't think we need to worry about it now. Ideally, it would be
nice to have the drivers recognize they are not needed and or setup
the Kconfig options to make these drivers dependent on the platforms
that support it so unselecting OMAP5 could make the omap5 options
disappear.
My point is that something is bugging there. It should not print
hdmi5_configure, regardless of setup or platform. If I'm not mistaken,
it should print "dispc_component_ops". But somehow it gets a wrong
symbol string.
But yes, I'm 99.9% sure it's not related, so let's ignore it here =).
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
