litmus-rt.git - The LITMUS^RT kernel.

The LITMUS^RT kernel.

Bjoern Brandenburg

about summary refs log tree commit diff stats

diff options

author	Zhao Yakui <yakui.zhao@intel.com>	2010-01-04 03:29:32 -0500
committer	Eric Anholt <eric@anholt.net>	2010-01-06 12:40:13 -0500
commit	e5a95eb778690bc864eb330202d2c1b974caaeb4 (patch)
tree	ac6e92b9a488812ab46e1819f184d0d1cdc9b18e /include/linux/compiler-gcc.h
parent	8faf3b317471179c02db339aa80955a2e88c036d (diff)

drm/i915: Select the correct BPC for LVDS on Ironlake

Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel, the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8. At the same time the BPC will be 8 when the output device is CRT/HDMI/DP. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>

Diffstat (limited to 'include/linux/compiler-gcc.h')

0 files changed, 0 insertions, 0 deletions

devices themselves for determining device context properties. If the device 'eth0' or 'sda' does not have a "driver"-link, then this device does not have a driver. Its value is empty. Never copy any property of the parent-device into a child-device. Parent device-properties may change dynamically without any notice to the child device. - Hierarchy in a single device-tree There is only one valid place in sysfs where hierarchy can be examined and this is below: /sys/devices. It is planned, that all device directories will end up in the tree below this directory. - Classification by subsystem There are currently three places for classification of devices: /sys/block, /sys/class and /sys/bus. It is planned that these will not contain any device-directories themselves, but only flat lists of symlinks pointing to the unified /sys/devices tree. All three places have completely different rules on how to access device information. It is planned to merge all three classification-directories into one place at /sys/subsystem, following the layout of the bus-directories. All buses and classes, including the converted block-subsystem, will show up there. The devices belonging to a subsystem will create a symlink in the "devices" directory at /sys/subsystem/<name>/devices. If /sys/subsystem exists, /sys/bus, /sys/class and /sys/block can be ignored. If it does not exist, you have always to scan all three places, as the kernel is free to move a subsystem from one place to the other, as long as the devices are still reachable by the same subsystem name. Assuming /sys/class/<subsystem> and /sys/bus/<subsystem>, or /sys/block and /sys/class/block are not interchangeable, is a bug in the application. - Block The converted block-subsystem at /sys/class/block, or /sys/subsystem/block will contain the links for disks and partitions at the same level, never in a hierarchy. Assuming the block-subsytem to contain only disks and not partition-devices in the same flat list is a bug in the application. - "device"-link and <subsystem>:<kernel name>-links Never depend on the "device"-link. The "device"-link is a workaround for the old layout, where class-devices are not created in /sys/devices/ like the bus-devices. If the link-resolving of a device-directory does not end in /sys/devices/, you can use the "device"-link to find the parent devices in /sys/devices/. That is the single valid use of the "device"-link, it must never appear in any path as an element. Assuming the existence of the "device"-link for a device in /sys/devices/ is a bug in the application. Accessing /sys/class/net/eth0/device is a bug in the application. Never depend on the class-specific links back to the /sys/class directory. These links are also a workaround for the design mistake that class-devices are not created in /sys/devices. If a device directory does not contain directories for child devices, these links may be used to find the child devices in /sys/class. That is the single valid use of these links, they must never appear in any path as an element. Assuming the existence of these links for devices which are real child device directories in the /sys/devices tree, is a bug in the application. It is planned to remove all these links when when all class-device directories live in /sys/devices. - Position of devices along device chain can change. Never depend on a specific parent device position in the devpath, or the chain of parent devices. The kernel is free to insert devices into the chain. You must always request the parent device you are looking for by its subsystem value. You need to walk up the chain until you find the device that matches the expected subsystem. Depending on a specific position of a parent device, or exposing relative paths, using "../" to access the chain of parents, is a bug in the application.


context:
space:
mode: