From 13049537007dee73a76f0a30fcbc24d02c6fa9e4 Mon Sep 17 00:00:00 2001 From: Joseph Handzik Date: Mon, 8 Aug 2011 11:40:15 +0200 Subject: cciss: Adds simple mode functionality Signed-off-by: Joseph Handzik Acked-by: Stephen M. Cameron Signed-off-by: Jens Axboe --- Documentation/blockdev/cciss.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/blockdev/cciss.txt b/Documentation/blockdev/cciss.txt index c00c6a5..71464e0 100644 --- a/Documentation/blockdev/cciss.txt +++ b/Documentation/blockdev/cciss.txt @@ -78,6 +78,16 @@ The device naming scheme is: /dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 /dev/cciss/c1d1p3 Controller 1, disk 1, partition 3 +CCISS simple mode support +------------------------- + +The "cciss_simple_mode=1" boot parameter may be used to prevent the driver +from putting the controller into "performant" mode. The difference is that +with simple mode, each command completion requires an interrupt, while with +"performant mode" (the default, and ordinarily better performing) it is +possible to have multiple command completions indicated by a single +interrupt. + SCSI tape drive and medium changer support ------------------------------------------ -- cgit v1.1 From f963d270cb7bbb8eeb57901d02b22a493e664fd2 Mon Sep 17 00:00:00 2001 From: Joe Handzik Date: Mon, 8 Aug 2011 11:40:17 +0200 Subject: cciss: add transport mode attribute to sys Signed-off-by: Joseph Handzik Acked-by: Stephen M. Cameron Signed-off-by: Jens Axboe --- Documentation/ABI/testing/sysfs-bus-pci-devices-cciss | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss index f5bb0a3..53d99ed 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss @@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices a dump device, as kdump requires resetting the device in order to work reliably. +Where: /sys/bus/pci/devices//ccissX/transport_mode +Date: July 2011 +Kernel Version: 3.0 +Contact: iss_storagedev@hp.com +Description: Value of "simple" indicates that the controller has been placed + in "simple mode". Value of "performant" indicates that the + controller has been placed in "performant mode". -- cgit v1.1 From 30343ef1de348cd21cd7d0cebde3c0175b730e0b Mon Sep 17 00:00:00 2001 From: Jamie Iles Date: Mon, 1 Aug 2011 17:25:19 +0100 Subject: crypto: picoxcell - support for device tree matching Allow the crypto engines to be matched from device tree bindings. Cc: devicetree-discuss@lists.ozlabs.org Cc: Herbert Xu Signed-off-by: Jamie Iles Signed-off-by: Herbert Xu --- .../devicetree/bindings/crypto/picochip-spacc.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/picochip-spacc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/picochip-spacc.txt b/Documentation/devicetree/bindings/crypto/picochip-spacc.txt new file mode 100644 index 0000000..d8609ec --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/picochip-spacc.txt @@ -0,0 +1,23 @@ +Picochip picoXcell SPAcc (Security Protocol Accelerator) bindings + +Picochip picoXcell devices contain crypto offload engines that may be used for +IPSEC and femtocell layer 2 ciphering. + +Required properties: + - compatible : "picochip,spacc-ipsec" for the IPSEC offload engine + "picochip,spacc-l2" for the femtocell layer 2 ciphering engine. + - reg : Offset and length of the register set for this device + - interrupt-parent : The interrupt controller that controls the SPAcc + interrupt. + - interrupts : The interrupt line from the SPAcc. + - ref-clock : The input clock that drives the SPAcc. + +Example SPAcc node: + +spacc@10000 { + compatible = "picochip,spacc-ipsec"; + reg = <0x100000 0x10000>; + interrupt-parent = <&vic0>; + interrupts = <24>; + ref-clock = <&ipsec_clk>, "ref"; +}; -- cgit v1.1 From fbc854027c91fa2813ae7f9de43cc0b5c1119f41 Mon Sep 17 00:00:00 2001 From: Lukas Czerner Date: Tue, 16 Aug 2011 18:08:06 +0200 Subject: ext3: remove deprecated oldalloc For a long time now orlov is the default block allocator in the ext3. It performs better than the old one and no one seems to claim otherwise so we can safely drop it and make oldalloc and orlov mount option deprecated. Signed-off-by: Lukas Czerner Signed-off-by: Jan Kara --- Documentation/filesystems/ext3.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 22f3a0e..b100adc 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -73,14 +73,6 @@ nobarrier (*) This also requires an IO stack which can support also be used to enable or disable barriers, for consistency with other ext3 mount options. -orlov (*) This enables the new Orlov block allocator. It is - enabled by default. - -oldalloc This disables the Orlov block allocator and enables - the old block allocator. Orlov should have better - performance - we'd like to get some feedback if it's - the contrary for you. - user_xattr Enables Extended User Attributes. Additionally, you need to have extended attribute support enabled in the kernel configuration (CONFIG_EXT3_FS_XATTR). See the -- cgit v1.1 From a78f6787a3dd7223bf185895fdcea661b408dc0a Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 17:18:08 +0000 Subject: DocBook/drm: Eradicate inappropriate uses of the future tense Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 50 +++++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index c279158..0527ff2 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -57,10 +57,10 @@ existing drivers. - First, we'll go over some typical driver initialization + First, we go over some typical driver initialization requirements, like setting up command buffers, creating an initial output configuration, and initializing core services. - Subsequent sections will cover core internals in more detail, + Subsequent sections cover core internals in more detail, providing implementation notes and examples. @@ -74,7 +74,7 @@ The core of every DRM driver is struct drm_driver. Drivers - will typically statically initialize a drm_driver structure, + typically statically initialize a drm_driver structure, then pass it to drm_init() at load time. @@ -155,7 +155,7 @@ In the example above, taken from the i915 DRM driver, the driver sets several flags indicating what core features it supports. - We'll go over the individual callbacks in later sections. Since + We go over the individual callbacks in later sections. Since flags indicate which features your driver supports to the DRM core, you need to set most of them prior to calling drm_init(). Some, like DRIVER_MODESET can be set later based on user supplied parameters, @@ -238,7 +238,7 @@ In this specific case, the driver requires AGP and supports - IRQs. DMA, as we'll see, is handled by device specific ioctls + IRQs. DMA, as discussed later, is handled by device specific ioctls in this case. It also supports the kernel mode setting APIs, though unlike in the actual i915 driver source, this example unconditionally exports KMS capability. @@ -315,7 +315,7 @@ Configuring the device - Obviously, device configuration will be device specific. + Obviously, device configuration is device specific. However, there are several common operations: finding a device's PCI resources, mapping them, and potentially setting up an IRQ handler. @@ -326,7 +326,7 @@ drm_get_resource_len() can be used to find BARs on the given drm_device struct. Once those values have been retrieved, the driver load function can call drm_addmap() to create a new - mapping for the BAR in question. Note you'll probably want a + mapping for the BAR in question. Note you probably want a drm_local_map_t in your driver private structure to track any mappings you create. @@ -357,7 +357,7 @@ - Once your interrupt handler is registered (it'll use your + Once your interrupt handler is registered (it uses your drm_driver.irq_handler as the actual interrupt handling function), you can safely enable interrupts on your device, assuming any other state your interrupt handler uses is also @@ -389,7 +389,7 @@ should support a memory manager. - If your driver supports memory management (it should!), you'll + If your driver supports memory management (it should!), you need to set that up at load time as well. How you initialize it depends on which memory manager you're using, TTM or GEM. @@ -430,13 +430,13 @@ have a type of TTM_GLOBAL_TTM_MEM. The size field for the global object should be sizeof(struct ttm_mem_global), and the init and release hooks should point at your driver specific init and - release routines, which will probably eventually call + release routines, which probably eventually call ttm_mem_global_init and ttm_mem_global_release respectively. Once your global TTM accounting structure is set up and initialized (done by calling ttm_global_item_ref on the global object you - just created), you'll need to create a buffer object TTM to + just created), you need to create a buffer object TTM to provide a pool for buffer object allocation by clients and the kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct ttm_bo_global). Again, @@ -455,8 +455,8 @@ than TTM, but has no VRAM management capability. Core GEM initialization is comprised of a basic drm_mm_init call to create a GTT DRM MM object, which provides an address space pool for - object allocation. In a KMS configuration, the driver will - need to allocate and initialize a command ring buffer following + object allocation. In a KMS configuration, the driver + needs to allocate and initialize a command ring buffer following basic GEM initialization. Most UMA devices have a so-called "stolen" memory region, which provides space for the initial framebuffer and large, contiguous memory regions required by the @@ -464,16 +464,16 @@ be initialized separately into its own DRM MM object. - Initialization will be driver specific, and will depend on + Initialization is driver specific, and depends on the architecture of the device. In the case of Intel integrated graphics chips like 965GM, GEM initialization can be done by calling the internal GEM init function, i915_gem_do_init(). Since the 965GM is a UMA device - (i.e. it doesn't have dedicated VRAM), GEM will manage + (i.e. it doesn't have dedicated VRAM), GEM manages making regular RAM available for GPU operations. Memory set aside by the BIOS (called "stolen" memory by the i915 - driver) will be managed by the DRM memrange allocator; the - rest of the aperture will be managed by GEM. + driver) is managed by the DRM memrange allocator; the + rest of the aperture is managed by GEM. /* Basic memrange allocator for stolen space (aka vram) */ drm_memrange_init(&dev_priv->vram, 0, prealloc_size); @@ -616,7 +616,7 @@ void intel_crt_init(struct drm_device *dev) DRM_IOCTL_MODESET_CTL should be called by application level drivers before and after mode setting, since on many devices the - vertical blank counter will be reset at that time. Internally, + vertical blank counter is reset at that time. Internally, the DRM snapshots the last vblank count when the ioctl is called with the _DRM_PRE_MODESET command so that the counter won't go backwards (which is dealt with when _DRM_POST_MODESET is used). @@ -632,8 +632,8 @@ void intel_crt_init(struct drm_device *dev) register. The enable and disable vblank callbacks should enable and disable vertical blank interrupts, respectively. In the absence of DRM clients waiting on vblank events, the core DRM - code will use the disable_vblank() function to disable - interrupts, which saves power. They'll be re-enabled again when + code uses the disable_vblank() function to disable + interrupts, which saves power. They are re-enabled again when a client calls the vblank wait ioctl above. @@ -699,14 +699,14 @@ void intel_crt_init(struct drm_device *dev) performs any necessary flushing or synchronization to put the object into the desired coherency domain (note that the object may be busy, i.e. an active render target; in that case the set domain function - will block the client and wait for rendering to complete before + blocks the client and waits for rendering to complete before performing any necessary flushing operations). Perhaps the most important GEM function is providing a command execution interface to clients. Client programs construct command buffers containing references to previously allocated memory objects - and submit them to GEM. At that point, GEM will take care to bind + and submit them to GEM. At that point, GEM takes care to bind all the objects into the GTT, execute the buffer, and provide necessary synchronization between clients accessing the same buffers. This often involves evicting some objects from the GTT and re-binding @@ -767,7 +767,7 @@ void intel_crt_init(struct drm_device *dev) In order to set a mode on a given CRTC, encoder and connector configuration, clients need to provide a framebuffer object which - will provide a source of pixels for the CRTC to deliver to the encoder(s) + provides a source of pixels for the CRTC to deliver to the encoder(s) and ultimately the connector(s) in the configuration. A framebuffer is fundamentally a driver specific memory object, made into an opaque handle by the DRM addfb function. Once an fb has been created this @@ -789,7 +789,7 @@ void intel_crt_init(struct drm_device *dev) The DRM core provides some suspend/resume code, but drivers wanting full suspend/resume support should provide save() and - restore() functions. These will be called at suspend, + restore() functions. These are called at suspend, hibernate, or resume time, and should perform any state save or restore required by your device across suspend or hibernate states. @@ -823,7 +823,7 @@ void intel_crt_init(struct drm_device *dev) Cover generic ioctls and sysfs layout here. Only need high - level info, since man pages will cover the rest. + level info, since man pages should cover the rest. -- cgit v1.1 From f11aca045c165b9d4c9c4fce29f51ec24bcf64d3 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 17:21:31 +0000 Subject: DocBook/drm: can -> may Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 0527ff2..b907938 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -32,7 +32,7 @@ The Linux DRM layer contains code intended to support the needs of complex graphics devices, usually containing programmable pipelines well suited to 3D graphics acceleration. Graphics - drivers in the kernel can make use of DRM functions to make + drivers in the kernel may make use of DRM functions to make tasks like memory management, interrupt handling and DMA easier, and provide a uniform interface to applications. @@ -293,12 +293,12 @@ can be used for tracking various device specific bits of information, like register offsets, command buffer status, register state for suspend/resume, etc. At load time, a - driver can simply allocate one and set drm_device.dev_priv + driver may simply allocate one and set drm_device.dev_priv appropriately; at unload the driver can free it and set drm_device.dev_priv to NULL. - The DRM supports several counters which can be used for rough + The DRM supports several counters which may be used for rough performance characterization. Note that the DRM stat counter system is not often used by applications, and supporting additional counters is completely optional. @@ -323,7 +323,7 @@ Finding & mapping resources is fairly straightforward. The DRM wrapper functions, drm_get_resource_start() and - drm_get_resource_len() can be used to find BARs on the given + drm_get_resource_len() may be used to find BARs on the given drm_device struct. Once those values have been retrieved, the driver load function can call drm_addmap() to create a new mapping for the BAR in question. Note you probably want a @@ -335,12 +335,12 @@ if compatibility with other operating systems isn't a concern (DRM drivers can run under various BSD variants and OpenSolaris), - native Linux calls can be used for the above, e.g. pci_resource_* + native Linux calls may be used for the above, e.g. pci_resource_* and iomap*/iounmap. See the Linux device driver book for more info. - Once you have a register map, you can use the DRM_READn() and + Once you have a register map, you may use the DRM_READn() and DRM_WRITEn() macros to access the registers on your device, or use driver specific versions to offset into your MMIO space relative to a driver specific base pointer (see I915_READ for @@ -440,7 +440,7 @@ provide a pool for buffer object allocation by clients and the kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct ttm_bo_global). Again, - driver specific init and release functions can be provided, + driver specific init and release functions may be provided, likely eventually calling ttm_bo_global_init and ttm_bo_global_release, respectively. Also like the previous object, ttm_global_item_ref is used to create an initial reference @@ -483,7 +483,7 @@ - Once the memory manager has been set up, we can allocate the + Once the memory manager has been set up, we may allocate the command buffer. In the i915 case, this is also done with a GEM function, i915_gem_init_ringbuffer(). @@ -572,7 +572,7 @@ void intel_crt_init(struct drm_device *dev) devices with PC-style architectures (i.e. a set of display planes for feeding pixels to encoders which are in turn routed to connectors). Devices with more complex requirements needing - finer grained management can opt to use the core callbacks + finer grained management may opt to use the core callbacks directly. @@ -637,7 +637,7 @@ void intel_crt_init(struct drm_device *dev) a client calls the vblank wait ioctl above. - Devices that don't provide a count register can simply use an + Devices that don't provide a count register may simply use an internal atomic counter incremented on every vertical blank interrupt, and can make their enable and disable vblank functions into no-ops. -- cgit v1.1 From 0c54781bc5aaec1e23bc50a4ef757b8e8bfc693b Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 17:55:54 +0000 Subject: DocBook/drm: Clean up code comment Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b907938..4ddc999 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -88,8 +88,8 @@ static struct drm_driver driver = { - /* don't use mtrr's here, the Xserver or user space app should - * deal with them for intel hardware. + /* Don't use MTRRs here; the Xserver or userspace app should + * deal with them for Intel hardware. */ .driver_features = DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | -- cgit v1.1 From 2c267e9e016da3e19a95261875a5f3b19dd6e9f6 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:10:12 +0000 Subject: DocBook/drm: Use a semicolon Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 4ddc999..aa13e08 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -154,8 +154,8 @@ In the example above, taken from the i915 DRM driver, the driver - sets several flags indicating what core features it supports. - We go over the individual callbacks in later sections. Since + sets several flags indicating what core features it supports; + we go over the individual callbacks in later sections. Since flags indicate which features your driver supports to the DRM core, you need to set most of them prior to calling drm_init(). Some, like DRIVER_MODESET can be set later based on user supplied parameters, @@ -647,8 +647,8 @@ void intel_crt_init(struct drm_device *dev) Memory management - The memory manager lies at the heart of many DRM operations, and - is also required to support advanced client features like OpenGL + The memory manager lies at the heart of many DRM operations; it + is required to support advanced client features like OpenGL pbuffers. The DRM currently contains two memory managers, TTM and GEM. -- cgit v1.1 From 02391f1fe7b4e5434e4c558dcae99b9368c84bf3 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:20:54 +0000 Subject: DocBook/drm: a -> an Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index aa13e08..5b815b8 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -203,7 +203,7 @@ DRIVER_HAVE_IRQDRIVER_IRQ_SHARED - DRIVER_HAVE_IRQ indicates whether the driver has a IRQ + DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler, DRIVER_IRQ_SHARED indicates whether the device & handler support shared IRQs (note that this is required of PCI drivers). -- cgit v1.1 From b1f95bdc1eb10e3d3c8a85b2f0bc08fa6c08ae5d Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:21:29 +0000 Subject: DocBook/drm: , -> . Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 5b815b8..a0f0f98 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -204,7 +204,7 @@ DRIVER_HAVE_IRQ indicates whether the driver has an IRQ - handler, DRIVER_IRQ_SHARED indicates whether the device & + handler. DRIVER_IRQ_SHARED indicates whether the device & handler support shared IRQs (note that this is required of PCI drivers). -- cgit v1.1 From 80c84e6f3c2c707ccb5d7b500e25bda69f0e1895 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:23:21 +0000 Subject: DocBook/drm: Move `should be set' to the beginning of the sentence Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index a0f0f98..42368f4 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -214,8 +214,8 @@ DRIVER_DMA_QUEUE - If the driver queues DMA requests and completes them - asynchronously, this flag should be set. Deprecated. + Should be set if the driver queues DMA requests and completes them + asynchronously. Deprecated. -- cgit v1.1 From 58f1d652def02db0bdcdf03d01f3483fc18ec392 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:31:42 +0000 Subject: DocBook/drm: Clean up `pre-memory management aware' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 42368f4..e9242c0 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -273,7 +273,7 @@ conflict with DRM client requirements. For instance, if user level mode setting drivers are in use, it would be problematic to perform output discovery & configuration at load time. - Likewise, if pre-memory management aware user level drivers are + Likewise, if user-level drivers unaware of memory management are in use, memory management and command buffer setup may need to be omitted. These requirements are driver specific, and care needs to be taken to keep both old and new applications and -- cgit v1.1 From 75aa9df5a2bf2ae90a1f0f6f283278f634ca4233 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:34:49 +0000 Subject: DocBook/drm: Rearrange wording to make more sense Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index e9242c0..eb28cc0 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -281,9 +281,9 @@ module parameter to control whether advanced features are enabled at load time or in legacy fashion. If compatibility is a concern (e.g. with drivers converted over to the new interfaces - from the old ones), care must be taken to prevent incompatible - device initialization and control with the currently active - userspace drivers. + from the old ones), care must be taken to prevent device + initialization and control that is incompatible with + currently active userspace drivers. -- cgit v1.1 From 6e375f44b6073dd320895753ff05cbfd3f410f66 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:37:05 +0000 Subject: DocBook/drm: Replace the paragraph's first sentence with its last sentence Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index eb28cc0..9eda9b6 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -269,8 +269,10 @@ initial output configuration. - Note that the tasks performed at driver load time must not - conflict with DRM client requirements. For instance, if user + If compatibility is a concern (e.g. with drivers converted over + to the new interfaces from the old ones), care must be taken to + prevent device initialization and control that is incompatible with + currently active userspace drivers. For instance, if user level mode setting drivers are in use, it would be problematic to perform output discovery & configuration at load time. Likewise, if user-level drivers unaware of memory management are @@ -279,11 +281,7 @@ needs to be taken to keep both old and new applications and libraries working. The i915 driver supports the "modeset" module parameter to control whether advanced features are - enabled at load time or in legacy fashion. If compatibility is - a concern (e.g. with drivers converted over to the new interfaces - from the old ones), care must be taken to prevent device - initialization and control that is incompatible with - currently active userspace drivers. + enabled at load time or in legacy fashion. -- cgit v1.1 From 06fa7b8066d4dc3f6c9d4c4bf34f385d5a823f13 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:40:55 +0000 Subject: DocBook/drm: Better wording Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 9eda9b6..b4196c1 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -292,8 +292,8 @@ information, like register offsets, command buffer status, register state for suspend/resume, etc. At load time, a driver may simply allocate one and set drm_device.dev_priv - appropriately; at unload the driver can free it and set - drm_device.dev_priv to NULL. + appropriately; it should be freed and drm_device.dev_priv set + to NULL when the driver is unloaded. The DRM supports several counters which may be used for rough -- cgit v1.1 From 57a15fd663d6680dc100a537f0ed328993c33af2 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:42:36 +0000 Subject: DocBook/drm: Clearer wording with `for consumption by' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b4196c1..33290e3 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -305,8 +305,8 @@ These interfaces are deprecated and should not be used. If performance monitoring is desired, the developer should investigate and potentially enhance the kernel perf and tracing infrastructure to export - GPU related performance information to performance monitoring - tools and applications. + GPU related performance information for consumption by performance + monitoring tools and applications. -- cgit v1.1 From 8814630f0b59421e558f4403b79f5dc3a025a386 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:46:10 +0000 Subject: DocBook/drm: Insert missing `that' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 33290e3..25e0f46 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -321,10 +321,10 @@ Finding & mapping resources is fairly straightforward. The DRM wrapper functions, drm_get_resource_start() and - drm_get_resource_len() may be used to find BARs on the given + drm_get_resource_len(), may be used to find BARs on the given drm_device struct. Once those values have been retrieved, the driver load function can call drm_addmap() to create a new - mapping for the BAR in question. Note you probably want a + mapping for the BAR in question. Note that you probably want a drm_local_map_t in your driver private structure to track any mappings you create. -- cgit v1.1 From f07faf693c59b449b6637ea056e5826c85dcd265 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:48:15 +0000 Subject: DocBook/drm: Insert missing `an' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 25e0f46..1b2e3c3 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -342,7 +342,7 @@ DRM_WRITEn() macros to access the registers on your device, or use driver specific versions to offset into your MMIO space relative to a driver specific base pointer (see I915_READ for - example). + an example). If your device supports interrupt generation, you may want to -- cgit v1.1 From 5b658bf2bf9e47f9a67cd26b1c69e4441eaf04fc Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:49:11 +0000 Subject: DocBook/drm: `setup' is the noun; `to set up' is the verb Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 1b2e3c3..d2f1dda 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -346,7 +346,7 @@ If your device supports interrupt generation, you may want to - setup an interrupt handler at driver load time as well. This + set up an interrupt handler at driver load time as well. This is done using the drm_irq_install() function. If your device supports vertical blank interrupts, it should call drm_vblank_init() to initialize the core vblank handling code before -- cgit v1.1 From bb49a6a1f3303f9cf23a19f403c9b90cdff0e7da Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:50:14 +0000 Subject: DocBook/drm: `at driver load time' -> `when the driver is loaded' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index d2f1dda..7001937 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -346,7 +346,7 @@ If your device supports interrupt generation, you may want to - set up an interrupt handler at driver load time as well. This + set up an interrupt handler when the driver is loaded. This is done using the drm_irq_install() function. If your device supports vertical blank interrupts, it should call drm_vblank_init() to initialize the core vblank handling code before -- cgit v1.1 From 9c2416adac986d7d90814d7985a0ea80ebea416f Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:56:12 +0000 Subject: DocBook/drm: Use the passive voice Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 7001937..03321eb 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -369,9 +369,9 @@ using the pci_map_rom() call, a convenience function that takes care of mapping the actual ROM, whether it has been shadowed into memory (typically at address 0xc0000) or exists - on the PCI device in the ROM BAR. Note that once you've - mapped the ROM and extracted any necessary information, be - sure to unmap it; on many devices the ROM address decoder is + on the PCI device in the ROM BAR. Note that after the ROM + has been mapped and any necessary information has been extracted, + it should be unmapped; on many devices the ROM address decoder is shared with other BARs, so leaving it mapped can cause undesired behavior like hangs or memory corruption. -- cgit v1.1 From 118bdd70bdd73b08dcc3920fa30a21be5bbbffae Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:57:04 +0000 Subject: DocBook/drm: Offset modifiers with commas Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 03321eb..ce145ba 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -371,7 +371,7 @@ shadowed into memory (typically at address 0xc0000) or exists on the PCI device in the ROM BAR. Note that after the ROM has been mapped and any necessary information has been extracted, - it should be unmapped; on many devices the ROM address decoder is + it should be unmapped; on many devices, the ROM address decoder is shared with other BARs, so leaving it mapped can cause undesired behavior like hangs or memory corruption. @@ -440,7 +440,7 @@ and its size should be sizeof(struct ttm_bo_global). Again, driver specific init and release functions may be provided, likely eventually calling ttm_bo_global_init and - ttm_bo_global_release, respectively. Also like the previous + ttm_bo_global_release, respectively. Also, like the previous object, ttm_global_item_ref is used to create an initial reference count for the TTM, which will call your initialization function. @@ -613,7 +613,7 @@ void intel_crt_init(struct drm_device *dev) DRM_IOCTL_MODESET_CTL should be called by application level - drivers before and after mode setting, since on many devices the + drivers before and after mode setting, since on many devices, the vertical blank counter is reset at that time. Internally, the DRM snapshots the last vblank count when the ioctl is called with the _DRM_PRE_MODESET command so that the counter won't go @@ -696,7 +696,7 @@ void intel_crt_init(struct drm_device *dev) set domain function, which evaluates an object's current domain and performs any necessary flushing or synchronization to put the object into the desired coherency domain (note that the object may be busy, - i.e. an active render target; in that case the set domain function + i.e. an active render target; in that case, the set domain function blocks the client and waits for rendering to complete before performing any necessary flushing operations). -- cgit v1.1 From 8d36ffae67d89a86e37e7745503743fec1ac695c Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:57:37 +0000 Subject: DocBook/drm: can -> could Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ce145ba..60ddf4b 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -372,7 +372,7 @@ on the PCI device in the ROM BAR. Note that after the ROM has been mapped and any necessary information has been extracted, it should be unmapped; on many devices, the ROM address decoder is - shared with other BARs, so leaving it mapped can cause + shared with other BARs, so leaving it mapped could cause undesired behavior like hangs or memory corruption. -- cgit v1.1 From cfdad2aba7398021f6eec415b9271b9cb40065f9 Mon Sep 17 00:00:00 2001 From: David Brown Date: Thu, 4 Aug 2011 01:55:24 -0700 Subject: msm_serial: Add devicetree support Add devicetree support to the msm_serial driver. Clocks are still queried by direct name from the driver until device tree clock support is implemented. Change-Id: Ia6b2ddfcf1e5dc3bd25dd502662f971202e6d56f Signed-off-by: David Brown Acked-by: Arnd Bergmann --- .../devicetree/bindings/tty/serial/msm_serial.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/tty/serial/msm_serial.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/tty/serial/msm_serial.txt b/Documentation/devicetree/bindings/tty/serial/msm_serial.txt new file mode 100644 index 0000000..aef383e --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/msm_serial.txt @@ -0,0 +1,27 @@ +* Qualcomm MSM UART + +Required properties: +- compatible : + - "qcom,msm-uart", and one of "qcom,msm-hsuart" or + "qcom,msm-lsuart". +- reg : offset and length of the register set for the device + for the hsuart operating in compatible mode, there should be a + second pair describing the gsbi registers. +- interrupts : should contain the uart interrupt. + +There are two different UART blocks used in MSM devices, +"qcom,msm-hsuart" and "qcom,msm-lsuart". The msm-serial driver is +able to handle both of these, and matches against the "qcom,msm-uart" +as the compatibility. + +The registers for the "qcom,msm-hsuart" device need to specify both +register blocks, even for the common driver. + +Example: + + uart@19c400000 { + compatible = "qcom,msm-hsuart", "qcom,msm-uart"; + reg = <0x19c40000 0x1000>, + <0x19c00000 0x1000>; + interrupts = <195>; + }; -- cgit v1.1 From eb2b8d4273fb8b73821ca8dbc9c0de10e9879833 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 18:58:42 +0000 Subject: DocBook/drm: , -> : Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 60ddf4b..953c4cb 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -389,7 +389,7 @@ If your driver supports memory management (it should!), you need to set that up at load time as well. How you initialize - it depends on which memory manager you're using, TTM or GEM. + it depends on which memory manager you're using: TTM or GEM. TTM initialization @@ -647,7 +647,7 @@ void intel_crt_init(struct drm_device *dev) The memory manager lies at the heart of many DRM operations; it is required to support advanced client features like OpenGL - pbuffers. The DRM currently contains two memory managers, TTM + pbuffers. The DRM currently contains two memory managers: TTM and GEM. -- cgit v1.1 From 005d7f4a01d3c755c3abab38b7e380f0bbff475d Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:02:52 +0000 Subject: DocBook/drm: Insert missing comma Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 953c4cb..230c738 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -429,7 +429,7 @@ object should be sizeof(struct ttm_mem_global), and the init and release hooks should point at your driver specific init and release routines, which probably eventually call - ttm_mem_global_init and ttm_mem_global_release respectively. + ttm_mem_global_init and ttm_mem_global_release, respectively. Once your global TTM accounting structure is set up and initialized @@ -499,8 +499,8 @@ Output discovery and initialization - Several core functions exist to create CRTCs, encoders and - connectors, namely drm_crtc_init(), drm_connector_init() and + Several core functions exist to create CRTCs, encoders, and + connectors, namely drm_crtc_init(), drm_connector_init(), and drm_encoder_init(), along with several "helper" functions to perform common tasks. @@ -578,7 +578,7 @@ void intel_crt_init(struct drm_device *dev) - For each encoder, CRTC and connector, several functions must + For each encoder, CRTC, and connector, several functions must be provided, depending on the object type. Encoder objects need to provide a DPMS (basically on/off) function, mode fixup (for converting requested modes into native hardware timings), @@ -727,7 +727,7 @@ void intel_crt_init(struct drm_device *dev) Output management At the core of the DRM output management code is a set of - structures representing CRTCs, encoders and connectors. + structures representing CRTCs, encoders, and connectors. A CRTC is an abstraction representing a part of the chip that -- cgit v1.1 From 1c86de2216f678bfb6e2472af6e5c25b0df8d91f Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:14:26 +0000 Subject: DocBook/drm: Remove parentheses and unnecessary repetition Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 230c738..6b2a803 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -433,8 +433,8 @@ Once your global TTM accounting structure is set up and initialized - (done by calling ttm_global_item_ref on the global object you - just created), you need to create a buffer object TTM to + by calling ttm_global_item_ref on it, + you need to create a buffer object TTM to provide a pool for buffer object allocation by clients and the kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct ttm_bo_global). Again, -- cgit v1.1 From ae63d793a43888eeb1c16422252d987aa37ab96c Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:19:18 +0000 Subject: DocBook/drm: Insert `()' after function name Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 6b2a803..6977cd9 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -433,15 +433,15 @@ Once your global TTM accounting structure is set up and initialized - by calling ttm_global_item_ref on it, + by calling ttm_global_item_ref() on it, you need to create a buffer object TTM to provide a pool for buffer object allocation by clients and the kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct ttm_bo_global). Again, driver specific init and release functions may be provided, - likely eventually calling ttm_bo_global_init and - ttm_bo_global_release, respectively. Also, like the previous - object, ttm_global_item_ref is used to create an initial reference + likely eventually calling ttm_bo_global_init() and + ttm_bo_global_release(), respectively. Also, like the previous + object, ttm_global_item_ref() is used to create an initial reference count for the TTM, which will call your initialization function. -- cgit v1.1 From 049cc903e714a27805eae0c34a4c34902a385032 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:21:17 +0000 Subject: DocBook/drm: Streamline wording of GEM initialization Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 6977cd9..7c11d79 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -451,7 +451,7 @@ GEM is an alternative to TTM, designed specifically for UMA devices. It has simpler initialization and execution requirements than TTM, but has no VRAM management capability. Core GEM - initialization is comprised of a basic drm_mm_init call to create + is initialized by calling drm_mm_init() to create a GTT DRM MM object, which provides an address space pool for object allocation. In a KMS configuration, the driver needs to allocate and initialize a command ring buffer following -- cgit v1.1 From 482b2ad8e488e609bb3bb408a8e9ca17b73b17c6 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:37:24 +0000 Subject: DocBook/drm: basic -> core Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 7c11d79..d385e90 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -455,7 +455,7 @@ a GTT DRM MM object, which provides an address space pool for object allocation. In a KMS configuration, the driver needs to allocate and initialize a command ring buffer following - basic GEM initialization. Most UMA devices have a so-called + core GEM initialization. Most UMA devices have a so-called "stolen" memory region, which provides space for the initial framebuffer and large, contiguous memory regions required by the device. This space is not typically managed by GEM, and must -- cgit v1.1 From 54f2cb8fc930e08fd6156519b28c45d576615f82 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:41:37 +0000 Subject: DocBook/drm: Use a singular subject for grammatical cleanliness Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index d385e90..3470c6b 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -455,7 +455,7 @@ a GTT DRM MM object, which provides an address space pool for object allocation. In a KMS configuration, the driver needs to allocate and initialize a command ring buffer following - core GEM initialization. Most UMA devices have a so-called + core GEM initialization. A UMA device usually has a so-called "stolen" memory region, which provides space for the initial framebuffer and large, contiguous memory regions required by the device. This space is not typically managed by GEM, and must @@ -635,10 +635,10 @@ void intel_crt_init(struct drm_device *dev) a client calls the vblank wait ioctl above. - Devices that don't provide a count register may simply use an + A device that doesn't provide a count register may simply use an internal atomic counter incremented on every vertical blank - interrupt, and can make their enable and disable vblank - functions into no-ops. + interrupt (and then treat the enable_vblank() and disable_vblank() + callbacks as no-ops). -- cgit v1.1 From 9029bd7a42e3c32783866630ee3eb6b82e273544 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:42:20 +0000 Subject: DocBook/drm: The word `so-called'; I do not think it connotes what you think it connotes From Webster's Revised Unabridged Dictionary (1913) [web1913]: So-called \So"-called`\, a. So named; called by such a name (but perhaps called thus with doubtful propriety). From WordNet (r) 2.0 [wn]: so-called adj : doubtful or suspect; "these so-called experts are no help" [syn: {alleged(a)}, {supposed}] My strong conviction is that widespread use of 'so gennant' or 'sogennant' in German has led to the creeping misuse of 'so-called' in English (especially through technical writings). In English, it would be better to use: what is called or a better translation of 'so gennant': so named Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 3470c6b..66a114a 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -455,7 +455,7 @@ a GTT DRM MM object, which provides an address space pool for object allocation. In a KMS configuration, the driver needs to allocate and initialize a command ring buffer following - core GEM initialization. A UMA device usually has a so-called + core GEM initialization. A UMA device usually has what is called a "stolen" memory region, which provides space for the initial framebuffer and large, contiguous memory regions required by the device. This space is not typically managed by GEM, and must -- cgit v1.1 From 1dbd39c3ea3967c41a09e81c826499f7ae9c8180 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:48:32 +0000 Subject: DocBook/drm: Insert `it' for smooth reading Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 66a114a..15541b1 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -458,7 +458,7 @@ core GEM initialization. A UMA device usually has what is called a "stolen" memory region, which provides space for the initial framebuffer and large, contiguous memory regions required by the - device. This space is not typically managed by GEM, and must + device. This space is not typically managed by GEM, and it must be initialized separately into its own DRM MM object. -- cgit v1.1 From 3bf7df615612671271512aada7d83285f3fa731b Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 19:49:10 +0000 Subject: DocBook/drm: Remove redundancy Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 15541b1..c24f50c 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -462,8 +462,7 @@ be initialized separately into its own DRM MM object. - Initialization is driver specific, and depends on - the architecture of the device. In the case of Intel + Initialization is driver specific. In the case of Intel integrated graphics chips like 965GM, GEM initialization can be done by calling the internal GEM init function, i915_gem_do_init(). Since the 965GM is a UMA device -- cgit v1.1 From 327d6fb962f227a31d4b03869774287efca49c50 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 20:18:14 +0000 Subject: DocBook/drm: Clarify `final initialization' via better formatting Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index c24f50c..1bbeea7 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -490,10 +490,19 @@ Output configuration - The final initialization task is output configuration. This involves - finding and initializing the CRTCs, encoders and connectors - for your device, creating an initial configuration and - registering a framebuffer console driver. + The final initialization task is output configuration. This involves: + + + Finding and initializing the CRTCs, encoders, and connectors + for the device. + + + Creating an initial configuration. + + + Registering a framebuffer console driver. + + Output discovery and initialization -- cgit v1.1 From 8a9ba910ac3962e5adb4ce1f086adf1e21fa04d1 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 20:21:22 +0000 Subject: DocBook/drm: Use a colon Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 1bbeea7..790e634 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -508,7 +508,7 @@ Output discovery and initialization Several core functions exist to create CRTCs, encoders, and - connectors, namely drm_crtc_init(), drm_connector_init(), and + connectors, namely: drm_crtc_init(), drm_connector_init(), and drm_encoder_init(), along with several "helper" functions to perform common tasks. -- cgit v1.1 From 896ee65fb646f9a98243a9f69e5904dff394c78a Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 20:26:17 +0000 Subject: DocBook/drm: Remove extraneous commas Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 790e634..d2aee84 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -562,9 +562,9 @@ void intel_crt_init(struct drm_device *dev) In the example above (again, taken from the i915 driver), a CRT connector and encoder combination is created. A device - specific i2c bus is also created, for fetching EDID data and + specific i2c bus is also created for fetching EDID data and performing monitor detection. Once the process is complete, - the new connector is registered with sysfs, to make its + the new connector is registered with sysfs to make its properties available to applications. -- cgit v1.1 From 4dc0152d5780f04573046b06a3fb7c7ad9b81afa Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 20:29:32 +0000 Subject: DocBook/drm: Insert `the' for readability, and change `set' to `setting' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index d2aee84..09e02f7 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -573,8 +573,8 @@ void intel_crt_init(struct drm_device *dev) Since many PC-class graphics devices have similar display output designs, the DRM provides a set of helper functions to make output management easier. The core helper routines handle - encoder re-routing and disabling of unused functions following - mode set. Using the helpers is optional, but recommended for + encoder re-routing and the disabling of unused functions following + mode setting. Using the helpers is optional, but recommended for devices with PC-style architectures (i.e. a set of display planes for feeding pixels to encoders which are in turn routed to connectors). Devices with more complex requirements needing -- cgit v1.1 From 65ffef508f23d5e67940cadc8eca2ae34738018a Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 20:55:58 +0000 Subject: DocBook/drm: Use an itemizedlist for what an encoder needs to provide Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 09e02f7..da011f2 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -586,17 +586,25 @@ void intel_crt_init(struct drm_device *dev) - For each encoder, CRTC, and connector, several functions must - be provided, depending on the object type. Encoder objects - need to provide a DPMS (basically on/off) function, mode fixup - (for converting requested modes into native hardware timings), - and prepare, set and commit functions for use by the core DRM - helper functions. Connector helpers need to provide mode fetch and - validity functions as well as an encoder matching function for - returning an ideal encoder for a given connector. The core - connector functions include a DPMS callback, (deprecated) - save/restore routines, detection, mode probing, property handling, - and cleanup functions. + Each encoder object needs to provide: + + + A DPMS (basically on/off) function. + + + A mode-fixup function (for converting requested modes into + native hardware timings). + + + Functions (prepare, set, and commit) for use by the core DRM + helper functions. + + + Connector helpers need to provide functions (mode-fetch, validity, + and encoder-matching) for returning an ideal encoder for a given + connector. The core connector functions include a DPMS callback, + save/restore routines (deprecated), detection, mode probing, + property handling, and cleanup functions. -- cgit v1.1 From 51b9500de28a1e5e7a2090de5d345d6d98581617 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 21:11:30 +0000 Subject: DocBook/drm: Use a for vblank ioctls Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index da011f2..457d56a 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -619,23 +619,34 @@ void intel_crt_init(struct drm_device *dev) VBlank event handling The DRM core exposes two vertical blank related ioctls: - DRM_IOCTL_WAIT_VBLANK and DRM_IOCTL_MODESET_CTL. + + + DRM_IOCTL_WAIT_VBLANK + + + This takes a struct drm_wait_vblank structure as its argument, + and it is used to block or request a signal when a specified + vblank event occurs. + + + + + DRM_IOCTL_MODESET_CTL + + + This should be called by application level drivers before and + after mode setting, since on many devices the vertical blank + counter is reset at that time. Internally, the DRM snapshots + the last vblank count when the ioctl is called with the + _DRM_PRE_MODESET command so that the counter won't go backwards + (which is dealt with when _DRM_POST_MODESET is used). + + + + - DRM_IOCTL_WAIT_VBLANK takes a struct drm_wait_vblank structure - as its argument, and is used to block or request a signal when a - specified vblank event occurs. - - - DRM_IOCTL_MODESET_CTL should be called by application level - drivers before and after mode setting, since on many devices, the - vertical blank counter is reset at that time. Internally, - the DRM snapshots the last vblank count when the ioctl is called - with the _DRM_PRE_MODESET command so that the counter won't go - backwards (which is dealt with when _DRM_POST_MODESET is used). - - To support the functions above, the DRM core provides several helper functions for tracking vertical blank counters, and requires drivers to provide several callbacks: -- cgit v1.1 From f877bd4ad5508e2f0653c31d05ffe0ad4e2bfe11 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Thu, 25 Aug 2011 21:16:15 +0000 Subject: DocBook/drm: Insert a comma Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 457d56a..0387970 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -638,7 +638,7 @@ void intel_crt_init(struct drm_device *dev) after mode setting, since on many devices the vertical blank counter is reset at that time. Internally, the DRM snapshots the last vblank count when the ioctl is called with the - _DRM_PRE_MODESET command so that the counter won't go backwards + _DRM_PRE_MODESET command, so that the counter won't go backwards (which is dealt with when _DRM_POST_MODESET is used). -- cgit v1.1 From 0c2d91a80a156208d2f9f3dfb01871ebcf4a9338 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 15:59:56 +0000 Subject: DocBook/drm: Use an for fundamental GEM operations Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 0387970..c358367 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -709,9 +709,13 @@ void intel_crt_init(struct drm_device *dev) read & write, mapping, and domain ownership transfers. - On a fundamental level, GEM involves several operations: memory - allocation and freeing, command execution, and aperture management - at command execution time. Buffer object allocation is relatively + On a fundamental level, GEM involves several operations: + + Memory allocation and freeing + Command execution + Aperture management at command execution time + + Buffer object allocation is relatively straightforward and largely provided by Linux's shmem layer, which provides memory to back each object. When mapped into the GTT or used in a command buffer, the backing pages for an object are -- cgit v1.1 From 2d43f5d667273ba4975cb79782a46aa374dd8607 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 16:00:55 +0000 Subject: DocBook/drm: Improve flow of GPU/CPU coherence sentence Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index c358367..ba20f9f 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -720,8 +720,9 @@ void intel_crt_init(struct drm_device *dev) provides memory to back each object. When mapped into the GTT or used in a command buffer, the backing pages for an object are flushed to memory and marked write combined so as to be coherent - with the GPU. Likewise, when the GPU finishes rendering to an object, - if the CPU accesses it, it must be made coherent with the CPU's view + with the GPU. Likewise, if the CPU accesses an object after the GPU + has finished rendering to the object, then the object must be made + coherent with the CPU's view of memory, usually involving GPU cache flushing of various kinds. This core CPU<->GPU coherency management is provided by the GEM set domain function, which evaluates an object's current domain and -- cgit v1.1 From b8c6e0fe46fcd60f58089365dd96dcf04f95263b Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 17:34:00 +0000 Subject: DocBook/drm: Refer to the domain-setting function as a device-specific ioctl Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ba20f9f..9ae328a 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -724,11 +724,11 @@ void intel_crt_init(struct drm_device *dev) has finished rendering to the object, then the object must be made coherent with the CPU's view of memory, usually involving GPU cache flushing of various kinds. - This core CPU<->GPU coherency management is provided by the GEM - set domain function, which evaluates an object's current domain and + This core CPU<->GPU coherency management is provided by a + device-specific ioctl, which evaluates an object's current domain and performs any necessary flushing or synchronization to put the object into the desired coherency domain (note that the object may be busy, - i.e. an active render target; in that case, the set domain function + i.e. an active render target; in that case, setting the domain blocks the client and waits for rendering to complete before performing any necessary flushing operations). -- cgit v1.1 From e355b2014da06458385902c47edf193a997895fc Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 17:38:48 +0000 Subject: DocBook/drm: Better flow with `, and then' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 9ae328a..0b6c59d 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -735,8 +735,8 @@ void intel_crt_init(struct drm_device *dev) Perhaps the most important GEM function is providing a command execution interface to clients. Client programs construct command - buffers containing references to previously allocated memory objects - and submit them to GEM. At that point, GEM takes care to bind + buffers containing references to previously allocated memory objects, + and then submit them to GEM. At that point, GEM takes care to bind all the objects into the GTT, execute the buffer, and provide necessary synchronization between clients accessing the same buffers. This often involves evicting some objects from the GTT and re-binding -- cgit v1.1 From 964d32dcbefcfda015bc33dc76414b05c6f512de Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 17:41:31 +0000 Subject: DocBook/drm: Use `; otherwise,' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 0b6c59d..606a989 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -743,7 +743,7 @@ void intel_crt_init(struct drm_device *dev) others (a fairly expensive operation), and providing relocation support which hides fixed GTT offsets from clients. Clients must take care not to submit command buffers that reference more objects - than can fit in the GTT or GEM will reject them and no rendering + than can fit in the GTT; otherwise, GEM will reject them and no rendering will occur. Similarly, if several objects in the buffer require fence registers to be allocated for correct rendering (e.g. 2D blits on pre-965 chips), care must be taken not to require more fence -- cgit v1.1 From 5a462d58c84a2f5ed161daced2c7df34357c6d3d Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 17:58:46 +0000 Subject: DocBook/drm: Clean up the paragraph on framebuffer objects Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 606a989..a39e76b 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -795,14 +795,12 @@ void intel_crt_init(struct drm_device *dev) Framebuffer management - In order to set a mode on a given CRTC, encoder and connector - configuration, clients need to provide a framebuffer object which - provides a source of pixels for the CRTC to deliver to the encoder(s) - and ultimately the connector(s) in the configuration. A framebuffer - is fundamentally a driver specific memory object, made into an opaque - handle by the DRM addfb function. Once an fb has been created this - way it can be passed to the KMS mode setting routines for use in - a configuration. + Clients need to provide a framebuffer object which provides a source + of pixels for a CRTC to deliver to the encoder(s) and ultimately the + connector(s). A framebuffer is fundamentally a driver specific memory + object, made into an opaque handle by the DRM's addfb() function. + Once a framebuffer has been created this way, it may be passed to the + KMS mode setting routines for use in a completed configuration. -- cgit v1.1 From a5294e01f2777649834d218583e7a32b2dacb699 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 18:05:52 +0000 Subject: DocBook/drm: `(device|driver) specific' -> `(device|driver)-specific' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index a39e76b..65e14f9 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -238,7 +238,7 @@ In this specific case, the driver requires AGP and supports - IRQs. DMA, as discussed later, is handled by device specific ioctls + IRQs. DMA, as discussed later, is handled by device-specific ioctls in this case. It also supports the kernel mode setting APIs, though unlike in the actual i915 driver source, this example unconditionally exports KMS capability. @@ -277,7 +277,7 @@ to perform output discovery & configuration at load time. Likewise, if user-level drivers unaware of memory management are in use, memory management and command buffer setup may need to - be omitted. These requirements are driver specific, and care + be omitted. These requirements are driver-specific, and care needs to be taken to keep both old and new applications and libraries working. The i915 driver supports the "modeset" module parameter to control whether advanced features are @@ -288,7 +288,7 @@ Driver private & performance counters The driver private hangs off the main drm_device structure and - can be used for tracking various device specific bits of + can be used for tracking various device-specific bits of information, like register offsets, command buffer status, register state for suspend/resume, etc. At load time, a driver may simply allocate one and set drm_device.dev_priv @@ -313,7 +313,7 @@ Configuring the device - Obviously, device configuration is device specific. + Obviously, device configuration is device-specific. However, there are several common operations: finding a device's PCI resources, mapping them, and potentially setting up an IRQ handler. @@ -340,8 +340,8 @@ Once you have a register map, you may use the DRM_READn() and DRM_WRITEn() macros to access the registers on your device, or - use driver specific versions to offset into your MMIO space - relative to a driver specific base pointer (see I915_READ for + use driver-specific versions to offset into your MMIO space + relative to a driver-specific base pointer (see I915_READ for an example). @@ -399,7 +399,7 @@ and devices with dedicated video RAM (VRAM), i.e. most discrete graphics devices. If your device has dedicated RAM, supporting TTM is desirable. TTM also integrates tightly with your - driver specific buffer execution function. See the radeon + driver-specific buffer execution function. See the radeon driver for examples. @@ -427,7 +427,7 @@ created by the memory manager at runtime. Your global TTM should have a type of TTM_GLOBAL_TTM_MEM. The size field for the global object should be sizeof(struct ttm_mem_global), and the init and - release hooks should point at your driver specific init and + release hooks should point at your driver-specific init and release routines, which probably eventually call ttm_mem_global_init and ttm_mem_global_release, respectively. @@ -438,7 +438,7 @@ provide a pool for buffer object allocation by clients and the kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct ttm_bo_global). Again, - driver specific init and release functions may be provided, + driver-specific init and release functions may be provided, likely eventually calling ttm_bo_global_init() and ttm_bo_global_release(), respectively. Also, like the previous object, ttm_global_item_ref() is used to create an initial reference @@ -462,7 +462,7 @@ be initialized separately into its own DRM MM object. - Initialization is driver specific. In the case of Intel + Initialization is driver-specific. In the case of Intel integrated graphics chips like 965GM, GEM initialization can be done by calling the internal GEM init function, i915_gem_do_init(). Since the 965GM is a UMA device @@ -561,8 +561,8 @@ void intel_crt_init(struct drm_device *dev) In the example above (again, taken from the i915 driver), a - CRT connector and encoder combination is created. A device - specific i2c bus is also created for fetching EDID data and + CRT connector and encoder combination is created. A device-specific + i2c bus is also created for fetching EDID data and performing monitor detection. Once the process is complete, the new connector is registered with sysfs to make its properties available to applications. @@ -704,8 +704,8 @@ void intel_crt_init(struct drm_device *dev) GEM-enabled drivers must provide gem_init_object() and gem_free_object() callbacks to support the core memory - allocation routines. They should also provide several driver - specific ioctls to support command execution, pinning, buffer + allocation routines. They should also provide several driver-specific + ioctls to support command execution, pinning, buffer read & write, mapping, and domain ownership transfers. @@ -797,7 +797,7 @@ void intel_crt_init(struct drm_device *dev) Clients need to provide a framebuffer object which provides a source of pixels for a CRTC to deliver to the encoder(s) and ultimately the - connector(s). A framebuffer is fundamentally a driver specific memory + connector(s). A framebuffer is fundamentally a driver-specific memory object, made into an opaque handle by the DRM's addfb() function. Once a framebuffer has been created this way, it may be passed to the KMS mode setting routines for use in a completed configuration. @@ -807,7 +807,7 @@ void intel_crt_init(struct drm_device *dev) Command submission & fencing - This should cover a few device specific command submission + This should cover a few device-specific command submission implementations. @@ -840,7 +840,7 @@ void intel_crt_init(struct drm_device *dev) The DRM core exports several interfaces to applications, generally intended to be used through corresponding libdrm - wrapper functions. In addition, drivers export device specific + wrapper functions. In addition, drivers export device-specific interfaces for use by userspace drivers & device aware applications through ioctls and sysfs files. -- cgit v1.1 From 7f0925aca586b4a0cce81b06af7383d6aec59cc1 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 18:07:13 +0000 Subject: DocBook/drm: `device aware' -> `device-aware' Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 65e14f9..9da9b28 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -841,7 +841,7 @@ void intel_crt_init(struct drm_device *dev) The DRM core exports several interfaces to applications, generally intended to be used through corresponding libdrm wrapper functions. In addition, drivers export device-specific - interfaces for use by userspace drivers & device aware + interfaces for use by userspace drivers & device-aware applications through ioctls and sysfs files. -- cgit v1.1 From bcd3cfc1213894ff955771508d46fa18d66e9328 Mon Sep 17 00:00:00 2001 From: Michael Witten Date: Mon, 29 Aug 2011 19:29:16 +0000 Subject: DocBook/drm: Clean up a todo-note Signed-off-by: Michael Witten --- Documentation/DocBook/drm.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 9da9b28..196b8b9 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -850,8 +850,8 @@ void intel_crt_init(struct drm_device *dev) management, memory management, and output management. - Cover generic ioctls and sysfs layout here. Only need high - level info, since man pages should cover the rest. + Cover generic ioctls and sysfs layout here. We only need high-level + info, since man pages should cover the rest. -- cgit v1.1 From 56889787cfa77dfd96f0b3a3e6a4f26c2e4a5134 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o Date: Sat, 3 Sep 2011 18:22:38 -0400 Subject: ext4: improve handling of conflicting mount options If the user explicitly specifies conflicting mount options for delalloc or dioread_nolock and data=journal, fail the mount, instead of printing a warning and continuing (since many user's won't look at dmesg and notice the warning). Also, print a single warning that data=journal implies that delayed allocation is not on by default (since it's not supported), and furthermore that O_DIRECT is not supported. Improve the text in Documentation/filesystems/ext4.txt so this is clear there as well. Similarly, if the dioread_nolock mount option is specified when the file system block size != PAGE_SIZE, fail the mount instead of printing a warning message and ignoring the mount option. Signed-off-by: "Theodore Ts'o" --- Documentation/filesystems/ext4.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 232a575..168242b 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -160,7 +160,9 @@ noload if the filesystem was not unmounted cleanly, lead to any number of problems. data=journal All data are committed into the journal prior to being - written into the main file system. + written into the main file system. Enabling + this mode will disable delayed allocation and + O_DIRECT support. data=ordered (*) All data are forced directly out to the main file system prior to its metadata being committed to the @@ -419,8 +421,8 @@ written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it -outperforms all others modes. Currently ext4 does not have delayed -allocation support if this data journalling mode is selected. +outperforms all others modes. Enabling this mode will disable delayed +allocation and O_DIRECT support. /proc entries ============= -- cgit v1.1 From a40f73419f02e40555f692785ea1c1813d5b4c12 Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 31 May 2011 16:31:22 -0700 Subject: mtd: nand: consolidate redundant flash-based BBT flags This patch works with the following three flags from two headers (nand.h and bbm.h): (1) NAND_USE_FLASH_BBT (nand.h) (2) NAND_USE_FLASH_BBT_NO_OOB (nand.h) (3) NAND_BBT_NO_OOB (bbm.h) These flags are all related and interdependent, yet they were in different headers. Flag (2) is simply the combination of (1) and (3) and can be eliminated. This patch accomplishes the following: * eliminate NAND_USE_FLASH_BBT_NO_OOB (i.e., flag (2)) * move NAND_USE_FLASH_BBT (i.e., flag (1)) to bbm.h It's important to note that because (1) and (3) are now both found in bbm.h, they should NOT be used in the "nand_chip.options" field. I removed a small section from the mtdnand DocBook because it referes to NAND_USE_FLASH_BBT in nand.h, which has been moved to bbm.h. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy --- Documentation/DocBook/mtdnand.tmpl | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 17910e2..05cc83e 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -572,7 +572,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) The simplest way to activate the FLASH based bad block table support - is to set the option NAND_USE_FLASH_BBT in the option field of + is to set the option NAND_USE_FLASH_BBT in the bbt_option field of the nand chip structure before calling nand_scan(). For AG-AND chips is this done by default. This activates the default FLASH based bad block table functionality @@ -1158,9 +1158,6 @@ in this page These constants are defined in nand.h. They are ored together to describe the functionality. -/* Use a flash based bad block table. This option is parsed by the - * default bad block table function (nand_default_bbt). */ -#define NAND_USE_FLASH_BBT 0x00010000 /* The hw ecc generator provides a syndrome instead a ecc value on read * This can only work if we have the ecc bytes directly behind the * data bytes. Applies for DOC and AG-AND Renesas HW Reed Solomon generators */ -- cgit v1.1 From bb9ebd4e714385a2592a482845865ef2d58b2868 Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 31 May 2011 16:31:23 -0700 Subject: mtd: nand: rename NAND_USE_FLASH_BBT Recall the recently added prefix requirements: * "NAND_" for flags in nand.h, used in nand_chip.options * "NAND_BBT_" for flags in bbm.h, used in nand_chip.bbt_options or in nand_bbt_descr.options Thus, I am changing NAND_USE_FLASH_BBT to NAND_BBT_USE_FLASH. Again, this flag is found in bbm.h and so should NOT be used in the "nand_chip.options" field. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy --- Documentation/DocBook/mtdnand.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 05cc83e..8c07540c 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -572,7 +572,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) The simplest way to activate the FLASH based bad block table support - is to set the option NAND_USE_FLASH_BBT in the bbt_option field of + is to set the option NAND_BBT_USE_FLASH in the bbt_option field of the nand chip structure before calling nand_scan(). For AG-AND chips is this done by default. This activates the default FLASH based bad block table functionality -- cgit v1.1 From b94e757c4b3aafa52f8b82efed8660427a8d2880 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Fri, 15 Jul 2011 16:38:56 +0800 Subject: mtd: dataflash: add device tree probe support It adds device tree probe support for mtd_dataflash driver. Signed-off-by: Shawn Guo Signed-off-by: Artem Bityutskiy --- Documentation/devicetree/bindings/mtd/atmel-dataflash.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/atmel-dataflash.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt b/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt new file mode 100644 index 0000000..ef66ddd --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt @@ -0,0 +1,14 @@ +* Atmel Data Flash + +Required properties: +- compatible : "atmel,", "atmel,", "atmel,dataflash". + +Example: + +flash@1 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash"; + spi-max-frequency = <25000000>; + reg = <1>; +}; -- cgit v1.1 From 48ee688df09fa3ddf86b5b53508316d18d6fcedd Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 23 Aug 2011 17:17:33 -0700 Subject: mtd: doc: remove mention of MEMSETOOBSEL It's been gone for a while. Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy --- Documentation/DocBook/mtdnand.tmpl | 14 -------------- 1 file changed, 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 8c07540c..0c674be 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -773,20 +773,6 @@ struct nand_oobinfo { done according to the default builtin scheme. - - User space placement selection - - All non ecc functions like mtd->read and mtd->write use an internal - structure, which can be set by an ioctl. This structure is preset - to the autoplacement default. - - ioctl (fd, MEMSETOOBSEL, oobsel); - - oobsel is a pointer to a user supplied structure of type - nand_oobconfig. The contents of this structure must match the - criteria of the filesystem, which will be used. See an example in utils/nandwrite.c. - - Spare area autoplacement default schemes -- cgit v1.1 From dfcd04b19d16c0016c705ed96a8b3cfa5315a2e9 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Thu, 8 Sep 2011 15:09:35 +0800 Subject: i2c-imx: add device tree probe support It adds device tree probe support for i2c-imx driver. Signed-off-by: Shawn Guo Cc: Grant Likely Cc: Darius Augulis Cc: Ben Dooks Acked-by: Grant Likely Signed-off-by: Ben Dooks --- .../devicetree/bindings/i2c/fsl-imx-i2c.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt b/Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt new file mode 100644 index 0000000..f3cf43b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt @@ -0,0 +1,25 @@ +* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX + +Required properties: +- compatible : Should be "fsl,-i2c" +- reg : Should contain I2C/HS-I2C registers location and length +- interrupts : Should contain I2C/HS-I2C interrupt + +Optional properties: +- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. + The absence of the propoerty indicates the default frequency 100 kHz. + +Examples: + +i2c@83fc4000 { /* I2C2 on i.MX51 */ + compatible = "fsl,imx51-i2c", "fsl,imx1-i2c"; + reg = <0x83fc4000 0x4000>; + interrupts = <63>; +}; + +i2c@70038000 { /* HS-I2C on i.MX51 */ + compatible = "fsl,imx51-i2c", "fsl,imx1-i2c"; + reg = <0x70038000 0x4000>; + interrupts = <64>; + clock-frequency = <400000>; +}; -- cgit v1.1 From e467b6421435f467e274d4f25d62900e1e0e4286 Mon Sep 17 00:00:00 2001 From: Ohad Ben-Cohen Date: Mon, 5 Sep 2011 16:42:36 +0300 Subject: hwspinlock/core: simplify 'owner' handling Use struct device_driver's owner member instead of asking drivers to explicitly pass the owner again. This simplifies drivers and also save some memory, since there's no point now in maintaining a separate owner pointer per hwspinlock. Signed-off-by: Ohad Ben-Cohen --- Documentation/hwspinlock.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index 7dcd1a4..bbaa464 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt @@ -256,18 +256,16 @@ underlying hwspinlock implementation using the hwspin_lock_register() API. * @ops: vendor-specific hwspinlock handlers * @id: a global, unique, system-wide, index of the lock. * @lock: initialized and used by hwspinlock core - * @owner: underlying implementation module, used to maintain module ref count */ struct hwspinlock { struct device *dev; const struct hwspinlock_ops *ops; int id; spinlock_t lock; - struct module *owner; }; -The underlying implementation is responsible to assign the dev, ops, id and -owner members. The lock member, OTOH, is initialized and used by the hwspinlock +The underlying implementation is responsible to assign the dev, ops and id +members. The lock member, OTOH, is initialized and used by the hwspinlock core. 6. Implementation callbacks -- cgit v1.1 From 93b465c2e186d96fb90012ba0f9372eb9952e732 Mon Sep 17 00:00:00 2001 From: Juan Gutierrez Date: Tue, 6 Sep 2011 09:30:16 +0300 Subject: hwspinlock/core: use a mutex to protect the radix tree Since we're using non-atomic radix tree allocations, we should be protecting the tree using a mutex and not a spinlock. Non-atomic allocations and process context locking is good enough, as the tree is manipulated only when locks are registered/ unregistered/requested/freed. The locks themselves are still protected by spinlocks of course, and mutexes are not involved in the locking/unlocking paths. Cc: Signed-off-by: Juan Gutierrez [ohad@wizery.com: rewrite the commit log, #include mutex.h, add minor commentary] [ohad@wizery.com: update register/unregister parts in hwspinlock.txt] Signed-off-by: Ohad Ben-Cohen --- Documentation/hwspinlock.txt | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index bbaa464..9171f91 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt @@ -39,23 +39,20 @@ independent, drivers. in case an unused hwspinlock isn't available. Users of this API will usually want to communicate the lock's id to the remote core before it can be used to achieve synchronization. - Can be called from an atomic context (this function will not sleep) but - not from within interrupt context. + Should be called from a process context (might sleep). struct hwspinlock *hwspin_lock_request_specific(unsigned int id); - assign a specific hwspinlock id and return its address, or NULL if that hwspinlock is already in use. Usually board code will be calling this function in order to reserve specific hwspinlock ids for predefined purposes. - Can be called from an atomic context (this function will not sleep) but - not from within interrupt context. + Should be called from a process context (might sleep). int hwspin_lock_free(struct hwspinlock *hwlock); - free a previously-assigned hwspinlock; returns 0 on success, or an appropriate error code on failure (e.g. -EINVAL if the hwspinlock is already free). - Can be called from an atomic context (this function will not sleep) but - not from within interrupt context. + Should be called from a process context (might sleep). int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int timeout); - lock a previously-assigned hwspinlock with a timeout limit (specified in @@ -232,15 +229,14 @@ int hwspinlock_example2(void) int hwspin_lock_register(struct hwspinlock *hwlock); - to be called from the underlying platform-specific implementation, in - order to register a new hwspinlock instance. Can be called from an atomic - context (this function will not sleep) but not from within interrupt - context. Returns 0 on success, or appropriate error code on failure. + order to register a new hwspinlock instance. Should be called from + a process context (this function might sleep). + Returns 0 on success, or appropriate error code on failure. struct hwspinlock *hwspin_lock_unregister(unsigned int id); - to be called from the underlying vendor-specific implementation, in order to unregister an existing (and unused) hwspinlock instance. - Can be called from an atomic context (will not sleep) but not from - within interrupt context. + Should be called from a process context (this function might sleep). Returns the address of hwspinlock on success, or NULL on error (e.g. if the hwspinlock is sill in use). -- cgit v1.1 From 300bab9770e2bd10262bcc78e7249fdce2c74b38 Mon Sep 17 00:00:00 2001 From: Ohad Ben-Cohen Date: Tue, 6 Sep 2011 15:39:21 +0300 Subject: hwspinlock/core: register a bank of hwspinlocks in a single API call Hardware Spinlock devices usually contain numerous locks (known devices today support between 32 to 256 locks). Originally hwspinlock core required drivers to register (and later, when needed, unregister) each lock separately. That worked, but required hwspinlocks drivers to do a bit extra work when they were probed/removed. This patch changes hwspin_lock_{un}register() to allow a bank of hwspinlocks to be {un}registered in a single invocation. A new 'struct hwspinlock_device', which contains an array of 'struct hwspinlock's is now being passed to the core upon registration (so instead of wrapping each struct hwspinlock, a priv member has been added to allow drivers to piggyback their private data with each hwspinlock). While at it, several per-lock members were moved to be per-device: 1. struct device *dev 2. struct hwspinlock_ops *ops In addition, now that the array of locks is handled by the core, there's no reason to maintain a per-lock 'int id' member: the id of the lock anyway equals to its index in the bank's array plus the bank's base_id. Remove this per-lock id member too, and instead use a simple pointers arithmetic to derive it. As a result of this change, hwspinlocks drivers are now simpler and smaller (about %20 code reduction) and the memory footprint of the hwspinlock framework is reduced. Signed-off-by: Ohad Ben-Cohen --- Documentation/hwspinlock.txt | 58 +++++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index 9171f91..a903ee5 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt @@ -227,42 +227,62 @@ int hwspinlock_example2(void) 4. API for implementors - int hwspin_lock_register(struct hwspinlock *hwlock); + int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev, + const struct hwspinlock_ops *ops, int base_id, int num_locks); - to be called from the underlying platform-specific implementation, in - order to register a new hwspinlock instance. Should be called from - a process context (this function might sleep). + order to register a new hwspinlock device (which is usually a bank of + numerous locks). Should be called from a process context (this function + might sleep). Returns 0 on success, or appropriate error code on failure. - struct hwspinlock *hwspin_lock_unregister(unsigned int id); + int hwspin_lock_unregister(struct hwspinlock_device *bank); - to be called from the underlying vendor-specific implementation, in order - to unregister an existing (and unused) hwspinlock instance. + to unregister an hwspinlock device (which is usually a bank of numerous + locks). Should be called from a process context (this function might sleep). Returns the address of hwspinlock on success, or NULL on error (e.g. if the hwspinlock is sill in use). -5. struct hwspinlock +5. Important structs -This struct represents an hwspinlock instance. It is registered by the -underlying hwspinlock implementation using the hwspin_lock_register() API. +struct hwspinlock_device is a device which usually contains a bank +of hardware locks. It is registered by the underlying hwspinlock +implementation using the hwspin_lock_register() API. /** - * struct hwspinlock - vendor-specific hwspinlock implementation - * - * @dev: underlying device, will be used with runtime PM api - * @ops: vendor-specific hwspinlock handlers - * @id: a global, unique, system-wide, index of the lock. - * @lock: initialized and used by hwspinlock core + * struct hwspinlock_device - a device which usually spans numerous hwspinlocks + * @dev: underlying device, will be used to invoke runtime PM api + * @ops: platform-specific hwspinlock handlers + * @base_id: id index of the first lock in this device + * @num_locks: number of locks in this device + * @lock: dynamically allocated array of 'struct hwspinlock' */ -struct hwspinlock { +struct hwspinlock_device { struct device *dev; const struct hwspinlock_ops *ops; - int id; + int base_id; + int num_locks; + struct hwspinlock lock[0]; +}; + +struct hwspinlock_device contains an array of hwspinlock structs, each +of which represents a single hardware lock: + +/** + * struct hwspinlock - this struct represents a single hwspinlock instance + * @bank: the hwspinlock_device structure which owns this lock + * @lock: initialized and used by hwspinlock core + * @priv: private data, owned by the underlying platform-specific hwspinlock drv + */ +struct hwspinlock { + struct hwspinlock_device *bank; spinlock_t lock; + void *priv; }; -The underlying implementation is responsible to assign the dev, ops and id -members. The lock member, OTOH, is initialized and used by the hwspinlock -core. +When registering a bank of locks, the hwspinlock driver only needs to +set the priv members of the locks. The rest of the members are set and +initialized by the hwspinlock core itself. 6. Implementation callbacks -- cgit v1.1 From af75655c066621352c419646ec0775e9523dc720 Mon Sep 17 00:00:00 2001 From: Jamie Iles Date: Mon, 25 Jul 2011 17:36:42 +0100 Subject: picoxcell: support for Picochip picoxcell devices picoXcell is a family of femtocell devices with an ARM application processor and picoArray DSP processor array. This patch adds support for picoXcell boards to be booted using the device tree registering the VIC's, UART's and timers. v3: - fixup vic compatible string in binding v2: - cleanup empty mach headers - convert to of_platform_populate() - simplify uncompress.h - split vic node into 2 devices - add missing __initconst attributes Signed-off-by: Jamie Iles --- .../devicetree/bindings/arm/picoxcell.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/picoxcell.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/picoxcell.txt b/Documentation/devicetree/bindings/arm/picoxcell.txt new file mode 100644 index 0000000..e75c0ef --- /dev/null +++ b/Documentation/devicetree/bindings/arm/picoxcell.txt @@ -0,0 +1,24 @@ +Picochip picoXcell device tree bindings. +======================================== + +Required root node properties: + - compatible: + - "picochip,pc7302-pc3x3" : PC7302 development board with PC3X3 device. + - "picochip,pc7302-pc3x2" : PC7302 development board with PC3X2 device. + - "picochip,pc3x3" : picoXcell PC3X3 device based board. + - "picochip,pc3x2" : picoXcell PC3X2 device based board. + +Timers required properties: + - compatible = "picochip,pc3x2-timer" + - interrupts : The single IRQ line for the timer. + - clock-freq : The frequency in HZ of the timer. + - reg : The register bank for the timer. + +Note: two timers are required - one for the scheduler clock and one for the +event tick/NOHZ. + +VIC required properties: + - compatible = "arm,pl192-vic". + - interrupt-controller. + - reg : The register bank for the device. + - #interrupt-cells : Must be 1. -- cgit v1.1 From dc2d07ebaea839a6e0fa47588c7984931f3c9c71 Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Wed, 10 Aug 2011 13:32:08 +0200 Subject: ARM: OMAP: omap_device: Add a method to build an omap_device from a DT node Add a notifier called during device_add phase. If an of_node is present, retrieve the hwmod entry in order to populate properly the omap_device structure. For the moment the resource from the device-tree are overloaded. DT does not support named resource yet, and thus, most driver will not work without that information. Add a documentation to capture the specifics OMAP bindings needed for device-tree support. Signed-off-by: Benoit Cousson Cc: Grant Likely Signed-off-by: Kevin Hilman --- .../devicetree/bindings/arm/omap/omap.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/omap.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt new file mode 100644 index 0000000..dbdab40 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -0,0 +1,43 @@ +* Texas Instruments OMAP + +OMAP is currently using a static file per SoC family to describe the +IPs present in the SoC. +On top of that an omap_device is created to extend the platform_device +capabilities and to allow binding with one or several hwmods. +The hwmods will contain all the information to build the device: +adresse range, irq lines, dma lines, interconnect, PRCM register, +clock domain, input clocks. +For the moment just point to the existing hwmod, the next step will be +to move data from hwmod to device-tree representation. + + +Required properties: +- compatible: Every devices present in OMAP SoC should be in the + form: "ti,XXX" +- ti,hwmods: list of hwmod names (ascii strings), that comes from the OMAP + HW documentation, attached to a device. Must contain at least + one hwmod. + +Optional properties: +- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module + during suspend. + + +Example: + +spinlock@1 { + compatible = "ti,omap4-spinlock"; + ti,hwmods = "spinlock"; +}; + + +Boards: + +- OMAP3 BeagleBoard : Low cost community board + compatible = "ti,omap3-beagle", "ti,omap3" + +- OMAP4 SDP : Software Developement Board + compatible = "ti,omap4-sdp", "ti,omap4430" + +- OMAP4 PandaBoard : Low cost community board + compatible = "ti,omap4-panda", "ti,omap4430" -- cgit v1.1 From d039c5b9fb2315ef942944439da6f0fbaf2f1941 Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Fri, 12 Aug 2011 13:52:50 +0200 Subject: ARM: OMAP2+: l3-noc: Add support for device-tree Add device-tree support for the l3-noc driver. Use platform_driver_register to defer the probing at device init time. Add documentation for the l3-noc bindings. Signed-off-by: Benoit Cousson Cc: Tony Lindgren Cc: Santosh Shilimkar --- Documentation/devicetree/bindings/arm/omap/l3-noc.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/l3-noc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt new file mode 100644 index 0000000..6888a5e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -0,0 +1,19 @@ +* TI - L3 Network On Chip (NoC) + +This version is an implementation of the generic NoC IP +provided by Arteris. + +Required properties: +- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family + Should be "ti,omap4-l3-noc" for OMAP4 family +- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain. + +Examples: + +ocp { + compatible = "ti,omap4-l3-noc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3"; +}; -- cgit v1.1 From 476b679a5d785d1244f6b43ad26877acf278cd18 Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Tue, 16 Aug 2011 11:49:08 +0200 Subject: arm/dts: OMAP3+: Add mpu, dsp and iva nodes Add nodes for devices used by PM code (mpu, dsp, iva). Add a cpus node as well as recommended in the DT spec. Remove mpu, dsp, iva devices init if is populated. Signed-off-by: Benoit Cousson Acked-by: Grant Likely Cc: Kevin Hilman --- Documentation/devicetree/bindings/arm/omap/dsp.txt | 14 +++++++++++ Documentation/devicetree/bindings/arm/omap/iva.txt | 19 +++++++++++++++ Documentation/devicetree/bindings/arm/omap/mpu.txt | 27 ++++++++++++++++++++++ 3 files changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dsp.txt create mode 100644 Documentation/devicetree/bindings/arm/omap/iva.txt create mode 100644 Documentation/devicetree/bindings/arm/omap/mpu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/dsp.txt b/Documentation/devicetree/bindings/arm/omap/dsp.txt new file mode 100644 index 0000000..d3830a3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/dsp.txt @@ -0,0 +1,14 @@ +* TI - DSP (Digital Signal Processor) + +TI DSP included in OMAP SoC + +Required properties: +- compatible : Should be "ti,omap3-c64" for OMAP3 & 4 +- ti,hwmods: "dsp" + +Examples: + +dsp { + compatible = "ti,omap3-c64"; + ti,hwmods = "dsp"; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/iva.txt b/Documentation/devicetree/bindings/arm/omap/iva.txt new file mode 100644 index 0000000..6d62951 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/iva.txt @@ -0,0 +1,19 @@ +* TI - IVA (Imaging and Video Accelerator) subsystem + +The IVA contain various audio, video or imaging HW accelerator +depending of the version. + +Required properties: +- compatible : Should be: + - "ti,ivahd" for OMAP4 + - "ti,iva2.2" for OMAP3 + - "ti,iva2.1" for OMAP2430 + - "ti,iva1" for OMAP2420 +- ti,hwmods: "iva" + +Examples: + +iva { + compatible = "ti,ivahd", "ti,iva"; + ti,hwmods = "iva"; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/mpu.txt b/Documentation/devicetree/bindings/arm/omap/mpu.txt new file mode 100644 index 0000000..1a5a42c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/mpu.txt @@ -0,0 +1,27 @@ +* TI - MPU (Main Processor Unit) subsystem + +The MPU subsystem contain one or several ARM cores +depending of the version. +The MPU contain CPUs, GIC, L2 cache and a local PRCM. + +Required properties: +- compatible : Should be "ti,omap3-mpu" for OMAP3 + Should be "ti,omap4-mpu" for OMAP4 +- ti,hwmods: "mpu" + +Examples: + +- For an OMAP4 SMP system: + +mpu { + compatible = "ti,omap4-mpu"; + ti,hwmods = "mpu"; +}; + + +- For an OMAP3 monocore system: + +mpu { + compatible = "ti,omap3-mpu"; + ti,hwmods = "mpu"; +}; -- cgit v1.1 From 2c1ba398ac9da3305815f6ae8e95ae2b9fd3b5ff Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 8 Sep 2011 10:37:31 -0700 Subject: regulator: Fix some bitrot in the machine driver documentation The documentation for the machine driver was rather badly bitrotted, using pointers to struct device rather than dev_name() to hook up the consumers. Update to use dev_name(). Reported-by: Philip Rakity Signed-off-by: Mark Brown --- Documentation/power/regulator/machine.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index b42419b..311c61f 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt @@ -16,7 +16,7 @@ initialisation code by creating a struct regulator_consumer_supply for each regulator. struct regulator_consumer_supply { - struct device *dev; /* consumer */ + const char *dev_name; /* consumer dev_name() */ const char *supply; /* consumer supply - e.g. "vcc" */ }; @@ -24,13 +24,13 @@ e.g. for the machine above static struct regulator_consumer_supply regulator1_consumers[] = { { - .dev = &platform_consumerB_device.dev, - .supply = "Vcc", + .dev_name = "dev_name(consumer B)", + .supply = "Vcc", },}; static struct regulator_consumer_supply regulator2_consumers[] = { { - .dev = &platform_consumerA_device.dev, + .dev = "dev_name(consumer A"), .supply = "Vcc", },}; -- cgit v1.1 From c3035a232e87f42b81d8ece1980abd0a2f26d792 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 8 Sep 2011 10:38:59 -0700 Subject: regulator: Clarify documentation for regulator-regulator supplies The mechanism used for connecting regulators together when one regulator supplies another wasn't clear as the names being used weren't really tied together well. Reported-by: Philip Rakity Signed-off-by: Mark Brown --- Documentation/power/regulator/machine.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index 311c61f..ce63af0 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt @@ -43,6 +43,7 @@ to their supply regulator :- static struct regulator_init_data regulator1_data = { .constraints = { + .name = "Regulator-1", .min_uV = 3300000, .max_uV = 3300000, .valid_modes_mask = REGULATOR_MODE_NORMAL, @@ -51,13 +52,19 @@ static struct regulator_init_data regulator1_data = { .consumer_supplies = regulator1_consumers, }; +The name field should be set to something that is usefully descriptive +for the board for configuration of supplies for other regulators and +for use in logging and other diagnostic output. Normally the name +used for the supply rail in the schematic is a good choice. If no +name is provided then the subsystem will choose one. + Regulator-1 supplies power to Regulator-2. This relationship must be registered with the core so that Regulator-1 is also enabled when Consumer A enables its supply (Regulator-2). The supply regulator is set by the supply_regulator -field below:- +field below and co:- static struct regulator_init_data regulator2_data = { - .supply_regulator = "regulator_name", + .supply_regulator = "Regulator-1", .constraints = { .min_uV = 1800000, .max_uV = 2000000, -- cgit v1.1 From af909a57fde821627282204ba43f27331342bf26 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o Date: Sat, 8 Oct 2011 14:01:08 -0400 Subject: ext4: documentation: remove acl and user_xattr mount options Acl and user_xattr mount options are no longer needed since those features are enabled by default if configured in (seee commit ea6633369458992241599c9d9ebadffaeddec164). We can not easily deprecate mount options itself (since it is probably too early), but we can remove it from documentation first. Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" --- Documentation/filesystems/ext4.txt | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 168242b..a530401 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -211,22 +211,19 @@ oldalloc This disables the Orlov block allocator and enables performance - we'd like to get some feedback if it's the contrary for you. -user_xattr Enables Extended User Attributes. Additionally, you - need to have extended attribute support enabled in the - kernel configuration (CONFIG_EXT4_FS_XATTR). See the - attr(5) manual page and http://acl.bestbits.at/ to - learn more about extended attributes. - -nouser_xattr Disables Extended User Attributes. - -acl Enables POSIX Access Control Lists support. - Additionally, you need to have ACL support enabled in - the kernel configuration (CONFIG_EXT4_FS_POSIX_ACL). - See the acl(5) manual page and http://acl.bestbits.at/ - for more information. +nouser_xattr Disables Extended User Attributes. If you have extended + attribute support enabled in the kernel configuration + (CONFIG_EXT4_FS_XATTR), extended attribute support + is enabled by default on mount. See the attr(5) manual + page and http://acl.bestbits.at/ for more information + about extended attributes. noacl This option disables POSIX Access Control List - support. + support. If ACL support is enabled in the kernel + configuration (CONFIG_EXT4_FS_POSIX_ACL), ACL is + enabled by default on mount. See the acl(5) manual + page and http://acl.bestbits.at/ for more information + about acl. bsddf (*) Make 'df' act like BSD. minixdf Make 'df' act like Minix. -- cgit v1.1 From 4113c4caa4f355b8ff8b7ff0510c29c9d00d30b3 Mon Sep 17 00:00:00 2001 From: Lukas Czerner Date: Sat, 8 Oct 2011 14:34:47 -0400 Subject: ext4: remove deprecated oldalloc For a long time now orlov is the default block allocator in the ext4. It performs better than the old one and no one seems to claim otherwise so we can safely drop it and make oldalloc and orlov mount option deprecated. This is a part of the effort to reduce number of ext4 options hence the test matrix. Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" --- Documentation/filesystems/ext4.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index a530401..4917cf2 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -203,14 +203,6 @@ inode_readahead_blks=n This tuning parameter controls the maximum table readahead algorithm will pre-read into the buffer cache. The default value is 32 blocks. -orlov (*) This enables the new Orlov block allocator. It is - enabled by default. - -oldalloc This disables the Orlov block allocator and enables - the old block allocator. Orlov should have better - performance - we'd like to get some feedback if it's - the contrary for you. - nouser_xattr Disables Extended User Attributes. If you have extended attribute support enabled in the kernel configuration (CONFIG_EXT4_FS_XATTR), extended attribute support -- cgit v1.1 From f62f548c1c04742f68c15e21f173712dd6633791 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Tue, 11 Oct 2011 16:16:13 -0600 Subject: arm/dt: Tegra: Add pinmux node to tegra20.dtsi Add a pinmux node to tegra20.dtsi in order to instantiate the future pinmux device. v2: Specify reg property precisely; don't just point at the whole APB_MISC register range. Signed-off-by: Stephen Warren Signed-off-by: Olof Johansson --- Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt new file mode 100644 index 0000000..36f82db --- /dev/null +++ b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt @@ -0,0 +1,5 @@ +NVIDIA Tegra 2 pinmux controller + +Required properties: +- compatible : "nvidia,tegra20-pinmux" + -- cgit v1.1 From 499ccb27a89ecd08475f73710fe27fb600431a91 Mon Sep 17 00:00:00 2001 From: Timur Tabi Date: Thu, 15 Sep 2011 13:04:13 -0500 Subject: powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards Standarize and document the FPGA nodes used on Freescale QorIQ reference boards. There are different kinds of FPGAs used on the boards, but only two are currently standard: "pixis", "ngpixis", and "qixis". Although there are minor differences among the boards that have one kind of FPGA, most of the functionality is the same, so it makes sense to create common compatibility strings. We also need to update the P1022DS platform file, because the compatible string for its PIXIS node has changed. This means that older kernels are not compatible with newer device trees. This is not a real problem, however, since that particular function doesn't work anyway. When the DIU is active, the PIXIS is in "indirect mode", and so cannot be accessed as a memory-mapped device. Signed-off-by: Timur Tabi Signed-off-by: Kumar Gala --- .../devicetree/bindings/powerpc/fsl/board.txt | 30 +++++++++++++--------- 1 file changed, 18 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt index 39e9415..380914e 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt @@ -1,3 +1,8 @@ +Freescale Reference Board Bindings + +This document describes device tree bindings for various devices that +exist on some Freescale reference boards. + * Board Control and Status (BCSR) Required properties: @@ -12,25 +17,26 @@ Example: reg = ; }; -* Freescale on board FPGA +* Freescale on-board FPGA This is the memory-mapped registers for on board FPGA. Required properities: -- compatible : should be "fsl,fpga-pixis". -- reg : should contain the address and the length of the FPPGA register - set. +- compatible: should be a board-specific string followed by a string + indicating the type of FPGA. Example: + "fsl,-fpga", "fsl,fpga-pixis" +- reg: should contain the address and the length of the FPGA register set. - interrupt-parent: should specify phandle for the interrupt controller. -- interrupts : should specify event (wakeup) IRQ. +- interrupts: should specify event (wakeup) IRQ. -Example (MPC8610HPCD): +Example (P1022DS): - board-control@e8000000 { - compatible = "fsl,fpga-pixis"; - reg = <0xe8000000 32>; - interrupt-parent = <&mpic>; - interrupts = <8 8>; - }; + board-control@3,0 { + compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis"; + reg = <3 0 0x30>; + interrupt-parent = <&mpic>; + interrupts = <8 8 0 0>; + }; * Freescale BCSR GPIO banks -- cgit v1.1 From b9df02231930c01eaaf3c37b192bd75ea0d1c0bb Mon Sep 17 00:00:00 2001 From: Stephen George Date: Fri, 16 Sep 2011 10:36:34 -0500 Subject: powerpc/85xx: Adding DCSR node to dtsi device trees Adding new device tree binding file for the DCSR node. Modifying device tree dtsi files to add DCSR node for P2041, P3041, P4080, & P5020. Signed-off-by: Stephen George Signed-off-by: Kumar Gala --- .../devicetree/bindings/powerpc/fsl/dcsr.txt | 395 +++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt new file mode 100644 index 0000000..9d54eb5 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt @@ -0,0 +1,395 @@ +=================================================================== +Debug Control and Status Register (DCSR) Binding +Copyright 2011 Freescale Semiconductor Inc. + +NOTE: The bindings described in this document are preliminary and subject +to change. Some of the compatible strings that contain only generic names +may turn out to be inappropriate, or need additional properties to describe +the integration of the block with the rest of the chip. + +===================================================================== +Debug Control and Status Register Memory Map + +Description + +This node defines the base address and range for the +defined DCSR Memory Map. Child nodes will describe the individual +debug blocks defined within this memory space. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,dcsr" and "simple-bus". + The DCSR space exists in the memory-mapped bus. + + - #address-cells + Usage: required + Value type: + Definition: A standard property. Defines the number of cells + or representing physical addresses in child nodes. + + - #size-cells + Usage: required + Value type: + Definition: A standard property. Defines the number of cells + or representing the size of physical addresses in + child nodes. + + - ranges + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + range of the DCSR space. + +EXAMPLE + dcsr: dcsr@f00000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,dcsr", "simple-bus"; + ranges = <0x00000000 0xf 0x00000000 0x01008000>; + }; + +===================================================================== +Event Processing Unit + +This node represents the region of DCSR space allocated to the EPU + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,dcsr-epu" + + - interrupts + Usage: required + Value type: + Definition: Specifies the interrupts generated by the EPU. + The value of the interrupts property consists of three + interrupt specifiers. The format of the specifier is defined + by the binding document describing the node's interrupt parent. + + The EPU counters can be configured to assert the performance + monitor interrupt signal based on either counter overflow or value + match. Which counter asserted the interrupt is captured in an EPU + Counter Interrupt Status Register (EPCPUISR). + + The EPU unit can also be configured to assert either or both of + two interrupt signals based on debug event sources within the SoC. + The interrupt signals are epu_xt_int0 and epu_xt_int1. + Which event source asserted the interrupt is captured in an EPU + Interrupt Status Register (EPISR0,EPISR1). + + Interrupt numbers are lised in order (perfmon, event0, event1). + + - interrupt-parent + Usage: required + Value type: + Definition: A single value that points + to the interrupt parent to which the child domain + is being mapped. Value must be "&mpic" + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-epu@0 { + compatible = "fsl,dcsr-epu"; + interrupts = <52 2 0 0 + 84 2 0 0 + 85 2 0 0>; + interrupt-parent = <&mpic>; + reg = <0x0 0x1000>; + }; + +======================================================================= +Nexus Port Controller + +This node represents the region of DCSR space allocated to the NPC + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,dcsr-npc" + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + The Nexus Port controller occupies two regions in the DCSR space + with distinct functionality. + + The first register range describes the Nexus Port Controller + control and status registers. + + The second register range describes the Nexus Port Controller + internal trace buffer. The NPC trace buffer is a small memory buffer + which stages the nexus trace data for transmission via the Aurora port + or to a DDR based trace buffer. In some configurations the NPC trace + buffer can be the only trace buffer used. + + +EXAMPLE + dcsr-npc { + compatible = "fsl,dcsr-npc"; + reg = <0x1000 0x1000 0x1000000 0x8000>; + }; + +======================================================================= +Nexus Concentrator + +This node represents the region of DCSR space allocated to the NXC + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,dcsr-nxc" + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-nxc@2000 { + compatible = "fsl,dcsr-nxc"; + reg = <0x2000 0x1000>; + }; +======================================================================= +CoreNet Debug Controller + +This node represents the region of DCSR space allocated to +the CoreNet Debug controller. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,dcsr-corenet" + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + The CoreNet Debug controller occupies two regions in the DCSR space + with distinct functionality. + + The first register range describes the CoreNet Debug Controller + functionalty to perform transaction and transaction attribute matches. + + The second register range describes the CoreNet Debug Controller + functionalty to trigger event notifications and debug traces. + +EXAMPLE + dcsr-corenet { + compatible = "fsl,dcsr-corenet"; + reg = <0x8000 0x1000 0xB0000 0x1000>; + }; + +======================================================================= +Data Path Debug controller + +This node represents the region of DCSR space allocated to +the DPAA Debug Controller. This controller controls debug configuration +for the QMAN and FMAN blocks. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include both an identifier specific to the SoC + or Debug IP of the form "fsl,-dcsr-dpaa" in addition to the + generic compatible string "fsl,dcsr-dpaa". + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-dpaa@9000 { + compatible = "fsl,p4080-dcsr-dpaa", "fsl,dcsr-dpaa"; + reg = <0x9000 0x1000>; + }; + +======================================================================= +OCeaN Debug controller + +This node represents the region of DCSR space allocated to +the OCN Debug Controller. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include both an identifier specific to the SoC + or Debug IP of the form "fsl,-dcsr-ocn" in addition to the + generic compatible string "fsl,dcsr-ocn". + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-ocn@11000 { + compatible = "fsl,p4080-dcsr-ocn", "fsl,dcsr-ocn"; + reg = <0x11000 0x1000>; + }; + +======================================================================= +DDR Controller Debug controller + +This node represents the region of DCSR space allocated to +the OCN Debug Controller. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,dcsr-ddr" + + - dev-handle + Usage: required + Definition: A phandle to associate this debug node with its + component controller. + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-ddr@12000 { + compatible = "fsl,dcsr-ddr"; + dev-handle = <&ddr1>; + reg = <0x12000 0x1000>; + }; + +======================================================================= +Nexus Aurora Link Controller + +This node represents the region of DCSR space allocated to +the NAL Controller. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include both an identifier specific to the SoC + or Debug IP of the form "fsl,-dcsr-nal" in addition to the + generic compatible string "fsl,dcsr-nal". + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-nal@18000 { + compatible = "fsl,p4080-dcsr-nal", "fsl,dcsr-nal"; + reg = <0x18000 0x1000>; + }; + + +======================================================================= +Run Control and Power Management + +This node represents the region of DCSR space allocated to +the RCPM Debug Controller. This functionlity is limited to the +control the debug operations of the SoC and cores. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include both an identifier specific to the SoC + or Debug IP of the form "fsl,-dcsr-rcpm" in addition to the + generic compatible string "fsl,dcsr-rcpm". + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-rcpm@22000 { + compatible = "fsl,p4080-dcsr-rcpm", "fsl,dcsr-rcpm"; + reg = <0x22000 0x1000>; + }; + +======================================================================= +Core Service Bridge Proxy + +This node represents the region of DCSR space allocated to +the Core Service Bridge Proxies. +There is one Core Service Bridge Proxy device for each CPU in the system. +This functionlity provides access to the debug operations of the CPU. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include both an identifier specific to the cpu + of the form "fsl,dcsr--sb-proxy" in addition to the + generic compatible string "fsl,dcsr-cpu-sb-proxy". + + - cpu-handle + Usage: required + Definition: A phandle to associate this debug node with its cpu. + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies the physical address + offset and length of the DCSR space registers of the device + configuration block. + +EXAMPLE + dcsr-cpu-sb-proxy@40000 { + compatible = "fsl,dcsr-e500mc-sb-proxy", + "fsl,dcsr-cpu-sb-proxy"; + cpu-handle = <&cpu0>; + reg = <0x40000 0x1000>; + }; + dcsr-cpu-sb-proxy@41000 { + compatible = "fsl,dcsr-e500mc-sb-proxy", + "fsl,dcsr-cpu-sb-proxy"; + cpu-handle = <&cpu1>; + reg = <0x41000 0x1000>; + }; + +======================================================================= -- cgit v1.1 From 2bcd1c0cfcf53a384159c272c972645e7e822140 Mon Sep 17 00:00:00 2001 From: Timur Tabi Date: Fri, 23 Sep 2011 12:41:35 -0500 Subject: powerpc/fsl_msi: add support for "msi-address-64" property Add support for the msi-address-64 property of a PCI node. This property specifies the PCI address of MSIIR (message signaled interrupt index register). In commit 3da34aae ("powerpc/fsl: Support unique MSI addresses per PCIe Root Complex"), the msi_addr_hi/msi_addr_lo fields of struct fsl_msi were redefined from an actual address to just an offset, but the fields were not renamed accordingly. These fields are replace with a single field, msiir_offset, to reflect the new meaning. Signed-off-by: Timur Tabi Signed-off-by: Kumar Gala --- .../devicetree/bindings/powerpc/fsl/msi-pic.txt | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt index 70558c3..5d586e1 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt @@ -25,6 +25,16 @@ Required properties: are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed to MPIC. +Optional properties: +- msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register + is used for MSI messaging. The address of MSIIR in PCI address space is + the MSI message address. + + This property may be used in virtualized environments where the hypervisor + has created an alternate mapping for the MSIR block. See below for an + explanation. + + Example: msi@41600 { compatible = "fsl,mpc8610-msi", "fsl,mpic-msi"; @@ -41,3 +51,35 @@ Example: 0xe7 0>; interrupt-parent = <&mpic>; }; + +The Freescale hypervisor and msi-address-64 +------------------------------------------- +Normally, PCI devices have access to all of CCSR via an ATMU mapping. The +Freescale MSI driver calculates the address of MSIIR (in the MSI register +block) and sets that address as the MSI message address. + +In a virtualized environment, the hypervisor may need to create an IOMMU +mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement +because of hardware limitations of the Peripheral Access Management Unit +(PAMU), which is currently the only IOMMU that the hypervisor supports. +The ATMU is programmed with the guest physical address, and the PAMU +intercepts transactions and reroutes them to the true physical address. + +In the PAMU, each PCI controller is given only one primary window. The +PAMU restricts DMA operations so that they can only occur within a window. +Because PCI devices must be able to DMA to memory, the primary window must +be used to cover all of the guest's memory space. + +PAMU primary windows can be divided into 256 subwindows, and each +subwindow can have its own address mapping ("guest physical" to "true +physical"). However, each subwindow has to have the same alignment, which +means they cannot be located at just any address. Because of these +restrictions, it is usually impossible to create a 4KB subwindow that +covers MSIIR where it's normally located. + +Therefore, the hypervisor has to create a subwindow inside the same +primary window used for memory, but mapped to the MSIR block (where MSIIR +lives). The first subwindow after the end of guest memory is used for +this. The address specified in the msi-address-64 property is the PCI +address of MSIIR. The hypervisor configures the PAMU to map that address to +the true physical address of MSIIR. -- cgit v1.1 From 73d2b4cdfc09a7a858b3ea1f32f6218b21439b96 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Mon, 17 Oct 2011 08:42:16 +0800 Subject: arm/mx5: add device tree support for imx53 boards It adds device tree support for imx53 boards. Signed-off-by: Shawn Guo Acked-by: Grant Likely Acked-by: Sascha Hauer Signed-off-by: Sascha Hauer --- Documentation/devicetree/bindings/arm/fsl.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/fsl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt new file mode 100644 index 0000000..d1e8d6f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -0,0 +1,15 @@ +i.MX53 Automotive Reference Design Board +Required root node properties: + - compatible = "fsl,imx53-ard", "fsl,imx53"; + +i.MX53 Evaluation Kit +Required root node properties: + - compatible = "fsl,imx53-evk", "fsl,imx53"; + +i.MX53 Quick Start Board +Required root node properties: + - compatible = "fsl,imx53-qsb", "fsl,imx53"; + +i.MX53 Smart Mobile Reference Design Board +Required root node properties: + - compatible = "fsl,imx53-smd", "fsl,imx53"; -- cgit v1.1 From 9daaf31a8cc9c98751b7b71198307e47d5bf6a4d Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Mon, 17 Oct 2011 08:42:17 +0800 Subject: arm/mx5: add device tree support for imx51 babbage It adds device tree support for imx51 babbage board. Signed-off-by: Shawn Guo Acked-by: Grant Likely Acked-by: Sascha Hauer Signed-off-by: Sascha Hauer --- Documentation/devicetree/bindings/arm/fsl.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index d1e8d6f..e2401cd 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -1,3 +1,7 @@ +i.MX51 Babbage Board +Required root node properties: + - compatible = "fsl,imx51-babbage", "fsl,imx51"; + i.MX53 Automotive Reference Design Board Required root node properties: - compatible = "fsl,imx53-ard", "fsl,imx53"; -- cgit v1.1 From 773e3206e6a8b4c81826dc76057a96ba3cc96672 Mon Sep 17 00:00:00 2001 From: Ike Panhc Date: Tue, 6 Sep 2011 02:32:52 +0800 Subject: ideapad: add debugfs support Add two nodes in debugfs which shows cfg value and its meaning, and status info read from VPC2004. Signed-off-by: Ike Panhc Signed-off-by: Matthew Garrett --- Documentation/ABI/testing/debugfs-ideapad | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-ideapad (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-ideapad b/Documentation/ABI/testing/debugfs-ideapad new file mode 100644 index 0000000..7079c0b --- /dev/null +++ b/Documentation/ABI/testing/debugfs-ideapad @@ -0,0 +1,19 @@ +What: /sys/kernel/debug/ideapad/cfg +Date: Sep 2011 +KernelVersion: 3.2 +Contact: Ike Panhc +Description: + +cfg shows the return value of _CFG method in VPC2004 device. It tells machine +capability and what graphic component within the machine. + + +What: /sys/kernel/debug/ideapad/status +Date: Sep 2011 +KernelVersion: 3.2 +Contact: Ike Panhc +Description: + +status shows infos we can read and tells its meaning and value. + + -- cgit v1.1 From 349d594be45bdc7a86a08385f2f4f49d08ab68dd Mon Sep 17 00:00:00 2001 From: Ike Panhc Date: Tue, 6 Sep 2011 02:33:00 +0800 Subject: ideapad: remove sysfs node for cfg Replaced by the one in debugfs. Signed-off-by: Ike Panhc Signed-off-by: Matthew Garrett --- Documentation/ABI/testing/sysfs-platform-ideapad-laptop | 15 --------------- 1 file changed, 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop index ff53183..814b013 100644 --- a/Documentation/ABI/testing/sysfs-platform-ideapad-laptop +++ b/Documentation/ABI/testing/sysfs-platform-ideapad-laptop @@ -5,19 +5,4 @@ Contact: "Ike Panhc " Description: Control the power of camera module. 1 means on, 0 means off. -What: /sys/devices/platform/ideapad/cfg -Date: Jun 2011 -KernelVersion: 3.1 -Contact: "Ike Panhc " -Description: - Ideapad capability bits. - Bit 8-10: 1 - Intel graphic only - 2 - ATI graphic only - 3 - Nvidia graphic only - 4 - Intel and ATI graphic - 5 - Intel and Nvidia graphic - Bit 16: Bluetooth exist (1 for exist) - Bit 17: 3G exist (1 for exist) - Bit 18: Wifi exist (1 for exist) - Bit 19: Camera exist (1 for exist) -- cgit v1.1 From 5a5f50802f5a31b9e15de8df40d5621af970a560 Mon Sep 17 00:00:00 2001 From: Thomas Abraham Date: Tue, 13 Sep 2011 09:46:05 +0530 Subject: i2c-s3c2410: Add device tree support Add device tree probe support for Samsung's s3c2410 i2c driver. Cc: Ben Dooks Signed-off-by: Thomas Abraham Acked-by: Grant Likely Signed-off-by: Ben Dooks --- .../devicetree/bindings/i2c/samsung-i2c.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/samsung-i2c.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt new file mode 100644 index 0000000..38832c7 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt @@ -0,0 +1,39 @@ +* Samsung's I2C controller + +The Samsung's I2C controller is used to interface with I2C devices. + +Required properties: + - compatible: value should be either of the following. + (a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c. + (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c. + - reg: physical base address of the controller and length of memory mapped + region. + - interrupts: interrupt number to the cpu. + - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges. + - gpios: The order of the gpios should be the following: . + The gpio specifier depends on the gpio controller. + +Optional properties: + - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not + specified, default value is 0. + - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not + specified, the default value in Hz is 100000. + +Example: + + i2c@13870000 { + compatible = "samsung,s3c2440-i2c"; + reg = <0x13870000 0x100>; + interrupts = <345>; + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <100000>; + gpios = <&gpd1 2 0 /* SDA */ + &gpd1 3 0 /* SCL */>; + #address-cells = <1>; + #size-cells = <0>; + + wm8994@1a { + compatible = "wlf,wm8994"; + reg = <0x1a>; + }; + }; -- cgit v1.1 From d3bf37955d46718ee1a7f1fc69f953d2328ba7c2 Mon Sep 17 00:00:00 2001 From: Michael Holzheu Date: Sun, 30 Oct 2011 15:16:37 +0100 Subject: [S390] kdump: Add size to elfcorehdr kernel parameter Currently only the address of the pre-allocated ELF header is passed with the elfcorehdr= kernel parameter. In order to reserve memory for the header in the 2nd kernel also the size is required. Current kdump architecture backends use different methods to do that, e.g. x86 uses the memmap= kernel parameter. On s390 there is no easy way to transfer this information. Therefore the elfcorehdr kernel parameter is extended to also pass the size. This now can also be used as standard mechanism by all future kdump architecture backends. The syntax of the kernel parameter is extended as follows: elfcorehdr=[size[KMG]@]offset[KMG] This change is backward compatible because elfcorehdr=size is still allowed. Acked-by: Vivek Goyal Acked-by: Andrew Morton Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky --- Documentation/kernel-parameters.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 93413ce..1fbe362 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -741,10 +741,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See Documentation/block/cfq-iosched.txt and Documentation/block/deadline-iosched.txt for details. - elfcorehdr= [IA-64,PPC,SH,X86] + elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390] Specifies physical address of start of kernel core - image elf header. Generally kexec loader will - pass this option to capture kernel. + image elf header and optionally the size. Generally + kexec loader will pass this option to capture kernel. See Documentation/kdump/kdump.txt for details. enable_mtrr_cleanup [X86] -- cgit v1.1 From b3f7ed0324091e2cb23fe1b3c10570700f614014 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 28 Sep 2011 21:27:52 -0500 Subject: ARM: gic: add OF based initialization This adds ARM gic interrupt controller initialization using device tree data. The initialization function is intended to be called by of_irq_init function like this: const static struct of_device_id irq_match[] = { { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, }, {} }; static void __init init_irqs(void) { of_irq_init(irq_match); } Signed-off-by: Rob Herring Reviewed-by: Jamie Iles Tested-by: Thomas Abraham Acked-by: Grant Likely --- Documentation/devicetree/bindings/arm/gic.txt | 55 +++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/gic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt new file mode 100644 index 0000000..52916b4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -0,0 +1,55 @@ +* ARM Generic Interrupt Controller + +ARM SMP cores are often associated with a GIC, providing per processor +interrupts (PPI), shared processor interrupts (SPI) and software +generated interrupts (SGI). + +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs. +Secondary GICs are cascaded into the upward interrupt controller and do not +have PPIs or SGIs. + +Main node required properties: + +- compatible : should be one of: + "arm,cortex-a9-gic" + "arm,arm11mp-gic" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 3. + + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI + interrupts. + + The 2nd cell contains the interrupt number for the interrupt type. + SPI interrupts are in the range [0-987]. PPI interrupts are in the + range [0-15]. + + The 3rd cell is the flags, encoded as follows: + bits[3:0] trigger type and level flags. + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of + the 8 possible cpus attached to the GIC. A bit set to '1' indicated + the interrupt is wired to that CPU. Only valid for PPI interrupts. + +- reg : Specifies base physical address(s) and size of the GIC registers. The + first region is the GIC distributor register base and size. The 2nd region is + the GIC cpu interface register base and size. + +Optional +- interrupts : Interrupt source of the parent interrupt controller. Only + present on secondary GICs. + +Example: + + intc: interrupt-controller@fff11000 { + compatible = "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <1>; + interrupt-controller; + reg = <0xfff11000 0x1000>, + <0xfff10100 0x100>; + }; + -- cgit v1.1 From 253d7addbcb06acc90eb722f122d32a6ccbf67a7 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 10 Aug 2011 15:22:11 -0500 Subject: ARM: highbank: add devicetree source This adds the devicetree source and documentation for the Calxeda highbank platform. Signed-off-by: Rob Herring Reviewed-by: Jamie Iles Reviewed-by: Shawn Guo --- Documentation/devicetree/bindings/arm/calxeda.txt | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/calxeda.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/calxeda.txt b/Documentation/devicetree/bindings/arm/calxeda.txt new file mode 100644 index 0000000..4755caa --- /dev/null +++ b/Documentation/devicetree/bindings/arm/calxeda.txt @@ -0,0 +1,8 @@ +Calxeda Highbank Platforms Device Tree Bindings +----------------------------------------------- + +Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following +properties. + +Required root node properties: + - compatible = "calxeda,highbank"; -- cgit v1.1 From 7d740f87fd0741c00231a4b13074660d526d5630 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Tue, 6 Sep 2011 13:53:26 +0800 Subject: arm/imx6q: add device tree source It adds device tree source and documentation for imx6q platform. Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.txt | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/fsl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt new file mode 100644 index 0000000..345bfc0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -0,0 +1,6 @@ +Freescale i.MX Platforms Device Tree Bindings +----------------------------------------------- + +i.MX6 Quad SABRE Automotive Board +Required root node properties: + - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q"; -- cgit v1.1 From 3241b1d3e0aaafbfcd320f4d71ade629728cc4f4 Mon Sep 17 00:00:00 2001 From: Joe Thornber Date: Mon, 31 Oct 2011 20:19:11 +0000 Subject: dm: add persistent data library The persistent-data library offers a re-usable framework for the storage and management of on-disk metadata in device-mapper targets. It's used by the thin-provisioning target in the next patch and in an upcoming hierarchical storage target. For further information, please read Documentation/device-mapper/persistent-data.txt Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon --- Documentation/device-mapper/persistent-data.txt | 84 +++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 Documentation/device-mapper/persistent-data.txt (limited to 'Documentation') diff --git a/Documentation/device-mapper/persistent-data.txt b/Documentation/device-mapper/persistent-data.txt new file mode 100644 index 0000000..0e5df9b --- /dev/null +++ b/Documentation/device-mapper/persistent-data.txt @@ -0,0 +1,84 @@ +Introduction +============ + +The more-sophisticated device-mapper targets require complex metadata +that is managed in kernel. In late 2010 we were seeing that various +different targets were rolling their own data strutures, for example: + +- Mikulas Patocka's multisnap implementation +- Heinz Mauelshagen's thin provisioning target +- Another btree-based caching target posted to dm-devel +- Another multi-snapshot target based on a design of Daniel Phillips + +Maintaining these data structures takes a lot of work, so if possible +we'd like to reduce the number. + +The persistent-data library is an attempt to provide a re-usable +framework for people who want to store metadata in device-mapper +targets. It's currently used by the thin-provisioning target and an +upcoming hierarchical storage target. + +Overview +======== + +The main documentation is in the header files which can all be found +under drivers/md/persistent-data. + +The block manager +----------------- + +dm-block-manager.[hc] + +This provides access to the data on disk in fixed sized-blocks. There +is a read/write locking interface to prevent concurrent accesses, and +keep data that is being used in the cache. + +Clients of persistent-data are unlikely to use this directly. + +The transaction manager +----------------------- + +dm-transaction-manager.[hc] + +This restricts access to blocks and enforces copy-on-write semantics. +The only way you can get hold of a writable block through the +transaction manager is by shadowing an existing block (ie. doing +copy-on-write) or allocating a fresh one. Shadowing is elided within +the same transaction so performance is reasonable. The commit method +ensures that all data is flushed before it writes the superblock. +On power failure your metadata will be as it was when last committed. + +The Space Maps +-------------- + +dm-space-map.h +dm-space-map-metadata.[hc] +dm-space-map-disk.[hc] + +On-disk data structures that keep track of reference counts of blocks. +Also acts as the allocator of new blocks. Currently two +implementations: a simpler one for managing blocks on a different +device (eg. thinly-provisioned data blocks); and one for managing +the metadata space. The latter is complicated by the need to store +its own data within the space it's managing. + +The data structures +------------------- + +dm-btree.[hc] +dm-btree-remove.c +dm-btree-spine.c +dm-btree-internal.h + +Currently there is only one data structure, a hierarchical btree. +There are plans to add more. For example, something with an +array-like interface would see a lot of use. + +The btree is 'hierarchical' in that you can define it to be composed +of nested btrees, and take multiple keys. For example, the +thin-provisioning target uses a btree with two levels of nesting. +The first maps a device id to a mapping tree, and that in turn maps a +virtual block to a physical block. + +Values stored in the btrees can have arbitrary size. Keys are always +64bits, although nesting allows you to use multiple keys. -- cgit v1.1 From 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 Mon Sep 17 00:00:00 2001 From: Joe Thornber Date: Mon, 31 Oct 2011 20:21:18 +0000 Subject: dm: add thin provisioning target Initial EXPERIMENTAL implementation of device-mapper thin provisioning with snapshot support. The 'thin' target is used to create instances of the virtual devices that are hosted in the 'thin-pool' target. The thin-pool target provides data sharing among devices. This sharing is made possible using the persistent-data library in the previous patch. The main highlight of this implementation, compared to the previous implementation of snapshots, is that it allows many virtual devices to be stored on the same data volume, simplifying administration and allowing sharing of data between volumes (thus reducing disk usage). Another big feature is support for arbitrary depth of recursive snapshots (snapshots of snapshots of snapshots ...). The previous implementation of snapshots did this by chaining together lookup tables, and so performance was O(depth). This new implementation uses a single data structure so we don't get this degradation with depth. For further information and examples of how to use this, please read Documentation/device-mapper/thin-provisioning.txt Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon --- Documentation/device-mapper/thin-provisioning.txt | 285 ++++++++++++++++++++++ 1 file changed, 285 insertions(+) create mode 100644 Documentation/device-mapper/thin-provisioning.txt (limited to 'Documentation') diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt new file mode 100644 index 0000000..801d9d1 --- /dev/null +++ b/Documentation/device-mapper/thin-provisioning.txt @@ -0,0 +1,285 @@ +Introduction +============ + +This document descibes a collection of device-mapper targets that +between them implement thin-provisioning and snapshots. + +The main highlight of this implementation, compared to the previous +implementation of snapshots, is that it allows many virtual devices to +be stored on the same data volume. This simplifies administration and +allows the sharing of data between volumes, thus reducing disk usage. + +Another significant feature is support for an arbitrary depth of +recursive snapshots (snapshots of snapshots of snapshots ...). The +previous implementation of snapshots did this by chaining together +lookup tables, and so performance was O(depth). This new +implementation uses a single data structure to avoid this degradation +with depth. Fragmentation may still be an issue, however, in some +scenarios. + +Metadata is stored on a separate device from data, giving the +administrator some freedom, for example to: + +- Improve metadata resilience by storing metadata on a mirrored volume + but data on a non-mirrored one. + +- Improve performance by storing the metadata on SSD. + +Status +====== + +These targets are very much still in the EXPERIMENTAL state. Please +do not yet rely on them in production. But do experiment and offer us +feedback. Different use cases will have different performance +characteristics, for example due to fragmentation of the data volume. + +If you find this software is not performing as expected please mail +dm-devel@redhat.com with details and we'll try our best to improve +things for you. + +Userspace tools for checking and repairing the metadata are under +development. + +Cookbook +======== + +This section describes some quick recipes for using thin provisioning. +They use the dmsetup program to control the device-mapper driver +directly. End users will be advised to use a higher-level volume +manager such as LVM2 once support has been added. + +Pool device +----------- + +The pool device ties together the metadata volume and the data volume. +It maps I/O linearly to the data volume and updates the metadata via +two mechanisms: + +- Function calls from the thin targets + +- Device-mapper 'messages' from userspace which control the creation of new + virtual devices amongst other things. + +Setting up a fresh pool device +------------------------------ + +Setting up a pool device requires a valid metadata device, and a +data device. If you do not have an existing metadata device you can +make one by zeroing the first 4k to indicate empty metadata. + + dd if=/dev/zero of=$metadata_dev bs=4096 count=1 + +The amount of metadata you need will vary according to how many blocks +are shared between thin devices (i.e. through snapshots). If you have +less sharing than average you'll need a larger-than-average metadata device. + +As a guide, we suggest you calculate the number of bytes to use in the +metadata device as 48 * $data_dev_size / $data_block_size but round it up +to 2MB if the answer is smaller. The largest size supported is 16GB. + +If you're creating large numbers of snapshots which are recording large +amounts of change, you may need find you need to increase this. + +Reloading a pool table +---------------------- + +You may reload a pool's table, indeed this is how the pool is resized +if it runs out of space. (N.B. While specifying a different metadata +device when reloading is not forbidden at the moment, things will go +wrong if it does not route I/O to exactly the same on-disk location as +previously.) + +Using an existing pool device +----------------------------- + + dmsetup create pool \ + --table "0 20971520 thin-pool $metadata_dev $data_dev \ + $data_block_size $low_water_mark" + +$data_block_size gives the smallest unit of disk space that can be +allocated at a time expressed in units of 512-byte sectors. People +primarily interested in thin provisioning may want to use a value such +as 1024 (512KB). People doing lots of snapshotting may want a smaller value +such as 128 (64KB). If you are not zeroing newly-allocated data, +a larger $data_block_size in the region of 256000 (128MB) is suggested. +$data_block_size must be the same for the lifetime of the +metadata device. + +$low_water_mark is expressed in blocks of size $data_block_size. If +free space on the data device drops below this level then a dm event +will be triggered which a userspace daemon should catch allowing it to +extend the pool device. Only one such event will be sent. +Resuming a device with a new table itself triggers an event so the +userspace daemon can use this to detect a situation where a new table +already exceeds the threshold. + +Thin provisioning +----------------- + +i) Creating a new thinly-provisioned volume. + + To create a new thinly- provisioned volume you must send a message to an + active pool device, /dev/mapper/pool in this example. + + dmsetup message /dev/mapper/pool 0 "create_thin 0" + + Here '0' is an identifier for the volume, a 24-bit number. It's up + to the caller to allocate and manage these identifiers. If the + identifier is already in use, the message will fail with -EEXIST. + +ii) Using a thinly-provisioned volume. + + Thinly-provisioned volumes are activated using the 'thin' target: + + dmsetup create thin --table "0 2097152 thin /dev/mapper/pool 0" + + The last parameter is the identifier for the thinp device. + +Internal snapshots +------------------ + +i) Creating an internal snapshot. + + Snapshots are created with another message to the pool. + + N.B. If the origin device that you wish to snapshot is active, you + must suspend it before creating the snapshot to avoid corruption. + This is NOT enforced at the moment, so please be careful! + + dmsetup suspend /dev/mapper/thin + dmsetup message /dev/mapper/pool 0 "create_snap 1 0" + dmsetup resume /dev/mapper/thin + + Here '1' is the identifier for the volume, a 24-bit number. '0' is the + identifier for the origin device. + +ii) Using an internal snapshot. + + Once created, the user doesn't have to worry about any connection + between the origin and the snapshot. Indeed the snapshot is no + different from any other thinly-provisioned device and can be + snapshotted itself via the same method. It's perfectly legal to + have only one of them active, and there's no ordering requirement on + activating or removing them both. (This differs from conventional + device-mapper snapshots.) + + Activate it exactly the same way as any other thinly-provisioned volume: + + dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1" + +Deactivation +------------ + +All devices using a pool must be deactivated before the pool itself +can be. + + dmsetup remove thin + dmsetup remove snap + dmsetup remove pool + +Reference +========= + +'thin-pool' target +------------------ + +i) Constructor + + thin-pool \ + [ []*] + + Optional feature arguments: + - 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks. + + Data block size must be between 64KB (128 sectors) and 1GB + (2097152 sectors) inclusive. + + +ii) Status + + / + / + + + transaction id: + A 64-bit number used by userspace to help synchronise with metadata + from volume managers. + + used data blocks / total data blocks + If the number of free blocks drops below the pool's low water mark a + dm event will be sent to userspace. This event is edge-triggered and + it will occur only once after each resume so volume manager writers + should register for the event and then check the target's status. + + held metadata root: + The location, in sectors, of the metadata root that has been + 'held' for userspace read access. '-' indicates there is no + held root. This feature is not yet implemented so '-' is + always returned. + +iii) Messages + + create_thin + + Create a new thinly-provisioned device. + is an arbitrary unique 24-bit identifier chosen by + the caller. + + create_snap + + Create a new snapshot of another thinly-provisioned device. + is an arbitrary unique 24-bit identifier chosen by + the caller. + is the identifier of the thinly-provisioned device + of which the new device will be a snapshot. + + delete + + Deletes a thin device. Irreversible. + + trim + + Delete mappings from the end of a thin device. Irreversible. + You might want to use this if you're reducing the size of + your thinly-provisioned device. In many cases, due to the + sharing of blocks between devices, it is not possible to + determine in advance how much space 'trim' will release. (In + future a userspace tool might be able to perform this + calculation.) + + set_transaction_id + + Userland volume managers, such as LVM, need a way to + synchronise their external metadata with the internal metadata of the + pool target. The thin-pool target offers to store an + arbitrary 64-bit transaction id and return it on the target's + status line. To avoid races you must provide what you think + the current transaction id is when you change it with this + compare-and-swap message. + +'thin' target +------------- + +i) Constructor + + thin + + pool dev: + the thin-pool device, e.g. /dev/mapper/my_pool or 253:0 + + dev id: + the internal device identifier of the device to be + activated. + +The pool doesn't store any size against the thin devices. If you +load a thin target that is smaller than you've been using previously, +then you'll have no access to blocks mapped beyond the end. If you +load a target that is bigger than before, then extra blocks will be +provisioned as and when needed. + +If you wish to reduce the size of your thin device and potentially +regain some space then send the 'trim' message to the pool. + +ii) Status + + -- cgit v1.1 From b89544575d0096735edc9b0ad187e635487905ad Mon Sep 17 00:00:00 2001 From: Jonathan Brassow Date: Mon, 31 Oct 2011 20:21:22 +0000 Subject: dm log userspace: fix comment hyphens Fix comments: clustered-disk needs a hyphen not an underscore. Signed-off-by: Jonathan Brassow Signed-off-by: Alasdair G Kergon --- Documentation/device-mapper/dm-log.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/device-mapper/dm-log.txt b/Documentation/device-mapper/dm-log.txt index 994dd75..c155ac5 100644 --- a/Documentation/device-mapper/dm-log.txt +++ b/Documentation/device-mapper/dm-log.txt @@ -48,7 +48,7 @@ kernel and userspace, 'connector' is used as the interface for communication. There are currently two userspace log implementations that leverage this -framework - "clustered_disk" and "clustered_core". These implementations +framework - "clustered-disk" and "clustered-core". These implementations provide a cluster-coherent log for shared-storage. Device-mapper mirroring can be used in a shared-storage environment when the cluster log implementations are employed. -- cgit v1.1 From 4356f21d09283dc6d39a6f7287a65ddab61e2808 Mon Sep 17 00:00:00 2001 From: Minchan Kim Date: Mon, 31 Oct 2011 17:06:47 -0700 Subject: mm: change isolate mode from #define to bitwise type Change ISOLATE_XXX macro with bitwise isolate_mode_t type. Normally, macro isn't recommended as it's type-unsafe and making debugging harder as symbol cannot be passed throught to the debugger. Quote from Johannes " Hmm, it would probably be cleaner to fully convert the isolation mode into independent flags. INACTIVE, ACTIVE, BOTH is currently a tri-state among flags, which is a bit ugly." This patch moves isolate mode from swap.h to mmzone.h by memcontrol.h Signed-off-by: Minchan Kim Cc: Johannes Weiner Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Cc: Mel Gorman Cc: Rik van Riel Cc: Michal Hocko Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/trace/postprocess/trace-vmscan-postprocess.pl | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 12cecc8..4a37c47 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -379,10 +379,10 @@ EVENT_PROCESS: # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation - # isolate_inactive == 0 - # isolate_active == 1 - # isolate_both == 2 - if ($isolate_mode != 1) { + # isolate_inactive == 1 + # isolate_active == 2 + # isolate_both == 3 + if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; } $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; -- cgit v1.1 From 73efc0394e148d0e15583e13712637831f926720 Mon Sep 17 00:00:00 2001 From: Dan Ballard Date: Mon, 31 Oct 2011 17:11:20 -0700 Subject: kernel/sysctl.c: add cap_last_cap to /proc/sys/kernel Userspace needs to know the highest valid capability of the running kernel, which right now cannot reliably be retrieved from the header files only. The fact that this value cannot be determined properly right now creates various problems for libraries compiled on newer header files which are run on older kernels. They assume capabilities are available which actually aren't. libcap-ng is one example. And we ran into the same problem with systemd too. Now the capability is exported in /proc/sys/kernel/cap_last_cap. [akpm@linux-foundation.org: make cap_last_cap const, per Ulrich] Signed-off-by: Dan Ballard Cc: Randy Dunlap Cc: Ingo Molnar Cc: Lennart Poettering Cc: Kay Sievers Cc: Ulrich Drepper Cc: James Morris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/kernel.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 704e474..1f24636 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -24,6 +24,7 @@ show up in /proc/sys/kernel: - bootloader_type [ X86 only ] - bootloader_version [ X86 only ] - callhome [ S390 only ] +- cap_last_cap - core_pattern - core_pipe_limit - core_uses_pid @@ -155,6 +156,13 @@ on has a service contract with IBM. ============================================================== +cap_last_cap + +Highest valid capability of the running kernel. Exports +CAP_LAST_CAP from the kernel. + +============================================================== + core_pattern: core_pattern is used to specify a core dumpfile pattern name. -- cgit v1.1 From 0eca6b7c78fd997e02bd9850e608102382b7822e Mon Sep 17 00:00:00 2001 From: Yanmin Zhang Date: Mon, 31 Oct 2011 17:11:25 -0700 Subject: printk: add module parameter ignore_loglevel to control ignore_loglevel We are enabling some power features on medfield. To test suspend-2-RAM conveniently, we need turn on/off ignore_loglevel frequently without rebooting. Add a module parameter, so users can change it by: /sys/module/printk/parameters/ignore_loglevel Signed-off-by: Yanmin Zhang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 27e0488..106efe1 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -973,6 +973,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ignore_loglevel [KNL] Ignore loglevel setting - this will print /all/ kernel messages to the console. Useful for debugging. + We also add it as printk module parameter, so users + could change it dynamically, usually by + /sys/module/printk/parameters/ignore_loglevel. ihash_entries= [KNL] Set number of hash buckets for inode cache. -- cgit v1.1 From 134620f7a865b3bc9e3d56d460603592b70ede21 Mon Sep 17 00:00:00 2001 From: Yanmin Zhang Date: Mon, 31 Oct 2011 17:11:27 -0700 Subject: printk: add console_suspend module parameter We are enabling some power features on medfield. To test suspend-2-RAM conveniently, we need turn on/off console_suspend_enabled frequently. Add a module parameter, so users could change it by: /sys/module/printk/parameters/console_suspend Signed-off-by: Yanmin Zhang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 106efe1..c2efe28 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1669,6 +1669,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. debugging driver suspend/resume hooks). This may not work reliably with all consoles, but is known to work with serial and VGA consoles. + To facilitate more flexible debugging, we also add + console_suspend, a printk module parameter to control + it. Users could use console_suspend (usually + /sys/module/printk/parameters/console_suspend) to + turn on/off it dynamically. noaliencache [MM, NUMA, SLAB] Disables the allocation of alien caches in the slab allocator. Saves per-node memory, -- cgit v1.1 From 7e777dd43d55a78c41c3498afaf3ef7edf157120 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Fri, 9 Sep 2011 17:07:43 +0900 Subject: ipvs: Add documentation for new sysctl entries Add missing documentation for conntrack, snat_reroute and sync_version. Also fix up a typo, IPVS_DEBUG should be IP_VS_DEBUG. Acked-by: Julian Anastasov Acked-by Hans Schillstrom Signed-off-by: Simon Horman Signed-off-by: Pablo Neira Ayuso --- Documentation/networking/ipvs-sysctl.txt | 52 +++++++++++++++++++++++++++++++- 1 file changed, 51 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt index 4ccdbca..1dcdd49 100644 --- a/Documentation/networking/ipvs-sysctl.txt +++ b/Documentation/networking/ipvs-sysctl.txt @@ -15,6 +15,23 @@ amemthresh - INTEGER enabled and the variable is automatically set to 2, otherwise the strategy is disabled and the variable is set to 1. +conntrack - BOOLEAN + 0 - disabled (default) + not 0 - enabled + + If set, maintain connection tracking entries for + connections handled by IPVS. + + This should be enabled if connections handled by IPVS are to be + also handled by stateful firewall rules. That is, iptables rules + that make use of connection tracking. It is a performance + optimisation to disable this setting otherwise. + + Connections handled by the IPVS FTP application module + will have connection tracking entries regardless of this setting. + + Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT + cache_bypass - BOOLEAN 0 - disabled (default) not 0 - enabled @@ -39,7 +56,7 @@ debug_level - INTEGER 11 - IPVS packet handling (ip_vs_in/ip_vs_out) 12 or more - packet traversal - Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG + Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG Higher debugging levels include the messages for lower debugging levels, so setting debug level 2, includes level 0, 1 and 2 @@ -141,3 +158,36 @@ sync_threshold - INTEGER synchronized, every time the number of its incoming packets modulus 50 equals the threshold. The range of the threshold is from 0 to 49. + +snat_reroute - BOOLEAN + 0 - disabled + not 0 - enabled (default) + + If enabled, recalculate the route of SNATed packets from + realservers so that they are routed as if they originate from the + director. Otherwise they are routed as if they are forwarded by the + director. + + If policy routing is in effect then it is possible that the route + of a packet originating from a director is routed differently to a + packet being forwarded by the director. + + If policy routing is not in effect then the recalculated route will + always be the same as the original route so it is an optimisation + to disable snat_reroute and avoid the recalculation. + +sync_version - INTEGER + default 1 + + The version of the synchronisation protocol used when sending + synchronisation messages. + + 0 selects the original synchronisation protocol (version 0). This + should be used when sending synchronisation messages to a legacy + system that only understands the original synchronisation protocol. + + 1 selects the current synchronisation protocol (version 1). This + should be used where possible. + + Kernels with this sync_version entry are able to receive messages + of both version 1 and version 2 of the synchronisation protocol. -- cgit v1.1 From 325aadc8483e4fc3bbd4acfa7e471e3a032bc941 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Thu, 29 Sep 2011 16:14:51 +0900 Subject: ipvs: secure_tcp does provide alternate state timeouts Also reword the test to make it read more easily (to me) Signed-off-by: Simon Horman Signed-off-by: Pablo Neira Ayuso --- Documentation/networking/ipvs-sysctl.txt | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt index 1dcdd49..13610e3 100644 --- a/Documentation/networking/ipvs-sysctl.txt +++ b/Documentation/networking/ipvs-sysctl.txt @@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN secure_tcp - INTEGER 0 - disabled (default) - The secure_tcp defense is to use a more complicated state - transition table and some possible short timeouts of each - state. In the VS/NAT, it delays the entering the ESTABLISHED - until the real server starts to send data and ACK packet - (after 3-way handshake). + The secure_tcp defense is to use a more complicated TCP state + transition table. For VS/NAT, it also delays entering the + TCP ESTABLISHED state until the three way handshake is completed. - The value definition is the same as that of drop_entry or + The value definition is the same as that of drop_entry and drop_packet. sync_threshold - INTEGER -- cgit v1.1 From 40cb1f9bc52186a1a9ef56f0d976482863516ce1 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Thu, 29 Sep 2011 16:27:37 +0900 Subject: ipvs: Enhance grammar used to refer to Kconfig options Reported-by: Randy Dunlap Signed-off-by: Simon Horman Signed-off-by: Pablo Neira Ayuso --- Documentation/networking/ipvs-sysctl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt index 13610e3..f2a2488 100644 --- a/Documentation/networking/ipvs-sysctl.txt +++ b/Documentation/networking/ipvs-sysctl.txt @@ -30,7 +30,7 @@ conntrack - BOOLEAN Connections handled by the IPVS FTP application module will have connection tracking entries regardless of this setting. - Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT + Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled. cache_bypass - BOOLEAN 0 - disabled (default) @@ -56,7 +56,7 @@ debug_level - INTEGER 11 - IPVS packet handling (ip_vs_in/ip_vs_out) 12 or more - packet traversal - Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG + Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled. Higher debugging levels include the messages for lower debugging levels, so setting debug level 2, includes level 0, 1 and 2 -- cgit v1.1 From edfd52e6367270c90f3fd7cc302b375ffa89f91e Mon Sep 17 00:00:00 2001 From: Pawel Moll Date: Mon, 24 Oct 2011 14:07:03 +0100 Subject: virtio: Add platform bus driver for memory mapped virtio device This patch, based on virtio PCI driver, adds support for memory mapped (platform) virtio device. This should allow environments like qemu to use virtio-based block & network devices even on platforms without PCI support. One can define and register a platform device which resources will describe memory mapped control registers and "mailbox" interrupt. Such device can be also instantiated using the Device Tree node with compatible property equal "virtio,mmio". Cc: Anthony Liguori Cc: Michael S.Tsirkin Signed-off-by: Pawel Moll Signed-off-by: Rusty Russell --- Documentation/devicetree/bindings/virtio/mmio.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/virtio/mmio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt new file mode 100644 index 0000000..5069c1b --- /dev/null +++ b/Documentation/devicetree/bindings/virtio/mmio.txt @@ -0,0 +1,17 @@ +* virtio memory mapped device + +See http://ozlabs.org/~rusty/virtio-spec/ for more details. + +Required properties: + +- compatible: "virtio,mmio" compatibility string +- reg: control registers base address and size including configuration space +- interrupts: interrupt generated by the device + +Example: + + virtio_block@3000 { + compatible = "virtio,mmio"; + reg = <0x3000 0x100>; + interrupts = <41>; + } -- cgit v1.1 From f0023bc617ba600956b9226f1806033d7486c8ba Mon Sep 17 00:00:00 2001 From: Sage Weil Date: Fri, 28 Oct 2011 10:02:42 -0700 Subject: vfs: add d_prune dentry operation This adds a d_prune dentry operation that is called by the VFS prior to pruning (i.e. unhashing and killing) a hashed dentry from the dcache. Wrap dentry_lru_del() and use the new _prune() helper in the cases where we are about to unhash and kill the dentry. This will be used by Ceph to maintain a flag indicating whether the complete contents of a directory are contained in the dcache, allowing it to satisfy lookups and readdir without addition server communication. Renumber a few DCACHE_* #defines to group DCACHE_OP_PRUNE with the other DCACHE_OP_ bits. Signed-off-by: Sage Weil Signed-off-by: Christoph Hellwig --- Documentation/filesystems/Locking | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 6533807..d819ba1 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -29,6 +29,7 @@ d_hash no no no maybe d_compare: yes no no maybe d_delete: no yes no no d_release: no no yes no +d_prune: no yes no no d_iput: no no yes no d_dname: no no no no d_automount: no no yes no -- cgit v1.1 From 8a91db29252f87630e6f31a56ff96eeda00d5ba3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Fri, 12 Aug 2011 02:28:23 +0200 Subject: UserModeLinux-HOWTO.txt: remove ^H characters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If you can't read this patch, please run: sed -i -e "s/[^\o10]\o10//g" \ Documentation/virtual/uml/UserModeLinux-HOWTO.txt Signed-off-by: Jonathan Neuschäfer Signed-off-by: Richard Weinberger --- Documentation/virtual/uml/UserModeLinux-HOWTO.txt | 530 +++++++++++----------- 1 file changed, 265 insertions(+), 265 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index 5d0fc8b..a7af9cf 100644 --- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt @@ -134,13 +134,13 @@ ______________________________________________________________________ - 11.. IInnttrroodduuccttiioonn + 1. Introduction Welcome to User Mode Linux. It's going to be fun. - 11..11.. HHooww iiss UUsseerr MMooddee LLiinnuuxx DDiiffffeerreenntt?? + 1.1. How is User Mode Linux Different? Normally, the Linux Kernel talks straight to your hardware (video card, keyboard, hard drives, etc), and any programs which run ask the @@ -181,7 +181,7 @@ - 11..22.. WWhhyy WWoouulldd II WWaanntt UUsseerr MMooddee LLiinnuuxx?? + 1.2. Why Would I Want User Mode Linux? 1. If User Mode Linux crashes, your host kernel is still fine. @@ -206,12 +206,12 @@ - 22.. CCoommppiilliinngg tthhee kkeerrnneell aanndd mmoodduulleess + 2. Compiling the kernel and modules - 22..11.. CCoommppiilliinngg tthhee kkeerrnneell + 2.1. Compiling the kernel Compiling the user mode kernel is just like compiling any other @@ -322,7 +322,7 @@ bug fixes and enhancements that have gone into subsequent releases. - 22..22.. CCoommppiilliinngg aanndd iinnssttaalllliinngg kkeerrnneell mmoodduulleess + 2.2. Compiling and installing kernel modules UML modules are built in the same way as the native kernel (with the exception of the 'ARCH=um' that you always need for UML): @@ -386,19 +386,19 @@ - 22..33.. CCoommppiilliinngg aanndd iinnssttaalllliinngg uummll__uuttiilliittiieess + 2.3. Compiling and installing uml_utilities Many features of the UML kernel require a user-space helper program, so a uml_utilities package is distributed separately from the kernel patch which provides these helpers. Included within this is: - +o port-helper - Used by consoles which connect to xterms or ports + o port-helper - Used by consoles which connect to xterms or ports - +o tunctl - Configuration tool to create and delete tap devices + o tunctl - Configuration tool to create and delete tap devices - +o uml_net - Setuid binary for automatic tap device configuration + o uml_net - Setuid binary for automatic tap device configuration - +o uml_switch - User-space virtual switch required for daemon + o uml_switch - User-space virtual switch required for daemon transport The uml_utilities tree is compiled with: @@ -423,11 +423,11 @@ - 33.. RRuunnnniinngg UUMMLL aanndd llooggggiinngg iinn + 3. Running UML and logging in - 33..11.. RRuunnnniinngg UUMMLL + 3.1. Running UML It runs on 2.2.15 or later, and all 2.4 kernels. @@ -454,7 +454,7 @@ - 33..22.. LLooggggiinngg iinn + 3.2. Logging in @@ -468,7 +468,7 @@ There are a couple of other ways to log in: - +o On a virtual console + o On a virtual console @@ -480,7 +480,7 @@ - +o Over the serial line + o Over the serial line In the boot output, find a line that looks like: @@ -503,7 +503,7 @@ - +o Over the net + o Over the net If the network is running, then you can telnet to the virtual @@ -514,13 +514,13 @@ down and the process will exit. - 33..33.. EExxaammpplleess + 3.3. Examples Here are some examples of UML in action: - +o A login session + o A login session - +o A virtual network + o A virtual network @@ -528,12 +528,12 @@ - 44.. UUMMLL oonn 22GG//22GG hhoossttss + 4. UML on 2G/2G hosts - 44..11.. IInnttrroodduuccttiioonn + 4.1. Introduction Most Linux machines are configured so that the kernel occupies the @@ -546,7 +546,7 @@ - 44..22.. TThhee pprroobblleemm + 4.2. The problem The prebuilt UML binaries on this site will not run on 2G/2G hosts @@ -558,7 +558,7 @@ - 44..33.. TThhee ssoolluuttiioonn + 4.3. The solution The fix for this is to rebuild UML from source after enabling @@ -576,7 +576,7 @@ - 55.. SSeettttiinngg uupp sseerriiaall lliinneess aanndd ccoonnssoolleess + 5. Setting up serial lines and consoles It is possible to attach UML serial lines and consoles to many types @@ -586,12 +586,12 @@ You can attach them to host ptys, ttys, file descriptors, and ports. This allows you to do things like - +o have a UML console appear on an unused host console, + o have a UML console appear on an unused host console, - +o hook two virtual machines together by having one attach to a pty + o hook two virtual machines together by having one attach to a pty and having the other attach to the corresponding tty - +o make a virtual machine accessible from the net by attaching a + o make a virtual machine accessible from the net by attaching a console to a port on the host. @@ -599,7 +599,7 @@ - 55..11.. SSppeecciiffyyiinngg tthhee ddeevviiccee + 5.1. Specifying the device Devices are specified with "con" or "ssl" (console or serial line, respectively), optionally with a device number if you are talking @@ -626,13 +626,13 @@ - 55..22.. SSppeecciiffyyiinngg tthhee cchhaannnneell + 5.2. Specifying the channel There are a number of different types of channels to attach a UML device to, each with a different way of specifying exactly what to attach to. - +o pseudo-terminals - device=pty pts terminals - device=pts + o pseudo-terminals - device=pty pts terminals - device=pts This will cause UML to allocate a free host pseudo-terminal for the @@ -640,20 +640,20 @@ log. You access it by attaching a terminal program to the corresponding tty: - +o screen /dev/pts/n + o screen /dev/pts/n - +o screen /dev/ttyxx + o screen /dev/ttyxx - +o minicom -o -p /dev/ttyxx - minicom seems not able to handle pts + o minicom -o -p /dev/ttyxx - minicom seems not able to handle pts devices - +o kermit - start it up, 'open' the device, then 'connect' + o kermit - start it up, 'open' the device, then 'connect' - +o terminals - device=tty:tty device file + o terminals - device=tty:tty device file This will make UML attach the device to the specified tty (i.e @@ -672,7 +672,7 @@ - +o xterms - device=xterm + o xterms - device=xterm UML will run an xterm and the device will be attached to it. @@ -681,7 +681,7 @@ - +o Port - device=port:port number + o Port - device=port:port number This will attach the UML devices to the specified host port. @@ -725,7 +725,7 @@ - +o already-existing file descriptors - device=file descriptor + o already-existing file descriptors - device=file descriptor If you set up a file descriptor on the UML command line, you can @@ -743,7 +743,7 @@ - +o Nothing - device=null + o Nothing - device=null This allows the device to be opened, in contrast to 'none', but @@ -754,7 +754,7 @@ - +o None - device=none + o None - device=none This causes the device to disappear. @@ -785,7 +785,7 @@ - 55..33.. EExxaammpplleess + 5.3. Examples There are a number of interesting things you can do with this capability. @@ -838,7 +838,7 @@ prompt of the other virtual machine. - 66.. SSeettttiinngg uupp tthhee nneettwwoorrkk + 6. Setting up the network @@ -858,19 +858,19 @@ There are currently five transport types available for a UML virtual machine to exchange packets with other hosts: - +o ethertap + o ethertap - +o TUN/TAP + o TUN/TAP - +o Multicast + o Multicast - +o a switch daemon + o a switch daemon - +o slip + o slip - +o slirp + o slirp - +o pcap + o pcap The TUN/TAP, ethertap, slip, and slirp transports allow a UML instance to exchange packets with the host. They may be directed @@ -893,28 +893,28 @@ With so many host transports, which one should you use? Here's when you should use each one: - +o ethertap - if you want access to the host networking and it is + o ethertap - if you want access to the host networking and it is running 2.2 - +o TUN/TAP - if you want access to the host networking and it is + o TUN/TAP - if you want access to the host networking and it is running 2.4. Also, the TUN/TAP transport is able to use a preconfigured device, allowing it to avoid using the setuid uml_net helper, which is a security advantage. - +o Multicast - if you want a purely virtual network and you don't want + o Multicast - if you want a purely virtual network and you don't want to set up anything but the UML - +o a switch daemon - if you want a purely virtual network and you + o a switch daemon - if you want a purely virtual network and you don't mind running the daemon in order to get somewhat better performance - +o slip - there is no particular reason to run the slip backend unless + o slip - there is no particular reason to run the slip backend unless ethertap and TUN/TAP are just not available for some reason - +o slirp - if you don't have root access on the host to setup + o slirp - if you don't have root access on the host to setup networking, or if you don't want to allocate an IP to your UML - +o pcap - not much use for actual network connectivity, but great for + o pcap - not much use for actual network connectivity, but great for monitoring traffic on the host Ethertap is available on 2.4 and works fine. TUN/TAP is preferred @@ -926,7 +926,7 @@ exploit the helper's root privileges. - 66..11.. GGeenneerraall sseettuupp + 6.1. General setup First, you must have the virtual network enabled in your UML. If are running a prebuilt kernel from this site, everything is already @@ -995,7 +995,7 @@ - 66..22.. UUsseerrssppaaccee ddaaeemmoonnss + 6.2. Userspace daemons You will likely need the setuid helper, or the switch daemon, or both. They are both installed with the RPM and deb, so if you've installed @@ -1011,7 +1011,7 @@ - 66..33.. SSppeecciiffyyiinngg eetthheerrnneett aaddddrreesssseess + 6.3. Specifying ethernet addresses Below, you will see that the TUN/TAP, ethertap, and daemon interfaces allow you to specify hardware addresses for the virtual ethernet @@ -1023,11 +1023,11 @@ sufficient to guarantee a unique hardware address for the device. A couple of exceptions are: - +o Another set of virtual ethernet devices are on the same network and + o Another set of virtual ethernet devices are on the same network and they are assigned hardware addresses using a different scheme which may conflict with the UML IP address-based scheme - +o You aren't going to use the device for IP networking, so you don't + o You aren't going to use the device for IP networking, so you don't assign the device an IP address If you let the driver provide the hardware address, you should make @@ -1049,7 +1049,7 @@ - 66..44.. UUMMLL iinntteerrffaaccee sseettuupp + 6.4. UML interface setup Once the network devices have been described on the command line, you should boot UML and log in. @@ -1131,7 +1131,7 @@ - 66..55.. MMuullttiiccaasstt + 6.5. Multicast The simplest way to set up a virtual network between multiple UMLs is to use the mcast transport. This was written by Harald Welte and is @@ -1194,7 +1194,7 @@ - 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr + 6.6. TUN/TAP with the uml_net helper TUN/TAP is the preferred mechanism on 2.4 to exchange packets with the host. The TUN/TAP backend has been in UML since 2.4.9-3um. @@ -1247,10 +1247,10 @@ There are a couple potential problems with running the TUN/TAP transport on a 2.4 host kernel - +o TUN/TAP seems not to work on 2.4.3 and earlier. Upgrade the host + o TUN/TAP seems not to work on 2.4.3 and earlier. Upgrade the host kernel or use the ethertap transport. - +o With an upgraded kernel, TUN/TAP may fail with + o With an upgraded kernel, TUN/TAP may fail with File descriptor in bad state @@ -1269,7 +1269,7 @@ - 66..77.. TTUUNN//TTAAPP wwiitthh aa pprreeccoonnffiigguurreedd ttaapp ddeevviiccee + 6.7. TUN/TAP with a preconfigured tap device If you prefer not to have UML use uml_net (which is somewhat insecure), with UML 2.4.17-11, you can set up a TUN/TAP device @@ -1277,7 +1277,7 @@ there is no need for root assistance. Setting up the device is done as follows: - +o Create the device with tunctl (available from the UML utilities + o Create the device with tunctl (available from the UML utilities tarball) @@ -1291,7 +1291,7 @@ where uid is the user id or username that UML will be run as. This will tell you what device was created. - +o Configure the device IP (change IP addresses and device name to + o Configure the device IP (change IP addresses and device name to suit) @@ -1303,7 +1303,7 @@ - +o Set up routing and arping if desired - this is my recipe, there are + o Set up routing and arping if desired - this is my recipe, there are other ways of doing the same thing @@ -1338,7 +1338,7 @@ utility which reads the information from a config file and sets up devices at boot time. - +o Rather than using up two IPs and ARPing for one of them, you can + o Rather than using up two IPs and ARPing for one of them, you can also provide direct access to your LAN by the UML by using a bridge. @@ -1417,7 +1417,7 @@ Note that 'br0' should be setup using ifconfig with the existing IP address of eth0, as eth0 no longer has its own IP. - +o + o Also, the /dev/net/tun device must be writable by the user running @@ -1438,11 +1438,11 @@ devices and chgrp /dev/net/tun to that group with mode 664 or 660. - +o Once the device is set up, run UML with 'eth0=tuntap,device name' + o Once the device is set up, run UML with 'eth0=tuntap,device name' (i.e. 'eth0=tuntap,tap0') on the command line (or do it with the mconsole config command). - +o Bring the eth device up in UML and you're in business. + o Bring the eth device up in UML and you're in business. If you don't want that tap device any more, you can make it non- persistent with @@ -1465,7 +1465,7 @@ - 66..88.. EEtthheerrttaapp + 6.8. Ethertap Ethertap is the general mechanism on 2.2 for userspace processes to exchange packets with the kernel. @@ -1561,9 +1561,9 @@ - 66..99.. TThhee sswwiittcchh ddaaeemmoonn + 6.9. The switch daemon - NNoottee: This is the daemon formerly known as uml_router, but which was + Note: This is the daemon formerly known as uml_router, but which was renamed so the network weenies of the world would stop growling at me. @@ -1649,7 +1649,7 @@ - 66..1100.. SSlliipp + 6.10. Slip Slip is another, less general, mechanism for a process to communicate with the host networking. In contrast to the ethertap interface, @@ -1681,7 +1681,7 @@ - 66..1111.. SSlliirrpp + 6.11. Slirp slirp uses an external program, usually /usr/bin/slirp, to provide IP only networking connectivity through the host. This is similar to IP @@ -1737,7 +1737,7 @@ - 66..1122.. ppccaapp + 6.12. pcap The pcap transport is attached to a UML ethernet device on the command line or with uml_mconsole with the following syntax: @@ -1777,7 +1777,7 @@ - 66..1133.. SSeettttiinngg uupp tthhee hhoosstt yyoouurrsseellff + 6.13. Setting up the host yourself If you don't specify an address for the host side of the ethertap or slip device, UML won't do any setup on the host. So this is what is @@ -1785,7 +1785,7 @@ 192.168.0.251 and a UML-side IP of 192.168.0.250 - adjust to suit your own network): - +o The device needs to be configured with its IP address. Tap devices + o The device needs to be configured with its IP address. Tap devices are also configured with an mtu of 1484. Slip devices are configured with a point-to-point address pointing at the UML ip address. @@ -1805,7 +1805,7 @@ - +o If a tap device is being set up, a route is set to the UML IP. + o If a tap device is being set up, a route is set to the UML IP. UML# route add -host 192.168.0.250 gw 192.168.0.251 @@ -1814,7 +1814,7 @@ - +o To allow other hosts on your network to see the virtual machine, + o To allow other hosts on your network to see the virtual machine, proxy arp is set up for it. @@ -1824,7 +1824,7 @@ - +o Finally, the host is set up to route packets. + o Finally, the host is set up to route packets. host# echo 1 > /proc/sys/net/ipv4/ip_forward @@ -1838,12 +1838,12 @@ - 77.. SShhaarriinngg FFiilleessyysstteemmss bbeettwweeeenn VViirrttuuaall MMaacchhiinneess + 7. Sharing Filesystems between Virtual Machines - 77..11.. AA wwaarrnniinngg + 7.1. A warning Don't attempt to share filesystems simply by booting two UMLs from the same file. That's the same thing as booting two physical machines @@ -1851,7 +1851,7 @@ - 77..22.. UUssiinngg llaayyeerreedd bblloocckk ddeevviicceess + 7.2. Using layered block devices The way to share a filesystem between two virtual machines is to use the copy-on-write (COW) layering capability of the ubd block driver. @@ -1896,7 +1896,7 @@ - 77..33.. NNoottee!! + 7.3. Note! When checking the size of the COW file in order to see the gobs of space that you're saving, make sure you use 'ls -ls' to see the actual @@ -1926,7 +1926,7 @@ - 77..44.. AAnnootthheerr wwaarrnniinngg + 7.4. Another warning Once a filesystem is being used as a readonly backing file for a COW file, do not boot directly from it or modify it in any way. Doing so @@ -1952,7 +1952,7 @@ - 77..55.. uummll__mmoooo :: MMeerrggiinngg aa CCOOWW ffiillee wwiitthh iittss bbaacckkiinngg ffiillee + 7.5. uml_moo : Merging a COW file with its backing file Depending on how you use UML and COW devices, it may be advisable to merge the changes in the COW file into the backing file every once in @@ -2001,7 +2001,7 @@ - 88.. CCrreeaattiinngg ffiilleessyysstteemmss + 8. Creating filesystems You may want to create and mount new UML filesystems, either because @@ -2015,7 +2015,7 @@ should be easy to translate to the filesystem of your choice. - 88..11.. CCrreeaattee tthhee ffiilleessyysstteemm ffiillee + 8.1. Create the filesystem file dd is your friend. All you need to do is tell dd to create an empty file of the appropriate size. I usually make it sparse to save time @@ -2032,7 +2032,7 @@ - 88..22.. AAssssiiggnn tthhee ffiillee ttoo aa UUMMLL ddeevviiccee + 8.2. Assign the file to a UML device Add an argument like the following to the UML command line: @@ -2045,7 +2045,7 @@ - 88..33.. CCrreeaattiinngg aanndd mmoouunnttiinngg tthhee ffiilleessyysstteemm + 8.3. Creating and mounting the filesystem Make sure that the filesystem is available, either by being built into the kernel, or available as a module, then boot up UML and log in. If @@ -2096,7 +2096,7 @@ - 99.. HHoosstt ffiillee aacccceessss + 9. Host file access If you want to access files on the host machine from inside UML, you @@ -2112,7 +2112,7 @@ files contained in it just as you would on the host. - 99..11.. UUssiinngg hhoossttffss + 9.1. Using hostfs To begin with, make sure that hostfs is available inside the virtual machine with @@ -2151,7 +2151,7 @@ - 99..22.. hhoossttffss aass tthhee rroooott ffiilleessyysstteemm + 9.2. hostfs as the root filesystem It's possible to boot from a directory hierarchy on the host using hostfs rather than using the standard filesystem in a file. @@ -2194,20 +2194,20 @@ UML should then boot as it does normally. - 99..33.. BBuuiillddiinngg hhoossttffss + 9.3. Building hostfs If you need to build hostfs because it's not in your kernel, you have two choices: - +o Compiling hostfs into the kernel: + o Compiling hostfs into the kernel: Reconfigure the kernel and set the 'Host filesystem' option under - +o Compiling hostfs as a module: + o Compiling hostfs as a module: Reconfigure the kernel and set the 'Host filesystem' option under @@ -2228,7 +2228,7 @@ - 1100.. TThhee MMaannaaggeemmeenntt CCoonnssoollee + 10. The Management Console @@ -2240,15 +2240,15 @@ There are a number of things you can do with the mconsole interface: - +o get the kernel version + o get the kernel version - +o add and remove devices + o add and remove devices - +o halt or reboot the machine + o halt or reboot the machine - +o Send SysRq commands + o Send SysRq commands - +o Pause and resume the UML + o Pause and resume the UML You need the mconsole client (uml_mconsole) which is present in CVS @@ -2300,28 +2300,28 @@ You'll get a prompt, at which you can run one of these commands: - +o version + o version - +o halt + o halt - +o reboot + o reboot - +o config + o config - +o remove + o remove - +o sysrq + o sysrq - +o help + o help - +o cad + o cad - +o stop + o stop - +o go + o go - 1100..11.. vveerrssiioonn + 10.1. version This takes no arguments. It prints the UML version. @@ -2342,7 +2342,7 @@ - 1100..22.. hhaalltt aanndd rreebboooott + 10.2. halt and reboot These take no arguments. They shut the machine down immediately, with no syncing of disks and no clean shutdown of userspace. So, they are @@ -2357,7 +2357,7 @@ - 1100..33.. ccoonnffiigg + 10.3. config "config" adds a new device to the virtual machine. Currently the ubd and network drivers support this. It takes one argument, which is the @@ -2378,7 +2378,7 @@ - 1100..44.. rreemmoovvee + 10.4. remove "remove" deletes a device from the system. Its argument is just the name of the device to be removed. The device must be idle in whatever @@ -2397,7 +2397,7 @@ - 1100..55.. ssyyssrrqq + 10.5. sysrq This takes one argument, which is a single letter. It calls the generic kernel's SysRq driver, which does whatever is called for by @@ -2407,14 +2407,14 @@ - 1100..66.. hheellpp + 10.6. help "help" returns a string listing the valid commands and what each one does. - 1100..77.. ccaadd + 10.7. cad This invokes the Ctl-Alt-Del action on init. What exactly this ends up doing is up to /etc/inittab. Normally, it reboots the machine. @@ -2432,7 +2432,7 @@ - 1100..88.. ssttoopp + 10.8. stop This puts the UML in a loop reading mconsole requests until a 'go' mconsole command is received. This is very useful for making backups @@ -2448,7 +2448,7 @@ - 1100..99.. ggoo + 10.9. go This resumes a UML after being paused by a 'stop' command. Note that when the UML has resumed, TCP connections may have timed out and if @@ -2462,10 +2462,10 @@ - 1111.. KKeerrnneell ddeebbuuggggiinngg + 11. Kernel debugging - NNoottee:: The interface that makes debugging, as described here, possible + Note: The interface that makes debugging, as described here, possible is present in 2.4.0-test6 kernels and later. @@ -2485,7 +2485,7 @@ - 1111..11.. SSttaarrttiinngg tthhee kkeerrnneell uunnddeerr ggddbb + 11.1. Starting the kernel under gdb You can have the kernel running under the control of gdb from the beginning by putting 'debug' on the command line. You will get an @@ -2498,7 +2498,7 @@ There is a transcript of a debugging session here , with breakpoints being set in the scheduler and in an interrupt handler. - 1111..22.. EExxaammiinniinngg sslleeeeppiinngg pprroocceesssseess + 11.2. Examining sleeping processes Not every bug is evident in the currently running process. Sometimes, processes hang in the kernel when they shouldn't because they've @@ -2516,7 +2516,7 @@ Now what you do is this: - +o detach from the current thread + o detach from the current thread (UML gdb) det @@ -2525,7 +2525,7 @@ - +o attach to the thread you are interested in + o attach to the thread you are interested in (UML gdb) att @@ -2534,7 +2534,7 @@ - +o look at its stack and anything else of interest + o look at its stack and anything else of interest (UML gdb) bt @@ -2545,7 +2545,7 @@ Note that you can't do anything at this point that requires that a process execute, e.g. calling a function - +o when you're done looking at that process, reattach to the current + o when you're done looking at that process, reattach to the current thread and continue it @@ -2569,12 +2569,12 @@ - 1111..33.. RRuunnnniinngg dddddd oonn UUMMLL + 11.3. Running ddd on UML ddd works on UML, but requires a special kludge. The process goes like this: - +o Start ddd + o Start ddd host% ddd linux @@ -2583,14 +2583,14 @@ - +o With ps, get the pid of the gdb that ddd started. You can ask the + o With ps, get the pid of the gdb that ddd started. You can ask the gdb to tell you, but for some reason that confuses things and causes a hang. - +o run UML with 'debug=parent gdb-pid=' added to the command line + o run UML with 'debug=parent gdb-pid=' added to the command line - it will just sit there after you hit return - +o type 'att 1' to the ddd gdb and you will see something like + o type 'att 1' to the ddd gdb and you will see something like 0xa013dc51 in __kill () @@ -2602,12 +2602,12 @@ - +o At this point, type 'c', UML will boot up, and you can use ddd just + o At this point, type 'c', UML will boot up, and you can use ddd just as you do on any other process. - 1111..44.. DDeebbuuggggiinngg mmoodduulleess + 11.4. Debugging modules gdb has support for debugging code which is dynamically loaded into the process. This support is what is needed to debug kernel modules @@ -2823,7 +2823,7 @@ - 1111..55.. AAttttaacchhiinngg ggddbb ttoo tthhee kkeerrnneell + 11.5. Attaching gdb to the kernel If you don't have the kernel running under gdb, you can attach gdb to it later by sending the tracing thread a SIGUSR1. The first line of @@ -2857,7 +2857,7 @@ - 1111..66.. UUssiinngg aalltteerrnnaattee ddeebbuuggggeerrss + 11.6. Using alternate debuggers UML has support for attaching to an already running debugger rather than starting gdb itself. This is present in CVS as of 17 Apr 2001. @@ -2886,7 +2886,7 @@ An example of an alternate debugger is strace. You can strace the actual kernel as follows: - +o Run the following in a shell + o Run the following in a shell host% @@ -2894,10 +2894,10 @@ - +o Run UML with 'debug' and 'gdb-pid=' with the pid printed out + o Run UML with 'debug' and 'gdb-pid=' with the pid printed out by the previous command - +o Hit return in the shell, and UML will start running, and strace + o Hit return in the shell, and UML will start running, and strace output will start accumulating in the output file. Note that this is different from running @@ -2917,9 +2917,9 @@ - 1122.. KKeerrnneell ddeebbuuggggiinngg eexxaammpplleess + 12. Kernel debugging examples - 1122..11.. TThhee ccaassee ooff tthhee hhuunngg ffsscckk + 12.1. The case of the hung fsck When booting up the kernel, fsck failed, and dropped me into a shell to fix things up. I ran fsck -y, which hung: @@ -3154,9 +3154,9 @@ The interesting things here are : - +o There are two segfaults on this stack (frames 9 and 14) + o There are two segfaults on this stack (frames 9 and 14) - +o The first faulting address (frame 11) is 0x50000800 + o The first faulting address (frame 11) is 0x50000800 (gdb) p (void *)1342179328 $16 = (void *) 0x50000800 @@ -3399,7 +3399,7 @@ on will be somewhat clearer. - 1122..22.. EEppiissooddee 22:: TThhee ccaassee ooff tthhee hhuunngg ffsscckk + 12.2. Episode 2: The case of the hung fsck After setting a trap in the SEGV handler for accesses to the signal thread's stack, I reran the kernel. @@ -3788,12 +3788,12 @@ - 1133.. WWhhaatt ttoo ddoo wwhheenn UUMMLL ddooeessnn''tt wwoorrkk + 13. What to do when UML doesn't work - 1133..11.. SSttrraannggee ccoommppiillaattiioonn eerrrroorrss wwhheenn yyoouu bbuuiilldd ffrroomm ssoouurrccee + 13.1. Strange compilation errors when you build from source As of test11, it is necessary to have "ARCH=um" in the environment or on the make command line for all steps in building UML, including @@ -3824,8 +3824,8 @@ - 1133..33.. AA vvaarriieettyy ooff ppaanniiccss aanndd hhaannggss wwiitthh //ttmmpp oonn aa rreeiisseerrffss ffiilleessyyss-- - tteemm + 13.3. A variety of panics and hangs with /tmp on a reiserfs filesys- + tem I saw this on reiserfs 3.5.21 and it seems to be fixed in 3.5.27. Panics preceded by @@ -3842,8 +3842,8 @@ - 1133..44.. TThhee ccoommppiillee ffaaiillss wwiitthh eerrrroorrss aabboouutt ccoonnfflliiccttiinngg ttyyppeess ffoorr - ''ooppeenn'',, ''dduupp'',, aanndd ''wwaaiittppiidd'' + 13.4. The compile fails with errors about conflicting types for + 'open', 'dup', and 'waitpid' This happens when you build in /usr/src/linux. The UML build makes the include/asm link point to include/asm-um. /usr/include/asm points @@ -3854,14 +3854,14 @@ - 1133..55.. UUMMLL ddooeessnn''tt wwoorrkk wwhheenn //ttmmpp iiss aann NNFFSS ffiilleessyysstteemm + 13.5. UML doesn't work when /tmp is an NFS filesystem This seems to be a similar situation with the ReiserFS problem above. Some versions of NFS seems not to handle mmap correctly, which UML depends on. The workaround is have /tmp be a non-NFS directory. - 1133..66.. UUMMLL hhaannggss oonn bboooott wwhheenn ccoommppiilleedd wwiitthh ggpprrooff ssuuppppoorrtt + 13.6. UML hangs on boot when compiled with gprof support If you build UML with gprof support and, early in the boot, it does this @@ -3878,7 +3878,7 @@ - 1133..77.. ssyyssllooggdd ddiieess wwiitthh aa SSIIGGTTEERRMM oonn ssttaarrttuupp + 13.7. syslogd dies with a SIGTERM on startup The exact boot error depends on the distribution that you're booting, but Debian produces this: @@ -3897,17 +3897,17 @@ - 1133..88.. TTUUNN//TTAAPP nneettwwoorrkkiinngg ddooeessnn''tt wwoorrkk oonn aa 22..44 hhoosstt + 13.8. TUN/TAP networking doesn't work on a 2.4 host There are a couple of problems which were name="pointed out"> by Tim Robinson - +o It doesn't work on hosts running 2.4.7 (or thereabouts) or earlier. + o It doesn't work on hosts running 2.4.7 (or thereabouts) or earlier. The fix is to upgrade to something more recent and then read the next item. - +o If you see + o If you see File descriptor in bad state @@ -3921,8 +3921,8 @@ - 1133..99.. YYoouu ccaann nneettwwoorrkk ttoo tthhee hhoosstt bbuutt nnoott ttoo ootthheerr mmaacchhiinneess oonn tthhee - nneett + 13.9. You can network to the host but not to other machines on the + net If you can connect to the host, and the host can connect to UML, but you cannot connect to any other machines, then you may need to enable @@ -3972,7 +3972,7 @@ - 1133..1100.. II hhaavvee nnoo rroooott aanndd II wwaanntt ttoo ssccrreeaamm + 13.10. I have no root and I want to scream Thanks to Birgit Wahlich for telling me about this strange one. It turns out that there's a limit of six environment variables on the @@ -3987,7 +3987,7 @@ - 1133..1111.. UUMMLL bbuuiilldd ccoonnfflliicctt bbeettwweeeenn ppttrraaccee..hh aanndd uuccoonntteexxtt..hh + 13.11. UML build conflict between ptrace.h and ucontext.h On some older systems, /usr/include/asm/ptrace.h and /usr/include/sys/ucontext.h define the same names. So, when they're @@ -4007,7 +4007,7 @@ - 1133..1122.. TThhee UUMMLL BBooggooMMiippss iiss eexxaaccttllyy hhaallff tthhee hhoosstt''ss BBooggooMMiippss + 13.12. The UML BogoMips is exactly half the host's BogoMips On i386 kernels, there are two ways of running the loop that is used to calculate the BogoMips rating, using the TSC if it's there or using @@ -4019,7 +4019,7 @@ - 1133..1133.. WWhheenn yyoouu rruunn UUMMLL,, iitt iimmmmeeddiiaatteellyy sseeggffaauullttss + 13.13. When you run UML, it immediately segfaults If the host is configured with the 2G/2G address space split, that's why. See ``UML on 2G/2G hosts'' for the details on getting UML to @@ -4027,7 +4027,7 @@ - 1133..1144.. xxtteerrmmss aappppeeaarr,, tthheenn iimmmmeeddiiaatteellyy ddiissaappppeeaarr + 13.14. xterms appear, then immediately disappear If you're running an up to date kernel with an old release of uml_utilities, the port-helper program will not work properly, so @@ -4039,7 +4039,7 @@ - 1133..1155.. AAnnyy ootthheerr ppaanniicc,, hhaanngg,, oorr ssttrraannggee bbeehhaavviioorr + 13.15. Any other panic, hang, or strange behavior If you're seeing truly strange behavior, such as hangs or panics that happen in random places, or you try running the debugger to see what's @@ -4059,7 +4059,7 @@ If you want to be super-helpful, read ``Diagnosing Problems'' and follow the instructions contained therein. - 1144.. DDiiaaggnnoossiinngg PPrroobblleemmss + 14. Diagnosing Problems If you get UML to crash, hang, or otherwise misbehave, you should @@ -4078,7 +4078,7 @@ ``Kernel debugging'' UML first. - 1144..11.. CCaassee 11 :: NNoorrmmaall kkeerrnneell ppaanniiccss + 14.1. Case 1 : Normal kernel panics The most common case is for a normal thread to panic. To debug this, you will need to run it under the debugger (add 'debug' to the command @@ -4128,7 +4128,7 @@ to get that information from the faulting ip. - 1144..22.. CCaassee 22 :: TTrraacciinngg tthhrreeaadd ppaanniiccss + 14.2. Case 2 : Tracing thread panics The less common and more painful case is when the tracing thread panics. In this case, the kernel debugger will be useless because it @@ -4161,7 +4161,7 @@ backtrace in and wait for our crack debugging team to fix the problem. - 1144..33.. CCaassee 33 :: TTrraacciinngg tthhrreeaadd ppaanniiccss ccaauusseedd bbyy ootthheerr tthhrreeaaddss + 14.3. Case 3 : Tracing thread panics caused by other threads However, there are cases where the misbehavior of another thread caused the problem. The most common panic of this type is: @@ -4227,7 +4227,7 @@ - 1144..44.. CCaassee 44 :: HHaannggss + 14.4. Case 4 : Hangs Hangs seem to be fairly rare, but they sometimes happen. When a hang happens, we need a backtrace from the offending process. Run the @@ -4257,7 +4257,7 @@ - 1155.. TThhaannkkss + 15. Thanks A number of people have helped this project in various ways, and this @@ -4274,20 +4274,20 @@ bookkeeping lapses and I forget about contributions. - 1155..11.. CCooddee aanndd DDooccuummeennttaattiioonn + 15.1. Code and Documentation Rusty Russell - - +o wrote the HOWTO - +o prodded me into making this project official and putting it on + o prodded me into making this project official and putting it on SourceForge - +o came up with the way cool UML logo - +o redid the config process + o redid the config process Peter Moulder - Fixed my config and build @@ -4296,18 +4296,18 @@ Bill Stearns - - +o HOWTO updates + o HOWTO updates - +o lots of bug reports + o lots of bug reports - +o lots of testing + o lots of testing - +o dedicated a box (uml.ists.dartmouth.edu) to support UML development + o dedicated a box (uml.ists.dartmouth.edu) to support UML development - +o wrote the mkrootfs script, which allows bootable filesystems of + o wrote the mkrootfs script, which allows bootable filesystems of RPM-based distributions to be cranked out - +o cranked out a large number of filesystems with said script + o cranked out a large number of filesystems with said script Jim Leu - Wrote the virtual ethernet driver @@ -4375,176 +4375,176 @@ David Coulson - - +o Set up the usermodelinux.org site, + o Set up the usermodelinux.org site, which is a great way of keeping the UML user community on top of UML goings-on. - +o Site documentation and updates + o Site documentation and updates - +o Nifty little UML management daemon UMLd + o Nifty little UML management daemon UMLd - +o Lots of testing and bug reports + o Lots of testing and bug reports - 1155..22.. FFlluusshhiinngg oouutt bbuuggss + 15.2. Flushing out bugs - +o Yuri Pudgorodsky + o Yuri Pudgorodsky - +o Gerald Britton + o Gerald Britton - +o Ian Wehrman + o Ian Wehrman - +o Gord Lamb + o Gord Lamb - +o Eugene Koontz + o Eugene Koontz - +o John H. Hartman + o John H. Hartman - +o Anders Karlsson + o Anders Karlsson - +o Daniel Phillips + o Daniel Phillips - +o John Fremlin + o John Fremlin - +o Rainer Burgstaller + o Rainer Burgstaller - +o James Stevenson + o James Stevenson - +o Matt Clay + o Matt Clay - +o Cliff Jefferies + o Cliff Jefferies - +o Geoff Hoff + o Geoff Hoff - +o Lennert Buytenhek + o Lennert Buytenhek - +o Al Viro + o Al Viro - +o Frank Klingenhoefer + o Frank Klingenhoefer - +o Livio Baldini Soares + o Livio Baldini Soares - +o Jon Burgess + o Jon Burgess - +o Petru Paler + o Petru Paler - +o Paul + o Paul - +o Chris Reahard + o Chris Reahard - +o Sverker Nilsson + o Sverker Nilsson - +o Gong Su + o Gong Su - +o johan verrept + o johan verrept - +o Bjorn Eriksson + o Bjorn Eriksson - +o Lorenzo Allegrucci + o Lorenzo Allegrucci - +o Muli Ben-Yehuda + o Muli Ben-Yehuda - +o David Mansfield + o David Mansfield - +o Howard Goff + o Howard Goff - +o Mike Anderson + o Mike Anderson - +o John Byrne + o John Byrne - +o Sapan J. Batia + o Sapan J. Batia - +o Iris Huang + o Iris Huang - +o Jan Hudec + o Jan Hudec - +o Voluspa + o Voluspa - 1155..33.. BBuugglleettss aanndd cclleeaann--uuppss + 15.3. Buglets and clean-ups - +o Dave Zarzycki + o Dave Zarzycki - +o Adam Lazur + o Adam Lazur - +o Boria Feigin + o Boria Feigin - +o Brian J. Murrell + o Brian J. Murrell - +o JS + o JS - +o Roman Zippel + o Roman Zippel - +o Wil Cooley + o Wil Cooley - +o Ayelet Shemesh + o Ayelet Shemesh - +o Will Dyson + o Will Dyson - +o Sverker Nilsson + o Sverker Nilsson - +o dvorak + o dvorak - +o v.naga srinivas + o v.naga srinivas - +o Shlomi Fish + o Shlomi Fish - +o Roger Binns + o Roger Binns - +o johan verrept + o johan verrept - +o MrChuoi + o MrChuoi - +o Peter Cleve + o Peter Cleve - +o Vincent Guffens + o Vincent Guffens - +o Nathan Scott + o Nathan Scott - +o Patrick Caulfield + o Patrick Caulfield - +o jbearce + o jbearce - +o Catalin Marinas + o Catalin Marinas - +o Shane Spencer + o Shane Spencer - +o Zou Min + o Zou Min - +o Ryan Boder + o Ryan Boder - +o Lorenzo Colitti + o Lorenzo Colitti - +o Gwendal Grignou + o Gwendal Grignou - +o Andre' Breiler + o Andre' Breiler - +o Tsutomu Yasuda + o Tsutomu Yasuda - 1155..44.. CCaassee SSttuuddiieess + 15.4. Case Studies - +o Jon Wright + o Jon Wright - +o William McEwan + o William McEwan - +o Michael Richardson + o Michael Richardson - 1155..55.. OOtthheerr ccoonnttrriibbuuttiioonnss + 15.5. Other contributions Bill Carr made the Red Hat mkrootfs script -- cgit v1.1 From c039aff672a540f8976770e74599d350de1805cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Mon, 15 Aug 2011 15:34:10 +0200 Subject: UserModeLinux-HOWTO.txt: fix a typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jonathan Neuschäfer Signed-off-by: Richard Weinberger --- Documentation/virtual/uml/UserModeLinux-HOWTO.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index a7af9cf..77dfecf 100644 --- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt @@ -770,7 +770,7 @@ - will cause serial line 3 to accept input on the host's /dev/tty3 and + will cause serial line 3 to accept input on the host's /dev/tty2 and display output on an xterm. That's a silly example - the most common use of this syntax is to reattach the main console to stdin and stdout as shown above. -- cgit v1.1 From 9b272977e3b99a8699361d214b51f98c8a9e0e7b Mon Sep 17 00:00:00 2001 From: Johannes Weiner Date: Wed, 2 Nov 2011 13:38:23 -0700 Subject: memcg: skip scanning active lists based on individual size Reclaim decides to skip scanning an active list when the corresponding inactive list is above a certain size in comparison to leave the assumed working set alone while there are still enough reclaim candidates around. The memcg implementation of comparing those lists instead reports whether the whole memcg is low on the requested type of inactive pages, considering all nodes and zones. This can lead to an oversized active list not being scanned because of the state of the other lists in the memcg, as well as an active list being scanned while its corresponding inactive list has enough pages. Not only is this wrong, it's also a scalability hazard, because the global memory state over all nodes and zones has to be gathered for each memcg and zone scanned. Make these calculations purely based on the size of the two LRU lists that are actually affected by the outcome of the decision. Signed-off-by: Johannes Weiner Reviewed-by: Rik van Riel Cc: KOSAKI Motohiro Acked-by: KAMEZAWA Hiroyuki Cc: Daisuke Nishimura Cc: Balbir Singh Reviewed-by: Minchan Kim Reviewed-by: Ying Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/memory.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 06eb6d9..cc0ebc5 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -418,7 +418,6 @@ total_unevictable - sum of all children's "unevictable" # The following additional stats are dependent on CONFIG_DEBUG_VM. -inactive_ratio - VM internal parameter. (see mm/page_alloc.c) recent_rotated_anon - VM internal parameter. (see mm/vmscan.c) recent_rotated_file - VM internal parameter. (see mm/vmscan.c) recent_scanned_anon - VM internal parameter. (see mm/vmscan.c) -- cgit v1.1 From 48618fb4e522d9d02e217ac05f52749545c1af20 Mon Sep 17 00:00:00 2001 From: Alexandre Bounine Date: Wed, 2 Nov 2011 13:39:09 -0700 Subject: RapidIO: add mport driver for Tsi721 bridge Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge device. The driver provides full set of callback functions defined for mport devices in RapidIO subsystem. It also is compatible with current version of RIONET driver (Ethernet over RapidIO messaging services). This patch is applicable to kernel versions starting from 2.6.39. Signed-off-by: Alexandre Bounine Signed-off-by: Chul Kim Cc: Kumar Gala Cc: Matt Porter Cc: Li Yang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/rapidio/tsi721.txt | 49 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/rapidio/tsi721.txt (limited to 'Documentation') diff --git a/Documentation/rapidio/tsi721.txt b/Documentation/rapidio/tsi721.txt new file mode 100644 index 0000000..335f3c6 --- /dev/null +++ b/Documentation/rapidio/tsi721.txt @@ -0,0 +1,49 @@ +RapidIO subsystem mport driver for IDT Tsi721 PCI Express-to-SRIO bridge. +========================================================================= + +I. Overview + +This driver implements all currently defined RapidIO mport callback functions. +It supports maintenance read and write operations, inbound and outbound RapidIO +doorbells, inbound maintenance port-writes and RapidIO messaging. + +To generate SRIO maintenance transactions this driver uses one of Tsi721 DMA +channels. This mechanism provides access to larger range of hop counts and +destination IDs without need for changes in outbound window translation. + +RapidIO messaging support uses dedicated messaging channels for each mailbox. +For inbound messages this driver uses destination ID matching to forward messages +into the corresponding message queue. Messaging callbacks are implemented to be +fully compatible with RIONET driver (Ethernet over RapidIO messaging services). + +II. Known problems + + None. + +III. To do + + Add DMA data transfers (non-messaging). + Add inbound region (SRIO-to-PCIe) mapping. + +IV. Version History + + 1.0.0 - Initial driver release. + +V. License +----------------------------------------------- + + Copyright(c) 2011 Integrated Device Technology, Inc. All rights reserved. + + This program is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your option) + any later version. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., + 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -- cgit v1.1 From 088024b1deee206cd37eff980138e918837aabdb Mon Sep 17 00:00:00 2001 From: Alexandre Bounine Date: Wed, 2 Nov 2011 13:39:19 -0700 Subject: RapidIO: documentation update Update rapidio.txt to reflect changes from recent patch. See http://marc.info/?l=linux-kernel&m=131285620113589&w=2 for details. Signed-off-by: Alexandre Bounine Cc: Liu Gang Cc: Micha Nelissen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/rapidio/rapidio.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt index be70ee1..c75694b 100644 --- a/Documentation/rapidio/rapidio.txt +++ b/Documentation/rapidio/rapidio.txt @@ -144,7 +144,7 @@ and the default device ID in order to access the device on the active port. After the host has completed enumeration of the entire network it releases devices by clearing device ID locks (calls rio_clear_locks()). For each endpoint -in the system, it sets the Master Enable bit in the Port General Control CSR +in the system, it sets the Discovered bit in the Port General Control CSR to indicate that enumeration is completed and agents are allowed to execute passive discovery of the network. -- cgit v1.1 From c736de60aed869df8a9aba512cdaf89e32545b00 Mon Sep 17 00:00:00 2001 From: WANG Cong Date: Wed, 2 Nov 2011 13:39:25 -0700 Subject: sysctl: make CONFIG_SYSCTL_SYSCALL default to n When I tried to send a patch to remove it, Andi told me we still need to keep compabitlies for old libc, so we can't remove this completely. Then just make it default to n and remove the doc from feature-removal-schedule.txt. Signed-off-by: WANG Cong Cc: Eric Biederman Cc: Andi Kleen Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 35 ------------------------------ 1 file changed, 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 7c799fc..3d84912 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -133,41 +133,6 @@ Who: Pavel Machek --------------------------- -What: sys_sysctl -When: September 2010 -Option: CONFIG_SYSCTL_SYSCALL -Why: The same information is available in a more convenient from - /proc/sys, and none of the sysctl variables appear to be - important performance wise. - - Binary sysctls are a long standing source of subtle kernel - bugs and security issues. - - When I looked several months ago all I could find after - searching several distributions were 5 user space programs and - glibc (which falls back to /proc/sys) using this syscall. - - The man page for sysctl(2) documents it as unusable for user - space programs. - - sysctl(2) is not generally ABI compatible to a 32bit user - space application on a 64bit and a 32bit kernel. - - For the last several months the policy has been no new binary - sysctls and no one has put forward an argument to use them. - - Binary sysctls issues seem to keep happening appearing so - properly deprecating them (with a warning to user space) and a - 2 year grace warning period will mean eventually we can kill - them and end the pain. - - In the mean time individual binary sysctls can be dealt with - in a piecewise fashion. - -Who: Eric Biederman - ---------------------------- - What: /proc//oom_adj When: August 2012 Why: /proc//oom_adj allows userspace to influence the oom killer's -- cgit v1.1 From 842fa69f3e0c9a178b294e7af7c07f4c9d9e7af2 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Wed, 2 Nov 2011 13:39:33 -0700 Subject: include/linux/dma-mapping.h: add dma_zalloc_coherent() Lots of driver code does a dma_alloc_coherent() and then zeroes out the memory with a memset. Make it easy for them. Cc: Alexandre Bounine Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DMA-API.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index fe23269..66bd97a 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -50,6 +50,13 @@ specify the GFP_ flags (see kmalloc) for the allocation (the implementation may choose to ignore flags that affect the location of the returned memory, like GFP_DMA). +void * +dma_zalloc_coherent(struct device *dev, size_t size, + dma_addr_t *dma_handle, gfp_t flag) + +Wraps dma_alloc_coherent() and also zeroes the returned memory if the +allocation attempt succeeded. + void dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_handle) -- cgit v1.1 From 02aac316abf436a7529d46a71f7083f9f9ef4b49 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Wed, 3 Nov 2010 21:04:59 -0500 Subject: ahci: add DT binding for Calxeda AHCI controller Add devicetree match table to ahci platform driver for Calxeda Highbank AHCI controller. Signed-off-by: Rob Herring Acked-by: Grant Likely Cc: Jeff Garzik Cc: linux-ide@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Documentation/devicetree/bindings/ata/calxeda-sata.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/calxeda-sata.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/calxeda-sata.txt b/Documentation/devicetree/bindings/ata/calxeda-sata.txt new file mode 100644 index 0000000..79caa56 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/calxeda-sata.txt @@ -0,0 +1,17 @@ +* Calxeda SATA Controller + +SATA nodes are defined to describe on-chip Serial ATA controllers. +Each SATA controller should have its own node. + +Required properties: +- compatible : compatible list, contains "calxeda,hb-ahci" +- interrupts : +- reg : + +Example: + sata@ffe08000 { + compatible = "calxeda,hb-ahci"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; + }; + -- cgit v1.1 From eff7687d473c31cba3876c13e97eebc708eb8582 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Fri, 4 Nov 2011 12:00:48 +0100 Subject: hwmon: (w83627ehf) Add support for the W83627UHG This is essentially a stripped down version of the W83627DHG. Noticeable difference is that it is still powered with +5V, as older models, even though the ADC resolution is 8 mV as newer models have. Thanks to Ulf Bruman (Saab Group) for doing all the testing. Signed-off-by: Jean Delvare Acked-by: Guenter Roeck --- Documentation/hwmon/w83627ehf | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index 76ffef9..3f44dbd 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf @@ -14,6 +14,10 @@ Supported chips: Prefix: 'w83627dhg' Addresses scanned: ISA address retrieved from Super I/O registers Datasheet: not available + * Winbond W83627UHG + Prefix: 'w83627uhg' + Addresses scanned: ISA address retrieved from Super I/O registers + Datasheet: available from www.nuvoton.com * Winbond W83667HG Prefix: 'w83667hg' Addresses scanned: ISA address retrieved from Super I/O registers @@ -42,14 +46,13 @@ Description ----------- This driver implements support for the Winbond W83627EHF, W83627EHG, -W83627DHG, W83627DHG-P, W83667HG, W83667HG-B, W83667HG-I (NCT6775F), -and NCT6776F super I/O chips. We will refer to them collectively as -Winbond chips. - -The chips implement three temperature sensors (up to four for 667HG-B, and nine -for NCT6775F and NCT6776F), five fan rotation speed sensors, ten analog voltage -sensors (only nine for the 627DHG), one VID (6 pins for the 627EHF/EHG, 8 pins -for the 627DHG and 667HG), alarms with beep warnings (control unimplemented), +W83627DHG, W83627DHG-P, W83627UHG, W83667HG, W83667HG-B, W83667HG-I +(NCT6775F), and NCT6776F super I/O chips. We will refer to them collectively +as Winbond chips. + +The chips implement 2 to 4 temperature sensors (9 for NCT6775F and NCT6776F), +2 to 5 fan rotation speed sensors, 8 to 10 analog voltage sensors, one VID +(except for 627UHG), alarms with beep warnings (control unimplemented), and some automatic fan regulation strategies (plus manual fan control mode). The temperature sensor sources on W82677HG-B, NCT6775F, and NCT6776F are @@ -86,17 +89,16 @@ follows: temp1 -> pwm1 temp2 -> pwm2 -temp3 -> pwm3 +temp3 -> pwm3 (not on 627UHG) prog -> pwm4 (not on 667HG and 667HG-B; the programmable setting is not supported by the driver) /sys files ---------- -name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG, - it is set to "w83627ehf", for the W83627DHG it is set to "w83627dhg", - for the W83667HG and W83667HG-B it is set to "w83667hg", for NCT6775F it - is set to "nct6775", and for NCT6776F it is set to "nct6776". +name - this is a standard hwmon device entry, it contains the name of + the device (see the prefix in the list of supported devices at + the top of this file) pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: 0 (stop) to 255 (full) -- cgit v1.1 From 5fe69d7e258a17d825d982ac695c1db5c4bc4768 Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Fri, 4 Nov 2011 11:22:05 -0700 Subject: Documentation: update cgroups notes - ns cgroup has been removed. - it's true moving a task to another cgroup can fail. Signed-off-by: Li Zefan Acked-by: Paul Menage Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/cgroups/cgroups.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index cd67e90..9c452ef 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must move it into a new cgroup (possibly the root cgroup) by writing to the new cgroup's tasks file. -Note: If the ns cgroup is active, moving a process to another cgroup can -fail. +Note: Due to some restrictions enforced by some cgroup subsystems, moving +a process to another cgroup can fail. 2.3 Mounting hierarchies by name -------------------------------- -- cgit v1.1 From 123aeec2ff5f749e92f8e3dd2d42f7a9948ca037 Mon Sep 17 00:00:00 2001 From: Kumar Appaiah Date: Fri, 4 Nov 2011 11:22:09 -0700 Subject: Documentation: thinkpad-acpi grammo fixes This adds minor grammatical fixes to the description of the keys in the thinkpad-acpi documentation. Signed-off-by: Kumar Appaiah Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/laptops/thinkpad-acpi.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 3ff0dad..9d66682 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -411,9 +411,9 @@ event code Key Notes 0x1004 0x03 FN+F4 Sleep button (ACPI sleep button semantics, i.e. sleep-to-RAM). - It is always generate some kind + It always generates some kind of event, either the hot key - event or a ACPI sleep button + event or an ACPI sleep button event. The firmware may refuse to generate further FN+F4 key presses until a S3 or S4 ACPI -- cgit v1.1 From d83fe6b6c54749a9b2d3198d62ec981024459425 Mon Sep 17 00:00:00 2001 From: Marcos Paulo de Souza Date: Fri, 4 Nov 2011 11:22:14 -0700 Subject: Documentation: fix inotify source file paths Fixes the path to find the source files of the inotify subsystem. Signed-off-by: Marcos Paulo de Souza Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/filesystems/inotify.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/inotify.txt b/Documentation/filesystems/inotify.txt index 59a919f..cfd0271 100644 --- a/Documentation/filesystems/inotify.txt +++ b/Documentation/filesystems/inotify.txt @@ -194,7 +194,8 @@ associated with the inotify_handle, and on which events are queued. Each watch is associated with an inotify_watch structure. Watches are chained off of each associated inotify_handle and each associated inode. -See fs/inotify.c and fs/inotify_user.c for the locking and lifetime rules. +See fs/notify/inotify/inotify_fsnotify.c and fs/notify/inotify/inotify_user.c +for the locking and lifetime rules. (vi) Rationale -- cgit v1.1 From b218ab0a5af943441e1daa7dc811874ecd409229 Mon Sep 17 00:00:00 2001 From: Antonio Ospite Date: Fri, 4 Nov 2011 11:22:19 -0700 Subject: Documentation: update CodingStyle use of braces After commit 38829dc9d7b4 ("Documentation/CodingStyle: flesh out if-else examples") highlight that if _only_one_ branch of a conditional statement is a single statement, then braces are to be used on both branches. Signed-off-by: Antonio Ospite Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/CodingStyle | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index c940239..2b90d32 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -166,8 +166,8 @@ if (condition) else do_that(); -This does not apply if one branch of a conditional statement is a single -statement. Use braces in both branches. +This does not apply if only one branch of a conditional statement is a single +statement; in the latter case use braces in both branches: if (condition) { do_this(); -- cgit v1.1 From ab05210bcba83b1fe2702eac7d4d453a97855c26 Mon Sep 17 00:00:00 2001 From: Marcos Paulo de Souza Date: Fri, 4 Nov 2011 11:22:22 -0700 Subject: Documentation: HFS is orphaned Removed the reference of Roman Zippel, last maintainer, of orphaned HFS filesystem. Signed-off-by: Marcos Paulo de Souza Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/filesystems/hfs.txt | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/hfs.txt b/Documentation/filesystems/hfs.txt index bd0fa770..d096df6 100644 --- a/Documentation/filesystems/hfs.txt +++ b/Documentation/filesystems/hfs.txt @@ -1,3 +1,4 @@ +Note: This filesystem doesn't have a maintainer. Macintosh HFS Filesystem for Linux ================================== @@ -76,8 +77,6 @@ hformat that can be used to create HFS filesystem. See Credits ======= -The HFS drivers was written by Paul H. Hargrovea (hargrove@sccm.Stanford.EDU) -and is now maintained by Roman Zippel (roman@ardistech.com) at Ardis -Technologies. -Roman rewrote large parts of the code and brought in btree routines derived -from Brad Boyer's hfsplus driver (also maintained by Roman now). +The HFS drivers was written by Paul H. Hargrovea (hargrove@sccm.Stanford.EDU). +Roman Zippel (roman@ardistech.com) rewrote large parts of the code and brought +in btree routines derived from Brad Boyer's hfsplus driver. -- cgit v1.1 From b670722009d52c79aea8ff7ed561365ee21ff58c Mon Sep 17 00:00:00 2001 From: Marcos Paulo Souza Date: Fri, 4 Nov 2011 11:22:26 -0700 Subject: Documentation: Computone ip2 is orphaned Removed the email for support and fixes for orphaned ip2 driver. Signed-off-by: Marcos Paulo de Souza Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/serial/computone.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/serial/computone.txt b/Documentation/serial/computone.txt index 60a6f65..39ddcdb 100644 --- a/Documentation/serial/computone.txt +++ b/Documentation/serial/computone.txt @@ -20,8 +20,6 @@ Version: 1.2.14 Date: 11/01/2001 Historical Author: Andrew Manison Primary Author: Doug McNash -Support: support@computone.com -Fixes and Updates: Mike Warfield This file assumes that you are using the Computone drivers which are integrated into the kernel sources. For updating the drivers or installing -- cgit v1.1 From ee31892aaf47f1b5fd1323c9397db5d3f22d8b9e Mon Sep 17 00:00:00 2001 From: Bryan Wu Date: Fri, 4 Nov 2011 11:22:29 -0700 Subject: Documentation: fix leds-class.txt duplicated word Fix a typo (duplicated word) in Documentation/leds/leds-class.txt Signed-off-by: Bryan Wu Acked-by: Richard Purdie Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/leds/leds-class.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index 4996586..79699c2 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -61,8 +61,8 @@ Hardware accelerated blink of LEDs Some LEDs can be programmed to blink without any CPU interaction. To support this feature, a LED driver can optionally implement the blink_set() function (see ). To set an LED to blinking, -however, it is better to use use the API function led_blink_set(), -as it will check and implement software fallback if necessary. +however, it is better to use the API function led_blink_set(), as it +will check and implement software fallback if necessary. To turn off blinking again, use the API function led_brightness_set() as that will not just set the LED brightness but also stop any software -- cgit v1.1 From b31966816dcd3d8b16109f39d7c7501dc9abb010 Mon Sep 17 00:00:00 2001 From: Wang Sheng-Hui Date: Fri, 4 Nov 2011 11:22:33 -0700 Subject: Documentation: drop as block elevator reference in switching-sched.txt Remove 'as' for as is no longer supported, and we can not use 'elevator=as' any more. Signed-off-by: Wang Sheng-Hui Signed-off-by: Randy Dunlap Cc: Jens Axboe Signed-off-by: Linus Torvalds --- Documentation/block/switching-sched.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/switching-sched.txt b/Documentation/block/switching-sched.txt index 71cfbdc..3b2612e 100644 --- a/Documentation/block/switching-sched.txt +++ b/Documentation/block/switching-sched.txt @@ -1,6 +1,6 @@ To choose IO schedulers at boot time, use the argument 'elevator=deadline'. -'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are -assigned globally at boot time only presently. +'noop' and 'cfq' (the default) are also available. IO schedulers are assigned +globally at boot time only presently. Each io queue has a set of io scheduler tunables associated with it. These tunables control how the io scheduler works. You can find these entries -- cgit v1.1 From e9db50b839c592fcd22952d7f1dccbd0a56da57d Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Thu, 3 Nov 2011 00:59:52 +0100 Subject: PM / Sleep: Update freezer documentation This patch: * Substitutes some obsolete references to kernel/power/process.c by kernel/freezer.c. * Mentions kernel/freezer.c as being part of the "freezer" code along with the rest of the files. * Fixes a trivial typo. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki --- Documentation/power/freezing-of-tasks.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index 38b5724..316c2ba 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt @@ -22,12 +22,12 @@ try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and either wakes them up, if they are kernel threads, or sends fake signals to them, if they are user space processes. A task that has TIF_FREEZE set, should react to it by calling the function called refrigerator() (defined in -kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state +kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it. Then, we say that the task is 'frozen' and therefore the set of functions handling this mechanism is referred to as 'the freezer' (these functions are -defined in kernel/power/process.c and include/linux/freezer.h). User space -processes are generally frozen before kernel threads. +defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h). +User space processes are generally frozen before kernel threads. It is not recommended to call refrigerator() directly. Instead, it is recommended to use the try_to_freeze() function (defined in @@ -95,7 +95,7 @@ after the memory for the image has been freed, we don't want tasks to allocate additional memory and we prevent them from doing that by freezing them earlier. [Of course, this also means that device drivers should not allocate substantial amounts of memory from their .suspend() callbacks before hibernation, but this -is e separate issue.] +is a separate issue.] 3. The third reason is to prevent user space processes and some kernel threads from interfering with the suspending and resuming of devices. A user space -- cgit v1.1 From 886486b792e4f6f96d4fbe8ec5bf20811cab7d6a Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Thu, 3 Nov 2011 23:39:18 +0100 Subject: PM / Runtime: Automatically retry failed autosuspends Originally, the runtime PM core would send an idle notification whenever a suspend attempt failed. The idle callback routine could then schedule a delayed suspend for some time later. However this behavior was changed by commit f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle notification after failing suspend). No notifications were sent, and there was no clear mechanism to retry failed suspends. This caused problems for the usbhid driver, because it fails autosuspend attempts as long as a key is being held down. Therefore this patch (as1492) adds a mechanism for retrying failed autosuspends. If the callback routine updates the last_busy field so that the next autosuspend expiration time is in the future, the autosuspend will automatically be rescheduled. Signed-off-by: Alan Stern Tested-by: Henrik Rydberg Cc: Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 0e85608..5336149 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -789,6 +789,16 @@ will behave normally, not taking the autosuspend delay into account. Similarly, if the power.use_autosuspend field isn't set then the autosuspend helper functions will behave just like the non-autosuspend counterparts. +Under some circumstances a driver or subsystem may want to prevent a device +from autosuspending immediately, even though the usage counter is zero and the +autosuspend delay time has expired. If the ->runtime_suspend() callback +returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is +in the future (as it normally would be if the callback invoked +pm_runtime_mark_last_busy()), the PM core will automatically reschedule the +autosuspend. The ->runtime_suspend() callback can't do this rescheduling +itself because no suspend requests of any kind are accepted while the device is +suspending (i.e., while the callback is running). + The implementation is well suited for asynchronous use in interrupt contexts. However such use inevitably involves races, because the PM core can't synchronize ->runtime_suspend() callbacks with the arrival of I/O requests. -- cgit v1.1 From 74cd4c67392c1cee0499ba0977ec843252c7af28 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Mon, 26 Sep 2011 15:40:13 +0200 Subject: Documentation: watchdog: add guide how to convert drivers to new framework Signed-off-by: Wolfram Sang Cc: Randy Dunlap Signed-off-by: Wim Van Sebroeck --- .../watchdog/convert_drivers_to_kernel_api.txt | 195 +++++++++++++++++++++ 1 file changed, 195 insertions(+) create mode 100644 Documentation/watchdog/convert_drivers_to_kernel_api.txt (limited to 'Documentation') diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.txt b/Documentation/watchdog/convert_drivers_to_kernel_api.txt new file mode 100644 index 0000000..ae1e900 --- /dev/null +++ b/Documentation/watchdog/convert_drivers_to_kernel_api.txt @@ -0,0 +1,195 @@ +Converting old watchdog drivers to the watchdog framework +by Wolfram Sang +========================================================= + +Before the watchdog framework came into the kernel, every driver had to +implement the API on its own. Now, as the framework factored out the common +components, those drivers can be lightened making it a user of the framework. +This document shall guide you for this task. The necessary steps are described +as well as things to look out for. + + +Remove the file_operations struct +--------------------------------- + +Old drivers define their own file_operations for actions like open(), write(), +etc... These are now handled by the framework and just call the driver when +needed. So, in general, the 'file_operations' struct and assorted functions can +go. Only very few driver-specific details have to be moved to other functions. +Here is a overview of the functions and probably needed actions: + +- open: Everything dealing with resource management (file-open checks, magic + close preparations) can simply go. Device specific stuff needs to go to the + driver specific start-function. Note that for some drivers, the start-function + also serves as the ping-function. If that is the case and you need start/stop + to be balanced (clocks!), you are better off refactoring a separate start-function. + +- close: Same hints as for open apply. + +- write: Can simply go, all defined behaviour is taken care of by the framework, + i.e. ping on write and magic char ('V') handling. + +- ioctl: While the driver is allowed to have extensions to the IOCTL interface, + the most common ones are handled by the framework, supported by some assistance + from the driver: + + WDIOC_GETSUPPORT: + Returns the mandatory watchdog_info struct from the driver + + WDIOC_GETSTATUS: + Needs the status-callback defined, otherwise returns 0 + + WDIOC_GETBOOTSTATUS: + Needs the bootstatus member properly set. Make sure it is 0 if you + don't have further support! + + WDIOC_SETOPTIONS: + No preparations needed + + WDIOC_KEEPALIVE: + If wanted, options in watchdog_info need to have WDIOF_KEEPALIVEPING + set + + WDIOC_SETTIMEOUT: + Options in watchdog_info need to have WDIOF_SETTIMEOUT set + and a set_timeout-callback has to be defined. The core will also + do limit-checking, if min_timeout and max_timeout in the watchdog + device are set. All is optional. + + WDIOC_GETTIMEOUT: + No preparations needed + + Other IOCTLs can be served using the ioctl-callback. Note that this is mainly + intended for porting old drivers; new drivers should not invent private IOCTLs. + Private IOCTLs are processed first. When the callback returns with + -ENOIOCTLCMD, the IOCTLs of the framework will be tried, too. Any other error + is directly given to the user. + +Example conversion: + +-static const struct file_operations s3c2410wdt_fops = { +- .owner = THIS_MODULE, +- .llseek = no_llseek, +- .write = s3c2410wdt_write, +- .unlocked_ioctl = s3c2410wdt_ioctl, +- .open = s3c2410wdt_open, +- .release = s3c2410wdt_release, +-}; + +Check the functions for device-specific stuff and keep it for later +refactoring. The rest can go. + + +Remove the miscdevice +--------------------- + +Since the file_operations are gone now, you can also remove the 'struct +miscdevice'. The framework will create it on watchdog_dev_register() called by +watchdog_register_device(). + +-static struct miscdevice s3c2410wdt_miscdev = { +- .minor = WATCHDOG_MINOR, +- .name = "watchdog", +- .fops = &s3c2410wdt_fops, +-}; + + +Remove obsolete includes and defines +------------------------------------ + +Because of the simplifications, a few defines are probably unused now. Remove +them. Includes can be removed, too. For example: + +- #include +- #include (if MODULE_ALIAS_MISCDEV is not used) +- #include (if no custom IOCTLs are used) + + +Add the watchdog operations +--------------------------- + +All possible callbacks are defined in 'struct watchdog_ops'. You can find it +explained in 'watchdog-kernel-api.txt' in this directory. start(), stop() and +owner must be set, the rest are optional. You will easily find corresponding +functions in the old driver. Note that you will now get a pointer to the +watchdog_device as a parameter to these functions, so you probably have to +change the function header. Other changes are most likely not needed, because +here simply happens the direct hardware access. If you have device-specific +code left from the above steps, it should be refactored into these callbacks. + +Here is a simple example: + ++static struct watchdog_ops s3c2410wdt_ops = { ++ .owner = THIS_MODULE, ++ .start = s3c2410wdt_start, ++ .stop = s3c2410wdt_stop, ++ .ping = s3c2410wdt_keepalive, ++ .set_timeout = s3c2410wdt_set_heartbeat, ++}; + +A typical function-header change looks like: + +-static void s3c2410wdt_keepalive(void) ++static int s3c2410wdt_keepalive(struct watchdog_device *wdd) + { +... ++ ++ return 0; + } + +... + +- s3c2410wdt_keepalive(); ++ s3c2410wdt_keepalive(&s3c2410_wdd); + + +Add the watchdog device +----------------------- + +Now we need to create a 'struct watchdog_device' and populate it with the +necessary information for the framework. The struct is also explained in detail +in 'watchdog-kernel-api.txt' in this directory. We pass it the mandatory +watchdog_info struct and the newly created watchdog_ops. Often, old drivers +have their own record-keeping for things like bootstatus and timeout using +static variables. Those have to be converted to use the members in +watchdog_device. Note that the timeout values are unsigned int. Some drivers +use signed int, so this has to be converted, too. + +Here is a simple example for a watchdog device: + ++static struct watchdog_device s3c2410_wdd = { ++ .info = &s3c2410_wdt_ident, ++ .ops = &s3c2410wdt_ops, ++}; + + +Register the watchdog device +---------------------------- + +Replace misc_register(&miscdev) with watchdog_register_device(&watchdog_dev). +Make sure the return value gets checked and the error message, if present, +still fits. Also convert the unregister case. + +- ret = misc_register(&s3c2410wdt_miscdev); ++ ret = watchdog_register_device(&s3c2410_wdd); + +... + +- misc_deregister(&s3c2410wdt_miscdev); ++ watchdog_unregister_device(&s3c2410_wdd); + + +Update the Kconfig-entry +------------------------ + +The entry for the driver now needs to select WATCHDOG_CORE: + ++ select WATCHDOG_CORE + + +Create a patch and send it to upstream +-------------------------------------- + +Make sure you understood Documentation/SubmittingPatches and send your patch to +linux-watchdog@vger.kernel.org. We are looking forward to it :) + -- cgit v1.1 From 2449b8ba0745327c5fa49a8d9acffe03b2eded69 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Mon, 24 Oct 2011 15:12:28 +0200 Subject: module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree Use of the GPL or a compatible licence doesn't necessarily make the code any good. We already consider staging modules to be suspect, and this should also be true for out-of-tree modules which may receive very little review. Signed-off-by: Ben Hutchings Reviewed-by: Dave Jones Acked-by: Greg Kroah-Hartman Signed-off-by: Rusty Russell (patched oops-tracing.txt) --- Documentation/oops-tracing.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index 6fe9001..13032c0 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -263,6 +263,8 @@ characters, each representing a particular tainted value. 12: 'I' if the kernel is working around a severe bug in the platform firmware (BIOS or similar). + 13: 'O' if an externally-built ("out-of-tree") module has been loaded. + The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred. Tainting is permanent: even if an offending module is -- cgit v1.1 From 362b646062b2073bd5c38efb42171d86e4f717e6 Mon Sep 17 00:00:00 2001 From: Thomas Renninger Date: Fri, 4 Nov 2011 03:33:46 +0100 Subject: ACPI: Export FADT pm_profile integer value to userspace There are a lot userspace approaches to detect the usage of the platform (laptop, workstation, server, ...) and adjust kernel tunables accordingly (io/process scheduler, power management, ...). These approaches need constant maintaining and are ugly to implement (detect PCMCIA controller -> laptop, does not work on recent systems anymore, ...) On ACPI systems there is an easy and reliable way (if implemented in BIOS and most recent platforms have this value set). -> export it to userspace. Signed-off-by: Thomas Renninger Acked-by: Rafael J. Wysocki Signed-off-by: Len Brown --- Documentation/ABI/stable/sysfs-acpi-pmprofile | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-acpi-pmprofile (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile new file mode 100644 index 0000000..964c7a8 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -0,0 +1,22 @@ +What: /sys/firmware/acpi/pm_profile +Date: 03-Nov-2011 +KernelVersion: v3.2 +Contact: linux-acpi@vger.kernel.org +Description: The ACPI pm_profile sysfs interface exports the platform + power management (and performance) requirement expectations + as provided by BIOS. The integer value is directly passed as + retrieved from the FADT ACPI table. +Values: For possible values see ACPI specification: + 5.2.9 Fixed ACPI Description Table (FADT) + Field: Preferred_PM_Profile + + Currently these values are defined by spec: + 0 Unspecified + 1 Desktop + 2 Mobile + 3 Workstation + 4 Enterprise Server + 5 SOHO Server + 6 Appliance PC + 7 Performance Server + >7 Reserved -- cgit v1.1 From 5f11161675be1351cadb96c83850e20bf5bcdc48 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sun, 6 Nov 2011 22:00:20 +0100 Subject: Documentation: Fix typo in freezer-subsystem.txt Fix a typo in Documentation/cgroups/freezer-subsystem.txt. Signed-off-by: Rafael J. Wysocki Reviewed-by: Srivatsa S. Bhat Acked-by: Randy Dunlap --- Documentation/cgroups/freezer-subsystem.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index c21d777..7e62de1 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt @@ -33,9 +33,9 @@ demonstrate this problem using nested bash shells: From a second, unrelated bash shell: $ kill -SIGSTOP 16690 - $ kill -SIGCONT 16990 + $ kill -SIGCONT 16690 - + This happens because bash can observe both signals and choose how it responds to them. -- cgit v1.1 From f7f9bdfadfda07afb904a9767468e38c2d1a6033 Mon Sep 17 00:00:00 2001 From: Julian Wollrath Date: Wed, 9 Nov 2011 10:02:40 +0100 Subject: ALSA: hda - fix internal mic on Dell Vostro 3500 laptop Fix the not working internal mic on Dell Vostro 3500 laptop by introducing the new model dell-vostro-3500. Signed-off-by: Julian Wollrath Cc: Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 4f34432..edad99a 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -349,6 +349,7 @@ STAC92HD83* ref Reference board mic-ref Reference board with power management for ports dell-s14 Dell laptop + dell-vostro-3500 Dell Vostro 3500 laptop hp HP laptops with (inverted) mute-LED hp-dv7-4000 HP dv-7 4000 auto BIOS setup (default) -- cgit v1.1