1. 03 1月, 2012 4 次提交
    • L
      pinctrl: make a copy of pinmux map · 97607d15
      Linus Walleij 提交于
      This makes a deep copy of the pinmux function map instead of
      keeping the copy supplied from the platform around. This makes
      it possible to tag the platforms map with __initdata as is also
      done as part of this patch.
      
      Rationale: a certain target platform (PXA) has numerous
      pinmux maps, many of which will be lying around unused after
      boot in a multi-platform binary. Instead, deep-copy the one
      we're going to use and tag them all __initdata so they go away
      after boot.
      
      ChangeLog v1->v2:
      - Fixup the deep copy, missed a few items on the struct,
        plus mark bool member non-const since we're making runtime
        copies if this stuff now.
      ChangeLog v2->v3:
      - Make a shallow copy (just copy the array of map structs)
        as Arnd noticed, string constants never get discarded by the
        kernel anyway, so these pointers may be safely copied over.
      Reviewed-by: NArnd Bergmann <arnd.bergmann@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      97607d15
    • L
      pinctrl: GPIO direction support for muxing · 542e704f
      Linus Walleij 提交于
      When requesting a single GPIO pin to be muxed in, some controllers
      will need to poke a different value into the control register
      depending on whether the pin will be used for GPIO output or GPIO
      input. So create pinmux counterparts to gpio_direction_[input|output]
      in the pinctrl framework.
      
      ChangeLog v1->v2:
      - This also amends the documentation to make it clear the this
        function and associated machinery is *ONLY* intended as a backend
        to gpiolib machinery, not for everyone and his dog to start playing
        around with pins.
      ChangeLog v2->v3:
      - Don't pass an argument to the common request function, instead
        provide pinmux_* counterparts to the gpio_direction_[input|output]
        calls, simpler and anyone can understand it.
      ChangeLog v3->v4:
      - Fix numerous spelling mistakes and dangling text in documentation.
        Add Ack and Rewewed-by.
      
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NThomas Abraham <thomas.abraham@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      542e704f
    • C
      pinctrl: add a pin_base for sparse gpio-ranges · 3c739ad0
      Chanho Park 提交于
      This patch enables mapping a base offset of gpio ranges with
      a pin offset even if does'nt matched. A base of pinctrl_gpio_range
      means a base offset of gpio. However, we cannot convert gpio to pin
      number for sparse gpio ranges just only using a gpio base offset.
      We can convert a gpio to real pin number(even if not matched) using
      a new pin_base which means a base pin offset of requested gpio range.
      Now, the pin control subsystem passes the pin base offset to the
      pinmux driver.
      
      For example, let's assume below two gpio ranges in the system.
      
      static struct pinctrl_gpio_range gpio_range_a = {
          .name = "chip a",
          .id = 0,
          .base = 32,
          .pin_base = 32,
          .npins = 16,
          .gc = &chip_a;
      };
      
      static struct pinctrl_gpio_range gpio_range_b = {
          .name = "chip b",
          .id = 0,
          .base = 48,
          .pin_base = 64,
          .npins = 8,
          .gc = &chip_b;
      };
      
      We can calucalate a exact pin ranges even if doesn't matched with gpio ranges.
      
      chip a:
          gpio-range : [32 .. 47]
          pin-range  : [32 .. 47]
      chip b:
          gpio-range : [48 .. 55]
          pin-range  : [64 .. 71]
      Signed-off-by: NChanho Park <chanho61.park@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3c739ad0
    • S
      pinctrl: add explicit gpio_disable_free pinmux_op · 3712a3c4
      Stephen Warren 提交于
      Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
      completely different manner than they select which function to mux out of
      that pin. In order to support a single "free" pinmux_op, the driver would
      need to maintain a per-pin state of requested-for-gpio vs. requested-for-
      function. However, that's a lot of work when the core already has explicit
      separate paths for gpio request/free and function request/free.
      
      So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
      call it when appropriate.
      
      When doing this, I noticed that when calling pin_request():
      
          !!gpio == (gpio_range != NULL)
      
      ... and so I collapsed those two parameters in both pin_request(), and
      when adding writing the new code in pin_free().
      
      Also, for pin_free():
      
          !!free_func == (gpio_range != NULL)
      
      However, I didn't want pin_free() to know about the GPIO function naming
      special case, so instead, I reworked pin_free() to always return the pin's
      previously requested function, and now pinmux_free_gpio() calls
      kfree(function). This is much more balanced with the allocation having
      been performed in pinmux_request_gpio().
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      3712a3c4
  2. 24 11月, 2011 2 次提交
  3. 23 11月, 2011 3 次提交
  4. 20 11月, 2011 1 次提交
    • M
      drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS · e70f224c
      Marek Olšák 提交于
      This adds a new optional chunk to the CS ioctl that specifies optional flags
      to the CS parser. Why this is useful is explained below. Note that some regs
      no longer need the NOP relocation packet if this feature is enabled.
      Tested on r300g and r600g with this flag disabled and enabled.
      
      Assume there are two contexts sharing the same mipmapped tiled texture.
      One context wants to render into the first mipmap and the other one
      wants to render into the last mipmap. As you probably know, the hardware
      has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
      but that only applies to samplers.
      (at least on r300-r500, though later hardware likely behaves the same)
      
      So we want to just re-set the tiling flags before rendering (writing
      packets), right? ... No. The contexts run in parallel, so they may
      set the tiling flags simultaneously and then fire their command streams
      also simultaneously. The last one setting the flags wins, the other one
      loses.
      
      Another problem is when one context wants to render into the first and
      the last mipmap in one CS. Impossible. It must flush before changing
      tiling flags and do the rendering into the smaller mipmaps in another CS.
      
      Yet another problem is that writing copy_blit in userspace would be a mess
      involving re-setting tiling flags to please the kernel, and causing races
      with other contexts at the same time.
      
      The only way out of this is to send tiling flags with each CS, ideally
      with each relocation. But we already do that through the registers.
      So let's just use what we have in the registers.
      Signed-off-by: NMarek Olšák <maraeo@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e70f224c
  5. 19 11月, 2011 1 次提交
    • D
      hugetlb: remove dummy definitions of HPAGE_MASK and HPAGE_SIZE · a5c86e98
      David Rientjes 提交于
      Dummy, non-zero definitions for HPAGE_MASK and HPAGE_SIZE were added in
      51c6f666 ("mm: ZAP_BLOCK causes redundant work") to avoid a divide
      by zero in generic kernel code.
      
      That code has since been removed, but probably should never have been
      added in the first place: we don't want HPAGE_SIZE to act like PAGE_SIZE
      for code that is working with hugepages, for example, when the
      dependency on CONFIG_HUGETLB_PAGE has not been fulfilled.
      
      Because hugepage size can differ from architecture to architecture, each
      is required to have their own definitions for both HPAGE_MASK and
      HPAGE_SIZE.  This is always done in arch/*/include/asm/page.h.
      
      So, just remove the dummy and dangerous definitions since they are no
      longer needed and reveals the correct dependencies.  Tested on
      architectures using the definitions with allyesconfig: x86 (even with
      thp), hppa, mips, powerpc, s390, sh3, sh4, sparc, and sparc64, and with
      defconfig on ia64.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a5c86e98
  6. 18 11月, 2011 1 次提交
    • R
      PM Sleep: Do not extend wakeup paths to devices with ignore_children set · 8b258cc8
      Rafael J. Wysocki 提交于
      Commit 4ca46ff3 (PM / Sleep: Mark
      devices involved in wakeup signaling during suspend) introduced
      the power.wakeup_path field in struct dev_pm_info to mark devices
      whose children are enabled to wake up the system from sleep states,
      so that power domains containing the parents that provide their
      children with wakeup power and/or relay their wakeup signals are not
      turned off.  Unfortunately, that introduced a PM regression on SH7372
      whose power consumption in the system "memory sleep" state increased
      as a result of it, because it prevented the power domain containing
      the I2C controller from being turned off when some children of that
      controller were enabled to wake up the system, although the
      controller was not necessary for them to signal wakeup.
      
      To fix this issue use the observation that devices whose
      power.ignore_children flag is set for runtime PM should be treated
      analogously during system suspend.  Namely, they shouldn't be
      included in wakeup paths going through their children.  Since the
      SH7372 I2C controller's power.ignore_children flag is set, doing so
      will restore the previous behavior of that SOC.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8b258cc8
  7. 17 11月, 2011 5 次提交
  8. 16 11月, 2011 5 次提交
  9. 14 11月, 2011 1 次提交
  10. 12 11月, 2011 1 次提交
  11. 11 11月, 2011 6 次提交
  12. 10 11月, 2011 1 次提交
  13. 09 11月, 2011 3 次提交
  14. 08 11月, 2011 3 次提交
  15. 07 11月, 2011 3 次提交
新手
引导
客服 返回
顶部