1. 04 3月, 2013 2 次提交
    • K
      regulator: core: manage enable GPIO list · 967cfb18
      Kim, Milo 提交于
       To support shared enable GPIO pin, replace GPIO code with new static functions
      
       Reference count: 'enable_count'
         Balance the reference count of each GPIO and actual pin control.
         The count is incremented with enabling GPIO.
         On the other hand, it is decremented on disabling GPIO.
         Actual GPIO pin is enabled at the initial use.(enable_count = 0)
         The pin is disabled if it is not used(shared) any more. (enable_count <=1)
         Regardless of the enable count, update GPIO state of the regulator.
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Reviewed-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      967cfb18
    • K
      regulator: core: support shared enable GPIO concept · f19b00da
      Kim, Milo 提交于
       A Regulator can be enabled by external GPIO pin.
       This is configurable in the regulator_config.
       At this moment, the GPIO can be owned by only one regulator device.
       In some devices, multiple regulators are enabled by shared one GPIO pin.
       This patch extends this limitation, enabling shared enable GPIO of regulators.
      
       New list for enable GPIO: 'regulator_ena_gpio_list'
         This manages enable GPIO list.
      
       New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
         The enable count is used for balancing GPIO control count.
         This count is incremented when GPIO is enabled.
         On the other hand, it's decremented when GPIO is disabled.
      
       Reference count: 'request_count'
         The reference count, 'request_count' is incremented/decremented on
         requesting/freeing the GPIO. This count makes sure only free the GPIO
         when it has no users.
      
       How it works
         If the GPIO is already used, skip requesting new GPIO usage.
         The GPIO is new one, request GPIO function and add it to the list of
         enable GPIO.
         This list is used for balancing enable GPIO count and pin control.
      
       Updating a GPIO and invert code moved
         'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
          new function, regulator_ena_gpio_request().
          Use regulator_enable_pin structure rather than regulator_dev.
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Reviewed-by: NAxel Lin <axel.lin@ingics.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      f19b00da
  2. 03 3月, 2013 4 次提交
    • J
      metag: Internal and external irqchips · 5698c50d
      James Hogan 提交于
      Meta core internal interrupts (from HWSTATMETA and friends) are vectored
      onto the TR1 core trigger for the current thread. This is demultiplexed
      in irq-metag.c to individual Linux IRQs for each internal interrupt.
      
      External SoC interrupts (from HWSTATEXT and friends) are vectored onto
      the TR2 core trigger for the current thread. This is demultiplexed in
      irq-metag-ext.c to individual Linux IRQs for each external SoC interrupt.
      The external irqchip has devicetree bindings for configuring the number
      of irq banks and the type of masking available.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Rob Landley <rob@landley.net>
      Cc: Dom Cobley <popcornmix@gmail.com>
      Cc: Simon Arlott <simon@fire.lp0.eu>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: devicetree-discuss@lists.ozlabs.org
      Cc: linux-doc@vger.kernel.org
      5698c50d
    • J
      metag: Time keeping · a2c5d4ed
      James Hogan 提交于
      Add time keeping code for metag. Meta hardware threads have 2 timers.
      The background timer (TXTIMER) is used as a free-running time base, and
      the interrupt timer (TXTIMERI) is used for the timer interrupt. Both
      counters traditionally count at approximately 1MHz.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      a2c5d4ed
    • H
      parisc: check return value of down_interruptible() in hp_sdc_rtc.c · 15fb9683
      Helge Deller 提交于
      additionally comment out unused code (which may be used later)
      Signed-off-by: NHelge Deller <deller@gmx.de>
      15fb9683
    • Y
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu 提交于
      Tim found:
      
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
          set_cpu_sibling_map+0x279/0x449
          start_secondary+0x11d/0x1e5
      
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      
      It turns out movable_map has some problems, and it breaks several things
      
      1. numa_init is called several times, NOT just for srat. so those
      	nodes_clear(numa_nodes_parsed)
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
      	anymore.
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      node.
      
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      
      So just remove that offending commit and related ones including:
      
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
      
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
          SRAT")
      
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
      
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
          ready")
      
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
      
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
      
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
      
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
      
       4d59a751 ("x86: get pg_data_t's memory from other node")
      
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: NTim Gardner <tim.gardner@canonical.com>
      Reported-by: NDon Morris <don.morris@hp.com>
      Bisected-by: NDon Morris <don.morris@hp.com>
      Tested-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20e6926d
  3. 02 3月, 2013 32 次提交
  4. 01 3月, 2013 2 次提交