From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
As __builtin_return_address(n) doesn't work for ARM with n > 0, the
kernel needs its own implementation.
This fixes many warnings saying:
warning: unsupported argument to '__builtin_return_address'
The new methods and walk_stackframe must not be instrumented because
CALLER_ADDRESSx is used in the various tracers and tracing the tracer is
a bad idea.
What's currently missing is an implementation using unwind tables. This
is not fatal though, it's just that the tracers don't get enough
information to be really useful.
Note that if both ARM_UNWIND and FRAME_POINTER are enabled,
walk_stackframe uses unwind information. So in this case the same
implementation is used as when FRAME_POINTER is disabled.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With several sections per module, and dozens of modules, the
searches down the linked list of sections would dominate the
lookup time, dwarfing any savings from the binary search
within the section.
A simple move-to-front optimisation exploits the commonality
of the code paths taken, and in simple real-world tests reduces
the number of steps in the search to barely more than 1.
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The check for compiler which is supposed to miscompile unwind tables
clearly has nothing to do with sparse (which does not define necessary
macros anyway), so simply silence it.
Signed-off-by: Alexander Shishkin <virtuoso@slind.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM unwind is known to compile only with EABI and not-buggy compilers.
The problem is not the unwinding information but the -fno-frame-pointer
option added as a result of !CONFIG_FRAME_POINTER. Now we check the
compiler and raise a #warning in case of wrong compiler.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Will now parse the mode list to:
- Remove pixel clocks above 133MHz which the MX51 IPU DI cannot display (PLL limitation)
- Remove modes from mode list that are interlaced (cannot display)
- Find and save the best (native) panel mode and try and match a mode as close as possible instead of
arbitrarily trying 1280x720 (unless EDID failed for some reason)
* Reduce bus timeout default to 10ms as it always takes less (<4ms or so, but we want to handle slow monitors)
* Comment out instrumentation until it returns reasonable values (jiffies aren't accurate enough)
* Some variable renames for clearer code
The framebuffer routines also work with the cea861 data. Move the edid reading
into the function itself, which avoids us having to read the EDID data multiple
times and allows us to pass the full EDID data to the framebuffer routines.
We always have to read the first block to determine the actual length of the
EDID data. In order to keep the reading logic the same all the time, we simply
re-read the EDID data always (even if there are no extension blocks). This
hopefully will help keep timing issues similar across all devices.
* fix bus frequency driver check for frequency (> instead of !=)
* fix VPU lockup due to misassigning a clock
* stop dvfs before reboots (otherwise it might not reboot)
* small cleanups in DVFS code for frequency changing and added spinlock
For timer based power autogating, we have to move clk_enable/disable out of
timer handler, because they become may sleep.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
If GPU error interrupt detected, related device will be destroyed.
In the destory function, device_idle and mutex_lock may cause sleep,
which may cause kernel crash, so delay the device destroy to the
workqueue to avoid this.
Signed-off-by: Jie Zhou <b30303@freescale.com>
Cleanup the siihdmi header (which really is pointless to split out...), redefine
the fields for the sii info frame packets, and restructure sizes to be in terms
of registers.
The allocations are no longer done in the info frame setting, DVI can transmit
the info frames, and the cost is simply the i2c writes. This is an infrequent
operation, so just absorb the cost regardless of the connection type.
Use a proper edid structure definition rather than indexing into a data blob.
This also adds additional helper functions to work with the returned edid data.
There is much room for further improvements still. We should simply read the
first block, then use that to actually determine the number of blocks we need to
read from the device. We cant simply read all the potential blocks as that can
be up to 32K of data.
Once we are reading all the EDID extensions, we should iterate over the blocks
to find the CEA block rather than assuming that the device is sending the CEA
block as the first block (especially given that the VESA spec calls for block 1
to be an extension map if there are more than 1 block present).
bus_timeout depends somewhat on the output device for certain operations. As
such, it can be useful to actually change the value at runtime. To that end,
make the value a module parameter.
Bonus whitespace cleanups and centralises the value to a single location.
info frame checksumming is defined by the CEA861-E standard, and is not specific
to SII9xxx, so move that into the CEA861 header.
Don't bother allocating the info frame structures off the heap. That causes
unnecessary fragmentation and complexity. Allocate them off the stack as they
are small enough. This also helps keep everything simple.
As a bonus, fixed up the SII HDMI structures and the CEA861 InfoFrame structures
in the process as well. Also clean up the magic number in the AVI InfoFrame
assertion.
