This patch introduces a new flag SCHED_RESET_ON_FORK which can be passed
to the kernel via sched_setscheduler(), ORed in the policy parameter. If
set this will make sure that when the process forks a) the scheduling
priority is reset to DEFAULT_PRIO if it was higher and b) the scheduling
policy is reset to SCHED_NORMAL if it was either SCHED_FIFO or SCHED_RR.
Why have this?
Currently, if a process is real-time scheduled this will 'leak' to all
its child processes. For security reasons it is often (always?) a good
idea to make sure that if a process acquires RT scheduling this is
confined to this process and only this process. More specifically this
makes the per-process resource limit RLIMIT_RTTIME useful for security
purposes, because it makes it impossible to use a fork bomb to
circumvent the per-process RLIMIT_RTTIME accounting.
This feature is also useful for tools like 'renice' which can then
change the nice level of a process without having this spill to all its
child processes.
Why expose this via sched_setscheduler() and not other syscalls such as
prctl() or sched_setparam()?
prctl() does not take a pid parameter. Due to that it would be
impossible to modify this flag for other processes than the current one.
The struct passed to sched_setparam() can unfortunately not be extended
without breaking compatibility, since sched_setparam() lacks a size
parameter.
How to use this from userspace? In your RT program simply replace this:
sched_setscheduler(pid, SCHED_FIFO, ¶m);
by this:
sched_setscheduler(pid, SCHED_FIFO|SCHED_RESET_ON_FORK, ¶m);
Signed-off-by: Lennart Poettering <lennart@poettering.net>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20090615152714.GA29092@tango.0pointer.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
(cherry picked from commit ca94c442535a44d508c99a77e54f21a59f4fc462)
Add parsing of E-EDID SVD entries. In this first version only a few
CEA/EIA-861E modes are implemented, more can be added as needed.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Modern monitors/tvs have more extended EDID information blocks which can
contain extra detailed modes. This adds a fb_edid_add_monspecs function
which drivers can use to parse those additions blocks.
Signed-off-by: Erik Gilling <konkers@android.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Use list_for_each_entry_safe to make the code easier to follow, re-order the
checks for removal, and break once the remove flag is set in the list traversal.
SII9022 requires some platform specific data that was previously hardcoded into
the driver. Create a new siihdmi_platform_data struct to actually get this
information. This allows a particular vendor to supply the IRQ vector, the
reset method, the framebuffer id, as well as the vendor/description for the SPD
block currently.
Some usbnet drivers update link state while others do not due to
hardware limitations. Add a flag to distinguish those that do, and
set the link down initially for their devices.
This is intended to fix this bug: http://bugs.debian.org/444043
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 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
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.
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).
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.
drag mxc_ipuv3_fb with it (remove final efikamx specific stuff)
update some IPU stuff and ioctls for it all to interoperate
notes:
that line_length bug is still there, I really can't find why it's 0...
doesn't register because the platform_device isn't in a/a/p-mxc/devices.?
ENGR00133954 ipuv3: remove FB_SYNC_EXT flag
ENGR00133034 ipuv3: fix black flash issue during high resolution video playback
ENGR00134076 ipuv3: should not set burst size again
ENGR00133345 IPUv3 VDI:Support bottom field first setting
ENGR00131660 ipuv3: left stripe output column should be set to zero
This actually fixes the clock sync problem with the AOC HDMI monitor we have (perfectly
working display but "input not support" floating around). Happily, the boot splash
actually works, too (previously it would not work until the second set of the display
when GDM booted). Hopefully IPU support is nice and stable now.
Support two new half-duplex SPI implementation restrictions, for links
that talk to TX-only or RX-only devices. (Existing half-duplex flavors
support both transfer directions, just not at the same time.)
Move spi_async() into the spi.c core, and stop inlining it. Then make
that function perform error checks and reject messages that demand more
than the underlying controller can support.
Based on a patch from Marek Szyprowski which did this only for the
bitbanged GPIO driver.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently spi_register_board_info() has to be called before its related
spi_master be registered, otherwise these board info will be just ignored.
This patch will remove this order limit, it adds a global spi master list
like the existing global board info listr. Whenever a board info or a
spi_master is registered, the spi master list or board info list
will be scanned, and a new spi device will be created if there is a
master-board info match.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
With this patch spi drivers can use standard spi_driver.id_table and
MODULE_DEVICE_TABLE() mechanisms to bind against the devices. Just like
we do with I2C drivers.
This is useful when a single driver supports several variants of devices
but it is not possible to detect them in run-time (like non-JEDEC chips
probing in drivers/mtd/devices/m25p80.c), and when platform_data usage is
overkill.
This patch also makes life a lot easier on OpenFirmware platforms, since
with OF we extensively use proper device IDs in modaliases.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A number of files in drivers/spi fail checkincludes.pl due to the double
include of <linux/spi/spi_bitbang.h>.
The first include is needed to get the struct spi_bitbang definition and
the spi_bitbang_* function prototypes.
The second include happens after defining EXPAND_BITBANG_TXRX to get the
inlined bitbang_txrx_* utility functions.
The <linux/spi/spi_bitbang.h> header is also included by a number of other
spi drivers, as well as some arch/ code, in order to use struct spi_bitbang
and the associated functions.
To fix the double include, and remove any potential confusion about it, move
the inlined bitbang_txrx_* functions to a new private header in drivers/spi
and also remove the need to define EXPAND_BITBANG_TXRX.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
