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

index : litmus-rt.git

The LITMUS^RT kernel.

Bjoern Brandenburg

about summary refs log tree commit diff stats

path: root/kernel/cpu.c

diff options

author	Zhao Yakui <yakui.zhao@intel.com>	2009-12-31 03:06:04 -0500
committer	Eric Anholt <eric@anholt.net>	2010-01-06 12:40:13 -0500
commit	4547668a050e7de3cd73a4c6736dfc2adebff67d (patch)
tree	da6d1fe67ed8295f89caaf2e9882718c61781557 /kernel/cpu.c
parent	e5a95eb778690bc864eb330202d2c1b974caaeb4 (diff)

drm/i915: Add DP dpll limit on ironlake and use existing DPLL search function

For some clocks, the old Ironlake DPLL calculator wold give m/n/p combinations that didn't match the spreadsheet of what HW validation tests. Instead, use the G4X DPLL calculator, which does a better job at it. So we use the intel_g4x_find_best_pll to calculate the DPLL for CRT/HDMI/LVDS on ironlake. At the same time to consider the dpll setting for display port, we add the display port DPLL limit on ironlake, which will directly use the function of intel_find_pll_ironlake_dp to get the corresponding dpll setting. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>

Diffstat (limited to 'kernel/cpu.c')

0 files changed, 0 insertions, 0 deletions

ink values as elements in a devpath string is a bug in the application o kernel name (sda, tty, 0000:00:1f.2, ...) - a directory name, identical to the last element of the devpath - applications need to handle spaces and characters like '!' in the name o subsystem (block, tty, pci, ...) - simple string, never a path or a link - retrieved by reading the "subsystem"-link and using only the last element of the target path o driver (tg3, ata_piix, uhci_hcd) - a simple string, which may contain spaces, never a path or a link - it is retrieved by reading the "driver"-link and using only the last element of the target path - devices which do not have "driver"-link, just do not have a driver; copying the driver value in a child device context, is a bug in the application o attributes - the files in the device directory or files below a subdirectories of the same device directory - accessing attributes reached by a symlink pointing to another device, like the "device"-link, is a bug in the application Everything else is just a kernel driver-core implementation detail, that should not be assumed to be stable across kernel releases. - Properties of parent devices never belong into a child device. Always look at the parent 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.