1. 16 Jan, 2006 1 commit
  2. 15 Jan, 2006 7 commits
  3. 14 Jan, 2006 6 commits
    • Xose Vazquez Perez's avatar
      [PATCH] docs: update some updated code docs · e1b114ee
      Xose Vazquez Perez authored
      Based on comments from Randy Dunlap on my previous commit
      5b0ed2c6Signed-off-by: default avatarLinus Torvalds <[email protected]>
      e1b114ee
    • David Brownell's avatar
      [PATCH] SPI: add spi_butterfly driver · 2e10c84b
      David Brownell authored
      This adds a bitbanging parport based adaptor cable for AVR Butterfly, giving
      SPI links to its DataFlash chip and (eventually) firmware running in the card.
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      2e10c84b
    • David Brownell's avatar
      [PATCH] spi: misc fixes · 7111763d
      David Brownell authored
      This collects some small SPI patches that seem to be missing from the MM tree:
      
        - spi_butterfly kbuild hooks got dropped somehow; this restores them
        - quick fix for a (theoretical?) m25p80_write() oops noted by Andrew
        - quick fix for a potential config-specific oops for mtd_dataflash()
        - minor doc tweaks
      Signed-off-by: default avatarDavid Brownell <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      7111763d
    • David Brownell's avatar
      [PATCH] SPI core tweaks, bugfix · 0c868461
      David Brownell authored
      This includes various updates to the SPI core:
      
        - Fixes a driver model refcount bug in spi_unregister_master() paths.
      
        - The spi_master structures now have wrappers which help keep drivers
          from needing class-level get/put for device data or for refcounts.
      
        - Check for a few setup errors that would cause oopsing later.
      
        - Docs say more about memory management.  Highlights the use of DMA-safe
          i/o buffers, and zero-initializing spi_message and such metadata.
      
        - Provide a simple alloc/free for spi_message and its spi_transfer;
          this is only one of the possible memory management policies.
      
      Nothing to break code that already works.
      Signed-off-by: default avatarDavid Brownell <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      0c868461
    • David Brownell's avatar
      [PATCH] spi: add spi_driver to SPI framework · b885244e
      David Brownell authored
      This is a refresh of the "Simple SPI Framework" found in 2.6.15-rc3-mm1
      which makes the following changes:
      
        * There's now a "struct spi_driver".  This increase the footprint
          of the core a bit, since it now includes code to do what the driver
          core was previously handling directly.  Documentation and comments
          were updated to match.
      
        * spi_alloc_master() now does class_device_initialize(), so it can
          at least be refcounted before spi_register_master().  To match,
          spi_register_master() switched over to class_device_add().
      
        * States explicitly that after transfer errors, spi_devices will be
          deselected.  We want fault recovery procedures to work the same
          for all controller drivers.
      
        * Minor tweaks:  controller_data no longer points to readonly data;
          prevent some potential cast-from-null bugs with container_of calls;
          clarifies some existing kerneldoc,
      
      And a few small cleanups.
      Signed-off-by: default avatarDavid Brownell <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      b885244e
    • David Brownell's avatar
      [PATCH] spi: simple SPI framework · 8ae12a0d
      David Brownell authored
      This is the core of a small SPI framework, implementing the model of a
      queue of messages which complete asynchronously (with thin synchronous
      wrappers on top).
      
        - It's still less than 2KB of ".text" (ARM).  If there's got to be a
          mid-layer for something so simple, that's the right size budget.  :)
      
        - The guts use board-specific SPI device tables to build the driver
          model tree.  (Hardware probing is rarely an option.)
      
        - This version of Kconfig includes no drivers.  At this writing there
          are two known master controller drivers (PXA/SSP, OMAP MicroWire)
          and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML
          mentions of other drivers in development.
      
        - No userspace API.  There are several implementations to compare.
          Implement them like any other driver, and bind them with sysfs.
      
      The changes from last version posted to LKML (on 11-Nov-2005) are minor,
      and include:
      
        - One bugfix (removes a FIXME), with the visible effect of making device
          names be "spiB.C" where B is the bus number and C is the chipselect.
      
        - The "caller provides DMA mappings" mechanism now has kerneldoc, for
          DMA drivers that want to be fancy.
      
        - Hey, the framework init can be subsys_init.  Even though board init
          logic fires earlier, at arch_init ... since the framework init is
          for driver support, and the board init support uses static init.
      
        - Various additional spec/doc clarifications based on discussions
          with other folk.  It adds a brief "thank you" at the end, for folk
          who've helped nudge this framework into existence.
      
      As I've said before, I think that "protocol tweaking" is the main support
      that this driver framework will need to evolve.
      
      From: Mark Underwood <[email protected]>
      
        Update the SPI framework to remove a potential priority inversion case by
        reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
      Signed-off-by: default avatarDavid Brownell <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarGreg Kroah-Hartman <[email protected]>
      8ae12a0d
  4. 12 Jan, 2006 8 commits
    • Mark Haverkamp's avatar
      [SCSI] aacraid: README update · 6171b5ef
      Mark Haverkamp authored
      Received From Mark Salyzyn.
      
      Move the README from the driver directory to the Documentation directory.
      Updated the documentation, added descriptions for cards that
      were missing.
      Signed-off-by: default avatarMark Haverkamp <[email protected]>
      Signed-off-by: default avatarJames Bottomley <[email protected]>
      6171b5ef
    • akpm@osdl.org's avatar
      [PATCH] scheduler cache-hot-autodetect · 198e2f18
      [email protected] authored
      )
      
      From: Ingo Molnar <[email protected]>
      
      This is the latest version of the scheduler cache-hot-auto-tune patch.
      
      The first problem was that detection time scaled with O(N^2), which is
      unacceptable on larger SMP and NUMA systems. To solve this:
      
      - I've added a 'domain distance' function, which is used to cache
        measurement results. Each distance is only measured once. This means
        that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT
        distances 0 and 1, and on SMP distance 0 is measured. The code walks
        the domain tree to determine the distance, so it automatically follows
        whatever hierarchy an architecture sets up. This cuts down on the boot
        time significantly and removes the O(N^2) limit. The only assumption
        is that migration costs can be expressed as a function of domain
        distance - this covers the overwhelming majority of existing systems,
        and is a good guess even for more assymetric systems.
      
        [ People hacking systems that have assymetries that break this
          assumption (e.g. different CPU speeds) should experiment a bit with
          the cpu_distance() function. Adding a ->migration_distance factor to
          the domain structure would be one possible solution - but lets first
          see the problem systems, if they exist at all. Lets not overdesign. ]
      
      Another problem was that only a single cache-size was used for measuring
      the cost of migration, and most architectures didnt set that variable
      up. Furthermore, a single cache-size does not fit NUMA hierarchies with
      L3 caches and does not fit HT setups, where different CPUs will often
      have different 'effective cache sizes'. To solve this problem:
      
      - Instead of relying on a single cache-size provided by the platform and
        sticking to it, the code now auto-detects the 'effective migration
        cost' between two measured CPUs, via iterating through a wide range of
        cachesizes. The code searches for the maximum migration cost, which
        occurs when the working set of the test-workload falls just below the
        'effective cache size'. I.e. real-life optimized search is done for
        the maximum migration cost, between two real CPUs.
      
        This, amongst other things, has the positive effect hat if e.g. two
        CPUs share a L2/L3 cache, a different (and accurate) migration cost
        will be found than between two CPUs on the same system that dont share
        any caches.
      
      (The reliable measurement of migration costs is tricky - see the source
      for details.)
      
      Furthermore i've added various boot-time options to override/tune
      migration behavior.
      
      Firstly, there's a blanket override for autodetection:
      
      	migration_cost=1000,2000,3000
      
      will override the depth 0/1/2 values with 1msec/2msec/3msec values.
      
      Secondly, there's a global factor that can be used to increase (or
      decrease) the autodetected values:
      
      	migration_factor=120
      
      will increase the autodetected values by 20%. This option is useful to
      tune things in a workload-dependent way - e.g. if a workload is
      cache-insensitive then CPU utilization can be maximized by specifying
      migration_factor=0.
      
      I've tested the autodetection code quite extensively on x86, on 3
      P3/Xeon/2MB, and the autodetected values look pretty good:
      
      Dual Celeron (128K L2 cache):
      
       ---------------------
       migration cost matrix (max_cache_size: 131072, cpu: 467 MHz):
       ---------------------
                 [00]    [01]
       [00]:     -     1.7(1)
       [01]:   1.7(1)    -
       ---------------------
       cacheflush times [2]: 0.0 (0) 1.7 (1784008)
       ---------------------
      
      Here the slow memory subsystem dominates system performance, and even
      though caches are small, the migration cost is 1.7 msecs.
      
      Dual HT P4 (512K L2 cache):
      
       ---------------------
       migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz):
       ---------------------
                 [00]    [01]    [02]    [03]
       [00]:     -     0.4(1)  0.0(0)  0.4(1)
       [01]:   0.4(1)    -     0.4(1)  0.0(0)
       [02]:   0.0(0)  0.4(1)    -     0.4(1)
       [03]:   0.4(1)  0.0(0)  0.4(1)    -
       ---------------------
       cacheflush times [2]: 0.0 (33900) 0.4 (448514)
       ---------------------
      
      Here it can be seen that there is no migration cost between two HT
      siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory
      system makes inter-physical-CPU migration pretty cheap: 0.4 msecs.
      
      8-way P3/Xeon [2MB L2 cache]:
      
       ---------------------
       migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz):
       ---------------------
                 [00]    [01]    [02]    [03]    [04]    [05]    [06]    [07]
       [00]:     -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [01]:  19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [02]:  19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [03]:  19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [04]:  19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1)
       [05]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1)
       [06]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1)
       [07]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -
       ---------------------
       cacheflush times [2]: 0.0 (0) 19.2 (19281756)
       ---------------------
      
      This one has huge caches and a relatively slow memory subsystem - so the
      migration cost is 19 msecs.
      Signed-off-by: default avatarIngo Molnar <[email protected]>
      Signed-off-by: default avatarAshok Raj <[email protected]>
      Signed-off-by: default avatarKen Chen <[email protected]>
      Cc: <[email protected]>
      Signed-off-by: default avatarJohn Hawkes <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      198e2f18
    • Andi Kleen's avatar
    • Andi Kleen's avatar
      [PATCH] x86_64: Don't reserve hotplug CPUs by default · f62a91f6
      Andi Kleen authored
      Most users don't need it so no need to waste memory.
      This means an user has to specify the appropiate number of
      hotplug CPUs on the command line with additional_cpus=...
      or fix their BIOS to follow the convention in
      Documentation/x86-64/cpu-hotplug-spec
      Signed-off-by: default avatarAndi Kleen <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      f62a91f6
    • Tore Anderson's avatar
      [PATCH] ext3: fix documentation of online resizing · e56d5ae3
      Tore Anderson authored
      Undocument the non-working resize= mount option in ext3, and add some
      references to the ext2resize package instead, which appears to be the only
      proper way of doing online resizing of ext3 filesystems.
      Signed-off-by: default avatarTore Anderson <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      e56d5ae3
    • Akinobu Mita's avatar
      [PATCH] doc: refer to kdump in oops-tracing.txt · 75ba0861
      Akinobu Mita authored
      Kdump has been merged and supported on several architectures.  It is better
      to encourage to use kdump rather than non standard kernel crash dump
      patches.
      Signed-off-by: default avatarAkinobu Mita <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      75ba0861
    • Akinobu Mita's avatar
      [PATCH] kdump: add dmesg gdbmacro into document · 8428cfe8
      Akinobu Mita authored
      Add gdb macro which print the kernel ring buffer into kdump docs
      Signed-off-by: default avatarAkinobu Mita <[email protected]>
      Signed-off-by: default avatarAndrew Morton <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      8428cfe8
    • Michael Krufky's avatar
      V4L/DVB (3349): Add PCI ID for UltraView DVB-T Plus, rebranded DViCO FusionHDTV DVB-T Plus · 6bfb2e1f
      Michael Krufky authored
      - Add PCI ID for UltraView DVB-T Plus,rebranded DViCO FusionHDTV DVB-T Plus
      Signed-off-by: default avatarMichael Krufky <[email protected]>
      Signed-off-by: default avatarMauro Carvalho Chehab <[email protected]>
      6bfb2e1f
  5. 11 Jan, 2006 3 commits
  6. 10 Jan, 2006 10 commits
  7. 09 Jan, 2006 5 commits