linux-kernel - Re: GMA500: ERROR: "__bad

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMeQTsYhLTPLUBGgBTQ=2xDjzw1aK2Oif+_aC+=hVikALuUXPg@mail.gmail.com>
Date:	Tue, 26 Jul 2011 16:07:07 +0200
From:	Patrik Jakobsson <patrik.r.jakobsson@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Alan Cox <alan@...ux.intel.com>, Arnd Bergmann <arnd@...db.de>,
	Ryan Mallon <rmallon@...il.com>,
	Jesper Juhl <jj@...osbits.net>, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...e.de>, devel@...verdev.osuosl.org
Subject: Re: GMA500: ERROR: "__bad_udelay" undefined!

> Opinions are cheap, generating a list of all the paths through the tree
> that can hit vblank waits is alas not, neither is verifying it on a pile
> of real hardware 8(

Yes, it certainly needs testing before being changed.

> Plus none of the Intel issued IMG drivers wait for a vblank event and in
> several cases it's quite clear that there is *no* vblank that can be
> waited for at that point, eg look at the MIPI interfaces.

I don't think there is a particular reason for that. They are based on an old
version of i915 that used to do it that way. i915 changed to polling pipestat
in 2.6.36.

If there is no vblank to be waited for, we shouldn't be doing
wait_for_vblank. If we're waiting for a pipe to turn off, there should be a
wait_for_pipe_disable, and so on..

> So unfortunately it's rather complicated to fix although working them
> through to make some of the msleeps is certainly doable - add a
> sleep_for_vblank() or similar and send patches as you verify each one is
> ok and test it perhaps ?
>
> Alan

What about catching vblanks in irq handler and using a wait queue in
sleep_for_vblank and do pipestat polling in wait_for_vblank? Then I can start
testing sleep vs wait. All current wait_for_vblanks should be replaced with
mdelay(20) and marked with a FIXME.

wait_for_pipe_disable can do mdelay(20) until something better comes up.

If that is ok with you, I'll send some patches.

Patrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/